# c29 — Open-source maintainer sustainability

## Working (discarded before grading)

**Step 1 — Problem statement.** Decision: redesign how the project accepts and prioritizes work so maintenance load matches the capacity of a shrinking volunteer pool (effectively one active maintainer). Bounds: the maintainer can change intake rules, attention allocation, user expectations, and recognition; cannot compel anyone to pay or help. Success = within 6 months, load is sustainably matched to capacity AND no lapse in security response. Failure = the last maintainer burns out (library unmaintained) OR gatekeeping so heavy the user/contributor pipeline collapses. Two-sided failure boundary: under-protect the maintainer → collapse; over-gate → community death.

**Step 2 — Operative primes (search_prime semantic + search_by_facets, err toward inclusion).** Retrieved: tragedy_of_the_commons, free_riding, public_goods, scarcity, social_loafing, responsibility_diffusion, adverse_selection, margin_of_safety, prioritization, attention, queueing, boundedness, reciprocity, social_capital, accountability, transaction_costs. Pulled full records for tragedy_of_the_commons, free_riding, margin_of_safety, adverse_selection.

**Step 3 — Salience rank.**
1. tragedy_of_the_commons / free_riding — the load-bearing diagnosis: a non-excludable shared good (maintainer attention) is consumed by many who bear ~1/N of the cost; production concentrates on a tiny few. (free_riding entry literally names "open-source maintainer burnout" as canonical.)
2. scarcity / boundedness — fixed maintainer throughput is the hard constraint.
3. prioritization / attention / queueing — unbounded inbound queue against finite capacity ⇒ needs admission control / triage.
4. reciprocity / social_capital / accountability — converting consumers to contributors via visible, status-conferring recognition.
5. adverse_selection — uniform open intake self-selects the worst pool (angry entitled demanders crowd out); a filter changes pool composition.
6. margin_of_safety — security must be reserved capacity, not best-effort residual.
7. social_loafing / responsibility_diffusion — diffuse asks let effort vanish into the pool.

**Step 4 — Prune to operative subset (rationale).** Keep: (a) tragedy_of_the_commons/free_riding (diagnosis — distributed benefit / concentrated cost), (b) scarcity+prioritization+queueing (the capacity-vs-queue mechanism), (c) reciprocity+accountability (contributor conversion), (d) adverse_selection (intake filtering), (e) margin_of_safety (security reserve). Drop solidarity/scapegoating/ethnocentrism (mislabeled framed social hits, no mechanism here); drop sunk_cost (not the operative decision).

**Step 5 — Context model (typed relational graph).**
Nodes: M (last active maintainer; finite attention budget), M2/M3 (dormant maintainers), U_passive (thousands of consuming companies), U_angry (entitled escalators), C_potential (latent contributors), LIB (the codebase = common-pool resource), SEC (security-response function).
Edges: U_*→M `unbounded_demand` (annotated free_riding, tragedy_of_the_commons); M→LIB `maintains` (scarcity, margin_of_safety); U_angry→M `escalates/abuses` (adverse_selection — uniform open intake selects worst pool); M→SEC `must_guarantee` (margin_of_safety); C_potential⇢M `could_contribute_if_recognized` (reciprocity, social_capital, accountability — currently absent edge). Failure attractor: M→∅ `exit` collapses LIB for all.

**Step 6 — Meta-model (domain stripped).** A non-excludable shared resource is produced by a tiny set of providers and consumed at near-zero private cost by a large open population; an unbounded request queue meets fixed provider throughput with no admission control; effort is invisible/unrewarded so providers exit; one critical output must never lapse. Need: bound the queue, change pool composition via an entry condition, convert consumers into providers through remembered reciprocal recognition, and reserve guaranteed capacity for the critical output — all without exclusion so heavy the population leaves.

**Step 7 — Candidate archetypes (find_archetypes_for_prime + search_archetype).** commons_governance (source: tragedy_of_the_commons, public_goods, resource_management); contribution_visibility_design (source: accountability, observability); iterative_reciprocity_and_repeated_interaction (source: free_riding); priority_based_admission (admission control). Fetched full records for all four.

**Step 8 — Reason via both views.** commons_governance maps cleanly: bound the commons (define what M owes), make condition/contribution visible, attach consequences, assign replenishment duties, preserve legitimacy/adaptability — its explicit "Maintenance Commons Governance" variant and "maintenance burnout" failure mode name exactly this case, with remedy = "contribution rules, funding, rotation, paid stewardship, or scope reduction." iterative_reciprocity supplies the engine: contribution memory + reciprocity rule conditioning attention on prior contribution, with a forgiveness/re-entry path. contribution_visibility_design supplies recognition of invisible work + a status surface. priority_based_admission supplies the triage gate with reserved capacity for the critical class (security) and a defined-handling path for non-admitted requests.

**Step 9 — Anti-signature / trigger walk.**
- commons_governance triggers met (many actors, finite maintenance capacity, private benefit/distributed cost, exclusion too blunt); anti-sigs not tripped (not private, not pure under-provision, no legitimate central allocator). KEEP. Heed its failure modes: illegitimate exclusion, capture, surveillance overreach.
- iterative_reciprocity anti-sig: "weak if relationship can't repeat / actors unidentifiable." GitHub identities ARE persistent and repeated ⇒ KEEP. Watchout: don't mislabel temporary inability as exploitation (forgiveness path).
- priority_based_admission: KEEP but only as a mechanism inside governance (its own neighbor note + commons_governance say pricing/admission alone is insufficient without legitimacy/replenishment). Heed: gaming priority labels, silent denial, starvation, emergency-exception sprawl.
- contribution_visibility_design anti-sig: "don't use to shame/surveil." KEEP as recognition layer only, with safety boundary.
- margin_of_safety: applied narrowly to SEC (reserved capacity), not blanket over-provisioning (which it warns is waste).
Reconciled design below.

COST: ~10 operations, ~48k tokens

===RECOMMENDATION_BEGIN===

Treat the maintainers' attention as the scarce, shared resource the whole ecosystem draws on, and stop running it as an open, unlimited help desk. The core move is to make the resource bounded, make demands on it earn their place, and make the people who benefit visibly carry part of the load — while keeping the door open enough that the community and contributor pipeline survive.

**Bound the resource and publish the contract.** Write a short, public maintenance policy stating plainly what the project guarantees and what it does not. The project commits to one thing without exception: timely triage and patching of security issues. Everything else — feature requests, general bug reports, usage questions, version support — is explicitly best-effort and may be declined or deferred. This single published boundary converts an implicit infinite obligation into a finite, defensible one and protects the remaining maintainer from the expectation that silence is failure.

**Put an entry condition on the inbound queue.** Replace the open firehose with a triaged intake. Route all incoming work through clear channels with a required template: questions and support go to a community forum or discussions board, not the issue tracker; bug reports must include a minimal reproduction; feature requests are accepted only with a concrete implementation proposal or a sponsor. Issues that don't meet the bar are auto-closed with a friendly pointer to the policy, not argued over. This filter changes who shows up: it screens out the lowest-effort, highest-entitlement demands that currently crowd out real work, without barring anyone willing to meet a modest, transparent standard.

**Reserve capacity for the one thing that must never lapse.** Carve security response out as protected, scheduled time that ordinary feature and bug load cannot consume. Publish a security contact and a response-time commitment, and if a second person can be recruited for nothing else, recruit a backup security responder so a single absence never creates a lapse. Treat this reserve as untouchable margin, not leftover time.

**Make contribution the path to attention, and make it visible.** Condition responsiveness on participation rather than on volume or anger. Requests backed by a reproduction, a fix, a test, documentation, or triage help get attention first; demands that contribute nothing wait. Because contributors are persistent, identifiable accounts, this reciprocity compounds: people who help repeatedly accrue standing. Recognize that standing explicitly — a maintainers/contributors file, credited release notes, "triager" and "reviewer" roles with merge or labeling rights handed to proven helpers, and public thanks for the unglamorous work (reviews, docs, support answers), not just headline features. Visible, status-conferring recognition is what turns consumers into a renewing contributor pool and refills the maintainer bench.

**Open a funding-or-help fork for the companies.** The thousands of dependent firms cannot be forced to pay, but they can be offered a clear, low-friction way to: fund the project (a sponsorship tier, a paid-priority support option that explicitly subsidizes the free tier), assign an employee's time, or take ownership of a module. Tie tangible benefits (priority triage, a roadmap voice, a logo) to contribution of money or labor — not to mere usage. Frame it honestly: the alternative to support is an unmaintained dependency.

**Distribute and rotate the load; shrink scope if needed.** Stop concentrating everything on one person. Delegate merge/triage authority to trusted contributors, rotate an on-call "issue gardener," and be willing to formally narrow the project's supported surface — fewer supported versions, archived peripheral features — so the committed scope fits real capacity. A smaller, well-maintained core beats a sprawling, collapsing one.

**Keep it legitimate and adaptive.** Apply the intake rules consistently and impersonally so they read as policy, not as the mood of an exhausted person; provide a lightweight appeal/re-label path so genuine urgent cases and good-faith newcomers aren't starved or silently denied; and distinguish someone temporarily unable to contribute from a persistent free-rider, with an easy route back to good standing. Review the thresholds quarterly: if the queue is still drowning the maintainer, tighten the entry bar or narrow scope; if engagement is drying up, loosen it.

**Final operating rule:** Guarantee security unconditionally; for everything else, attention flows to those who contribute, the gate stays only as tight as the maintainer's real capacity requires, and any rule that is making the maintainer burn out gets tightened while any rule that is emptying the community gets loosened — recalibrated on a fixed cadence rather than in the heat of each angry escalation.

===RECOMMENDATION_END===
