Open Path

The Case for an Institution

Over on GitHub we’ve (mostly) converged on “Software Commons” as our answer to Adam Jacob’s call to find a brand name other than “Open Source” to represent the values behind such efforts as FSL. What we’re less clear on is what exactly it is we are naming. What are our goals?

There’s a “thin” version in which our goal is to produce an educational website, and a “thick” version in which we are founding (or joining with?) an institution. The thick version would obviously be a much more serious commitment, so it needs justifying. That’s what I aim to do in this post.

• I start by discussing what it means to think about software as a commons; then
• I talk about the ways a software commons can fail; then
• I present a case for why an institution is necessary to protect against these risks.
• I conclude with a brief sketch of what this institution might look like.

Software as a Commons

Economists classify goods based on excludability (is it widely accessible or no?) and rivalry (is it lost in consumption or no?):

• public goods—non-excludable, non-rivalrous
• common-pool resources—non-excludable, rivalrous
• club goods—excludable, non-rivalrous
• private goods—excludable, rivalrous

In which class is society’s shared software?

Software itself is an information good, so its excludability depends on whether it is public. To quote Thomas Jefferson:

If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it.

The excludability of information in general and software in particular is implemented not at the natural level, but at the technological and cultural levels, through information security practices and intellectual property law. The law makes possible a wide range of degrees of excludability. By nature, though, published software is non-excludable.

Information goods are also, by their nature, non-rivalrous. “You can’t download a fish a billion times,” I’ve heard Andrew Nesbitt say, to make the point that you can download a software package a billion times. Jefferson proceeds from the above quotation to make a similar point. This is his famous candle analogy:

[An idea’s] peculiar character, too, is that no one possesses the less, because every other possesses the whole of it. He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me. That ideas should freely spread from one to another over the globe, for the moral and mutual instruction of man, and improvement of his condition, seems to have been peculiarly and benevolently designed by nature[.]

Information as such, then, and software as an instance, is a public good: non-excludable and non-rivalrous. But this misses something crucial, which Nadia Asparouhova has described as two “states” of software (Working in Public, p. 121).

• static—bits on GitHub waiting to be downloaded at negligible marginal cost; and

• active—demands piling up in GitHub Issues waiting for the maintainer to find time for them.

The rivalrous resource in software as a commons is maintainer attention (p. 161). “Open Source is consumed like a public good, [but] produced like a commons” (p. 212). This distinction is essential to thinking clearly about software as a commons.

Enclosure and Tragedy in Software

Because a commons is non-excludable yet rivalrous, its caretakers must in general balance against two risks:

• enclosure—failure through exclusion, too many restrictions; and
• tragedy of the commons—failure through overuse, too few restrictions.

What do enclosure and tragedy of software as a commons look like? Keep in mind the distinction between software as a non-rivalrous information good and maintainer attention as a rivalrous resource. Both matter.

Enclosure of Information

Considered as an information good, software enclosure means dialing up exclusivity via licensing restrictions past some threshold. I say “some threshold” because, as mentioned above, intellectual property law makes possible a wide range of rights sharing, and there’s an art and a negotiation to deciding at what point in the range we’ve passed from acceptable to unacceptable restriction on user freedom.

Open Source itself allows for some restrictions, for example:

• on non-attributed use;
• on non-shared-alike use; and
• on patent litigation.

Open Source draws the line where it does because of its value system: the freedom of users overrides the needs of maintainers. Attempts by companies to change an Open Source project’s license to a more restrictive license generally demonstrate the power of Open Source. If there is a real third-party community around the project, a viable fork emerges.

Since we value maintainer needs on par with user rights, we are open to drawing the line of acceptable restriction differently. In the spirit of Jacob Kaplan-Moss’s “Paying people to work on open source is good actually” (but declining to muddy the term Open Source), we want to celebrate sustainable software sharing wherever we see it.

The hard line of information enclosure in software is closed source, which today accounts for nearly all of the consumer-grade software that defines our digital lives. By staking out an all-or-nothing position, Open Source has lost the possibility of encouraging companies to share more of their code than they do today. There’s a wide range of sharing models available, we should explore them all. We should celebrate whenever companies share their code, rather than scolding them for not doing it right.

Enclosure of Attention

While software itself is a non-rivalrous information good, maintenance attention to society’s publicly shared software is a common-pool resource. What constitutes enclosure of this resource? It would have to be the hiring of maintainers by organizations that then influence, whether subtly or overtly, the maintainer’s priorities for the project.

This is delicate, because surely companies paying staff to produce Open Source is a primary way that maintainers are paid today. In general it’s a wonderful arrangement to be celebrated, and it would be inappropriate to single out any individual case for scrutiny. On a macro view, I think we can say that software as a commons is stronger if the balance of incentives includes a meaningful contingent of independent developers.

Tragedy of the Software Commons

Because software as an information good is non-rivalrous, it is by definition not susceptible to overuse. However, because it is rivalrous, maintainer attention is prone to the tragedy of the commons. In fact, we’re living through an Open Source sustainability crisis right now.

What does the tragedy of the commons look like in software? Maintainer burnout. The time and attention of maintainers is the rivalrous resource in software, and overworked people burn out. Time is money, so the way to address the tragedy of the commons in software is to pay maintainers. Software Commons celebrates all software sharing, including Open Source. Preserve the Open Source Definition if we must, but let’s please also figure out how to pay maintainers fairly without making them jump through hoops. Let’s stop burning people out.

Software Commons: An Institution

Whereas the Free and Open Source Software (FOSS) movement only upholds user freedom, we value user freedom and maintainer sustainability. We want to balance the rights of users with the needs of maintainers. Software Commons is a great name for us, because it so precisely points to the somewhat complex reality of our situation and the problems we need to solve. But what are we going to do with this name?

There’s a “thin” version in which we produce an educational website that discusses software sharing in term of different business models, distribution models, and contribution models, with a decision tree to guide people to a good fit for their situation. This might be roughly parallel to GitHub’s choosealicense.com.

Then there’s a “thick” version in which what we are doing is founding (or joining with?) an institution. The reason we would do this is because it is the only way to solve the three big problems that our analysis of software as a commons has uncovered:

1. the closed-source information enclosure of the bulk of society’s software;
2. the enclosure of maintainer attention, eroding overall community independence; and
3. the tragedy of the commons, burning out maintainers.

If the only problem we are trying to solve is the first, then yes, we can put up an informational website that educates companies on options for sharing their source code in ways that fit their business and gives us something to link to next time we announce an FSL product, and be done with it.

However, I don’t think we can justify using the name Software Commons while ignoring the second and third problems. Maintainer burnout is a real problem that has been with us for too long. If we’re going to live up to the promise of the Software Commons name, then we need to directly tackle the task of funding maintainers, and to do that properly requires an institution.

A Commons Is an Institution

Why do we need an institution in order to walk back the tragedy of the Open Source commons? Because that is what we find in actual practice for common-pool resources (CPRs) that successfully protect against overuse. Here is Elinor Ostrom in her definitive work, Governing the Commons (pp. 88-89), emphasis mine:

Despite all of the differences among the CPR settings described in this chapter—and substantial differences exist—all share fundamental similarities. […] The most notable similarity of all, of course, is the sheer perseverance manifested in these resource systems and institutions.

Ostrom’s answer to how to govern the commons is a set of eight, “Design principles illustrated by long-enduring CPR institutions” (p. 90):

1. Clearly defined boundaries
   Individuals or households who have rights to withdraw resource units from the CPR must be clearly defined, as must the boundaries of the CPR itself.
2. Congruence between appropriation and provision rules and local conditions
   Appropriation rules restricting time, place, technology, and/or quantity of resource units are related to local conditions and to provision rules requiring labor, material, and/or money.
3. Collective-choice arrangements
   Most individuals affected by the operational rules can participate in modifying the operational rules.
4. Monitoring
   Monitors, who actively audit CPR conditions and appropriator behavior, are accountable to the appropriators or are the appropriators.
5. Graduated sanctions
   Appropriators who violate operational rules are likely to be assessed graduated sanctions (depending on the seriousness and context of the offense) by other appropriators, by officials accountable to these appropriators, or by both.
6. Conflict-resolution mechanisms
   Appropriators and their officials have rapid access to low-cost local arenas to resolve conflicts among appropriators or between appropriators and officials.
7. Minimal recognition of rights to organize
   The rights of appropriators to devise their own institutions are not challenged by external government authorities.
8. For CPRs that are parts of larger systems:
   Nested enterprises
   Appropriation, provision, monitoring, enforcement, conflict resolution, and governance activities are organized in mulitple latyers of nested enterprises.

Sketching an Institution

The sort of institution I have in mind for Software Commons, after Ostrom’s principles:

1. brings together producers and consumers of FOSS under one roof, alongside platform partners, to negotiate an enduring solution to the Open Source sustainability crisis (is it a multi-stakeholder platform cooperative?); and
2. fleshes out and educates the industry on software sharing practices between closed and Open Source. [Update: dropping this from scope.]

Perhaps there is an institution that exists today that could be made to fit this description. It’s worth talking about, but I’m skeptical.

• It’s not the Open Source Initiative, which can only promote user freedom, not maintainer sustainability.
• It’s not the Linux Foundation, because it’s a company-centric trade association.
• It’s not Post-Open; I talked with Bruce yesterday, and if I understand it right, it really only represents producers.
• An Ostrom-ian institution needs to provide accountability for money flow, but I’m not sure any of the existing platforms (GitHub Sponsors, Thanks.dev) on their own is the right solution.
• OS Collective probably comes closest; it’s worth a conversation. My hunch is FOSS consumer representation is too weak.

It may fall to us—if we want it—to found Software Commons as a new institution that fulfills Ostrom’s principles. If we don’t want it, that’s okay. We can still publish an educational website to encourage a range of sharing between closed and Open Source. But if we don’t also tackle the enclosure of maintainer attention and particularly the tragedy of the Open Source commons, it would be beneath us to use the Software Commons name.

Something to add? Discuss on GitHub.