Node.js and Open Source Community Updates | James Snell

Luke: In this episode of In The Open, we bring you a conversation with James Snell. We will be discussing a variety of topics including Node. js, NodeConf Remote, LF Public Health, and COVID Green. We will also discuss James's career path through IBM, NearForm, and now CloudFare. Before we welcome our guest, let's say hello to my co- host, Joe Sepi.

Joe Sepi: Hey Luke. How are you, my friend? How's the weather over there?

Luke: I am doing well, Joe. The weather here is fine. Not too hot, definitely not cold.

Joe Sepi: Is there a tornado warning or something? I was reading about this last night. Are you worried at all? You're close to the water?

Luke: That's a good question. I did see that there was some rain in the forecast. I did not see a tornado warning, but I did see this, this was quite alarming. In Greenland, on top of the ice sheets I guess, two miles up for the first time ever since they've been a National Science Foundation station there, they've had rainfall. So normally, it never rains there. They said in itself is not a big disaster, but it's obviously not a great sign of things to come.

Joe Sepi: Yeah. Oh boy. Yeah, the weather is decent here. That's nice, get a little bit of sunshine.

Luke: Let's find out how the weather is on the West Coast and ask our guest, James Snell. Let's bring him in.

James Snell: Hey, how's it going?

Joe Sepi: Good, how are you, James? How's the weather over there?

James Snell: It is hot and smoke. We're getting all the smoke from the Dixie fire and some of the other fires just coming right down here. And I think yesterday it was about, yeah, little over a hundred degrees. So, nice and warm.

Joe Sepi: Yeah, you're in the middle of California, right?

James Snell: Yep, smack in the middle, just outside of Fresno.

Joe Sepi: Yeah, yeah. Good luck out there. I think you were saying before, you don't trust air you can't chew or something? What was it?

James Snell: Yeah, yeah. Out here you definitely can't trust air you can't taste and chew. And every summer out here, it's been the same thing, just the smoke hanging in the air.

Joe Sepi: Yeah, that's tough. We got a little taste of it out here on the East Coast. I think it was from Canadian wildfires, but we've been getting public air alerts and stuff.

James Snell: It'd definitely be good to get some of that rain here. If you could send it out our way, it'd be fantastic, it would be inaudible-

Joe Sepi: Yeah, we'll see what we can do. Cool, yeah. Thanks for joining us, James. Happy to have you here. I thought we've known each other for a while. I joined IBM on the StrongLoop team, and I remember the first time that I came across your name was when I was joining the StrongLoop team, reading a thread on GitHub, a very long thread that kept me up late at night trying to really understand what was going on. And you were very patient and really navigated the situation pretty well. But maybe we could talk about your career path and where you started and where you've been. I know you were at IBM and some other places. Let's get into that.

James Snell: Hi, yeah, yeah. I was at IBM for 16 years, so it was long run. Started there March, 2001. So yeah, going way back, got all kinds of things there. Started in the emerging technologies group and was working on all of the SOAP and the WS- star, WS- Security star, everybody. But I did work on that, contributed to that mess. Switched over to working over in the CIO's group for a while, helped get blogs and wikis and all that kind of stuff launched within IBM. One of the really fun things we did there, it took about a week, we did the first draft of the social media guidelines, kind of that policy, right?

Joe Sepi: Yeah.

James Snell: Another guy that was there, Dave Berger, I think he's over at Wells Fargo now, but he and I put this idea together and it's like, " Let's not draft it ourselves. Let's have the company draft it, let's open it up." It was the first time that IBM Legal let a policy document be drafted by the employees, and we did it in a week and got those published and we became one of the very first examples of a corporate social media policy and guideline. We published it publicly. It was amazing, but it was only about a week's worth of work.

Joe Sepi: Wow.

James Snell: So, did that for a while. Yeah.

Joe Sepi: Yeah, that's interesting. I've read that documentation and it's interesting to think that you were there at the beginning. One of the things I love about being at IBM is I've been here for five years and I still feel like a baby. That's just such a short time for most IBMers, so it's funny to hear 16 years from you. I didn't know it was that long, it's great.

James Snell: Yeah, it was a good run, yeah.

Joe Sepi: And so what were you doing beforehand

James Snell: Before IBM, so I was with this tiny little custom app developer, system integrator in central California, had eight employees, but all of our customers were large enterprises. And there was this one in particular that was working on working, for a large multinational manufacturer, and they had basically outsourced their intranet to us to manage and develop, inaudible and things were significantly less complicated back then. We're talking 20 plus years ago, they had outsourced the test run and yeah, was writing up an asset document management system for them. This was 1999. And the thing I really like about this is it was right about when the XML HCC request was introduced as this new experimental thing in Explorer, and Microsoft had put it out there and they were telling everybody, " Don't use this in production." So the first thing we did, of course was use it in production. And this for me, I love it because it was actually one of the very first examples of an AJAX style application where we were using this to request data in the back end, separating it from the rendering of the rendering and the visualization. But that was in 1999 and AJAX... Well, the term wasn't coined, I think until probably about four or five years later, but no, it was a lot of fun. But that was what I was doing before and that's actually what led me directly to IBM.

Joe Sepi: That's cool. I can imagine, my first thought goes to, okay, so IE had it, did Netscape have it yet? Did you have to write some conditionals? And the old days of having to write something for two browsers, yeah.

James Snell: No, unfortunately they had a company standard, everybody had to be on IE. So, didn't have to worry about that.

Joe Sepi: That's good. Yeah, my thought was to talk through your career trajectory, but I wonder actually if talking about Node, Node. js if that would be, take us through that career trajectory regardless. So, maybe we'll talk about that. And one of the things that comes to mind, I was mentioning that thread and just I think Node's history is fairly well known, but to just touch on it briefly, the fork of io. js and the community really getting behind that, and I imagine a lot of companies being concerned about that sort of situation. I know that we, IBM, were focused on trying to help there. What was your experience? I imagine that was an interesting time?

James Snell: Yeah, and this is in 2014, IBM was really looking to start getting involved with investing in Node platform, but because of all these community issues and stuff that were ... all the drama that was happening, it wasn't a safe investment. And there was a lot of conversations that were happening behind the scenes, where IBM was trying to guide the project in the direction of, " Hey, a foundation is actually a good place for this. It'll help deal with all of these ownership issues and these kinds of things." But it was difficult while the conversations were happening, but the community decided to go ahead and fork in the middle of it and just threw a monkey wrench in all the conversations.

Joe Sepi: So, let me just get that correct. So, there was a conversation about the foundation first and then the fork, inaudible.

James Snell: That's right, it was in parallel. It was in parallel. While the community frustration was building, IBM was over here having conversations with Joyent and stuff and say, " Hey, this might be a better path to go." When it was clear that the fork was going to be a thing, my management at the time had remembered that back in 2013, I opened a poll request on Node. And that experience wasn't a great experience, that's a whole nother story, but it was like this, " Hey, James, you did something with Node once, right?" I'm like, " Yeah." " Okay, we have a job for you." And the job was essentially to become the technical lead for everything IBM was doing with Node. And the first task was essentially go to Node, go to io. js and figure out how to bring them back together, essentially fix it. And so, for majority of 2015, was me getting involved in the project and getting myself visible and known, actively contributing so that I could help guide the project through that process. And part of that was having weekly meetings with the folks at Joyent, to make sure their concerns were being addressed. Part of that was helping draft the governance documents and the first versions of the governance documents for the foundation, figuring out the path for, okay, we had these two different code bases now. How are we going to move forward with those? Ultimately ended up being that the io. js fork is what we actually took off with and what node is today is actually from io. js itself, or from that fork branch. Well, a lot of 2015 was just that. And then once we got that launched, it became, let's work on the processes that caused the problems in the first place. And this attitude of, " Oh, Node is done, it doesn't need anything new." Anytime a new contributor would come to the project, it was automatic. " No, that a API is locked. Node is done." I was actually yelled at by one of the core contributors at the time, actually physically, in person yelled at because I was daring... make changes to some stuff. And it was just, I don't think people realized that's the kind of unfriendly attitude that caused the fork in the first place, and we needed to break that culture. So, I very intentionally started this process of giving very liberal code reviews. I would look at it and I'm like, " Yep, good idea. Let's do it. Oh, I guess I better go look at the code to see if there's bugs." It was this saying yes first, and eventually we got there. I think the project has evolved into a much, much better state today.

Joe Sepi: Yeah, I agree. And we still have our challenges, of course, more community driven and people can get involved. And one of the things that I like about the approach that has developed over the years is this real open source methodology, whatever you want to call it, approach. And so, sometimes I'll be looking around through GitHub and trying to find something, whatever the case may be, and I'll stumble across an issue with Michael Rogers or somebody talking about the TOC and the way back in the day, and should we do this? I found the issue about whether we should be in the foundation, create a foundation or not. It's great to read through that stuff and it's still all right there for everybody to dig into. It's really interesting.

James Snell: Yeah, anyone that is looking to create a community around a large open source project really should go back and read that history of what Node went through and what we did. And there are painful parts, there are parts of it that were very painful and very hard to go through, but it really, I think, serves as a great case study for how do we work ourselves out of this community drama? Nobody trusting each other, everybody's just a fighting, to we have something that is growing actively. The contributors are happy, the community is engaged, and we're making progress.

Luke: I think it's really important to talk through that because I think a lot of folks... or we all want to avoid pain and avoid conflict, but I love that we get to unpack that on this show and talk about how the proverbial sausage was made.

James Snell: Going back to thinking of the thread you mentioned at the beginning. Yeah, so this is just an example. We're not going to go into all the details and stuff on it, but Express. Express has had an interesting history. It's still super popular. It's a fantastic package. Among all the contributors that have kept it going, kept it alive, done a fantastic job, but Doug Wilson really does deserve a huge amount of credit for keeping that thing going. Well, when IBM bought StrongLoop, there was this question of what's going to happen with Express? IBM's interest wasn't to own Express, and it just got caught up in the acquisition and stuff like that. And there was never a decision at IBM, it's like, " Hey, what are we going to do with this?" But Doug and others were like, " Hey, do you mind if we just take this over? And it ended up being a very difficult conversation because the future of Express really was up in the air and there was some politics between multiple different companies and all this kind of stuff that's not worth going into, but it was painful. There were times we were jumping on the phone and having these conversations that were just really hard to get through. But in the end, it got out there to the community, it's a community project, it belonged with the community, and we got the right results. It's out there.

Joe Sepi: Yeah, and I remember particularly reading through that thread and you really did a good job at remaining level- headed and calm and trying to project that outward. But the community, and I think society in general, really wants something right away. They just want to... this needs to be solved and it has to be done yesterday. And I've worked at IBM and other big companies and stuff takes time. Just to even get a meeting to talk to somebody and may take a week or more. And I just remember you keep saying, " Give me two weeks and I'll respond back to tell you what... but our goal is to get this in the community. Please be patient." And five minutes later, " What's going on with this? How come... " So, balancing the community and the corporate is a challenge, but I'm glad it worked out and did end up in the community and things did work out as you were asking them to be patient for it to happen.

James Snell: Yeah, I think a lot of people forget that it's like, yes, you have the big corporation, but we're still just people. And the corporation, yes legally it can be counted as an entity, it's a person, but it doesn't have an intent. It goes down to the individual people. You're working with the individual people. Now, there may be a culture and stuff you're dealing with, but in this case it wasn't IBM against the community, right?

Joe Sepi: Yeah.

James Snell: It was, no, we're just... IBM was still trying to figure out what it had bought at StrongLoop and figure out how to assimilate this and what everyone was going to be doing. Literally, nobody had thought about Express until I raised it and was like, " Oh, wait a second. What's going on here?" And we had to have a couple conversations where we were educating the executives on, " Oh no, there's a whole issue here brewing." And as soon as they found out there was an issue, they're like, " Okay, do it. Go take care of it."

Luke: That's so interesting. I love stories like this too, because from the outside and the general impression we get of big companies, is that they are very impersonal and you get lost in them and don't have an identity. But actually, because there's so much specialization and leadership can't really know about all these things, there's actually a lot of opportunity through open source and through these issues that you're mentioning, to really differentiate yourself and be a thought leader.

James Snell: Yeah, yeah, and that's exactly it. And people need to realize that for the most part, companies don't have interest in trying to own parts of the community. They want to influence it. And you'll have some that go in there and say, " Okay, this is our thing. We own this." Whatever else, but it's not necessarily in their best interest. For me, it's a very important view of open source. If a company goes in saying, " We own... this is our thing, we're going to make decisions that are only our benefit," then whatever the thing is, it's just going to die because no one else is going to care. But if they approach it from the point of we want to do what's good for the community, and if the stuff that they are doing actually is for the good of the community and they're putting their commercial interest second to that, then it seems cliche, but the whole rising tide raising all ships, that's true. That actually does happen, especially with open source. So, make decisions that are good for the community before good for your company and it'll come back around to you.

Joe Sepi: Yeah, absolutely. Couldn't agree more. Cool. So, maybe that's the beginning of your work in Node. What does it look like beyond that? What are some of the highlights of stuff you've been doing there?

James Snell: Yeah, so my work at IBM on Node led me to NearForm, which is this unexpected company out in Ireland. They're headquartered in some tiny little town on the Southern Irish coast, you would not expect whatsoever. Absolutely fantastic company. They're primarily a services company, so they go out and they do a bunch of custom applications in support of those kind of things for a lot of customers, think last count, like 24 different countries and 180 people. And so it's inaudible... they basically wanted me to do is take me to work on Node. They really embraced this attitude of, " We are getting a lot of benefit from open source, so we need to invest in supporting it and driving it forward." So, that was basically my job there, was just to contribute to Node and do some consulting work in that. What that allowed me to do is it freed me up to work on a lot of the stuff that we've seen in Node. So, you have the URL parser and the HP2 implementation and web crypto. More recently, the web WG Streams implementation. A lot of these larger things have been added to Node in the past couple years are largely because for the longest time, I think I was probably one of the only core contributors that was paid to work on Node full- time. It wasn't like a secondary thing or part- time thing. That was my primary responsibility. So, it really freed me up to do all kinds of work on that platform. So, my fingerprints are all over stuff. I like to instigate things. So, I'll write the initial implementation and really encourage other folks to come in and take off with it. Tongue in cheek, I'll say, " I'll add the bugs and then encourage other people to come fix them."

Joe Sepi: That's a great approach though. That's an easy way for people to get involved. Here, I'll get us started and you take it from here. Yeah.

James Snell: Yeah, so we've got a lot of changed things in there. Now here recently, I started conversations with CloudFlare. There's an opportunity to go help evolve the CloudFlare workers platform and not only evolve the platform itself, but evolve its connection with the ecosystem, the ecosystem of NPM modules and Node and Deno and how it relates to all of those things. So, I decided to go ahead and switch over and there's some exciting stuff. I can't talk about it yet, what we're doing, but there's going to be some fun stuff coming.

Joe Sepi: Very cool. Yeah, I'm excited, I'm eager to hear more about it. This is random, but what's your take on Wasm and is that into the work you're doing?

James Snell: Oh yeah, it's directly linked with a lot of the work I'm doing. I do like Wasm, I think it holds a lot of promise. Some people are like, " Okay, this is the answer to... " whatever problem. And I think it is over- hyped to a degree, but I think it is an extremely useful tool. The WASI interface, the basically WebAssembly System Interface, that is providing that lower level syscall type functionality, holds a lot of promise, but needs to... has a ways to go before it's there. It's missing quite a few things that someone would need, but it's there. It's coming along and it's going to be exciting to see what people do with it.

Joe Sepi: Yeah, we'll see how that goes. I feel like there are a few technologies out there that are still... There's a lot of hype and I think there's potential, we just got to get there. Cool, Luke, do you want to take a moment and promote the stuff?

Luke: So first off, I want to say thank you for everyone who's tuning in live. If you have any questions for James, please drop them in the chat on whatever platform you're listening on and we'll get to them later in the show. If you happen to be catching this as a replay on a podcast, in the show notes, we'll have all of our Twitter handles. Feel free to drop any questions you have to us asynchronously on social media and we can answer any questions you have later. And now, this show In the Open with Luke and Joe, you can always find it on ibm. biz/ intheopen. We'll always embed the latest episode at the top so you can watch it there, or you catch it on your streaming platform of choice. We will also publish it later as a podcast. So you can catch it on Spotify, Stitcher, Google Play, a bunch of places. And besides this show, we have a variety of podcasts on IBM Developer. We just launched Z Platform Talks. We have Z DevOps talks. We're about to launch a data and AI podcast again. So, we've got a bunch of stuff going on that's really exciting. Subscribe on your listening platform of choice. You can always find it here too, at developer. ibm. com/ podcasts. And then developer. ibm.com, you can find a whole variety of media. So, I work with a bunch of great writers and editors and folks making videos. So, we've got a bunch of learning paths and code patterns and all kinds of things on IBM Developer. So, please check out what we have there.

Joe Sepi: Smash the like and subscribe button wherever you see it. This maybe is a good time too, just to touch on your podcast, James?

James Snell: Yep, yep. Yeah, OpenHive. js, we launched this at NearForm last year. Matteo Collina and I co- host it. We are on a slight pause right now while we retool the format a little bit. All right, and especially now that I've moved over to CloudFlare, I'm no longer at NearForm, so we're going to make some changes to the format and how we go. But it's been fantastic. We've been having some really great conversations with a number of guests from around the JavaScript ecosystem and just keeping it informal. Just chat, see what's on their minds and go from there. It's been a lot of fun.

Joe Sepi: Yeah, it's a really good podcast. I recommend folks to check that out as well. Let me see, there's a comment in here. Since we just talked about this, I'll throw this up here and see if you have any thoughts on this. Oh, it's Brian. Okay, but still...

James Snell: Yep. I'll say yes. I can see a feature for this. The WASI system interface has to evolve a bit more. There's a lot of stuff it just doesn't do and a lot of stuff it doesn't do efficiently enough. You get a lot of performance loss, depending on what you're doing. An example of one of the things that's missing right now, are the ability to open a TCP connection or UDP connections. So, you have the net subsystem in Node core, we wouldn't be able to implement it as is on top of WebAssembly and WASI, simply because those system calls don't exist yet in the WASI definition. Now there's an open poll request, if you go to the WASI, get every inaudible, but it's been open for a while. It's not clear when it's going to land, what changes are going to be. I've thought about implementing it for Node, but it's going to be a moving target. So eventually, yes, we might get there. Would I like to see it? I think there's a lot of good possibility there. It would help us out in Workers, CloudFlare Workers, which we don't have these system APIs. If we could just drop in a WebAssembly module and here's a Node net module, that'd be fantastic. It would really improve interop, for sure. But I think we're a long ways away.

Joe Sepi: Interesting. Thanks for the question. Yeah, hello Brian. So, I would love to hear more about the Linux Foundation Public Health Foundation Initiative. What's been going on there and what's your involvement?

James Snell: Yeah, so Linux Foundation Public Health is a kind of sub- organization under Linux Foundation. It was organized as a home for open source, public health- related projects. And it was launched specifically because of COVID-19. We had a number of products, that you have COVID Green, which is the open source project that NearForm created for doing digital contact tracing, exposure notifications. You have some projects out there that are trying to build a digital vaccine certificate, where you get a QR code on your phone, you scan it and it's proof whether or not you've been vaccinated or not, that kind of thing. So there's a lot of these open source projects out there and they really didn't have much of a home. There wasn't a place for them to go, where they weren't just tied to just a single company's commercial strategy and that kind of thing. What we wanted was a place where, no, here's a neutral home. Here's where these things could exist, not just on a national level, but on a global level, where these products could grow and evolve, have a safe place to. And so, the Linux Foundation Public Health was launched. Now, my involvement was specifically because at NearForm, COVID Green become one of the founding projects for this. And so, it was donated there. And I joined what's called the Technical Advisory Committee. They basically provide a liaison role between the projects and the board, and the foundation board. The TAC is responsible for deciding which projects come in, what the process is, what those projects have to do in order to maintain their status as a LFPH project, that kind of thing. And to provide some kind of mentorship and guidance to the projects. Because some of these are coming from companies that have no experience with open source at all. We're dealing with public health agencies that have no concept of where the technologies are at or where they're going. So, it provides that liaison role there. I was elected as the chair of the TAC, the Technical Advisor Committee for this year, and will be serving until the end of my term in December.

Joe Sepi: So, obviously there's been a lot of work done there already, but this is still ongoing. What's in the near future for the work that's going on there?

James Snell: So, all of the work so far has been geared towards addressing the acute crisis of COVID-19. If you look at the exposure notification, these are the apps that you can install on your phone. And if you're within 15 feet or 20 feet of another user that also has that app, the phones exchange keys, you go off on your way. It doesn't exchange any other information, it's just this random key that's exchanged. And then later on, if I test positive, I can hit a button in there and it lets everyone else know that my phone came in contact with within the past two weeks, it'll let them know that they may have been exposed. It doesn't tell them who, it doesn't tell them where, but they don't get any of the information. It just says, " Okay, you may have had exposure, you might want to go get a test." That's been the whole exposure notification thing. And that's where we've been putting the majority of our focus of that and the infrastructure around the digital vaccine certifications. So far, that's everything that LFPH has been working on, and it's all designed toward how do we manage the current crisis and try to get a handle in things as they are right now? But the LFPH'S broader mission is not just COVID-19, it's providing a home for open source that affects the whole range of public health issues in support of public health authorities, these agencies worldwide. So, there's challenges with data sharing, particularly here in the US, where every state has its own health authority. You might have county or city level health authorities. And what it turns out is very little information is shared between all these different authorities. I think we've all had the experience, I'm not sure internationally, how internationally true it is. But here in the US, you fill out a form online to make an appointment. You go to the office and you have to provide all the exact same information on form. And then maybe when you go pick up your medications, you have to fill out the information again. Every provider, you have to fill in. It's because they're not sharing information around the systems don't exist. It's not that they're just not doing it. It's the actual infrastructure for sharing that information does not exist and it still needs to be built. And ideally, that'd be built in an open source way, where this information can flow. But also ideally, there has to be privacy protections there. The security has to be there. And it's really hard to ensure those things if you're not doing it in an open source, a transparent way. So, that's really what the LINUX Foundation wants to do with the LFPH, but we have a ways to get there. We have to get past this current acute crisis before we can really start building up the rest of that.

Luke: That's so interesting. And what comes to mind when you say this, it's like before open source, science was already having this idea of publishing white papers and presenting. And so, it's like they have the foundation of how open source works, like a similar pattern, and then... but they don't necessarily have the mechanics to apply it or the knowledge of the technology. So, it's interesting how it's like this layer as an evolution and how we're maybe even giving back to the fore... I want to say it's like standing on the shoulder of giants type thing, but we're able to pull them up.

James Snell: Well, it really goes back also to just pure politics. So, public health agencies, they are government organizations. They are subject to the whims of budget proposals. And when your budgets are being drafted by elected officials, you have this winds of change thing that happened. So right now, because of COVID, public health agencies, they're getting a ton of cash, " Go take care of this, go fix this." But as soon as that's no longer the issue, as soon as that's not the acute crisis of the day, that funding is going to disappear and all that focus and attention is going to go away. So, how can we maintain a healthy, robust, evolving technology strategy if we have no idea if we're going to even have any budget at all to do so next year, or two years from now? So, it makes it really challenging. The other part of that is public health agency, rightfully so, they're focused on health crises. They're not focused on, " Hey, should we use Kubernetes and Node or Go?" They don't care about that stuff. So, it's a lot of complexity. It's not that the ideas aren't out there, it's not that people don't know the right thing to do. It's that they may not have the money to do it or it may not be what they're focused on.

Luke: I have a suggestion. This is something else from the enterprise. I think we should have a mandatory education and badging system just like we have to... Oh, I've got to do my cybersecurity training again this year. I've got to do my anti- bullying and sexual harassment training. I've got to skill up. Maybe in order to be a public official, you should have to have some sort of mandatory technology training. You can't be calling the internet pipes.

Joe Sepi: Trucks on the pipes, yeah.

James Snell: That's a fun area, it'd be nice. Now, I will say that in this process, I have met quite a few folks who are working at public health authorities around the world. I have to say, that just over this past year, they have been doing absolutely amazing job of trying to keep the flow of information and balancing the technology out. Because they have companies coming at them say, " Hey, it's this technology." And they're doing a barrage of things. " This will solve everything." And they're like, " Wait, no, stop." And just in terms of the privacy protections. I know when a lot of these exposure notification apps were out there and people were immediately mistrusting us, " Oh no, the government's going to collect all the information." No, it's been the government that have been the strongest advocates of saying, " We don't want that information. We don't want this to collect anything. We're not going to use any of this private information. We only want the bits of information that help us deal with this COVID- 19 crisis. That's all we want." And they have been the ones that have been really hammering hard at maintaining this privacy protection. So, the health authorities just globally deserve a tremendous amount of credit and thanks from all of us on helping to manage this crisis.

Joe Sepi: Yes, thank you to them. One thing that has come to mind in this conversation is I wonder about, and this is maybe US versus EU and whatnot, but in terms of building out platforms to facilitate these sort of health systems, I think of the banking APIs that I think in EU are much more standardized and then you can do a lot more, whereas in the US it's not the case. How do you see that playing out in terms of standardizing platforms and thinking about this from a health perspective?

James Snell: Yeah, I mean, I'd say sadly, because I'm coming at it from a US perspective, sadly, it's exactly the same with public health infrastructure. Europe is much more open to collaborating across borders, to sharing information. Just, " Hey, let's build something that works." Now, I mean, there's some differences. So, the French build a slightly different version than the Germans and then... but at the same time, they're on the phone every week with each other, hashing it out. " This is why we made this decision and this is why we made this decision." And the focus then becomes on, " Great, we're going to do it differently, but we're still going to interop." And then the conversation becomes, " How do they interop?" Here in the US, we're still fighting, well, this state assembly made it illegal for us to even have this type of system. And it's just very, very frustrating here in the US just to break down the whole political culture that has been fostered over the past number of years, has really made it difficult for us to address the technology issues adequately.

Joe Sepi: Yeah, we've got big issues to solve. It would be great if we weren't fighting over stuff that's really not important, yeah, yeah. Anyway, good times.

James Snell: LFPH is definitely something to get involved with. If you are involved with... just call out to anybody, if this is an area that you're passionate about or if you want to find ways to contribute, even just small ways, to contribute to building this technology infrastructure to support public health. I definitely encourage folks to get involved there. There's a couple of fantastic projects. One in particular, project Herald, we just advanced it to stage three, which is... I won't go through all what the stages mean, but stage three is for our banner head projects. Those are the main ones, and Herald just got there. Herald is a digital contact tracing application, similar to COVID Green, except it is not based on the Google and Apple APIs that they host and maintain. They've built an entire architecture, it's independent of that. It's a fantastic project. Lots of opportunities to get involved. Folks are interested. Have them reach out to me on Twitter and I can get them connected.

Joe Sepi: And it is Herald, H- E- R- A- L- D?

James Snell: Yep. I'll get the link for the show notes.

Joe Sepi: Yeah, I've got something here, but I don't know if it's the shortest one, but I'll add this in here, the announcement.

James Snell: It originated from VMware, they've done a fantastic bit of work on it, they deserve a huge amount of credit on this.

Joe Sepi: Oh yeah, heraldprox. io. I'll drop that in there too for folks who want to check that out.

James Snell: Yeah, I would've had the link for you already, but it just popped in mind.

Joe Sepi: Cool, interesting. That's a great suggestion for folks who are interested in getting more involved. It reminds me, do you have any suggestions for folks who want to get involved in Node. js, for example?

James Snell: Yeah, Node. js, I mean, there's a thousand issues open. There's pull requests that need reviewed. The way I started and going back to 2015, when I was told, " Hey, go help fix io. js," I spent three months doing nothing but going through the issue tracker and finding open issues and we're like, " Okay, hey, what's going on with this?" There was one day in particular, I went through I think a thousand issues in one day.

Joe Sepi: Wow.

James Snell: And for some of the Node core contributors, that was their introduction to me, is getting spammed by GitHub notifications, like, " Who the hell is this James guy?" And it was just me going, " Hey, what's up with this? Has this been done?" Just going through and doing some triage. It's a fantastic way for people to get involved with their project, go through the issue tracker and just find the old issues and say, " Hey, what's up with this? Maybe I'm going to help get this finished." It's fantastic. And folks, always free. I'm always happy to talk to new contributors, so folks can hit me up on Twitter and ask how to get involved. I'm happy to point in the right direction.

Joe Sepi: Great, great. Yeah, thank you. I'm curious, on a similar topic, we have this initiative happening right now called the Next 10. The Next 10 years of Node. js. Or, I guess, are we 11 now yet? I'm not sure, close. And so, what does the next 10 years look like for Node. js? And that's something that people can get involved in if you go to the github. com/ node and look for the Next 10 repo. You can see when the meetings are and read the notes and the documentation that we're working through, it's an ongoing process. But I'm curious, what do you think, in terms of the next 10, what are some important things that you think that we should be working on in Node. js?

James Snell: Web platform alignment is a key one, and it's something I've been working on for the past couple of years now, and I think it needs to progress. There will always be new Node specific APIs added. There's always going to be a need to... okay, we're going to add this thing that's only available in Node. I would like us to minimize that going forward. If there is some piece of functionality that is not just specific to Node, but hey, maybe Deno also needs it. Maybe Browsers also need it, maybe CloudFlare Workers needs it. Maybe all these other JavaScript environments also do that type of thing. Then we should be looking at common APIs, standard APIs. Even if they're not entirely optimal for Node in every case, it still should be the priority and focus on for us to deliver these standard APIs that developers can use across all the environments. Web streams is a good example of this. Literally no one wanted yet another stream API in Node. Node streams is a horrible, complex beast. Nobody enjoys maintaining it. I think fewer enjoy using it, and it's been there, but we added web streams. Why? Because that's where developers are. That's what they're using and that's what they want. And it was this argument before it's, Node's not a browser, it shouldn't do all this stuff. I mean, I'm like, " No, that's wrong." There is an overlap. Node's not a browser, but it does some of the same things and where it does the same things, we should be following the standards. So next 10, my key goal is I want to see more emphasis on shared APIs, common approaches across all these different environments. I want to be able to go to Deno users and say, " Hey, you know what? It's going to work the same way in their environment." Deno has this module where they've basically emulated Node's API, surface area. Why? That should not be necessary. You write to a common set of APIs that just work in both environments. And that's really what I want to see.

Joe Sepi: That's interesting. I feel like over the last few years, it seems like Node folks have been more involved in ECMA's TC39 group, which standardizes the JavaScript language. And in fact, the last meeting I was at, I think I remember Ryan and Burt were there from Deno as well. Do you think, is that the place where we should be doing that work and things improving there?

James Snell: Some of it, yeah. Yeah, that's definitely part of it. But W3C, WoT WG, there's other places where those APIs are being developed. It might even be getting involved, contributing to the browser platforms, go to Blink and go to Chrome, go to Firefox and work on those features there. What ends up happening a lot of times is that... and it's just because of history, a lot of these new APIs that emerge come out of the browser and then get standardized and pushed out. Yes, I would like to see that come more out of the standards bodies and stuff being developed there, but right now, if the way to influence the direction of those APIs is to contribute to the browsers, let's do that. So, I think it's just a matter of getting involved where the work is happening.

Joe Sepi: No, that makes a lot of sense. That sometimes drives where things... the standards follow that, once things shake out in those implementations. Yeah, that makes sense. Cool, I know we're running out of time. One thing that I wanted to talk to you about, I know you have left NearForm and now are at CloudFlare, but you're still involved with NodeConf, NodeConf Remote, is that right?

James Snell: NodeConf Remote, NodeConf EU, yeah. So, the primary sponsor for NodeConf EU and NodeConf Remote has always been NearForm, but they don't consider it a company event. It's put on for the community. It's representative of the community. Our number one rule is no product pitches. We will not accept a talk even if it smells like a product pitch. And as I was looking at making this change to go to CloudFlare, I was thinking about it. It's like, " No, NodeConf, it's very important. It's very important to the community." There are very few Node specific conferences left, inaudible Node Summit going away and what was Node Interactive, becoming OpenJS World and having this broader focus, we really do need to maintain the community- focused Node events and NodeConf Remote, NodeConf EU is... that's what it is and that's what we're going to maintain it. So yeah, so I'm going to remain as one of the core organizers of that indefinitely, yeah. I can't say for sure. I can't say for sure. But 2022, we're looking at options for actually being able to do it in- person again. And we went to NodeConf Remote because of COVID, the next year we might actually be able to do it in- person and I'm hoping we'll be able to have an announcement about that.

Joe Sepi: Oh, that would be amazing. I would be so excited. Yeah, and I agree with you. I think the Node interactive evolving as the foundation has grown, taken shape that that is more of OpenJS World now and it's a wider array of... I think that's a positive thing. But I think that you're right, that really NodeConf EU is the only really Node- focused event, seemingly. So hopefully, that changes and other folks spin up their own events and those grow, and the community and whatnot. We'll see. But yeah, I really hope that we get to meet in- person again soon.

James Snell: Yeah, absolutely. The one other NodeConf out there that I know that they really want to get things going, so NodeConf Columbia, fantastic one. I really hope that they're able to make it back in- person. And I'll say that when I went down, oh geez, yeah, it was '99 that I went down, it was absolutely amazing down there, so highly recommend that one.

Joe Sepi: Yeah, really fantastic people that run that too. Actually, one of them, two of them, are my neighbors, Camillo and Catherine. We have one more question from Brian that we can throw up there. Let's see if we can tackle this one. What do you think about this, James? Do incompatibilities in module systems make it harder to have that goal of code that's runnable in multiple JS environments?

James Snell: I think Brian's inaudible. Yes, absolutely. Yes, without question, just the fact that the incompatibilities in the module system just find themselves are a major distraction. We end up having to deal with those before we can move on to the other things. And then now this stuff works differently and its different module systems. So, we constantly have to be going back to dealing with those inconsistencies rather than the stuff that's running on top. Just that fact alone makes it really hard. I have my problems with ESM, just from a technical... with my engineer geek hat on. I have a number of issues, but those, they're not relevant. It's where the standard is, we should just... I think people should just get away from CommonJS focus on ESM, focus on Web assembly, focus on the standards, move forward from there, and then start building good stuff.

Joe Sepi: Yeah, that's interesting. There has been a lot of conversation over the years about modules and the implementation. Do I understand you correctly in what you just said, that you are encouraging folks to use ESM? I ask this partly because I saw somebody recently say, " If you don't need those features, just stick with CommonJS," but you're of the mind to just... let's move forward, let's adopt it and make it better?

James Snell: Yep, yep. We need one. It goes back to the whole, the VHS versus Beta and I might be... Yeah, I'm dating myself here, all the young kids, and they're like, " What is he talking about?" But back then Beta was superior, but VHS won out. And we may be in that kind of situation here, even if we don't think it's as good, we have to pick one, standardize, and move forward.

Joe Sepi: I had a Betamax, it ended up on the trash eventually.

Luke: I read an interesting post the other day though, that while VHS won in that consumer market, it died out. And then Betamax still, it had this long life in professional production. It actually outlasted VHS, although it didn't rise as high. We'll sneak it in there.

Joe Sepi: Yeah, inaudible.

Luke: We'll sneak it inaudible. Well, this has been a great conversation, James. I really appreciate you coming to visit us and taking the time to share your experience and your story. So, thank you so much.

James Snell: Yeah, yeah. Thanks for having me, it's been a blast.

Joe Sepi: Yeah, thank you, James. We'll definitely see you out and about in the open source space, and good luck with everything at the new role. I'm excited to see how things play out there.

James Snell: Yeah, yeah, it's going to be fun. We're going to have some good stuff coming.

Joe Sepi: Yeah, I'll keep my ear out. Cool, I guess that's a wrap. Thanks everybody for listening and yeah, thanks again, James. And we'll talk more soon.