What Happens to Your GitHub, npm Packages, and Open Source Projects When You Die

The Bus Factor of Half the Internet Is One

In November 2018, the maintainer of event-stream — an npm package downloaded over a million times a week and depended on by everyone from PayPal to Microsoft — handed maintainer rights to a stranger who emailed asking for them. The original author had stopped using the package. He didn't have time. The new maintainer seemed eager. Two weeks later, malicious code targeting Bitcoin wallet users was discovered embedded in a transitive dependency of nearly the entire JavaScript ecosystem.

The package wasn't unmaintained because the author died. He just got tired. But the failure mode is identical to the death case, and it exposed something most software supply-chain conversations still avoid: enormous swathes of the open source code your business depends on are maintained by exactly one person, and there is no plan for what happens to it when that person stops showing up.

Now multiply that across the millions of packages on npm, the public repositories on GitHub, the widely-used Python libraries, the Cargo crates, the Maven artifacts, the homebrew taps, and the personal SaaS projects with a handful of paying customers — and you start to see the scale. When a maintainer dies, what actually happens?

The honest answer: usually nothing good.

What the Platforms Actually Do

GitHub

GitHub has no formal account memorialization or transfer process specific to death. There is a next-of-kin policy that lets a verified family member request that a deceased user's account be either deleted, archived (made read-only), or — in rare cases — transferred to a designated successor. In practice, the process requires a death certificate, proof of relationship, and weeks of correspondence with GitHub Support.

What you do not get, by default:

Continued maintenance authority over your repos
Transfer of ownership of organizations you own
Access to your private repos for your family
Continued GitHub Sponsors revenue

If you maintain critical infrastructure, "archive the account" is a polite way of saying "the project is dead now."

npm

npm's policy is that account ownership cannot be inherited. They will, on request, transfer specific packages to designated successors — but only if the original author explicitly named them as collaborators with publish rights or as additional maintainers before death. If you're the sole publisher and you die, your packages enter limbo. They keep working. Nobody can publish updates. Security patches don't ship. The same is true for PyPI, RubyGems, and Crates.io.

GitHub Sponsors, Patreon, Open Collective

Revenue streams stop. Sponsors keep being charged for a few cycles depending on the platform until someone notices. There is no automatic distribution of funds to a beneficiary. Open Collective is somewhat better — it's organizational rather than personal — but only if your project actually uses it.

The Real Cases

colors.js and faker.js (2022). Marak Squires, the maintainer of two packages with millions of weekly downloads combined, deliberately sabotaged both as protest against unpaid open source labor. He wasn't dead — but the maintainer-as-single-point-of-failure problem was identical. Within hours, applications across the industry were printing infinite "LIBERTY LIBERTY LIBERTY" loops.

core-js. Denis Pushkarev maintains core-js, downloaded tens of millions of times a week. He has publicly described the difficulty of sustaining the project. If he stops — for any reason — it is unclear who would or could take over.

The maintainer of the cryptographic library that signs your bootloader. The author of the Make replacement your CI uses. The single human who maintains the Postgres extension that handles your encryption. There are no good public lists of these people. That's part of the problem.

What This Means for the Rest of Us

If you write open source code that other people use — even casually — you have inherited a small responsibility. It is uncomfortable to think about, and most of us don't.

You don't owe your users perpetual support. You do owe them an answer to: "what happens to this project if you stop?"

For most maintainers, the answer should be one of:

Designated successor. Add a co-maintainer who has publish rights. Document who they are and how they'll be notified.
Graceful deprecation. Make it possible for the project to be archived without breaking the world. Document the migration path to alternatives.
Organizational handoff. Move the project under a foundation, working group, or trusted organization (Apache, OpenJS, etc.) before you need to.

Pick one and write it down somewhere your family can find it.

A Maintainer's Estate Checklist

Concretely, here's what a maintainer's digital estate plan should cover:

Account access:

GitHub login + 2FA backup codes
npm/PyPI/RubyGems/Crates.io credentials
Personal access tokens still in use anywhere
SSH keys used for signing or deployment
GPG signing keys (and their passphrases)

Funding:

GitHub Sponsors / Patreon / Open Collective access
Bank account where revenue lands
Any grant agreements with conditions tied to maintainership

Infrastructure:

Domain registrar credentials for project domains
Hosting (if you run docs sites, demos, package mirrors)
DNS provider
Any CI/CD secrets stored as personal credentials rather than org credentials

Identity:

The list of projects you actually maintain (most maintainers don't have a complete list)
Co-maintainers, contributors, and people who've expressed interest in succession
Your preferred outcome for each project (continue, archive, transfer)

A succession letter. A short document explaining: "If I'm gone, here's what to do with each project, in priority order, and here's who to contact."

That last one is the hardest and most important. It doesn't have to be long. It just has to exist.

The Single-Maintainer Problem Isn't Yours to Fix Alone

The structural fact that critical infrastructure rests on individual unpaid hobbyists is bigger than any one maintainer. Foundations exist for a reason. Funding mechanisms are improving slowly. Companies are getting better — slowly — at sponsoring the projects they depend on.

But while the structure improves, you can do the small, personal version of the right thing: leave a paper trail. Make sure that whoever picks up after you knows the keys, the conventions, the people, and the path forward.

A zero-knowledge encrypted deadman switch is a natural fit for this. Your credentials, signing keys, and succession letter sit encrypted, untouchable by the service. If you stop checking in — for any reason — they deliver to the people you've designated. Co-maintainer. Spouse. The foundation you trust.

The keys in your head don't have to die with you. The packages don't have to silently rot. The thing you spent years building doesn't have to become someone's social engineering target.

You just have to write it down somewhere it'll actually be delivered.

Killswitch stores your maintainer credentials, signing keys, and project succession plans with zero-knowledge encryption. When you stop checking in, the right people inherit the right access — automatically, on your terms. Get started today