/Governing the Commons/, part 1: setting the scene

/Governing the Commons/, part 1: setting the scene

Author: Brian Marick February 20, 2023 Duration: 26:00

This is the first of two or three episodes that draw on Elinor Ostrom’s 1990 book, Governing the Commons: The Evolution of Institutions for Collective Action, and Erik Nordman’s 2021 book, The Uncommon Knowledge of Elinor Ostrom: Essential Lessons for Collective Action.

What I hope is that those lessons apply to the problem of keeping codebases from devolving into unworkable piles of crap.

Ostrom has nine design principles for designing successful commons governance. I mention them all in this episode, and provide Ostrom's summary below. In the descriptions, "CPR" stands for "Common Pool Resource" (that is, a commons). "Appropriation rules" govern extracting "resource units" from the commons. "Provision rules" govern improvement and maintenance of the commons.

I've replaced some of the bolded summaries with my own when Ostrom's had too much jargon.

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.

The rules governing a CPR are strongly influenced by local context: 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 money.

Those affected by rules make them: Most individuals affected by the operational rules can participate in modifying the operational rules. 

Monitoring: Monitors, who actively audit CPR conditions and appropriator behavior, are accountable to the appropriators or are the appropriators.

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.

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.

Minimal recognition of the right to organize: The rights of appropriators to devise their own institutions are not challenged by external governmental authorities.

For CPRs that are parts of larger systems:

Nested enterprises: Appropriation, provision, monitoring, enforcement, conflict resolution, and governance activities are organized in multiple layers of nested enterprises.

--------

In the podcast, I said "There will always be pressure to deliver faster. There’s been a lot written on reducing that pressure, or resisting it. That’s off topic for these episodes, so I’ll put links in the show notes." Well, I thought there were, but I don't have anything to offer you yet.

Here's a comment from Sasha Cuerda

"a tactic I have used in the past is ADRs. Basically keep receipts documenting the trade off being made. When my team had a track record of correctly and proactively assessing and documenting risk and those documents kept surfacing in retros tied to those risks materializing, we gained credibility with the non-manager stakeholders impacted by incidents and were able to push back. But def a long game.

"it helped that we had an already established and blessed practice of using ADRs in other contexts. They weren’t initially seen as “resistance” but as part of established good practice."


I did remember a blog post I wrote long ago, warning new agile teams not to deliver too much value too soon before they know how to do it sustainably. 

"I find myself advising new Agile teams to go slower than they could. Here’s the thing: at the beginning, they’re probably working on a bad code base, and they have yet to learn important rules and habits. They will find it easy to go faster than is compatible with making the code more malleable. [...]"


But that's not really the same problem. 

--------
Image of grazing cattle due to Emilian Robert Vicol is licensed under CC BY 2.0 and was obtained from OpenUniverse.org.


Brian Marick hosts Oddly Influenced, a podcast that digs into the unusual and often overlooked connections between software development and the wider world. Each episode starts with a concept, theory, or practice that originated far from the realm of code-perhaps in sociology, theater, history, or urban planning-and traces its journey into the hands of software practitioners. The focus is on the concrete application: how these borrowed ideas were adapted, what problems they aimed to solve, and what actually happened when people tried them. You’ll hear about the successes, the surprising failures, and the messy, fascinating reality of translating an abstract principle into working practice. This isn’t about generic inspiration or vague parallels; it’s a detailed look at cross-disciplinary pollination, examining the mechanics of how influence actually works. The conversations are grounded and specific, avoiding hype to explore what we can genuinely learn from fields that don’t think in loops and logic. For anyone in technology or education curious about how innovation often comes from the edges, this podcast provides a unique and thoughtful perspective. It’s for listeners who enjoy deep dives into the history and sociology of their craft, who appreciate hearing stories that aren’t the usual case studies, and who are open to having their own thinking oddly influenced by the end of an episode.
Author: Language: English Episodes: 55

Oddly Influenced
Podcast Episodes
E34: /Collaborative Circles/, part 1: a teaser [not-audio_url] [/not-audio_url]

Duration: 24:56
Michael P. Farrell's Collaborative Circles: Friendship Dynamics and Creative Work (2001) is about how groups of people ("circles") begin with discomfort about the status quo and, after collaboration and discussion, make…
E33: Interview: Jessica Kerr on /Games: Agency as Art/ [not-audio_url] [/not-audio_url]

Duration: 41:16
Jessica Kerr (known to computers everywhere as @jessitron) is a software developer, speaker, and symmathecist. (A symmathesy is a learning system composed of learning parts. To her, each software team is a symmathesy com…
E31: Foucault, /Discipline and Punish/, part 2: the factory [not-audio_url] [/not-audio_url]

Duration: 19:33
An intermediate episode. It seems wrong to talk about Foucault without mentioning his theory of power and societal change. But I don't think there's a lot you can *do* with that theory in the sense of "applying it to sof…
E28: /Governing the Commons/, part 4: creating a successful commons [not-audio_url] [/not-audio_url]

Duration: 19:55
I describe how the Gal Oya irrigation system got better. It's an example that might inspire hope. I also imagine how a software codebase and its team might have a similar improvement.As with earlier episodes, I'm leaning…
E26: /Governing the Commons/, part 2: the key mechanisms [not-audio_url] [/not-audio_url]

Duration: 29:19
Ostrom's core principles for the design of successful commons: how to monitor compliance with rules, how to punish non-compliance, how to resolve disputes, and how to participate in making rules. Elinor Ostrom, Governing…
BONUS: Seeing like a personality survey [not-audio_url] [/not-audio_url]

Duration: 13:12
My goal is to help you understand what it means when you see a headline like “Scientists find that people on the political right are less open to experience than people on the left.”TL;DR: For practical purposes, it does…