/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
Personality and destiny [not-audio_url] [/not-audio_url]

Duration: 28:09
A summary of the "situationist" faction of personality psychology, which holds that behavior is strongly influenced by the situation. Knowing someone's personality type adds little value when predicting how they'll behav…
Legitimate peripheral participation: the book and the idea [not-audio_url] [/not-audio_url]

Duration: 22:58
"Legitimate peripheral participation" is based on observations about how novices learn in the presence of experts. The novel bits are that novices learn better from fellow novices than from experts, that we need to pay a…
/Seeing Like a State/, part 3: the users, the clients [not-audio_url] [/not-audio_url]

Duration: 33:03
In this episode, I hope to give you some helpful hints about *actually* improving the lives of the users of the software you create. Or, if you’re the kind of “change agent” or “coach” I used to be, the lives of the, uh,…
Interview: Glenn Vanderburg on engineering [not-audio_url] [/not-audio_url]

Duration: 29:36
In episode 12, I used the chapter in /Image and Logic/ about Monte Carlo methods to argue that analogies of software development to engineering are not helpful. Glenn Vanderburg pushed back: it's not *engineering* that's…
BONUS: Lord, preserve us from totalizing systems [not-audio_url] [/not-audio_url]

Duration: 26:22
Why *are* teams stuck in hierarchical and commercial exchange economies, when they'd be happier and just as productive if the example of the previous episode were the default? A discussion of totalizing systems and "syst…