When you’re writing code for an employer, whether that’s a company or a client, you generally know who’s in charge. You have team leads who approve PRs, directors and product managers who determine the features for the next release, and a CTO and CEO who make the big decisions.
With open source, those lines of authority can be blurrier. Contributors are volunteers and may come and go as they please. Determining how decisions get made and projects move forward is called governance. Depending on the project, the style of governance may be as open as the code itself, or it may all depend on the leadership of a single founder, sometimes referred to as a benevolent dictator for life (or BDFL, for short). Some appoint a board through merit and community votes, while others have corporate sponsors that pick their people to make decision.
Because no matter how well-intentioned and free wheeling a project is, at some point, to succeed at scale, decisions need to be made and conflicts need to be resolved. A small project can operate with unspoken shared rules. Once a project forms a larger community, the processes for making those decisions need to be written down and made explicit so new contributors know how to engage successfully. “It's a fundamental prerequisite for achieving any kind of scale,” said Tim Lehnen, CTO at Drupal.
Governance, no matter what form it takes, is there to further the progress of the open source project and encourage contributions. “It’s crucial to set up structures that both support contributors and that help ensure that they see that their contributions are recognized,” said Nicholas Matsakis, Principal Research Engineer at Mozilla and member of the Rust core team and co-lead of the compiler and language design teams. “After all, the main strength of OSS is its ability to draw on so many people. People stick around when their efforts are valued and they can have an impact on the project.”
“Open source can kind of have a cowboy culture,” said Stack Overflow’s own Sara Chipps, who has been on the board of the .NET foundation and on the OpenJS Cross Project Council. “When you introduce guardrails, you ensure that there's a safe, encouraging, and open environment for every project to be successful.”
I spoke to several people involved in OSS projects to see whether the most effective guardrails come from a BDFL, a single person with the final say, or through building consensus with a committee of several people.
BDFL-style: Heavy is the head that wears the crown
The term “benevolent dictator for life” was coined for Guido van Rossum, the creator of Python, mostly as a joke, but the name stuck. The term grew to cover any founder-led open source project, including the Linux kernel, Drupal, Clojure, and Ruby. There’s a significant number of popular OSS projects that rely on a dedicated founder to govern them, so there must be some benefits to it.
I asked the community about this in the Open Source Stack Exchange. “I've always seen the BDFL model as halfway between a traditional open-source project structure and a traditional corporate project structure,” answered a user who goes by bta. “You have the openness, transparency, and general culture of OSS, but with a single strong project manager to make high-level decisions and direct the overall effort.”
A BDFL can signal that a project has a strong vision and will maintain that vision in the long term. “It allows leadership to develop and stick to a cohesive long-term vision instead of a series of short-lived leaders constantly changing plans and directions,” continued bta. “If you are aligned with the BDFL in terms of vision for the project, contributing to a BDFL-run project makes sense,” wrote another user who goes by D. SM.
It’s no accident that so many popular languages today operate on the BDFL model. Perl, Ruby, Rails, Python, and Scala all began as creator-led projects. Even C++ had a creator, Bjarne Stroustrup, who has remained an active member of the standards committee, chairing the language extension subgroup for 24 years. “Having someone with a very long-term view of the language, and a vested personal stake in its success, is critical in the early stages of a language ("early" being the first 10-20 years of a language),” said Ryan Cavanaugh, the principal engineering lead for the TypeScript language at Microsoft. “I don't think it's a coincidence that nearly every language in wide use today started with a strong centralized designer.”
With a BDFL that aligns with contributors’ vision, a project can follow that vision and make real progress towards a release. “You’ve got a small group of people that's trying to do something,” said Rob Tomkins, a DevOps engineer and member at the Apache Software Foundation. “They can move faster and make quicker decisions as opposed to a big group, a big crew of people that has to move slower. I try to be as open minded as possible because Linus [Torvalds, creator of Linux] has been tremendously successful.”
While the Linux Foundation does host a large number of popular open source projects, including jQuery, Kubernetes, and Node.js with varying forms of governance, the Linux kernel still has a loose BDFL structure. Mike Dolan, GM and senior vice president of Strategic Programs at Linux Foundation, said, “The Linux kernel follows a model where Linus oversees the final release details, but nearly all decisions are actually made by the respective subsystem maintainers, or subsystem group maintainers. All projects are inclusive, meaning anyone can contribute and participate in the technical community.”
As the project grows, though, other contributors may find themselves gaining expertise and sometimes unofficial leadership in certain areas. “In any large project there will always be at least an informal locus of power around various subjects,” said Manish Goregaokar, staff research engineer at Mozilla and member of the Rust Core Team. “It is not possible for a BDFL to be everywhere at all times, so the least you can do is formalize their roles and make it easy to get involved.”
It would seem that long term BDFL projects move the leader into a more removed position, as a final decision maker, not someone in the weeds wrangling PRs. The same scenario applies to Dries Buytaert, founder of Drupal. “Dries' role as BDFL for Drupal makes him the final decision maker when it comes to anything related to the Drupal software,” said Lehnen. “However, the Drupal project has a broader governance framework than just software change management. Day-to-day contributions to the Drupal project are vetted and accepted via a peer-review process.” [ed. note: You can listen to Dries discussing the details of how it works on a recent episode of the Stack Overflow podcast:]
In some ways, many of the BDFL-style projects eventually operate as hybrid governances, with the BDFL having the final say, while the teams below work out the details. “The BDFL model can work if most of the power is devolved to other groups of people, with the BDFL letting decisions be made by these groups,” said Goregaokar. “This isn't all that different from what happens in Rust.”
Of course, nobody succeeds alone, and nobody is perfect. “In practice, I don't think any language designer today sits atop a mountain, comes down every few months to issue a proclamation, and then returns to seclusion,” said Cavanaugh. “They're talking with people whose opinions they respect, looking for people to ask hard questions, and probably making a lot more compromises than you'd expect from the ‘dictator’ part of the name.”
That’s one of the risks you take when you rely on a central figure. The project succeeds or fails on the strength of the dictator and their ability to manage a complex technical project. Some people have a preternatural ability both to guide discussions, suss out the input they need, and make great decisions,” said Matsakis. “Others, not so much. So that’s a risk you take.”
We certainly can’t discount the benefits of the model, though there is a bit of survivors bias in how we consider its successes. “No one talks about the BDFLs of unsuccessful languages, so we're already talking about a community of people who have demonstrated their expertise and wisdom by nature of their position,” said Cavanaugh.
“The potential downsides of a BDFL-model are many, and as varied as are the individual personalities of project founders,” said Lehnen. Sometimes, though, the personality of the founder is the problem. People with strong opinions, distinct visions, and the ambition to push a major change to an industry aren’t always the most pleasant to be around. “It's not a model that reflects well on most folks,” said Chipps. “They think of them as generally tough people to be around—unkind, unfriendly, unwelcoming. But they happened to build something cool.”
In fact, most of the problems with the model come from relying on a single developer, regardless of their personality. If they disappear, either from a lottery win or bus accident, the project is in trouble. The person who is good at creating a new language with their genius technical ability may not be a great people person or project manager, and regardless of their programming ability or brilliance, they are but one person with limited time and energy. “Trying to run a project all on your own can be really exhausting,” said Matsakis. “I can’t imagine how any one person could try to run the Rust project all by themselves.”
While open source projects aren’t the same as businesses, software projects at businesses don’t rely on a single person either. “Even startups don't work that way,” said Chipps. “People are fallible, so at some point, either people burn out, they get tired of working on it, or they're asked to step down. It’s an effective model early in a project because it allows for quick decision making, as it scales, it breaks down; people are fallible and they make mistakes and they don't have unlimited time. It does prevent bureaucracy, but at a certain size, pulling the trigger quickly is not good.”
We have seen this pattern play out in recent years: van Rossum stepped down, and Torvalds took a break after accusations of rude, aggressive behavior. They added additional decision-making support and community involvement. So, what does the other side of the coin look like. Let’s take a look at what benefits and drawbacks a community-led project has, and how this can be tempered by the involvement of a foundation.
Design by committee
Where BDFL-led projects can align contributors around a central vision and make decisions fast, a project that seeks a group consensus, whether that’s a committee selected or voted in or a group of people who have earned their way to voting privileges through dedicated contributions, will always slow things down. Sometimes, that slower, measured decision process can actually be a net positive. “If done well open governance gets you a huge breadth of input, which can better inform your decision,” said Matsakis. “People may contribute ideas that had not occurred to you.”
Having these open, slower conversations can help work ideas, even ones that you might not be sure about. Sometimes being able to work out a definitive ‘why’ about a wrong answer is as valuable as finding a new right answer. Tomkins told me a story about when he pitched a change to the Apache commons listserv. “I discussed whether we should stay with the Apache Maven build infrastructure or move to Gradle, which is what the Spring Framework uses. For the sake of a healthy conversation, I tried to make it clear that I'm merely pushing the boundary a little bit, and I'm okay with what the community says. Everybody was like, ‘No, let's not move to Gradle. That's a minus one. Let's stay on Maven.’ And I was like, that makes sense.”
With a more mature technology, this exploration of ideas is definitely a plus. Fresh thinking from multiple developers, both experienced and personally involved in the technology’s success, can keep it relevant for years to come. “Any language that has become successful enough to warrant a committee to decide its direction must already be "good enough" to have justified a committee in the first place,” said Cavanaugh. “The slower nature of a consensus committee is not going to be a severe impediment.”
“Here on Rust, there's a good tendency towards positive-sum thinking,” said Goregaokar. “It's often the case that there are major tradeoffs involved in a technical decision, but people try hard to find positive-sum answers that show that you can have your cake and eat it too. It's not always possible, but when it is, it works really well.” Fostering these positive, productive conversations can be hard, and building consensus doesn’t mean everyone is on board. Sometimes, committee decisions diverge from the overall consensus. “Most of the time, we wind up deciding things in ways that align with the ‘sense’ of the RFC thread, but that is not always the case,” said Matsakis.
The problems with committees come not just from trying to build consensus, but also from who gets to sit on these committees. With founder-led projects, the question is moot. You built it, you run it. But a committee is often elected or selected by existing members. For those projects with corporate sponsors that select a board member, this decision can be extra fraught, especially to the more idealistic contributors.
Committee-style governance actually shares a problem with BDFL styles: burnout. If you think having to make every decision yourself is exhausting, try making every decision with a group of people. “Open governance can be tiring,” said Goregaokar. “Sometimes people have strong opinions, and it's hard to manage a discussion that's being bombarded with strong opinions.”
Where BDFL governance values decisiveness and vision, committee governance values patience and empathy. “People have their nuances,” said Tomkins. “That's okay. Your tone has to be particularly careful and tolerant and understanding of folks from other countries because they may not necessarily understand the nuances of the language as well as some of us that are from the United States. You just have to be patient and tolerant and I think it builds a healthier project that way.”
Committees can suffer from deadlock when multiple good solutions present themselves or fall into in-fighting when feelings are hurt. That’s why many open source projects now fall under umbrella foundations who can resolve these meta-governance questions. Mozilla, Linux, Apache, and even Java all provide once-removed oversight groups to weigh in on these matters. “There's an appeals process, so that if somebody feels like they're being done wrong or a decision is not being made on reasonable grounds, they can bring their grievance,” said Georges Saab, Vice President of Software Development at Oracle’s Java Platform Group and chair of the OpenJDK governing board. “But I'm very pleased to say we haven't had to employ that. We haven't had an issue like that happen in the last 10 years.”
Sustainable organic code
All of this governance, of course, is to ensure that the OSS project is sustainable in the long term and that contributors feel like they are being valued and get something out of it. Contributing to open source has a lot of benefits—it bolsters your resume, keeps your skills up to date, and connects you with other developers. But the fact remains that it is largely volunteer work.
“I try to be as welcoming and open minded as possible because it's really hard to find committers,” said Tomkins. “Everybody out there is super busy; everybody does this stuff in their free time. If I can be refreshingly welcoming to people, people are more likely to work with me in the long run.”
There’s a classic talk (warning: salty language) from Jacob Thornton, creator of Bootstrap, Hogan.js, and more. He talks about the toll that open source takes on a person, especially if that project becomes popular. Good governance and codes of conduct can alleviate that stress. “Open source can just be a really thankless place where you make something people love and then all of a sudden people are yelling at you,” said Chipps. “It's not great. Open source governance allows for a support system for those folks.”
Projects that have found success, especially projects that have an associated business built around their open sourced code, can find corporate investors. These groups may provide financial or technical support, but they can also start to skew a project’s mission. “One key lesson for us was to separate the governance for business and for technical work,” said Dolan. Plenty of corporations use OSS in their solutions and generate real revenue. “They quickly realize the need to contribute back. The alternative is a situation that will cost them too much money to maintain a project codebase out of sync with the upstream community. And this is how many of our projects find a sustainable cycle and, hopefully, long term success.”
These governance rules aren’t just so contributors feel good about the work that they put in; they also serve to ensure that the project moves in helpful directions. Regardless of style, most projects have a proposal and RFC process that put any new features through their paces. “It's important for us that any feature we're looking to add today is serving a concrete need, not just adding to the language speculatively,” said Cavanaugh. “Once we're comfortable with a feature proposal, the last step is getting it implemented, after which time we can try it out, work out any edge cases, and make sure we've created something that will be a good ‘forever’ addition to the language.”
The Linux foundation may be the current gold standard for governance. They started early and essentially created the modern idea of open source. The Linux operating system conceived code contributions like a bazaar, not a cathedral; that is, anyone can contribute, not just the elect. Because they were early to open source, they’ve gained plenty of experience over time. “The Linux foundation as a parent foundation is a good example of governance,” said Chipps. “Because it has failed at so many things, it's had to become a better at everything it does. It started out as an adversarial place to be. Now has so much bureaucracy that that's not possible.”
Dolan agrees: good decisions come from experience, and experience comes from breaking things. “We’ve certainly learned by doing, breaking things, and having to help fix them, too. That doesn’t apply to just software, but the governance models themselves. We’ve also hired open source professionals who built and broke many things before they came to the Linux Foundation and brought those experiences to the table as we set up new communities.”
Open source projects and their governance, like the code itself, is still a work in progress. It’s still figuring out what works as a governing model and how to make all-volunteer contributions into a sustainable model. But they’ve already changed the world, and they’ll continue to change with the world.