Transcription

Ryan is the creator of Sanchez Latino and she is a software engineer with a background in mathematics. So, Ryan, welcome to Sanchez Computing. Hello, good morning everyone. Node is quite old at this point, maybe 13, 14 years old. My original goal with Node was to force developers to easily build optimal servers by forcing them to only use async IO. This is really standard these days. Essentially, any platform is making use of non-blocking IO. But in 2008, this was not the case. I was a graduate student in math in upstate New York. I was studying for a PhD. Although I like the work of it, it's not really doing anything practical. My professors would say, someday, maybe theoretical physicists might use this work. And it's just like, yeah, that's kind of not good enough. I wanted to be doing something that is more related to what humans are doing. I dropped out and I moved randomly to South America and found my way into programming by way of Craigslist. I was working on like a snowboard marketing website for some snowboarding company. It's not like the sort of thing that is like one's life purpose or anything, so I pretty quickly like moved into more abstract problems, right? You start at the snowboard website, you realize that we should implement this on Ruby on Rails. You start thinking about Ruby on Rails, why is that slow? Maybe we should be implementing something else. And pretty soon you're working on Nginx modules, lower level technology in the web stack. So I think I kind of found my place within there. What brought me to Germany was a girl named Lisa, who also traveled with me to South America. She was my girlfriend. I met her in upstate New York. She was there on an exchange program, and she had to go back to Cologne to finish her graduate studies. And me, not knowing what I'm doing, having dropped out of grad school, went with her and ended up living in Cologne for two and a half years or so. It was great because Cologne is cheap. I paid like $400 a month for my room, and it provided kind of a lot of space to be able to think about things and work on different projects. And yeah, I think it was a really enjoyable part of my 20s, just kind of sitting in Cologne thinking about programming topics. I'm Lars Back. I'm a V8 tech lead, and I'm all the way from Aarhus, Denmark to present V8. Around the time that Chrome and V8 came out, I was thinking about those sort of problems, how JavaScript relates to non-blocking servers and, you know, this new JavaScript runtime had just come out. And so really kind of thinking about the right things at the right time. I was very excited about building websites, but very quickly realized that these websites were pretty slow. In 2009, like, interactive websites and stuff was basically non-existent. There was different bits of software that could do this in different domains, and I was certainly building on the ideas of other people. But I think Node was the first system to really make this kind of widely available and accessible to people. I started working on it in Cologne. I built the first version there, like, basically stopped everything I was doing and worked on it from, like, February to October, basically full time. Around the time that Node was first released, I was working at Yahoo and getting kind of frustrated that I had to be context switching between PHP and JavaScript, PHP on the back end, JavaScript on the front end. So I thought, it's a programming language, why don't we just have JavaScript on the server? And there was a handful of people trying to kind of make that work. Kevin Dangor and Chris Kowal and a handful of others started this server.js group that were trying to, like, come up with a specification for all of these new server-side.js platforms that people were trying to build. Node sort of came out of left field a little bit in terms of that space. I think Ryan Dahl kind of picked JavaScript not because he was particularly attached to JavaScript. It just was a good fit. I realized that it did some sort of N-level language. If I was, you know, if I was actually going to get real users using this. And I looked around, and I spent some time with Python, and I spent some time with Lua, and I spent some time with Haskell. And I think around January of 2000, I was sitting with my friend, and I just had this idea, like, oh, shit, JavaScript, JavaScript, like, fuck. It was, like, so perfectly clear at that moment that, like, oh, my God, this is the language. He had a particular kind of I-O paradigm that he wanted to push, and JavaScript was kind of this perfect storm of, like, large community of developers, there's a lot of really good run times for the language, and it has no I-O paradigms already, right? If you tried to do that in Ruby or Perl or Python or whatever, you know, you're sort of fighting this uphill battle because all the existing code is using this older kind of more synchronous approach to I-O. I think it was Node 0.0.2 I first came across and was like, oh, this is neat, and I tried to build it. It didn't build on my Mac, so I was like, well, this is obviously broken and not going to become anything, so whatever. Matt and I had this idea that we were going to write a game on server-side JS and kind of to see what this stack can do and actually use it for a proper project. I gave this talk at Yahoo about server-side JS, and built this little tic-tac-toe multiplayer game with a co-worker of mine. So here we go. We've got two different web browsers. Somebody came up after the tech talk and was like, hey, have you checked out Node? And I was like, yeah, I tried it. It didn't really work. It seems kind of, I don't know, it seems kind of niche. He was like, well, you should give it another try. It's actually really cool. So I did. I went back and checked it out. At that point, it was like version 0.0.6. It did build on my machine. I played with it, and I was like, oh, this is way better. This is the way to do it. Like this actually feels much more like a JavaScript platform. Slowly, but surely, there were more and more people that just kind of appeared, and Isaac Schluter came along and built this NPM system, this Node Package Manager. There was a really small group of people, maybe dozens but not hundreds, on a mailing list in an IRC channel. People would share things. They'd be like, hey, I wrote this new library that's like a connector for such and such database, or it does this or that thing, parses email addresses, I don't know, whatever. Check it out. Let me know what you think. And to use it, you have to download it from GitHub, and then you need to copy this other project into this place for its dependency, then you need to run make, and then copy this file over to here, and yada, yada, yada. This is a pain in the ass. I wrote a message to the mailing list and was like, I think Node needs a package manager. Here's kind of what I think it should look like, or how it should work. So that was NPM. It started out as essentially a Bash script that I just called from a Node program. There was very little cleverness to it. And I copied a lot of paradigms and a lot of approaches from yinst, which is the package manager that Yahoo used internally for development. The thing that Yahoo did was, any developer can publish whatever they want into the internal registry. And you're supposed to just be publishing versions of your packages all the time, like when you're in dev mode. And then you move it into production when you ship your application or whatever. I kind of built NPM with that idea in mind of, anybody should be able to publish anything, there's no barriers to entry there, mostly because I did not want to be in the loop. If somebody wanted to publish a package, it should just be like, yeah, you go do that, and I don't want to know about it. Yeah, and that's been pretty effective since, I think. People took to it pretty quickly. At that point, I kind of had this initial version that I took to Berlin and showed off at I think the first JSConf EU. I'm going to talk about Node. So briefly, Node is a server-side JS platform. It's built on Google's V8. I'm super nervous in there, because I've been preparing for this forever, and this was like my one chance to show people, and I really felt a lot of pressure to make sure it went okay. What I want to make is a non-blocking infrastructure, so that you can make very highly concurrent servers, and you don't need to know about it. We're going to abstract all of the difficult non-blocking event loop. You don't need to know about that. It's just going to be callbacks. I'm just some random person kind of showing up there, but I was very prepared with this demo. I had been preparing it for weeks in advance, and everybody's presenting their toy projects, but this was a very serious toy project that I was working on. Now I have a demo for you. I wrote an IRC server in Node. It's a chat server that people in the audience could connect to, and it's all written in JavaScript. In 2009, this was a mind-blowing sort of development. Like, oh wow, you can build this in JavaScript, and we're all connecting and chatting with this in real-time. I'm so glad that demo worked, because it was very, who knows, the Wi-Fi could have gone out. I mean, it's 2009. Things were not working properly, but thankfully, that went really well, and that really kind of jump-started the Node project, right? A lot of people saw that talk and got involved in it. In 2009, I was actually mostly writing Python, but also wrote a little bit of JavaScript, because I was working at Mozilla at the time. A friend of mine who ran a conference, JSConf EU, had this great talk about this project Node.js. He was talking about it a lot, and so I was like, okay, I should check that out. I write JavaScript. I have a lot of these kinds of problems. I should go look into it. And I asked on Twitter, hey, has anybody written a proxy in this yet? It's like a week old or something, like probably not. But nobody had actually written an HTTP proxy in it, and that seemed to be like the first thing you would want to really do in it. And I'd spent like probably about four years working on a Python proxy that was very... As optimized as you can make a proxy in Python, I was very convinced and still am pretty convinced that that's about as fast as you can get it. And so I was like, okay, I'll maybe try for a weekend, and maybe a few weekends, it'll be a fun little side project. In like three or four hours, I had a proxy. It worked pretty well. I benchmarked it next to my Python proxy, and my Python proxy was like not even close. Like it was just killing it. And this was after the project had been out for a week. So where is it going to go from there? What am I even doing spending my time writing Python? So I kind of told everybody at Mozilla, I'm not going to write Python anymore, I'm going to write this. And I was employed as a Python programmer, so that went over about as well as you might expect. But I was just done wasting my time. Back then, there weren't these established channels for programmers, really. There wasn't Slack, there wasn't Discord, GitHub was super primitive. People would email me patches, I would apply them. There was no continuous integration back then. I would run the tests manually on all of the operating systems for every patch. Like I was the CI system, which, you know, these days just seems ridiculous. But there's no infrastructure for that. I didn't know Ryan prior to Node. I assumed that he was German, because on the IRC channel, like, he mentioned being in Germany. You know, it was like Ryan Dahl, like, that's a pretty German-ish sounding name. And I had seen him in the IRC channel speaking in German. I was at the time trying to kind of beat the drum for this spec that the CommonJS group was pushing forward. And after that, like, this guy comes up to me and was like, hi, and I was like, oh, hi. And he was like, I'm Ryan. I was like, nice to meet you, Ryan. He's like, Ryan Dahl from Node. I'm like, oh, oh, like, your English is really good. He was like, well, I grew up in San Diego, so it should be. When I was still in Cologne, shortly after this JSConf presentation, I got approached by a number of companies that were like, hey, we would like to do something with Node. I flew out to San Francisco and met with a couple of them and was basically looking for a way to fund this project. I mean, it was very clear I should keep working on this. Like, I knew I was onto something, but I could not continue doing this out of my own pocket, right? I needed somebody to pay for this. And yeah, Joyent basically had the best proposition. This is the computer that we founded the Joyent cloud on. They were building a hosting provider, and they would like Node to work on this hosting provider and make it so that they can run Node applications there. And I thought that was a good use case for Node, and kind of the incentives were correctly aligned. Joyent had been a hosting company for a pretty long time, but most of their kind of marketing and their business and their offerings were really targeting more enterprise stuff. They weren't really well known among the sort of demographic of like hobbyist hackers who were getting involved in Node. I think people more or less trusted Ryan, and they didn't really know who Joyent was, and they were just like, cool, it's got sponsorship now. Like, Ryan's going to keep working on it. That's great. I moved out to San Francisco and started work with them, you know, basically continuing to work on Node full time. I think there was some idea that I would also work on Joyent software at the time, and I was perfectly fine with that. I was interested in, you know, servers and hosting technology and that sort of stuff. But like, I mean, by the time I joined, like Node was even more popular. And every month that went by, I mean, it was just really clear that this thing was taking off in a serious way. And I ended up not doing anything at Joyent other than working on Node. I think Ryan definitely was surprised that Node got so popular so fast, or maybe not surprised. I mean, I think he thought it was going to be a popular thing. Like that was why he chose JavaScript was so that it would be popular. But at the same time, like there's a big difference between you can know something rationally and still be surprised by what it's like, right? And I think Ryan definitely was somewhat surprised by what it's like to run a huge, you know, world-renowned open source project. I was working at a startup where we did automation for construction companies. And yeah, there were some like complicated computations we had to do that we would write for the front end so that we could like people show people quickly what their total would be. And then for security reasons, we would have to like replicate that in the back end and write all that in a different programming language. And so, yeah, I was already looking for a solution here and, you know, you're thinking about, okay, how can I translate JavaScript to PHP? Like it's like a little bit much to do when you're the only engineer on a big project. We also needed to do a big database migration. And if you write lots of database statements and you try to do them one by one, that would just take forever. In order to get that database migration done, what I did is I took Node.js, did a whole bunch of stuff in parallel and that actually allowed us to get it done like overnight. And yeah, at that point I was hooked. I mean, I knew that was going to be the future of programming. I was considering getting a job with this company that wanted to do like some Node hosting stuff. So I mentioned this to Ryan and he was like, no, no, no, no, don't do that. Joanne just hired me. They're making a big bet on Node, like you belong here, like you should come join this team and work on Node. And I was like, oh, that's way better. Yeah, that's a much better choice. It was like me and him, we were in some office building in downtown San Francisco. I would come in and sit at my desk and answer emails and merge patches and, you know, basically did that for quite a while. We were doing the same things that we were doing when it was me in my apartment and him in Germany, like on an IRC channel, but we were in person. Yeah. And so that was kind of the first phase of things at Joyent. Node is changing, okay? It's a living creature. And with that comes some blood, some pain and your necessity to compile it. In the like 0.0, 0.1 kind of versions of Node, Ryan was extremely cavalier about just like, well, I broke all the Node programs, pushed a new version and now this, you know, all the APIs changed. He had this plan where, you know, he would do an 0.2 release and then 0.3 would be unstable and then 0.4 would be stable. And in between these two releases, you could do breaking changes and he would keep doing these breaking changes until 1.0 and that would be the only time that he wouldn't guarantee a breaking change. The first time one of these actually lands, it's just the rename of a module, renaming sys to util. And it's an easy enough thing not to break, right? Like you could just return that module, it's like one line somewhere, who cares? But like, you know, he wanted to rename the module, so he's going to break everybody. People freaked the fuck out. Nobody could understand why that opinion was worth breaking their software. There is different maturity levels to projects. And when things are young, you move fast and you break things and you just make it the way that it needs to work. The first NPM where you could actually install stuff came out around the same time as Node 0.0.8. It like didn't work on the next release of Node and so they had to like update everything and then, you know, there was kind of this back and forth like as we were like seesawing towards getting stuff to a usable state that a community could actually grow on. What else is there before we get to something that we want to call 1.0? There's not a totally laid out roadmap for 1.0 because it's in the distant future. We'll focus on 0.6, reworking the plumbing, and then revisit that question. There were certainly periods where Node was starting to have many users and I would be like we've made a mistake here. We're going to do this. I'm just going to shut off the lights for everybody and like, you know, paint the room and then turn the lights back on and everybody's like, oh shit. I think it's just kind of at the cusp of one of these maturity levels where like, you know, things were still being changed in earnest. And that definitely held back the growth to some extent in those early days. But I think it was actually really the right choice because, to be honest, I mean, once it got really popular, things got a lot harder. Like now you had to be much more careful. A year or so into working there, Joanne approached me and was like, hey, we want to buy this project from you. And of course, it's like, okay, well, what does it even mean to buy it from me? I mean, it's an open source project, but, you know, essentially they wanted to manage the project, own the trademark, own the website and use this to promote their company. We did this deal and I walked away not completely poor from this. So I felt pretty good about it. I think it kind of happened a little bit under the radar over the course of a couple of years. There was somebody who raised some question on the Node mailing list, like if Joanne acquired Node, like what does this mean for Node? And like, what if Joanne turns evil? It's not like fear, fear, fear. And my response was like, what's the big deal? There's a pattern for this and open source, like the code is MIT licensed. If Joanne turns evil, like all they bought was a name and we can take this code and put a new name on it, like even if they're not evil, even if they're just annoying. I have a potentially impertinent question. I read the trademark policy and I was really curious to know, is there going to be some conservancy or is there going to be some organization that's going to sort of shepherd that out in the future? No, I think Joanne's going to keep shepherding this and pushing it forward. In the end, the software is very, very open source and so hopefully that will prevent any sort of problems. Joanne hasn't done anything to deserve any ill will. They've done a great job. I mean, just another thing, this is not a conference for a logo. This is a conference about a piece of software. That's why we're here. That's still MIT licensed and it will be forever. At the time, most of us really brushed it off, me included, really brushed it off. Because one, when you're writing the software and they need you to write the software, you're not worried that like they think that they own something. We didn't think that the switching cost would actually get as difficult as it would become. Node.js at the time only ran on Mac OS and Linux, but me and the other engineers working on this startup were all using Windows. So we could, in theory, at least deploy it to our servers, but we were not able to develop with it. I was like, oh, why don't I go fix this? That kind of got a life of its own. It turned out that actually doing that on Windows is very complicated, mostly because the way Windows works is very different from Mac OS and Linux, how they approach asynchronous I.O. That seems like maybe a little bit strange nowadays because asynchronous I.O. is everywhere. But yeah, at the time it was just not. And so I got involved, I got sort of a first prototype of the ground that wasn't very fast or very good. You know, at the time, all discussions around this happened on the mailing list. And I went on there and I described more or less how I would approach it. That's when my first contact with Ryan was established. I think he said like, okay, well, yeah, show that it can be done. And so yeah, that's how I got into all this. This was like more than a year undertaking where we essentially like, you know, if Node is a building, like we basically put it onto forklifts, like lifted it up, moved it 50 meters and then kind of set it down on a new foundation. Like it was extremely difficult. Today is not about Node, but something that underlies Node, which is called LibUV. LibUV ultimately was Ryan's idea. So like before Node.js 0.4, I was using another library called LibEV. And LibEV is basically a wrapper around the function called select and there's other variants of that. Select is very old and it's almost on every operating system, but it's very slow as well. So it's basically unusable if you want to make a runtime that runs stuff fast and, you know, is very scalable. But LibEV was really built around that primitive. So what I did is kind of like try to, yeah, fake it, make LibEV work on Windows anyway. And that only went so far. Then the next step, what I did is just, you know, don't use LibEV, like, you know, LibEV was only used on Mac OS and Linux, but on Windows, Node.js would basically have a completely separate implementation. Ryan didn't like that because it made the code for Node.js very complicated. I think that is a very reasonable position. And so his idea was, okay, let's just write our own library that is like LibEV as much as possible, but exposes an abstraction that works for all operating systems. The way we started working on it is basically I took the code that I had written for Node.js and I put it on sort of the Windows side of LibEV and he took LibEV and wrote some like wrapper around it and that would become sort of the initial version of the Linux and Mac OS version of LibEV. Once that was done, we had hired some more people like Ben Nordhuis in particular, who said I can actually do this a lot better and like make it more maintainable and more efficient. And so then he wrote, rewrote that part essentially. But yeah, it was like Ryan who took the initiative and like we worked very closely to get the first design out of the door. That was a super successful project. These days Node runs fantastic on Windows. I don't think it's really an accomplishment that is celebrated or even known about that much, but it was a massive undertaking. You know, it's essentially invisible to users. They just use it on Windows, right? But I think that ultimately has had a lot of effect on how much people have been able to utilize it. This wild like knock-on consequence of Node being really good on Windows because Bert and Ben made it really good on Windows is that when Stack Overflow became like the place for everyone to answer every question about programming, a lot of Node questions ended up on Stack Overflow. And when the .NET community was starting to think like maybe we shouldn't use .NET anymore for web backend stuff, they started looking at Node.js and they found that it was really good on Windows. And so they ended up adopting it and creating this whole community on Stack Overflow that we had no idea about. Like at a certain point, I realized that some of the answers on Stack Overflow are kind of wrong and maybe we should take an interest in this. So I wrote a little bot where every time someone would ask a Node.js question on Stack Overflow, I'd put it into IRC. It floods the channel. Like immediately all the project contributors are like, turn this off. What are you thinking? This is too much stuff. Because they had just already created like the largest answering community about our software problems and that wouldn't have happened if it wasn't good on Windows. For a long time, growing the community meant making Node itself better, like fixing bugs and fixing performance and making sure that it compiles on Windows. Those were our bottlenecks for a while, but now actually it's running pretty well. Ryan basically said, hey, I've been doing this for like over three years now. This is the first project I've ever worked on that lasted more than six months. This is not natural for me. I'm over it. Like I'm kind of burnt out on this. Also like the money that he was getting from Joyent, he had fully invested into. And I mean, at that point I was already kind of like doing our weekly builds and we had a core team who had commit access and had some kind of like, you know, designated areas of responsibility. Yeah. And he was like, Joyent owns the project. They want a Joyent employee to be like their, you know, the lead developer who's got like, you know, the final like gatekeeper say on what goes into a release, you're already doing that job. Do you want to just keep doing that job? Because I'm going to leave. And I was like, oh, all right. I think it ultimately just came down to a business decision of, you know, where should I put my effort? This company has bought it from me. They are going to manage it. You know, I've explicitly given up control of it. I've been paid. So, you know, it seems to be going well. You know, I think my job was done at that point. He basically went off and kind of became a professional hipster for a while. I moved out here to New York. I didn't have a job for a long time. I basically went back to my preferred mode of operation, which is hanging out in Starbucks and programming on projects. I started just sort of being the, you know, the main person who was in charge of the Node project. It was a lot more challenging. I mean, it was a much harder job than what I'd been doing. I didn't have the same level of, like, moral authority when it came to Node that Ryan did, right? I wasn't its original inventor. Yeah, I had built a couple of really big parts of it, but there was also a lot of things that I didn't understand as well as Ryan had and really had to rely on the rest of the core devs on the team. When Ryan left, I was like, this is actually kind of perfect because now you've set a precedent that, like, you work on the thing that you're into and then you just hand it off. And then we can just have these, like, and it's just kind of obvious. When he gave it to Isaac, nobody was like, why did Isaac get it? Like, you know, he wrote, he made NPM. That's why he gets it. Like, he was doing all of the releases already. But like, you know, in that transition and even after, for some people, just seeing it transition from one joint employee to another, even with Isaac, some of them didn't have the same relationship with the project anymore. And I think that it just made a lot of stuff more difficult with some of those contributors. And so even while Isaac was running the project, relationships got stretched very thin. Joint really had put the word out that, like, Joint's the Node company and we're real and Isaac's the leader of Node and, like, believe what he says and follow his direction, which was kind of a, I mean, it helped, I think, from a community point of view to just sort of cement that, like, Node is still alive. Like, don't worry, even though Ryan left. But also, it had this kind of weird effect of sort of casting me as, like, the Joint guy, you know, like the corporate shill. And I definitely encountered some, like, negative perception as a result of that. I've been using Node since 0.6, which would have been, I want to say either late 2011 or early 2012. I was in art school in Toronto at the Ontario College of Art and Design. I was doing a lot of, like, site-based installation work. I was particularly interested in building this kind of, like, large didactic installation. I had this goal that, like, people could just walk into the space and open their phone and control the installation. And I was pretty adamant that I didn't want people to have to go into, like, a walled garden ecosystem and install a native app. And I definitely didn't want to, like, have to learn Objective-C or Java to, like, do this one little thing. I wanted to do it with web technologies. I found this protocol called Open Sound Control, which is heavily used within music software and artist software for kind of getting different softwares to communicate. And I found a tutorial on how to do it with PHP. That didn't work. I found a tutorial on how to do it with Python. And that didn't work. And then I found a tutorial on how to do it with Node.js. That also didn't work, but I knew just enough JavaScript that I was able to debug it and get it to work. And in about, like, 15 or 20 minutes, I had a prototype and I was just like, oh my God. That was kind of, for me, like, the wow moment, like, we talk about, like, time to wow or time to productivity in product as far as, like, getting people running. And I think that is one of, like, the real magics of Node.js. It gives you all of these, like, really powerful capabilities that, like, historically were maybe reserved for, like, systems programmers or, like, you know, the people who understood C. But all of a sudden, with, like, a bit of JavaScript, I could, like, send network packets across a room. I pushed for, you know, hiring another Node developer because it was just too much. I was doing the weekly releases. There was a constant steady stream of, like, various marketing, legal, whatever, whatever type of things that I had to interface with Joyent about. And then there was also just running the project. So we hired TJ Fontaine, great background, you know, doing a lot of, like, build tooling type stuff, which had gotten really ridiculous, right? Like, the early, like, scripts to build and deploy Node that Ryan had used were really simple, right? They just, like, built a tarball of the code and they uploaded it somewhere and then you could download it. The end. And then we started doing, like, pre-built binaries for different operating systems and stuff. And so for that, you had to either, like, cross compile or have a VM running. And just these, like, these scripts for doing these builds had gotten really, really ludicrous. And so we brought TJ Fontaine in and his first job was, like, make all of that, just, like, put it in, like, Jenkins or something, right? Put it in some kind of CI system so we don't have to touch it. My passion and my motivation was largely spent in open source projects in my spare time. So when I had the opportunity to work at Joyent, I was incredibly excited by the fact I was going to work full time on open source. It wasn't just any open source project. It was my new crush, Node.js. I left Joyent not because I was, like, burnt out on Node.js, but because I really needed to go fix NPM. In the time that I'd been running the Node.js project, I was really not doing anything with NPM. Like, it was coasting along more or less on autopilot. So I more or less left Joyent kind of in a hurry to go deal with that. And I don't feel great about this. I don't know what I would have done differently or what I could have done differently. But I definitely did just sort of, like, rush out the door, toss the keys to TJ, like, have fun. Don't let Node.js die. He was left without a ton of guidance in terms of, like, how to run this project in a way that's effective. I remember talking to folks at Joyent and saying, like, I know TJ. He's a nice guy. I don't have any problem with him taking over the project. But, like, you really need to message this like it's a project thing and not a Joyent thing. This person did not become the BDFL because he had shown great vision. He became the BDFL because he, you know, already worked at Joyent on Node.js related stuff. And so, you know, they needed someone. That's a very tough position to be in and not a very effective choice if you want to steer an open source project in the right direction. Some people left right away. Like, I mean, it was it was like that. They were gone. And then, you know, TJ's trying to hold together this project with less people. Who wants to be involved now? Right. Like, you've been shedding contributors and now it's it's your company's project that you're PMing like a company project. Who wants to show up and be your free labor? You know, so he was put in this impossible position. The leases kind of ended up slowing down. There was a bunch of conflicts about, like, what's going to get in and what's not. What I had heard from people's, at least people's impression, was that Joyent had built this whole cloud using Node.js, which is extremely impressive for the time at which they did it. But upgrading certain things like V8 or making changes to certain interfaces that perhaps were necessary for the growth of the platform or the needs of the community potentially broke like this giant cloud that they had built. So there was this huge conflict where, like, for them to be good stewards of the platform for themselves was in conflict with Joyent being stewards for the broader community. So my understanding is they stopped accepting community contributions. They weren't open to things like updating V8. Node was starting to show its age. It didn't have the language features that people wanted to use. Node.js is a great thing, and I would bet the company on it, but I would not bet the company on Joyent. I see Joyent doing some stuff which is amateurish, maybe a little childish. So I would fork it. And I would then give that back to the community. I had taken a break from Core for a while and was doing more community stuff. I started to hear from people that there was going to be a fork, and I was like, oh, OK, I probably know who would be doing that. Maybe I should just reach out to all the people that might do that. And what I figured out was that there wasn't going to be a fork. There was going to be three forks, because not only were people kind of upset with Joyent, they were also not really talking to each other. Like a lot of relationships had just broken apart. And what I decided to do at that time was just, you know, at least make it one fork. You had a project that didn't start as corporately stewarded. It started as open source with the BDFL. It got purchased. It got turned into a corporately stewarded project, but that was ambiguous. And slowly over time, it drifted into the point where the corporation was driving the roadmap. But that was not aligned with the expectations of the community. Secure was like, OK, well, like, fuck you, right? Like, we're going to, like, go do our thing. I run NodeConf, and we use that as an opportunity, since so many people are going to be in the Bay Area, to have a get together after that conference. And this is, you know, a collection of a bunch of contributors that are upset. Some of their employers, some of the startups that have literally built their entire business around Node. It's not a group of people that get along with each other, necessarily. Because what happens with the BDFL model is that you have all these people that have been putting years into this project. And they have to fight with one person to get all their stuff in. And eventually they start fighting with each other, too. We were all now in a group together, like, solving this problem that we had with Joyent. When we walk away from that meeting, we have three weeks. We set a timer and we say that we're going to have three weeks. And all the contributors are going to figure out what we kind of want to see. And you can just tell us if you're willing to do that or not. And we can, like, have a conversation going from there. But, like, let's set a date that we'll do something. So we create this private repository called Node Forward. Basically, every core committer on the project or core contributor to the project joined this Node Forward group, but TJ refused, abstained from it, or was prohibited by Joyent, I don't know. But he didn't join. The idea there was just to kind of, like, have some discussions, right? Because we came to Joyent, we said Node needs open governance. And they said, what does that mean? And we said, good question. We'll get right back. We'll get back to you on that. Let's go figure that out. We put together this offer that, in hindsight, is a dream for Joyent. We would just operate the project under this governance model. And if Joyent ever decided they could just pull it away and we would have to, you know, go home, right? We'd have to just go and create something else or call it something else at that point. And they just didn't engage. They just they didn't participate at all. And when the three week mark came up, they removed two contributors without talking to anybody. And then they put on a blog post. So we were like, oh, OK. So they told us to go fuck ourselves. We're going to go. That week, though, they get a new CEO. And so everyone around this is like preparing for us to just go off and fork. But now all of the companies and all of the corporate representation is like, let us try to negotiate with this new guy. And this new guy turns out to be like a totally reasonable guy. Like, we really think that we can negotiate with them. And they're not wrong. Scott Hammond's a totally reasonable guy. I knew that there was some angst in the community. The team at Joyent had sort of, we talked about that before I came in. And I knew that Node was an important project to Joyent. And I knew that Node was a very important project in the whole to the much broader developer community. So I spent a lot of time when I first got to Joyent meeting with a lot of the key stakeholders in the project. He reached out to me and like set up a time for us to like chat and kind of get to know each other. He was just kind of like learning the space. We set up, I forget what we called it, a leadership council or community council or something where I wanted to bring in some of the key stakeholders from each of the different facets to really vet the issues and come to a consensus on what Node should be going forward. So they created an advisory board, the Joyent Node Advisory Board. And they were like, you know, we're doing this to listen to the community. And then we told them a lot of things that they didn't do. And we're like, you're not listening to us. And I'm like, oh, we're definitely listening. We were working on new features, but like this release just wasn't being made. It's just it's dragging on and on. And we keep arriving back at the same things. And the contributors now, they have a governance policy that they like. They're in a private repository where we now have more people contributing to it than the project has ever had consistently already in private. Essentially, what I tried to do is just quantify a lot of the stuff that we've talked about in terms of governance and a contribution policy and scope it just to this kind of Node forward repo. The core devs who had been working on this, right, they were like, oh, cool. Like, this is a place where I can actually go and send a bug fix and it will get landed. It's not going to end up in a Node release yet, but like at least I can just get it off my to do list. Whereas all these patches I keep sending to joint Node, like they're just sitting there pending forever and they're not happening. So there was a lot of frustration around that. TJ is not working on this project, but the main code going into even the Node.js project is Fedor and Trevor porting stuff out of this private repository into the public projects. So everybody's just getting annoyed with this situation. And we just go, let's make it public, but let's not like do a big thing about it. Let's not rub it in their face. Like we want to just like stop with the annoyance of it being private. That leads to like, you know, me getting phone calls that are, you know, insinuating that I'm going to be sued for trademark infringement. It was something that was called Node that was clearly competing with Node and it was in the same space, you know, in the same market category as Node. And so therefore it's a copyright violation and they would sue over it. And we're like, there are tens of thousands of forks of Node that are all called Node and they're all in the same space as Node and they're all different from Node. This is how GitHub works. Like this doesn't make any sense. And they're like, aha, cool story, we're going to sue. Funny thing about trademark law is if you don't enforce your trademark rights, then you actually don't get to enforce your trademark rights. And I told them that we had full intent to pursue our our trademark rights around Node and Node.js. We don't really want to like cause a bunch of drama or a big scene about it. What we really want to do is just prove out that like this contribution model where the contributors have more control over the project works. I understood why they wanted to do it. In the end, I disagreed with what they were doing. I was concerned that we were going to lose the big users. The feedback that I was getting from that community was that this is a disaster, that if Node forward goes ahead as a separate group, they would have to rethink whether they were willing to make a bet and a commitment on Node as a platform for on a going forward basis for them. So they wanted a healthy, singular community. They didn't want this fractured community. So I was very concerned from that and that these were also the organizations that we're going to depend on for providing additional technical contributions and financial contributions. I flipped it back to private. I'm like, you guys are great. I love you. Call me when you want to fork. And so Fumitor replied, OK, I forked it. I called it IOJS. It's right here. Let's do it. We were at some family's house and just had this like, you know, big Thanksgiving dinner and I start getting pinged by like reporters and everybody is like, what are you doing? Like, oh, my God, like, how could you do this? Like, this is such a like such an underhanded move to do this over a holiday weekend. And I was just like, I have literally no idea what you're talking about. So, you know, and the reporters were pinging me like, would you like to comment on IOJS? And I was like, IOJ who? I've never heard of this thing. And then I go back and I look at the mailing list. I look at the like comments that Fumitor had posted on GitHub. And he was just like Wednesday. He was just like, hey, what do you all think of IOJS? You just like rename and then open source it again. And somebody else was like, yeah, I don't know. I think that'd be fine. And then like six hours go by and nobody's responded. And he was like, OK, well, cool, I'm doing it. And then he did Thursday, you know, Thanksgiving morning, everybody in the US wakes up and sees that there's this new IOJS thing. That's a fork of Node. From my perspective at the time, it seemed like Joyent wasn't being a good steward for Node.js and people were pissed and they were taking destiny into their own hands. And that seemed, you know, like very reasonable to me. It was collective action. That was cool. Literally everybody working on IOJS had previously been working on Node. It was the same team. It was the same people. It was the same code base. We were even preferring to just keep calling it Node. Our ideal would have been at Joyent. We're pulling those changes and implementing those things. Did it seem like a big drama to you? I mean, there was like some debate about it, but to us, it just seemed like, OK, well, like, I guess we'll take matters into our own hands. That's the beauty of open source. You can fork things. And I think if you were to talk to people at Joyent at the time, I think they would probably agree with me. It frustrated me and disappointed me when the IOJS fork did come out. I was frustrated. I was pretty pissed off. I was disappointed. The community sentiment was immediate and profound. Everybody was like, sweet, Node has stalled. IOJS is the new hotness. I'm on IOJS now. That's kind of the thing that's interesting about open source, I think. It is that, like, instability and chaos actually makes it stronger. On the other hand, that instability is really dangerous for companies that are trying to, you know, extract value because it becomes very slippery and brittle. And so, you know, like, that whole thing of like, you know, like, like, like, like, like, whole thing of like, oh, why are you rocking the boat by changing the name and forking It's like, well, because I don't mind a rocking boat. I'm a dolphin. Like, it's all good. More waves, the better. You're the one with the problem because you're the one in a boat. I don't know if that analogy makes a lot of sense. But our first release has, you know, a modern V8 engine in it and a bunch of features that everybody's been wanting forever. So we had a lot to talk about that developers wanted to hear. The joint was very upset because, and I don't think that we appreciated this enough at the time, but this is property. And so it's an asset on their books. And so to them, it was always like we had taken something from them. And all we had done from our perspective was, like, not do free labor for them, like, actually take the work that we were doing and do it as a community the way that we want. So this is mostly for Scott, but what are your two cents on the I.O. org? Yeah, first, yeah, great, great question. I thought that would come earlier. We want to make sure that we have a governance model around the project that allows for a truly, you know, community driven progress around what the roadmap is and the technical direction, the technical decisions. So making sure that the project is run in a true consensus model, you know, and not one that represents the special interests of any organization, not even joint. I.O.J.S. did end up being this really big shot across the bow as far as, like, getting joint to realize that what they had in Node was actually at risk, right? That, like, if they continue to really, like, dig in their heels and refuse to move and refuse to budge on going to a foundation, they were going to be left holding an empty bag. What are kind of your priorities for 2015? What are you guys working on that you're excited about? We're working with a group of organizations for a foundation for Node.js. We concluded that for our interest, we didn't need to be the steward of Node, but we needed Node as a project to be unified and successful and have very broad adoption, broad contributions. So we needed a healthy and vibrant Node going forward. The biggest sort of change on the immediate horizon is certainly Node going to a foundation, which Joynt announced yesterday. And, you know, that's not the end of the road. That's the beginning of a different road with tons of work. So a lot of us have been very involved. IBM throws James Snell at both projects and says, contribute to both, evaluate the governance models, tell us what you think. So in January of 2015, I was given two directives by my manager. And the first thing that she asked me to do was figure out how to help. IBM is a user of Node. The second directive was figure out how to bring Node and IoJS back together. And he comes back and he says, well, you know, IoJS has this, you know, it's a big project consensus-seeking model. And here's the governance policy and here's the release policy. And here's where they're thinking about that. And Node doesn't really have a policy or a governance policy or any of this. At that point, the Linux Foundation says, hey, Michael, can you solve this governance problem for us? At that point, we can bring it to a vote in IoJS. And what could happen is that we can move the whole IoJS org to the foundation and continue IoJS releases while we're trying to merge and convert to end of the repository. Then we kind of put it to the project and we say like, hey, like, what do you think? There were a lot of people that came out of the woodwork to be like, don't do it, man. There was a lot of consternation about what Node 4 was trying to do and what the IoJS fork did. But we took some of those ideas from that group and folded them into how the project was going to be run going forward. There was a lot of good thought put into a bunch of that stuff. So why not? Scott had a job to do. He did it in a way that I think actually ended up being a pretty positive outcome for the Node community. I probably don't have a special opinion as long as we can shape the releases regularly. I'm pretty impressed with the activity that we have in Node Foundation and impressed with the stuff that guys prepared for us to reconcile. So I'm very optimistic. We never had some kind of hardcore disagreement with the other project other than governance. So if we can get our governance and be Node again, we are fully happy. Do we want to go back around and do the vote thing on this or what? The limited scope of this proposal is something I can agree with. So plus one for me. I'm in favor. Plus one. Plus one. Plus one enough. He was like, plus one for me as well. So that's plus one all around. Okay. Yeah. We announced it and rolled it out and moved forward. And that's all. That's a happy ending. I mean, at the end of the day, essentially everything that was in IOJS is what became Node in the Node Foundation. There was like a little bit of work that had gone into Node 0.12 that somewhat conflicted with the stuff that was in IOJS version 1 or 2, whatever it was up to. And so there was like a little bit of technical work to just sort of figure out how to merge those things back together. But then I think the next version of Node was like Node 4, which was the merger of IOJS and joint Node. There was this question of whether this foundation thing would just bring us back to the way things were before, where it took two years to get from 0.10 to 0.12. Obviously that has not happened. Every IOJS release is considered a proper Node release at this point. So we were at IOJS 1 in January. We also released Node 0.12 in January. We had IOJS 2 in May, IOJS 3 in August, Node 4 in September, and Node 5 in October. During that same period of time, we launched the foundation, developed a new open governance model based on what IOJS had pioneered. There's so much fucking drama, especially around this one thing in this one period. It really masks the fact that the whole time, people were having a very good time. It was actually very fun to work on the software and to build things in the community. It spurred definitely a lot of new contributors, like the core team, whatever, grew. But yeah, I think that's something that I learned later in life. Yeah, it's difficult to set direction also when you have open governance. It's the thing, stories in real life don't start and end. It's like they start midway and they don't end. They keep going. And you could do a sequel of this documentary talking all about the ins and outs of the Node Foundation. I'm sure there's plenty of stories to be told there. The most positive part of this whole story is, despite any of the challenges, despite any of the personal conflict, despite any of the corporate posturing, Node is still strong. It's still doing major releases. It's still making significant changes. It's still shifting its culture. I ran the Node.js Foundation for a few years and joined a long line of people that played some leadership role in Node and then left and handed it off to people who are more interested in solving that problem now. And that's what keeps the project alive. Like all bits of infrastructure, it's hard to measure the impact of these things. But this is some bit of machinery that is operating essentially behind every website. Almost all websites use Node in some respect. It might be a little technical or difficult to put your finger on where exactly this is having an impact. Is it when you're on Notion and you make a comment and it pops up immediately and then there's a little dot, dot, dot when somebody's typing? That's probably going through Node somewhere. So it's very diffuse. What is very rewarding is building something that people are using and that is being built on and hopefully changing the world in some sense. So thousands of developers find jobs across Europe using Honeypot. If you're up for a new challenge in one of these European cities, sign up at Honeypot.io. If you want to see more tech documentaries, then subscribe so you don't miss the next one.