# B-vs-B' grade-set: S5_oss_burnout — Open-source project collapsing under maintainer burnout and free-riding

SCENARIO (given verbatim):
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.

4 candidate recommendations, labeled R1, R2, R3, R4.

## Recommendation R1
Treat maintainer attention as the scarce shared resource the whole ecosystem draws on, and redesign the project so that resource is bounded, replenished, and never silently carried by a few. The aim is not to punish users but to change what each request costs and earns.

**Make the resource and its rules explicit.** Publish a short, plain governance note: what the maintainers commit to (security fixes, reviewing well-formed contributions, periodic releases), what they do not (free debugging, on-demand support, feature delivery on anyone's timeline), and how decisions are made. This converts an implicit, infinite obligation into a stated, finite one, and gives the remaining maintainer legitimate ground to decline work without guilt.

**Bound the intake.** Replace the open firehose with a small number of governed lanes, each with a cap. Security reports get a private channel and a guaranteed response path — this lane is never closed. Bug reports require a reproducible, minimal example using a template; reports that don't meet the bar are auto-closed with a courteous note explaining what's missing and inviting resubmission. Feature requests go to a separate discussion area where they must gather support and, ideally, a contributor before becoming work. Set a visible open-issue ceiling per lane; when full, intake pauses with an honest "at capacity, reopening when drained" message rather than accumulating an unanswerable backlog. The default answer to a well-formed request is a pointer to where it sits, not a promise of when it ships.

**Order the work by harm, not by volume or by who shouts loudest.** Serve in this priority: security first, then defects affecting many users, then reviewing community pull requests, then everything else. Protect a slice of attention for reviewing contributions even when bug volume is high — if the contributor lane starves, the pipeline that could relieve the maintainers dies, which is the collapse you must avoid. Entitled escalation earns no priority bump; make that explicit and apply it consistently, because inconsistent exceptions are what reintroduce favoritism and resentment.

**Shift the default from "we fix it" to "we merge it."** Make contributing the fast path: clear contribution guide, "good first issue" labels, fast acknowledgement of pull requests, and a documented route from contributor to reviewer to co-maintainer based on demonstrated reliable work. Recognize all contribution publicly — including triage, docs, and review, not just code — so the people sustaining the project are visible and credited. This is reciprocity made concrete: those who give back get attention and standing; those who only consume get the public artifact and the documented self-serve paths, but not a private support desk.

**Convert dependence into funded stewardship.** The companies that rely on the library are the beneficiaries who currently pay nothing; give them a legitimate way to contribute money or labor. Offer sponsorship tiers and, for organizations wanting reliability guarantees or priority triage, a paid support or retainer option — paid attention is a separate, honest lane, not a queue-jump for the free tier. Route funds toward maintainer compensation and toward a maintenance reserve, separating one-time enthusiasm from durable upkeep. Even modest funding lets the project pay for security audits or buy down a maintainer's hours, turning goodwill into capacity. Where money is impossible, ask dependent organizations for in-kind help: a rotating reviewer, a security contact, documentation.

**Remove the single point of failure.** Document everything required to run a release so no knowledge dies with one person. Recruit at least one additional maintainer or trusted reviewer within the six-month window, and name a security backup so response never depends on one individual being awake. Set a low-ceremony release cadence the team can sustain rather than heroic bursts. If recruitment stalls, the governance note should already declare a graceful-degradation mode — security-only maintenance — so the library survives in reduced form rather than collapsing silently.

**Keep it legitimate and adaptive.** Apply rules proportionally and transparently; pair every "no" with a path (self-serve docs, the contribution route, paid support, or a later intake window). Watch a few signals quarterly: maintainer hours and morale, security response time, open-issue age, contributor count, and any work leaking into private channels. If the caps over-reject genuine need, or if maintainers are still drowning, retune the thresholds — the design is meant to flex with demand, not to ossify.

**Final operating rule:** the maintainers owe the ecosystem a maintained, secure artifact and a fair, open path to contribute — not unbounded free labor on demand. Accept only the work you can honestly serve, serve it by harm and by reciprocity, make contribution the fastest way to get attention, fund stewardship from those who depend on it, and never let the project's survival rest on one exhausted person.

## Recommendation R2
Treat the project not as a help desk but as a shared resource with explicit, published rules. The single most urgent move is to make acceptance honest: the maintainer cannot serve an infinite line, so the line must be bounded and its overflow given a declared outcome instead of festering as silent, impossible obligation.

**Bound the intake.** Publish a short charter stating what the project promises and what it does not. Free, unpaid attention is a finite budget, not an entitlement. Set a hard cap on the open issue queue (for example, a fixed number of "accepted" issues the maintainer commits to look at). When the queue is full, intake auto-pauses: new reports are not silently dropped but routed to a clearly labeled holding state ("not currently accepted — here is what to do") with self-service paths first: search existing issues, a troubleshooting checklist, and a community discussion forum where users help each other. A bot should enforce a required template (version, reproduction, what was tried). Reports that skip it are auto-closed with instructions to refile properly. This alone converts most of the "treat us as paid support" load into either self-service or well-formed, actionable reports.

**Carve out a protected lane for the one thing that must never lapse: security.** Security reports get a dedicated channel, an explicit response-time promise, and an escalation threshold that interrupts everything else. Everything else (feature demands, "urgent" questions, non-critical bugs) is explicitly *not* interruptive — it waits for a scheduled review window. The maintainer should set fixed, public "office hours" (e.g. one batched triage session a week) so deep work and life are not fragmented by whoever shouts loudest, and so users learn the rhythm rather than expecting instant replies.

**Change the terms of attention so contribution, not volume, earns it.** Make the deal visible and reciprocal: anyone can use the library freely, but *attention* from maintainers is prioritized toward people who give back. A well-written reproduction, a fix, a documentation patch, helping another user in the forum, or a sponsorship all move a request up the queue; a bare demand does not. State this plainly and without apology — it is the legitimate price of a free good. Because the same companies return repeatedly, condition future responsiveness on past behavior: chronically abusive or extractive actors are warned, then rate-limited or muted through a graduated, documented ladder (reminder → reduced priority → temporary block), always with a path back. This is not punishment; it is protecting a shared resource from the few who would exhaust it.

**Build a contributor pipeline so the burden stops resting on three people.** Lower the barrier to helping: label "good first issues," write a contributing guide, and — critically — be generous and fast with recognition. Credit contributors by name in release notes, grant commit/triage rights to anyone who shows up reliably a few times, and create a "maintainer of the week" or triage-rotation role so responsibility is distributed and visible rather than hidden. Recognition should reward the invisible work (triage, docs, answering questions), not only merged code, because that invisible work is exactly what is burning people out. Aim explicitly to grow from three maintainers to a wider, rotating circle within six months.

**Open an optional but real funding leg.** You cannot force payment, but you can make contribution easy and make non-contribution visible. Set up sponsorship tiers; publish, without shame, that the project is depended on by thousands of companies and maintained by volunteers, and show what funding buys (faster security response, paid maintainer time). Offer companies a paid support/priority tier — those who want help-desk treatment can buy it, which both funds the work and routes the most demanding users into a channel that pays for itself. Treat any funds as funding *maintenance*, not just features, ideally enough to compensate the core maintainer's time.

**Make the load visible and review it.** Track queue size, response times, security-response latency, and the active-maintainer count on a simple public dashboard. Use cap pressure as the signal: if the queue is constantly full, that is evidence to recruit, narrow scope, or raise the funding ask — not to work harder. Revisit the caps and rules quarterly.

**Final operating rule:** Serve only the work that fits within the maintainers' real, finite capacity, keep one always-protected fast lane for security, and spend the project's scarce attention preferentially on those who contribute back — never on whoever demands loudest. If demand exceeds capacity, the correct response is to recruit, narrow scope, or charge — never to let an exhausted few quietly absorb the gap.

## 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 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.**
