What success really looks like in open source
And how we can support them
When we talk about successful open source projects, we imagine big, thriving, participatory communities, where many people share the burden of contribution.
Where did this idea come from?
Open source as a community model can be traced back to nearly 20 years ago, when Eric Raymond wrote an essay called “The Cathedral and the Bazaar”, outlining two models for software development.
The essay centers around a then-new software project, Linux, as a “subversive” example of how software can be built more openly, a “great babbling bazaar of differing agendas and approaches” (Bazaars) rather than “small bands of mages working in splendid isolation” (Cathedrals).
Raymond believed Bazaars were a more resilient and sustainable approach to software development. More people = more resources. To describe this, Raymond coined the famous line, “Given enough eyes, all bugs are shallow”, which he dubbed “Linus’s Law”.
“The Cathedral and the Bazaar” defined an entire generation of open source. But some people remained skeptical of Bazaars, questioning whether it was feasible for all projects to aspire to.
Bazaars are rhetoric, not reality
From the outside, projects like Linux seemed to prove that Bazaars really did exist. But not everybody was sold on the idea.
- Nikolai Bezroukov, an internet security analyst, wrote an immediate rebuttal to Raymond’s essays in 1999, calling it “too simplistic” and a “vulgar Marxist interpretation of software development”.
- Robert Glass, a software engineer, researched the topic for his 2002 book Facts and Fallacies of Software Engineering and found that the ideal number of code reviewers is actually 2–4, after which point the quality of review drops.
- Poul-Henning Kamp, a veteran programmer who’s worked on FreeBSD, NTP and Varnish, wrote a 2012 post called “A Generation Lost in the Bazaar”, musing that while “it would be nice if [Raymond] was right…quality happens only when someone is responsible for it”.
- Jeff Atwood, cofounder of Stack Overflow, wrote a 2015 post called “Given Enough Money, All Bugs Are Shallow”, noting that a major security bug called Heartbleed went undetected for two years. Atwood wrote that “if you want to find bugs in your code, in your website, in your app, you do it the old fashioned way: by paying for them.”
Was Raymond wrong? No, not necessarily. Consider the historical context in which his essay was first published.
This was 1997. Microsoft, Oracle and IBM dominated software. Linux, and the related open source projects making up the LAMP stack, were the underdogs. Essays like Raymond’s helped legitimize Linux and galvanize support for open source in a world where closed source was still the norm.
Raymond needed rhetoric to be persuasive, and he succeeded. Our mistake as readers was to treat it as canon.
Bazaars captivate us because they appeal to our hearts, not our head. But we shouldn’t mistake rhetoric for reality. Let’s dig into what success really looks like in open source.
Open source projects don’t start as communities
Many would agree that open source projects don’t start out as Bazaars, but just in case, I’ll emphasize the point. Raymond himself wrote:
It’s fairly clear that one cannot code from the ground up in bazaar style. One can test, debug and improve in bazaar style, but it would be very hard to originate a project in bazaar mode. Linus didn’t try it. I didn’t either.
Somebody has to be chiefly responsible for an open source project’s initial development. In Linux’s case, it was Linus. Somebody has to live and breathe the problem all day. Once that project is in a stable position, the community helps support it.
Other prominent Bazaars that were started by people with dedicated time:
- Ruby on Rails started as a project by David Heinemeier Hansson at the company Basecamp
- Michael Widenius and David Axmark started MySQL as a company project
- Ryan Dahl wrote Node.js, which was sponsored by the company Joyent for five years
Somebody is always “in charge”, even as projects mature
Nearly every Bazaar has one or more people — even an organization — who are chiefly responsible for its ongoing development.
Sometimes this is called a “benevolent dictator for life”, or BDFL. Sometimes it is called a “core team”. Sometimes they are simply called “maintainers”. Although some projects avoid these terms to reduce hierarchy, basic human behavior dictates there will always be somebody who is more involved, and therefore carries more influence, than someone else.
From far away, successful Bazaars look like moneyless anarchic systems, but up close, the bulk of responsibility falls on a couple of people, who are usually being paid to do the work.
Sometimes, these arrangements are clearly defined. For example, Go is a programming language written by several Google employees, and those employees continue to be paid to work full-time on Go.
Other times, these arrangements are less obvious. For example, several of the maintainers of the programming language Ruby are employed by Heroku. Even though Ruby is older than Heroku itself, it is effectively dependent upon Heroku at the moment to finance its ongoing development.
What we’re really talking about are resources
99% of open source is about community. Just because there is some structure there doesn’t mean the community aspect is worthless. (Even Burning Man has a Department of Public Works!)
So why am I being a wet blanket about this?
Because many of us genuinely believe in the Bazaar, and we want to believe it so strongly that it blinds us from the very real problems that exist in supporting open source infrastructure.
The lack of support for infrastructure hinges upon a cultural misperception that “successful” projects subsist entirely on volunteers. Until we are on the same page about this, talk about solutions will go nowhere.
The following statement has been repeated to me, mostly in private, more times than I can count: A project that relies on a couple of maintainers to survive…well…
That an open source project used by millions, but maintained by just a few people, should simply die: this seems counterintuitive even by capitalist measures.
A dying community of users? That’s one thing. But it is much harder to argue that Python infrastructure should be “Darwin”ed out of existence when Python is one of the most popular programming languages in the world.
To VCs, a project that gets millions of users, even if it lacks a business model, is an interesting one indeed. It means there is “magic” there, and magic leads to abnormal, outsized outcomes. If these projects were startups, VCs would be looking rather closely.
So when we talk about “success” in open source infrastructure, success actually has a couple of components:
- A popular project is a project that is being used by a lot of people, and ideally growing.
- A healthy project is a project where maintainers have an active, reciprocal relationship with their community.
- A supported project is one where maintainers have the resources to manage the popularity of a project and grow a healthy community.
Ideally, you want all three. But there are many combinations. And that’s why there is no one-size-fits-all solution to sustaining open source.
Money can only make a project supported. It can’t make it popular (consider venture backed, unsuccessful infrastructure projects) or healthy (that part comes down to the people).
A project can be popular, but if it’s not supported, it’s hard to have the bandwidth to grow a healthy community. (For example, Read the Docs gets 15M PVs/month and is used by companies like Dropbox and Twilio, but without steady funding, the maintainers can’t focus on sustainability.)
And, of course, there are projects that are popular and supported, but have unhealthy communities. I won’t name those. 😉
But let’s not mistake unsupported for unpopular. Some maintainers openly solicit help, only to find that nobody steps in. This is a tragedy of the commons; that the phenomenon exists does not make the commons worthless.
So as long as a project meets the first criteria (i.e. is popular), we ought to move beyond questioning whether it deserves to exist, and instead focus on what we can do to ensure it is healthy and supported.
How do we make popular projects healthy and supported?
When it comes to addressing the sustainability of a popular project, there is probably a Maslow’s hierarchy of sorts. For example, if a maintainer is not willing to work with their community, throwing money at them is probably not going to help.
I’ve collected the following list of needs based on what I’ve noticed across projects. I’ve tried to roughly organize it from critical (bottom of Maslow’s pyramid) to legacy (higher on the pyramid).
Critical -> Legacy
- Is the maintainer responsive to his or her community? Do they respond to issues, pull requests, community discussion? (Opportunities: diplomacy, or when all else fails, a fork to force governance changes)
- Is the maintainer able to manage their workload (pull requests, issues, etc)? This is where maintainers burn out and quit. They may appear unresponsive because they are overburdened. (Opportunities: better project management tools, improved documentation and onboarding, passing project to someone else, enabling maintainer to work full-time on project)
- Is it easy to contribute to the project? What does the first-time experience look like? (Opportunities: improved documentation and onboarding, translations, cleaning up code, creating a website)
- For projects that cannot be managed part-time, are there one or several committed maintainers who work on it full-time? (Opportunities: hiring a maintainer to work on project full-time, corporate/individual sponsorship)
- Who controls the project? Is there risk of undue influence or legal conflict? (Opportunities: move project to a foundation, contribution agreements)
- Are people aware of the project? Is it easy to find? Is there fresh talent contributing? (Opportunities: creating a website, improving design, moving to a platform like GitHub, outreach to new developers)
What do you think? Did I miss anything here? I’d love to hear what has or hasn’t worked for projects you’ve been involved with.
I’m currently exploring better ways to support open source infrastructure. If you want to stay involved, you can sign up here to get updates when I post something new, or follow me on Twitter.
