Open Source Projects Should Ship Without Their Maintainers
I like maintainers. I’ve spent years reading their mailing lists, filing their bugs and depending on code they wrote at night for nothing, and I run a few small projects myself. So I’m the last person who wants to argue that the human at the centre of an open source project matters less than we say. My claim is narrower than that. It’s about what happens on the days that person isn’t there.
A small open source project should be built so it keeps shipping when its maintainer is busy, burned out or gone.
Not eventually. Not once it gets popular. From the first tagged release.
In practice that means a short list of dull things. Tests and fuzzing run in CI on every push. A tag triggers the build, and the build signs its artifacts and writes the changelog from the commit history. A dependency bot opens the update pull requests so nobody has to remember. The build is reproducible, so anyone can check that the tarball matches the source. The scope stays small, the dependencies stay boring, and the licence file says plainly what people may do with the code. None of this is new. Most of it costs an afternoon to set up.
The famous failures all had one person holding the keys
Take the test case everyone in security now knows by heart. In June 2022 Lasse Collin, who had maintained XZ Utils for years, answered a pushy account called Jigar Kumar on the xz-devel list. He wrote that his ability to care had been “fairly limited mostly due to longterm mental health issues,” reminded everyone that “this is an unpaid hobby project,” and mentioned he’d been working off-list with a contributor named Jia Tan who might take on a bigger role. Jia Tan did. By early 2024 releases 5.6.0 and 5.6.1 carried a backdoor aimed at SSH servers, rated 10.0 under CVE-2024-3094. Andres Freund, a Microsoft engineer, caught it in March 2024 because sshd on a Debian development box had started eating CPU and throwing Valgrind errors.
So ask the plain question. Where did the backdoor live? The obfuscated payload sat in binary test files, and the script that switched it on, a modified build-to-host.m4, was in the release tarballs the maintainer uploaded by hand and absent from the git repository. A release built by CI from a tagged commit, with a reproducible build anyone could rerun, would have produced a tarball that didn’t match. The gap between “what’s in git” and “what we ship” was the attack surface. Hand-rolled releases created that gap.
Left-pad is the cheaper version of the same lesson. On March 22, 2016, after npm handed the kik package name to Kik Interactive, Azer Koçulu unpublished all 273 of his modules. One of them was left-pad, 11 lines of string padding. Babel and React builds broke. npm restored the package from a backup about two hours later and changed its rules so a package more than 24 hours old with dependents can’t simply be pulled. Who fixed it? The registry, by taking the decision away from one person. The code was fine. The single point of control was the bug.
Then there’s core-js. In February 2023 Denis Pushkarev published a long post about the polyfill library that sits under a large share of the web’s most visited sites. He’d been putting in more hours than a full-time job, donations that had run to about $1,700 a month were heading towards $400 as sanctions cut off payment platforms in Russia, and he said that without proper funding the project might go commercial or wither. Ask who depends on core-js and you get a list of very large companies. Ask who pays for it and you get one man’s monthly budget.
The security community has already answered this, with automation
Here I’ll use the other side’s own witnesses, because the people who say “just fund the maintainer” are mostly right about funding and mostly quiet about release engineering.
OpenSSL is the classic case. The flaw behind Heartbleed, a missing bounds check in the TLS heartbeat extension, was committed on the last day of 2011, shipped in OpenSSL 1.0.1 in March 2012 and sat there until April 2014. In the year before, the OpenSSL Software Foundation had taken in about $2,000 in donations and employed one full-time developer. Steve Marquess, its fundraiser, wrote that there should be at least half a dozen. The Linux Foundation’s answer, the Core Infrastructure Initiative, came within weeks, backed by Google, Amazon, Facebook, IBM, Intel, Cisco and Dell. Money helped. It also paid for audits and testing, which is the point: the fix for one overloaded human was more process around the code, so the next missing bounds check would meet a fuzzer before it met a server.
Look at what the security world built after xz. Sigstore lets a CI job sign an artifact with a short-lived certificate tied to its own identity, and logs the signature in a public transparency log. npm added package provenance in April 2023: publish from GitHub Actions with --provenance and consumers can check which repository, commit and build steps produced the package, recorded in the SLSA provenance format. PyPI made Sigstore-based attestations generally available on November 14, 2024, switched on by default for projects that use Trusted Publishing and the standard publish action. Every one of these tools assumes the release is made by a pipeline and verified by a stranger. None of them assumes a trusted person with a laptop and a signing key.
That’s the design I’m asking small projects to adopt on day one, before anyone’s paying attention. When a release comes from CI, the maintainer’s absence stops being an emergency. When it comes from a laptop, the maintainer’s absence is the release schedule.
I’ve watched my own small projects keep putting out tagged, signed builds through weeks when I didn’t open the repository. Nobody noticed. That’s the whole idea.
Automation won’t save a project that’s too big for its people
Now the part where I don’t get to win.
Ingress NGINX is the counterexample I take most seriously. In November 2025 Kubernetes SIG Network and the Security Response Committee announced its retirement, and best-effort maintenance ended in March 2026. A January 2026 statement from the Kubernetes Steering and Security Response committees says the controller was critical infrastructure for about half of cloud native environments, and the retirement notice says that for years it had “only one or two people doing development work, on their own time, after work hours and on weekends.” It had CI. It had releases. It also had features like the snippets annotations, which let users inject arbitrary NGINX configuration, and the maintainers’ verdict was blunt: “Yesterday’s flexibility has become today’s insurmountable technical debt.” Tabitha Sable, a co-chair of Kubernetes SIG Security, called it a never-ending CVE piñata. The planned replacement, InGate, never matured and was retired too.
So I don’t claim pipelines replace people. A pipeline ships what’s in the repository, and if the repository’s scope has outgrown its maintainers, you just ship the debt faster. That’s why small scope and boring dependencies are on my list and not decorations on it. The most automated release process in the world can’t keep a project alive whose attack surface needs ten full-time people and has two volunteers.
I also reject the comfortable reading of the funding cases. Paying Lasse Collin in 2022 might have spared him the sock puppets. It wouldn’t have closed the gap between git and the tarball. Paying the OpenSSL team in 2011 would have been decent, and the bug still needed fuzzing to find it. GitHub Sponsors passing $100 million is good news, and I’d like to see it double. Funding buys time. Release engineering decides what that time is spent on.
Maintainers matter. They just shouldn’t be the release process.