Can one person run an open source project alone?
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.
Tags: governance, open source
18 Comments
Consensus produces garbage. Everything good in the world is the masterwork of a single great mind.
Wikipedia decided by consensus.
That’s a pretty bold claim.
I assume you have some sort of evidence to back it up?
Well said… and so observably true!
Consensus produces documentation, that’s good right? 🙂 I hear you, bold statement, true statement in so many instances, probably most.
You can of course. @Kevin, Wikipedia is perfect, and it decided on consensus, so consensus does not produce garbage. I am developing an improved version of OpenSSH all by myself.
I wouldn’t call it an improvement if it’s written in Python, but each to their own.
I concur. The virtue of Python is a lowered bar for proofs of concept by people whose primary expertise is in a problem domain rather than software development. For redevelopment as a stable product it is an appalling choice.
Wikipedia can be perfect for some topics where a pure rational/empirical approach to knowledge is key, but not for others where it’s riddled with systemic bias and where perfection doesn’t always make sense. Eg. selection of ‘reliable sources’. Consensus is affected by the views of founders and early joiners who appeared to have stayed on only because they could find common principles of applying consensus that perfectly work for some topics to the extent that it’s so addictive, and who then apply the same principles on topics where things are not so clear cut, just like a hammer looking for a nail.
I feel that the post title is misleading (or even a click-bait). You call it “Can one person run an open source project alone?”, but in fact it’s not about the whole life of the project (which includes contributions and development), but only about its governance (making decisions, choosing the strategy). Also it says about the relative influence of the creator, not about him or her doing every decision completely alone.
Who’s account and profile user name was the app first built on that took fifthtenth place . and wasn’t it made to his specifics for two accounts ,one social media, other for online . Social media was supposed to be secured and protected bye the app, online searching was supposed to be secure private both where protected bye apple , which I was never informed of any issue!
Great article Ryan. It is very relevant to the research which I am currently doing.
I have been researching teamwork science for more than 20 years, with more than 1,000 relevant studies read and three Web books written based on that literature. The overwhelming evidence is that zero valuable products and services came from a single great mind, though it may provide the initial idea. Furthermore, the BDFL model survives not because it is the most efficient, but as a result of individuals’ drives for social power. The resulting hierarchies evolved in ancient circumstances where quick decisions mattered more than *best* decisions. The evidence suggests a disciplined group of equals outperforms similar leader-led groups (in non-life-or-death scenarios) over the long term because the average quality of their decisions is better. Every time some manager has tried to argue consensus is slower, I have been able to prove 1) the group did not implement efficient decision-making processes like formal meeting facilitation, Scrum or Kanban, and/or 2) the manager only gave it a few months, instead of allowing time for the long-term benefits to emerge. Note, however that “consensus” is not the same thing as “unanimous agreement.” It just means everyone agrees to support the majority position given what they know now, subject to revision later.
What about purity of purpose? The overheads of communication? The inevitable failures of communication? The most effective players in a meeting are usually those whose purpose is their personal advancement rather than advancement of the project goal.
Teams are excellent for slow grinding detail that is sufficiently unglamorous that it does not attract politicians.
Though nothing comes wholly from a single mind, everything great comes from a single mind having an epiphany founded in what it learnt from its precursors. Mozart, Newton, Einstein. Committees fill in gaps in the works of their betters. They are incapable of clarity of intent, but they have more collective experience. Even the stupid committee members serve to inform the brighter ones of how people of low intellect will interpret and respond.
I challenge you to list three works of genius that were the products of committees, and not the refinement of a virtuoso effort.
Open source projects are much like business, in my opinion. They require some mean decision making to trump the competition and succeed. The founder either has the business skills to push the product or they don’t. If they don’t, they’ll have to be wise enough to realize that they have to find someone who can, and do it while the steam is still going.
It’s all about strategy.
Even a unique project with practical uses will remain in the slumps if nobody ever hears about it. Two years down the road it’s lost its exclusive status and everyone is going for the guy that came afterwards.
Whichever decision making process one chooses, one thing is sure to work for the best: there must be a strategy and it must be fine tuned regularly. The decisions are then easier to make when it’s decision time because they adhere to a set strategy.
Of course it can. I wrote open source code, wrote, wrote, and in the end I realized that I needed to make a commercial project). But I am 100% sure that you need to benefit the world and write something useful.
I have two projects. The one where I am an autocratic one-man-band has hardly any issues, perfect rating scores and a small clean codebase. It has ~25000 users. The other one is educating some people about CICD, testing and consensus decision making but has yet to deliver product even though the proof of concept code was already usable on my computer when the project went open.
One person is far more efficient but does not scale.
A team has overheads, and a less clear agenda.
A dictator must be tactful and diplomatic because it’s all volunteers.
Thinking about small projects, right now most are a github repo, BDFL (benevolent dicatator for life), a bus number of one and an issues page that does everything from capturing bug reports to proposing new issues. The only real way for third parties to contribute is by pull request.
Next generation.
It would be cool if one could easily put software projects under the control of a decentralised governance system. Goals would be:
* Increase that bus number – if the founder/maintainer disappears or hoes on holiday, other people can contribute bug fixes in their absence. There area bunch of nuances here. There could be different types of update requiring different levels of consensus, e.g. updating dependencies if current ones turn out to have security flaws could get an automatic thumbs up, conditional on ci passing. However for now I’ll stick with the basic idea of each PR going to a vote. Decentralize ownership. Give the project a life of its own.
* Have a kickstarter/issue funding page. Most open source projects are maintained by people in their free time, or by one of a small number of big orgs that make their money in some other way and fund the open source. It would be cooler if open source had legs of its own. Want a feature? Pledge $100 or make a PR. Is the coding effort greater than the value you would get out of it? Make a proposal to capture pledges. The goal here is to maximise the energy that can be captured from people to make the project better. A project can always still be forked, but forking splits energy, it diffuses it, so unless that energy is recaptured by merging the forking model isn’t good at making things happen. And merging requires consensus around what should be merged. Merging requires a governance model.
As a side issue, it really bugs me that there are problems with open source software and I can’t easily to to the source repo and put $100 on “fix this issue here”. A very few projects support that but by and large there is no good funding model for FOSS, apart from finding shelter under a behemoth like Google.
So, if one were to encode the rules for such project governance into a program, what would they look like? The first model doesn’t need to be perfect and many projects may want to tweak the model but it would be cool to make the first steps and see what actually works, in terms of human dynamics.
Governance model == constitution. I would be really interested in writing – or seeing someone write – such a governance model as a program. Personally I would run the program on blockchain, say as a Dfinity canister, so you could clone a repo from the blockchain, you could get voting tokens by contributing code and/or funds to the canister.