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

by Nadia Asparouhova

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.

A few of the conditions that Benkler identifies as necessary to pull off commons-based peer production are intrinsic motivation, modular and granular tasks, and low coordination costs.

When it’s unclear where to draw community boundaries, voting systems don’t work very well, because there’s no way to know whether those votes are representative of the total population.

Consensus-seeking emphasizes discussion over enumeration: “Rough consensus is achieved when all issues are addressed, but not necessarily accommodated.”

Being a contributor is a form of identity, regardless of the contributions one has made to a project. Like joining a club, it’s not about how many times you’ve attended meetings but how you self-identify, and how others identify you, that makes you a “member.” Some attendees might come every week for years and still not be considered part of the group.

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.

At their worst, however, active users can be pushy, putting stress on the project by demanding work, or providing other users with “unofficial” answers that are outdated or inaccurate.

😬 this is my fear

To the untrained eye, writing software appears to be all about the new and shiny, free from the earthly troubles of working with atoms rather than imaginary bits. In practice, software ages quietly, in the shadows, and stubbornly refuses to die.

It’s easy to write off the cost of newness as unnecessary, compared to the more urgent costs of maintenance, but good stewardship of infrastructure requires the foresight of innovation.

To identify problems of organized complexity, Timothy Patitsas, a theologian who builds upon Jacobs’s work, paraphrases a heuristic from urban ministry practitioner Douglas Hall: “The question is, are you dealing with a toaster or a cat? . . . Can you take it apart and put it back together? It’s a toaster. If you take it apart, do you belong in jail? That’s a cat.”242

Hahahaha that metaphor will stick

Similarly, treating code as a living organism does not replace the idea of software as a commodity. Rather, it’s that software can be understood as both artifact and organism.

By setting up automated tests and workflows for building, testing, and deploying code, maintainers can feel more confident about merging contributions from unfamiliar developers, so long as they pass the checks. And contributors can feel more confident about submitting changes to a project they might not be deeply familiar with.

In both cases, Guo and Vieira acknowledge that pull requests can function more like comments or suggestions. These contributions can still provide helpful inspiration to the maintainer, without the technical and social coordination work that comes with merging others’ code into their project.