In 1968, Garrett Hardin argued that shared resources are doomed. Every individual takes a little more than their share, and the resource collapses. Rational actors, irrational outcome. He called it the tragedy of the commons.

In 2009, Elinor Ostrom won a Nobel Prize for proving him wrong.

She studied fisheries, forests, and irrigation systems where communities governed shared resources successfully for centuries. No privatisation, no central authority. Just clear rules, maintained collectively. The commons doesn't fail because people are selfish. It fails when governance breaks down.

Your codebase is a commons. And most teams have no governance at all.

The extraction loop

Every developer extracts from the codebase: reading, shipping features, depending on its stability. Every developer is supposed to contribute back: updating docs, cleaning up, sharing context. When more people extract than contribute, the commons degrades. The README describes last year's architecture. The test suite is 40% skipped. The runbook references a pipeline you replaced in January.

Nobody broke these things on purpose. They stopped being anyone's job.

What governance actually looks like

Ostrom identified design principles that keep a commons healthy. They map to software teams with uncomfortable precision.

Clear boundaries. Who owns which parts of the codebase? When documentation is "everyone's responsibility," it's no one's responsibility. The shared fridge at work is full by Tuesday for the same reason.

Monitoring. Code review, CI pipelines, linting, type checking. Not bureaucracy. The mechanism that makes extraction visible. Without it, a stale doc looks identical to a current one.

Graduated sanctions. A PR comment is a nudge. A failing build is a stronger signal. A team conversation about recurring shortcuts is stronger still. Healthy teams calibrate. Unhealthy teams oscillate between tolerating everything and blaming someone.

Collective decision-making. When standards are imposed without buy-in, the team produces compliance, not quality. Rules work when the people bound by them helped write them.

Proportional costs and benefits. The people who ship features should also maintain the docs those features need. When one team writes and everyone else reads, the writers burn out.

The view from outside

Nobody sees their own commons degrading. The decline is slow, and every shortcut makes sense in isolation. You skip the doc update because the feature is urgent. You leave the flaky test because fixing it isn't in the sprint. Individually rational. Collectively, the commons erodes.

At madewithlove, we embed in teams. Write code, attend standups, ship features. We don't arrive with a governance framework. We just name what we see. "Nobody owns this doc." "This knowledge lives in one person's head." "Who updates this when the API changes?" Small observations, dropped into standups and PR reviews. Not a diagnosis. A seed.

Once a team has the word "commons," they start seeing the extraction everywhere. The flaky test suite stops being a quality problem and becomes a governance question. The stale doc stops being someone's fault and becomes a missing owner. The vocabulary is the intervention.

The tragedy of the commons isn't a law of nature. It's what happens when nobody builds governance. Look at yours. Who owns what? How do you detect drift?

The commons can hold. It just needs tending.

Follow our bi-weekly SaaS show

Fast, honest insights from the trenches of SaaS. Andreas and Sjimi, partners at madewithlove, share what they’re seeing inside real SaaS teams and products every two weeks.