What Kills Open-Source and Nonprofit Projects: The Name, the Domain, Publish Rights, Ownership

1. The structural layer: four things you can't fork

"The project dies when the founder leaves" is almost always misread in an open-source context. MIT and Apache-2.0 already guarantee that anyone can take the code and continue. What dies is never the code. What genuinely cannot be forked is four things:

1. The package name / namespace (the string you occupy on npm, PyPI, crates)
2. The domain and its DNS
3. Publish rights (the ability to push a fixed version to already-installed users)
4. Organization ownership (the owner seat on the GitHub org)

The nonprofit side is structurally identical, substituting: the legal entity, the public-fundraising qualification (or the sponsorship relationship), the donor list, and the continuity of the ledger.

Downstream trust in a package name or a domain is inherited. Nobody re-runs diligence when a maintainer changes hands, and neither registries nor browsers signal that it happened. So "handing it over" means transferring an already-established trust credential covering tens of thousands of downstream consumers, wholesale, to a new party.

This is why you must never simply let the domain expire [Solid]: expiry means the drop-catch market, where an attacker acquires it for nothing — worse than selling it. polyfill.io is the sale case: in February 2024 the domain was sold to Funnull, an entity with almost no industry record, and from June it injected code redirecting users to gambling sites. Worth correcting a widely repeated error: the original author, Andrew Betts, never owned that domain (the service was operated by the Financial Times); his statement afterwards was simply that modern browsers no longer need it and people should stop using it.

2. Where the bus factor actually sits

[Narrowed] A bus factor of ≤2 is the norm in popular projects — roughly 46–65%. Avelino et al. measured truck factor across 133 popular GitHub systems: TF=1 for 34%, TF=2 for 31%, so 65% at ≤2. Metabase re-ran the truckfactor library over the top 1,000 repos by stars (about 95% computable) and found "nearly half at ≤2, and only 10% at ≥6." The frequently quoted "74%" is wrong.

The Metabase re-run also produced a counterintuitive finding: star count is uncorrelated with bus factor. Being well known is not being safe.

[Judgment] But every one of those percentages measures "who wrote more than half the files." No public dataset has ever measured concentration of publish rights. A project whose GOVERNANCE.md lists five maintainers while exactly one holds npm publish still has a bus factor of 1 in the sense that matters. This is the most important reframing in this piece — and it has to be labeled an inference, because it rests on mechanism rather than data.

The metric also deserves cooling off. Avelino's own validity check cuts against high confidence: asked whether losing the identified TF authors would cause the project trouble, 39% agreed and 43% disagreed. Most maintainers do not accept that the metric is fatal.

3. The 2025–26 platform shift: "guard your key" is now obsolete advice

The most widely circulated succession advice is "never transfer the release signing key." That is largely void as of 2026 [Solid]:

• npm classic tokens were permanently revoked on 2025-12-09 and can no longer be created. The official path is trusted publishing (OIDC) — short-lived credentials that cannot be extracted or reused (requires npm CLI ≥11.5.1 / Node ≥22.14; supports GitHub Actions, GitLab CI, and CircleCI cloud runners — self-hosted runners are not supported).
• npm also shipped staged publishing: with stage-only permissions, CI publishes land in a staged state and a maintainer must review and approve each one with 2FA before it goes public.
• PyPI has an equivalent mechanism. When publishing via trusted publishing, provenance attestation is generated automatically — you do not need to add --provenance.

The control point therefore moved from "who holds the key" to "who can merge to the release branch, and who can approve that workflow."

The direct implication: .github/workflows/** must have its own CODEOWNERS entry with required review. Granting merge rights without locking the workflow silently grants publish rights too — anyone who can change one line of the release workflow can make your trusted publishing identity sign an artifact you never reviewed.

Also know what it does not solve [Narrowed]: trusted publishing defends against long-lived token theft — which is the highest-base-rate incident class (on 2025-09-08 chalk, debug and 16 other packages were poisoned, entry being a forged 2FA-reset email that harvested a username, password and a live TOTP; on 2025-09-14 the Shai-Hulud worm took down 500+ packages) — but it does not defend against a malicious successor. So the real first priority is switching 2FA on both the registry and the GitHub account from TOTP to a passkey or hardware key: WebAuthn is origin-bound, so the same phishing email fails. The order matters: enabling trusted publishing while your GitHub account remains phishable upgrades the attacker from "steal one token" to "own a standing publishing pipeline."

4. The real xz timeline: why time gates don't hold

"Set a six-month observation period plus five non-trivial PRs" is the most common succession-risk advice. Against the actual xz (CVE-2024-3094) timeline, that gate lets the attacker through on schedule [Solid]:

So the only genuine use of a numeric gate is to give you a line to decline with: "this is project policy, not about you." Say exactly that. Do not dress it up as a security control.

Two things actually work: release artifacts must be reproducibly built by CI from a git tag (eliminating the git-versus-tarball delta and forcing the injection surface back into publicly auditable territory), and no individual can release alone.

5. The 2026 variables: the section most likely to change your judgment

curl's full arc (the popular account covers only the first half)

Removing the money only kills arbitrage on fake reports. It does not solve the flood of real ones. The second wave isn't money-driven — credit, CVE attribution, a résumé, and security-tool vendors demonstrating capability are sufficient motivation. The harder part: burnout risk is higher after removing the bounty, because now every report is real and you have no legitimate ground to decline.

One counterintuitive piece of reassurance: nearly all of curl's recently discovered vulnerabilities are rated LOW or MEDIUM, and the most recent HIGH-severity CVE dates to October 2023. What AI finds at scale is the long tail of small defects, not catastrophic holes — a spike in CVE count does not mean the product is becoming more dangerous, so don't over-react to the number.

More lethal than slop: users no longer entering the community

[Solid] Record usage and a funnel at zero can coexist — and every metric you watch stays green.

• Tailwind Labs: 75 million monthly downloads, all-time-high usage — while documentation-site traffic fell 40% versus 2023 and revenue fell nearly 80% (the monetization entry point sat on the docs site). On 2026-01-06 it cut 75% of the engineering team (four people to one). The founder said the decline was too gradual to notice until he did the accounts over the holidays and found roughly six months of cash left.
• Stack Overflow: 3,862 questions site-wide in December 2025, −78% year over year (the 2014 peak was over 200,000 per month). The public Q&A layer has effectively gone to zero — meaning neither newcomers being taught in public by experienced people, nor new high-quality corpus.

The operational implications: decouple the revenue entry point from page views (monetize at the moment of use — CLI login, runtime license, hosted service, support contract — not "x% of people who visit the docs will buy"); decouple the recruitment entry point too (put the contribution path into error messages, CLI output and release notes rather than hoping someone browses to CONTRIBUTING.md); and put "docs-site unique visitors / new questions / first-time contributors" on a monthly dashboard with a decline alert — Tailwind's lesson is precisely that the curve is gradual enough that without a threshold you won't notice.

Gates belong at the identity layer, not the "was this written by AI" layer

[Solid] You cannot reliably detect AI-generated content, but you can reliably limit how much of your attention a stranger's account can consume. Three free switches shipped in 2026: repository-level PR access settings (2026-02-13, allowing PRs to be disabled entirely or restricted to collaborators), concurrent PR limits (2026-06, capping users without write access — PRs opened by Copilot and other AI agents count toward the quota, drafts do not, and long-standing contributors can be added to a bypass list), and collaborator-only issue creation (2026-06-29).

But the precondition has to be stated [Judgment]: this is net-positive only once inbound stranger PR/issue volume already exceeds your review capacity. Every example comes from projects at the scale of Homebrew or llama.cpp. A low-traffic project's real constraint is that nobody comes; closing the gate early cuts off the top of the contributor funnel, in direct conflict with preventing the founder-leaves-project-dies outcome. Note too that collaborator-only issue creation blocks more than it sounds like — it takes real users' bug reports with it.

6. Trust: specific to the nonprofit side, structurally identical on the open-source side

[Solid] Mixing project funds with personal finances means, mechanically, that you can only answer challenges with your private life. Once the money is in your personal wallet, "how many properties do you own" becomes a legitimate question and you have no institutional answer — because your bank statement contains your private life, you can only refuse to reconcile, and refusing confirms the accusation.

The Luo Er case in China (November 2016) is the cleanest specimen of this mechanism: the platform ultimately returned a total of 2,525,808.99 yuan in tips (another accounting gives 2,626,919.78) to the original payers before midnight on December 3. He was not penalized administratively and was not found to have committed fraud — yet the civil affairs authority, the legislative affairs commission, the platform and public opinion all characterized the event differently. The lesson is not merely "lawful ≠ defensible," but something harder: once the money is in your personal wallet, you no longer control the characterization.

[Narrowed] The fuel for a collapse of trust is usually being unable to answer about one specific transaction — but add this: a line-item ledger can only prove nothing was stolen. It cannot prove what should have been spent was spent.

• American Red Cross, Haiti: nearly $488M raised and a claim of providing homes for more than 130,000 people, against six permanent homes actually built in the whole country. The ignition was that output gap; opacity was the fuel that kept it burning for five years, and a spokesperson eventually stating that the organization would no longer respond to the reporters was the extreme form of the failure. Internal documents indicated the organization itself could not say what each project had spent, because of an accounting system described as complex but inaccurate.
• The Wu Huayan case in China: the opposite shape — the books were accurate to the cent (1,004,977.28 yuan), and the failure was that the earmarked funds had no disbursement schedule: the patient had received only 20,000 yuan by the time she died on 2020-01-13, with the balance sitting in the organization's account.

So a line-item ledger has to be paired with "the due date for undisbursed funds, the disbursement conditions, and what happens if it slips." And the ledger itself must be a byproduct of wherever the money actually lives [Judgment] — never a hand-maintained page you have to remember to update. A ledger that stopped updating eleven months ago is worse than no ledger: it proves you once had the discipline and lost it.

[Solid] Don't spend limited money on a formal audit first. ACFE's Occupational Fraud 2024 (1,921 cases, roughly $3.1B in losses): 43% of frauds are detected by tips and only 3% by external audit — while 84% of victim organizations already had an external audit. Audit is a compliance credential for regulators and large donors, not a detector; the detector is somebody being able to speak. The one-person equivalent: give a trusted third party outside the project read-only access and state publicly who holds it (the statement itself is the deterrent), plus an anonymous challenge address, plus a surprise reconciliation each quarter.

[Judgment] Don't publish an overhead ratio; publish "what a year costs to stay alive" and "what I pay myself." Ratios can be recomputed, so they are permanently arguable; a budget and a salary are statements of fact and are not. Babel put maintainer salaries directly on a public blog (Henry Zhu's full-time baseline at $11,000/month) — the controversy happened once, and nobody has used it since. Not publishing your own pay is the real landmine: someone will eventually back it out from "income minus known expenses," and at that point any number looks like embezzlement, because you concealed it.

But don't treat "publishing the shortfall" as a fundraising channel either: the Babel post that disclosed a $333,000 gap simultaneously cut three maintainers to $6,000/month; as measured in July 2026, its Open Collective annual income is about $285k — up roughly 70% over five years, and still below the line stated back then. Publishing a shortfall is honesty, not a channel.

7. Shutting down: archiving doesn't send anyone away

[Solid, measured] From the npm downloads API for 2026-07-18 to 24: request at 14,985,210 per week — it marked all 126 versions deprecated back in 2020, and six years later this is where it stands; moment at 36,228,334; core-js at 65,873,924.

Your exit has to assume users will never read anything you publish — because there is no human in the decision loop at all. At that volume, the overwhelming majority of downloads are CI reinstalls and transitive pulls from other unmaintained packages. So the exit has to be machine-readable. The consumer is a machine.

Three actions serving three different purposes; do not treat them as equivalent:

• Stop inbound → GitHub archive. This is the only effective lever: issues, PRs, wiki and releases all become read-only, so you physically cannot receive new issues; the repo can still be forked and starred; and it can be un-archived, so it is reversible rather than destructive.
• Signal the machines → the registry layer, where reach differs enormously. npm's npm deprecate <pkg>@"*" is the only one that genuinely reaches the command line (npm 11.9.0 warns on both direct and transitive dependencies — but bun 1.3.14 prints nothing at all). PyPI's Archived status, shipped 2025-01-30, is only a web banner: it does not block installation and pip install says nothing, putting it at exactly the visibility level of "a line in the README." And crates.io's yank means "this version is broken," not "this is unmaintained" — yanking everything makes cargo add fail outright for new users.
• Don't expect migration. There is exactly one path to migration: hand the package to a successor, or name the successor in the deprecation message itself.

[Solid] Copy two templates for the exit notice. Atom supplies the date: announced 2022-06-08, committing to archive on 2022-12-15, with the announcement itemizing what will break (package management stops working, no security updates, collaboration service ends) and what still works (prebuilt binaries on the releases page remain downloadable). One caveat: it actually archived on 2023-03-03, about 2.5 months late — the date is a floor, and slippage needs a public follow-up note so the buffer period doesn't become a new source of uncertainty. Moment supplies the falsifiable commitment boundary: one characterization ("not dead, but it is indeed done") plus two things it will do (critical security concerns, following time-zone data updates) and six it will not (no new features, no API change, no bundle-size work, no v3, no fixing long-standing known bugs, no accepting changes without adequate evidence), closing with five named alternatives.

There is one more universal lesson from Atom: on 2023-01-30 its code-signing certificate was preventively revoked after unauthorized access, and versions 1.63.0/1.63.1 of the already-archived project stopped running on 2023-02-02. Archiving does not terminate any asset that can still publish in your name or is still injecting runtime content into users' machines — on the way out you must go through the list and mark each item "keep renewing" or "kill deliberately": domains, registry tokens and 2FA recovery, the GitHub account, developer accounts, OTA update endpoints, signing and push certificates.

Finally, write one sentence into the notice in advance: "The package name and publish rights will not be transferred; you are welcome to fork under a new name." Nobody comes asking after a large project archives, but an independent developer will be asked within a day — and handing publish rights to an enthusiastic stranger is exactly how both event-stream (2018) and xz (2024) opened.

Primary sources: Avelino et al., “A Novel Approach for Estimating Truck Factors” (arXiv:1604.06766) and Metabase’s 2022-11-14 re-run; Russ Cox’s xz timeline at research.swtch.com/xz-timeline; the official npm trusted publishing / staged publishing documentation and GitHub’s September 2025 npm supply-chain hardening plan; Daniel Stenberg’s six first-hand blog posts from July 2025 through June 2026 and curl.se’s current vulnerability policy; GitHub’s three repository-settings changelogs from February and June 2026; Tailwind Labs’ founder’s public statements and Stack Overflow’s official site data; ACFE, “Occupational Fraud 2024”; the ProPublica/NPR investigation of the Red Cross in Haiti; the official Atom and Moment wind-down announcements; and the npm downloads API measured directly (2026-07-18 to 24). Every load-bearing conclusion was independently re-verified; what appears here is the corrected version, with grades and staleness risk marked line by line.