The Changelog: Software Development, Open Source - The Rise of io.js (Interview)

Episode Date: January 30, 2015

Mikeal Rogers joined the show to talk about io.js, a friendly fork of Node.js with an open governance model. We discussed why the io.js fork exists, why they choose open governance, the roadmap and future of io.js, supporting ES6, burnout while working in open source, and the steps you can take to get involved with the future of io.js and Node.js.

Welcome back, everyone. This is The Change Log. I'm your host, Adam Stachowiak. This is episode 139. Today, Jared and I have talked to Michael Rogers, one of the leads behind IOJS. IOJS is a recent fork of Node.js. A lot of good conversation here today about the community, open governance, why the IOJS fork exists, SEM version, how they're doing it, open governance.

A lot of cool conversation today with Michael. We got some awesome sponsors today for the show. CodeShip, TopTile, and DigitalOcean. We'll tell you a bit more about CodeShip and TopTile later in the show, but our friends at CodeShip, they want us to tell you about this awesome free plan they have. It includes 100 builds a month and 5

private projects. CodeShip is a hosted continuous deployment service that just works. You can easily set up continuous integration in just a few steps and automatically deploy all your code when your test pass the cool thing too about code ship is they just released a brand new design none of this look better but it also has a lot of great usable functions uh usability improvements

to make things even easier than they were before they got great support for lots of languages and test frameworks they integrate with github orbucket, and you can deploy to cloud services like Heroku, AWS, and the list goes on. Setup takes just three minutes. Find CodeShip at codeship.com slash the changelog. Also check out their blog too, blog.codeship.com to get updates. Use our special offer code, the changelogpodcast, to get 20% off any plane you choose for three months again that code is

the changelog podcast to get a 20 discount on any plane you choose for three months codeship.com slash the changelog and now on to the show all right everybody we're back we're talking with mich Rogers. He is – well, Michael, what are you? What exactly are you to IO.js? To IO.js. I think the best title for me would be janitor. Janitor, okay. That's the most apt, yeah. So it's me.

I generally go around and clean up the messes. There you go. So it's me. Jared's on the call. Jared, say hello. Hey, everybody. Oh, my god, Michael. And funny, I'm going to just say this, Michael, because that's the question I asked you prior to get on the call. Jared, say hello. Hey, everybody. And we got Michael. And it's funny.

I'm going to just say this, Michael, because that's the question I asked you prior to getting on the call, which was how to say your first name. And I'm sure you get that a lot. So everyone, his name is Michael. He just had hippie parents. Yeah, hippie parents invent spellings. Which is cool. And a little disclaimer here. DigitalOcean does sponsor the show.

Michael works there. He's not on the show because of DigitalOcean by any means. But they are sponsoring this show. It's just a fluke. It's just timing. It works out like that sometimes. But the call we want to have today is in the preamble of the call that wasn't in the audio that you're not going to listen to was us sort of rehashing the changelog's perspective on the node community our coverage of it we had aaron hammer on two black fridays ago talking about how node scaled and how their servers barely saw a blip on in terms of cpu and everything that was going on there we've had uh isaac sued on a show before

we've had talking about npm um we've had lots of conversations about it we haven't come back to the topic of io.js and what's happening there. So maybe the easiest way to open up the show would be to sort of introduce deeper than a janitor level kind of who you are, Michael. You obviously work at DigitalOcean, what their usages of it is, and sort of what your stake is here. We'll kind of begin there. Yeah, yeah. So, I mean, I've been a developer for a long time, been an open source developer for quite a long time, been a JavaScript developer for a long time.

I was at Mozilla and I was at CouchOne, the CouchDB company. And, you know, right when Node sort of became public and Ryan did his first talk, I got really into Node and went pretty deep. And, you know, back in the day, I worked a bit on Core and haven't really worked too much on code and core since, but mostly in, like, the HTTP client. And I wrote a library called Request that became quite popular and is now sort of, like, the default HTTP client

that people use on top of Node. And, oh, I run NodeConf and JSFest, some pretty big and really fun Node and JavaScript conferences. And at DigitalOcean, I'm a JS evangelist. So I go out and sort of give back to the JS community on behalf of DigitalOcean. And, you know, we love Node and JavaScript, and a lot of our customers are running it. We just shipped FreeBSD support, actually. And FreeBSD, for a variety of historical and technical reasons, is a great place to run Node or IOJS. So that's been really cool to see as well.

What makes FreeBSD specifically tailored for that environment? So if you've gone to a Node conference or if you've sort of sat through, um, any series of speakers about node, you'll hear about D trace, right? Like, um,

D trace is really big in the node community. Um, and you know, a lot of that is because of joint. Um, but also it's just a great tool for, for looking at what's going on. Uh,

turns out that not only Solaris, Solaris variants, uh, have D trace support, but also for BSD has pretty fantastic D-Trace support. To the extent that Voxer, who's one of the bigger Node users, they've actually moved everything over to FreeBSD. And one of the more prolific contributors to IOJ is Fyodor Indutny, who actually was the person who hit the damn fork button. He's responsible.

He's great, and he writes a ton of code. But he actually works at Voxer and is really dedicated to keeping FreeBSD support great. And is even a FreeBSD kernel contributor now and has done work to make DTrace better over there. Awesome. So let's talk about that fork button Node, huge project lots of corporate interest lots of hobbyist interest plenty of people making a living writing Node applications maybe take us a little bit through at whatever level you like to get into

on the recent history of the Node project Joyance involvement why the fork? Right, right. So Node simultaneously has become one of the biggest success stories and one of the biggest failures in open source. So about a year ago, myself and other people started to get increasingly concerned and organized around doing something about this. And the problem is that a year ago, we had the fastest growing open source ecosystem. Today, we have by far the largest public open source ecosystem.

There are over 100,000 modules on NPM. There will probably be around 200,000 by the end of the year. That's just phenomenal. It's crazy. So a ton of people are using it. A ton of people are bringing it into production. The usage and the ecosystem has grown tremendously. At the exact same time, actual people contributing to NodeCore

has gone down precipitously. And an even greater decline, we've seen the releases. So releases just don't happen anymore. We just don't ship any software. And we can argue forever about why that is, and we can argue forever about the quote-unquote best way to fix it. But the reality of the situation is that while there's a company that runs the project and sort of owns the project at this level, they're the only people that are enabled to fix it.

And so what myself and a bunch of other companies that were concerned and core contributors were consumed, we sort of got organized around asking Joyent, we want to take over the actual running of the project so that we can take on these issues and so that we can fix them. So we started a process. It was rocky and a bit up and down. And I think Isaac has probably talked a bit more about that publicly than I have.

Eventually, Joint got a new CEO, a guy named Scott Hammond. Scott got involved. He built out an advisory board. And Scott's a great guy. Everything that he has said that he would do, that he has taken on to himself to do as a task has totally happened and come through. But, you know, he has this really long involved process

where all these companies sort of get in a room and they try to figure out what to do to solve these problems. And the big problem, the thing that we're talking about, is that open source contributors in an open source community isn't participating in the project and isn't enabled to fix these problems. And having a room full of people from companies doesn't really fix that. And even if they say tomorrow, okay, here, the contributors run the project, we don't have the momentum and all the people behind that to actually get the project moving along. So what I did around the time that the advisory board was sort of spinning up is I started this project called Node Forward. The idea was that we would try to organize and galvanize the community around solving some of these higher level issues, some of them in core and some of them just around core.

And for a time we had, for a very short amount of time, we had a fork of node where we were just sort of merging stuff. And we didn't have plans at the time to even really do releases. We just wanted to see what we could do sort of code-wise and contributor-wise. I was informed quite quickly over the phone that that is a trademark violation and that I would be sued and da-da-da. And we talked about it with the other contributors and sort of in good faith because Scott was putting this good foot forward with the advisory board. We decided to make that private for an amount of time. And then we kind of kept pushing it out and pushing it out. And finally, Fyodor had just kind of had enough. He wanted to be putting his patches back into a public fork.

So he created one called IOJS, which doesn't infringe on the trademark. And even if it did, I mean he's Russian. Like you can't sue him for trademark. That's one way to do it, right? Or at least to get around the temporal issue. Yeah, yeah. So within a day, basically Fyodor just said, I'm landing my patches here now. And that was enough for all the other contributors and everybody to be like, well, I guess we're also landing our patches there.

And we just sort of moved all of the work and the effort over there and came up with a plan to ship a release. It seems sort of purposeful but accidental. What do you mean by that? Well, I mean purposeful in the fact that Node forward and then getting a phone call and then having to have alternate plans and then accidental that Fedora had pushed the fork button and wanted to start contributing back publicly, not back to original node and IO.js. And so that's sort of the purposeful yet accidental approach to this. Yeah, I mean we had done a lot of governance work already and we were having these regular sort of technical committee calls.

But they were all private and they were about this private fork and there's just a limited amount of things that you can do there. Right. And nobody was happy with it being private. But trademark law being what it was, like we just didn't want to mess with it. And I think it was actually like maybe Thanksgiving weekend or something. So a bunch of the people in the US just aren't even around when he decided to do it. So it was not the most opportune time to do it too. To do it on the radar, you know?

Right, right. I mean, it wasn't even the most opportune time to do it, you know, if we really wanted to message it as this big thing, but, um, we all got on board real quick and, and, you know, immediately we saw people get really excited about it. And, you know, like when the, when the Node Forward stuff sort of like leaked, although I don't know how something public can leak, but when people started talking about the Node Forward stuff, we made the mistake of, you know, not talking to press

and to people more honestly about it because we didn't want to, you know, make waves with the stuff going on with Joyent. But then Joyent actually did talk to all of those press. And so we didn't make that mistake again. You know, we talked about it really openly. We had really clear messaging so that people didn't get confused and there wasn't a lot of FUD.

And then, you know, if you look at, you know, all the Twitter stuff about IOJS, when all the information gets out there, you know, people were pretty much universally positive. So that was really good to see. It seems like it wasn't necessarily accidental. It's just that you guys were kind of maybe waiting for someone to take the lead and jump into that cold water. And then once somebody's in, it's easier for everybody else just to make the leap. Yeah, and I think it has to be somebody like Fyodor

or somebody who is contributing an equal amount. I mean, the reality is we don't have a fork or a node without Fyodor. So where he goes, it's like everybody else is very incentivized also. How many of the core team moved over? Everybody except the ones employed by Joyent. Okay. And just historically, did Joyent, I know Ryan Dahl started the project,

and did he work at Joyent when it was conceived and released? No, no. He was living off of savings in Germany actually when he wrote it in Cologne and then sort of ran out of savings and needed a job and was like, by the way, I wrote this note thing. And then he went to Joyent and worked there. And then after some amount of time working there, there was an agreement where he transferred the copyright

and the trademark and all the assets over to Join. Okay, so they own the trademark for Node.js, but the project itself, what was the open source license on it? MIT. And in addition to that, there was – for a while, there was a CLA that granted Joyent a license to your work that was essentially the equivalent of also sharing the ownership. But they removed that sometime I think in the summer of last year. So there's no CLA and there was no DCO and there's lots of very concerned people about that for a while. IOJS has always had, it's called the DCO, which is a developer certificate

of origin. Essentially some of the patent protection stuff and some of the concerns that people have about just taking contributions under license without anything else, they're solved by the DCO just as a public notice. It's not like a thing that you have to sign. And this is used by the Linux kernel project. It's used by the Git project. Every company that you would need to buy into this idea

has bought into this idea. It's kind of interesting. Just last week we had on Alex Polvey, who was the CEO of CoreOS, and they just did not fork Docker, but they just released a public implementation competitor in a certain sense to Docker. IOJS, this is your traditional fork, right? This is not a rewrite, this is not an alternate implementation.

This is literally code base taken, renamed, and just landing patches on the renamed version. Is that right? Well, I don't even think it's all that traditional as a fork because for it to be a fork, there has to be a competing linear line of development. So far, we haven't seen that. We basically have the future of Node happening over in IOJS. And while some patches are still going in that we're merging out of Node back into IOJS for 0.12, they haven't made any public plans past 0.12.

They haven't shipped 0.12, even though all the other contributors thought that they should have. I don't know what's going on over there. And a lot of the contributors that still feel obligated to do some work over there to get out O.12, they're also actively involved in IO.js and aren't really going to continue. I don't think they'll continue much past the O.12 release.

So it sounds like Joyent is stagnated because of perhaps lack of interest, and that's just going to remain on that side of the 0.12 release. So it sounds like Joyent is stagnated because of perhaps lack of interest, and that's just going to remain on that side of the fence who knows how long. I mean, I don't like to speculate. Like, you know, a lot of people have a lot of differing opinions about why it has sort of died on the vine. I mean, I don't know what Joyent Corporate's position is on it, like on it, like why they are or are not investing in it or why they have one opinion or another. I just know that the reason that the project lacks contributors is that there's not a clear way to contribute. And then even if you do contribute, it's this huge hill to climb to get any recognition for it. And then if you even get any recognition for it, there's no way that you can actually direct the future of the project or be involved in decision making because of this corporate dictator model.

How long has it been like that? Like it's – if this is why – has that been a problem for years or is this like something new that's crept up trying to release the next version um well no i think that a combination of things happened right so the first project leader was ryan doll ryan um was sort of done he just didn't really have any interest in in working on node anymore he has a bunch of other crazy projects i'm having dinner with him tonight actually i'll find out what his new thing is okay um but it went to Isaac Schluter, who was also a joined employee, but was also just the most obvious choice to start running the project. I mean, he had created NPM. He was a really active contributor. He built out the module system. And sort of a lot of the shift in priorities and

focus that the project needed to go through through basically from focusing on low-level details to enabling more of an ecosystem, it was just a natural choice. So even though Ryan made that decision somewhat unilaterally, or you could say Joyent made that decision somewhat unilaterally, if anybody were to complain about it in the community, they would have had to come up with somebody else. And nobody else really had the credibility at the time to do that um and just for the listeners sake too just to sort of play catch up here if you're going back and listening to past changelog shows to kind of keep up the pace with what we've talked about around node and and whatnot npm with isaac on the show that show with isaac isaac was still at joy and then and i remember andrew and i because this was prior to j Jared coming on as a co-host. He was on the team at the time, but

Andrew was the co-host with me then. Shout out to Andrew Thorpe, by the way. Awesome dude. On that show, we were talking too about how cool it was that Isaac was getting paid by Joint to hack on open source, NPM,

Node, all that good stuff. Just to sort of paint the picture for those going back and listening. Go ahead and continue, Michael. getting paid by joint to hack on open source, NPM node, all that good stuff. So just to sort of paint the picture for those going back and listening, but go ahead and continue Michael. Yeah. Yeah. So they, you know, they were employed by joint. I'm sure that joint and people at joint had opinions and, and it influenced the direction of the project. That's, that's entirely possible. I don't know that it didn't, and I don't know that it did.

But when TJ Fontaine's an amazing developer. He's done an amazing amount of work on Node. But just, you know, I don't think that some of the contributors felt like it was the most obvious choice, or that we should really continue with this dictator model. At that point, people really didn't feel like it was, it was the best choice. And even a lot of the decisions that Isaac had made, other contributors felt were really not the right decision and that we should have had like a real conversation about them. But, you know, we just weren't allowed to have that conversation.

Like it's, it's joint's project. There's a new dictator. It's TJ's project. TJ is going to go in whatever direction that he wants to go. And then for whatever reason, releases just kind of stopped. And also some really key developers and some developers that were contributing a lot sort of checked out and stopped contributing as much. And there weren't new people to replace them. So the project – so not only – I mean this is like a very hard position for TJ to be in, right?

Because not only is he taking over the project and I'm sure that there are people at joint telling him this or that or what to do. But also he lacks like people to even implement all of this stuff now. And like me and a bunch of other people are around going like take on this contribution model or take on that governance model. And yeah, it's an impossible situation. I don't think that any of this is TJ's fault. Like, you know, TJ's done, you know, as good of a job as I think anybody can in the situation. It's just a terrible situation.

And now a word from our sponsor. TopTile is the best place to work as a freelance software developer. If you're freelancing right now as a software developer and you're looking for a way to work with top clients on projects that are interesting, challenging, and using the technologies you want to use, TopTile might just be the place for you. Working as a freelance software developer with TopTile, your days of searching for high

quality long-term work and getting paid what you're worth will be over. Let's face it, you're an awesome developer and you deserve to be compensated like one. Joining TopTal means that you have the opportunity to travel the world as an elite freelancer. On top of that, TopTal can help provide the software, hardware, and support you need to work effectively no matter where you are. Head to toptal.com slash developers.

That's T-O-P-T-A-L dot com slash developers to learn more and tell them the change law sent you. Well, it sounds like you guys are taking steps with IOJS to avoid the dictator situation. The biggest step being this open governance model, which you guys proclaim right there on the homepage of IOJS. Can you tell us about that? Sure. I mean, the most important thing for the project is that at every layer of the project, literally every part of it, there is a way for you to contribute and a way for the community to contribute. And so, you know, it starts at if you're just a user and you want your voice to be heard in, you know, what your problems are and your concerns are and those to make it into the future of the project, there's a roadmap repo with some issues where you can just comment and give us your feedback.

And that will get rolled up into what eventually ends up being the future of the project. If you want to help us with the website, there's a website working group. It's great. Very easy to get involved. We're spinning up work around documentation, around translations. And then core, you know, the traditional sort of what we've, you know, forked and replaced from Node. There's a technical committee, which, you know, was spun up and started with the traditional committers that had come over from Node into the fork. Since then, two more people have been added to the technical committee.

Chris Dickinson and Colin, I think it's pronounced Erring. They're fantastic. We've also separated sort of the technical committee from the idea of contributorship or getting a commit bit. So what we want to do is we want to really bring in a lot of people that have a commit bit and a lot of people actively contributing to the project. And really the TC just focuses on really contentious problems and issues. And that's something that we, you know, move people into once they have some history with the project. And so the technical community uses this governance

model called consensus seeking. So it's not a pure consensus model. Like if something stays contentious long enough, we'll just take it to a vote and it'll go majority wins for the voting. This has, you know, consensus models get criticized a lot for incentivizing people saying no or incentivizing kind of stalwartism. Because if a peer consensus model i'm one person if i disagree with you i can literally just hold up the entire process right so they're they don't they have a bias towards not having any kind of change now the great thing about consensus seeking is that everyone is incentivized to try and convince their peers of their position and if you can't convince your peers of the position where you don't care enough, you just sort of feel like, okay, whatever, I'll go with whatever everybody else is doing.

So, you know, we have this great process where we essentially just say, hey, does anybody disagree? And if there's just silence, then we just move along. So we don't even really take things to vote very often. It's not like everybody has to say yay or nay. You know, it's literally just like, is it the direction? Nobody has any problem with that? Okay, we're moving along. And that's allowed the project to go incredibly fast, right? So like I said, we've added two new contributors to the project. We've also done, you know, four releases in a week. We, you know, got up an entire new build infrastructure.

We're also, you know, in, I think in the history of the Node project we never had more than 8 active committers we're onboarding that many new committers under the new policy I think like next week so that's pretty phenomenal so all the committers on the technical committee or is that a subset? yeah the technical committee is a subset um

how many people are on that and then how do you get on that well so that's that's really interesting so um anyone at any time on the tc can just say like hey i think this person should be on there and then it comes up in the next tc meeting and it falls under the regular kind of rules but we also have uh like people that we want to have participate in the TC meetings but don't necessarily need a vote or even want to vote. So for instance, I actually don't have a vote on the TC. I was facilitating the calls until Rod Veg stepped up and he's doing a great job. So really I'm just there sort of like informing them about some of the other working groups that are going on. We've invited Dominic DiNicola because he's very well connected to the V8 team and to TC39. And we really want to

up the amount of collaboration that we're doing with those groups. So it's great to have him involved in those calls. Also, Rod Veg, who's the new facilitator, he's built out the whole build system. He's doing the releases, but he's not actually a voting member of the TC. And if you look at the contributions that he actually does to core, he's doing the releases, but he's not actually a voting member of the TC. And, you know, if you look at the contributions that he actually does to core, there's not that many because he's working on NAN, which is like the binary interface,

which is a separate project. He's working on build, which is a separate project. So, you know, we've upped the collaboration and the TC, we really just want it to be, okay, here are the people that we all trust to make the right technical decisions at a low level in the project.

They don't have to be involved in everything. And we're breaking a lot of stuff off into working groups when we know that other people are going to be better at kind of fixing them and delegating all of that authority and that autonomy to those groups. Right. So, you know, the website group is allowed to make decisions without going to the TC. It's just its own working group. It has its own contributorship. It just rolls along.

And the same is true of Build. The members of the TC, though, they do have the final authority over the project, though, right? If it doesn't pass the TC, then whatever the concern is, whether it's voting a new member, something technical, policy change, whatever it might be, it's got to go through the TC to get – and then that subsequent meeting to sort of get approved. Is that the right method that you're all taking? Yes, for IOJS kind of core, I mean, I'm working on the working group policy right now. But as it stands, I think what will end up happening is that the working groups will have a lot of autonomy and be able to make decisions totally outside of the TC. That's sort of the point of the working group is to break off this responsibility out of the TC. But also I think that it's the wrong way to look at it saying that everything goes through them because that makes it seem like there's a funnel and all of the work kind

of has to be approved. When in reality, the work is just going on and most work that ends up happening and getting merged, you know, it goes through review process. It's not contentious ever. It just sings along. You know, we have releases without the entire TC buying off as well. Really, the TC only deals with issues of contention where, you know, we don't agree about something. So I'm assuming that the reason for this governance, was this based on anything prior to that? And the reason for implementing this was probably largely because of the stagnation that happened in Node original and then sort of the break off from there because that wasn't in place there. Is that why this is in place now? Not so much to provide more red tape or the opportunity for red tape, but just to provide some sort of model where the community in fact does guide this project yeah i mean so the the the origins of this go all the way

back to um last july uh i sort of built out a proposal that we hoped to get joined on board with um which obviously didn't happen uh and then when we ended up doing node forward we sort of like revive like revive that um and initially it was actually called the bootstrap voting model because the purpose of it is not to define all the governance rules forever. It's actually just to get us some governance rules so that we can iterate on the governance rules as we go along. So if something doesn't work, we can just change it. You know, none of this governance is sort of stagnant. A lot of the initial stuff that we put together, we did a lot of research and had a lot of conversations about what the best approach was.

A lot of it's worked out just really well, so we haven't felt the need to change it. In fact, mostly what we've done is we've documented it a lot more. We've described the process and the way in which the governance model is actually implemented a lot better. So we talked about having this TC governance model and making decisions, but we didn't talk about they happen on this TC call that happens every week, and how do you call or not call for a vote, and how do you move along in the agenda, and that kind of stuff.

So, I mean, man, it feels like you've broken free from the shackles of a dictator and you're now forming your brave new world. And you're – you've got to set up a government. It sure does, yeah. Very much – it harkens at least a little bit to me to the U.S. Constitution where they built in the ability to amend it if there's – because knowing that they didn't have everything figured out and things would change. It sounds like the bootstrap model is very much the, we're just going to get us enough so that we can get going and we're going to figure everything else out as we go. It's very software-y. Yeah, and it's worked better than any of us could have ever imagined.

When I said that I'm a janitor right now, I was not exaggerating. We have so many new contributors coming in and so much stuff happening that all I'm really trying to do is keep up with them and make sure that everybody is still enabled and it's clear where everybody can contribute. I think, you know, so for the listener's sake, listening to all this and trying to figure out we're probably like 25 minutes into the show ish somewhere around there and you know we've had conversations like this in the past around the node community and now io.js and what's happening here and i think the reason for this last 25 minutes was really to sort of paint a picture of what the history has been and what's gotten us to today uh prior to some sort of technical conversations, just to sort of get a snapshot of what's happened, why the governance, why the community had a change of heart, why the fork button was pushed,

and sort of why we're at where we're at. Trying to think the next direction here. I think maybe let's move on to some more highlights, I guess, for IOJS. I mean, one of the bigger highlights is bringing ES6 to the community. That was something that, you know, some members of the community seemed to want and some others could live without, you know, in terms all move december um what is in this latest version of version one which actually is unstable and you've got reasons why you say that what's what's in this latest version aside from just yet uh es6 and all the greatness that comes with that what's what's new and happening well so i will say that you know the the first release uh i talked about that roadmap repo earlier right um which is like a place where you can sort of voice what you think is wrong with Node or where you'd like to see it go.

So the top things that we saw in there were more releases, please. I would love to have releases. Right. ES6 was a huge one. And could you please move to Sendver and stop with this weird, even odd thing that nobody understands? So we did all of those. And it turns out that we actually get the S6 stuff basically for free just by taking a modern V8. So the V8 that ships in the last stable version of Node is so old that they don't fix critical bugs anymore.

Wow. And even the one that I – the last time I checked was planned for 0.12 is even behind where we are now. So one of the decisions that we actually made in the last TC meeting is to come up with a way to track with V8 really, really closely so that, you know, we have an unstable line that we're working on. And in there, we're taking the unstable version that V8 is working on for the next Chrome release. So when we find bugs, they're actively engaged in fixing those bugs and those performance regressions, and we can collaborate more closely together. And then once every six weeks, those are going to come into, those are going to land in a Chrome and they're going to be considered stable. And then, you know, we can say, okay, now we know that this V8 is stable. It's our stuff stable. Okay. Now here's the stable release.

So yeah, I mean, there's a bunch of ES6 features as dictated by V8. We're not going to go in and turn them off just because some people don't like them or whatever. We're going to take V8 as is. So that's a big win for a lot of people. I was going to say, are these ES6 features intrusive into existing code bases? Like if I don't want those features,

could they possibly mess up what I'm currently doing? It seems like they would be new APIs. Well, the thing about ECMAScript and JavaScript in general is that you can't break the web. So everything has to be somewhat reverse compatible. You can't break a bunch of existing code that's out there. So we don't really need to worry about that. You do have forward incompatibility though, right?

So if people are now building a bunch of modules and putting them in npm uh they use these new features um and they're not doing any kind of like you know compile down steps or anything like that um they're not going to work in node 012 and node 010 um so you know potentially as they add more features there may even be versions of iodate js that don't have those um but we've there's a lot of threads right now on the best way to handle that. Is it NPM tooling? Is it cross-compilation? All that goodness.

According to your guys' ES6 pages, it sounds like there's a few features that are still behind the flag, namely classes, object literal extensions, and symbol to string tag, which I'm not familiar with that one. But the majority of everything else, let, const, generators, just the whole kit and caboodle, besides those few subsets, are all in there. Why classes and object literal extensions didn't make the cut? I mean, the V8 team doesn't feel that they're stable.

Okay, so just completely whatever V8's shipping, you guys are shipping. Right, right, exactly. And I think that going forward, we're not actually going to see a lot of people publishing modules that rely on features behind flags. In the past, we actually did have a bunch of people, including T.J. Hollowaychuck, build a little ecosystem around generators,

which in Node 0.10 requires like a recompile, and in 0.11, 0.12 is still behind a flag, or at least in the existing 0.11 releases. I don't know what 0.12 will take when it goes out. So that's a huge barrier to entry for using those features, but people were clamoring for them so much, and it was just so unclear when the next version of Node would come out that people were really going the extra mile.

I think that now that we're shipping quickly and that releases are coming out on time and that we're taking new V8 features as fast as the V8 team is doing them, I really don't think that people are going to do more than play around and test stuff behind flags. So you guys were

excited to get this version 1.0 out there, but yet on your homepage it says that the choice to release this as 1.0 was not to signify that IOJS should be considered production ready, but because it was a significant enough release from Node.js to warrant a major version increment. Now, SemVer means 1.0 is production ready, right? And this is specifically not production ready, so help me out here.

Well, I mean, I think it's, in my opinion, as production-ready as any release of Python or Ruby. And that's really not a dig at them. It's just a node is incredibly stable. And in huge production use cases, I don't know of any scale, anything where Python or Ruby is at that scale. And the node that you've been using for a long time has been at 1.0 quality for at least a full major release cycle. I think that the reason why we state really strongly that it is considered unstable is that we are tracking an unstable version of V8.

And because we have a brand new release process and a brand new build process um so if there are any built like kinks and stuff in that also you know we've taken a lot of work that was going into o12 um and while a lot of people do follow the o11 lines um this stuff just hasn't shipped and hasn't been tested that much um because of this you know giant lack of releases and actually getting code out of the wild. So we really want people to pull down even that work, as well as some of the work that's only happened in IOJS, as well as the new V8, and tell us, you know, how stable it is and verify that there's no regressions.

And, you know, we have found some performance regressions. I was seeing them pop up the other day. Some of them we fixed because they were in R code. Some of them are in V8, and now they're logged. And luckily, they are logged against a version of V8 that the V8 team is actively working on and doesn't like performance regressions in. So, you know, going forward, you know, once that V8 is stable, very soon after that, you'll see a stable release of node. And then it'll be really clear where the lines of delineation are around stable, unstable. Also, in the beginning, we really wanted to make it clear that we're moving to Senvair and that we have a much cleaner, more organized way of doing these version numbers. Since then, we've gotten a little deeper into what it looks like to take V8 as it's unstable.

And if we want to do that in strict Zendure or if we want to go, you know, dash pre one, dash pre two while we're in that unstable mode. So that may change after the first stabilization phase just to make it a lot clearer to everybody. And now a word from our sponsor. Digital Ocean, a simple cloud hosting provider built for developers. We've been working with DigitalOcean for quite a while. We host ourselves on DigitalOcean. We love DigitalOcean. And we think you'll love DigitalOcean too.

In 55 seconds, that's how long it takes to provision a brand new server, you'll have a cloud server with full root access, and it just doesn't get any easier than that. Pricing plan started just $5 a month for half a gig of RAM, We'll see you next time. They've got an awesome control panel to use, amazing hardware built on the hex core machines with dedicated ECC RAM and RAID SSD cloud storage. You're going to love DigitalOcean. Use our promo code CHANGELOG to get a $10 hosting credit when you sign up. Again, that code is CHANGELOG, and you'll get a $10 hosting credit when you sign up. And now back to the show.

This is sort of to send a message then. I mean, it sounds like, I mean, obviously, Node has been out there and this is, you know, to a degree a fork as you've already mentioned how it is or isn't a fork in the show already. But it's really around the new things that are happening, build process and various processes that sort of make it unstable, so to speak.

Yeah, yeah. And I mean, you know, like we're very confident that it's awesome. But, you know, nothing is going to make us fully confident in calling it stable until other people run it in production and tell us that it is. And they're doing that now that we have releases. This is somewhat off topic, but I'm kind of curious because, you know, Jared, I'm just sitting here thinking about like we've said several times in the past, I don't know how many shows, but we've either alluded to or directly said how difficult and how time-consuming and how hard open source is. how much time you spend not just contributing back, but I guess sacrificing for open source,

sacrificing for your life and your time, whether you love it or not, how much time you spend and others spend making this open source possible. I mean, it's got to take a ton of time. Yeah, I mean, I will say that it was a bit of a sacrifice and a little bit hard back when we were just trying to negotiate with Joyent and these companies. Like that took a toll on me much more than anything right now is taking a toll on me.

Also, one of the things that I figured out and this project kind of continues to prove is that it's not just about what you do. It's about what you don't do and when you step away. So, I mean, what I've been really doing a lot of is I'll jump in, I'll bring some organization to something, have some conversations, get things moving, get things into a state where there's something there and there's a clear way to contribute to it and a clear way to move it forward. And then take all the people that are now contributing and make sure that they feel comfortable making decisions, that they feel comfortable moving this forward on their own, and then I just get the hell out.

And a lot of it is just about what I don't do. I mean, I actually don't merge a lot of people's pull requests. I make them merge it themselves. Like this was happening in the website because we had to spin up this website team really quickly, so we gave a bunch of people commit privileges. But a lot of them were like, oh, what are the rules around actually putting this in? And like, you know, do I have the authority to do this just because of a commit bit?

So, you know, they were looking to me and rather than merge it, I just said, had, a lot of it has been that there has been a centralization of control around a few people, not just the dictator or the corporate owner but like the – even just the committers, right? And the more that you try to control all of that, the more that they just become a bottleneck and the people check out of the process. I think the reason why I also mentioned that too is, is just when you, with, you know, with the proverbial drama or with all the change and new process and all the motion that's happened from Node to IOJS and all the traction you guys and the rest of the community have, have placed into this, you know, we've had several guests on the show that talk about past run times of burnout for themselves, you know, we've had several guests on the show that talk about past, uh, runtimes of burnout for themselves, you know, where they sort of no matter how much they care about something,

they sort of hit a brick wall. And, you know, I see all of you all, you know, contributing so much and you love it. I can tell you love it. You know, we can both Jared, I can both tell you love it. Um, but I guess the caution I concern myself with is like, you know, how how much of a toll does this take on a certain core team, a certain core membership of the first TC meetings that we had. Ben Nordhus was on it. And somebody mentioned something about like, okay, I'll go through and I'll triage all of the bugs or I'll go through and I'll review all of the pending pull requests for the last like six months in Node or whatever and see if we can merge them over. And Ben cautioned like he was like, you know know don't take that on indefinitely it's soul sucking work like you will burn yourself out um speaking like you know from experience and um

i mean one of the great things about the project right now is that we've seen so many people flock to it and contribute and now it's it's not it's not on one person anymore. And I think for the first time, a lot of people that are on the TC right now weren't super active in NodeCore within the three to four month period before we did IOJS. They had started to check out quite a bit. And they're also really busy people.

And I think that they probably really don't want to be in these tc meetings forever um they're looking for a way out you know they're not looking for the door but um you know they would love it if they just didn't have to worry anymore and they knew that there were a ton of people um you know qualified and the tc and everything is running and they can just like go and run their business or whatever you know isaac sluter is like the ceo of npm inc right now it's a growing company like they have this investment i mean he has a lot of things to do that aren't being on these cc calls i'm sure that he would love to get off of them as soon as we have people step up and we have people stepping up and we have people growing into the project so it's looking great i guess that's the the light

shining back on the, as Jared mentioned, kind of casting light on the American Constitution and the ability to amend it and sit into government. That whole mindset is sacrificed now, but it's more of a long-tail approach to not only just a more mature software release, but a more healthy team of people making it happen day to day.

Yeah, yeah. And also, I mean, the thing about these working groups that we're spinning up to, they offer people the opportunity who may not even be programmers to participate in a particular way and even to become leaders in a particular area. You know, like we're spinning up one sort of about like evangelism pretty soon, which is like, you know, helping with the social media stuff and the messaging and like, you know, keeping a good list of people that can speak at conferences and all that. And, you know, there will be, I really hope to see people contribute there that, you know,

aren't just programmers and aren't just code contributors. Additionally, though, we have stuff like the roadmap. That could be attractive to a TC member, and it could take time away from their other technical work, but could also be really valuable and could actually be where they want to put more of their sort of influence. I know that like Burt Belder, for instance, really wants to help and work on the roadmap stuff and is super interested in that. So a lot of this is like offering up the opportunity for people to go and do work that they're well qualified to do and that they'll see a lot of benefit from, but also we as a project see a huge amount of benefit.

Sounds like it's fun again, too, at least for the time being. There's a renewed enthusiasm. You have a lot more people who are diving in who may have burnt out or lost interest. And there seems to be a vigor around the project. And yourself, I mean, you sound very excited about it. That usually fights off that burnout. Are you feeling more excited? Are you feeling vigorous? Are you feeling good about things?

Oh, definitely. Yeah. I can tell. Yeah. No, it's, it's been great. I mean, I, I was very optimistic and I had really high hopes for what would happen and, and, you know, a vision for like how many people that I thought would come. And, uh, it turns out that I was actually being quite pessimistic in my numbers and what I thought people would show up and do. I mean, the other day somebody showed up and was like, hey, I registered a SoundCloud account and set up like a podcast feed of all of the TC meetings with just the audio. I was like, wow, I hadn't even thought of that. Yeah. And it already exists.

It's great. It's really great. There's probably people that want to listen to that too, which is awesome. So let's talk about the transition, because obviously it's a transition from one project to the other. As a user, if I've been a long- stuff in production, or even if you have like a really great local dev environment, I mean, dip your toe in the water before you just jump in. So NVM, which is like the node kind of version manager, it's like a set of shell scripts that will just install and manage the version of node that you're currently running. That supports IOJS. So

just use NVM, install IOJS, and then you can run and play around with IOJS. You can see which of your projects work and which ones don't. There's a list of native modules, like modules that bind in some way to C++ that need to get fixed. Actually, that's another phenomenal story of contributors showing up. Tim Oxley just started a thread where he was like, let's compile a full list of all the modules that need to get updated and, you know, get people to go and do stuff on each one. So within a day, he had like a full list of, you know, like 40 native modules that needed to go. And then I think only shortly after that, there was a PR link next to every single one of

them. And now it's just a matter of those getting tested and actually released by all those projects. So that's awesome. That's going very fast. So, you know, if you can run all of your code on IOJS, please do it. Please tell us about any sort of bench, like any benchmarks that might be off. But it should just run. And, you know, it should be backwards compatible

with everything. So it should just be better. I mean, that's, you know, it intends backwards compatible with everything. So it should just be better. I mean, that's, you know, it intends to be a drop-in replacement. You know, by default, we do also have a node alias to IOJS by default. You know, we're there to sort of supplant the prior node that was there. So that, I mean, and especially once we stabilize, like, it should be really easy and really simple. And if there are any sort of gotchas or hangups, you can expect the documentation around that to be pretty fantastic.

Awesome. And as far as roadmap goes, obviously you've caught up with V8. You're going to keep up with V8 regular release cycles. It sounds like you guys are getting that figured out. So once that kind of gets in place, I know you have the roadmap repo, but that seems like a conversation anything that's like in the roadmap for sure that's going to happen over the next two or three months um i don't think that there's anything certain um i think um there's definitely some more streams updates coming in. So a readable stream module was brought into IOJS. There's a working group around streams.

That's getting rolled into further releases of nodes, so the required stream will just be that readable stream. There's also work that Dominic Nicole has been doing for working group streams, and we want to make sure that any incompatibilities between these two APIs, any functionality that can't be polyfilled, is reconciled now in the standardization phase. Once that's done, I expect that to move in a direction where it's very easy to interoperate

between what WD streams and streams that come out of Node. In terms of other roadmap stuff, I mean, that hasn't been decided yet because, you know, my next task really is to jump into the roadmap repo and figure out more ways of pulling in feedback from the community and figuring out what people want out of Node Next. And, you know, that's the direction that I expected to go in. Awesome. We'll definitely link up that roadmap repo in the show notes. You can get those show notes at the changelog.com slash podcast slash 139 uh all the relevant links will be there i do have a i'm about ready to wrap up here adam but i do have one i guess kind of it's not off topic but it's tangential and kind of a personal question for

you michael uh because you've been running the node conf right and so i'm starting to wonder what happens with node conf well i mean the community is still called the node community. We still install a binary called node, um, or it's an alias, I guess now, but, um, you know, we're not going to rebrand the community. We, we, you know, we consider the project sort of the future direction of core. Um, we don't want to split or bifurcate the community. Um, and in fact, like, you know, we're, we're sort of just waiting forent to come around and just join the project, to be honest, and lead the way in doing some kind of foundation. But we have figured out a better democratic model for running the project. We have a huge amount of success now.

We're sort of done having that conversation because we've solved it and it's going incredibly well. But we would like it to exist in some kind of a neutral party. We would like Join to get back on board. So we're sort of still waiting around for that. So ideally, would I.O. eventually loop back into Node and we'd go back to Node only under the open governance model? Yeah, I mean, as long as there's no owner that can kind of pull stuff out from under us.

As long as the website domain is actually owned by this neutral party. The trademark is actually owned by this neutral party. So it's not like, hey, you guys use this for a while and then later we might be able to change it. But it's a pretty, hey, you guys use this for a while, and then later we might be able to change it. But, you know, it's a pretty obvious path to that, and we hope to see them come around. Man, what a success story that would be. Yeah.

Yes. Yeah, that would be nice. I mean, it's good when everybody plays well anyway, so hopefully, you know, for the betterment of the community, there can be just eye to eye speak across the across the channels yeah well michael it's definitely been great having on the call i know that uh we we sort of sort of cut ties with the the call so to speak and go into some kind of neat questions we have here at the time of the show that sort of give us a deeper view of the guests we just have on the show and and you're that guest so the the favorite question that our listeners like to hear about is who is your programming hero and you can have one you can

have several it's up to you um i mean so historically i think um i just don't know if anyone programming today that does stuff uh as cool or as clever as what I read about Woz doing back in the day in the 70s. It's just insane, the stuff that he did. I've never met anyone or even heard of anyone quite that talented. I think today, though, like actually active programmers, probably Rod Vag. He's been, you know been he built out the build system he runs the TC meetings now as well I don't run them anymore

he's a fantastic developer obviously but he's also played this huge role in leading the community forward so this more liberalized contributor model that we've moved to that was actually pioneered by him called Open Open Source

in the Level Up ecosystem and all the LevelDB stuff that's going on in Node. He also played a really pivotal role in getting Node School off the ground. And at the same time, you know, he's taking on all these, like, really important leadership roles and code roles in IOJS. So, yeah, he's been amazing to work with

and a real hero lately. Awesome. so yeah he's he's been uh amazing to work with and a real hero lately awesome um next question is what's the call to arms i think we've talked heavily about the history obviously it probably dipped in a little bit into the call to arms but i think jared your question prior to this was probably the best which is you know if you're currently using node how do you begin to enjoy the IOJS goodness? But aside from that, I think the question is a little bit – let's make it a little bit more open-ended, not just a call to arms to IOJS and how people can contribute, but also keep up because it's moving so fast. Changes are happening quickly what's the easiest way to keep up and what's the best way to step in and start making some impact regardless of programming depth whether you're a new coder or a seasoned veteran so very soon you'll be able to sort of go to the iojs github org and look through the repos and have a clear like that's something that i could work on that's something

that i couldn't that's something that i could contribute in some way too. Um, and in each of those readme's, you should see a very clear way to do that contribution. Um, but I, I, I'm really interested in sort of what people can do, you know, in a pure community kind of way. Um, really like just growing the community, teaching people. Um, and so there's a bunch of things that you can do there. You can run a node school, uh, which is like a free programming, uh, workshop format. There's a ton of them. They're all interactive. So you just sort of NPM installed this workshopper and then dump, jump through it. Um, there's a huge amount of resources on node school.io on how to get those up and running and, and how to, you know, mentor them. Uh, there's a great process actually for, you know, you get a repo for your upcoming

node school, and then you should add everybody as an owner to it that comes to the node school so that, um, you're actually creating a support network locally for helping them even after they leave the event. And people will ask questions there that they would never ask in any of the, the big forum, global forums, because they're just too scared. But because it's just people that they just met, they have no problem with it. And, you know, in addition to sort of like the local meetup scene, one thing that I've seen be really successful is Oakland JS.

So Oakland JS is, there's no talks, there's no speakers. It's just we, every week, every week at the same time, at the same bar, we just hang out. We just, and just talk about stuff and it's become this amazing support system for the community and the culture locally and you know we've had a lot of people brand new to programming that find out about it and then like that's like the only thing they do for the first month of their programming is like they come to this thing and they keep talking to everybody and they get really involved um and that's just been awesome

so you can totally run, you know, your own of those. It's very simple. There's literally no setup. And surprisingly, it's easier to run something weekly than monthly because it's just not this big production. People, you know, don't feel quite as obligated or quite as stressed out about going. So some people go one week, they come back the next week, who knows. It just, it stays really informal, but it's also consistent, which is great. And now there's going to be a sunset JS actually in, in San Francisco, which will be pretty cool. Yeah. And also if you have a bit more chops, if you've been organizing meetups and stuff for a while, you can run what's called a node conf

one shot, which is just a one day conference, really simple, really stripped down. We have documentation on like, here's the best way to do a CFP and the kind of stuff that you need to worry about and how to do the ticketing. And, you know, we help out with some of the promotion and we get you on the OneShot site. So yeah, those are all ways that you can just kind of do pure community stuff. Awesome. I'm sure I'll have tons of fun finding all the links for the show notes. So if you're listening and you're like, man, like I want to go grab that link, go to the show notes, assuming I took the time, which I will to go and find all these links. Yeah, we like to put some awesome show notes in there for the listeners because it really

just helps, you know, you can listen and sort of be running or working out or gardening, whatever people do when they listen to the change log. I don't know. People commute and they listen. So they're not always like ready to take down links or go to the change log. I don't know. People commute and they listen, so they're not always ready to take down links or go to the Google and search around and stuff. So it kind of depends. But, yeah, I think that's pretty much the show.

I think that it's been great having you on the show. Is there anything that you want to mention prior to us closing out, Michael? No, not that I can think of. It's been fantastic. Thank you. Awesome. Well, we do have some awesome sponsors for the show that I do want to mention.

CodeShip, TopTile, and we did put the asterisk disclaimer on there. Michael does work at DigitalOcean, and DigitalOcean did sponsor the show. But DigitalOcean has been sponsoring the show for a very, very long time, and we love DigitalOcean. So we're hosted on DigitalOcean. We think you should be hosted but DigitalOcean has been sponsoring the show for a very, very long time, and we love DigitalOcean. So we're hosted on DigitalOcean. We think you should be hosted on DigitalOcean.

And if you're not, that's just a sad state of affairs there. Jared, one thing I thought we need to keep mentioning at the end of the show is to remind our listeners that we are listening as well. Go to github.com slash the changelog slash ping.

That is our open repo. I've been calling it our open inbox. And, you know, maybe, Jared, since you've been kind of triaging that quite a bit, maybe you can mention quickly, you know, how we're using that and some of the things we're hearing back from the community. Yeah, absolutely. Whether it's a project that you love or a project that you just released and you want to have some coverage to, an idea for a future show, a complaint,

you think I talk too much, I don't know, whatever you've got to say to us, come say it at Ping. We're watching that repo. We're conversing there. And we've had a lot of interesting projects come through and great show ideas. And a lot of those are turning into real shows. So it's been pretty awesome. We've been leveraging issues, not just there,

but Michael, that's how you got on here. We went to the IOJS repo and just dropped an issue in there and said, hey, can you guys come on the show? And that's how this happened. That was pretty awesome. Jared was like, that's a neat way to get a hold of people. That's how we do pretty much everything.

Yeah, so it worked out. So that was good stuff. Well, like, that's a neat way to get a hold of people. That's how we do pretty much everything. Yeah. So it worked out. So that was good stuff. Well, everybody, thanks for listening. We'll be back next week. Enjoy this. I hope you enjoyed this show. If you have any questions about some of the links you mentioned, the show notes are there.

That's changelog.com slash 139, episode 139. Thanks, Michael. Thanks, Jared. Let's all say goodbye. Bye, guys. Bye, Michael. Thanks, Jerry. Let's all say goodbye. Bye, guys. you