Michael Dawson | Node.js Community updates | In the Open with Luke and Joe

Luke Schantz: What you're about to hear is a new podcast and livestream show entitled In the Open with Luke and Joe. In this series, my co- host Joe Sepi and I bring you conversations with community and technical leaders from the world of open source and enterprise tech. We do this live twice a month on Fridays at 12:00 noon Eastern Time. You can catch us on a variety of streaming platforms or here as a replay on your favorite podcast app. To find out all the details, go to IBM. biz/ IntheOpen. There, you will find our show schedule, an embedded player of the live streaming video, as well as embeds of past episodes. Or, you can link directly to the podcast page with IBM. biz/ IntheOpenPodcast. Thanks so much. I hope you enjoy our new series, In the Open with Luke and Joe. Welcome to In the Open with Luke and Joe. I'm your host, Luke Schantz, and here's my co- host Joe Sepi. And, a big welcome to our guest, Michael Dawson. Before we get to our show, don't forget to like and subscribe. Thanks for joining us. Today, we are pleased to bring you a conversation with Michael Dawson. Michael is the Node. js lead for Red Hat and IBM. He's on the Node technical steering committee and has extensive experience in the community. We're going to be talking about upcoming releases, the next 10 years of Node. js, and much, much more. But, before we welcome Michael, let's say hello to my co- host Joe Sepi. Welcome, Joe. Good to see you. I can't hear you, Joe.

Joe Sepi: Let me unmute.

Luke Schantz: There, I can hear you now.

Joe Sepi: This is the world we live in.

Luke Schantz: So, let me ask you, Joe, how is the weather?

Joe Sepi: The weather, it started out really nice today. It was in the 60s, but then it started raining. But, it's still a nice day. I'm going to stick with it. How about you? We're not that far away, but how's the weather by you?

Luke Schantz: Back to the microclimate conversation we've had before, it's not raining here. Yeah, so it's strange. I do think we need to do some kind of community data plotting around this microclimate.

Joe Sepi: I think, yeah, that would be great, but without further ado.

Luke Schantz: That's exactly what I was going to say. Let's welcome our guest. Hello, Michael. Welcome to the show.

Michael Dawson: Hey, thanks for having me. Great to be here. And, it's not raining here either, just in case you're interested.

Joe Sepi: Great. Yeah, welcome, Michael. I wanted to mention too, in Luke's intro, you're not only on the TSC, but you've been the chair of the TSC for a little while now.

Michael Dawson: Yeah, the last few years. It's been great to be able to do that and help keep things going. We have quite a few people on the technical steering committee, and everybody really helps keep the project going.

Joe Sepi: Yeah, it's a really great community- run platform overall, and we can get into that in a minute. But, first I just want to jump right into the breaking news, the exclusive here with Michael Dawson. We've got some news Michael is bringing to us today. Michael, what is this incredibly awesome breaking news you've got?

Michael Dawson: I hate to rain on your parade, but it's really not breaking news. If I show you the release schedule here, we try really hard to make sure that the Node. js project has predictable and reliable releases. Tomorrow, we're planning for the 16.x release. You probably knew about that a year ago, and in fact, I can predict that next year at the exact same time, there's going to be an 18. x release. As you can see, every six months like clockwork, we're going to have a release. So, sorry if it's not so breaking, but it's still very interesting and important, of course.

Joe Sepi: Yeah, yeah. Okay, I admit I knew it wasn't really breaking, but it is super exciting. Everybody is abuzz with all these amazing features that are coming out tomorrow.

Michael Dawson: Unfortunately, I sometimes get the question, why are releases so boring? It's because we work really hard to make sure that our releases are as easy to consume for end users. Yeah, we have a major release, which is semver- major, which means it could have breaking changes in it. But, those breaking changes we try and work hard, and we're very cautious. So, even though we tag things as breaking changes, they won't affect most people. When we get to this major release, we do have some breaking changes, but they're not really the interesting things. The most interesting things are some of our minor changes, which are new features. But, the project is also really quite... It works hard to actually flow those back into the hands, so you don't have to wait, unlike some projects where if you want to get the new stuff, you better upgrade to the latest version, and you're just waiting for that version. We're very good at flowing those changes back into the hands. A lot of changes that are coming out in 16, they were already available in 15 and in 14. So, we backport it, so lots of good stuff, really great. I think it's still really important, because it's the first time here where 16 is going to become an LTS. Even though you might have been able to try out some of those changes before, it's the first time you'll be able to use them in a version that will go LTS. But, in terms of content, it maybe rain on your plate again, maybe not quite as exciting as we'd like sometimes.

Joe Sepi: Yeah, I'm joking around here, just having a good time. I think it's a really interesting point though, right? Because, this is the sort of predictability that you want in a mature platform companies can adopt and feel comfortable knowing what's coming ahead and plan their transitions and all these kinds of things. The backporting that you mentioned is a lot of work that we do in the community, but still exciting, right?

Michael Dawson: Oh, yeah, definitely exciting. It's a great time to talk about what's Node, what things have come. I like to even talk about things that have come back. Maybe they're even two releases back, because we do releases every six months. That's pretty often. It's a great time to remind people that there's some of this new functionality. There's tons of work that goes in the project. If you tried to track the things, when I come back to GitHub after missing a few days, there can easily be three, 400 issues here. So, there's always lots of stuff going on. Just sometimes when we come to these major releases, you look at it and say, " Oh, that's already in the people's hands." So, there's not as much. It might not seem like there's as much as there really is, because there's always lots of stuff going on.

Joe Sepi: Yeah, yeah, that's cool, really active, vibrant community and platform. It's really great. Do you want to talk about some of the things that some people should be excited about with version 16?

Michael Dawson: Let's save most of the nitty gritty details for tomorrow, because I don't want to take the fender out of the release itself. But, there are a bunch of interesting things. There's the ones that we expect that always in our semver- major like a new upgrade to V8. There's usually something on the diagnostic side. We have a longer term effort around bringing promise based APIs to Node. So, there's something there as well. I think we'll see a good number of different features, but we'll leave the details of what's specifically in to the release announcement for tomorrow.

Joe Sepi: Cool, cool. Where should we look? Obviously, I guess on the Node site, we'll see announcement details and such.

Michael Dawson: Yeah, there should. There'll be a blog post that comes out. We do that every time that has a list of all the main things that we want to call out. I'm also doing a blog post on the Red Hat Corporate Developer blog, because it gives a little bit of the Red Hat and IBM perspective on the new releases, how some of the people on our team have been involved. For example, Bethany is preparing the release. She's on the releases team. Different people on the team help with the release infrastructure and all that kind of stuff, but to give a little bit of an insight of my perspective on some of that as well.

Joe Sepi: Cool. Do you want to talk at all about how releases go? I can pull this schedule back up.

Michael Dawson: Sure. We have an LTS schedule, and what happens is we have a current, which is a semver- major every six months. Then, every other current becomes an LTS release. This release will become the new current. It'll be 16, but it'll be current for six months, which is great, because it gives us time for people to try out the release, give us feedback. So, by the time it becomes the LTS in October, we have a pretty solid feeling that this is something that people should be moving up to and using in production. If you look at the release schedule, you'll see that currently, we have 10 and 12, actually 10, 12 and 14 as our current LTSs. 10 goes out of service though at the end of this month, about the same time as we do a new release for the next 16. x release. So, if anybody is still using 10, they should really think about... Hopefully, they've already thought about moving over, but if you haven't yet, it's really time to do that, because there won't be any more updates and security releases, any of those kinds of things after the end of the month.

Joe Sepi: And, if you're on 12, you have about a year to be making sure that you're not on unmaintained line.

Michael Dawson: Exactly. That's what's nice about this schedule is you can predict. Okay, the next release is going to come out. 16 is coming out. It's going to become LTS in October. So, do I want to move up to 14? Do I want to want to wait for that? You could plan that in terms of then, I then have one or two years to go before I'm going to have to update again. So, it is quite nice and predictable. We've been doing this... Oh, I can't remember now, but I think it was back to six, which would be two, three years ago. So, it's been working pretty well. I think we hear people like that predictability, although I'm still shouting to as many people as I can. Because, sometimes it's when is the next release? Oh, the next release is going to be either April or October, and the next LTS is in October. It doesn't seem like we got the message out there to everybody quite yet.

Luke Schantz: Well, now you have, because everyone is listening to this podcast.

Michael Dawson: Okay, that's right. We got everybody.

Luke Schantz: Everyone knows now.

Joe Sepi: I roped them in with the breaking news, so now we know we've got them all.

Michael Dawson: Yeah, maybe minus one or two people. The other billion, X billion will be there.

Joe Sepi: Sounds good.

Luke Schantz: Well, I think it is. Actually, when you're so involved with it, sometimes you can take these things for granted. It is nice to have an opportunity on a platform like this to be able to unpack it and talk it through. I find it fascinating to see how we can bring both. We can have the innovation. We can have the openness. We can get involvement and have lots of ideas come in, but then do it in a way that's stable and that makes sense for the folks who need to rely on it.

Michael Dawson: Yeah, that's right. We have nightly builds for people who really want to live on the edge, can pull those, experiment. We have the current, which features flow back very quickly from the master into current. So, you can take those and use that if you're adventurous. Then, as you said, we've got the LTS ones, which typically the enterprise deployments or the more conservative people pick up and use in production. Yeah, I think it's never going to make everybody happy. Some people want some things to go faster. Some people want things to go slower, but I think we've found a pretty good balance between the two here in my opinion.

Joe Sepi: Yeah, yeah, I agree. People can use a tool like NVM or something to bounce around between the different versions, see if their app is broken, what they need to be aware of, and stuff. So, that's all cool. It's interesting too, I'm curious. This even numbered release lines, is that something that came elsewhere? Or, where did we get that from?

Michael Dawson: I think that really just, I don't remember it coming from any other sort of pattern or existing ecosystem. I think it just came from the pattern of we wanted to do a current fairly regularly, so six months, a fairly short period of time. But, we only wanted to do an LTS once a year, because the more LTSs, even at where we're at, we have 10, 12 and 14. That's quite a few to support. When we have to do security releases, we typically have to patch all three of them. So, we like to keep that number as small as we can. So, that's why we didn't want to do an LTS every six months. It just came out in that wanting to balance between, yeah, let's give something for people who really want something newer while keeping, limiting the number of LTS releases that we have in flight at the same time.

Joe Sepi: Yeah, and I know that JSON file, we could probably... I'm not suggesting you do this, but we could click in and see all the different releases. But, for example, Node.js 10, that probably came out a while ago, what, a couple years ago?

Michael Dawson: Oh, Node. js 10 would've come out three years ago around now, because we have 30 months support. For the first six months, it's current. Then, 30 months is about two and a half years where it's in the LTS phase. So, yeah.

Joe Sepi: Yeah, that's pretty impressive. I think that's a good sign of a stable, mature platform. That makes sense.

Michael Dawson: Definitely.

Joe Sepi: Cool. We've been talking about this new release, which again, folks, we're expecting it out tomorrow, April 20th of the year 2021. Let's capture that for our repeats later on, people watching later. But, there's also been, shifting gears here, there's been this Next- 10 effort that's been happening. Should we spend a moment to talk about what that is?

Michael Dawson: Yeah, I think that's a great idea. We're talking about a new release. It's when we talk about some of the new features and stuff like that, so it's a good time to think about, okay, what's coming? Now, I often get asked for, okay, where's the roadmap? The answer is the Node project doesn't have a roadmap, and it's on purpose. The work that gets done is based on the contributors and what they think is important. It's, I think, one of the most open projects. I've heard it been termed open source. What that means is there's no one company who's got an agenda and a schedule and a plan and is who's driving most of the work. There's lots and lots of work done, but it's done by a lot of individuals, a number of companies, each contributing people like yourself and me from IBM and Red Hat, people from other companies like Microsoft and so forth. But, there's no one map that says, " Hey, we're all agreed that this is the work we're going to do together." So, what happens in terms of features is what people are interested in, where they spend their time. That of course doesn't mean that we don't do planning. We do try and make sure that we plan for the future. We have things like strategic initiatives. So, if you go into the TSC repo or the community committee repo, we've got some strategic initiatives. You'll see things like adding promise APIs, improving our build infrastructure, and things like that. Node 10 is not that, but it's related. A couple years ago, time goes by so quickly now, I think it's actually over a year ago. Node had its 10th anniversary, and we were like, " Wow, it's such a great 10 years, first 10 years." It really became popular very quickly. It has had a great success, broad usage. So, the Next-10 is an effort to say, " Okay, we had a great first 10 years. How do we make the next 10 years just as good or better?" Part of that is we want to figure out technology- wise, what is it that we have to do? What's important? That turns out actually to be a pretty complex problem to figure that out. What is it that's going to be important? So, we've got to predict that. But, when we started looking at it, actually we even had to step back another couple steps. We had to say, " Okay, actually we need a pretty good understanding of what are the values of the project." Because, that's going to influence how we do these kinds of things. Give me one second. I'm going to pull up the first thing that we put together, which was the values. So, let me see.

Joe Sepi: And, the cool thing about this-

Michael Dawson: Technical values.

Joe Sepi: Yeah, I'll mention while you're looking is that you can see this is in GitHub, so almost everything we do in the Node space, we try to do as transparently as possible. So, you'll find these things in GitHub. You'll find issues. You'll find pull requests. The meetings are public, and we can get into that more later, but it's a great example. Oh, I need to find this thing. Oh, I'm going to go to the repo, because that's where it is.

Michael Dawson: Yeah, no, the project is very open, all the meetings, like you said, recordings, and so forth. People can get involved. So, this is very quickly, I don't want to go into detail on this, but we had to step back and say, " Okay, well, what are the values of the project?" Now, this isn't meant to be a... Here's what the values are. Here's what the they'll always be. This was meant to be the current state of the project. This is the values that we see being exhibited by the project. That can change over time. But, things like developer experience have always been very important, so making it great for developers to come and pick up and use Node. Of course, things like stability, we talked about the LTS release process where we've worked on that, so making sure that we're not constantly breaking people while we still allow innovation. Operational qualities, so things like being able to debug your applications, monitor, and things like that we think are quite important. Of course, we've always been very focused on trying to bring in as many people as we can in terms of contributing. So, the maintainer experience is important as well. Then, finally, up to date and technology and APIs are part of being the success as well, bringing in things like ES6, which is the new module system, making sure that Node itself stays up to date. These aren't all the values. Of course, there's lots of values, but this is what came out as the very top level things that whenever we're doing something, we should consider. Well, how does that affect developer experience? How does it affect stability, operational qualities? If somebody's proposing a new API, actually that could be important, because we want to be up to date with the API. So, this was the first thing we looked at, which was, okay, when we're going to evaluate what's important, what's the lens that we should be looking through in terms of making trade offs and balances and stuff like that?

Joe Sepi: Yeah, makes sense. You could come to these meetings and be like, " I want X. I want Y." To have this sort of framing, what are the values and the priorities, makes a lot of sense.

Michael Dawson: So, that was the first thing. Then, we started to say, " Okay, the next thing we should really understand is who uses Node. js. So, who are our users, so that we can understand what they need? Again, we had some good brainstorming sessions. We came up with this list of constituencies, which includes direct end users, application operators, application developers, of course, library package authors who build that great NPM ecosystem that we have, our core maintainers, and organizations who invest in Node. js. So, there are some very large organizations or even small organizations, but when you choose something like Node. js, you're making an investment, and you want to have confidence that it's going to continue to move forward, continue to meet your needs, and so forth. So, we came up with this list of constituencies. Then, we did some brainstorming to say, " Okay, now that we know that, what do those constituencies need?" So, we went through and said, " Okay, what are the different kinds of things that people could use?" I won't go through this whole list, but there's a good list there. Then, we tried to map it against those different constituencies to say, " Okay, which do we think each of them need?" The thing that we realize is the people who have been getting together to put this together are a small subset of all of these different constituencies. So, there's no way we can fully represent them. Thanks to help from the OpenJS Foundation, we've recently been running a survey. Unfortunately, it's closed, so you can't go and fill it out now. But, we may do other surveys as we move forward on this work. From what I hear, we had over 2, 500 responses. We went to people, asking, " Are you in one of these constituencies? Or, have we missed you under something, another one we should be considering? Are there key needs that are here that map your needs or that are missing?" I'm looking forward to seeing that data so that we can basically validate the sort of fundamental... I think this is the foundation on which we can start to talk about technologies like inaudible and TypeScript and all those things and say, " Okay, how does that fit into these constituencies, what they need, and have those things?"

Joe Sepi: Yeah. Sorry, go ahead.

Michael Dawson: No, no, go ahead.

Joe Sepi: I was going to say it's really interesting. First of all, I'm impressed with how much work has gone into these. I've been in a few of the meetings, but to see a table mapping out how these things play out is really... You're doing a great job with the team. We mentioned the survey, which just closed I think last Friday. But, if somebody is hearing this and wants to get involved, what would they do?

Michael Dawson: Well, basically just go to the Next- 10 repo, and I don't think there's an issue. Oh, there is an issue right there. So, the next meeting is the 22nd. About a week before or three to five days before, an issue is opened in the repo, which will have all the details. So, it has the dates and the times across different geos and a link to be able to join the meeting. Now, heads up, we are looking for a new time, but the current time I think is every other Thursday at... I think it's 11: 00 Eastern. Let's see, no, sorry, 12:00 Eastern. So, that's one way. You can also look at the Node. js calendar. So if, I go to NodeJS. org/ Calendar, this basically gives us the calendar. This is in Pacific, I believe. But, you can find here, and you can basically find all of the meetings for the project and find when the next one is going to be in advance of the issue being created. So, long answer to just say you can come on, show up in our meeting. You could also participate in the issues within GitHub. We've started already brainstorming some of what the key technical things are. We have a list, and we're starting to work through that. I find it really interesting to work through these things with the team. Hopefully, we'll come up with a good list that people recognize and say, " Yeah, those are things that we can rally around, and we want to help move forward as we work on them."

Joe Sepi: Yeah, A couple of quick things to point out. Number one, this calendar is in Pacific Time. I have to remind folks, but yeah, NodeJS. org/ Calendar. I go there regularly to see what's going on, what's on the calendar. But, again just going back to the comment before, the work is in the open, and people are encouraged to get involved, to see what's going on. And, it's all right here, NodeJS. org/ Calendar and the GitHub repos. Usually, there's a meeting issue, almost always when there's a Zoom link, the meeting doc. We check the meeting notes into the repos, so it's all there. I encourage folks to check it out and get involved, whether it's the Next- 10 initiative or other things like tooling. Maybe this is actually a good segue to talk about other initiatives that you're excited about, Michael. I know-

Michael Dawson: Yeah, I've got a couple.

Joe Sepi: You're in every meeting I'm in. I'm like, " Oh, Michael is here." So, I know you're doing a lot, but what are some of the things that you're excited about right now?

Michael Dawson: Yeah, there's a couple. I'd like to talk about package maintenance and the Node API. First, let's talk about the package maintenance. That one is around, and it brings together a number of people who are maintaining packages to deal with some of the issues that we were seeing a few years back in the package ecosystem. There's some things around how do we keep packages who are important, that are important to continue to be maintained. How do we help maintainers do that more efficiently? We have such a great ecosystem, but it also on the flip side, can cause us some grief, because if any one of those has security vulnerabilities or whatever, it can actually be an issue for the whole ecosystem as well. So, this group is around how do we help maintainers as well as consumers work together to make things as good as they can. One of the first things... Sorry, go ahead.

Joe Sepi: I was going to say it's a really important area to be focused on, because every time I talk to people about Node, that's one of the things that comes up, is how do you maintain packages and ensure that your application has packages that are up to date and whatnot?

Michael Dawson: Yeah, so one of the things we did do here, and just let me show you that, if you... One of the things we started out by doing was looking at guidance that we could provide package maintainers, so not necessarily telling anybody what to do or saying, " Hey, you have to do something like this." But, if you want some suggestions, you want some guidance on how to do things, I figure a lot of the times I just want to... What's the best practice? I just want to do that, versus figuring it out all myself. There's a few things that I'm super interested in, and I'll figure out Michael's best way of doing that. But, for the rest, I just want the guidance. That's some of the things we've worked on through that original guidance here. A particular one that I think is interesting is this package support. One of the things we see out there at times is the friction between, hey, I'm running my production system, and I'm having a problem. Then, I need help right now, because I'm in a panic. Then, the module owners, this isn't my day job. I did this. I gave it to you for free, but I can't drop my day job and come help you. So, there's sometimes a mismatch between expectations. Hey, yeah, I made a package. Wow, there's 20 million downloads a week. I never expected that, but it's still not my day job. So, this package support information is intended to help the maintainer communicate to the consumers some expectations, and vice versa, for the consumers to be able to say, " Let me better understand the expectations I should have on the modules and packages that I'm using." I hope that someday this may become just as widely used as say the license information. Most modules or packages include a license information. There's lots of tooling which we'll go through and scan for that information and tell you, are there any concerns in terms of the licenses of the packages you're using? As a consumer, you make your choices based on that information. So, this package maintenance information helps the maintainers add in, and I'm trying to find three main things, target, response, and backing. Target is not like the engines field, but sometimes people confuse it, because it's in the same space. It's not specifically which versions of Node my modules support. It's meant to communicate what model am I following. For example, LTS can mean that whenever there's a new LTS, I'll plan to support that LTS version. When a version drops out of LTS, I'm no longer going to support. So, it tells you the bounds, a moving set of bounds of what will be supported. There's a number of different ones. It could be, no, I know some maintainers say, " I want to support every version of Node that was ever out there." Other people just want to say, " I support the very latest." So, this is intended to communicate that so that the consumer can say, " Oh, I understand that that model of support will fit how long I want to use a Node version and so forth." Response is about what should be the expectations of support? Can you get paid support? Do you expect a response seven days, one day, whatever? Or, is there just no support? Or, is it best effort? Again, it's a good way to communicate, this is the level of support that you should expect, and that's the expectation. Then, finally backing is how is the project supported? Am I just doing this in my... Is this a Michael Dawson, I'm doing this in my spare time, fun project, so it's a hobby? Or, is it backed by Red Hat, because it's a module that we build as a team, and we support it and so forth? So, you get those three different things that the maintainer can communicate back to the consumers. Hopefully, the consumers can factor that in, and we reduce some of that friction so that the expectations are good, then there should be no friction. I also really hope that it serves as a way to help consumers and businesses understand their modules and contribute back to those modules, either by getting involved in helping to submit PRs to fix issues they have, to add features they want, fund it through funding platforms, adjoin things like the open JS Foundation. Because, open source is freely available, but it doesn't mean that it's free for a business. Anything that you integrate into your application brings some risk. To properly manage your risk, I think one of the things you should do is to understand your modules and make sure you're active in making sure that those modules are great and continue to remain great.

Luke Schantz: I find this so fascinating. Thank you for unpacking this, Michael, because I'm going to start with the last thing you just said there. I think it is. On the internet, it's so easy to lurk and be like, " Oh, I got this code." But, if you're using something, especially in production, you want to speak up, be proactive, get involved early, and maybe even contribute to it. If you hear that, hey, this is popular, and people are using it, and it's something that has value, knowing that upfront is probably going to avoid having these issues down the road. I would say to be a little bit of meta here, I love that we can analyze this, because whether you're into JavaScript and Node or not, it's so interesting just to get a cross section of how this works. So, if you want to be involved in any open source or you're looking to open source a project, this is a masterclass in how to do it and how maybe your stakeholders are different. Maybe it's a different set of circumstances, but this is all... I love seeing how all the parts fit together. So, thank you so much for sharing. I do want to mention one thing. I know Joe has some stuff he wants to switch gears on, but I just want to mention if anybody's listening and they have any questions, please drop them in the chat on whatever platform you're listening, and we will aggregate those, and we'll get to them towards the end of the conversation here.

Joe Sepi: Yeah, I think I heard Michael's squeaky chair trying to ask a question. It's great that there's such high quality here that we can hear squeaky chairs. Cool, yeah, that's all awesome work. The package maintenance stuff is really active, and there's great stuff happening there. Anything else on that one?

Michael Dawson: Yeah, yeah, before we move on. On this one, I would say I'm asking package maintainers if you can read up on it and add it to your modules. We did that through all the ones that we have in the Node Shift repo. We're going to be talking to maintainers at IBM and Red Hat to ask them to do that as well. Another really interesting thing the team is working on is called WIBY. It's Will I Break You? It's meant to help package maintainers, because we have fairly deep chains of module dependencies. It's intended to help maintainers figure out if the changes they're making are going to break any of the modules that depend on them. So, that's another great thing to check out, because it's fairly early on, but it's intended to let you run the modules that use tests to validate that you're not breaking them. I think this is something that may take time, but over time, I hope that we can cooperatively work together. Because, it's very hard for me as a package maintainer to replicate and get all the infrastructure that I need to run everybody else's tests. But, WIBY actually works so that you can farm and distribute some of that effort off by, say running tests in... If I maintain Michael's package, and somebody else... and I'm using Joe's package, and Joe is changing his package. He could delegate a test run to my CI, and it's good for me, because I'll find out whether what he's doing is going to break me or not. And, he will find that in advance, and maybe he'll avoid breaking my package, so I won't even have to worry about it. So, that's something as a maintainer, again I'd say, " Hey, if you can, check it out, and think about how it might work in your environment, and participate." We're currently doing some early testing and stuff like that. That would be great. Then, the team just overall gets together and talks about how we try and improve the package maintenance for the overall ecosystem. We did some work around how do we help maintainers bring on new people in the express ecosystem and a number of other things. But, that's another one of these things that, hey, open meetings. You can come. They're on the calendar. So, if you're interested in a maintainer, it'd be great to see you there.

Joe Sepi: Very cool. Did you mention the collaboration spaces at all? I'm checking our notes here.

Michael Dawson: I forgot about that. That's a good point. So, one of the issues that we're talking about which I think is really interesting is probably pretty timely, is that if you maintain a module or an application, you've probably run into this case where one of your dependencies has a security vulnerability. You look at it, and it doesn't even affect you. We've had that in the Node project. Say there's a security vulnerability in NPM and NPM looks at it. They're not even using the API, but they issue a security release. Then, at the Node project, we look at it and say, "There wasn't even an issue in NPM, but we better issue a security release anyway." So, tons of work for no benefit. The security scanners are like, " Hey, there's problems. There are problems." The collaboration space that Joe mentioned is a way to get people together to talk about that issue and see if we can come up with a good way to address that problem. Collaboration spaces are a new concept in the OpenJS Foundation. To start with, we formed the foundation as a great place to support projects, important JavaScript projects. This is a way to support important JavaScript conversations and topics. So, you don't need to have a project. You don't need to contribute code, but if there's something of importance to the JavaScript ecosystem, you can bring together a number of people, a number of people, organizations, whatever, get support from the OpenJS Foundation, so things like repos, Slack channels, emails, things which aren't necessarily vast in scope, but that are very important, even just a Zoom call so you can have a video so that you can bring people to collaborate together, support from the OpenJS Foundation to move these issues forward. The first one came out of the package maintenance assistant working group, which is to look at a dependent, a security vulnerability chaining up. And, how do you break the chain where it no longer applies? Then, you'll save everybody a whole bunch of problems. That one, I think is in the process of kicking off. We're starting. There should be the announce soon with a call to, hey, get involved. Here, we're setting up meetings and all that. So, if you've ever had that problem, have some ideas, maybe you want to get involved in trying to fix that. We're of course looking to bring people like NPM and Snyk and the people who are doing security vulnerabilities. Even as I work more within Red Hat, I learn that Red Hat actually has teams who are working on security reporting as well in terms of looking at containers. So, I'm going to need to pull some of them into these conversations as well so that hopefully the things that are actually reporting the vulnerabilities participate in whatever solution that we come up with.

Joe Sepi: Yeah, I think really, the collaboration spaces is really an interesting concept. I think the OpenJS Foundation provides a lot of value. Granted, I'm a little biased as a chair of the CPS, but I love this idea. We work hard to support the projects and the projects communities, but to try to think about it even beyond that and just bring people to the table and figure out ways to work together. I think it's really a great concept.

Michael Dawson: Yeah, so again, if anybody out there has a shared problem and they want some support into bringing it to somewhere where we can have a productive, level playing field type discussion, you can check it out. Again, maybe I can share that too, if I go there. Anybody can propose one, and I'm just looking for collaboration spaces here. Collaboration network, I think you can go there, and it will have some of the support you can get. There's a document that explains how you actually submit a proposal. We of course do expect people to come with some expertise, and so we want the champions to be recognized in the area that they're bringing in some way or bringing together a group of people that can actually talk to that issue. But, it's like everything else, and so if you have a challenge or have a problem you think we should be talking about as an ecosystem, it's a great place to bring it up and propose that.

Joe Sepi: Great, cool. We have a couple of things on the list here that I might skip over, unless you want to talk about Node API or the platforms.

Michael Dawson: Our time is going pretty quickly. I always like to talk about Node API, but it is pretty specialized in terms of people writing native code. So, we can probably move on from that one to the next time.

Joe Sepi: Yeah, sure.

Michael Dawson: Platforms, I'll just mention our involvement did start from the IBM side on bringing P and Z to Node. We still do a lot of work to keep the CIs going, make sure it's working on AI X and Linux on Z. But, not only that, our team also helps with newer, with other platforms. One of the ones that Ash helped in the last release is the Apple Silicon. I know there's lots of interest in that, so I still wanted to mention that. It's looking good as far as I know, that we should have the binaries which run natively on Apple Silicon and the installers being able to install and then actually being a fat binary, so they'll run on either Intel or the Apple Silicon. So, I think that's worth mentioning just before we move on.

Joe Sepi: Yeah, yeah, good, good. So, to move things along, I know you and I are rather fortunate that we get to do a lot of work in the community, but there's also a lot of work that we have going on in IBM and Red Hat and stuff. Maybe let's shift gears and talk about some of that. Maybe start with the reference architecture.

Michael Dawson: Yeah, sure. Yeah, but as you said, one of the great things about our role is that we get to work in the community helping to build Node, but the flip side is that we also get to work within organizations that are using and deploying Node. js. I always find that we have pretty good insight and knowledge, deep level knowledge into the runtime itself and what's going on there. But, that's actually quite different than the knowledge of somebody who's deploying their application. It has to keep it running in production. So, the great thing I find is that being in IBM and now in Red Hat, we get to meet and work with the people who actually do that work. The reference architecture is an attempt to try and capture some of what we've learned, because even within our own organizations, it's actually pretty hard to share that information, how you can have one group doing something with Node. Then, the next group comes along, and they may be inventing the wheel themselves. It all goes back to if I have no interest in trying to argue people into using a particular technology or particular component, but my personal perspective is that most of the time, it's maybe the 20% of your app is where you really want to be aggressive in terms of choosing the leading edge things or trying out new techniques or doing something which is going to make your magic sauce. The other 80%, I just want a reasonable choice. I don't want to choose the worst thing that gets me into trouble later, but I just want one that other people have used that's worked successfully for them. So, the reference architecture is about giving you those reasonable choices. There may be better choices, but they're ones that people within IBM or Red Hat have used and that we found work for us and that we can pass on some of the experience that we have with them. So, we're not going to claim to be the experts in all of these different areas, but if you find it useful, it's some experience in terms of what we've done and what we found worked for us. I find it really fascinating, because it's basically a learning experience for me when I get to get together with the group. We have people who are running super large deployments. The Weather Company is an example, and I'll talk about that. We have some great success stories, but it's something like 10 different geos. So, there's Kubernetes clusters running in 10 different geos. There's hundreds of pods running in each of those. It's one massive Node. js application running across the world. Getting the experience from the people who are working on that, it's nothing that I could get. It's totally different from working in the project itself. So, it's really great to get that different perspective. We have a bunch of those different perspectives within Red Hat and IBM, because we have consultants who are out working with customers. We have the people who are running and building applications for our internal use. We have these external systems. We even have people working in ecosystems. IBM I is an ecosystem where it's ran a really long time, but at this point, 25% of the customers in that ecosystem use Node. js. You get the different perspectives from all the different people, and we're trying to capture that as we work through in this reference architecture, still work in progress, quite often will be. Once we're done, there'll be something new and changing and stuff, but whenever possible, it's based on what we use internally or with customers. This is also to give us some focus as well. The great thing about the Node ecosystem is it's so broad, but sometimes the bad thing is that it's so broad, because we can't invest in and be knowledgeable about 10 different logging packages, 10 different app servers, 10 different clients of whatever flavor. So, this is also to give us some focus to say, here are the ones we're familiar, we know we've used. So, they're reasonable. If we're going to invest time in those projects, those are the ones we'll spend some time investing in. If our customers don't have a better reason to use something else, if they choose those when they come to us to talk about their Node deployments, we'll be familiar with them. We can actually talk much more knowledgeably. We can help them more easily. So, it's just not meant to exclude anything, but to give us some focus just in terms of what we look at. Because, you just can't look at everything. We have quite a broad set of topics that we want to cover, so you can see we've covered some of them in terms of template engines, message queuing, internationalization, GraphQL. And, we just continue as we can, because again, it's not anybody's... necessarily their full- time job to create this reference architecture. We bring together people from all these different groups, and we try and capture and collate and distill down their experiences. We try and keep the recommendations fairly small, so you can see it's, hey, here's a module that we recommend. Here's some reasons around it. There are some challenges in that particular case. There can be then a small amount of guidance always along with using that. To go along with this, we're also planning a sort of blog post series where we talk a little bit more about the really interesting conversations we had when we went through this. Thank you for putting up there, it's the link to the part one where I introduced the concept. We have the first one on logging basically should be published anytime soon. Lined up behind that, we have one on linting and code quality, and we have some other interesting ones lined up as well. Those are the ones where we hope to get into a little bit more of the discussion behind the scenes. Because, sometimes you look at these and say, " Why did you choose that one, or why did you choose this one?" Those blog posts can go a little into more of the detail without cluttering up the recommendations. Hey, if I just want a recommendation, what should I use? Versus 10, 000, too long, didn't read, right? We just want to keep the actual reference architecture pieces to itself quite concise, but explain more of the rationale and thinking in those other ones. Again, I also want to really say if you've got a good reason to use something else, we're not trying to tell you not to use it. There's lots of very specific cases. This is really just, hey, from what we've seen, what we've done, this is a reasonable choice. So, there's plenty of other reasonable choices as well.

Joe Sepi: Yeah, no, that's a good point, too. It's from what we've seen and what we've done. I think that's a good segue too into talking about some of what we've seen and what we've done. What want to share any success stories that you're able to talk about?

Michael Dawson: Yeah, the first one, I think the Weather Company success story, that's the one I mentioned where basically it's a large Node. js deployment, lots and lots of Kubernetes clusters running across the world. It runs 24/ 7, serving weather. You may have used it yourself all over the world with APIs that you can use as well as finding out the weather. That's a great success story. I'm working on a few others. The cloud UI within the IBM Cloud is again another very large IBM... sorry, a very large Node. js application. I'm working with Jesse from IBM I to talk about the ... That is an ecosystem success story where 25% of the clients now use Node on the platform. The great thing about now being at Red Hat is I'm now starting to learn and learn some of the teams within Red Hat who also have some good Node deployments. So, I'm going to start working on finding those and being able to surface those success stories as well. So, that's the series. Currently, we have the one in the series, but I'm hoping we can turn that into a longer series over time as well.

Joe Sepi: Cool, cool. Yeah, you talked about having moved over to Red Hat and working on things over there. I know the new developer Node focus section on the Developer. RedHat. IBM. RedHat. com is being fleshed out as well.

Michael Dawson: Yeah, let me just quickly bring that up for a second, because that's something that we want to help show how prominent and show the focus that Red Hat and IBM have on Node.js. The IBM developer site already had a great landing page which had lots of good Node resources, and we're just trying to bring some of that good to the Red Hat developer site as well, of course with the lens of the Red Hat customers and people. So, you can go there. It gives you some of the, hey, why is Node important? Of course, a bunch of resources related to deploying on OpenShift. That's a great place to run your Node applications. I mentioned some of the large deployments we have are running in Kubernetes, so some good examples and resources getting started there, some general links for running some things in Katacodas, which are pretty cool. They let you run without having to have any of your own infrastructure. We talk, of course, talk about the reference architecture. We have a nice section on what's up in the community, talking about the releases, conferences that we're at. It's great to go and talk to people and end users and customers at these conferences. I'm missing that these days. Virtual conferences are good. You don't quite get the same feel, but that'll be nice when we get back there, a video series that Joe has appeared on. I run a short, five minute video series once every couple months just talking to different people working in the community so that if you're wondering what we're doing in the community, you can go and hear about what's going on in the build working group, the release working group, stuff like that. So, we have a good list of all the different people that we've talked to and then some events and stuff outside of that. So, this is a good starting point. Then, we continue actually to focus a fair amount on providing some great content around Node. js and some of the components. For example, Opossum is a circuit breaker, one of the most used ones out there. It's one of the first components, NPM components that we support in addition to Node at Red Hat. Some content there, I think for any node developer, there's probably a good series of things that are interesting to keep up with and know what's going on. So, that's definitely one of our focus, having moved on. Other ones include trying to work more or working more closely with the OpenShift community, understanding what it takes to run Node applications in that, to deploy Node. js applications. The Red Hat team has for a long time maintained NodeShift, which is a tool to help you very easily deploy it to NodeShift, to OpenShift. Just for me, it's personally great to be learning all the things that it makes available. The UI is really cool in terms of being able to do a lot of things that if you use the Kubernetes command line, there's tons of stuff you can do, but figuring out how to do it and what all the options are can be pretty overwhelming. The OpenShift UI actually can make a lot of that a lot easier in terms of, hey, I want to attach some storage. Oh, good, I have a UI to be able to do that. So, I'm finding interesting how much that can really help when you're trying to test things out and so forth.

Joe Sepi: Cool. Yeah, there's a lot there, a lot on the developer destination on the Red Hat site and NodeShift. That's got a lot there, too. We are running low on time. What else do we want to touch on before we start to wrap it up?

Michael Dawson: I think we want to make sure we don't forget about the events that are coming up, so OpenJS World. I know you've been really doing some great work on a quarterly Node event where you're working with NearForm. Maybe you can tell us a little bit about that.

Joe Sepi: Well, yeah, yeah. We are really excited to have figured out a way to partner with a NearForm on some events. It's a quarterly thing. We have a sponsor, as well as IBM does the platform, the conference platform side. NearForm does pretty much everything else. We had our first event a couple of weeks ago. It was really great, three or four talks, I think four talks in total, a workshop on the day of the event, and then a workshop the day after the event. It's really great, like I said, quarterly. So, the next one is going to be in June, so we've got a little bit of time there. But, that's a lot of fun, and I'm glad to partner with NearForm, really great company that does a lot great work in the community and for Node. js. Then, speaking of June, like you mentioned Michael, there's the OpenJS World event, which we're pretty excited about as well.

Michael Dawson: Yeah, that one I think will have a reasonable number of people participating and doing talks. I think that one, in my mind, there's two key events that you absolutely want to make as a Node developer. One is the OpenJS World, and the other one is usually the NodeConf EU. Then, the quarterly event is great. There's lots of other good events too, but those are my two go- tos. So, it's great that one's coming up again this year and looking forward to... We're trying to figure out how to make this interactive and get together with people, even though it is remote. It is remote this year, but I think it's still going to be a good time to be there.

Joe Sepi: Yeah, for sure, for sure. And, it does remind me of... Why am I blanking now? On the Collaborator Summit, which we usually do along both of those events, NodeConf and Node. js Interactive, now essentially OpenJS World, which I don't think we're going to do at this OpenJS World, the collaborator summit. The whole virtual thing is maybe too much to try and pile into one time.

Michael Dawson: I think the feedback was that it's not quite as good. Usually, we did it at the same time, because people were traveling. You were already there. You got the person, so it made sense to do it at the same time, because if you'd already traveled, you could stay around for another couple days. The flip side of virtual events seem to be though that if you've already spent three days or whatever it is at the main event, spending another couple days is a challenge, because you haven't traveled there. It's a lot harder for people to separate themselves and dedicate it. For that reason, the discussion we had is let's wait until a little bit later in the year. Maybe there's some chance we can do an in- person Collaborator Summit, which everybody would prefer. Yeah, exactly, we'll see. But, if not, we'll think about a virtual one, and having it a different time is actually better. So, that's the way I understand the discussion, and it makes total sense to maybe hold off until September to see what we might be able to do.

Joe Sepi: Yeah, I agree, I agree. Again, if folks are interested in this sort of thing, we're working on it in the open. If you have any thoughts about any sort of Collaborator Summit ideas, definitely reach out to us or get involved in the repo. But, yeah, there may be smaller events that are focused on different areas that we might want to focus on and do it that way while we're still running things mostly virtually. But, hopefully, like you said, we can get together in person at some point, and that would be grand.

Michael Dawson: Yeah, absolutely.

Joe Sepi: Yeah. Cool, great. I think we really got through a lot of stuff there. I'm excited that you were able to come and hang out with us, Michael.

Michael Dawson: Yeah, thanks for having me. It's always a great chat between when we get together, and I hope people found that interesting. As Joe said, everything's open, so if you want more information, you can check it out. And, you can hopefully come and get involved, because it's really quite fun.

Joe Sepi: Yeah, yeah, and feel free to reach out. We're on Twitter if you want to get involved. Also, OpenJSF. org/ collaborate will give you links to a lot of places that we've mentioned, calendars. The Slack inviter is there, more information about different ways to collaborate. So, definitely we'd love to have everybody involved and work on this stuff. You got anything to close, Luke?

Luke Schantz: Well, I just wanted to reiterate thanking Michael for his time, really appreciate it. Thank you so much for going through all of this. I found it fascinating, and I think Joe made it easy for me, because you and him work together so much. He did most of the talking, but I'm all right with that. I could use a slow Monday. But, again, yeah, thank you so much. If that's it, I think we'll see you later.

Joe Sepi: Call it a wrap. Yeah.

Luke Schantz: Next time.

Michael Dawson: Bye.

Luke Schantz: Yeah. Bye.

Michael Dawson: Thanks, everybody.

Joe Sepi: Cheers.

Michael Dawson: Bye, everybody. Bye.