Tragedy of the Commons

Activate when: shared resource is degrading even though no one is doing anything "wrong"; team complains about free riders or overuse; designing API quotas, rate limits, or open-source governance; someone says "everyone is overusing this" or "the system worked fine until it got popular"; evaluating why a platform or community is burning out. Do NOT activate when: the resource is fully non-rival (unlimited supply, zero marginal cost); the problem is a purely individual-action issue with no shared resource.

Overview

When a shared resource has individual access but no individual responsibility for preservation, rational users extract private benefit while the cost of overuse is shared — leading to collective degradation. Garrett Hardin named this in 1968; Elinor Ostrom corrected it in 1990 (Nobel 2009): many communities self-govern commons via her 8 design principles without privatization or coercion.

Composes with prisoners-dilemma, principal-agent, network-effects, goodharts-law, repeated-games-reputation.

When to Use

• Diagnosing why a shared resource is degrading (open-source burnout, API abuse, attention market polarizing)
• Designing platforms, marketplaces, shared infrastructure, API quotas, or rate limits
• Designing workplace norms around shared resources (meetings, Slack, email)
• Evaluating regulatory or policy responses to shared-resource problems

Not when: resource is genuinely non-rival; fully private; "commons" framing is misapplied to individual-action problems.

Coaching Novices (Adaptive Front Door)

• Engine mode: user has a concrete commons case → run The Process directly.
• Coach mode: user is unfamiliar → guide step by step.

In Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.

1. One-line: when a shared resource degrades despite each user acting rationally, you have a commons problem — the answer is institutional design per Ostrom's 8 principles, not just "privatize" or "regulate."
2. Check fit: shared resource + individual extraction + shared cost? If not, different frameworks apply.
3. Elicit the resource, users, and current rules: What's shared? Who has access? What rules govern use? What's failing?

[WAIT — do not advance until user responds]

4. Audit which of Ostrom's 8 principles are present / weak / absent in their situation.

[WAIT — do not advance until user responds]

5. Close: name the institutional gaps + propose design applying missing principles + monitoring plan.

[WAIT — do not advance until user responds]

The Process

Step 1 — Identify: shared resource · user community · failure mode · current rules. Step 2 — Verify commons structure: shared access + rivalrous + diffuse responsibility + Hardin pattern (individually rational, collectively destructive). All four yes → commons. Step 3 — Ostrom audit (mark present / weak / absent): 1 Boundaries · 2 Congruence · 3 Collective-choice · 4 Monitoring · 5 Graduated sanctions · 6 Conflict resolution · 7 Right to organize · 8 Nested enterprises. Weak/absent = design targets. Step 4 — Intervene: for each weak/absent principle, design a specific fix. Avoid the "privatize or regulate" binary — Ostrom's institutional design often outperforms both. Step 5 — Monitor: sequence · metrics (resource health, sanctions issued) · quarterly review.

Output Template

text

Commons Design: <resource>
Structure: shared resource | boundaries | failure mode | current rules
Verification: shared Y/N · rivalrous Y/N · diffuse responsibility Y/N · Hardin pattern Y/N
Ostrom audit: [1–8: present/weak/absent]
Intervention: [per weak/absent principle] · why not privatize · why not pure regulation
Implementation: sequence · metrics · review cycle

→ Method in Action: Hardin 1968 + Ostrom's Empirical Correction + Modern Digital Applications

Pack: Commons Patterns

Commons	Failure mode	Ostrom countermeasure
Open-source project	Maintainer burnout	Contribution rules; governance council; sustaining funding
API / cloud infrastructure	Abuse degrades service for all	Tiered quotas; monitoring; graduated sanctions
Slack / meetings	Notification overload	Norms; meeting-free blocks; signal-noise metrics
Fisheries / antibiotic efficacy	Stock collapse / resistance	Quotas; stewardship programs; surveillance
Atmospheric carbon	Climate change	Carbon pricing; international agreements; local action

Applying It Well

• Ostrom's 8 principles are load-bearing, not optional: missing several reliably produces Hardin tragedy.
• Privatization works when exclusion is feasible and transaction costs are low. Regulation works when the regulator has information and legitimacy. Ostrom's self-governance works when users can communicate, monitor, and self-organize — often best for technical commons.
• Peer monitoring (users see each other's behavior) differs from punitive surveillance; successful commons use the former.

→ Primary sources: references/sources.md

Common Rationalizations

[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.

Fake move	Reality
[D] "Commons always fail; we have to privatize"	Hardin over-stated this. Ostrom's empirical evidence: many commons endure for centuries with the 8 principles.
[D] "The government must regulate"	Sometimes. Often community self-governance is faster, cheaper, and more legitimate.
[D] "Punish free riders; that's enough"	Graduated sanctions is one of 8 principles. Punishment alone without monitoring, boundaries, etc. doesn't work.
[D] "Open source means free; we don't owe anything"	Maintainer labor is a commons; without contribution mechanisms it depletes (xz 2024 was the warning).
[D] "Our users would never abuse the API"	The Hardin structure predicts abuse from a substantial fraction regardless of intent. Design accordingly.
[D] "We don't need formal governance; people are reasonable"	Even reasonable people benefit from boundaries, monitoring, and conflict resolution.
[D] "Monitoring is surveillance; we don't do that"	Ostrom distinguishes cooperative peer-monitoring from punitive surveillance. Successful commons use the former.
→ Add [O] entries here after each real use — paste the actual failure pattern	What went wrong and why

Red Flags

• Shared resource degrading; rules unclear or unenforced
• Free-rider complaints but no graduated sanctions exist
• Users have no voice in rule-setting (Ostrom principle 3 absent)
• Default response is "regulate it" or "privatize it" without considering institutional design

Verification

• Shared resource and user boundaries specified
• Commons structure verified (shared + rivalrous + diffuse responsibility)
• Ostrom's 8 principles audited; weak/absent identified
• Institutional intervention designed; privatize-or-regulate alternatives addressed
• Monitoring metrics and review cycle scheduled

---

Part of deciqAI Knowledge Skills — open-source thinking skills that make rigor executable for AI agents. Built by deciqAI · https://deciqai.com · Contributions welcome — see the template at the repo root.