Oddly Influenced

Welcome to oddly influenced, a podcast about how people have applied ideas from *outside* software *to* software. Episode 27: /Governing the Commons/, part 3: Man, 63, seeks software teams, any age. Object: matchmaking.

In the previous two episodes, I’ve encouraged you to think of a software codebase as enough like a commons that Ostrom’s writings about successful commons can apply. There’s been a fair amount of skepticism on Mastodon about that, of two sorts.

The first is a reaction to Ostrom’s eighth design principle which, in Nordman’s formulation, is: “[Outside] authorities recognize a right to self-organize”. People commented that software teams have bosses, and despite all of this century’s talk about “self-organizing teams”, the brute reality is that bosses tend to allow self-organizing teams right up until they self-organize in the wrong way or to the wrong conclusion. In practice, teams often would require uncommon determination and solidarity to face up to the pressure to cut corners in exchange for faster delivery. We see that from how few do.

Now, Ostrom wasn’t willing to say her design principles are *prerequisites*; that is, necessary conditions, but she does have a table of 14 case studies on page 180. Six of those commons are marked “robust”, three are marked “fragile”, and five are marked “failure”. Of the eight marked “fragile” or “failure”, six have a “weak” or “no” annotation when it comes to self-organization. All the robust commons have a “yes”.

Other aspects of Ostrom’s work are troubling for us. She emphasizes long-term time horizons: not exactly something characteristic of software product development, where moving from product to product, or company to company, is extremely common. Why resist pressure to rush feature development when you’ll be gone before you’d have to really deal with the consequences of your choices? Why allow the team you manage to do painstaking, disciplined work when you intend get promoted before the chewing gum and twine you “encourage” programmers to use starts breaking?

All in all, it seems trying to adopt a commons approach would have a low return on investment. It’s true that commons adoption is gradual, incremental, and low cost (at least at first), but why not try something else with a higher chance of success?

At least something that other software teams have done before? As it stands – as far as I know – you’d be pioneers in adapting Ostrom to commercial software development, with all of its peculiarities. Extrapolating without expertise, from case studies like lobster harvesting and irrigation, seems… not great.

Which gave me an idea.

Indiana University contains a building called the “Ostrom Workshop”. “Workshop” here doesn’t mean something like a half-day workshop at a conference. It’s intended to evoke “a room, area, or small establishment where manual or light industrial work is done.” That is, a place that facilitates the study – and the putting into practice – of commons-like ideas.

The week after next, I’ll be talking to people from there, thanks to Erik Nordman’s facilitation. My hope is to fund some sort of collaboration between software teams and commons experts. Here’s a slightly modified version of an idea I floated to them:

quote

My dream contribution would be this:

1. One or more software teams want to apply Ostrom’s principles to codebases. (There’s also a nested commons angle, which I’ll omit here.)
2. They get to talk to your people. A team will have many questions about specifics that you may well have answers for.
3. By keeping in touch with what’s happening in the team(s), you get ethnographic-ish, publishable data in a new domain that’s of considerable economic importance.
4. My people get popularizations of what worked and what didn’t. The goal is to make it easier for teams to get started.

I’m able to spend some of our family money to make it happen. Probably more grant money than my wife got for a lot of her work.

end quote

My conference call would probably be better if I can say I’ve heard from teams who might participate. Being able to talk about a team of type X would help ground the discussion. If you’re interested in *your* team being one of those, send me a note via email or Mastodon. You can find my addresses on any page at podcast.oddly-influenced.dev or you can remember what I’m about to say. Email is marick@exampler.com (that’s the word “example” with an ‘r’ on the end) and Mastodon is @marick@podcast.oddly-influenced.dev.

≤ music ≥

The other main objection people make goes like this: sure, I could see commons governance as useful *before* a codebase has devolved as far as ours has. But it’s too late for us.

Let me offer hope. Your codebase and your team’s situation is not as bad as that of the Gal Oya canal system in Sri Lanka. Gal Oya was completed in 1950 and had spent about 30 years falling into what was described as a “hydrological nightmare”. But Ostrom has a case study of the rescue of one of three regions within the system. That region had been designed to irrigate 65,000 acres (26,000 hectares) of farmland with about 780 miles (1250 kilometers) of canals and field channels. But by the late ’70s, it was actually serving many fewer acres because of silted up canals, broken hardware, and a general lack of maintenance.

The farmland had been settled by people from all over the country, so there was no tradition of cooperation. That’s especially true since the farmers came from different ethnic and language groups. You may have heard of conflict between the Sinhalese and Tamil groups. That conflict was imported to Gal Oya, especially since Tamil speakers got the worst land (furthest from the water source), whereas the Sinhalese speakers generally got the best.

Most farmers had no participation in governance. The canals were managed by officials from the Irrigation Department, who by and large despised the farmers. The farmers despised them right back, considering them incompetent. Moreover, the Department’s bureaucrats were, at best, not paid for performance. At worst, they were out-and-out corrupt. Because of corruption, the wealthier farmers got water more reliably, creating another source of division among the farmers.

Cheating by farmers was rampant. And if cheating were to be punished, it would be by farmer-on-farmer violence. Murder over water was not unknown.

So: both the resource and the community were in worse shape than yours. (If not, you have my sincere sympathy. Get out as quickly as you can.)

Around 1980, someone – maybe international aid organizations – funded a four-year project to fix things for the 19,000 farmers. Things did indeed get better. Here’s a snapshot from Jayantha Perera:

quote

“During my visit in January 1983,I observed fifteen Tamil and twelve Sinhalese farmers finishing the cleaning of [the channel]. The thickness of the tree root that had grown through the channel and which the farmers were chopping out by hand was mute evidence that water had not reached the tail in some twenty years. The farmers worked together for three days to get the channel cleaned, just in time for the arrival of the season’s first water delivery.”

end quote

Things are not perfect in Gal Oya. Ostrom described its commons as “fragile” in 1990. Still, it improved despite having weak institutions for conflict management and a shaky right to self organization.

You probably have more potential than anyone saw in Gal Oya, so experimenting – incrementally, cheaply – with commons governance might well work for you.

I’ll describe the history of Gal Oya in the next episode. But for now, I’ll stop here, in the interest of getting this episode published sooner.

Thank you for listening, and thank you for considering using your team to help me spend some of my children’s inheritance.