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

by Nadia Asparouhova

Then we hit a snag. Suddenly, there was too much information. Too many notifications made us want to check them less. Too many social interactions made us want to post online less frequently. Too many emails made us not want to answer. We were, effectively, DDoSing one another: the term for a distributed denial-of-service attack, in which malicious actors overwhelm their target by flooding it with traffic, leaving the victim incapacitated. Our online public lives became too much to handle, causing many of us to shrink back into our private spheres.

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.

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.

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.

The npm ecosystem—which, according to its parent company, makes up an estimated 97% of the code in modern web applications today—offers some clues to the future.8 Npm, which stands for Node Package Manager, is the platform commonly used by JavaScript developers to install and manage packages, or libraries. (Libraries are prewritten bits of code that other developers can use, instead of having to write the same code from scratch. The ability to legally reuse other people’s code is what allows software developers to work more quickly and efficiently today.)

In contrast to big, monolithic software projects that give rise to persistent communities, npm packages are designed to be small and modular, which leads to fewer maintainers per project and a transitory relationship with the code they write. Viewed in this light, the lack of contributors today reflects an adaptation to changing environmental circumstances, wherein the relationship between a maintainer, contributors, and users is lighter, more transactional.

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.

Increasingly, our online worlds are being built by individuals, not just communities.‡ As one Reddit user observes, If you read reviews on Amazon, you’re mostly reading reviews written by people like Grady Harp. If you read Wikipedia, you’re mostly reading articles written by people like Justin Knapp. . . . And if you read YouTube comments, you’re mostly reading comments written by people like Justin Young. 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.11

Rather than the users of forums or Facebook groups, GitHub’s open source developers have more in common with solo creators on Twitter, Instagram, YouTube, or Twitch, all of whom must find ways to manage their interactions with a broad and fast-growing audience. Instead of facing one another, as pop culture critic Mark Fisher allegedly once put it, a creator’s audience now faces the stage.

Early internet activity was characterized by large-scale, distributed online communities: mailing lists, online forums, membership groups. These communities operated as a cluster of villages, each with its own culture, history, and norms. 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.

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.

JavaScript’s most recognizable developers are known for the talks they give, the videos they record, the tweets and blog posts they write. They command large followings and attract eager audiences in a way that, say, PHP developers just don’t. Kent C. Dodds, for example, spent so much time making content about React that he left his job as a JavaScript engineer at PayPal to become a full-time educator.45

JavaScript developers aren’t always known for a specific project anymore, either, the way Stallman is known for GNU, or Torvalds is known for Git and Linux. Rather than being associated with just one project, or a few, prominent JavaScript developers often create hundreds of small yet widely used projects. They’re known for who they are, rather than which projects they’re involved in.

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.

To borrow again from conservation biology, maintainers can be thought of as a keystone species. A keystone species is small in population size but has an outsize impact on its ecosystem. If we were to imagine a forest, for example, while there may not be many wolves in absolute numbers, if the wolves disappeared there would be cascading effects on the rest of the forest. The deer population, lacking a natural predator, would grow out of control, the plants would start to disappear because there would be too many deer, and so on.