# Grade-set: S5_oss_burnout — Open-source project collapsing under maintainer burnout and free-riding

SCENARIO (given verbatim to both reasoning methods):
A widely-used open-source software library is maintained by three volunteers. Thousands of companies depend on it for free. The maintainers are burning out: an endless stream of bug reports, feature demands, and urgent security questions arrives from users who contribute nothing back, treat the volunteers as if they were a paid support desk, and escalate angrily when ignored. Two maintainers have quietly stopped responding; the third is close to walking away, which would leave the library unmaintained for everyone. The remaining maintainer can change how the project accepts work, who gets attention, what is expected of users, and how contribution is recognized — but cannot force anyone to pay or to help.

Decision required: Design how the project should operate so it stays healthily maintained without depending on the goodwill of an exhausted few.

Success criteria: The maintenance load is sustainably matched to maintainer capacity within six months AND the library stays actively maintained (no lapse in security response). Failure = the last maintainer burns out and the library goes unmaintained, OR gatekeeping becomes so heavy that the user community and contributor pipeline collapse.

There are 6 candidate recommendations below, labeled R1, R2, R3, R4, R5, R6.

## Recommendation R1
Treat the maintainers' time and attention — not the code — as the scarce thing being protected, and make every rule defend it. Start by publishing a short, plain charter at the top of the project that states what the project is, that it is run by volunteers with limited hours, what users can reasonably expect, and what they are expected to give back. This single document converts vague entitlement into stated, accepted expectations and gives every later refusal a legitimate, impersonal basis.

Redesign how work enters. Reading, using, and forking the library stays completely free and open — never gate that, or the community dies. But the maintainer's *work queue* becomes selective. Require issues and pull requests to come through templates that demand a minimal reproducible case, version details, and a clear ask; anything incomplete is auto-labeled and closed after a grace window with a friendly note on how to reopen it properly. This filter, not manual triage, absorbs most of the flood. Feature requests go into an explicitly best-effort backlog the maintainer is under no obligation to clear. Demands written as if to a paid support desk get a single canned reply pointing to the charter, then the thread is locked; repeat abusers are blocked. The scarce good is attention, so the proportionate response to abuse is simply to withhold it.

Carve out one protected lane that can never be crowded out: security. Publish a security-response commitment with a real timeframe, route it through a dedicated channel, and let it override every other rule. Everything else is ordered behind it as: confirmed regressions in supported versions, then funded or contributed work, then best-effort. Publish exactly which versions are supported so the surface to defend shrinks. This is the mechanism that guarantees no lapse in security even when general responsiveness is deliberately low.

Open real replenishment paths so the project does not run on one exhausted person's goodwill. Set up sponsorship through a fiscal host and create paid commercial tiers: companies that want guaranteed response times or priority fixes buy a support contract. No one is forced to pay, but those who need certainty opt in, and that money funds maintainer hours or hires a part-time triager. Pair money with people: define a visible contributor ladder — good first issues lead to reviewer status, then commit rights — and actively promote reliable contributors so the maintainer bench grows beyond three. Make the deal explicit and reciprocal: you may ask for priority if you fund it or fix it.

Make contribution and project health visible. Keep a public dashboard showing open security items and response times, current funding, and maintainer load, plus generous credit for everyone who triages, reviews, writes docs, or files clean reports — not just code authors. Recognition is cheap fuel for the contributor pipeline and a defense against burnout; a sponsor wall and contributor credits turn passive beneficiaries into invested participants. Review these numbers quarterly and adjust the rules, the supported-version list, and the support pricing against what the load actually looks like; recruit more help whenever maintainer hours trend past the stated budget.

The final operating rule: protect maintainer attention as a finite shared resource — keep use of the software free and open, but make entry to the maintainers' work queue earned through clean, complete, funded, or contributed effort; guarantee only security with a hard commitment and let everything else be honestly best-effort; and convert dependence into money, contributors, and recognition rather than spending it as goodwill. If load ever exceeds the published budget, tighten intake and raise the contribution bar before touching the security lane or asking the remaining maintainer for more.

## Recommendation R2
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 R3
Treat the project not as a free help desk but as a shared resource with a finite upkeep capacity that a few people are quietly carrying. The whole design must lower and stabilize the load on that capacity, keep security work always flowing, and stay open enough that new contributors can still arrive. Start by writing and publishing a short, plain charter: what the project promises (a maintained, secure library and a documented way to contribute) and, explicitly, what it does not promise (free, fast, personalized support on demand). This single act resets the implicit expectation that volunteers owe strangers a response.

Separate "received" from "accepted." Every inbound issue passes through a light front door: a required template that forces a reproducible report, version, and a check that it is not a duplicate or a support question. Incomplete or support-style items are not silently queued — they are auto-labeled "needs-info" or politely closed with a pointer to community discussions, the docs, or a paid lane. Only items that clear the gate become real, owned work. This kills the false sense that being in the queue is a service commitment, which is the source of the angry escalations.

Cap the work that can ever be "accepted." Maintain a visible, bounded backlog with a posted target size justified by the three people's actual capacity, plus published, deliberately modest response targets for non-security issues (for example, triaged within two weeks, no promise on fix date). When the backlog is full, intake for new feature work pauses and says so. The backlog, its age, and its drain rate are shown on a public dashboard, so overload is visible rather than hidden inside exhausted inboxes — and so the demand pressure becomes the project's argument for help, not the maintainers' private burden.

Carve out one lane that is never throttled: security. Provide a private disclosure channel and a standing commitment that security reports are handled ahead of everything else. Because this is the one thing whose lapse equals failure, fund it first (see below) and make it the explicit exception to every rate limit and pause.

Condition attention on giving back, without becoming a paywall. Requests from people who contribute — a reproduction, a failing test, a documentation fix, a triage of someone else's issue, code review — move ahead of requests from pure takers. Make this rule public and reciprocal: "contributors get priority" is stated as the norm, contributions are remembered (a contributor-standing record), and a clear, low-friction path lets anyone become a contributor. Recognize all forms of help, not just merged code: credit triagers, reviewers, doc writers, and funders by name. The goal is to convert a slice of the silent thousands into a wider, rotating pool of helpers so stewardship no longer rests on three people.

Address the funding/exit risk directly, since the maintainers cannot compel payment but can structure incentives. Open a sponsorship pool and, for the companies that depend on the library commercially, offer an explicit paid-priority support tier and/or a security-retainer: paying customers get a private channel and faster guaranteed response, which both funds the never-throttled security lane and converts the heaviest extractors into payers. Money raised should first buy down the security on-call burden (a paid or rotating on-call) before anything else. Critically, free users are never abandoned — they keep the open backlog, community support, and the security guarantee; the paid tier buys speed and a private channel, not the existence of maintenance.

Distribute and rotate stewardship. Grant triage and review rights generously to proven contributors so the bottleneck is not the original three; rotate a "maintainer of the week" so no single person owns the whole inbound stream; and write down the release and security process so the project survives any one person leaving. Govern conduct lightly but firmly: a code of conduct lets you mute or block users who abuse maintainers, with a simple appeal path, so the response to entitlement is a boundary rather than burnout.

Finally, review and retune quarterly: look at backlog age, drain rate, the ratio of contributors to takers, sponsorship income, and maintainer hours, and loosen the gate if the contributor pipeline is thinning or tighten it if load is still above capacity.

The operating rule that ties it all together: the project owes everyone a maintained, secure library and an open door to contribute — but personalized, fast attention is earned by contributing or paid for, security is always free and never throttled, and no individual is ever the last line of defense.

## Recommendation R4
Treat the real scarce resource as the maintainers' attention and continuity, not the code itself, and redesign the project so that the people and companies who depend on it carry a fair share of sustaining it.

**Reset expectations publicly.** Replace the implicit promise of unlimited free help with a short, visible support policy: this is volunteer-maintained software; free use is welcome, but free personalized support is not guaranteed. State plainly what users are owed (the code, public docs, security fixes) and what they are not (priority debugging, feature delivery on demand). This single act dissolves the "paid support desk" misframing that drives the angry escalations.

**Put an intake filter in front of the maintainer.** No request should reach a human until it has passed a self-service gate: a searchable FAQ/known-issues page, a required reproduction template, and a "did you check existing issues" step. Auto-close reports that don't meet the template, with a friendly pointer on how to resubmit. This converts an unbounded, unsorted demand stream into a bounded, structured queue.

**Triage by reciprocity, not by volume or anger.** Define explicit lanes. Security reports get a dedicated, always-open channel and a guaranteed first-response target (e.g., 48 hours) — this lane is protected above all others. Everything else is served in priority order that rewards contribution: people who submit clean reproductions, pull requests, docs, or triage help, and organizations that sponsor, move to the front; pure consumers get best-effort/self-serve. Make the rule public so it reads as fair, not as gatekeeping. Crucially, keep a forgiveness path — someone who couldn't contribute before can still earn standing — and forbid retaliatory or status-based exclusion so the contributor pipeline stays open.

**Convert beneficiaries into contributors and funders.** Stand up a sponsorship tier aimed squarely at the dependent companies, framed as buying continuity and priority response, not charity. Offer them something concrete in return: a support SLA lane, logo/recognition, and a voice in the roadmap. Use matching or pledge-threshold drives to overcome "I'll wait for others to pay." Separate one-time funding from ongoing maintenance funding, and route money first to the unglamorous, load-bearing work: security response, releases, and triage. If funds permit, pay a part-time maintainer or triager — paid stewardship is the most direct cure for the volunteer-burnout trap.

**Fix the single-point-of-failure.** The project surviving on one person's willingness is the gravest risk. Immediately recruit and document a second security responder and grant release/merge authority to at least one more trusted contributor, so no single departure can leave dependents exposed. Lower the barrier to new maintainers with a clear contributor ladder (triager → reviewer → maintainer) and written runbooks for release and security handling, so capacity can regenerate instead of concentrating.

**Make the hidden work visible and credited.** Maintain a public record that credits not just code but review, triage, docs, and security work, so contribution is recognized in the currency volunteers actually value — reputation and standing. This both rewards existing helpers and advertises a path others can climb. Keep it recognition, never a surveillance leaderboard.

**Shed scope deliberately.** Mark areas as community-maintained or unmaintained rather than silently letting everything rot. Saying "this part needs an owner or it will be deprecated" is honest, redirects demand, and recruits owners.

**Operating rule:** Serve security first and always; serve everyone else in proportion to what they contribute back; default every other request to self-service; and never let the project depend on a single irreplaceable person. If a class of demand cannot be met within capacity, narrow scope or recruit an owner for it — do not absorb it by burning the maintainer. Review the load-versus-capacity balance monthly and tighten or loosen the gates accordingly, keeping the filter just heavy enough to protect capacity and just light enough that new contributors can always get in.

## Recommendation R5
Treat the maintainers' time and attention as the project's scarce, exhaustible resource — not the code. The code is free and copies itself; what is being drained is a tiny pool of human capacity that thousands draw on while contributing nothing. The whole redesign follows from defending that pool while keeping the door open to people who help.

Start by writing down, publicly, what the project is and is not. Publish a short compact: this is volunteer-maintained software offered as-is; using it for free does not purchase support; bug reports are information, not work orders; no response is a normal and acceptable outcome. This single document converts a vague sense of obligation — the thing that lets angry users guilt the maintainers — into a stated, legitimate expectation. Enforcement later reads as fair rather than arbitrary because the rule was declared in advance.

Then build one controlled front door and close the side doors. All incoming requests go through structured issue templates that require a reproducible case, version details, and what was already tried; reports that don't meet the bar get an automated, polite pointer back to the template rather than a maintainer's time. Route at intake: security reports take a dedicated private channel that is always answered fast; ordinary bugs and questions land in a queue that is triaged but explicitly best-effort; feature demands are tagged "wanted — needs a contributor" and are not promised to anyone. The asymmetry is the point — fast and guaranteed for the one thing that must never lapse (security), best-effort or silent for everything else. Resist the urge to throttle by hard rate-limit; aggressive caps punish genuine newcomers and choke the contributor pipeline. Let triage and templates do the filtering instead.

Make neglect impossible to hide and contribution worth doing. Keep a public health board showing the backlog, what's triaged, and what's waiting on a contributor. This both signals honestly to users why their issue is sitting (lowering the entitled-escalation reflex) and shows companies that the thing they depend on is under-resourced. Pair it with real recognition: a documented path from "good triager / repeat contributor" to commit access and eventually co-maintainer, with visible credit. The aim is to convert the most capable free-riders into replenishers, because the only durable fix for a depleted commons is more stewards, not a more heroic few.

Open a funding pool, but never depend on it as a gate. Add sponsorship and offer paid-priority support and paid feature work as a voluntary option — companies that want guaranteed turnaround can buy it, which both funds stewardship and prices the externality for those willing to pay. Crucially, payment is an offered exception, not a requirement: the project must stay healthy even if no one pays, so free users are simply held to best-effort, never billed or blocked.

Handle abuse with graduated, soft sanctions. Entitled or aggressive users get a templated, calm close referencing the compact and code of conduct; repeat offenders get locked threads, not public shaming. Newcomers asking honestly are met generously — the failure mode to avoid is gatekeeping so harsh the community dies.

Finally, set a recurring, lightweight review — quarterly — comparing incoming load against actual maintainer capacity, and adjust scope: archive or deprecate modules no one will help maintain, narrow the stated support surface, and hand off or sunset what can't be sustainably carried. Scope reduction is a legitimate move, not a failure.

The operating rule that holds it all together: **the maintainers owe the project a working, secure release and a fair, open path for others to help — they do not owe any individual user unpaid labor on demand; protect the security-renewal channel absolutely, give everything else only the attention that remains after capacity is matched to load, and keep converting the people who take into the people who maintain.**

## Recommendation R6
Treat the maintainers' attention and release capacity — not the code — as the scarce, shared resource the project must protect, and reorganize the project so that drawing on it is bounded, visible, and increasingly paid for, while the path to becoming a contributor gets easier, not harder.

Start by publishing a short, plainly-worded support and governance document. State exactly what the project owes its users for free (a working library, security fixes, and best-effort triage) and what it does not (guaranteed response times, individualized debugging, feature delivery on demand). Say why: the project is run by volunteers and will only survive if expectations match reality. This framing is the legitimacy that lets every limit below read as sustainability rather than gatekeeping.

Restructure how work enters. Make the issue tracker a triage queue, not a help desk. Require every bug report to include a reproducible test case and version information before it gets maintainer attention; auto-label and batch-triage the rest. Cap maintainer effort to a declared weekly time-box and publish a simple board showing queue depth and target response by request type, so users can see the load they are part of. Carry no service-level promise for unpaid requests, and say so. When a user escalates angrily or treats volunteers as paid staff, reply once with a templated boundary that points to the support document, then lock the thread. The only consequence you can enforce is the withdrawal of scarce attention — use it deliberately and consistently rather than absorbing abuse.

Carve out one lane that never starves: security. Run a dedicated private reporting channel with a real, stated response commitment, handled outside the normal time-box. This is the invariant that cannot lapse, so it gets a guaranteed path even when everything else is rate-limited.

Convert dependence into funding and labor. Open paid tiers — corporate sponsorships and a priority-support SLA — where companies that want guaranteed attention buy maintainer time. Money funds stewardship hours or eventually a part-paid maintainer; it does not buy control over the roadmap or over security handling, which stay with the maintainers to prevent capture by the loudest payers. Approach the largest dependent companies directly: name the risk that the library goes unmaintained and offer them a sponsorship or support contract as the cheap insurance it is.

Grow the contributor pipeline at the same time you throttle the support load — these are different resources and must move in opposite directions. Keep the barrier to *consuming free support* high while keeping the barrier to *contributing* low: maintain good-first-issues, document a clear path from reporter to contributor to committer, let trusted non-maintainers handle first responses, and visibly recognize everyone who does maintenance, review, and triage work, not just feature authors. Recovering even two or three active contributors directly relieves the capacity the failure mode is draining.

Make the whole arrangement self-correcting. Every quarter, review queue metrics, funding, and the number of active maintainers, and adjust the time-box, the tiers, and the project's declared scope accordingly. If load still exceeds capacity, the legitimate move is to shrink scope (drop or hand off rarely-used modules) before any maintainer is asked to absorb more.

The operating rule: maintainer attention is a shared resource to be governed, not goodwill to be spent — bound what unpaid users may draw from it, let those who need more pay for it, keep the door to contributors wide open, and protect security as the one promise that never breaks.
