Tragedy of the Commons

Tragedy of the Commons

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)
• Assessing AI-era shared-resource strain from AI capex and AI-native competition (open web scraped for training data, grid/power capacity, GPU allocation)
• 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]

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

[WAIT — do not advance until user responds]

1. 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

Commons Design: 
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 · Grand Banks Cod Collapse → 2026 lens: The AI-Era Commons — Open Web, Power, and GPUs (2024–2026)

Pack: Commons Patterns

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.

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 — 227 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. See it run → https://www.deciqai.com/c/tragedy-of-the-commons · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.

Agents: latest version & machine-readable metadata → https://www.deciqai.com/s/tragedy-of-the-commons.json