Can One Person Run An Open Source Project Alone - Stack Overflow Blog PDF

10/23/2020 Can one person run an open source project alone?
- Stack Overflow Blog
Essays, opinions, and advice on the act of

computer programming from Stack
Overflow.
Find something
Latest Newsletter Podcast Company Developer Hiring IT-Recruiting (German)
code-for-a-living SEPTEMBER 9, 2020
Can one person run an open source project

alone?
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. But is a project managed best by a single
person with the final say or through building consensus with a committee of several people?
Ryan Donovan
https://stackoverflow.blog/2020/09/09/open-source-governance-benevolent-dictator-or-decision-by-committee/?utm_source=Iterable&utm_medium=e… 1/15
10/23/2020 Can one person run an open source project alone? - Stack Overflow Blog
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. “A er all, the main strength of OSS is its
ability to draw on so many people. People stick around when their e orts 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 e ective 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 e ort.”
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 Microso . “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 So ware 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 uno icial 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, sta 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 so ware,” said Lehnen. “However, the
Drupal project has a broader governance framework than just so ware 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:]
The Stack Overflow Podcast | EP244

Dropping knowledge with Drupal's creator,
00:00
1X
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 di erent 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, so ware 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 e ective 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 a er 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
o en the case that there are major tradeo s 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 o en 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 su er 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 So ware 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 stu 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, a er 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 so ware, 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
The Stack Overflow Podcast is a weekly conversation about working in so ware

development, learning to code, and the art and culture of computer programming.
The Stack Overflow Podcast | EP282

How should tech titans act when produ
00:00
1X
Related
code-for-a-living AUGUST 3, 2020
Getting started with contributing to open source

It can be intimidating to start contributing to an open source project. But with a little research and
planning, you can be a valuable part of your favorite open source so ware.
Zara Cooper
13 Comments
Kevin 10 Sep 20 at 1:55
Consensus produces garbage. Everything good in the world is the masterwork of a single
great mind.
Reply
Python Coder 12 Sep 20 at 4:52
Wikipedia decided by consensus.
Reply
Kyle 13 Sep 20 at 10:14
That’s a pretty bold claim.
I assume you have some sort of evidence to back it up?
Reply
14 S 20 t 11 12
https://stackoverflow.blog/2020/09/09/open-source-governance-benevolent-dictator-or-decision-by-committee/?utm_source=Iterable&utm_medium=… 10/15
14 Sep 20 at 11:12
Mark
Well said… and so observably true!
Reply
Matt 14 Sep 20 at 12:15
Consensus produces documentation, that’s good right? I hear you, bold

statement, true statement in so many instances, probably most.
Reply
Python Coder 12 Sep 20 at 4:51
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.
Reply
bit2shi 16 Sep 20 at 4:18
I wouldn’t call it an improvement if it’s written in Python, but each to their own.
Reply
Yaroslav 12 Sep 20 at 1:38
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.
Reply
Ryan Gollihar 15 Sep 20 at 12:06
Who’s account and profile user name was the app first built on that took fi htenth
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!
Reply
Devika Agarwal 14 Sep 20 at 7:00
Great article Ryan. It is very relevant to the research which I am currently doing.
Reply
Jim Morgan 14 Sep 20 at 1:16
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 e icient, 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 e icient
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.
Reply
WTrix 16 Sep 20 at 9:24
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 a erwards.
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.
Reply
Devoleksiy 15 Oct 20 at 5:33
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.
Reply
Leave a Reply
Your email address will not be published. Required fields are marked *
Comment
Name *
Email *
Website
Save my name, email, and website in this browser for the next time I comment.
Post Comment
This site uses Akismet to reduce spam. Learn how your comment data is processed.
© 2020 All Rights Reserved.

Proudly powered by Wordpress
STACK OVERFLOW
Questions
Jobs
Developer Jobs Directory
Salary Calculator
PRODUCTS
Teams
Talent
Advertising
Enterprise
COMPANY
About
Press
Work Here
Legal
Privacy Policy
Contact Us
CHANNELS
Podcast
Newsletter
Facebook
Twitter
LinkedIn
Instagram

Can One Person Run An Open Source Project Alone - Stack Overflow Blog PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Can One Person Run An Open Source Project Alone - Stack Overflow Blog PDF

Uploaded by

Copyright:

Available Formats

10/23/2020 Can one person run an open source project alone?

- Stack Overflow Blog

Essays, opinions, and advice on the act of

Latest Newsletter Podcast Company Developer Hiring IT-Recruiting (German)

code-for-a-living SEPTEMBER 9, 2020

Can one person run an open source project

BDFL-style: Heavy is the head that wears the crown

The Stack Overflow Podcast | EP244

Sustainable organic code

Tags: governance, open source

The Stack Overflow Podcast is a weekly conversation about working in so ware

The Stack Overflow Podcast | EP282

code-for-a-living AUGUST 3, 2020

Getting started with contributing to open source

Kevin 10 Sep 20 at 1:55

Python Coder 12 Sep 20 at 4:52

Wikipedia decided by consensus.

Kyle 13 Sep 20 at 10:14

That’s a pretty bold claim.

I assume you have some sort of evidence to back it up?

Well said… and so observably true!

Matt 14 Sep 20 at 12:15

Consensus produces documentation, that’s good right? I hear you, bold

Python Coder 12 Sep 20 at 4:51

bit2shi 16 Sep 20 at 4:18

Yaroslav 12 Sep 20 at 1:38

Ryan Gollihar 15 Sep 20 at 12:06

Devika Agarwal 14 Sep 20 at 7:00

Jim Morgan 14 Sep 20 at 1:16

WTrix 16 Sep 20 at 9:24

It’s all about strategy.

Devoleksiy 15 Oct 20 at 5:33

© 2020 All Rights Reserved.

You might also like