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

by Nadia Asparouhova

That many open source developers suffer from a lack of support is indisputable.

Many open source developers are not directly paid for their work, despite generating trillions of dollars in economic value. In the absence of additional reputational or financial benefits, maintaining code for general public use quickly becomes an unpaid job you can’t quit.

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: literally, anybody with an internet connection who cares to comment on their code. The lack of financial reward is a symptom, perhaps, of misaligned incentives, but this inevitable cycle of churn seems to hint at something deeper.

However, in speaking to maintainers privately, I learned that these initiatives frequently cause them to seize with anxiety, because such initiatives often attract low-quality contributions.

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. Maintainers simply don’t have the energy to onboard every person who shows passing interest. Many told me they were frustrated by prior attempts to cater to a revolving door of contributors—sometimes hundreds of them—who didn’t stick around. Maintainers recounted how those who’d expressed interest sometimes disappeared before they’d even submitted their first contribution.

One study found that, in a sample of 275 popular GitHub projects across various programming languages, nearly half of all contributors only contributed once. These contributors accounted for less than 2% of total commits, or overall contributions.

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. From the perspective of these maintainers, quietly tending to their code on the prairie amidst the tumbleweeds of unanswered issues, the world doesn’t look like the utopian vision, embraced by early internet pioneers, of large-scale collaboration among strangers. If anything, it looks like exactly the opposite of what these early advocates predicted.

When speaking to first-time and casual contributors about their experiences, I found their stories just as enlightening as those of maintainers. Casual contributors are often aware that they have little context for what is going on behind the scenes of the project. But more importantly, they do not want to spend time familiarizing themselves with a project’s goals, roadmap, and contribution process. These developers primarily see themselves as users of the project; they do not think of themselves as part of a “contributor community.”

Maintainers also rely on platforms—namely, GitHub—and tools—such as bots that help with managing issues, notifications, and code quality—to keep up with their work.

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.

That so much information is now freely available at our fingertips is one of the most important wins of the digital age. More importantly: it’s not the excessive consumption of code but the excessive participation from users vying for a maintainer’s attention that has made the work untenable for maintainers today.

While social media, news, and entertainment all serve critical public roles in our lives, we directly rely on open source code to keep our phones, laptops, cars, banks, and hospitals running smoothly. If a YouTube video goes down, we might lament the loss of valuable knowledge, but if an open source project goes down, it can literally break the internet (as we’ll see in Chapter

In open source, you can only have “my” in the associative sense. There is no possessive “my” in open source.

Members of this generation aren’t aware of, nor do they really care about, the distinction between free and open source software. Neither are they fired up about evangelizing the idea of open source itself. They just publish their code on GitHub because, as with any other form of online content today, sharing is the default.

Python doesn’t necessarily need GitHub for discovery anymore, but as a mature project the programming language especially benefits from GitHub’s cost-reducing infrastructure.

The fact that today’s developers don’t just use, but actively prefer, GitHub suggests a different set of values from previous generations. The simple act of using GitHub already separates these developers from the most dogmatic free software advocates, who refuse to use the platform whatsoever. 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.

The locus of open source culture has shifted from celebrating heavy-handed authoritarianism to seeking out thoughtfulness and stewardship.

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. `¯\_(ツ)_/¯`

They don’t know how open source works, and they’ve been told that they’re doing the right thing by asking questions. “Don’t let this be a deterrent for you to contribute though,” Sorhus himself added.

But the fact that GitHub became the preferred platform for most developers, overcoming initial opposition that bordered on religious fervor, suggests that maybe platforms do a lot more for creators than we realize. Instead of treating platforms as adversaries, we might think of platforms as powerful allies for creators, and try to understand the strange, symbiotic relationship they’ve formed with one another.

Open source is complicated because it contains a messy mix of both technical and social norms, most of which play out in public. It is documented extensively (nearly every decision is written down somewhere) but not clearly (you have to dig through years of mailing list archives to find what you need). Its treasures are hidden amidst a tangle of brambles and thorns.

Developers don’t contribute to open source for lack of technical ability, but rather due to fear of committing a faux pas.

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.

The idea is to distribute the burden of maintenance by making it easy for others to contribute, and it’s assumed that strangers are trustworthy until proven otherwise.

A project’s contributor growth is a function of its technical scope, support required, ease of participation, and user adoption.

One infrastructure developer, who worked for years on projects with different tooling, told me that he’s now so used to GitHub that if he finds a bug on a project that uses a different issue tracker, he won’t even bother filing an issue anymore—it’s too much work.

Similarly, in the online world, centralized communities tend to form around individual creators, who “[facilitate] every activity represented in the community by the act of providing space for it,” and who are thus tasked with maintaining its function.100 The community exists because the creator has provided something for people to gather around.

Benkler observed that people were collaborating online for seemingly no obvious reason beyond personal satisfaction.

Benkler reasons that if individuals are personally motivated to do something, coordination costs will be lower.111 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.

Benkler proposes that, in order to keep people motivated, tasks must be modular and granular: When a project of any size is broken up into little pieces, each of which can be performed by an individual in a short amount of time, the motivation necessary to get any given individual to contribute need only be very small.

Modularity refers to how the project is organized. Can it be broken into clear subcomponents, and do they fit easily back together? Granularity refers to the size of each module. It should be easy for anyone to jump in and complete the task without too much preexisting knowledge.

Although the commons might not be as profitable as the firm, it’s also more resilient, because the currency of its transactions is the desire to participate, rather than money.

“Our credo is that we don’t let a single individual dictate decisions (a king or president), nor should decisions be made by a vote.”132 In a consensus-seeking model, the goal is not to “win” votes or come to a unanimous agreement, but rather to ensure that there’s a forum for people to raise and discuss their concerns, and that nobody feels strongly enough to block the group from moving forward. Consensus-seeking emphasizes discussion over enumeration: “Rough consensus is achieved when all issues are addressed, but not necessarily accommodated.”

They might prefer the freedom of making video tutorials or organizing events on their own terms, without the additional overhead of coordinating with other contributors.