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

by Nadia Asparouhova

Only maintainers are interested in “the success of the whole community rather than that of any special interest within it.”144 While maintainers may do other work for the project, all other work can be performed by other community members, whereas a proprietor’s tasks are reserved for maintainers alone.

contributors to an open source project can be classified as either active or casual, which is often determined based on the frequency of their contributions.

what constitutes a “frequent” contributor varies depending on the project.

Active contributors tend to be somewhat specialized, whether they focus on a specific part of the codebase or contribute their expertise, like security knowledge or managing the community. They’re distinct from maintainers in that they aren’t responsible for the overall direction of the project. While active contributors might care about the community, they’re not expected to make trade-offs between their interests and others’.

Whereas a casual contributor might begin by opening an issue or pull request (“I need something”), for example, an active contributor might start out by commenting on someone else’s issue (“I want to help with something”).159 Another common behavior pattern of active contributors is lurking on mailing lists, issue threads, and pull requests before interacting with the project.

Active contributors who stick around do so not because they successfully made their first contribution, but because they already came in with the intent to stick around. In other words, they were never really casual contributors in the first place.

Casual contributors are in an “I want this fixed, and then I’m done” mindset.

Casual contributors don’t plan on sticking around, and they have the least amount of context regarding the project’s process or norms. They only want to know enough to get their contribution merged. Their primary interest is personal, and it’s the maintainer’s job to figure out how to weigh the contributor’s needs against those of the project.

For maintainers, it’s helpful to think of contributors as falling into these two distinct “tracks,” identifiable based on self-interested versus prosocial motives, so the maintainers can decide how much time they want to spend on a particular contributor, as well as how to tailor the resources and support that they offer.

Generally speaking, maintainers don’t know who their users are. Like lurkers in an online community, users can consume code without necessarily making themselves publicly known.

Of the projects that could track usage, most maintainers don’t bother with it, either due to lack of interest or difficulty of implementation, or perhaps to avoid public controversy.

A project’s bus factor is the number of contributors that would need to get hit by a bus before the project is compromised.

We need to look beyond the total number of contributors, and instead consider contributor quality. Rather than measuring the quality of code that a contributor writes—which would be difficult to objectively evaluate—we could use the quality of a contributor’s reputation as a proxy.

“greenfield” projects—those where a developer gets to write software from scratch—are

The cost of maintenance, coupled with a lack of intrinsic motivation to maintain, is why large open source projects tend to become modular as they grow.

once software finds a set of users, it’s hard for it to ever really disappear. Someone out there is probably going to use that code for a very long time.

ECMAScript is a specification, created and managed by a standards organization called Ecma International. Any changes to JavaScript are discussed and approved by Ecma’s Technical Committee 39, also known as TC39, comprised of companies and organizations that pay for their membership.

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.

In addition to marginal costs, software also requires ongoing maintenance to continue running successfully, regardless of how many people use it. Rather than a function of use, these costs are a function of entropy: the inevitable decay of systems over time.

It’s not just code itself that requires maintenance either, but all the supporting knowledge that surrounds it. When code changes, its documentation must also change.

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.

Open source projects are particularly susceptible to technical debt because they accept contributions from developers who may not necessarily know one another, nor have full context on the project. Scope creep refers to the tendency for software to become bloated over time, because new code additions are evaluated incrementally rather than holistically.

Refactoring is the process by which developers pay down technical debt: rewriting, simplifying, and otherwise cleaning up the codebase without changing its functionality.

Bigger projects might use a monitoring tool like Snyk or SourceClear to scan their code and notify maintainers of known security vulnerabilities, but the maintainers of smaller open source projects, frankly, often can’t be bothered.

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.

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.

Developers are finicky consumers. Not only are they discerning, with a high degree of sensitivity to slight differences between open source projects, but if they don’t like the options presented to them, they’re frequently inspired—and have the ability—to try making their own version.

When explaining why nobody wants to pay for software, people often cite the free-rider problem, which is the idea that if you can’t exclude others from consuming a good they’ll use it without paying. Eventually, the good becomes overused, as producers lack the resources—usually provided by consumers—to supply it.

It’s easiest to see how free-rider problems apply to non-excludable, rivalrous goods, a situation better known as the tragedy of the commons. If a public park is free to access, people will use it without paying for maintenance and upkeep. As more people flock to the park, its quality is diminished.

But when it comes to public goods—i.e., goods that are both non-excludable and non-rivalrous, like software—it’s a bit harder to see where the free-rider problem applies. After all, a thousand people can read the same article, or use the same snippet of code, without diminishing its quality.

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.

When software is in static state, what if there is no free-rider problem? When code is non-rivalrous, it only has first-copy costs, which the creator is intrinsically motivated to provide—so the problem doesn’t seem to lie in how many people consume it.

I’d flip the question to ask: What if, rather than being underproduced, software is actually overproduced? The problem with the Christmas lights isn’t that anyone can drive by and view them. A problem only surfaces if we think our neighbor owes us anything; if we cross the invisible boundary and knock on his door, making demands and requesting changes.

In open source, anybody should be able to not only view, download, and fork open source code, but also to witness the interactions between members. There’s no reason to prevent users from accessing any of this information, so long as they don’t appropriate attention from producers.

There are two types of funders that care enough to spend money on open source: institutions (usually companies, but also governments and universities) and individuals (usually developers who are direct users).

Companies are mostly interested in open source code itself as a “product” or commodity. As a result, companies tend to value benefits like code quality, influencing the project’s roadmap, and brand association.

Companies will also pay for influence and access to a project they care about. It can be difficult for a company to attract the attention of a project’s maintainers; they find it frustrating when issues and pull requests go unanswered.

Patronage is an emerging funding system for online creators today,

When it comes to vetting funding opportunities for open source, Ostrom’s principle of seeking “high context, low discount rate” opportunities serves us well. It’s not a company’s or individual’s job to fund every open source project that they use. But some projects will mean more to certain funders than others, and those are the best opportunities to pursue.

But if there’s a particular project that they happen to love, that’s the one they should pursue. Likewise, it’s the job of an open source developer to make themselves top-of-mind to a targeted set of funders instead of boiling the ocean.

the Django Foundation raised money to create a Django Fellowship program.

For precisely this reason, Open Collective, the aforementioned platform used by Vue.js to collect funds, offers a lightweight way to legally accept, manage, and disburse funds.

From a governance perspective, funding individual developers is better aligned with the distributed nature of open source projects. To some developers, the fact that these projects aren’t managed by formal organizations is a feature, not a bug. Funding individuals means that funding can come from multiple sources, that funding decisions are made based on the contributions of that particular individual, and that developers can join or leave without toppling the whole project.

When GitHub launched its Sponsors product in 2019, the platform encouraged users to financially support the “developers, maintainers, writers, teachers, and programmers” that they depend on.