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

by Nadia Asparouhova

Much of my stress-testing happened from 2016 to 2018, while I was working to improve the open source developer experience at GitHub, a company that offers hosting for open source projects.

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.3 The regular presence of hundreds or thousands of contributors making few substantial contributions, rather than a smaller group of developers making meaningful contributions, throws the idea of “contributor communities” into question.

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

If you use Python’s packaging tools, you’re using code maintained by Donald Stufft.

Nominative determinism strikes again.

GitHub also helped popularize the widespread use of permissive licensing, which significantly improved the reach and distribution of open source code.

Surely Apache did it first?

because JavaScript must maintain compatibility across browsers, its official core library is smaller than that of most other languages. So developers are forced to customize it for themselves, writing their own packages to fill in the gaps. As a result, each project tends to be smaller and more disposable, like LEGO blocks that fit together instead of a castle carved from stone.

I like the metaphor.

Dan Abramov, a maintainer of React, a popular frontend framework, wrote a blog post that lists all the programming topics that “people often wrongly assume that I know.”

The term “open source” refers only to how code is distributed and consumed. It says nothing about how code is produced. “Open source” projects have nothing more in common with one another than “companies” do.

Deferring to one’s community seems to be more obviously aligned with democratic values, but open source’s distributed nature makes that ideal challenging to live up to. If maintainers were to defer to their community, how could they assess overall opinion, given the lack of clear membership boundaries? Countries have citizenships and constituencies, but open source projects are open to anyone. If someone made a one-time contribution to Opal, does that make them a “contributor” in the same sense as a lead maintainer?

There is no universal definition of a maintainer. We could say that it has something to do with having commit privileges, or how frequently someone makes commits. But every definition quickly breaks down across projects, because, like the term “contributor,” “maintainer” is an identity more than a function.

Authors may also accrue extrinsic, social rewards in the form of recognition and reputation. But as the project matures, reputational benefits flatten out: after all, the authors are already known for their affiliation to the project, and spending more time on its maintenance isn’t going to change that. At the same time, reactive work may start to overtake the proactive tasks, while providing neither intrinsic nor extrinsic benefits.

This is the equivalent of a writer being asked to edit and make changes to the same book every day, into perpetuity, long after they’ve reaped the initial financial and reputational rewards from its creation. What’s more, unlike other content, open source code is relied upon by people, companies, and other institutions that need it to keep working, long after the maintainer’s interest has waned. External contributions don’t necessarily reduce the burden of maintenance either, because they still require someone to review and merge them.

Casual contributors are like tourists visiting New York City for a weekend. Just as we wouldn’t expect, or even want, tourists to participate in local governance decisions, we shouldn’t assume that casual contributors are part of a project’s contributor community simply because they are physically present. After studying why newcomers abandon open source projects, researcher Igor Steinmacher et al. conclude, “By reading the discussions initiated by dropouts, we realized that part of the newcomers had no intention to join the project.”

One maintainer, who has created hundreds of popular libraries, described to me what he does when he gets tired of maintaining them. Using a “ghost” admin account that he has purposely forgotten the password to, he transfers his unwanted projects to that account, then removes his main account as administrator. This way, he explained rather cheerfully, nobody will bother him about maintenance, because he cannot access the project anymore, even if he tries. If anybody wants to change the code, instead of bugging him they’ll simply have to fork and maintain it themselves. While this practice works well for him, it illustrates how a popular and widely depended-upon project could have literally nobody at the helm.

The author Neal Stephenson once described Unix as “not so much a product as it is a painstakingly compiled oral history of the hacker subculture. It is our Gilgamesh epic . . . Unix is known, loved, and understood by so many hackers that it can be re-created from scratch whenever someone needs it.”

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.

In practice, software providers understand that the optics of being associated with undesirable content will be detrimental in the long run. Although it is not a “hard” cost of production in the way that physical infrastructure might be (if the software breaks, nobody can access it), community moderation is a “soft” cost that is enforced by social norms (“Ignore these costs at your own risk”).

Much like editing a book versus writing it for the first time, refactoring code is often dreaded and unrewarding work. Since open source developers tend toward work that they find intrinsically motivating, not only are open source projects more susceptible to technical debt but there are also fewer incentives to clean up messy code.

Economist David Friedman tells a joke that goes like this: Two economists walked past a Porsche showroom. One of them pointed at a shiny car in the window and said, “I want that.” “Obviously not,” the other replied.

Economists tell us that we tend to rely on governments to provide our public goods because otherwise they’ll become underproduced over time, meaning that consumers are unlikely to provide them on their own, due to the free-rider problem.

Only an extremely rude person would consider marching up to our neighbor’s house, knocking on the door, and demanding a surfing Santa. But online, it’s considered normal for people to comment on articles and posts with derogatory or demanding things, or to open issues on an open source project, requesting new features or asking for support.

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.

Extractive contributions are those where the marginal cost of reviewing and merging that contribution is greater than the marginal benefit to the project’s producers. In the case of a code contribution, it might be a pull request that’s too complex or unwieldy to review, given the potential upside. Or it might be an enthusiastic user who wants to organize a community event that requires more resources from the project’s developers than it’s worth.

Maintenance costs are anathema to software developers. Every developer tries to reduce the amount of maintenance work they need to do over time. But software is never done, and also never dies: the cost of maintaining a project can be near-zero, but it is asymptotic.

92.3% of contributors to the Linux kernel are paid by an employer, for which the Linux Foundation offers this explanation: “Kernel developers are in short supply, so anybody who demonstrates an ability to get code into the mainline tends not to have trouble finding job offers.”

!! So much for it being hobby projects.