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.

faced with growing demand, an open source “maintainer”—the term used to refer to the primary developer, or developers, of a software project—needs to find more contributors.

However, in speaking to maintainers privately, I learned that these initiatives frequently cause them to seize with anxiety, because such initiatives often attract low-quality contributions.

a genuine conflict between wanting to encourage newcomers to participate in open source and feeling unable to personally take on that work.

Maintainers simply don’t have the energy to onboard every person who shows passing interest. Many told me they were frustrated by prior attempts to cater to a revolving door of contributors—sometimes hundreds of them—who didn’t stick around.

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.

We assume that open source projects need to grow strong contributor communities in order to survive.

the bus factor, where project health is measured by the number of developers that would need to get hit by a bus before the project is in trouble.

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.

hackers believe in sharing, openness, and decentralization, which he calls the “hacker ethic.”

hackers care about improving the world, but don’t believe in following the rules to get there.

Hackers are characterized by bravado, showmanship, mischievousness, and a deep mistrust of authority.

“The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary,”

Torvalds is still the only person who’s allowed to merge those contributions into the main project.

Is Torvald’s a better or worse BDFL than Mullenweg? He’s forthright in his speech, but is that a good thing?

The locus of open source culture has shifted from celebrating heavy-handed authoritarianism to seeking out thoughtfulness and stewardship.

Open source is complicated because it contains a messy mix of both technical and social norms, most of which play out in public. It is documented extensively (nearly every decision is written down somewhere) but not clearly (you have to dig through years of mailing list archives to find what you need). Its treasures are hidden amidst a tangle of brambles and thorns.

Social norms are passed down through trial and error, which means that getting something wrong runs the risk of embarrassment and mockery in front of one’s peers. Developers don’t contribute to open source for lack of technical ability, but rather due to fear of committing a faux pas.

While this is theoretically true, in practice open source is not blindly open to every person who wants to change it.

Bigger projects often use a formal “request for comments” (RFC) process to allow communities to discuss these changes before they are merged.

Debian, an operating system based on Linux, requires that developers follow an extensive onboarding process in which they are expected to read a manual, find a mentor, and meet a maintainer in person who can vouch for their identity.71 On the other hand, it’s common among JavaScript developers to give away commit access more freely.

A company, for example, might release open source code but rely primarily on its own employees to maintain it. Although the project is open source in the sense that anybody can use, inspect, fork, and modify the code, it might be difficult to make substantial contributions as a non-employee. Anybody can submit a change, but that doesn’t mean it will be approved.

By contrast, WP-CLI, a command-line interface for the popular content management system WordPress, requests the exact opposite in its README: Please do not ask support questions on Twitter. Twitter isn’t an acceptable venue for support because: 1) it’s hard to hold conversations in under 280 characters, and 2) Twitter isn’t a place where someone with your same question can search for an answer in a prior conversation.

A project’s contributor growth is a function of its technical scope, support required, ease of participation, and user adoption.

Technical scope refers to the size and complexity of a project’s codebase: in other words, how much more there is to do. A project that feels feature-complete won’t attract as many contributors as one that’s extensible and customizable. It could be widely used, but that doesn’t mean there’s a lot to contribute to.

Focusing on the relationship between contributors and users, we can think of projects in terms of their contributor growth and user growth. This gives us four production models: federations, clubs, toys, and stadiums.

Federations are projects with high contributor growth and high user growth. These are the “bazaars,” first described by Eric S. Raymond, which we typically think of when we imagine an open source project.

Federations also often employ an RFC (request for comments) process, similar to a ballot initiative, to manage major change proposals to the project.

Clubs are similar to meetup or hobby groups: they attract a narrow group of users, who then also become contributors because they have higher context for the project’s activity and feel a sense of affinity to the group.

Many widely depended-upon packages and libraries fit into this model, including webpack, Babel, Bundler, and RSpec. Stadiums are becoming increasingly commonplace today.

Decentralized communities are defined by many-to-many interactions, but centralized communities have a one-to-many social structure.

if we think about who supplies labor to an open source project, it’s “expensive” to onboard new maintainers, because maintenance often requires knowledge that isn’t easily externalized to others. So newcomers tend to make casual contributions, instead of pitching in on more complex tasks around project management.

But a few people noticed that these open source projects operated like communities, so they instead explained the projects’ behavior by describing them as a commons, meaning a resource that is owned, used, and managed by a community. These communities rely upon self-governed rules, rather than outside intervention, to manage the resource and avoid over-provisioning or depletion.

Ostrom identified eight design principles that contribute to a well-managed, successful commons: Membership boundaries are clearly defined. The rules that govern the commons should match the actual conditions. Those who are affected by these rules can participate in modifying them. Those who monitor the rules are either community members or are accountable to the community, rather than outsiders. Those who violate the rules are subject to graduated sanctions, which vary depending on the seriousness and context of the offense. Conflicts should be resolved within the community, using low-cost methods. External authorities recognize the right of community members to devise their own institutions. If the commons is part of a larger system, its governing rules are organized into multiple “nested” layers of authority.110

Members also have a low discount rate, which is another way of saying they have “skin in the game,” meaning they intend to participate in the community for a while.

Additionally, at a company, only employees can do the work, limited by their job function. But in a commons, anyone can stumble upon an advertised task and volunteer themselves. By removing “property and contract,” the commons will theoretically select for the best person for the job at a lower cost.

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.

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.

Coordination work is expensive because it’s not intrinsically motivated. (For example, developers tend to be more excited about writing code than reviewing someone else’s contribution.) And, as anyone who’s tried to delegate work has probably noticed, it’s usually faster to do things yourself than to train someone else to do it.

Stadiums have one or a few maintainers, who are surrounded by casual contributors and users.

Decentralized communities prioritize work based on abundance of attention: encouraging new contributors, developing governance processes, and improving engagement and retention.

But a creator prioritizes work based on scarcity of attention: saying no to contributions, closing out issues, reducing user support. While the commons is tasked with resolving coordination issues, creators are defined by the need for curation.

Can the management of open source projects accommodate the increasing number of contributors? The frequency and quality of contributions to each of the open source projects studied appears to be highly skewed, with a few individuals (or at most a few dozen) accounting for a disproportionate amount of the contributions, with most programmers making just one or two submissions. . . . If large numbers of low-quality contributions are becoming increasingly common, there may be substantial management challenges in the future.

In order for sanctions to be effective, for example, communities need cohesion. But if developers don’t see themselves as “members” of a community, they might not necessarily mind being shamed or kicked out, and may indeed even thrive on such conflict.

This may be why many hosts in the WordPress space aren’t contributing to Matt’s standards.

defining membership boundaries in an open source project turns out to be one of the hardest problems to solve.

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?

“Because newcomers have not yet developed commitment to the group and have not yet learned how the group operates, it is rational for established group members to distrust them.”

Sometimes, the term “maintainer” is used interchangeably with “core developer,” which raises another question: Do maintainers write new code, or simply tend to the existing code? The term “maintenance” seems to imply reactive work, whereas “core development” implies proactive work. Maintaining a minimum degree of functionality might include tasks like responding to issues, reviewing pull requests, and upgrading software dependencies. But actively evolving the project would require tasks like defining the vision of the project, writing new features, and reducing “scope creep” (not letting in too many features, which eventually bloat the purpose of the project).