 I'm Michael Rogers. Now I actually work on the Node.js foundation full-time. And I'm going to talk a bit about how open-source has changed over the last decade or so. And some of the stuff that we've done recently in Node in this new modern open-source ecosystem that has really worked. And my hope is that what you take away from this isn't just like, hey, Node's doing really well now, but also a lot of things that you can use in your own projects and use in your open-source communities. Okay, so the first thing that we have to talk about is the fact that open-source won. So... Alright. You know, if I was up here 10 or 15 years ago, I'd be talking about how, you know, open-source is amazing and you can totally convince your boss that it's not going to kill everybody in your building. And, you know, but nowadays, you know, not only is every major company built in some way on open-source and supporting open-source in some way, but also every startup in the world is like this thin layer of code for their application on top of this giant open-source stack. So everything from operating systems and databases and languages and frameworks, all of the base technological innovation for everything that we do is all open-source now. So we've won, like you have to use this stuff. And the world that you live in once you win is quite a bit different than the one that you were working in when you hadn't won yet. And that's why a lot of older people and older generations of open-source and even some of the institutions that are really important to supporting open-source are kind of struggling to catch up and understand what this new world that we won looks like. The other really big thing that happened with GitHub, like, we're still understanding how much GitHub changes the way that we build software and communities. There's a lot of things that it does. It lowers the barrier to entry in general for doing open-source, but I think the biggest thing that they did that nobody's really talking about is that when you take that first step and you contribute to an open-source project on GitHub, you're starting to learn a skill set that is transferable to every other project that you're ever going to engage with in open-source. That didn't exist before. So if you were getting into open-source 15 years ago, like I did, if you went to give a patch into MySQL and then you went to get a patch into Apache, everything that you did to prepare that patch was totally untransferable as a skill. It wasn't just an entirely different community and release process and governance structure. It was also a different source code manager, a different ridiculous fork of bugzilla with their crazy component thing that nobody can figure out. And no project was consistent about this. The only thing that was consistent was that it was always confusing. And it seemed to be built for five people that work on the project a lot and not everybody else. So that's gone. And so what that means is that what we used to do for these big projects is that we would build a bunch of common infrastructure because building the infrastructure was a pain in the ass. You had to host your own source control and issues and whatnot. So it made a lot of sense to centralize a huge amount of effort in these giant projects. And now you don't need to do that. The infrastructure is all there. All the skills are transferable. And so we can create new projects and new communities very, very quickly. There's very little barrier to entry. There's no friction in doing that. And there's no friction for the participants to move around those projects. So to illustrate this a little bit, in 2001, these are the stories of open source. These are the most successful projects in the world. In 2000, Apache had just kind of killed the IIS in terms of market share, which is kind of the first time that that ever happened to Microsoft. So people were really talking about that. And Linux was obviously taking off. And these projects are really big. Apache, I don't know if you know, but it has every feature ever. Like all of them. I mean, it has every feature ever. And then you can just, like, in a config, swap out the entire concurrency model. Like, that's how big that project is. And in that older world of open source, it made a huge amount of sense to do that. Because setting up a new HTTP server or even writing a plugin required that you would, like, go and you'd set up all this crap. And then, like, and then you have to maintain all of that. Like, why don't I just get this feature into Apache, like, the whole server, right? So we built these giant projects that over time became kind of inaccessible. And nowadays, like, these projects are still alive, and they still have contributions. But a lot of that is that they have a big established community, and they also have a huge install base. So a lot of people need to continue to maintain them and get their stuff in. So they're not going away. They're still pretty healthy. But you wouldn't be able to do a project of that size with that much code nowadays. It just wouldn't happen. As soon as you got to a certain size, somebody else would just, you know, fork it and reduce it and turn it all into plugins. But by the same token, now that we're in this smaller project space and people are doing all of these smaller modules and everything is getting tinier, the stories of open source today aren't about projects, they're about ecosystems. And the project that enables that ecosystem just ends up being a proxy for what we want to talk about for the entire ecosystem. Like, when people say that they're into Node, they're not really into Node Core. They're into, like, all of the stuff that they use on top of Node Core, right? They're into this huge ecosystem of stuff that they can do. When people say that they're into Docker, they're not, like, into, you know, the Docker thing that they install and the features that that enables. They're into, like, you know, I can build this image, I can build on top of these other images and these other layers, and there's this big ecosystem in this huge community contributing all of the stuff that I'm not going to have to do myself, which is great. So this is kind of the more common case. And going forward, I think that you're going to see a lot of the same things happen to these projects, to these, like, kind of critical projects that provide the compatibility layer for an ecosystem for a couple obvious reasons that I'll get into soon. But to kind of illustrate my example, this is language ecosystem growth. So the number of libraries for every, all these different languages. And they don't have pretty comparable growth. Like, these languages all seem to have, like, pretty iterative growth. A couple are growing a little faster. A couple have had a longer time to get up there. PHP is actually, like, the only one that's looking, like, really kind of good taking off there in 2013 once they got, like, a better package manager. But then when we add Node to this graph, the whole graph changes. Like, the entire top section comes in. And you realize that while these other ecosystems are growing incrementally, Node's ecosystem is actually growing exponentially. It's ridiculous. Like, we're now not only, like, the number one ecosystem in the world. We're not only, like, the fastest growing ecosystem in the world, but sometime early next year will actually be twice as big as the second biggest ecosystem, Java. And this shows no signs of slowing down. And I'll talk a little bit about why this isn't slowing down when we all thought that it probably wouldn't in a little bit. But having a huge ecosystem doesn't solve all of your problems. You still have this critical compatibility layer, this, like, the thing that actually enables the platform. And it may not have the same incentives as the ecosystem. So while this was happening, the largest ecosystem in the world, this also happened. These are contributions to Core. And you can see that they, you know, they're bits and spurts, but they've been going down for a long time. And they hit a critical point coming into 2014 where it literally drops off a cliff. I mean, it's, like, coming into 2015 there, it's going to zero. Like, nobody is working on the actual Core. And that's a huge problem because it wasn't done. And it had bugs and huge problems. And the other result of this that's far more striking is actually the number of releases. So the number of releases of Core drops dramatically. And there was really no way to pick it up in that project. And there's a huge amount of reasons for this. But the big thing to note is that in the ecosystem, it's really easy to create a new project and to get involved. And the slightest bit of friction in getting involved in this Core project, even though it's very important, was killing it off over time. So we can start to trace a lot of why it had these deficiencies to actually the things that made us popular when we started growing. And if you look at any big project, and especially languages, when they start to become popular, they build a culture and a community. And all of the things that are helping them win really define the people that show up and the people that stick around. And then literally the things that made them successful end up hurting them down the road. And that culture has a really hard time changing. So we're going to look at what was going on in Node in 2010 and then in 2014 when we started to have all these problems. So small, corner, large ecosystem. Huge advantage. There's no question that we would have ever been able to be successful without that. We don't have a giant standard library. This isn't Python. We just want to keep it as small as possible and then let this ecosystem flourish. So that also meant that as this giant community is growing, they're not actually trying to get modules in the core. They don't really have any reason to work on core. So this huge community that's growing over time isn't focused on core at all. We also have autonomy in the ecosystem. So each one of these little components can be published without getting anybody's permission. You can start it without anybody's permission. There's a lot of freedom there. But that means that the barriers to entry and contributing to core where you can break this huge ecosystem and it's just slightly harder to get involved in general and you don't get to own the project right away become really big barriers to growing that core contingency. Also, in 2010, foundation was kind of a bad word. And I'm as guilty for that as anybody. But I think really what we were feeling at the time was that foundations had been set up around these older open source models and their governance structures were really baked around some of the tools and processes that they used and as GitHub started to take off and we started to build these huge new communities, foundations were sort of like the antithesis of what we were doing. They were trying to get everybody to move to these older models of participation and we were trying to create new ones. So we felt at the time like it was this huge advantage that we didn't have institutional backing. We weren't inside of a foundation. The community could just own this thing. So it turns out that an abstract idea like a community can't own property legally. It turns out that like when you think that a community owns something, actually a single person owns it or a company owns it. And it really took until 2014 where that started to sink in where we would like to change some of these policies. We would like to change the way the project works and the governance structure and the people who work on this are not actually enabled to do that because this company controls it. Also, when projects get to this size and big companies start to rely on them, even if you aren't getting a lot of contributors, those companies will just kind of throw resources into it, usually, unless the project happens to be owned by a single company that they're a little bit freaked out about, right? That might be a competitor or might not be a competitor. So they won't throw those resources in if it's controlled by this single company. One of the reasons why you're seeing all these new foundations start up around Docker and Kubernetes and all these technologies is that there's just a ceiling that you hit when you're growing where the people who want to adopt you won't adopt you if you're owned by this one company or this one person. They need to know that there's an independent entity that they can invest in that actually owns this over the long term. I did that too. I hate that. That's not a feature. Why do they do that? In 2010, we were like, JavaScript is done. None of this other stuff is ever going to happen. These guys are going to duke it out in standards bodies forever and it's just going to be ES4 all over again and Crockford is just going to put his foot down and be like, you shall not pass. But at the time, this is actually really freeing because we got to just build a platform. We didn't need to argue about a language. We didn't think that any of our problems could be solved with a language, so we had to solve them ourselves. We had to implement a binary type before the browser really had a binary type because we really needed that and we couldn't wait around for it. That was a huge advantage then. But it turns out that actually the language isn't done. People are working on it. They're making changes to it. And we're not involved in that process at all because when we were building up our core community, nobody who wanted to talk about a language showed up because we weren't doing that. And now we're really on the outside looking in on new features and a lot of them affect us pretty dramatically. They affect node really dramatically and we need to get involved in this process. So what we're really looking at is a list of competencies that we built and then the things that were excluded from our community as a competency because we built these other competencies instead. So what we needed to do was find a way to go and build new competencies into our community and into our project. So for a lot of reasons, we ended up forking. We did this IOJS thing and we focused very specifically on only building up the competencies that we were lacking. So the advantage that a fork has is you take all the code with you, right? And in this case, we actually took pretty much all the contributors too. So we basically had all the competencies or most of them that node had. We didn't have the install base so we couldn't do things like, you know, fix bugs in older releases or dedicate to LTS support and these things that people really do want, we couldn't solve those because we were this new fork but that freed us up to focus on building new competencies and to building a project that really specifically tried to bring in new contributors and invigorate a newer community around it. So the first thing that we did was we took on this liberal contribution policy. This is a lot of work that was pioneered by Rod Vagg in a couple projects that he did but the basic premise is that when somebody shows up and they write a piece of code, it's not like just a one-line doc change or something. It's like a decent thing of code. You just add them as a committer. And this sounds really scary to a lot of people but what it actually is is just our policies catching up with our tools. So a lot of the guards, like the weird structures that you have around like who is a committer and who is not a committer is because there's this huge amount of trust involved in being a committer and that's because if you ever worked on like a CVS repository or a subversion repository and somebody did something slightly wrong, it fucked up your whole week and everybody else who worked on that project whole week and it took forever to unfuck that repo. It was terrible. You can't do that to Git. Like you can't fuck up a Git repo. There's nothing that you can't undo in a Git repo. This is by design, right? But we still have these older ideas about commit rights and commit access and write access and we're just kind of catching up with them now. So you just add them, right? You're not allowing them to release necessarily. The release process might still be a little bit guarded, right? But why not just give them commit access? And it turns out that when you do that, when you show a little bit more trust in people, they actually engage a lot more and they stick around a lot more and you build a lot stronger of a community. Another thing that we did was we went to a consensus seeking model for governance. So consensus is like everybody has to agree on something. That model is bullshit. The reason that that model is bullshit is because it incentivizes not doing something. If to do something everybody has to agree, then it only takes one person for it not to happen. And there's actually no incentive for that person to convince the rest of the group that they're right and that we shouldn't do this. They just get a veto. That's what a consensus system really is. It's everybody gets a veto on every decision. And in an open source project where you want to be effective, you can incentivize that kind of behavior. So consensus seeking is that we try to reach a consensus, but if we can't, we will vote. And a vote is kind of just the ultimate tiebreaker. And it's always there as a threat. So the interesting thing about this model is that we've never had to call for a vote. The reason we never had to call for a vote is because if I don't agree with you, but I'm not willing to put in the time to try and convince everybody else, it's pointless. Like, why would I even waste my time? So what ends up happening is that when a tough decision needs to be made, the people that are invested in that decision and know about it, get involved, they try to convince each other, they end up at like a pretty good solution and everybody else pretty much just accepts it. And nobody's incentivized to just step in and go, I don't want to do this. Okay. The other thing we did, so we don't want to load up people working on the project with a huge amount of process. Like, I don't know how many projects you've been involved in, but I've been involved in like a dramatic range of open source projects. And the ones that have a huge amount of process around getting anything done are painful. And they don't grow new contributor bases the way that they should. And it just, it really starts to feel icky. So we didn't want this consensus seeking to create some really formalized process that then everybody had to adhere to and it was very hard to get code in. So basically what we do is we err on the side of changes happening. So somebody sends a PR and people review it. And as soon as somebody is like, yeah, this is ready to go in, if nobody objects for a long enough time that all the time zones could object, then that just goes in. And so all this code is going in all of the time and the TSC, this sort of like, which is basically just like 15 people right now who are heavily invested in Node, really know a lot of the code, and we act as like a tiebreaker if something contentious comes up. But the default is for code to just make it in. Like it should go in, all of the committers, there's like 40 of them now, can all put in code, it's great. But when somebody does object, when there is some kind of contentious issue, that escalates to the TSC and then the TSC talks about it, tries to reach consensus, usually does pretty quickly. And then we move along. So we're just trying to keep the process moving. We're trying to keep changes happening, keep work going on. It's not designed as a giant system of safeguards that just like kick people out of wanting to be involved. All right, frequent loses, as often as we possibly can. This is kind of self-explanatory. But yeah, this was a big problem prior. So this was really important to note that we wanted to get releases out really often. We implemented a code of conduct. For some reason we couldn't get one in and we didn't have the project, so we implemented that because that's the same thing to do. And we have this autonomous working group model. I'll talk about that a little bit more, but essentially we have a bunch of sub-projects inside of core that are all essentially independent. At some point we reconciled the projects together. We merged them back. And you saw this happen as well with the kind of core OS Docker thing. And you're seeing this in a lot of the forks or alternatives that come up. And this is actually the best possible outcome. Because what you end up doing is you build all of these new competencies in this other community. And then you merge it with the original community that had all the other side of all of those competencies. It's actually a really good way to continue to build competencies into your community. But you have to keep the door open to reconciling, which is really hard to do. You have to have a lot of different kind of boxing matches and cover them that way because they like drama. But anyway, Joyant created the Node.js foundation and said they're going to put all of their Node property basically into the foundation. So that was great. So immediately we could start working with Joyant and with the foundation to possibly merge back together with an existing foundation, they would have had a governance structure that they would have needed to impose on the project. And we had just built a new one designed to solve all these problems. We couldn't just take somebody else's off-the-shelf governance model. So that was really important. At this point I got involved, Bert got involved, a few other people from IOJS and we worked with the foundation to build a new governance model for the foundation. I don't know if you've ever had to start a foundation to just keep the lights on, to just keep everything moving. And it takes actually a lot of money to do that as well. Accounting services for specialized things like foundations and open source projects are kind of expensive. So you need to have fundraising, you need to have all of this infrastructure kind of stood up just to keep the entity alive. And in America you also have really, really tough tax laws that you have to comply with. So it's all very specialized. But we wanted to make sure that the people that were running the foundation could run the foundation under the best governance model for them and the project could remain under the governance model that we had more or less built in IOJS. So we ended up doing what we said, okay, foundation has a governance model, the project has a governance model, and there's a wall in between them where the community and the contributors own the project and that process. And essentially the people who end up funding the foundation can keep the lights on and do all of the things that we put in it doing than programmers are. Programmers are pretty bad at accounting. We also got long-term support. People have wanted a dedication to long-term support and to know how long a particular version of Node will be supported and we finally get that because, one, we have the Node project and all of the old release lines that we can now properly do releases for and we have all the contributors from IOJS to Bear, which is amazing. When we reconciled, we had a little over 40 core contributors as well. So Node.js at its peak had seven core contributors. So we were already more than four times that. We also have 360 GitHub members and those are people that work in some working group of some kind. And I'll get to a second how that's actually representative of all of CORE and of the CORE project because we've broken so many things off of CORE into these working groups. So these are the working groups that I could remember basically that are going on right now inside of IOJS. We found this really great model for what we think can be continuous building of core competencies. So as soon as something is clearly not being well done in CORE itself by like the TSC and in this tiny little GitHub repo we go okay, let's break that off. We're going to say the responsibility for this now entirely lies in this other group of people and they don't work for the TSC. This isn't like a hierarchy. They are autonomous. They get to control their own destiny. They can build their own processes. And what that does is it turns these working groups into its own little community with its own little incentives. So you would try to get code through the group of CORE committers that do low level networking shit. That sucked. Just getting it in. And then what would happen is one person who is good at building websites would end up doing all of this work because they can deal with the process. But they are really undervalued. They are not very valued for the great work that they do on the website because the people who work on CORE are into other things. It's not their competency. They don't really understand it. So you're not going to get new contributors to show up because new contributors want to see that their skills are valued and that their opinion matters and things like that and they're trying to work inside of the structure where the incentives just aren't there. So what these really are in a way are like tiny little forks of node. We're basically taking little pieces of node forking them off into like their own community and saying, you deal with this. It's awesome. Thank you. And it's working incredibly well. I mean, some working groups are going better than others. Some are brand new. Some are like thriving. But that 360 number is really the number of contributors to node as a CORE project now. Which is so many more than we used to have or could even imagine contributing to a single project. So this has been hugely important. But we want to extend this. So part of node success and why that exponential growth curve is still happening is that node is a really good platform to build new platforms on. That's way too fucking meta. So if you look at NPM and all the modules in NPM what you can pull out are these little sub-ecosystems. So these other really critical projects that enable another set of plugins or another set of modules. And the reason that the exponential growth is staying is that more and more of these start stacking on top of each other and then they have a growth curve and they level off. But when you put all of them together you get this giant exponential growth curve. So just as an example let's look at Gulp and Grunt. So these two tools essentially go after some of the same tasks. They're just for front-end tools to get your front-end tool chain knocked out. And these have been hugely successful. They have been using tons of people use these. They have a lot more engagement than a typical node project because the barrier to entry for working out front-end stuff is just a bit lower. And interestingly if you put these ecosystems like the Grunt and Gulp ecosystems next to entire programming languages they're doing pretty well. So Grunt has a couple hundred more modules for it than all of closure. That middle graphic is for Haskell. Haskell has a different kind of grad graphic. I don't know what any of that means but it's probably a crazy Haskell math or whatever but something with monads. But we have considerably more modules just than Grunt. Gulp, which is the smaller ecosystem it's about half the size of Grunt is still more modules than all of R. And R has the worst logo. Did they rip that off a GeoCities page? That's ridiculous. It's your shit together, R. But what we're noticing is that as node becomes a place for sub-platforms for sub-ecosystems those projects end up having a lot of the same problems that we had in node. They grow to a certain size and then they can't really handle it they need to encourage participation but it's too hard to get involved. And when you think about them as being basically the size of small programming languages this is a pretty serious problem. They're not really going to be able to set up their own foundation and all of their own infrastructure. So what we want to do is create an umbrella inside of the foundation for these projects where we can take a lot of what we've learned in the node projects and help grow these communities and give them a solid place to be. This isn't the official logo for the umbrella this is just the first umbrella image that came on GitHub or Google Images. I'm sure that when we want a logo we'll create an issue on GitHub and we'll say send us your logos and thousands of people will send crazy ass logos and that was fun. So part of this process of creating this umbrella is that we've had to look back at what's happened with node.io.js over the last six months and really start to distill down some core values. So if there's one thing that we know it's that we're not done iterating on our own processes yet. We know that we don't have a perfect process. Every working group has a slightly different process. Some of them work well. Some of them don't. We try to share that and iterate as a group. So we can't do what Apache does and what a lot of other like big foundations do where they just impose a process that says that at the end of the day you'll hit these values. Instead what we have to do is go back and go what are the core values? What do we think it means to be a successful project inside of this foundation and then evaluate how well the policies and processes that these projects implement are working towards that goal? So the first one is that we think the project should be participatory. We don't think that we're kind of done with BDFLs. We're kind of done with closed off decision making. We think that a good project is one where people fucking participate. Where not only are people participating actively but also you're going out and trying to get more participation. You're trying to be representative of the larger community. We also think the project should be transparent. Transparency isn't just about a decision being public. A decision ends up in code and the code is public. That's not good enough. You need to be able to take the decisions that led to that piece of code the discussion around a decision finally coming to it and trace that code back through that decision process. Otherwise one can never participate in it because they don't understand it, they've never seen it and also it starts to violate people's trust. They start to believe that there's some kind of cabal of people somewhere that make decisions that they're never going to be a part of. So by making things transparent you get around that and you get a lot more credibility. And finally we think the project needs to be effective. A lot of policies and processes that you put in place will make you better at achieving some kind of goal but also leave you much less effective. And also we want new innovation in process. I mean, we're still building tools that help us build all of this stuff. We're still building tools on top of GitHub because it's still adding features. We want to be able to continuously iterate on our processes and the kind of guiding principle is that iterating on them will make us more effective and that a newer, better effective policy is actually valuable and we should actually adopt it rather than just going oh no, we figured this out, we're never changing. And finally, I think as a cultural thing, we need to be nice. We need to be like a really inviting community. This has been really important to stay one in node, like we really give a shit about this. But being nice isn't just about being positive, it's also about ejecting people that are disruptive and ejecting people that are just there to be an asshole. And the reason you have to do that is that there's a much smaller number of people that are very nice, that are very pleasant people that have a tolerance for assholes. And to get the larger Venn Diagram of nice people, you have to eject the assholes. And then you get a much bigger community and you get a community that basically perpetuates positivity. And the moment that I turned this into a Venn Diagram, it became science. So now you can't even like, this is the data now. All right. And finally, I think we, you need a neutral body. At some point, you're going to reach a breaking point with not having a neutral body or institution to carry the property and setting that up is really, really difficult. I just went through this, I know exactly how hard it is. I don't want a bunch of other projects to have to go through that all over again. So we hope that we can share what we've built with a broader community and we're working on a lifecycle document and a process for bringing these projects in. And also a lot of what we've learned we've tried to just be very public about. So we write about it on our, we try to blog about it, we try to do talks like this about it so that even if you don't come into the foundation and you don't come under an umbrella, you can take a lot of what we've learned about running software projects in open source. So that's about it, but just as a nice little thing that happened today, the first release candidate of Node v4 is up which is the first converse release of all of IOJS and NodeJS. So go to that Earl and please test that. I'm just wondering, there's probably a lot of people in the Node community that they want to participate and maybe they're confident that the active participants will be welcoming, but what if they don't know how to participate or what if they're not sure what they can offer? What would your advice be? So I think that one of the things that we're trying to do with the working groups and we haven't promoted them well enough, right? Think about getting involved in Node, you go to core and then you're like just terrified, right? But we really want people to get involved in working groups first because if you just look at that list one of them is just going to appeal to your skill set, right? Like you're just going to go, I know how to do stuff like that. And we've actually already seen somebody literally come in to the website working group and then get involved in core and then move on to the TSC in the governing body within a matter of a couple months. So I think that once you're involved in a single working group it becomes a lot more accessible to jump around to other working groups eventually into core and we really think that that's a good funnel for getting people that for one thing, it's not as hard to contribute to core as you think. Like anybody can learn it if you really want to put in the time but it is kind of terrifying and part of the thing that's terrifying isn't just the code part, it's also the culture part. So with the working groups we can take the code part out, it's freaking you out and you just kind of acclimate to the culture and then when you understand the culture is not very scary then you're not you're not fearing the code part as much. That's what I'm saying about that. And we're working on the new website right now where we're going to try to promote the working groups a lot more. Awesome. There's a hardware working group that you should be in. I'm already in it.