Episode 4 | Michael Dawson | Node.js Community updates

Luke Schantz: 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. ja 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 is, it started out really nice today. It was in the sixties, 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, huh?

Michael Dawson: Yep, 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's bringing to us today. Michael, what is this incredibly awesome breaking news you 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. jr 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 a buzz with all these amazing features that are coming out tomorrow.

Michael Dawson: Unfortunately, I sometimes get the question, why are releases so boring? And it's because we work really hard to make sure that our releases are as easy to consume for end users. And we have a major release, which is inaudible, 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. And so when we get to this major release, we do have some breaking change, but they're not really the interesting things. The most interesting things are some of our minor changes, which are new features, but the projects also really quite works hard to actually flow those back into the hands so you don't have to wait. Unlike some projects where 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. So a lot of changes that are coming out in 16, they were already available in 15 and in 14. And so we backport. 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.

Michael Dawson: Yeah, I know.

Joe Sepi: I think it's a really interesting point though 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. And the backporting that you mentioned is a lot of work that we do in the community, but still exciting.

Michael Dawson: Oh yeah, definitely exciting. It's a great time to talk about what's Node, what things have come, and 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. And 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 300-400 issues PR. So there's always lots of stuff going on and just sometimes when we come to these major releases, you look at it and say, " Oh, that's already in the people's hands." 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. There's the ones that we expect that always in our December majors, like a new upgrade to v8. And there's usually something on the diagnostic side and we have a longer term effort around bringing promise based APIs to Node, so there's something there as well. So I think we'll see a good number of different features, but we'll leave the details of what's specifically into 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 who have been involved. For example, Bethany's preparing the release. She's on the releasers team, different people on the team help with the release infrastructure and all that kind of stuff. But give to give a little bit of an insight of my perspective on some of that as well.

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

Michael Dawson: Sure. We have an LTS schedule and what happens is we have a current, which is December major every six months. And then every other current becomes an LTS release. So 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. And 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's 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 or two to be making sure that you're not on unmaintained line.

Michael Dawson: Exactly. And 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. And so do I want to move up to 14? Do I want to wait for that? You can 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 a nice and predictable. And we've been doing this, oh, I can't remember now, but I think it was back to 6, which would be two, three years ago. So it's been working pretty well and I think we hear people like that predictability. Although I'm still shouting to as any people as I can because sometimes it's, " When's the next release?" It's, " Oh, the next release is going to be either April or October and the next LTS is in October." Doesn't seem like we got the message out there to everybody quite yet.

Luke Schantz: Well now you have because everyone's listening to this.

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

Joe Sepi: And then with the breaking news so now we know we've got them all.

Michael Dawson: Maybe minus one or two people, right? The other billion, X billion will be there.

Luke Schantz: Well I think it is, it's actually when you're so involved with it, sometimes you can take these things for granted. And it is nice to have an opportunity on a platform like this to be able to unpack it and talk it through. And 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. And we have nightly built 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. And 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 found a pretty good balance between the two here in my opinion.

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

Michael Dawson: I think that really just, I don't remember it coming from any other 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 where we're at, where we have 10, 12 and 14, that's quite a few to support. And 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. And so that's why we didn't want to do an LTS every six months. So it just came out of that wanting to balance between, yeah, let's give something for people who really want something newer while 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: Node. js 10 would've come out three years ago around now because we have 30 months support. And so for first six months it's current and 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. Just 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, hey, what's coming. Now, I often get asked for, " Okay, where's the roadmap?" And 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. And what that means is there's no one company who's got an agenda and a schedule and a plan and 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 and you'll see things like adding promise APIs, improving our build infrastructure, and things like that. And Node 10 is not bad, 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, has had a great success, broad usage. And 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?" And part of that is we want to figure out technology wise, what is it that we have to do? What's important? And that turns out actually to be a pretty complex problem to figure that out. It's what is it that's going to be important. So we got to predict that. But when we started looking at it, actually we even had to step back another couple steps is 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." And I'm just going to give one second... I'm just 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: inaudible values.

Joe Sepi: 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 poll 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: Yep. No, the project's 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 sort of values of the project?" Now this isn't meant to be a here's what the values are, here's what 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 and 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 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. And then finally, up to date and technology and APIs are part of being been the success as well. Bringing in things like ES6, which is the new module system, making sure that Node's health stays up to date. And 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 a first thing we looked at, which was like, 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, that 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? And so who are our users so that we can understand what they need." And again, we had some good brainstorming sessions and 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's 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 and 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?" And I won't go through this whole list, but there's a good list there. And then we tried to map it against those different constituencies to say, " Okay, which do we think each of them need?" And the thing that we realize is the people who've 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. So we 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 and 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 Wasm 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, that's- Sorry, go ahead.

Michael Dawson: No, no, go ahead.

Joe Sepi: I was going to say it's really interesting and 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 tables mapping out how these things play out is really is you're doing a great job, the team. And 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 Eastern. Let's see, no sorry, 12 Eastern. And 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. And 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. And I find it really interesting to work through these things with the team and 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. Yeah, nodejs. org/ calendar, I go there regularly to see what's going on, what's 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 and there's another Zoom link, the meeting doc. We check the meeting notes into the repos. So, it's all there. Encourage folks to check it out and get involved, whether it's the next 10 initiative or other things like tooling or maybe this is actually a good segue in to talk about other initiatives that you're excited about, Michael. I know I've kept it-

Michael Dawson: Yeah, I got a couple.

Joe Sepi: In every meeting I'm in, I'm like, " Oh, Michael's here." So yeah, 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. So 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. Now there's some things around how do we keep packages that are important to continue to be maintained? How do we help maintainers do that more efficiently? And 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 let's just, let me show you that if you... So one of the things we started out by doing was looking at guidance that we could provide a package maintainer. 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? And 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. And 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. And 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 and then I need help right now because I'm in a panic." And 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 and it's, " 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." And I hope that someday this may become just as widely used to say the license information. Most modules or packages include a license information. There's lots of tooling which will go through and scan for that information and tell you are there any concerns in terms of the licenses of the package you're using? And 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. And when a version drops out of LTS, I'm no longer going to support it. So, it tells you a moving set of bounds of what will be supported. And there's a number of different ones. You could be like, I know some maintainers say, " I want to support every version of Node that was ever out there." Other people just want say, " I support the very latest." And so this is intended to communicate that so that the consumer can say, " Ah, 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? And again, it's a good way to communicate this is the level of support that you should expect and that's the expectation. And then finally backing is how is the project supported? Am I just doing this in my... Was this some 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 sort of three different things that the maintainer can communicate back to the consumers and hopefully the consumers can factor that in and we reduce some of that friction so that the expectations are good, then there inaudible friction. I also really hope that it's 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 OpenJS 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. And 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, it's 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. And 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. And 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 is 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, yep. Before we move on it. So 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 chip repo. And we're going to be talking to the maintainers in IBM and Red Hat to ask them to do that as well. Another really interesting thing the team's working on is called WIBY, it's Will I Break You. And 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 lets you... It's intended to let you run the modules that use tests to validate that you're not breaking them. And 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 is... 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 out 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 you 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. And 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. And 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. And 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's problems." And 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, 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. So support from the OpenJS Foundation to move these issues forward. And the first one came out of the package maintenance working group, which is to look at a security vulnerability chaining up and how do you break the chain where it no longer applies and then you save everybody a whole bunch of problems. So 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 and 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 learned 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 it's really, the collaboration spaces is really an interesting concept and I think the OpenJS Foundation provides a lot of value. Granted I'm a little biased as a chair of the CPC, 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. And so again, if anybody's 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 things on the list here that I might skip over unless you want to talk about Node API or the platforms.

Michael Dawson: I feel like our time's going pretty quickly. I always like to talk about Node API, but it's pretty specialized in terms of people writing native code. So, we can probably move on from that one to the next time. Platforms, I'll just mention, our involvement did start from the IBM side on bringing PNZ to Node and we still do a lot of work to keep the CIs going, make sure it's working on AIX and Linux on Z. But not only that, our team also helps with other platforms. And one of the ones that Ash helped in the last release is the Apple silicon. And 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 binar 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. 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. So, 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. And 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 and has to keep it running in production. And 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. And 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 and then the next group comes along and they may be inventing the wheel themselves. And 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. And 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. And so the reference architecture is about giving you those reasonable choices. And 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. And 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 and 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. And it's one massive Node. js application running across the world and 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. And so it's really great to get that different perspective. And 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. So IBM i is an ecosystem where it's been around a really long time, but at this point, 25% of the customers in that ecosystem use Node. js. And just 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 a work in progress. Quite often we'll be... Once we're done, there'll be something new and changing and stuff. 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 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 know we've used, so they're reasonable. And 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, 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. And 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's some challenges in that particular case." And so there could be... And then a small amount of guidance that goes 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's the link to the the part one where I introduced the concept. We have the first one on logging is 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. And 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?" And those blog posts can go into more of the detail without cluttering up the recommendations and be, " Hey, if I just want a recommendation, what should I use versus 10, 000 too long didn't read." 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. And again, and 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 it'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. And I think that's a good segue too into talking about some of what we've seen and what we've done. 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. Well, 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 and 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. And 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 that as 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 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. And yeah, you talked about having moved over to Red Hat and working on things over there. I know the new developer, a Node focus section on the developer at redhat. com. This 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 an 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 for 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've of course talked 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. We hope to... 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 it'll be nice when we get back there. 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 are 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. And 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. And 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 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 OpenShift. And 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. And 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. And we had our first event couple of weeks ago 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 of the day after the event. And it's really great. Like I said, quarterly, so the next one is going to be in June, so we 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 of great work in the community and for Node. js. And 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 we'll have a reasonable number of people participating and doing talks. And I think that one's 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. And then the quarterly event is great and 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 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. And 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 seemed 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. And because you haven't traveled there, it's a lot harder for people to separate themselves and dedicate it. So for that reason, the discussion we had is, " Let's wait till a little bit later in the year. Maybe there's some chance we can do an in- person Collaborator Summit, which everybody would prefer and 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 me to hold off until September to see what we might be able to do.

Joe Sepi: Yeah, I agree. I agree. And 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: Yep, 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 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: Yep. 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 thank you, Michael, for his time. Really appreciate it and 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. You did most of the talking, but I'm all right with that. I could use a slow Monday. But again, thank you so much. And if that's it, I think we'll see you later, next time.

Michael Dawson: All right. Yeah. Bye.

Luke Schantz: Bye.

Michael Dawson: Thanks everybody.

Joe Sepi: Cheers.

Michael Dawson: Bye everybody. Bye.