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

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

But just as tweets are easy to read and retweet without context as to who wrote them, code is easy to copy-paste without knowing, or caring, where it came from.

The bigger your project becomes, the harder it is to keep the innovation you had in the beginning of your project. Suddenly you have to consider hundreds of different use-cases . . . . Once you pass a few thousand active users, you’ll notice that helping your users takes more time than actually working on your project. People submit all kinds of issues, most of them aren’t actually issues, but feature requests or questions.84

In comparison to decentralized communities, centralized ones don’t rely as strongly on defined governance processes, because social interactions primarily take place not among regular contributors but between a creator and their users. It’s the creator, rather than their users, who is “responsible for the basic economic structure of the community.”102

Even Wikipedia, the world’s biggest online encyclopedia, and a canonical example of large-scale collaboration, has Steven Pruitt, a volunteer who’s edited one-third of all the English language articles on the site.12

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.

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.

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.

Maintainers simply don’t have the energy to onboard every person who shows passing interest.

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 the absence of additional reputational or financial benefits, maintaining code for general public use quickly becomes an unpaid job you can’t quit.

Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure.

Social norms are passed down through trial and error,

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.

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.

Kazuhiro Yamashita et al. describe contributor retention using the terms “magnet” and “sticky,” which were originally coined by the Pew Research Center to describe population migration trends.96 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.

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

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.

He told me that code is “anarchist” and “untouchable,” and that it must be able to survive beyond any one person’s desires, or their need to pay rent. “It needs to be something that nobody can take away,” he said. “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.

The role of a maintainer is evolving. Rather than coordinating with a group of developers, these maintainers are defined by the need for curation: sifting through the noise of interactions, such as user questions, bug reports, and feature requests, which compete for their attention.

Open source code is public, but it doesn’t have to be participatory: maintainers can buckle under excess demand for their attention.

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.