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

by Nadia Asparouhova

What I am saying is that this emerging third model is (a) distinct from [markets and firms], and (b) has certain systematic advantages over the other two in identifying and allocating human capital/creativity.112

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.

Benkler proposes that, in order to keep people motivated, tasks must be modular and granular: When a project of any size is broken up into little pieces, each of which can be performed by an individual in a short amount of time, the motivation necessary to get any given individual to contribute need only be very small.116

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.

When the costs of coordination outpace the benefits, the commons breaks down as a useful production model.

David Heinemeier Hansson, who created Ruby on Rails, is a vocal advocate for a commons-based approach to open source production: External, expected rewards diminish the intrinsic motivation of the fundraising open-source contributor. It risks transporting a community of peers into a transactional terminal. And that buyer-seller frame detracts from the magic that is peer-collaborators.

Anthropologist Michael Wesch uses the term “context collapse” to describe how YouTube’s wide reach affects how people present themselves online. Instead of having in-person interactions, which occur within a specific context, YouTube creators experience “an infinite number of contexts collapsing upon one another into that single moment of recording.”

online communities experienced their own version of context collapse when platforms turned the “panopticon” upon itself, inducing a flood of newcomers, spectators, and drive-by visitors. The collective identity of communities was reduced in favor of personal identity, with individuals acting as free agents.

This problem is especially difficult to deal with because social sanctions . . . may either have no effect, or, in the case of trolls, may actually increase their activity.”

In recent years, it’s become more common for open source projects to have codes of conduct. This decision sometimes leads to emotionally charged discussions between those who see codes of conduct as politically motivated and others who don’t understand how enforcing civil behavior could possibly be controversial. At the heart of these conversations lies a question of who has the authority to make and set policies for a given community.

But what defines an outsider in open source, when any developer is supposed to be able to participate? If everybody is a potential contributor, who gets to make, enforce, and follow the rules?

Kraut and Resnick further suggest that successful online communities need to “designate formal sanctioning rules so that those imposing sanctions have legitimacy,” noting that this role typically falls upon moderators or administrators, who are “less likely to generate drama or retaliation than the same message coming from someone without a formal role.”

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? How do we know if the developers opposing or favoring action represent a minority voice, if we don’t know the actual population of the community?

The Internet Engineering Task Force (IETF), which develops the standards behind our internet protocols, uses what it calls “rough consensus” to reconcile the tension between authoritative and democratic governance, given a hard-to-define constituency: “Our credo is that we don’t let a single individual dictate decisions (a king or president), nor should decisions be made by a vote.”132 In a consensus-seeking model, the goal is not to “win” votes or come to a unanimous agreement, but rather to ensure that there’s a forum for people to raise and discuss their concerns, and that nobody feels strongly enough to block the group from moving forward. Consensus-seeking emphasizes discussion over enumeration: “Rough consensus is achieved when all issues are addressed, but not necessarily accommodated.”

Developer Kent C. Dodds proposed a standard called All Contributors for “recognizing contributors to an open source project in a way that rewards each and every contribution,” complete with an emoji key to display these types of contributors in the README file of a project.

The project description for All Contributors reads, “Recognize all contributors, not just the ones who push code.”

In the surgical-team model, there is a “chief programmer,” who, like a surgeon, sets the project’s specifications and design. The surgeon has a “copilot,” who serves as their confidante and right arm. Then there are a number of supporting roles, including someone who handles money and administration, someone who writes documentation, and so on.

We can return to Spencer Heath MacCallum’s idea of “proprietary communities” to understand what a maintainer does differently from other contributors. MacCallum suggests that a proprietor serves three functions: selection of members, land planning (in the case of open source, “land” is the codebase), and leadership. Member selection and land planning occur whenever maintainers review pull requests from new contributors. They must choose contributors “with a view to their compatibility and complementarity with other members,”143 and they accept contributions based on how they affect the rest of the code.

After Jim Weirich, a prominent open source developer in the Ruby community, passed away, the community realized he had not named a successor to many of his projects. When another developer, Justin Searls, wanted to step in to maintain one of those projects, Rspec-Given, he wasn’t able to gain administrative access. Instead, he had to fork the project and convince RubyGems, the package manager for Ruby, to point to the new version.

The distinction between “author” and “maintainer” also underscores the inherent tension between creating and maintaining software. Some developers love to make things, but they don’t like maintaining them.

While contributors are sometimes described as moving through a “funnel” from user —> casual —> active —> maintainer, there’s evidence that incentives to participate differ between casual and active contributors from day one.

Minghui Zhou and Audris Mockus, in their study of long-term contributors on Mozilla and GNOME, found that “joiners who start by commenting on instead of reporting an issue or ones who succeed to [sic] get at least one reported issue to be fixed, more than double their odds of becoming a long-term contributor.”

However, the extent to which casual contributors affect projects today is a newer phenomenon, a direct byproduct of GitHub’s platform effects. By lowering the friction to contribute, combined with the exponential growth in users of open source projects, GitHub has created the ideal conditions for casual contributors to flourish.

A project’s bus factor is the number of contributors that would need to get hit by a bus before the project is compromised. For example, if a project has a bus factor of 1, that means there is only one maintainer, who, if they were hit by a bus, would take all their knowledge of the project to their grave. The implication is that projects with higher bus factors are more resilient, because knowledge is distributed among more people.

as Fred Brooks notes in The Mythical Man-Month, “Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them”—in

Code is nearly free to distribute, but maintenance can still be expensive. Although it’s not immediately visible from the code itself, software does incur a hidden set of costs over time.

“One of my hypothesis [sic] is that species of technology, unlike species in biology, do not go extinct. When I really look at supposed extinct species of technology, I find they still survive in some fashion. A close examination of by-gone technologies shows that somewhere on the planet someone is still producing it.” —KEVIN KELLY, “Immortal Technologies”

Fergus Henderson, a software engineer at Google, states that “most software at Google gets rewritten every few years.”

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 is not a product to be bought and sold so much as a living form of knowledge.

But not all old code is actively depended upon, even if it continues to exist. For example, the code used to manage Apollo 11’s command and lunar modules, first written in 1969, was published on GitHub in 2016, meaning that it is still publicly accessible today.193 We can view, fork, and modify Apollo 11’s code, but it’s widely understood that the code is archival. The code that is available on GitHub was digitized from a hard copy that lives in the MIT Museum; it’s not expected that anyone will run it today.

Open source code derives its value not from its static qualities but from its living ones.

When Richard Stallman first described free software as “free as in speech, not free as in beer,” the distinction he wished to make is that the term “free” referred to what one could do with the software, rather than to its price.

Jacob Thornton, the developer who cocreated Bootstrap, suggested that open source is, instead, “free as in puppy”: Open-sourcing something is kind of like adopting a cute puppy. You write this project with your friends, it’s really great, and you’re like, “OK, like I’ll open-source it, it’ll be fun! Like, whatever, we’ll get on the front page of Hacker News.” . . . And it is! It’s super fun, it’s a great thing. But what happens is, puppies grow and get old, and pretty soon . . . your puppy’s kinda like a mature dog . . . . and you’re like, “Oh my god, so much time is required for me to take care of this thing!”

It’s unsurprising that free and early open source developers like to talk about the freedom to fork. Forking is a useful exit strategy when we ignore the dependencies and upkeep required by the project in question. In reality, a widely used project makes itself unforkable because it’s become more than just the code.

Maintenance costs typically fall onto the creator but, as we’ve seen, are not intrinsically motivated.

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.

Donald Stufft, who maintains the Python package manager PyPI, estimates that its infrastructure costs two to three million dollars per year in hosting, donated by Fastly.

This scale creates additional challenges, because when a system processes trillions and trillions of requests, events that normally have a low probability of occurrence are now guaranteed to happen and must be accounted for upfront.

there are marginal costs associated with the developer tools used to maintain software. For example, developers might use error-monitoring software like Sentry, configuration management tools like Puppet or Chef, or incident-response tools like PagerDuty, all of which are priced according to usage.

Dewitt Clinton, a product manager at Google, explains the problem as such: If you have a billion users, and a mere 0.1% of them have an issue that requires support on a given day (an average of one support issue per person every three years), and each issue takes 10 minutes on average for a human to personally resolve, then you’d spend 19 person-years handling support issues every day. If each support person works an eight-hour shift each day then you’d need 20,833 support people on permanent staff just to keep up.

Eric S. Raymond once coined the aphorism “Given enough eyeballs, all bugs are shallow.”

Maintenance makes up a significant aspect of software’s hidden costs. A 2018 Stripe study of software developers suggested that developers spend 42% of their time maintaining code.220 Nathan Ensmenger, the informatics professor, notes that, since the early 1960s, maintenance costs account for 50% to 70% of total expenditures on software development.221

JavaScript’s package manager, has more packages than any other popular package manager: over 1 million packages, compared to the 153,000 packages in RubyGems (Ruby’s package manager) and the 175,000 packages in PyPI (Python’s package manager).

Adding a package as a dependency outsources the work of developing that code—designing, writing, testing, debugging, and maintaining—to someone else on the internet, someone you often don’t know. . . . . . . . We are trusting more code with less justification for doing so.

Developer Ben Lesh once tweeted, “Open Source is such a strange thing. The open source work I do is clearly the most impactful work I do, but no one wants to pay me to work on it. Yet I’m asked to speak about it, and the work I’m actually *paid* to do no one really wants to hear about. ”

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. The rules of the “information economy,” like patents and licenses, lend themselves well to commoditized content, but when content is a living organism its value is better measured in terms of people and relationships. This innate duality—software visible as both a fixed point and a line—is at the heart of today’s conflict around how we value not just software but online content more broadly. Is software worth nothing, or is it indispensable to society? The answer is both.

Infrastructure is recursively defined by public consensus. It’s the set of structures that we’ve collectively decided are most valuable in any given moment, and, therefore, its boundaries and definitions are expected to change over time.

Open source code also tends to be a highly elastic good, meaning that its consumers are sensitive to price changes and restrictions, and will happily switch to a competitor if needed. (Airline tickets, for example, are an elastic good, while health insurance is inelastic.)

Like dependencies, the reputation of a developer is a dynamic property, based on their past and expected future value, viewed through the eyes of others.