/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
E42: The offloaded brain, part 2: applications [not-audio_url] [/not-audio_url]

Duration: 34:10
Suppose you believed that the ecological/embodied cognitive scientists of last episode had a better grasp on cognition than does our habitual position that the brain is a computer, passively perceiving the environment, t…
E41: The offloaded brain, part 1: behavior [not-audio_url] [/not-audio_url]

Duration: 31:52
Embodied or Ecological Cognition is an offshoot of cognitive science that rejects or minimizes one of its axioms: that the computer is a good analogy for the brain. That is, that the brain receives inputs from the senses…
EXCERPT: Concepts without categories [not-audio_url] [/not-audio_url]

Duration: 15:38
This excerpt from episode 40 contains material independent of that episode's topic (collaborative circles) that might be of interest to people who don't care about collaborative circles. It mostly discusses a claim, due…
EXCERPT: Christopher Alexander’s forces [not-audio_url] [/not-audio_url]

Duration: 14:29
Software design patterns were derived from the work of architect Christopher Alexander, specifically his book A Pattern Language: Towns, Buildings, Construction. This excerpt (from episode 39) addresses a problem: most s…
E40: Roles in collaborative circles, part 2: creative roles [not-audio_url] [/not-audio_url]

Duration: 45:14
The last in the series on collaborative circles. The creative roles in a collaborative circle, discussed with reference to both Christopher Alexander's forces and ideas from ecological and embodied cognition. Special emp…
E39: Roles in collaborative circles, part 1 [not-audio_url] [/not-audio_url]

Duration: 32:19
Farrell describes a number of distinct roles important to the development of a collaborative circle. This episode is devoted to the roles important in the early stages, when the circle is primarily about finding out what…
E38: The trajectory of a collaborative circle [not-audio_url] [/not-audio_url]

Duration: 27:52
Collaborative circles don't have a smooth trajectory toward creative breakthrough. I describe the more common trajectory. I also do a little speculation on how a circle's "shared vision" consists of goals, habits, and "a…
E37: Resilience engineering with Lorin Hochstein [not-audio_url] [/not-audio_url]

Duration: 44:36
An interview with Lorin Hochstein, resilience engineer and author. Our discussion was about how to handle a complex system that falls down hard and – especially – how to then prepare for the next incident. The discussion…
E36: BONUS: One circle-style history of Context-Driven Testing [not-audio_url] [/not-audio_url]

Duration: 47:52
I was a core member of what Farrell would call a collaborative circle: the four people who codified Context-Driven Testing. That makes me think I can supplement Farrell's account with what it feels like to be inside a ci…