Working in Public: The Making and Maintenance of Open Source Software

by Nadia Asparouhova

The spirit of openness lasted more than 200 years. We championed the value of literacy and education. We built roads, bridges, and highways that brought together previously isolated communities. We careened toward the new millennium, flushed with the global triumph of Western liberal democracy.

That many open source developers suffer from a lack of support is indisputable. My inbox was flooded with emails from people involved in open source, eager to share their stories. The hard part was identifying what they actually needed.

The cycle looks something like this: Open source developers write and publish their code in public. They enjoy months, maybe years, in the spotlight. But, eventually, popularity offers diminishing returns. If the value of maintaining code fails to outpace the rewards, many of these developers quietly retreat to the shadows.

A developer who’s employed at a private company works primarily with their colleagues. A developer who writes code in public must work with thousands of strangers:

In my conversations with maintainers, I heard them express a genuine conflict between wanting to encourage newcomers to participate in open source and feeling unable to personally take on that work.

I started to see the problem is not that there’s a dearth of people who want to contribute to an open source project, but rather that there are too many contributors—or they’re the wrong kind of contributors. Open source code is public, but it doesn’t have to be participatory: maintainers can buckle under excess demand for their attention.

I realized there was an enormous disconnect between how we think open source works and what is actually happening on the ground today. There is a long, and growing, tail of projects that don’t fit the typical model of collaboration. Such projects include Bootstrap, a popular design framework used by an estimated 20% of all websites,4 where three developers have authored over 73% of commits.*5 Another example is Godot, a software framework for making games, where two developers respond to more than 120 issues opened on their project per week.†6

This distribution—where one or a few developers do most of the work, followed by a long tail of casual contributors, and many more passive users—is now the norm, not the exception, in open source.

If anything, it looks like exactly the opposite of what these early advocates predicted. One study found that in more than 85% of the open source projects the researchers examined on GitHub, less than 5% of developers were responsible for over 95% of code and social interactions.7

There’s even a term called the bus factor, where project health is measured by the number of developers that would need to get hit by a bus before the project is in trouble.

The problem facing maintainers today is not how to get more contributors but how to manage a high volume of frequent, low-touch interactions. These developers aren’t building communities; they’re directing air traffic.

SourceForge, the dominant code-hosting platform back in 2001, had just over 200,000 users at the time.9 Today, GitHub, its successor, claims over 40 million registered users, a number that has nearly doubled in just the past two years.

Increasingly, our online worlds are being built by individuals, not just communities.‡

If you consume any content on the Internet, you’re mostly consuming content created by people who for some reason spend most of their time and energy creating content on the Internet. And those people clearly differ from the general population in important ways.

Social platforms brought all these communities to one place and smashed them together like Play-Doh. In doing so, they inadvertently changed the way we make and consume content. Creators now reach a much bigger potential audience, but these relationships are fleeting, one-sided, and often overwhelming.

Kristen Roupenian, reflecting upon her experience after her short story in The New Yorker, “Cat Person,” went viral, describes it this way: The word I keep reaching for, even though it seems melodramatic, is annihilating. To be faced with all those people thinking and talking about me was like standing alone, at the center of a stadium, while thousands of people screamed at me at the top of their lungs. Not for me, at me. I guess some people might find this exhilarating. I did not.

As a result, examining the behavior of these developers, as compared to other types of creators, prompts a certain set of essential economic questions. It also helps that open source developers work in full public view, making their stories easier to study.

Open source has always served as a vanguard for the rest of our online behavior. In the late 1990s, open source was the poster child for a hopeful vision of widespread public collaboration, then dubbed “peer production.”

But over the last twenty years, open source inexplicably skewed from a collaborative to a solo endeavor. And while more people use open source code than ever before, its developers failed to capture the economic value they created: a paradox that makes them just as interesting to reexamine today.

We’re still trying to reconcile the rise of individual creators with the crumbling of newspapers, book publishers, and talent agencies: the decline of the firm as a principal agent of change.

If creators, rather than communities, are poised to become the epicenters of our online social systems, we need a much better understanding of how they work. In a world where 4.5 billion people are now online, what is the role of one?

His 1997 book-length essay, “The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary,” makes a compelling case for the benefits of open source software.

“It’s the system that’s important. If one developer goes away, another will step in and maintain it.” Freedom of code extends to freedom from the people who make it, too.

today’s developers hardly even notice “open source” as a concept anymore. They just want to write and publish their code, and GitHub is the platform that makes it easy to do that.

GNU is what it is because it is not hosted on GitHub. By contrast, today’s generation of open source developers needs GitHub to do their best work. Just as there are Instagram influencers and Twitch streamers, there are GitHub developers. These activities take place away from platforms, too—you can still upload photos or videos of your Hawaii vacation to a self-hosted website—but why would you? For those hoping to reach an audience, platforms and creators have become inseparable.

Thompson suggests that Facebook is not actually a platform but an aggregator, because there is “no reason for Facebook, beyond goodwill, to do anything for [media] publishers.”

The fact that modern developers slap an MIT license onto their projects unthinkingly—if they bother to license their projects at all—separates them from early open source advocates, who built their megaphone on the dogma of “openness,” manifested through permissive licensing.

Software licences regulate distribution, but cannot regulate production. . . . This is also the main challenge of whatever comes after open source.40

Package managers first appeared in the 1990s to support the Linux ecosystem, but eventually they became standard tooling for most programming languages. For example, the programming language Ruby has a package manager called RubyGems, while Python has PyPI.

Sarah Drasner, a maintainer of Vue, another popular frontend framework, cowrote an “open source etiquette guide” with Kent C. Dodds, in which they emphasize that contributors should “be polite, respectful, and kind.”

Sindre Sorhus, who maintains hundreds of JavaScript projects, once tweeted, “After having reviewed 10k+ pull requests on GitHub . . . ~80% of contributors doesn’t [sic] know how to resolve a merge conflict.”56 A few years later, he followed up with more observations: Almost no one writes a good pull request title More than half don’t know about the ‘Fixes #112’ syntax ~30% don’t run tests locally before submitting a PR ~40% don’t include docs/tests57 I’ve also noticed that the general PR quality has gone considerably down in the past few years. I guess it’s a result of GitHub’s increased popularity. `¯\_(ツ)_/¯`

Open source maintainers have become the de facto teachers for developers who are learning how to contribute. In the past, this made sense when new developers were trying to join a project’s community. Today, rehashing the basics to a revolving door of strangers can be fatiguing: death by a thousand paper cuts. Developer Nolan Lawson describes his experience as “a perverse effect where, the more successful you are, the more you get ‘punished’ with GitHub notifications.”

The tribalistic nature of open source is frequently overlooked and misunderstood. As we’ve seen from the evolution of “hackers” to the more neutral “programmers” or “engineers,” to the polished-sounding “developers” today, there is no “open source community,” really, anymore than there is an “urban community.” Certainly, one city dweller can sympathize with another in many ways, especially when comparing themselves to their suburban or rural counterparts. But knowing the streets of San Francisco says nothing about how well you’ll fare in Hong Kong. “Urban” is an adjective, not an end point.

there’s no one right way of doing things, just different communities that each have their own cultural norms.

Nathan Marz, who wrote the data-computation system Apache Storm, timed its release with his talk at a software conference called Strange Loop, open-sourcing the project live onstage. The announcement got a lot of attention, and he set up a mailing list for developers to give feedback, where he “spen[t] one to two hours a day answering questions.”82 Over the next year, he continued giving talks about Storm at conferences, meetups, and companies, noting that “all this speaking got Storm more and more exposure.” At this stage, the goal is distribution—getting

Focusing on the relationship between contributors and users, we can think of projects in terms of their contributor growth and user growth. This gives us four production models: federations, clubs, toys, and stadiums.

Magnetic projects are those that attract a large proportion of new contributors. Sticky projects are those where a large proportion of contributors continue to make contributions.

Given the high fixed costs of entry into maintainership, the knowledge required to maintain tends to stay concentrated among one or a few people. The longer they go without externalizing this knowledge, the more difficult it becomes for newcomers to participate.

Mikeal Rogers, who worked on Node.js in the early days, describes this model in his blog post “Healthy Open Source”: The purpose of [Node.js’s contribution] policy is to gain contributors, to retain them as much as possible, and to use a much larger and growing contributor base to manage the corresponding influx of contributions. . . . Avoid creating big decision hierarchies. Instead, invest in a broad, growing and empowered contributorship that can make progress without intervention.

Creators, on the other hand, are tethered to the support that platforms provide, because platforms significantly reduce their costs, enabling them to accomplish far more than they could have on their own.

Coase’s theory of the firm fails to explain why these developers would find one another and make software together, despite a lack of both formal contracts and financial compensation. In terms of transaction costs, collaborating on open source software with unaffiliated individuals should be too “expensive,” compared to writing software with one’s coworkers. But a few people noticed that these open source projects operated like communities, so they instead explained the projects’ behavior by describing them as a commons, meaning a resource that is owned, used, and managed by a community. These communities rely upon self-governed rules, rather than outside intervention, to manage the resource and avoid over-provisioning or depletion.

In the second half of the twentieth century, the economist Elinor Ostrom spent decades studying the conditions that lead to a flourishing commons, such as forests, fisheries, irrigation systems, and other common pool resources.* She tried to understand how people produce in a commons, and why some resources are successfully self-managed, thus avoiding the so-called “tragedy of the commons” (wherein resources are depleted by people acting in their own self-interest, rather than in the collective interest) and the need for either market or government intervention.

Ostrom identified eight design principles that contribute to a well-managed, successful commons: Membership boundaries are clearly defined. The rules that govern the commons should match the actual conditions. Those who are affected by these rules can participate in modifying them. Those who monitor the rules are either community members or are accountable to the community, rather than outsiders. Those who violate the rules are subject to graduated sanctions, which vary depending on the seriousness and context of the offense. Conflicts should be resolved within the community, using low-cost methods. External authorities recognize the right of community members to devise their own institutions. If the commons is part of a larger system, its governing rules are organized into multiple “nested” layers of authority.

Members also have a low discount rate, which is another way of saying they have “skin in the game,” meaning they intend to participate in the community for a while.

A low discount rate also means that members are biased toward cooperation. Like being trapped in an elevator with strangers, if members are all stuck with one another for a while, they’re more inclined to figure out strategies to make things work, such as developing governance processes to handle future disputes.

Early online forums like Usenet and MetaFilter relied upon self-defined social norms to manage community behavior. Contemporary examples of online communities might include Reddit or Facebook groups, where each subreddit or group has a distinct identity and culture.

In the early 2000s, Yochai Benkler expanded upon Ostrom’s model by applying her findings to the online world. He terms this communal structure commons-based peer production (CBPP) in a 2002 essay called “Coase’s Penguin, Or, Linux and ‘The Nature of the Firm.’” (The title is a reference to Linux’s mascot, which is a penguin; in the paper, Benkler leans heavily upon the example of open source software to make his case.) Benkler observed that people were collaborating online for seemingly no obvious reason beyond personal satisfaction. He tried to understand how and why people would do this outside of Coase’s firm (i.e., in their spare time), given that it should be more transactionally expensive.

Unlike companies—which need to solicit, evaluate, hire, and manage employees—the members of a commons simply self-organize based on who wants to do the work most.

in a commons, anyone can stumble upon an advertised task and volunteer themselves. By removing “property and contract,” the commons will theoretically select for the best person for the job at a lower cost.

In terms of coordination effort, it could be less costly to designate one person as the leader, whose job it is to collect information from everyone and keep all the work in one place. But when you have a group of strangers who are loosely affiliated with one another and excited to participate, and nobody is officially in charge, it’s more likely that a bunch of people will volunteer all at once. Intrinsic motivation makes it easier for people to self-organize to achieve the same outcome.