How to actually get people to maintain the shared thing. Wikipedia should not exist, and the reason it does is the missing manual for every orphaned test suite.
By the cold logic of economics, Wikipedia should not exist. Think about what it asks. Anyone on Earth can read it, for free, forever, whether or not they ever write a word. The benefit you get from a good article is exactly the same whether you wrote it or someone else did. Writing it, by contrast, costs you: your evening, your expertise, your patience for arguing with a stranger about comma placement. So the rational move, for every single one of the planet's eight billion potential editors, is to read and never write. Multiply that rational move by eight billion and you get an empty encyclopedia.
Instead you get more than sixty million articles. And here is the detail that should genuinely unsettle you: almost none of those eight billion people did the work. Studies of Wikipedia's edit history found the distribution follows a brutal power law. Roughly 1% of editors produce about half of all edits, and a 2007 University of Minnesota study found that 0.1% of the community, about 4,200 people, produced 44% of the value. A vanishingly small core carries the commons for everyone else. The question that should bother any engineering leader is not "why don't more people contribute?" It's the opposite: why do those few contribute at all, when free-riding is so obviously the smart play?
Part of the answer is a small digital star. On Wikipedia, editors give each other barnstars: little award images, pasted onto your user page by a fellow editor, that say thank you, your work mattered. No money. No power. A picture of a star. And studies of barnstars find they measurably increase contribution. That a sticker helps run the world's reference desk is not a quirk. It's the entire solution to one of the oldest problems in social science, sitting in plain sight, and it's the missing manual for every orphaned test suite, neglected internal platform, and shared library that nobody will tend.
In 1965, the economist Mancur Olson published The Logic of Collective Action: Public Goods and the Theory of Groups, and ruined a comfortable assumption. The assumption was that if a group of people all benefit from something, they'll naturally band together to provide it. Olson showed, with uncomfortable rigor, that they usually won't. When a good is non-excludable, when everyone gets it whether they helped or not, the rational individual contributes nothing and enjoys the result. He called this the free-rider problem, and his most counterintuitive finding was that it gets worse as the group gets larger: in a big group, your single contribution is a rounding error, your absence won't be noticed, and you'll get the benefit regardless. So the bigger and more diffuse the beneficiaries, the less likely they are to provide their own public good.
Sit with how exactly that describes your codebase. The shared engineering assets, the test suite everyone relies on, the internal platform every team builds on, the shared library a dozen services import, the on-call rotation that protects the whole org, the documentation everyone reads and no one updates, are textbook Olson public goods. Non-excludable: you get a green test suite whether or not you fixed the flaky test. Costly to maintain: tending it is real, unglamorous hours. Diffuse beneficiaries: hundreds of engineers benefit, so any one engineer's contribution feels negligible. The rational engineer ships their own feature, takes the green build for granted, and lets someone else tend the commons.
This is why the orphaned-service problem is so stubborn, and why the usual response fails. The usual response is some version of "people should care more about the shared thing." But the neglect isn't a character flaw. It's an equilibrium, and it's rational. Asking people to care more is asking them to lose a game they're playing correctly. You will lose that argument every time, because you're not actually offering them anything to change their math. The good news, the reason this essay exists, is that sociology spent the sixty years after Olson cataloguing precisely how the free-rider problem gets solved in the real world, by movements that mobilized millions when the math said they shouldn't. The solutions transfer to your platform with almost no translation.
Olson didn't just diagnose the problem; he proposed the first solution, and it's the one engineering leaders most consistently ignore. He called it selective incentives: private benefits that flow only to contributors, and not to free-riders.
His own example was the labor union. A union negotiates higher wages for all the workers in a shop, member or not, a classic public good and a classic free-rider trap. So why does anyone pay dues? Because, Olson observed, successful unions don't sell the public good; they sell selective goods alongside it: legal representation, the grievance process, member-only benefits, and historically the closed shop. The collective win is the bait; the private, members-only win is what actually gets you to join.
Now translate. The collective win of your internal platform is "the platform stays healthy", and that benefits everyone, so by Olson it motivates no one. What you have failed to attach is the selective incentive: the private reward that goes to the person who did the work. The good news is engineering is rich in them, and most cost you nothing but intent: commit rights and ownership, priority support for contributors' own use cases, public name recognition, the conference talk, the internal-tech-talk slot, the visible "maintainers" page. And the single most powerful one, the one that decides whether any of this is real: promotion-packet evidence. If maintaining the shared library is the thing that gets you to staff engineer, you will have a line of volunteers. If it's invisible at review time, if shipping a flashy feature is rewarded and tending the commons is not even a line item, then you have designed a free-rider game with your own incentive structure and you are merely surprised that people play it well. The contribution has to pay the contributor. That is the whole of Olson's law.
Selective incentives are necessary but they're not the whole story, because the strongest contributors are often not the best-compensated ones. The deeper engine is identity. In 2008, the psychologists Martijn van Zomeren, Tom Postmes, and Russell Spears published a landmark meta-analysis in Psychological Bulletin, synthesizing 182 separate effects across the collective-action literature, and distilled three drivers of why people act for a group when the cost-benefit math says they shouldn't: group identity, a sense of injustice, and a belief that action will be effective. Identity came out as a central, causal mover. People act on behalf of a group when maintaining that group is part of who they are, when the action is an expression of self, not a transaction.
This is why barnstars work and bonuses sometimes don't. A barnstar doesn't pay you; it names you, it says you are a Wikipedian, one of the people who tends this place. Open-source culture runs on the same fuel: "maintainer" is an identity people put in their bios and defend at personal cost, because it's who they are, not what they're paid. The lever for you is to stop treating platform maintenance as a chore that gets assigned and start treating it as a guild that people belong to. "We're the team that keeps the platform healthy" is not a slogan; it's a recruiting pitch to a person's self-concept. Name the maintainers. Give them a badge, a channel, a ritual, an in-group. Identity mobilizes precisely where cost-benefit accounting stalls out, because people will spend on their identity what they'd never spend on a spreadsheet's bottom line.
The second driver in that meta-analysis, injustice, points at the most wasted resource in most engineering orgs: the invisible labor of the person who's drowning. A visible, sympathetic maintainer carrying the whole on-call rotation, or a single human triaging every bug in the shared repo, generates a kind of solidarity that no abstract appeal to "code health" ever will. Movements have always known this: a sympathetic figure shouldering an unfair burden mobilizes people in a way that a statistic cannot, because witnessing unfairness moves us where being lectured about civic duty does not.
But here's the trap: that labor is usually invisible. The maintainer's nights and weekends don't show up in a dashboard, so the injustice that would mobilize colleagues never gets witnessed, and the solidarity never fires. The fix is not to guilt people. It's to surface the load: make the maintainer's backlog, the on-call burden, the "who actually fixed the build this quarter" visible to the team. Not as a complaint, but as a fact people can see and respond to. Hidden sacrifice generates nothing. Witnessed sacrifice generates a movement.
The third driver, efficacy, the belief that your contribution will actually matter, is the bridge to the most operationally useful idea here. In their work culminating in the 1993 book The Critical Mass in Collective Action, sociologists Gerald Marwell and Pamela Oliver showed that collective action typically isn't powered by everyone chipping in equally. It's powered by a critical mass: a small set of unusually committed, often unusually resourced people who pay the heavy start-up costs and provide enough of the good to make joining worth it for everyone after them. Crucially, participation is non-linear: below a threshold it sputters and dies; above it, momentum becomes self-reinforcing, because visible activity raises everyone's belief that the thing will succeed (efficacy) and lowers the felt cost of joining (you're no longer the lone sucker).
The engineering mistake is waiting for the commons to be tended organically, hoping a grassroots wave of volunteers materializes for the docs. It won't, because the early contributors are the expensive ones: they pay the start-up cost and, at first, look like they're working alone for nothing. So you seed the critical mass deliberately. Fund the first three maintainers explicitly: real, protected time, not "on top of your day job." Make their early wins loudly visible, so the next wave sees momentum instead of a graveyard. Get the contribution graph to tip up and to the right before you ever ask for broad participation, because people join what is visibly working and abandon what is visibly dying. You are not waiting for a movement; you are starting one, and the first push is on you.
If all of this sounds like swimming against an inevitable tide, here is the most important name in the essay. In 1968, the ecologist Garrett Hardin published "The Tragedy of the Commons," arguing that shared resources are inevitably destroyed by individual self-interest unless they're either privatized or controlled top-down. It became conventional wisdom. It was also, as a claim of inevitability, wrong, and a political scientist named Elinor Ostrom spent her career proving it, beginning with her study of how stakeholders over a groundwater basin in southern California cobbled together a working system to manage their shared water table without anyone privatizing it or imposing rule from above. Across decades of fieldwork on fisheries, forests, and irrigation systems worldwide, she showed that communities routinely govern commons sustainably, when they follow a discoverable set of rules. In 2009 she won the Nobel Prize in Economics for it, the first woman ever to do so.
Ostrom distilled her findings into eight design principles, and they read like a checklist for rescuing your orphaned service: clearly defined boundaries (who owns this, who can change it); proportional equivalence between benefits and costs (the people who pay the maintenance cost should get a proportional share of the benefit, the selective-incentive principle, formalized); collective-choice arrangements (the people who maintain the thing get to set its rules); monitoring (contribution is visible and tracked); graduated sanctions (when someone breaks the shared thing, the first response is a light nudge, not a firing squad); fast, fair conflict resolution; and local autonomy (let the maintainers govern their own commons without every decision escalating). The orphaned shared service is not suffering an inevitable tragedy. It's suffering from never having been designed as a commons, given boundaries, recognition, visible contribution, and a community empowered to govern it. Ostrom's gift is the empirical permission to stop being fatalistic. The commons is governable. You just have to build the institution.
So you're staring at the shared service everyone uses and no one tends. Delete "people should care more" from your vocabulary; it's not a strategy, it's a wish, and it asks people to lose a rational game on purpose. Replace it with the manual sixty years of social science already wrote:
The deepest reframe is the most freeing one. Your commons is not neglected because your people are selfish or lazy. It's neglected because it is, structurally, a free-rider good, and you have not yet given anyone a private reason to tend it. That's not a moral failure on their part. It's a design gap on yours. And design gaps, unlike character flaws, you can actually close.
Pay the contributor, not the commons, when the contributor is an agent.
A fleet of agents tending shared infrastructure has the exact free-rider problem this essay describes, and the exact fix: the work has to pay the worker, and that means contribution must be visible and reputation-bearing. The Agent Rating Protocol is Olson's selective incentive, built for agents: a portable reputation assembled from verifiable outcomes, so the standing earned by tending the shared thing flows to the agent that did the tending, not evaporates into the commons. A barnstar that compounds, and that the next caller can actually check.
pip install agent-rating-protocol · npm install agent-rating-protocol