Open Source Community Organizing

Speaker 1: Tell us about that community and some of the work that he's doing. Michael Rogers.

Speaker 2: Yeah, I was actually at the first Django Con uh and saw that talk, which was like it's but why Python sucks, I think it was. It was great. Um So I'm I'm not gonna be that good, I'm sorry. Um so yeah, I'm gonna talk about uh some like building new open source communities um and also uh how to turn them around. Uh to some extent, mostly from my own experience, um, but a lot of the stories and a lot of the the things that we've done and that we've learned are it's pretty universal. Um and apologies in advance for the number of bullet points in I I go back to a lot of things that I say previously, so the best way to do that is to kind of have recurring bullet points, but it does look a little bit like a sales rep 's PowerPoint deck. So I'm sorry about that. Okay. So in 2009, uh I actually wrote Python. Uh I had been writing Python for

Speaker 2: about 10 years off and on, but for five years like a lot. Um And it was really my language of choice. And then at some point in 2009, I literally flipped a table on Python and I was like, I'm never writing this again. It wasn't like a gradual thing. It was I Node had just gotten publicly released. I wrote one application in it on Saturday, and then I never wrote Python again. It was really, really dramatic. And I was employed to write Python at the time, so that was a little bit of a thing. So uh I I so there were a lot of things there were a lot of reasons why I stopped writing Python um and and moved to this new community. And I'm gonna talk about them not to like point at Python and be like you suck at d But um to give you like an idea of my headspace at the time, uh because

Speaker 2: why people go to a community and create a new one has a lot to do with their experience leaving the last one, uh both good and bad. So uh Python sucked at concurrency real bad. Um there like real real bad uh and there was really no solution to it. I mean I'd I'd written twisted, I'd written async core stuff, I'd written use the stackless stuff. And especially what what I was doing at the time was I was uh building test tools for Mozilla. Um and so we would like launch the browser and then a bunch of things would be happening in the browser. We had like this RPC layer back and forth where I could kind of tell it to do things. And so I had to to run these like, you know, synchronous lists of tasks from Python over this RPC bridge and then get events out of Python and then process them basically asynchronously. It was really, really bad. It was probably the worst thing that you could possibly do with Python.

Speaker 2: Python at the time. So I was souring quite a bit. Uh VM performance was really, really bad. Like um uh compared to other languages and other VMs at the time. Um When I started writing Node, even within a few weeks, I realized how much performance is a feature. Because when you when you have that great of performance, you just start doing stuff that you never would have done before and you start on tasks and programs that you never would have written before. written before. And this was really probably the biggest one for me was that the ecosystem was really fractured. So it wasn't just that, you know, things for Twisted don't work anywhere but twisted and things like that. like in some of these other frameworks that work anywhere else. It was also that uh when you take one module and then you take another one and you and you just start fitting them together and gluing them together, it was really non-obvious

Speaker 2: what the usage was and how it was to to do that. For a community that is so into code styles and standards and being so restrict about the language, there's actually a a really wide uh infuriating diversity of usage. uh of each module. So when when you publish something in Python, it's really not that obvious and how to use it. And I was finding that to be increasingly uh complex. So No. No programs are written in it yet. There's no ecosystem yet. But I went to it anyway for a couple reasons. One was that it it was invented by default, right? So it was async and invented by default. There was no ecosystem yet, but it was going to be all async. Uh there was not going to be like the split between things that were done synchronously and things that were done asynchronously. This also meant that concurrency was just really, really good. Good by default.

Speaker 2: Crazy fast VM. So browsers have been competing with each other and leapfrogging each other in performance for about five years at this point. And the the VM performance was really insane. Um compared to like every other platform now, even compared to like Java. Um so that was a huge win. It also stopped when you hit control C. Stopping a Python process is crazy blackmagic voodoo that I spent years trying to perfect in all of my programs and could never quite get to work right. And uh I can't tell you how great it was writing that first program, and every time I would run it and stop it, it would just stop. It's phenomenal. So uh there's also a new ecosystem, right? So this this is terrible when you're when you want to sit down and just write a website because nobody's written anything yet you can't use

Speaker 2: any of this code that's been building up over time. But it is a really great opportunity, right? So I took it as a as an opportunity to go after newer universal compatibility patterns. So we started to define things in the node community. Some of it was like pretty much enforced by the by the platform. Some of it was just like a best practice. And those ended up shrinking the usages that you would have over different modules and really improve the compatibility between two modules. So note if you go through the ecosystem, I mean now there's, you know uh 160,000 modules. But um for having an ecosystem that size, it is very surprising how many of those modules have almost identical usage. They're very, very simple. And they use a lot of the same underlying competitiveness. ability patterns. Also in 2009, we really were like, oh the language is done.

Speaker 2: So we don't have to have a conversation about the language. We can't look to the language to solve any problem. We actually are going to build a platform and an ecosystem and we're going to solve all of our problems there. Because in 2009 , ECMA working on the next version of JavaScript was just totally ineffectual. Like they had spent all of this time working on a new standard only to kill it off because they decided that it wasn't worth it. And then they were basically starting the whole process over again, making no progress, just yelling at each other. each other. So in 2009 we were like, okay, great, like they can keep yelling and then we can like you know just innovate on our own over here. So Node had a really small core and and maintains a small core today. Compared to other platforms, it's actually I think the smallest of any platform that you could ever compare it to. The standard library is a

Speaker 2: handful of modules. We don't take modules from the ecosystem and put them in them in the standard library. We don't really grow the standard library at all. And what the platform exposes is really, really minimal. So this led to a very autonomous ecosystem. So a lot of people wrote modules and those modules are governed completely outside of the core project. And that leads to a lot more growth because people like to own things, they like to start new things, they like to build these little communities. communities. And the less that you get in the way, the better. Also, not having anything in core by default meant that you were going to use modules. Like nobody is going to write an application without pulling in modules from MP. Once that becomes the standard, once nobody writes an application without that, now modules are like taken for granted. It's really nice. The other, and

Speaker 2: this was a huge advantage that we didn't really realize until later, but Node was the first platform built in the post-GitHub era. And what I mean by that is that, you know, it It it was built on GitHub. Every module since then has just used GitHub by default, right? Like 99. 9 % of all of the modules in in NPM uh are are hosted on GitHub. This is really great when you're building a community because there's a whole skill set on top of knowing the language that you need to figure out to contribute to a project project. And when all of them share the same skill set for contributing to every single project, you dramatically lower the barrier to entry for people collaborating on each other's projects. So this this was this was huge and led to a lot of success. It also meant that having a small core meant less focus on core and a lot of leaders in the community sprouting out not from core.

Speaker 2: To work on like a like an actual plot like low-level platform or VM or anything like that, you have to have a really specific background and skill set. And um but as communities we tend to build into these hierarchies and then we look to the top for some kind of leadership and pull from there probably too often. So in Node, the vast majority of leaders came from outside of core. And that that led to like an explosion in community-driven conferences. Like there's more JavaScript conferences than maybe all other languages combined. It's ridiculous. You could go to one every week and you'd still miss half of them. It's absurd. And we also, at the time, this felt like a positive that we didn't have an institution institutional support. So in 2009, foundation was almost like a dirty word. Like there wasn't a good one around open source software. Like Apache was was basically a place where they'd like imposed these really draconian rules on how you had

Speaker 2: to run your project. Um all of the standards bodies were were just deadlocked at the time, like really dramatically. And so we really felt like, oh, we're a pure community project. We don't have like the this these like arguments and all of this politics and all of this bickering, like at the institutional level, we're just off on our own and we're, you know, a more kind of pure community. Um okay, so uh building a nice community that is like nice and inviting is really deliberate. It doesn't happen uh by accident. And uh myself and and Isaac Schluter really knew that in the early days and we have a lot of discussions about how do we build a nice community like Django instead of whatever's going on in Rails right now. Especially in 2009-2010, it was really bad.

Speaker 2: And and there 's a lot of things about the Rose community that is gre that are great, like they're very creative, um, but they're they're not known for being the most inviting place and the nicest place, especially back then. Um And so we're kind of trying to figure out, well, how do you build a nicer community? What what are like, is there any kind of trick here? Like what 's the deal? And um I r I remember really distinctly kind of figuring it out in this uh There's this old panel that Adrian is on with DHH called like Snakes and Rubies. Yeah, yeah. It's like eight years old. But but in this panel, DHH lays out the key to to promoting your open source project. And the key to promoting your open source project is to figure out the thing that everybody's using. So for him at the time, I think it was like spring uh Java stuff. And just say they're all fucking idiots.

Speaker 2: and that all their code sucks and it's terrible and that your thing is great. And then you'll get a bunch of people from that, right? So maybe that's a great way to promote your project, but it builds a terrible community. Because like because you end up attracting people that don't mind assholes. Like they have a really hot like low barrier for assholes because you attracted them by being an asshole. So uh so we figured that out really early and I made this Venn diagram because everything is more true when you make a Venn diagram out of it. Like the moment that this came up, it became science. Um so So basically like like there's a whole lot of nice people out there that just won't deal with assholes, right? And there's a bunch of nice people that will tolerate assholes and it doesn't make them any less nice But if you want to get all of these extra nice people, you actually have to get rid of like really disruptive abusive people.

Speaker 2: Um so you have to come up with prop processes that are basically exclusionary. They exclude people that want to indulge in this kind of behavior. So really early on we started to build uh at first it was uh to govern an IRC and then the mailing list and then anything that was in the community that we had control over, we started to create these different policies. And what they really are is prototypes for what we now have in in codes of conduct. But at the time I think they were just like rules or something or like admin rules or whatever. And out of that, out of enforcing those, we immediately started to attract people that were transgender, that like like a lot more women and and not only were those people showing up, but they they would report somebody and then after they reported somebody twice, we're like, you know what, you have ops now. Like we yeah, go for it. And so and then we ended up growing like a lot of leaders in the community that came out of that whole

Speaker 2: process. And as soon as like people saw that we were doing this and we were kicking those people out, we immediately got more more diversity as a result. And a lot more nice people showed up. Like it's still a real really nice place. Um so what what effect did this have on growing our community? So this is the growth of open source ecosystems without Node in it. And they're relatively comparable. Like some are obviously bigger than others, some are growing a little bit faster than others. And others, but they're they're somewhat comparable. But when you add note, it's ridiculous. Like we're we're nearing just going straight up pretty soon. Um and when you start to drill into what those modules are and where our growth is today. And then I've actually done this where you then go and figure out where those modules are in GitHub and figure out how many people engage with them. Which is uh like you know how many people are logging issues and that kind of stuff.

Speaker 2: stuff, which you can you can sort of suss out like the number of users. Our highest growth areas now actually represent more users than our old growth areas. growth areas. So this isn't even actually how big we're growing in terms of usage. This is just how much we're growing in terms of modules. Um but if you've been following node stuff, uh you know that not everything W has been great. Um so this is Node Core. Um and in so it it peaks in terms of uh contributions in 2020. Uh but in 2014 uh it starts a precipitous decline to zero. Um that's not okay. Um these are major releases per year. Um and with no contributors, it turns out you can't really do very many releases.

Speaker 2: And that starts to plummet into 2014 as well. And uh we we at this time we literally are the largest and fastest growing ec system in open source and core is about to die. So how how does that happen? Okay, so let's come back to Python for a minute. So We're gonna compare the world uh in 1999, which is when uh Python really first started to take off. And if you look at a lot of the people that sort of started to establish the culture around Python , Python and core, they started to come around that time. This is also around the time that I started playing with Python. Um then 2009 is just the end of my historical narrative for Python. I don't know what happened after that. So um so that's what that's why that ends there. But I do know what the world looked like in 2009.

Speaker 2: Okay, so in in 1999, Pearl is ridiculously big. Like um and it's growing ridiculously fast. O'Reilly makes so much money selling how to write Pearl books that he just starts parrying parrying paying Larry Wall to work on Pearl full-time with no guidance whatsoever And that ends really badly if you know the history of Pearl, but like it just seemed totally feasible, right? Like just do that. Um But you have a lot of people, like and I started to have this problem as well in in 1999 Um you can't read your Perl code when you go back to it. Uh after a day, a week, a month, or whatever, you can't read other people's Perl code. It's just too expressive. And so the problems that that we're running into as programmers actually has to do with the expressiveness of language being too crazy.

Speaker 2: And this is what drives a lot of people to Python. It's certainly what drove me to Python. Which, oh sorry. Go back. So that means that like Python grows a core and a culture that has a great competency at building a language and writing a language. Writing a very understandable language, a very precise language. Like it is a very clean, concise language. It's very good at that. And one of the reasons why it's so good at that is that l that's what attracted people to it. That's where it built a lot of its competencies. But in 2009 that actually meant like making that fracturing problem significantly worse by revving the language to make print a function and break everything. And like and I mean like to a lot of people that totally made sense. To me it it seemed like just period. insanity. But you you can see how

Speaker 2: like why the culture would move in that direction and why like the the world of 2009 just doesn't look like 1999. Um but that still seems like a good choice because you don't change your culture overnight. So also in 1999, Apache HTTP is like the story of open source. So Linux is definitely a story, but Apache HTTPD is the thing that most people are talking about. in 1999 because this is in the the first web bubble, right? And so everybody's talking about the web. And in particular, they're talking about how Microsoft kind of missed the web. And the one of the things that they had that actually did make some money was the server IIS, which was did pretty well in the early days, but by 1999 had just been destroyed by Apache HTTP. It was really the first time that Microsoft got walloped, like, I mean, to to the tune of like 70% of the market was owned by Apache and they owned like 10.

Speaker 2: Like, and that just hadn't happened in software. Like Microsoft dominated software. um crazy that this open source thing just took off. So what this means is that in 1999, uh if you have a language that people want to write back-end applications in, you don't really worry about concurrency. Apache HTTP has like amazing contributors and amazing track record of dealing with concurrency. So if you're PHP or your Perl or your Python, you just sort of like hook into this thing that does all the concurrency for you and then you just like go off and do your application stuff and you get this nice separate of concerns. So you so what what happens is that you know most of those languages don't build a lot of competency around concurrency. It's not a priority for those languages. communities and those cultures. In 2009 this starts to become a problem, but gets really bad in 2010 because

Speaker 2: real-time applications start to take off. Um and for real-time applications, the application server actually does need to be pretty good at concurrency because you're not as stateless as you used to be. Um and it it's not that you necessarily like want to go off and write your own servers and replace It's just that your applications are a lot simpler if you can, and if you can hold state around. So you know all of the early real-time uh apps thank you all like all of the early real-time apps that you see that were demoed were like in Node or like one of these like crazy Java dialects that were really good at concurrency. Because it was just much, much easier. Um okay, so obviously we still have Moore's Law in 2009. But in 1999, this literally meant that like you valued a computer and bought it based on the number of megahertz that it had, right? Like in 98 the iMac

Speaker 2: came out and like some hippies and artists bought it and really nobody else. Like Macs weren't a thing. They were still like telling Steve to like shut down the whole company. Like you bought a computer based on its megahertz. So think about if if you're a VMM and you're thinking about things to do with in the VM. This is the worst time in history to be thinking about making VM optimizations. Because you're gonna sit down for a year and you're gonna optimize some code 30 or 40%. And in that year all the computers just got twice as fast. It's just stupid. Like, why would you do that? So no competency really gets built in most languages around VM optimizations at that time because because it's just unnecessary. Like you can go back through most of these VMs back then and see people trying to send optimizations and them getting rejected based on the fact that it obfuscates the code a bit or that it makes it more difficult to reason about.

Speaker 2: That's like the definition of an optimization. But it's just not worth it, right? It's it's better to keep the code clean because all the computers are getting faster. Um so i in in 2009 this means that like you still have a really slow VM and megahertz are not going up anymore. Like they're they're not. And in fact, like your concurrency needs are are getting greater, right? So you can run a process per core now because we are getting more cores, but this just this just isn't gonna keep up. It's not going to do it anymore. And so a lot of the languages that start to take off and platforms that take off in 2009 have really fast VMs or have a really clear path to having a fast VM. Okay, so that explains like a lot of the reasons why this this the situation existed in Python that made me leave, but not that's probably not everybody else's priority. list. But so let's let's like apply this to NodeNow. Okay, so

Speaker 2: in 2010 we're we actually really start to take off. Like I showed up in 2009 because I'm crazy, but we actually got like people that aren't out of their mind. mind to to start using Node in 2010. Um and uh in 2014 we started we had a really clear problem. So having this small core was you know, we already talked about like why that was a huge thing, a huge value, and a big boon to our success in two thousand nine. But this meant there was no community focus on core. Like when when when all of those commits went to zero and we stopped doing remote releases, I noticed, a couple of the people close to core noticed, most of the community didn't notice. It was actually it was it was so ridiculous that for the The six months we were trying to negotiate and figure out a way to fix this with joint, and the rest of the community literally hadn't even figured out that it was a problem yet. Like people weren't even really talking about it.

Speaker 2: The only reason that people started talking about it was that V8 started taking on new language features. And then they were like, oh when are those gonna land in V8? How old is the V8 that we have? And it's two and a half years old. is the answer to that. So an autonomous ecosystem. Really, really good for growing an early ecosystem. It also means that we don't really care that there are huge barriers to entry to core contributions. Because all the work is happening in the ecosystem. Who gives a shit? Um no institutional backing. It's a pure community project. We run it, we're the community. Well, actually the The thing about property is that it has to be owned by an institution or an individual. Um so in this case, a company actually owns the copyright. They're like it's in their GitHub org. Um they do

Speaker 2: they have the release keys. They own own the domain. We didn't think those things really mattered. Uh you you didn't really like go around selling open source trademarks or like everything everything weird that people were doing, that companies were doing trying to own open source projects had to deal with weird copyright deals, right? And we didn't have those. But this ended up being a huge problem because now the community wanted to change the project and move it in this other direction and change some of the contribution policies. We had to negotiate with this company that we did not have a very good relationship with. So the language is done. It's done. Except it's not. So it turns out ECMA actually does put out a spec and people People care and they start wanting features and using it. And the node community has zero collaboration with um with the language community on those standards. Uh so I mean literally like you know they wrote a module spec without input from

Speaker 2: Anybody who'd written modules in the node ecosystem. So we have a great diversity of leadership in the community, but we had homogenous leadership in core, and we never really got around to fixing it because it was always easier to bring diversity into the ecosystem and into the rest of the community than it was in the core. Okay, so for a lot of reasons that I won't get into, the way that we ended up having to solve this problem was to fork core. Which is difficult because this is the most successful project in in modern open source. But luckily we had, you know, very Virtually every contributor come on board. It's really hard to change a culture. It's really hard to steer a ship in another direction. There's actually some really big advantages in this case to us doing a fork. Because we got to re-establish some of these uh cultural norms intentionally to fix some of these problems.

Speaker 2: And we and we weren't just tied to how the world was when we all happened to come to the project. So one was that we created a very liberal contribution policy. It's based on work that was actually pioneered in our own ecosystem, but um basically if you send a a patch of any note to to IOJS or now to Node. js, um you will become a contributor. Like you will become a committer, you'll get a commit. But Git makes it really easy to to fix mistakes. So you don't really need to guard the the gates to getting code in. You just need to come up with a good policy for reviewing it. Those contributions are in a consensus seeking model, so not pure consensus, consensus seeking. So you try to reach an agreement with everybody, but if it's contentious then you have the threat of a vote, basically. And the threat of a vote is enough to basically get rid of obstructionism because there's no value in just saying no if you're not trying to convince your peers.

Speaker 2: We escalate this contentious issue to TSC, which is sort of like a like a technical body of people that have been around for a while that know a lot of the code really well. We do very frequent leases because it doesn't matter how much uh great work that you do if nobody knows about it or uses it. And it turns out that like a big incentive to people doing things is that it gets We adopted a code of conduct. It's insane that we pioneered so much of this code of conduct stuff and we were not allowed to put one on the main project because of lawyers at a company. So immediately we put one on our project and of course it still has that one today. And we this was the the really big one that really made us successful. Was these autonomous working groups. So we liked that autonomy of the uh in the ecosystem, and we thought that it like really encouraged people to participate.

Speaker 2: So rather than having this like a hierarchical project where everybody sort of like reports to the TSC , reports to core, we broke every part of core that we can logically into these autonomous working groups. And once they're broken out, they have their own governance, they make their own decisions. They're They're not like subjects of the main project. And that really encouraged people. The biggest success story here was we tried to we started to build a localization community. We had 142 people sign up to do 29 languages in the first day. Because they basically got to take over this group, make their own decisions, decide what they wanted to translate. We weren't just throwing stuff over a wall and saying, hey, go translate this now. Okay. So we we did really well. We got a lot of contributors on board, but we were trying to solve node. We weren't trying to solve like just the

Speaker 2: this new little project that we got. So eventually it did come time to reconcile and to try to bring the project back together. We wouldn't do this without having a an a foundation that actually owned the assets. We weren't going to go back to Joyant. So Joint did cave and well like they they came to their own decision about putting it into a foundation. That was great. We have autonomous open governance that is actually separate from the foundation. So the foundation has a board and they deal with money and some other stuff. The project is run by the contributors. own the project. It was also really important that we had a new foundation to do this under because if we went into an existing foundation, we'd have to adopt a lot of their governance structure. We have a long-term support strategy which we never had in IOJS because we didn't have any

Speaker 2: old releases. And that would turn out to be really important to enterprises that want to pick this stuff up. And now Node has enough contributors to actually run an LTS project. program. It couldn't before. We have 40 plus core committers. In in 2012, there were eight. And that was a peak. There were like I think three active by the time that we had forked. There are now 40 active core committers. committers. There's over 300 GitHub org members, so those are all people that are in working groups and localization and stuff like that. There's over 70 teams, which are basically mostly working groups, but they do everything from like the website, evangelism. everything else. So this is like a very strong project. Much stronger than it ever was under Node R us. But we we did have to reconcile, we did have to compromise. Like you don't you don't just get to be right.

Speaker 2: You also have to be reasonable if you want to make an act actual lasting impact. So that that's that story. I'm Michael pretty much everywhere. And uh yeah, I'm still at Modulus uh for another day or two. But like they're amazing. They've been hugely supportive of this entire effort. I couldn't have done it without them. And they just launched Python support yesterday. So you can look like act actually have a Python PaaS now to host your Python in Django apps. So that's my talk. Thank you. Okay.