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

by Nadia Asparouhova

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.

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.

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.

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.”

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.

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.

Before dependency managers, publishing an eight-line code library would have been unthinkable: too much overhead for too little benefit. But NPM [JavaScript’s package manager] has driven the overhead approximately to zero, with the result that nearly-trivial functionality can be packaged and reused.

By connecting towns to one another, highways change communities’ underlying social structure. Highways enable migration and cross-pollination of ideas. Without highways, residents tend to stay in the towns they grew up in. When these pathways are opened, collective identity is eroded. Instead of “competing for status in small tribes,” people find themselves “dropped into a talent show,” competing against strangers.

It’s tempting to attach a host of assumptions to casual contributors—that they are unfamiliar with open source, new to the project, demanding, destructive—but it’s better to simply think of them as self-oriented rather than communally oriented. A casual contributor seeks a resolution to their own problem; that their contribution might benefit others is merely a positive externality.

While software does have lower marginal costs compared to material goods, like cars or houses, its actual costs depend on whether we’re viewing it in active or static state. Code, in static state, can be bought and sold at nearly zero marginal cost. When maintenance is involved, however, software’s marginal and temporal costs begin to add up.

while governments provide public goods and services in our physical world, it’s much more difficult for them to serve this same role in our online world. Open source code is transnational, affecting developers and users across many different countries, whereas governments are beholden to national interests (such as national security). And the world of software moves so fast that the law can’t keep up.

Van Rossum’s suggestion highlights the critical difference between content that is public and content that is participatory. Content can be made available for anyone to read and consume, but that doesn’t mean it needs to be open for anyone to participate. Much of the fatigue that open source developers experience comes not from making their code public but from expectations around making their code participatory.

Open source code, in static state, is a public good, meaning that it is both non-excludable and non-rivalrous. Like my neighbor’s Christmas decorations, if it can be consumed at nearly zero marginal cost we should just let people have it. The value of this code can be measured like any other type of infrastructure: by its number of dependencies, as well as by its substitutability. The production of open source code, however, functions more like a commons—meaning that it is non-excludable and rivalrous—where attention is the rivalrous resource. Maintainers can’t stop users from bidding for their attention, but their attention can be depleted.

To reduce the over-appropriation of attention in open source software, we can think of its production as a one-way mirror, where we design for the parasocial, or one-sided, relationships that are endemic to stadiums, rather than for the interpersonal relationships that are associated with clubs.

Typically, a common pool resource is both produced and consumed solely by its members: a closed system of users who are also contributors. But online content can also be consumed at no cost by outsiders. The ability of non-members to consume code should be treated as a positive externality, rather than a sign that they are part of the community. Tourists are allowed to visit Paris, but they’re not Parisians.

Our relationship to content matters less than our relationships to the people who make it. As a result, we’re starting to treat content not as a private economic good but as the externalization of our social infrastructure.

Our social platforms were built for distributed, small-scale, many-to-many use cases: the quaint social world of yesteryear. They were modeled after internet forums, chat groups, and mailing lists, because these were the only blueprints that we had for our online social infrastructure.

In a two-sided market, paying subscribers subsidize all of the content for nonpaying readers, under the assumption that creators aren’t actually selling content but a sense of membership and identity. Instead of charging, say, all 100,000 readers ten cents to read an article, creators can instead give away the article for free, but charge 1,000 extra-dedicated subscribers ten dollars per year.