Common-Pool PushoversElinor Ostrom without boundaries
This post is part of a series, Memeguments.
We all love metaphors for open source. Open source as ecosystem. Open source as science. Open source as infrastructure. And we love talking open in the high-flying abstractions of economics. When we’re feeling triumphant, as an exception to all the orthodox rules, as through Benkler’s “commons-based peer production”. When we feel stuck, to invoke economic solutions to our crises, as through Ostrom’s “common-pool resources”.
But a strange thing happens when open source dogooders talk about Ostrom. They blunt all her hard edges.
In particular, they take the first of her design principles, clear boundaries and memberships, and turn it inside out. Membership becomes about belonging, about welcoming, about togetherness, about community. Not about who can and cannot use what’s made and maintained. It’s a membership that only says “welcome”. It never says “no”. Which is exactly not Ostrom’s point.
Getting away from hand-wavy summaries and easy-to-glance tables into the text of Ostrom’s book, here is how she specified the first design principle for robust common-pool resources:
define a set of appropriators who are authorized to use a CPR
Of the studies Ostrom tabulated, five lacked clear boundaries and memberships. Four of those she classed as failures outright. The last she termed “fragile”, noting:
Although the rules in devised in Alanya provide an elegant way to solve an assignment problem, they do not address the problem of limiting access to the local fishery. At the current time, the number of fishers desiring to fish in Alanya does not threaten the viability of the fishery. But if more individuals were to want access to the fishery, the problem of rent dissipation that characterized Mawelle [which lacked clear boundaries and memberships, and failed] could well arise in Alanya.
Running with the metaphor, Alanya was like an open software project still flying under the radar. Its maintainers might be making good use of it and getting along. Nearly everyone using might be developing, too. But it hasn’t been choked out, because outsiders aren’t clamoring to exploit it yet.
If by “open source” you mean code that anyone can access and use—that anyone can appropriate—then open source projects fail Ostrom’s design criteria for robust common-pool resources by definition. They may have members and nonmembers, but the difference between the two isn’t the one that counts. It’s not a boundary of the type Ostrom taught us to look for, the kind she might’ve counseled us to build to sustain our work in a robust way.
Ostrom began her book with a warning against cooking up policies from metaphor. Her example was nationalizing forests in the Third World, a process of “creating open-access resources where limited-access common-pool resources had previously existed”. This, Ostrom notes, led to “disastrous effects”, for which she cites six sources about four different countries.
In Ostrom’s terms, an open-access resource is a Hobbesian state of nature where the rules about who can appropriate are no rules at all. The “membership” that can exploit is everyone. In our terms, an open-access resource is the kind of thing many take open source to be, or think that it ought to be, and think is good for them. It is a broad, permissive public license, full source code, responsive support, dutiful maintenance, and good documentation, all free for the taking. No share-alike rule. No credit requirements. No open core. No company project steward.
Nearly two hundred pages later, Ostrom ended her book with a warning against policy making by crisis, with notes on the root of its dysfunction:
The propensity of political leaders to discuss CPR problems in terms of “crises” is far more understandable once one takes into account that individuals weight perceived harms more heavily than perceived benefits of the same quantity.
In other words, political leaders respond to crises in common-pool resources, especially highly visible signs of degradation, because politicians and their constituencies exhibit loss aversion, a common human bias or fallacy. We overreact to harms and things taken away—rights taken out of a license, code held back from public release, features allocated to an “enterprise” version—while downplaying benefits and opportunities, like the prospect of better works, longer sustained, under balanced arrangements of contribution, maintenance, and reward. What’s more, we’re short-termist, bad at estimating probabilities, and conservatively hew to familiar rules over new ones, all of which Ostrom points out.
In the end, Ostrom’s common-pool resources are at best a metaphor for open source, not a study of it. Developers aren’t fish, forests, water, or game, but people just as capable of participating in governance as being governed upon. But open source can and should take lessons from Ostrom’s work. Not that we should do as we’ve been doing, without reflection, and trust that a Nobel winner solidly theorized the inevitability of our triumph over funding, motivation, and fairness crises. But rather that she theorized, and empirically validated, a pattern that predicts the problems projects now face, if not their solutions. Plus the biases, fallacies, and political traps that would blind us to the difference.
Your thoughts and feedback are always welcome by e-mail.