Nadia Eghbal, in her major report on the state of our digital infrastructure, and Jonathan Lister, in his response describing our digital ecosystem, both point to a tragedy of the commons in open source software. While some projects are sustainable, many still struggle with “a free rider problem.” As Nadia puts it:

Resources are offered for free, and everybody (whether individual developer or large software company) uses them, so nobody is incentivized to contribute back, figuring that somebody else will step in.

Heartbleed revealed an extreme case of this phenomenon: a single developer, working for peanuts, bearing the weight of more than half the web.

For advice on addressing this problem, Jonathan suggests we look to ecosystem management, “an industry in itself, with its attendant experts, who write books and speak at conferences.” I recently read one of the seminal books in this area, Governing the Commons, by Nobel laureate Elinor Ostrom, and I’d like to offer some initial thoughts on how it might apply to open organizations and open source sustainability.

Ostrom on the commons

Ostrom observes that some groups clearly have overcome the tragedy of the commons, while others have not. Her first lesson for us is to focus on institutions as the deciding factor between success and failure. Through a careful review of case studies, she distills principles for designing institutions to manage what she calls “common-pool resources,” or CPRs:

The term “common-pool resource” refers to a natural or man-made [sic] resource system that is sufficiently large as to make it costly (but not impossible) to exclude potential beneficiaries from obtaining benefits from its use.

CPRs include things like fisheries, groundwater basins, and forests. “Appropriators” are those who take from a CPR, while “providers” and “producers” set up a CPR and keep it going.

Now, open source software is not technically a CPR, but rather a so-called “public good.” The two are similar: it is difficult (by design!) to prevent someone from appropriating open source software, just as it is difficult to prevent people from fishing in a certain area. Economists would call them both “non-excludable.” But while you and I can’t both catch the same fish (when you catch one, I can’t catch the same one), you and I can both use the same software (when you download and deploy it, I can do the same). In technical terms, then, economists consider CPRs “rivalrous,” whereas public goods like open source software are “non-rivalrous.”

This distinction means that ecosystem management such as Ostrom describes does not apply completely or neatly to open source software. However, CPRs and public goods do both suffer from free rider problems, and Ostrom herself says:

A study that focuses on how individuals avoid free-riding, achieve high levels of commitment, arrange for new institutions, and monitor conformity to a set of rules in CPR environments should contribute to an understanding of how individuals address these crucial problems in some other setting as well.

Free-riding in open source communities leads to overworked and underpaid individuals, and eventually to burnout. It’s bad for people, and it’s bad for projects. It’s a problem we need to address. Ostrom shows us how to tackle the problem with a methodical approach to institutional design and analysis. Open organizations that steward open source software projects have much to learn from her, while recognizing that we will need to adapt her recommendations to fit our situation.