Liberal Contribution and Governance Models

Welcome to Request for Commits, a podcast that explores different perspectives in open source sustainability. On this show, we talk to people about the human side of code; we cover everything from community and governance to businesses and licensing. If you’ve ever wondered how open source projects get started, survive, die or flourish, then you are gonna love this show. I am Nadia Eghbal.

And I’m Mikeal Rogers.

On today’s show Mikeal and I talk with Rod Vagg, Chief Node Officer at NodeSource. Rod has worked across the Node.js ecosystem, including in the database community and creating several key NodeSchool workshops. He serves as a Technical Steering Committee Chair for Node.js as well as on the Node.js Foundation Board.

Our focus on today’s episode with Rod was around liberal contribution policies. We talked about Rod’s early experiments with liberalized common access, the underlying mechanics of liberal contribution management and how to level-up casual contributors.

We also talked about how projects transition into a liberal contribution mindset and whether there is a place for BDFLs in the future of project governance.

So Rod, you once said that the history of open source is divided into eras based on the different tools you’ve used, which I think is a great way to start this episode. All three of us have written and spoken about how there’s this new era of open source where there are a lot more casual contributions, kind of like this GitHub era. So I’m curious, to start out, what that transition was like for you, as you’ve been involved in open source? How did you observe that sort of transition happening?

I guess I observed that simply by my involvement, because while I’ve been doing the software thing for a while now, my involvement hasn’t really been significant until this new era of GitHub and Git.

The friction involved in some of the earlier eras really prevented me from embracing it properly. I can’t tell you when it was that I really started to jump in headfirst into open source or why that change happened, but I think it was much more when open source became easier to be involved in the community.

I don’t live in a large city, I don’t have a community of nerds around me that I can just go out and hang out with, I don’t have local Meetups, so for me the online community is my nerd community, it’s where my people are. For me, when that became easy, that’s when I really threw myself out there into open source. So while I have contributions going back a fair way, particularly in the kinds of things that people would always do, like submitting bug reports - I was doing that for a long time, but if you were to do a commit graph of my involvement in open source, it really started to properly pick up during this recent era that we are in with GitHub and Git.

Did you ever get to a point where you realized that was different from maybe open source projects in the past, or that not all projects were like the ones you were involved in?

No. It’s not until really recently when I’ve started to speak about these things and actually think more about open source governance, that I’ve really had to think about the difference there.

[03:46] I wasn’t early on with the GitHub thing; I don’t know if the IDEs are easy to find on Google, I think they are through the API, but my IDE is not particularly low. I didn’t jump in early and see this thing was this radical new thing that we’re getting involved in. I didn’t recognize that at the time, and so I was a slow adopter. It wasn’t until recently that I’ve looked back and seen it as something that really demarcates this new open source versus the old. But the dividing line, it’s really quite stark when you think about what it means for open source, and so it’s surprising that it crept up on all of us, it just sort of happened. But I think for people that have been deeply involved, particularly people who have been involved in Apache projects, it’s probably been more obvious because it’s been a little bit more painful to have this new thing to come along that is really replacing the old and presenting challenges, because people don’t want to get involved if it’s not on GitHub; they don’t want to have to use SVN or whatever other old tools people wanna use. So it’s been a bit more painful for them, a bit more obvious, but for those of us who have sorta lurked and only become more involved recently, it’s not as obvious.

I find this really interesting, because usually this just complete lack of wanting to jump through hoops to contribute is associated with people that have not as low level of a technical background. But you actually have a very low-level background and have written some very low-level stuff in the Node community, like the native abstraction layer and stuff like that. But I’ve seen you not get involved even in GitHub projects, where it was just too annoying to try to contribute. Do you associate that with anything? Have you really thought about it and tried to identify what it really is?

I think there’s a soft confidence thing there. So even though you might identify me as somebody that’s comfortable with low-level things, my own personal soft confidence with my technical abilities took a long time to grow. Part of that was because I wasn’t involved as heavily in communities online and didn’t have large peer groups, so I wasn’t able to properly measure my technical abilities. That’s one of the nice things about communities - even though measuring your skills against others might sound uncomfortable, it’s actually a confidence boosting measure when you are able to clearly identify where you fit in that hierarchy, because that gives you the ability to find an entry point to something. But if you don’t know that, if you don’t know where you fit and what you have to offer, then it’s gonna provide much more uncertainty about how you can even get involved, or if you should get involved.

Yeah, I think that the biggest confidence boost isn’t the first contribution or the first bug report or even the first push. It’s the first time you help somebody else get their commit in or you get to give somebody else advice and improve their work. It’s this huge confidence boost to go, “I’m at a point where I can help other people, I’m not just a person being helped.”

Yeah and that’s true, that’s very true. Along with that, the confidence boost can come with just releasing your own code. Sometimes that can be scary to people who are doing open source for the first time and aren’t already involved in interesting projects. Releasing your own code and saying, “Here I am, here’s what I have to offer the world. Judge me by it” is really scary, but doing that and finding out that the sky doesn’t fall, people are not gonna come and yell at you or laugh at you or anything like that, and they might actually find value in your project. That can be the confidence booster people need.

[07:53] Those of us that have been involved in open source now for a while - I guess I’m addressing this to people who are rough around the edges now and are considering getting involved – we’re used to seeing this spectrum of quality from pretty raw to very mature and high level… I guess you just accept that there is this level and some projects will need a little bit of a hand to level up, and other projects already have that because of the technical abilities of the people involved. And that doesn’t mean that you reject things that are on that lower end of the spectrum, it just means those things need a little bit of a hand. Even if you really don’t have that big technical skill, you’re not gonna get laughed at or judged. That happens occasionally, but it’s actually really rare.

It’s really rare that somebody’s project gets pointed out and laughed at; it might happen occasionally on Hacker News, but most of the time people release their stuff and it collects a community of some kind, whether that be people of similar interest and skill level, or other people trying to just get involved and make something useful out of it. It’s actually not as scary to do that first step as you often think it is before you get involved in open source.

Can you tell us a little bit about getting involved with LevelDB and then how some of these learning got fed into your experiments with liberal contribution Policies there?

Okay, LevelDB - this was one of my first explicit experiments with much more liberal contribution agreements or governance. So to be honest, the LevelDB stuff, I started getting involved there simply because I was looking for a new project to do that would let me do some interesting work on the Node add-on area, so C++ add-ons. I wanted to dive into that and learn a bit about that area and was looking for something to do. That just seemed like an interesting area to play with.

There was an existing project that did this, and like a good open source person, I thought there’s really no reason not to reinvent the wheel, so I reinvented the wheel and dove in and wrote this thing. Early on in that process of exploration, I was trying to make something that felt a lot more Node-like than what already existed for LevelDB; so I wanted to make something that was much more natural and when you used it felt like a Node thing.

While I think I started off in the right way there, I actually had some of the best ideas come from outside. I opened it up pretty early and I started throwing around these ideas on GitHub and in IRC as well, and managed to pick up some ideas from some people who were able to really make it feel much more Node-like. One of those people actually was Max Ogden; most people around the Node ecosystem probably know Max. Mikeal, you know him particularly well.

He actually gave me some really good ideas around - I think it was some streaming stuff that I was tinkering with, but he gave me a couple of suggestions that really clicked and I thought, “Yeah, that’s a great idea, that really feels Node-like” and went with a couple of those suggestions that he had.

[11:51] And that process of getting other people involved in the design stage and then the very early contribution stage where there were some people who were interested in making a tool here that felt much more Node-like… That process of actually saying, “These people actually have really valuable opinions from the get-go, from actually building this thing. They wanna get involved, but also they are already involved and they already own a lot of the ideas here. What right do I have to claim full ownership of this stuff? A lot of the code and a lot of the ideas are not even mine.” It was a small project, pretty small API surface area, and not all of it came out of my head. I just didn’t feel I had the right to fully own this thing and so the idea of liberal contribution, liberal governance – sorry, what was it called at that stage?

Open open source?

Yeah, open open source. This idea that I shouldn’t claim sole ownership of this thing, and when you give contributions, you are actually giving them to me to claim ownership of; that just didn’t fit, so I decided to go ahead and make this open open source thing around LevelDB at the time. The LevelUP project, that’s split up into two projects and then this ecosystem appeared around those projects, and they all pretty much adopted the same contribution style, where the idea is that if you are showing up with something to add – and that’s not a trivial thing, so don’t just give me a typo fix; give me something material – if you are showing up with something meaningful to add, then you should have a seat at the table, because this thing is obviously valuable to you and you’re putting some time and effort, which is valuable, into this thing, so you can share ownership in that.

That style, the open open source style that has evolved in the LevelUP ecosystem, it’s very much about equal sharing. You get ownership of the project, the whole project. You get to have an equal vote as the original person that started it. You get your name on the overall copyright thing; it says “This is copyrighted and owned by the contributors who are listed.” You basically become an equal with the other people and that has persisted, it’s worked really well and it’s something that I generally adopt now for all my open source projects, because the people that show up, that wanna contribute and do the work obviously have a vested interest in the project, it’s meaningful for them. There’s no good reason to hold it tightly, most of the time.

There might be some, there’s obviously some situations where that does make sense, but a lot of the time you are putting it out there anyway, you are finding a community of people that it has value to, so why shouldn’t you share that?

So beyond just these initial principles, what were some of the early iterations you did to that policy? I can’t imagine that it was super fleshed out right away, there had to have been some additions or changes you made along the way.

Look, to be honest, what you find… If you go to the LevelUP repo and look at the contributing file, that hasn’t actually changed very much since the original version, and it’s not because it’s perfect, it’s simply because no one has thought to update it, or no one has actually – like, I haven’t gone back, or anyone hasn’t gone back and said, “Well, these things don’t make that much sense.” But if you look at it, there’s a bunch of things in there that actually don’t make as much sense now that we’ve iterated on this idea, and I’ll quickly just go through…

[16:10] We’ve got these five rules: the first rule is no false pushes or modifying the Git history in any way. In practice, that idea suggests that you shouldn’t write over people’s stuff and you shouldn’t mess with the Git history; it’s just a good idea. But in practice, false pushing is sometimes necessary, but the idea there is simply that you don’t have the right to mess with other people’s history. You only do that if the tools make it necessary because you are doing some weird rebasing or whatever.

So that rule in practice is quite soft, and people will do what needs to be done with the tools, as these needs come up. So I’m not sure I’d codify that the some way these days.

Second rule is non-master branches ought to be used for ongoing work. Again, this is just like, whatever works for the project and the people involved. The idea behind it was that the master branch was supposed to represent the pinnacle of the active work, the stuff that has really been accepted. And in practice that’s at least how it works, but how that plays out, how you get to that, is really a matter for the people involved.

Sometimes people are quite comfortable doing a fork and submitting from their own fork. I had this idea originally that you wouldn’t need to fork the projects, because you actually have full rights to the project; you don’t need to make a fork and then pull request from your own fork. In fact early on, I actually started encouraging people, “You don’t need to do that. Come and make a branch in this project.”

And while I still like that idea, in practice it really depends on the individual and the mechanics of the project. So in the Node project, for example, we don’t do very much in the main project at all; we tend to do it from our own forks, so that’s again a bit soft in practice.

The third one is external API changes and significant modifications ought to be subject to an internal pull request to solicit feedback from other contributors. In practice, the way that I think it actually should be done - and that rule should actually be changed - is that every change should be done by a pull request.

Early on it was like, okay, if your fixing grammar or some minor little thing, then sure just commit it, but for the sake of visibility, I would change that and say that everything should be done via pull request.

The fourth one is similar - internal pull requests solicit feedbacks are encouraged for very non-trivial contributions, but it’s left to the discretion of the contributor - that’s pretty much the same thing.

And the last one is contributors should adhere to the prevailing code style of the project. I don’t know if that actually needs to be said; that’s just how we do open source. The reason I put that there was because I sometimes adopt some quirky code style things, and the last thing I want is people showing up and saying “We should change this and put semicolons or change the spacing.” Just get over it and accept whatever the code style is in the project you are contributing to. I don’t know if that needs to be said in these rules.

Mostly, these rules have sort of become really flexible and there’s just a more of a general idea of openness and a mechanics to contributing that make that openness work well.

[19:49] In terms of iterations, I actually haven’t had enough time to go back and really pin down the best mechanics that work for the different kinds of projects. Mostly, they just evolve within those little communities and it just works as it works,

That makes a lot of sense. So we are gonna take a quick short break, and then when we come back we’re gonna really dig into the meat of liberal contribution policies and what this does for casual contributions.

And we are back with Rod Vagg. So Rod, take me through some of these mechanics of liberal contribution policies. You talked a little bit about what went into the LevelDB specific policies. What would say is the overarching philosophy of how these are constructed and how that differs from the more traditional approach to contribution policies and governance?

There’s a couple of things to look at. The first one is the mechanics of collaboration; how do you do this in a way that involves the whole group of people that have the ability to make decisions, so all of your contributors are these equals that seat at the table?

GitHub presents the obvious answer to that, which is pull requests. So pull requests for everything, and that means that every time you want to make a change, you do it as a pull request, which is the invitation for discussion.

If something doesn’t garner a discussion, then you take it as an implicit okay. If nobody steps up and says “I don’t like this” or “Hang on, let’s talk about these things”, then you’ve got the go-ahead. You don’t need to necessarily chase sign up from other people. In practice, people do, and in some of the more formal settings that’s actually written in, like in the Node project that’s written in, but most of the time in these small projects where you have only a small number of people that actively concentrate on the project at each point in time, a pull request that doesn’t go into discussion has an implicit yes.

See, that’s a really big departure from traditional policies. Traditionally, in open source if I send a change to a project, it’s my responsibility to convince them that it should go in, not the other way around, right?

Right, this is where the initial gating process comes in. So if you send a pull request to one of these liberal projects and you are not one of the core contributors to it, then you have to go through the process of convincing that the change is good, and that can mean a whole lot of things. That actually is the onboarding process most of the time.

[23:40] That can be things like going through looking at your code style, “Hang on, you’re not actually conforming to the code style of the project. Just do the basic here!” There’s always these hurdles that you go through, which are quite normal in open source projects. You get this thing right, fit into the project, make sure the API makes sense - all of the things that you normally go through with a pull request is actually treated as the onboarding process, and if you manage to get over that first hump, then you’re in. You’ve done the initial work and you can be at the table now, doing that process with other people. ;

And what’s more, you can actually be involved in changing some of those things that you had to go through. So if you really hate the code style, like if there is something wrong with it, then you’re perfectly within your rights to propose that it be changed; you’ve just got to convince the other people that may stand up and say, “No, I don’t think we should change that.”

So getting through that initial gate is the important bit, but once you’re through, then you’ve proven yourself as somebody that places enough value in this thing and is willing to give your valuable time and effort, too. So you have rights to change it as you think it needs to be changed. But in practice, people know that radical changes are difficult, and will likely raise a discussion or significant objections.

So every change, if it doesn’t get a discussion, it usually means it’s pretty trivial and no one cares enough about it, so just go ahead. You do need to leave time for a discussion. If I were to rewrite the policy in general for open source, I would definitely build in something about that time period, because you do need to take into account, for a start, the global nature of open source. You can’t assume that everyone’s within your time zone.

Also, the different ways that people do open source; some people do it in their work time because it’s a part of their work, and they are using projects for their work; other people do it on the weekends. So you do need to make sure that you leave enough time for these pull requests so that all of the people involved in the project have a chance to jump in if they’re going to. This becomes part of the culture; it’s not fair to create a pull request and merge the same day, or even the next day, usually.

It’s not fair on the other people in the project, and it’s usually frowned upon. So they do need to be left open for enough time to get going on a discussion. And then when discussion does happen, consensus-seeking really is at the heart of the process, and that does really need to be written into any liberal contribution policy. Consensus seeking is what happens to get to agreement, and consensus seeking doesn’t necessarily mean that you have to reach consensus; it just means you have to address enough of the concerns that you don’t have anyone saying “No, this can’t go in.”

So you don’t have to reach consensus as something that is good, but you have to reach enough consensus that nobody is gonna put their foot down. So the gating for something getting in is really that somebody is willing to strongly enough assert that this thing shouldn’t get in. If somebody gives it a no, then that’s a no, and that could just be one person amongst the group.

Yeah, there’s a big difference between pure consensus and consensus seeking; with consensus seeking, the goal is that everybody agrees that this should go in, but if one person objects, in pure consensus they would basically get a veto. In consensus seeking, they have to convince everybody else that it shouldn’t go in. Inevitably, you can go to a vote if you need to, but in practice you never end up using votes because if somebody objects, but they don’t wanna take the time to convince everybody else, they just give up the objection.

Yeah, and that depends on how strongly they feel. And that’s actually an interesting thing, because the strength of somebody’s feelings about technical changes actually reflects more than just feelings. It’s a technical opinion and it usually carries along with it some technical merit, so that’s why these things are important to pay attention to, even if people don’t express them very well, because nerds are often not that great at expressing themselves beyond pure technical things, and sometimes not even with technical things.

[28:10] So just that process of allowing people to say no is important. What it means is you ‘to have to drop into a discussion mode, which can be uncomfortable for people, and can actually be intimidating for outsiders, as well. That’s something in practice that we’ve found, that it becomes occasionally discussion-heavy, and while that is part of community and it’s actually one of the valuable parts I think of the existing communities that develop, it can be intimating for people coming from the outside. So that’s just something to keep on top of. So that’s the contribution thing with pull requests, that’s the important part of that.

The other thing to note is that the way I often describe these things is we try to make open source more like a Wiki, so we think more like a Wikipedia. Trying to turn open source projects into their own little mini Wikipedia is the goal here; everyone has these valuable contributions, and they may be tiny or they may be significant. There’s no good reason to really be so protective about these things, because we often pretend that every change involves some huge technical - it needs to go through these technical hurdles, when often it really doesn’t. If someone is trying to fix something small, it’s as simple as that, they are trying to fix something small. It’s not that they are trying to mess or change the architecture of something.

If you look across pull requests across almost any open source project - the kinds of things that people from the outside are waiting to get in, they’re these small things that will make a huge difference to them and very little difference to other people who haven’t even encountered the same problem, or haven’t wanted the same kind of functionality from the project. And it’s not usually going to make a radical difference to the project itself. So that’s how Wikipedia evolved, that’s how articles on Wikipedia evolved.

Usually, most of the changes are not these big architectural changes, they are minor. So moving open source projects closer to a Wiki is one of the goals here, but the challenge that code presents that you don’t get in the same way with Wiki articles is that you want to occasionally make releases, and these releases have to represent a conception of quality at a point in time. So while we go to a Wikipedia page and we accept that it might contain errors because somebody edited it five minutes ago and they have made some trolling comment in there that’s really funny - you don’t want that in your code releases. You don’t want to make a release of a library and it’s got somebody’s little trolling comment in there or it’s got a silly API that’s somebody is messing with, just because they had the ability to do so.

So we do still need this process of being able to make releases that we agree are of quality and that represent the project at that point in time, so we can’t quite act just like Wikipedia. We do have to have a process that allows us to assert quality at these snapshot points.

That’s where the idea of having a master branch, or a branch that is sacred is important. This branch represents a place where we only put things that we all agree are good, and then having some way of making releases off that, and often that will involve an individual or a group of individuals that are a subset of the project, that go through that process. So there is a difference in release mechanics over just contribution mechanics, which is worth thinking about when you dive into this thing. But at the same time, you shouldn’t let that hold you up from being more liberal with accepting contributions, because there’s releases and then there’s what’s in your Git repository; what’s in your Git repository is rarely used by users in production or even in development.

[32:21] What they use is your releases, so try not to get too hung up in what’s in your repository; it’s the releases that matter to end users, so try and separate those two things a bit. That’s my thoughts on mechanics for now.

Let’s get a little bit into the casual contributions that you touched upon. I think there is a perception that casual contributions are really small things, nothing really substantial and we can’t really rely on them for anything useful. What types of contributions do you see coming from casual contributors versus more regular contributors, and where do you think they can fill in a strong role?

I don’t make as much differentiation between casual contributors and whatever the opposite of that is, because I don’t think you can actually know when somebody is a casual contributor and when they are not. Something might be small to start with, but that might be somebody testing the waters. So they might be trying to just change a tiny thing that’s annoying for them, but if you give them the right signals that “Everything is okay, we’re not going to jump down your throat every time you try and make a tiny change, we are actually going to embrace you”, you can actually turn those people very readily into more than casual contributors.

So I don’t think that distinction is actually that helpful, unless you are able to measure it over time. So if you look back in the history of a project, look over the past six months, then you might actually be able to actually see who were the casual contributors. But at the time that it’s happening, I’m not sure you can say who the people are that you could label casual, because very often, those people, when given the right signals, can turn into something a lot more.

I’ve seen people come and show up with documentation fixes, even minor ones, and you give them the right signals that, “We’re open for business, we’re open for contributions” and they level up really quickly. In fact, one of the most interesting things about this kind of contribution policy is that you can actually take people with a low level of technical skill and you can level up their skill through the process.

So I’ve seen people come in, saying things like “I don’t really understand C++ or this fancy stuff you are doing in here, so just contributing to the documentation is good enough for me.” But they may contribute enough documentation to get over that initial hurdle of non-trivial changes, and they may become of the core contributors of it, even though they are asserting they don’t have the technical skill, but the fact that they recognize that is important, and when you put them at the same level as everyone else, it actually encourages them to level up.

I’ve seen people go from saying that they don’t have the technical skill to be a primary maintainer of a project that is very technical, just by giving them the permission and that blessing to say, “You’re one of the team, you’re equals with us and you have the responsibility to help foster this community and this project” and just simply giving that responsibility means people level up.

[\00:35:44.27] It’s really surprising how that works in practice when you give them the responsibility. It’s the responsibility that does it; when you give people responsibility over a project, then it creates in them something that makes them step up to the plate, and they are not just somebody from the outside tinkering and throwing little changes at you; they are actually somebody that takes it on board personally and that does really surprising things.

I really like this outlook of, “Well, you don’t know if they are casual or not.” Do you ever experience a tension between people that are already working on the project a lot and the kinds of policies that are gonna help them out and favor them, versus what’s gonna be more applicable to people that first show up?

I think the tension comes mostly in terms of culture, and that’s something that you do have to be very tuned into. How do you treat people coming in from the outside? It is helpful the fact that everyone who is part of that core group has already gone through that process, so usually they are tuned into that. Actually, it really makes people receptive to outsiders because they know they were once in that same place and they were helped out by the same community and they have become another helper.

So most of the time, it’s actually really positive, but you do have to be careful that culture does not start to turn inward too much and start to become snobbish to people with different opinions. Because the fact about open source projects is that if they don’t evolve with the people that use them, then people will stop using them. If they are not meaningful to people over the long run, then they become irrelevant.

I don’t even need to give examples here, because this is the history of open source, and people move on as well, and people show up; those new people often bring new ideas and new preferences, and if you don’t allow a project to start to accept some of those new things, then you can become just as stale as a classic open source project. So being attuned to that policy, that culture of openness, and making sure that not just the mechanics, but the actual culture, the way that people work together remains open, I think is really important. And it’s hard to do, as well. It’s not something that you can as easily build into as something that goes over the long run.

I’ve seen this in a couple of projects where it’s a small group, and you end up with a bit of an echo chamber about how something should be, and other people coming from outside with new ideas/alternative views and they have a hard time really getting into that echo chamber.

I think that’s still the same problem that open source has had for a long time. It can be solved, but it’s a matter of actually being attuned to it and watching for it, and making sure that you keep on reminding each other that “Hey, new people value this as much as we do.”

In fact, a lot of the time new people may value it more than we do because we might be moving onto new things, and we might be hanging around here because it’s a great community, but in terms of use of the project, other people out there may be using it more than we are and may actually place more value in the project, so allowing them to come in and shape it is not only worthwhile, but is vital for the future of the project.

You said something interesting, which is that it’s about culture; when everybody has gone through the process, you naturally have a culture that is really welcoming and open to newcomers if they started on that kind of long tail of contributions… But what about projects that have an established culture and an established policy? I mean, you and I were both involved in the reforming of the Node.js project, which very much had a very old style contribution policy, and there were not just one person, but several people that were very skeptical of liberalized contribution agreements.

[39:59] So I was wondering if you could speak to some of the standardized arguments against liberal contribution policies, and what your response is and what other people’s response should be if they are trying to move a project in a new direction or establish a newer culture.

I think that these standard arguments are actually very familiar even outside of open source and software. My wife is a teacher, and during the rise of Wikipedia I got to hear all of the arguments that came from typically librarians, actually, but also educators that were used to having walled gardens around knowledge. Not that my wife had problems with Wikipedia or anything, but I got to hear it, being attached to that sort of community of educators. So those exact same arguments that arose during the rise of Wikipedia, and that still go on today … You go to a school and find the librarian and you ask them about Wikipedia, there’s a good chance you will get the same arguments. Those same arguments apply here.

It’s simply a fear of openness, it’s a fear of the masses and the crowds. Some of it is legitimate, because it’s a fear of chaos, and chaos is scary, for good reasons. But in practice, things are not chaotic; it’s actually this wisdom of the crowds, this collective process where people get together and they get to collaborate, which is actually quite magical and it’s not chaotic, even though it might look chaotic from the outside, or it might sound - usually it just sounds chaotic, and not just looks chaotic. It sounds chaotic to people.

I’ll give you one of these very specific things that we had to deal with, because I really want to know what your response is to this very simple one, because I hear it over and over again in other projects; they have a project with a bunch of open pull requests, and what they’re really falling under is that they have a couple of maintainers and they are too stressed and they have too many pull requests coming in. So liberalizing contributions is just gonna make more requests come in and they’re afraid of that maintenance overhead. What is the liberal contribution policy answer to that problem?

Well, for a start, how good a problem is that to have, that you have people lining up to contribute to your project? That’s a great problem to have, so get over yourself. But the best answer to that I think is if you look in practice at how this actually works. When you have a project that has those kinds of bottlenecks, particularly in the administrative areas, because the maintainers have their head in code or other areas where they think is more important, actually bringing on new people and giving them that sense of ownership and the sense of responsibility can actually take away a lot of those burdens. So in practice, when you - this happens almost universally - take on somebody new to a project and you say, “ You own this thing; this is yours as much as it’s mine and were are gonna work on this together, and you have permission to go and do all the things that a maintainer does as long as you do it in a collaborative way”, one of the first things that most people do is go through the issues list and the pull requests lists and start doing some pruning or some maintaining of those things.

That’s an obvious place where a lot of people can help in open source, and they know they can help because they’re doing it already often in their own projects. They can go and actually help with that interface with the community.

So very often I’ll have a project that I might be the only person doing it, and I say – it might be something trivial, but I have this contribution policy where if you show up with something non-trivial, then I’ll give you ownership of it; somebody might show up and I give them ownership… Almost immediately they’ll go through the issues list and start closing things or responding to things, just cleaning it up because they have this thing about what the project looks and feels like, so giving them that ownership is actually great for offloading some of that administrative burden.

[44:22] In terms of getting a flood of people contributing, as I said, I think that’s a great problem for open source project to have, and that was not something to be afraid of with Node. That was something we wanted to embrace, because that meant that Node was healthy and if we couldn’t unblock that, then it was going to be unhealthy.

But there is a fear there of the outsider coming in with different ideas to what you already have. As somebody who starts an open source project particularly, you have these ideas in your head about what this thing could be, where it’s going, and very often you’ll hold to those ideas pretty tightly. It’s a rare open source project that comes to life and has the idea that it’s finished and it’s ready to go. Mostly, these things come to life and we have these ideas about where it could go; it could evolve into this particular space and solve this particular problem set, and it would be this magical thing.

If you are unable to let go of that internalized vision, or if you are unable to actually communicate that in a way that people are actually able to get on board with, then it can be really scary, because you’re saying, “These other people that don’t share my inner monologue about this project, these other people are gonna come in and they’re gonna bring their own ideas about where this thing can go.”

That was one of the things I think we faced with Node, and it’s probably gonna be a challenge for a lot of existing projects. They have this idea, that this project is on a path towards this point in time and certain people, particularly people that are just interested in technical problem solving, the people who are thinking more architecturally and organizationally have this idea about what the steps to get there looks like and where it needs to go. Bringing in people from the outside that don’t have that is really scary, because it means that the project is probably not gonna go in that same place, unless you can do some pretty heavy communication and convincing work.

I think that’s the problem we faced with Node and I can see that same problem with some other projects that are considering, but not quite at the stage of accepting this kind of model.

Good stuff. We’re gonna take a short break and then when we get back we’ll talk about reconciling liberal contribution with the BDFL’s model of the past and what things might look like in the future.

We’re back with Rod Vagg and we are talking about liberal contribution agreements. I would like to hear about at what point do you think a project is “ready to take on” a liberal contribution policy? A lot of projects now start with a BDFL model and then they might transition later, but that’s how a lot of projects start. Do you think this is something that projects should have from the beginning? Is it something you think they should save for when they are a little bit more mature?

My ideas here are very much formed by my own involvement in community groups outside of technology, and watching community groups that are held too tightly by a core group really fail to get traction and thrive. And this idea that you can run a group for your own personal interest – that’s a pretty raw way of saying it, but often I think that’s the way the groups are run, that they are run for the sake of the people running them. When you are trying to do community, that’s just not gonna work and it’s kind of terrible.

If you have a community, then that community needs to exist for itself. It needs to be self-referential, it needs to be self-governing, it needs to be self-owning. And when you’re running a community group and you’re not letting the people inside it have that sense of ownership or the actual ownership, then you’re in for a lot of trouble. So applying that to open source I think just makes perfect sense.

So earlier you were talking about how one of the big fears is that other people coming in are going to change the vision of the project, and what you were just talking about there kind of backs it up. There’s gonna be this tension between the personal interest that I have and the shared interest of other people, and I think especially when you have a popular project that you’ve been the BDFL of for a while, all the people coming in asking for things just seem kind of crazy in that scope, and the fear is that “When I open this up to more shared interests, there is gonna be this big scope creep.” What has been your experience actually opening up that sense of ownership, though? Has the scope kind of gotten out of control or has it actually contracted?

Right, okay. So I guess that back us to the previous section about the objections, and one of the big things is scope creep. And that’s acute for us in the Node area, because we have this idea of small core, and a lot of us, particularly that have been around Node for a while, have this very much internalized.

We appreciate the core of Node being small, so that was a particular problem for the Node core project, but we also apply that all across the ecosystem. We like having our modules small, we like having the scopes small, so that we can have lots of these modules pieced together and not have these modules balloon out into these monoliths that do everything. We wanna have them to be really small and self-contained, and just be able to describe them nicely in an idea, rather than having to have these huge sets of documentation that describe all these magical things you can do with it. It’s just gonna be… A readme is enough, and if you need more than a readme, then perhaps you are doing too much.

So there is a fear of scope creep there. If I open up to people coming in from the outside, then they are gonna add all this crazy stuff because they want this thing to do more than it really should do. In practice, that comes down to culture again, and also this whole consensus seeking process.

[51:44] You can actually see how this works by looking at governments, in general. The more people you add to a committee, the more people you add to a government, the harder it is to make decisions, and so that process of - it’s like an intentional gridlock that actually is built into this liberal contribution process, where it’s not easy to make radical changes. In fact, sometimes it’s impossible. I embrace that and actually like that as one of the features here; it’s very difficult to make radical changes. Incremental changes usually are okay, but making radical changes is very difficult; even adding huge features is very difficult. Particularly a departure from the core idea of the project can be difficult, because you are having to deal with people that have already internalized what the project is about - so that’s that onboarding process again. You’re showing up with your changes and they may be a big departure from the project, and you are having to present them to the people that have already internalized what this project is about. If it doesn’t match, then you are gonna be gently rejected.

We see this all the time, particularly with Node core now, because we have people showing up all the time wanting to add features because they think… They have this idea that something belongs in core because they are bringing their preconceptions about what a standard library should be from other languages, be it Python or Java. Then they bring these arguments usually, “I can do this when I write a Java program, why can’t I do it when I just run Node? Why do I have to install this thing from npm”? But you are bumping up against a very established culture of small core and small standard library, so you have to go through that process of accepting that that’s just the way things are before you can even get into that group.

Yeah, I guess that’s a roundabout way of saying a couple of things there, which is that the model itself is not very well suited to big revolutionary changes; it’s much more suitable to evolutionary changes, which is actually in the interest of users, because software projects that do revolutionary changes that might change radically between versions one and two rarely survive that transition. And I’ve done that myself, I’ve taken a project that was going really well and I thought “Okay, well I don’t like the way it is internally. I’m gonna rewrite it all, and make a version two that is so much better”, to find out that no one cares about your version two and it doesn’t suit their needs, and it was all in your head.

That happens all the time with open source and that’s the nature of revolutionary change. You have users out there that value the thing as it is and if you are not evolving it in contact with those users, then you are gonna be in trouble. So the process itself really lends itself much more to evolutionary change, and also that onboarding, the process of getting into that core group; there’s an implicit onboarding there, it’s not even explicit. There’s not a thing where you have to go through an onboarding, you are going through an onboarding when you get through those hoops, and that is part of an enculturation thing that is really taking on board the ideas of the project. Perhaps the project itself actually has the idea that it wants to be expansive; that would be found out pretty quickly as part of that process.

I wonder if that makes the argument then that… I mean, if you want to say arguably the most “innovative stage” of a project might be earlier on when everything is still really new, and you’re trying to lay the foundation, find your voice, find the culture and the kind of angle you wanna take, it makes more sense to have a BDFL style model early on, when changes can be made more radically and more quickly by, say by one person, and the liberal contribution working better in like this maturity stage of evolving things, but a little more slowly? Is that consistent with what you’ve seen?

I don’t think so. So BDFL, for a start, I really don’t like the idea of BDFL. To me this idea that you can take full ownership and be dictatorial on a project that is valued by other people often very deeply, I find it really repulsive. And so just in general I just hate that model, and often what happens in BDFL projects, pre-BDFL run projects and small-group run projects that are closed is that you’ll end up with the people that are running the project spending more time on the project than actually using it. That creates for an interesting effect, which is that they become more detached from their users. And they might hear from their users via issues and pull requests, but if they spend more time as a maintainer than as a user, then you’ve got a problem there.

We still have that in Node, because many of us that work on Node Core, we do that as a job. We spend a lot of time in there, rather than being users of the project. So that’s where the value of constantly having this intake of people who value the project enough that they are willing to put in time and effort to contribute to it - those are the people that are the users, they are the people that this thing matters to.

And it might matter to you simply because you have some history with it, or you’ve become emotionally attached to it, but if it doesn’t matter to you as a user of the project, then you are in a bit of trouble.

[57:47] So back to the original question, which is how early should you start this thing… I don’t have a great answer for that, because I’ve seen it work in different ways; mostly, new projects don’t have a lot of buzz anyway. When you start a new project, you might pick up a few interested people in your ideas, but you’re hardly gonna start off with something that suddenly you have an influx of people wanting to contribute to your thing, until you have something that is meaningful.

I’m not sure that it makes sense to say, “This thing should be BDFL until it’s ready”, because until it’s ready, you’re probably not gonna have enough users that want to jump into it anyway, and if you have this idea of what is ready, if that’s obvious, then contributors are probably gonna be onboard with that anyway. I saw that with the LevelUP and the LevelDB ecosystem, that’s exactly what happened. It was obvious to people what this thing needed to add in order to be what it was going to be what, and that was a very small group initially, and a very passionate group, because they had a need and they saw where this thing was gonna fit. So they contributed from an early stage, it was open from early on, and they contributed around that idea, and they really created that culture and they created the idea of where it should end up.

It might make sense for you to just hold something as closed sourced while you get it ready to be open sourced, so you’re not always throwing out projects that are not gonna be finished, and maybe you wanna set something up that’s obvious where it’s going. That might be an important thing to do, but I don’t buy the argument that something should be BDFL because it’s still getting ready, because getting ready is a special process in itself that people will attach to.

We’re in a very distinct phase with Node, which is we’ve gone past the phase of defining what this beast is. That happened - I think it happened all the way up to I think Node 0.10. That was very much an evolving process of trying to figure out what the boundaries of this application, this platform were.

We’ve gone through that process; we have a very clear understanding of that now, so we’re very much in the phase of minor evolutionary incremental changes to improve things for the life of users. We’re filing off the rough edges, and we are basically in this maintenance mode, but it’s still extremely active maintenance mode, where we have a lot of contributions, a lot of work going on every single day. It’s all around this sort of perfecting this thing that is already defined.

That’s a very distinct phase for Node, but I think Node still could have been developed early on from being much more open than it was, and it may have even gotten to a better place, but I don’t know. I doubt it would have gotten to a worse place than it is now by being more open.

Sounds like even if effectively there aren’t that many people contributing early on, that’s different from codifying the idea of BDFL, does that make sense? It sounds like you’re suggesting that liberal contribution works from the very beginning and just realistically you’re not gonna have as many people contributing when a project is super young, and you’ll just sort of transition over time; that’s different from saying, “I am BDFL” early on.

That’s just right, and that brings up an important point, which I haven’t touched on at all which is the importance of leadership. It’s nice to have this idea that you’re gonna have people show up, you’re gonna have this emergent property of leadership, it’s just gonna emerge out of the mass of people doing things. That’s a nice idea and sometimes it works, but very often you still need leadership, and that leadership may be in the form of people putting in more effort than others.

[01:02:01.17] That’s what happens early on in a project - you’ve either got one person or a few people who are passionate enough about making this thing work, that they are willing to put in that much time to get it there; rarely do you have a lot of people doing that. Usually, there is only a small group or only one person, so that’s what leadership looks like initially.

As the project evolves you need somebody or some people to serve in that role of facilitating the community, and that comes down to the fact that not everyone is a leader and we ought to be fine with that, that not everyone wants to be a leader and not everyone has those natural skills to be a leader, and when you accept that then you see that there is a place for individuals to step up and just start being the grease in the wheels. And that can play out in really interesting ways; it can play out just by the fact that somebody is stepping up. Very often, other people will be looking for that person, and they’ll be waiting for it, and they step up and they might start to assert things, and other people involved in the project might say “Phew, finally somebody is here to take that burden.” And we can disagree with them, “Great, at least we’ve got someone to disagree with now. We don’t just have this mess of people that are too timid to really assert thing”, so having somebody stand up and start asserting can be a really valuable thing and people look forward to it.

The other way that it can manifest is simply in the respect that people get over time, and that’s how leadership can evolve in these projects. It evolves in open source in general; you build up this capital of respect by your contributions and by what you know and what people know that you know, and you see that in complex projects like Node. Node has a lot of different areas that are all very distinct and there are different levels of expertise in different areas that are required to understand them and nobody – there’s zero people in the Node Core project, amongst that group of people, that understand it all and that are experts in it all. Everybody is an expert in one area or a few areas, and nobody is an expert in it all.

And the way this kind of leadership evolves in that setting is that people build up the respect and the technical capital from other people that they know this area and that they are somebody to be listened to. One of the most obvious ways this plays out at Node is when you think about Crypto; it’s a really hard area for people to get across, very few people really understand it enough. We have a few people that are really well respected in that area, and we will generally defer to them, and often for even the most trivial things; we’ll say we need sign off from these people, or they need to be involved in this discussion in order for it to move forward, and then when those people in that small group - or it might be just one person even - they start proposing changes in their little area of expertise, they almost get a free pass because everyone looks at them as the leader in that area.

So that plays out really interestingly when you’ve got a complex enough project, but it also plays out in smaller projects when you’ve got simply somebody who has got obvious depth of technical knowledge and understanding about a project; they are generally recognized and they get to play that leadership role, as well.

[01:06:08.21] I think that there’s a really interesting distinction here between entitlement and respect. The BDFL model is about entitlement, like you are entitled to run this project indefinitely, and to some extent when you have a small group that’s closed off too, like “I’m entitled to be the area owner of this, and it’s not anymore about just other people respecting my expertise here.” And one of the interesting effects there is that you’re only ever going to get one person that’s gonna be the expert on that if you’re allowing this entitlement to be there rather than respect; like, at one point in its history Node did only have one Crypto expert, and now there are two and they are both equally respected. I don’t think there ever would have been two or would have gotten two if there was an area owner, or an area dictator of that particular area.

Right, that’s exactly right, and also that dynamic also impacts on people’s willingness to be involved. If you have a process that says, “You have to respect this individual and their opinions”, simply because they are that person, they are their BDFL, you’re actually less likely to get people to engage, because a lot of people are not going to submit to this idea that authority is granted rather than earned, and particularly in the technical community, especially amongst engineers.

If you’ve ever done any work with personality typing, you find that there are people that will accept authority simply because it exists or because it’s being granted or because somebody just says so. You have a monarch, and they’ve always been that way and they should be respected - that’s great - and then you have other people, who are like “No, you have to earn my respect, you have to earn that place in authority before I’m willing to submit to that authority, and I’m willing to give you that respect.”

In software engineering and engineering in general, we’re much more heavily weighted towards those kinds of personalities where you need to earn the respect, you need to earn your place in authority, otherwise you just not going to get it automatically. People are not gonna come down and automatically accept what you say. And you can see that every day if you go to Hacker News, you’ll see this same sort of dynamic happening, where everyone is an expert and there’s only a few people that really have earned enough trust of enough of enough of our community to be able to say things and get a free pass for saying them without getting everything picked apart.

And that happens all the time in open source and if you have a BDFL that says this individual is the person that decides what goes and what’s good enough, and they haven’t earned that respect or they aren’t continually earning that respect, then you’re gonna have a huge breakdown in people’s willingness to be involved. To use it as well - if people don’t respect the people running the project, why would you use it?

The continual part there is the big distinction, I think, and this is also what I think a lot of people’s problem with meritocracy is. It’s that Meritocracy isn’t about continued investment and respect for that continued investment, it’s really just about setting a bar and then saying, “Everyone who gets over this bar has a particular set of entitlement now.” Once you’re in the club, you’re in the club forever. That’s what meritocracy has become to mean, in a lot of ways.

To be honest, that’s something we’re still struggling with, and you know this Mikeal. We have this process of onboarding people to these projects, but we don’t have a good process for off-boarding, and that’s still something we need to explore. We need to have a way to say “Okay, your time has passed. You’re no longer actively involved, so maybe you don’t deserve a seat at the table anymore.”

[01:10:01.17] This is a real challenge, because we have even now situations where people are making decisions in Node – Node is the obvious place because it’s been around for a long time and it has these people that have earned their position, but have sorta moved on. But even now, you will have people showing up and asserting themselves or even being involved in the decision-making process that are not actively involved in the day-to-day. And there’s a disconnect between that and this process of ‘those that do the work, get to make the decisions’ - that’s what really underlies open contribution governance. Those that show up, those that put in time and effort are the ones that should be making the decisions about the project, because those are the ones to whom the project is most valuable.

And so if you have people that you haven’t effectively off boarded, but are still effectively hanging around asserting themselves - and that may be the original person, the original BDFL… Even in some of my own projects I’ve struggled with this, because I have these ideas internalized about the project and I haven’t even used it for a long time, and then to watch people, having its own community of collaborators evolve it in ways that I’m not comfortable with, it’s very difficult not to step in and say, “No, that’s just not in line with what this project should be”. Having a way to off board people from that I think is really important, and I don’t think we’ve quite figured that out yet. But we will get there, because it’s an important step.

In that vein, I’d like to hear a little bit on about what you might think some potential – not necessarily downsides, but challenges of liberal contributions might be, that are new or specific to liberal contributions?

Well, one thing I’ve touched upon earlier on is this discussion-heavy culture. This is something I think about regularly, because I personally enjoy it. I like to engage in vigorous discussion, I like discussion to be almost argumentative; argument for argument’s sake is a bad thing, but a discussion that is vigorous and is actually trying to find better outcomes I find extremely invigorating, because it means you are working with other very capable people to perfect something that one individual could not do on their own, and to me that’s one of the greatest things about having a community of equals. You can present something that you may think is great, and then it goes through the process of working with other people and it becomes even greater because you’ve go that extra input.

That’s a great thing, but it makes this process really discussion-heavy, and that, unfortunately, is a barrier to a lot of people, because a lot of people don’t appreciate that, and for good reason. Sometimes it’s just a personality thing; they don’t want to have to engage in too much discussion, but often it’s simply a soft confidence / maturity thing. You show up and you put up your ideas, gently put up your suggestions and suddenly you’ve got these people piling on, going through the process they go through every other change to perfect something, and you’ve just put up something that you feel very deeply about, or you might feel it’s a reflection of your own abilities or your own self in some day, and you’ve suddenly got people showing up, telling you ways that it could be made better or changed or fixed, or ways that it’s no good, and that can be extremely intimidating and it can be very off-putting.

[01:13:45.26] One of the challenges I think we have is in making sure we do this in a way that is welcoming even to those people. That’s a challenge, because it’s not something that’s easily codified into rules, and it’s certainly not something that emerges out of the process, because what emerges naturally out of the process is it raises up those individuals and those processes that encourage discussion, and the grinding away of the ideas until they become their best selves.

That’s a really interesting challenge that I don’t have great answers for, but I think we will be seeing a lot more thought put into as time goes on, because it’s a real one and we don’t want to marginalize people that don’t fit into this natural mode that this thing is really well-suited for.

I think there’s also just a time commitment aspect to that. You are valuing people’s input that can assert themselves continually for quite a long time, whereas people that are more casual or just don’t want to put in all the work to read this giant thread, they no longer can participate because of how this is going.

Right, and I often say that these models are the best way so far in connecting project governance with the users that value it the most. With open source, we don’t have the ability to go out and survey all our users, because we don’t know who they are. It’s not like a product from a company where you might have contact with every one of your users and you can actually go there and ask them questions.

We can’t involve our users that way directly with our open source projects, but what we can do is say, “If you’re showing up and you have a change to me, could be a bug fix or an enhancement, then this thing is obviously important to you”, so in my opinion it’s the best way we have so far to connect a project with the people that value it the most.

Unfortunately, a lot of those people that do value the project, don’t have the time, as you said, to go through the process itself. It may be extremely valuable to them and there may be something about it that needs fixing, they may have a bug or a way that they are using the project that is unique enough that no one else has picked up on the problem, and they may present a solution, but perhaps they are using it to run a business and they don’t have time to engage in this process. But their changes actually have merit, it’s just that it’s not experienced by many other people, so that they have to be the champion of that change. When you are in that position, that can suck, really.

I’d like us to find a way to make sure that we recognize that input from outsiders that don’t have the ability to engage in that same way, but it’s very difficult to find a way that. I guess you wanna make sure that the project is still run by those that value it the most; you don’t want to open up avenues for it to be run by people who just wanna show up with their ideas and turn it into something they think it should be, simply because it’s their preference. You want it to be run by people who actually use it, who actually value it. Finding a way to make it inclusive enough I guess is the challenge.

That’s a good stopping point for us. Thanks, Rod, for talking to us about liberal contributions.

Thank you very much.