Oddly Influenced

Welcome to oddly influenced, a podcast about how people have applied ideas from *outside* software *to* software. Episode 26: /Governing the Commons/, part 2: the key mechanisms.

In this episode, I’ll continue my work 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/.

Ostrom has eight design principles for a successful commons. I covered the ones I judged less important or interesting to us in the last episode (although I only characterized them as design principles in the show notes). This episode is about what I consider the core principles, those that have to do with monitoring compliance with rules, punishing non-compliance, resolving disputes, and participating in making rules.

But the underlying idea here, perhaps, is how do we get programmers to behave as well as Maine lobster harvesters? Quoting one of them:

“You lose that reputation amongst your peers and it’s very, very difficult to get it back. Everybody works their entire career as a harvester to build up that reputation. […] It would be my worst nightmare if I was caught with 15 or 20 undersized lobsters and all those individuals that I looked up to as kids, I knew they would be reading that in the local publication and seeing my name right next to that violation. That alone is enough to keep me from doing it.”

Such internalized norms are perhaps *the* key to avoiding Hardin’s “tragedy of the commons”, but I suspect – or hope – Ostrom’s core principles help to drive the internalization of such norms.

≤ music ≥

I’m going to start with monitoring. Last time, I used the example of near-shore fishing where there are the same number of fishing spots as people fishing, and the people rotate to a new spot every day. In this case, monitoring is cheap because (1) it’s obvious when someone is in your spot for today, and (2) the total area is small enough, and the number of fishers small enough, that an extra boat outside of the allowed spots is easily detected.

The same is true of Maine lobster harvesting. Each harvester uses a signature buoy to mark where a line of their traps rests on the bottom of the sea. One harvester might use buoys that are half blue and half orange, another might be solid orange with a red vertical stripe, and so on. If you go out every day to haul up traps, you’re going to notice if, allofasudden, there are a bunch of new buoy colors in your harbor – even if you didn’t happen to see the boat that laid the traps.

It’s common for those Ostrom calls “the appropriators” to do the monitoring as a natural side-effect of doing the appropriating. Here’s another example: you’re a farmer who takes water from an irrigation canal. You get to divert the water onto your field starting at 8 o’clock, for one half hour. After that, you have to free up the water so that I, the next farmer downstream, can use it in my time slot. If you try to overshoot your time slot, I’m right there to notice.

Such appropriator monitoring has two purposes. First, it makes monitoring cheap. Cheap is important because monitoring doesn’t directly earn money. The second purpose is so the people most affected by cheating – the appropriators – can get a good personal estimate of how often cheating happens. Remember, our goal is “quasi-voluntary compliance”, where everyone mostly follows the rules only because they believe everyone else is mostly following the rules. And seeing – for yourself – is believing, as the saying goes. If it seems most cheating is caught, you yourself will rarely cheat.

The importance of low cost is all throughout Ostrom’s book. Often there are mechanisms to simply eliminate the need for monitoring. I mentioned an example last episode. In the village of Törbel, families gather to cut logs into piles. Then the piles are distributed by lottery. The need for monitoring the size and quality of the piles built by family A is eliminated because family A is unlikely to win the lottery and so get the benefit of making a better pile than everyone else.

It’s often not practical for all the monitoring to be done by the appropriators. In such cases, the appropriators hire someone to check the commons for cheaters. Such a job often went to young men, as a sign of merit: they’re worthy of this important responsibility.

But who will watch the watchers themselves? Who monitors the monitors that the appropriators hired? Why, the appropriators themselves. Some of that is direct: they check in on what their employees are doing. Some is indirect, because they never completely delegate monitoring the resource. If they catch cheaters but their employees don’t, there’s evidence the employees are slacking off, and they’ll get fired.

And monitors can have their financial incentives aligned with those of the owners. For example, in some Japanese villages, a monitor who catches you in a minor infraction could fine you cash or a bottle of saké, payable directly to the monitor.

Of course, as always happens, a solution to a problem causes another problem. What’s to prevent an alcoholic monitor from fining someone a bottle of saké every night? Well, he’d be fining one of the people who hired him, someone who – as an appropriator – has the right to appeal to the kind of conflict-management structure I’ll discuss later. Unless the complainant is unpopular, other appropriators will likely offer support: none of them want to be the next one falsely accused.

(I mention unpopularity, by the way, because there’s no way around a harsh fact: we’re talking typically-small groups of people who spend a lot of time with their noses in each other’s business. There are inevitably going to be feuds, cliques, unfair opinions, and pressure for conformity – a sort of social conservatism. Some people will struggle unduly with that and, like millions of small-town kids in every kind of culture, head off for the city. I don’t want to give the impression that a commons is some sort of universal, unproblematic solution.)

Another kind of, quite cheap, monitoring is self-monitoring. That’s what the lobster harvester in the introduction was talking about. And here’s a quote from one lawyer responding to another lawyer’s blog post. “You once noted a long time ago that the dirty secret of contract law is that most contracts are effectively unenforceable. The reason for this being that the costs of prosecuting and/or defending a breach of contract lawsuit almost always will exceed the value of the actual contract. I've done some prosecution and defense of breach of contract and it is true. What keeps contracts enforced is this hazy, almost mystical belief that people should adhere to contracts because it is honorable and enough people get slapped in breach that people tempted have a warning.

Whereas I more than halfway believe our intense desire not to be a sucker is hardwired into us, the desire not to be a cheater is cultural, encoded in norms like “don’t steal lumber from the commons”, “always pay your debts”, or the even stronger, because more primal, “be someone people can depend on”. Such norms – such ‘hazy, almost mystical beliefs’ – are important to the workings of successful commons. Better than an appropriator who resists temptation is the appropriator who isn’t tempted in the first place.

≤ short music ≥

Remember, my interest here is what Ostrom’s work says about keeping a code base from devolving into slime as programmers pursue their self-interest in getting done fast by pushing work into the future or onto someone else.

For reasons that I’ll get into later, I’m limited in what I can usefully say. Or, rather, I should say: usefully speculate. Because I lack any real experience to transmit.

But for now: monitoring!

We have lots of ways of monitoring. Pair programming, an artifact of the last century, is an excellent example of combining doing the work with monitoring each other. That’s especially true if you practice switching pairs frequently, as that comes closer to everyone watching everyone all the time. And mob or ensemble programming comes closer still.

Code ownership should be discouraged, as that lets one person (or a group) hide offenses for longer, and also to cheat by pushing work off to code outside the ownership boundary. But I’d also watch out for an informal sort of code ownership, where perhaps almost all the pairs that touch a particular chunk of code have Shannon as a member because Shannon knows that code best. How is Shannon, in this case, not the code’s owner? It might be interesting to steal a trick from fishing and timber harvesting and have pairs assigned to tasks by lottery. At least, most of the time.

Pull request reviews or old-fashioned code reviews also add visibility, though they make monitoring a separate task, thus increasing its cost. (Although, I can credit the counterargument that a pull request review is about other things, such as finding bugs or provoking team-wide impromptu discussions.)

Automation – like standardized code formatters or linters – reduces monitoring cost, though I personally think the kind of code rot they prevent is fairly unimportant.

In fact, my distaste for code formatters raises an objection to my whole idea. Surely the monitoring in all these fishing and timber examples is inherently simple. Those monitors are looking for people stealing wood in the middle of the night or sneaking another cow onto the commons. It’s surely much harder to determine if someone is degrading the internal quality of the code with poor design.

That might be true, though I wonder if I’m not doing that programmer thing of thinking everyone else’s job is straightforward. Consider even a simple rule like “each household must have someone spend a day a month cleaning the canal”. How old can that person be? How young? Is the community really getting someone who can do a full day’s work? And what exactly is “a day”? Six hours? Eight? Ten? Does eight hours working on a pleasant spring day count the same as eight hours at the height of sweaty summer? And there are *so* many ways to shirk a job – does what Oreb’s doing count as shirking? What happens if Matthew sprains his ankle halfway through the day and hobbles home? Does someone else have to make up the remaining time? When? Is it fair to count time spent improving specifically that part of the canal that waters your farm as maintenance for the benefit of the whole community? And so on.

My hunch is that our particular problems aren’t so obviously harder that applying commons-style ideas to them isn’t worth a try.

≤ music ≥

Monitoring leads to some form of punishment. Here’s a nice description from Ostrom about punishment:

“Let us also look at the situation through the eyes of someone who breaks the rules and is discovered by a local guard (who will eventually tell everyone) or another appropriator (who also is likely to tell everyone). Being apprehended by a local monitor after having succumbed to the temptation to break the rules will have three results: (1) It will stop the infraction from continuing and may return contraband harvest to others. (2) It will convey information to the offender that someone else in a similar situation is [also] likely to be caught, thus increasing confidence in the level of quasi-voluntary compliance. (3) A punishment in the form of a fine, plus loss of reputation for reliability, will be imposed.”

Notice how much of the punishment is social: *everybody knows* of the rule breaking. As social animals, people really don’t like having their status decreased, and it’s especially annoying to know that people will be gossiping about you behind your back. A reputation for reliability has value, and the rule breaker is going to have to work to earn it back.

Sometimes social punishment is enough, possibly when the individual offense isn’t that big. Nordman describes a grassy college quadrangle. “The students […] treasure this common space and defend its integrity. The quad is a perfectly green rectangle, unmarred by ‘desire lines’ worn across the turf by students who wish to cut across it. New students quickly learn not to cut across the quad. Those who violate this tradition will hear shouts from students firmly reminding them to stick to the path around the perimeter. Cutting across the quad is not formally forbidden by the college. The only penalty is a brief moment of social stigma. It’s a tradition […] that has been passed down through generations of students.”

In other cases, there’s some sort of physical compensation, like a bottle of saké. While punishment scales with the severity of the offense, first or infrequent offenses are typically lightly punished. With further offenses, the punishment escalates. Extreme and habitual offenders may be banished or put at risk of their life.

The guiding principle for determining the amount of punishment is the deterring of behavior rather than moralistic retribution or “making the punishment fit the crime”. So it’ll naturally tend toward erring on the easy side at first. That’s especially so because the infraction might have been an honest mistake or a product of desperation. Because the people imposing the punishment can imagine making a similar mistake or being similarly desperate, they’re inclined to practice the Golden Rule and treat the miscreant the way they’d want to be treated.

≤ short music ≥

It seems to me that most software teams do not have the ability to produce graduated sanctions. We can muster social disapproval. But after that, the only option is eviction. There’s little-to-nothing in between.

For whatever reason, tangible sanctions – like bottles of saké and cash – don’t seem to culturally fit most teams. As an example, there was once a scattered practice of having anyone late to a standup or other meeting put a dollar or euro into a jar. At the end of the month or quarter or just when the jar was full, the money would be sent to charity or spent on something to benefit the team.

Now, that seemed a fine idea for me, especially since I was raised by traditional German parents who gave me a horror of being late, so I sometimes would mention the idea on consulting trips when the team had a perennial problem with tardiness and social pressure wasn’t working. I was surprised by how strongly some people objected to it. And, in any case, the practice seems to have died out, at least among my followers on Mastodon.

So that’s a tool – graduated sanctions – that’s maybe missing from a lot of team toolboxes.

≤ music ≥

Another of Ostrom’s rules is about 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.”

Nordman describes Valencia, Spain’s, “water court”. “Each Thursday at noon, as they have for the last one thousand years, members of this unique court conduct a public hearing in which they resolve disputes over irrigation water.”

The way it works is this: there are multiple canals that draw from the Túria river. Each canal is its own district, but each district is nested within the larger “huerta”. Both levels of nesting – the individual canal and the whole canal system – are governed as a commons.

In any given canal district, landowners elect an executive committee from among their members. The committee makes water use rules, collects fees for maintenance projects, and so on. The committee is headed by a “syndic” (elected to that position by the landowners, not by the other committee members). He – so far, it’s always been a “he” – is responsible for assessing fines and resolving disputes.

If the syndic can’t resolve a dispute, a farmer can take it up to the next level: the water court. That’s composed of the syndics from the eight canals.

Here is how the water court resolves disputes, per Nordman:

“The Tribunal’s justice is swift. The complaints must be filed with the Tribunal relatively quickly – between three and ten days, depending on the canal district. Then at Thursday’s hearing, the syndics hear evidence and a defense. No lawyers are called upon in this popular court. The farmer’s own syndic does not participate to avoid a conflict of interest. The syndics review the evidence, hear testimony from witnesses, and confer with one another […] with the crowds watching. Within minutes, the Tribunal arrives at a judgment. The Tribunal’s decision is final. The guilty party has no opportunity to appeal.”

Interestingly, the Tribunal doesn’t assess a punishment. That’s done afterwards, by the guilty party’s syndic.

The Tribunal doesn’t have to handle a lot of cases, partly because it’s *embarrassing* to be found guilty while literally hundreds of people may be watching. Many disputes are settled just before the ceremonies start.

After the public court, the syndics retire for a private discussion, where they plan water usage for the next week or two and resolve any other cross-canal issues.

I’ll use that planning as an excuse to shoehorn in something I noticed throughout my reading: how often commons governance involves clever ways to work *with* human nature, rather than against it. This contrasts with what I’ve seen so often in tech: the assumption that if you tell someone the right thing to do, they’ll do the right thing. Knowledge and belief are taken to be incentive enough.

One example comes from the Philippines. It’s another canal story. In their system, land adjacent to the canal is divided into three or more zones, with the land furthest upstream in Zone 1, land further down the canal in Zone 2, and so on. Each farmer gets land in each zone. So if there’s only enough water for Zone One, no one is completely left out. Again, perceived fairness is important.

As with the Valencia system, there are people elected to determine when the canal will get water. If they allow upstream plots to waste water in a time of drought, the downstream plots will suffer. Everyone will suffer roughly equally, but still: everyone will suffer.

So here’s the trick. The elected people are compensated for their work by being given extra land – at the very end of the canal. If they allow waste anywhere upstream, they are the ones most likely to suffer.

This example also highlights something important enough that Ostrom makes it one of her design principles. The rules are always closely tailored to the specifics of a commons. The Spanish huerta (or canal system) I described earlier gives examples. Here’s Ostrom:

“Among the four Spanish huertas that are located in fairly close proximity to one another, the specific rules for the various huertas differ rather substantially. It is only in the one system (Alicante), where there has been substantial water storage available since the construction of the Tibi Dam in 1594, that a water auction is held. At the time of the Sunday morning auction, substantial information about the level of water in the dam is made available to the Alicante irrigators. Consequently, they can know about how much water they will receive if they purchase an hour of water. In the systems without storage, water is strictly tied to the land, and some form of rotation is used.” (Interjection: what Ostrom means here is that if water runs out just before it gets to your land, next time through, you’ll get to draw water first, then the farm downstream of you, and so on. Over time, fair access is achieved. That is, how much water you get depends only on how much land you have, not on your position along the canal.)

Returning to Ostrom:

“In Valencia, each farmer takes as much water as he can put to beneficial use in a defined order. Thus, each farmer has a high degree of certainty about the quantity of water to be received, and less certainty about the exact timing. In Murcia and Orihuel, where water is even more scarce, a tighter rotation system is used that rations the amount of time that irrigators can keep their gates open. […] No single set of rules defined for all irrigation systems in the region could deal with the particular problems in managing each of these broadly similar, but distinctly different, systems.”

≤ short music ≥

And that’s the reason why my suggestions in this episode have to be vague. It’s just the nature of the beast that – beyond general design principles – each governance structure is going to be specific to the team or company, plus be heavily influenced by chance and history.

Nevertheless, let me comment on one thing. When software teams have a hierarchy – a technical lead, say – that hierarchy is typically both *appointed* and *universal*.

By appointed, I mean that the team does not elect the team lead. Rather the lead is assigned to the team from the outside. As we’ve discussed, that’s at best unusual for a commons.

By “universal”, I mean that this single person is supposed to have the final say on *all* technical matters. Why? Skill at design, or intense knowledge of the codebase, doesn’t necessarily imply the best understanding of how to preserve the codebase’s potential. In fact, intense knowledge could be a negative. A lead may well be the person *most* able to understand and work with changes that degrade the code, to be *least* representative of the newbies who’ll have to work with it.

In my consulting days, I was not surprised to find relatively junior programmers that had a better feel for internal quality than the team lead, to be less likely to shrug off problematic code as being “well, that’s the way it’s always been” or “that’s the standard” – and to be most eager to push for improvements.

If you’re going to establish a commons-style governance structure, it might not be horrible to vote the wet-behind-the-ears kid into a position of authority for commons maintenance. Give it a try; votes can always be reversed.

Generally, commons governance is “polycentric”, where there are many centers of decision-making power, as opposed to a top-down flow from one authority. For example, Nordman says of southern California groundwater management: “By the early 1960s, a complex network of institutions managed the West Basin’s water resources. Some focused on delivering freshwater while others managed floods and water pollution. Whatever problem a resident faced and whatever the scale, there was some kind of association, board, or district that could handle it. And if there wasn’t, the public entrepreneurs would get together and create one if needed.”

≤ music ≥

Ostrom’s last principle is “Most individuals affected by the operational rules can participate in modifying the operational rules”.

Unfortunately, Ostrom doesn’t give examples of rule changes, so I can’t pass them along to you. About all she says is that the cost of changing the rules should be rather low. I’m thinking that doesn’t necessarily mean “quick decisions and short meetings”, as Ostrom thinks of talk as a positive good rather than a cost. Much is made of discussing things over coffee, rather informally, as a way of building trust and community. Nordman puts it like this:

“Game theorists dismissed most inconsequential conversations as ‘cheap talk’ that didn’t affect the game. However, Ostrom and her colleagues found that such cheap talk actually has a big influence. Simply talking – about the weather, about sports, whatever – can build trust among the players. Getting resource users to start talking and building that trust became a cornerstone of Ostrom’s ideas about common-pool resource management.”

As a person who doesn’t enjoy small talk *at all*, that doesn’t thrill me in the slightest. But, hey: if it were all fun, they wouldn’t call it “work”.

≤ short music ≥

I’ve covered, at least sketchily, each of Ostrom’s design principles. You can find them written down (for reference) in the show notes for *last* episode, episode 25. They’re kind of jargon-ey in Ostrom’s version, so I’ll give Nordman’s:

1. The physical and social boundaries are clearly defined.
2. Locally tailored rules define resource access and consumption.
3. Individuals who are most affected by the rules can participate in rule making.
4. Resource monitors are accountable to resource users.
5. Graduated penalties can be imposed on rule breakers.
6. Conflict management institutions are accessible.
7. [Outside] authorities recognize a right to self-organize.
8. Complex systems are organized into layers of nested governance.

The next episode will cover introducing commons governance where it didn’t exist. Think “iterative, incremental, and experimental”. Also, Nordman’s book turned me onto Aseem Prakash’s “club theory of voluntary programs”, an extension of Ostrom’s theory that might provide ideas for situations – like ours – where we’re generally missing the autonomy to put all of Ostrom’s design principles into practice. So I have more reading to do.

Thank you for listening.