Oddly Influenced

Welcome to oddly influenced, a podcast about how people have applied ideas from *outside* software *to* software. Episode 25: /Governing the Commons/, part 1: setting the scene.

These episodes 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.

≤ music ≥

In 1968, Garrett Hardin published a paper that hypothesized a village whose inhabitants graze cattle on a pasture held in common. Each person decides how many cattle to graze, and no one in the village is subject to any outside force or regulation. Hardin concluded such a situation would inevitably lead to overgrazing and the collapse of the pasture because every person would keep adding more of his own animals to the common resource.

That is, the common pasture is a situation where my playing nice gives you the opportunity to win big by taking advantage of me. So the rational thing for me to do is try to take advantage of you. Maybe *you’ll* be a sucker who plays nice and *I’ll* win big. But if both of us cheat, at least I’ll lose less than if I play nice and you cheat.

So we become trapped in a system that will lead to ecological collapse. Q.E.D.

I wish *I* had that kind of chutzpah, the self-confidence to publish such a theory despite examples of that exact grazing situation working fine for sometimes hundreds of years. Literally: the Swiss village of Törbel was grazing cattle on a commons in the Alps since at least 1483 – without destroying it. And it’s not just one unusual village within Switzerland. There are others there. And Switzerland isn’t some special culture; Japanese villagers managed grazing land in a very similar way. As of 1982, Margaret McKean wrote about Japanese villages that she had quote “not yet turned up an example of a commons that suffered ecological destruction while it was still a commons”.

Hardin was enormously influential among people who prefer ironclad, abstract theory to messy actual practice. Which turns out to be an enormous number of textbook writers, pundits, and policymakers. It has led to a lot of human misery, particularly in the developing world, as various reformers ruined successful commons in the name of progress.

There are two main ways in which reformers have inflicted help.

The most popular one these days is privatization. The State swoops in and divides the existing commons among its users. If you overgraze the plot you get, you’ll ruin it. Because you know that, you won’t overgraze it. Even if you do, it’s no skin off my nose. It’s your problem, not mine.

In practice, there are problems with privatization. Often, the more politically adept people mysteriously get more of the land. And even if the State attempts to be fair, there’s still the /Seeing Like a State/ problem from episodes 17 through 19: can a distant State really know how best to divide up the commons?

Moreover, suppose *your* plot is right by a river, whereas mine is away from it. Your plot is, on average, better than mine, so the fair State gave you less land. Unfortunately, once in a while, the river floods at exactly the wrong time, so you’ll be hurting that year. Other years, my plot experiences drought and *I’m* hurting. If we were grazing on a commons, either case would be less of a disaster because we could move our cattle to undamaged land. Dividing into smaller plots increases the risk of each plot. All of the owners have to pay the cost of their increased risk. If they buy some form of insurance, the sum of their costs will exceed what it would have cost to insure the commons as a unit.

I should note that villages like Törbel have both commons and private property. The meadows the cows feed from in the summer are held in common, but the farms that grow the hay the cows eat in the winter are privately owned. The issue isn’t which of private property or commons is better in some abstract way, but which works better to solve a particular problem.

But let’s look at the other solution: regulation.

Before, say, the 1980s, regulation was much more popular than it is today. The State would tell farmers how many cattle each could graze on the commons, and punish them if they exceeded the limit. But it’s /Seeing Like a State/ all over again: the State has to know the carrying capacity of the land, which it is poorly equipped to do.

Moreover, the State has to be able to detect cheating reliably. If it misses some cheating, herders might still find it individually rational to cheat often enough that the commons collapses. Especially because it’s way more satisfying when the target of your cheating is some government bureaucrat than if it’s Jürgen, whom you see every Saturday evening at the tavern and every Sunday morning at church.

A better solution – if it can be made to work – is for the people with the most knowledge – the herders themselves – to make the regulations and do the enforcement. Our two books contain examples of that working – and examples of it not working. Ostrom’s life work was to derive design principles for successful commons.

She was more polite than I am, but I take her underlying theme to be this: Hardin’s core error was that he assumed the village herders were too dumb to recognize and avoid his tragedy of the commons. He treated them as automata that had to blindly follow the logic of games like the Prisoner’s Dilemma. It turns out he was wrong. People can be more than rational utility maximizers reacting to a fixed set of rules. They can be *smart* and change the rules.

≤ music ≥

This episode will be more analytical than I like, so let me start with two short examples of commons in action.

The first example is a system developed in the 1970s to manage a near-shore fishery in Turkey. It works like this:

* Each September, the cooperative of fishers draws up a list of everyone who’s allowed to use the fishery. As is typical of a commons, the list doesn’t change very rapidly from year to year, but people do die and so on.

* The fishing ground is divided into a number of fishing sites equalling the number of fishers. The sites are spaced far enough apart that one person’s nets won’t poach fish from another’s.

* The fishers draw lots to get a *starting* spot.

* The first day, each fisher fishes their starting spot. The next day, each one shifts east one spot. (I presume the one that started furthest east wraps around.)

* That goes on until February, when the fishers start shifting west each day. That further equalizes opportunity because the fish switch their migration direction around that time. That regime continues until May. I don’t know what the fishers do over the summer.

Peeking ahead, notice how easy it is to spot cheaters. If I sail my boat to today’s spot and someone else is there, that person’s a cheater. Spotting cheaters cheaply turns out to be really important.

≤ short music ≥

The second example is the distribution of timber in Törbel, that Swiss alpine village. As is frequently the case, there’s a person deputized by the village to make an overall decision about how much will be extracted from the common forest this year. This village forester marks all the trees that will be harvested. Then all the families eligible to receive lumber form work teams and there’s a communal harvest. They make piles of harvested logs, all roughly the same size, and then have a lottery to see which families get which piles.

Notice that in both these examples, the rules produce the kind of situation humans think of as fair. Every fisher gets roughly equal access to the best fishing spots. In the case of lumber harvesting, your family has no incentive to put all the best logs in one pile because that pile will almost certainly go to some other family.

≤ music ≥

It’s definition time! Oh boy!

Let me start by being a bit more precise about the word “commons”. A commons is, first, a renewable resource. The resource is also what’s called, in the jargon, “rival”. A rival resource is one where, if *I* consume a unit, *you* can’t. If I catch a fish, you can’t catch it. If I spray a gallon of water on my field, you can’t spray it on yours. In contrast, a “non-rival” resource is something like a weather forecast. My knowing that it will rain tomorrow doesn’t prevent you from knowing the same thing.

It’s possible to extract units of the resource faster than it’s renewed. In addition to the “oops, it’s all used up, guess there’s no more water until the rainy season” problem, over-extraction can permanently reduce the resource’s productivity. For example, people in southern California get some of their water from thick and wide underground bands of sand and gravel, called “basins”. Withdrawing water faster than the “safe yield” allows the sand and gravel to compact, with the result that they forevermore can hold less water. Moreover, if the basin is close to the ocean and its level drops below sea level, it can become contaminated by salt water.

Resource destruction is not necessarily gradual. A resource can act like a dry stick that’s gradually bent to the point it suddenly snaps.

The first problem of the commons is how to keep a set of individuals from exceeding the safe yield.

The second problem of the commons is maintenance. Canals occasionally have to be cleared. Dams sometimes have to be repaired or replaced. Maintenance benefits everyone, but each person is tempted to be a “free rider”: getting the benefit without helping to pay the cost; that is, without helping with the work.

That’s a problem because people *hate* being a sucker. If they observe free riders getting away with it, they’ll become increasingly likely to become a free rider themselves. My impression is that the shift from free riders not being a problem to everyone defecting is like the Hemingway quote from /The Sun Also Rises/:

“How did you go bankrupt?”
“Two ways. Gradually, then suddenly.”

The free rider problem is solved if everyone in the community is in “quasi-voluntary compliance”. That’s a state in which all the people extracting units of the resource – who Ostrom calls “appropriators” – collaborate on some goal *because they believe everyone else is collaborating too*. This requires trustworthy monitoring so everyone has a good idea of the level of compliance.

Detecting cheaters is pointless unless there’s some punishment. But punishment has to be well-tailored so that it doesn’t violate the community’s sense of fairness. Otherwise, people will get mad and stop complying with the whole system. As an illustration, consider what’s called the Ultimatum game. It works like this. You’re given a sum of money. Ten dollars, say. You can split the money any way you want and give a portion to me. I can accept it, in which case we both go away with money. If I reject it, neither of us gets any money.

Unless you offer me *nothing*, it’s always rational for me to accept. Maybe I only get one dollar and you get nine, but I’m still one dollar better off. But (with a qualification I’ll mention in a second) people generally will reject splits that are too far from fifty-fifty. We’d rather spitefully tear the whole thing down than be taken advantage of.

Note that “being taken advantage of” is culturally-specific. In some cultures, an unfavorable split is more acceptable than it is in, say, the mainstream American culture I grew up in. And if I’d grown up in a gifting culture where accepting gifts imposes an obligation to return a comparable favor, I might refuse a split that was too generous to me. Maybe I don’t want to feel in your debt.

Mechanisms of monitoring and enforcement are really the heart of designing a successful commons. I’ll discuss them next episode, but let’s get some lesser points out of the way.

Successful commons have boundaries for both the appropriators and the resource. *Here* is where we harvest wood; *there* is outside the bounds. Households from *this* village may join the harvest; *that* village may not. Boundaries are true even of water. For example, Nordman’s book describes the “gangs” of Maine lobster harvesters.

“Lobsters, like [Los Angelos’s] groundwater, can be depleted if harvested too intensively. And like LA’s groundwater managers, lobster harvesters organized themselves to protect their resource. The ‘lobster gangs’ or ‘harbor gangs’ developed informal, unwritten rules about who can set lobster traps and where they can set them. And the lobster gangs enforce these rules when they are broken [by cutting loose the buoys that mark traps’ locations].”

The safe yield of a commons is more-or-less fixed, but humans have the capacity to breed quite a lot. How does population growth not overwhelm the resource? In Switzerland, Ostrom writes, “the level of resource use was held in check by various population-control measures such as late marriages, high rates of celibacy, long birth spacing, and considerable emigration.” Similarly, in Japan, rights to appropriate were associated with households, which could only subdivide with permission of the village.“Consequently, households with many members had no advantage, and considerable disadvantages, in their access to the commons. Population growth was extremely low (0.025% for the period 1721 to 1846).”

That was surprising to me. My dad (born in 1920) grew up in a peasant farming village in what was then German East Prussia, now Poland. He was one of nine children. My impression was such large families were the norm in peasant societies. Sure doesn’t seem my grandparents did the “high rates of celibacy and long birth spacing” thing. They did do the emigration thing, but only because the women fled the Russians toward the end of WWII. (All the men had been previously drafted and were having their own problems.) I’m 100% sure my father would have returned home after he was released from the French prisoner of war camp, except there was no longer a home to return to.

Whenever I’m feeling sorry for myself, I remember that my grandmother and aunts were refugees who fled more than a thousand kilometers to safety, mostly on foot.

Anyway.

Another characteristic of successful commons is that the appropriators have a “low future discount rate”. What does that mean?

Generally you’d prefer getting one hundred euros now to getting it in a year. That implies there’s some number, let’s say 98 euros, where you’d be indifferent between getting 98 euros today or 100 euros next year. You might die before next year, or you might really need the money to pay this month’s rent, or you might be able to buy a one-year bond that will pay back 101 euros next year.

Different people will have different discount rates. An impatient person – someone with a high discount rate – might accept 70 euros now rather than wait for next year.

Appropriators in commons frequently assume they’ll be fishing or farming or whatever the rest of their lives, and that their descendants will too. That inclines them toward being focused on long-term stability, less likely to help ruin the commons for short-term gain.

A final characteristic of a successful commons is that the State has to leave people alone to make their own decisions and rules. It may provide support (like the funding to build a dam), but otherwise it should butt out. In the case of southern California groundwater basins, the State provided motivation: if the people who were already over-extracting water didn’t solve the problem themselves, a judge would do it for them. But once the people in the business of pumping water negotiated rules to prevent overuse, the State left them to it.

≤ music ≥

Is there a way a software codebase can be viewed as a commons?

The first question is “what’s the resource unit?” I don’t think that programmers who implement features or write code to produce new business value are really *extracting* features or value from the codebase, not the way fish are extracted from the water or water is extracted from a underground basin.

So that looks bad for the cause. But let’s try this. Consider the codebase as providing the *potential* to create new features. (I’m going to stop saying “features or business value” now, because it’s awkward. If you prefer, feel free to substitute the idea of business value for the idea of a feature. I don’t think it will make a difference.) Each act of creating a feature may reduce the codebase’s potential. That is, it’s possible to write a feature in such a way that some later feature will become *harder* to write. I think we’ve all seen this, and we’ve all heard of codebases that have effectively collapsed: become so hard to add to that it’s hardly worth bothering. Their metaphorical sand and gravel is compacted, and they’re metaphorically filled with seawater.

Moreover, it’s *faster* to write a feature badly than in a way that preserves potential. Programmers and programming teams are paid and judged by people who can’t directly see the potential (or “internal quality”) of the codebase. Those people primarily see speed of delivery and, secondarily, bugginess. Therefore, programmers have an incentive to satisfy the outsiders by cheating and delivering faster than is sustainable. I think that’s analogous enough to overfishing or overgrazing.

Another way of looking at it is that every feature-producing task has two parts: the part that’s necessary to create the feature and the part that’s necessary to restore or maintain potential. The two parts may happen at the same time, or alternate so frequently that it wouldn’t make sense to measure them and so be able to say, “I spent 70% of my time on creation and 30% on maintenance”, but it’s still conceptually true that there are incentives to cheat on the maintenance part.

Maybe that’s a strained analogy, but it might be good enough that we can adapt commons-style rules, monitoring, and enforcement to the codebase problem.

Let’s look at the other properties of successful commons in relation to codebases.

First, boundaries. Teams are typically fairly constant in size, and it seems to me that codebases are usually fairly well-defined. Having people from one team poking into another team’s codebase would generally be bad, because they’re able to impose costs while being less susceptible to the enforcement of rules. The same would go for codebases that “no one” owns, like, say, various administrative or deployment scripts. A commons with no common governance is going to have problems.

Multiple teams raises the topic of nested commons, which happen frequently. Consider, for example, an irrigation system with a main canal that has secondary canals. The set of farms on a particular secondary canal would be governed as a single commons, one dedicated to fair and sustainable use of the water in that canal. However, the water from the main canal has to itself be fairly and sustainably distributed amongst the secondary canals. Things will go badly if the most downstream secondary canal often doesn’t get water because upstream canals take it all. A typical governance structure would have representatives from each canal work out the rules governing the whole canal system, including high-level monitoring, enforcement, and dispute resolution.

A similar governance structure, it seems to me, may be required when there are multiple teams that have to collaborate to deliver value. For example, suppose a new system-level feature requires team A to provide an API that team B will consume. If team A controls the design of the API, it can push cost off onto team B by producing an API that’s easy to implement but hard to use. If team B controls the design, it can do the reverse: easy to use, but hard to implement. Once again local benefit *now* will degrade future benefit for everyone.

So I’ll include talk about nested commons in the next episode.

Discount rates are a problem for us. Not many programmers expect their descendants to work on the same code base. And perversely, in our industry, the best way to get a decent raise is often to go work for a different company. A company that doesn’t value retention is probably not a good candidate for commons governance. The same is true if most team members are jumping jobs every few years.

I feel like I’ve just become irrelevant to most of my listeners, but I’ll persevere.

You may have noticed, when I talked about maintenance earlier, I characterized it as something that happens seamlessly during the production of a feature. I implicitly discounted large, focused maintenance projects like replacing part of the code base or a “cleanup sprint”. The reason for that is it violates noninterference by outside rulers. Generally such projects have to be approved, and outsiders will almost inevitably underinvest. /Seeing Like a State/ again.

That’s a reason why, back in my consulting days, I always harped on the need to do maintenance and improvement as an invisible part of tasks that provide externally-visible value. Work outsiders can’t see is work they can’t tell you to skimp on. At least not explicitly: 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. I’ll just note that it’s likely to require some backbone – some mental toughness – and team solidarity.

≤ short music ≥

Next episode will be about Ostrom’s guidelines for monitoring compliance with rules, discouraging non-compliance, and resolving disputes. I might also discuss creating and changing rules – that is, how governance structures are created in the first place and how they’re maintained – but I suspect that will need its own episode.

Thank you for listening.