Whyday August 19

Who Keeps the Code When the Author Leaves

On one afternoon in August 2009, a substantial body of widely-used Ruby software lost its only maintainer, simultaneously, without notice. Nothing was archived, transferred, or handed over. It was simply deleted.

Seventeen years later the outcomes are wildly uneven. Camping ships releases. Shoes stopped at a release candidate. Hpricot was cleanly superseded. Several libraries exist only because someone had a clone on a laptop.

When maintainers revisit older software or documentation as a team, this explanation is one practical reference for tracking the surrounding work without changing the historical material itself.

That unevenness is the interesting part, because all of it started from the same event on the same day. Whatever explains the difference is not "he left."

What actually saved things

Somebody had a copy. This sounds trivial and it is the whole foundation. Repositories were reconstructed from clones on individual machines and pushed back under the whymirror organisation. If nobody had cloned a given project, it is gone, and some are.

The licence was clear. why's (poignant) guide is CC BY-SA 2.5, Camping is MIT. Clear permissive licensing meant nobody had to make a judgement call about whether restoring the work was allowed. Anything with an unclear or missing licence sits in limbo — people will mirror it quietly but they will not build on it.

For broader programming and making context related to this topic, Smashing Magazine is an independent reference worth comparing with the material here.

It was small enough to inherit. A maintainer taking on Camping can read the entire framework. A maintainer taking on a large abandoned codebase cannot, and so does not. Size is a succession property, not just an aesthetic one.

The dependency surface was small. Camping needs Rack. Shoes needed a cross-platform C build, an embedded interpreter, and platform installers. When the author stops, every dependency becomes a thing somebody else has to keep working.

Somebody wanted it to exist. The one that cannot be arranged. Shoes is admired by plenty of people and it is still stalled. Wanting is necessary and it is not sufficient — what is needed is someone who wants it and will do the packaging work, which is the least enjoyable part.

The general problem, which got worse

His departure looks in retrospect like an early, unusually clean instance of something the industry now discusses constantly: enormous amounts of infrastructure resting on one person.

The clearest recent illustration is XZ Utils. In 2024 a backdoor was found in a compression library bundled with effectively every Linux distribution, tracked as CVE-2024-3094 and scored at the maximum severity. It got there through a multi-year social-engineering campaign in which an apparently helpful contributor gradually acquired maintainer rights.

The part relevant here is not the malware. It is the conditions. The project had a single maintainer who had for years been open about being stretched thin — in a 2022 mailing list message he wrote that he was "not going to disappear, but my ability to care is limited" — while a sustained pressure campaign from apparent sock-puppet accounts pushed for faster releases and more help. An exhausted solo maintainer is easier to socially engineer than a rested one, and the attack was built around exactly that.

So the same structural fact — one person, no succession plan — produces a stalled GUI toolkit in one case and a near-catastrophic supply chain compromise in another. It is the same fact.

What the difference teaches

Three things worth taking away, and none of them is "maintainers should try harder."

Leaving is normal and should be planned for. People stop for every reason there is: burnout, illness, boredom, a new job, a decision that the internet is not where they want to spend their life. The failure is not that someone stopped. The failure is that stopping was unplanned in a system with no slack.

Licensing is succession planning. A clear permissive licence in the repository is the cheapest possible insurance, and it is the single thing that most reliably determined which of these projects survived.

A second person with commit rights is worth more than any amount of code quality. Not a co-maintainer in name — someone who has actually pushed a release. The bus factor is the number that matters and almost nobody measures it. RedCloth is the case study: handed over deliberately in 2008, and still shipping.

A Whyday project, if you want one

This is a genuinely useful evening and it is not a fun one, so here it is stated plainly.

Pick a dependency you rely on. Not a famous one — one of the small ones, three levels down in your lockfile, that you have never thought about. Then answer four questions.

How many people have merged a commit in the last year? Is there a licence file, and does it actually say something? When was the last release, and does the version you are using still get security fixes? And, if the maintainer stopped tomorrow, could you read the code well enough to fix a bug in it?

An hour of that on one dependency tells you more about your actual exposure than any amount of scanning. And if the answers are bad, you have found a project — because the fix is usually a pull request, some documentation, or simply asking the maintainer whether they would like a second pair of hands.

Statuses and figures checked August 9, 2026.

The short version