Six years without a commit, 1,821 crates still depend on it

At a company I worked with, there was a man called Ahmed who understood the billing reconciliation job. Not "was familiar with it" — understood it at it’s core, in the sense that when it failed at 2am he knew from the error message which of four upstream systems had an issue or which input we received had a malformed date.

Ahmed left. He gave two months' notice, which was generous from. In those two months we wrote documentation, recorded knowledge sharing sessions and did handovers. Nine weeks after he left, the services and jobs failed in a way nobody could explain, and it took days to fix.

Nothing had gone wrong with the handover. The handover was fine. What we had transferred was the description of the system, and what Ahmed had was something else.

The same event, in public

The secretspec team announced on 15 August that they are forking dotenvy into dotenv-ng. The stated reasons are the usual ones — stalled maintenance, a backlog that stopped moving, a dependency too load-bearing to leave in that state.

What makes it worth more than a shrug is that dotenvy is itself a fork. It exists because dotenv, the original crate, went quiet. So I pulled the actual commit history for both.

The original dotenv is not on that chart because there would be nothing to draw. Its last commit was 26 June 2020 — six years ago, with fifty issues and pull requests still open. It is not deprecated, not archived, and still sitting in dependency trees today.

dotenvy's own shape is the more interesting one. Seventy-six commits in the second half of 2024, and then the cliff. Between February 2025 and March 2026 the project produced exactly two commits, and both were edits to a README clarifying that the main branch was unreleased.

The part that is still load-bearing

Here is what makes all of this more than archaeology. I pulled the dependent counts too.

Read the left-hand column again. dotenv has had no commit since June 2020, and 1,821 crates still list it as a dependency. It was downloaded 7.3 million times in the last ninety days. Nothing about that is anomalous or alarming to anyone involved, because nothing is broken — that is precisely the condition being described.

And dotenvy's last published release was March 2023. Which means the seventy-six commits from late 2024 never shipped to crates.io at all. That is what those two README edits were about: someone kept having to explain that the working code was on a branch nobody could install.

Nobody chooses to depend on an unmaintained library. It happens the other way around. You adopt something healthy and actively developed — dotenvy demonstrably was, in 2024 — and years later the maintenance quietly stops while your dependency graph sits exactly where you left it. The risk arrives with no event on your side at all: no decision, no migration, no warning email.

Then the fork announcement did what the backlog could not

Here is the part I did not expect to find.

The fork was announced on 15 August. At 18:18 on 17 August, dotenvy merged a community pull request. By 18:57 a behaviour change and its changelog entry were in. A second pull request was merged at 01:50 the following morning.

A project that had managed two commits in the previous eighteen months produced four in about eight hours.

Forty-six open issues and pull requests could not move it in two years. The credible threat of being routed around moved it in an evening.

I want to be careful here: that is timing, not proof of cause. I cannot read the maintainer's mind, and it may be coincidence. But the shape is familiar to anyone who has watched an organisation rediscover urgency the week a competitor ships.

It also reframes what a fork is. We talk about forking as a failure state — the community fragmenting, effort duplicated. Sometimes it is the only remaining message that gets through, because it is the only one that costs the recipient something.

Why the handover never quite works

Back to Ahmed, because he and the quiet maintainer are the same problem wearing different clothes.

What they hold is not documentation. It is a compressed history of failures. Ahmed knew that dates from the Oracle system arrive in a different timezone during the last week of the fiscal year, because he had been burned by it in 2019, at 3am, and had spent six hours on it. That fact is not written anywhere, and it would not survive being written — as a line in a runbook it reads as trivia, and the reader has no slot to put it in.

xkcd drew this in 2020: the entire modern digital infrastructure, and one thin block at the bottom holding it up, thanklessly maintained since 2003 by some random person in Nebraska. It got a laugh because it is a load-bearing joke.

So a maintainer going quiet is not a licensing problem or a governance problem. It is a knowledge problem, and it has the same shape inside your company as it has on GitHub:

• The knowledge is tacit — held as pattern recognition, not as prose

• It is concentrated — one person, sometimes two

• It is invisible while it works — nothing on any dashboard turns red as it drains away

• It is only priced at the moment it is gone, which is the worst possible time to discover the price

What a team can actually do

Auditing every transitive dependency is not realistic, and pretending otherwise produces a spreadsheet that nobody updates after the first quarter.

What is realistic is naming the load-bearing ones — usually somewhere between five and fifteen, and every senior engineer can list them from memory — and checking, for each, when the last commit landed. That is one afternoon and a browser tab. Had anyone done it for dotenv in 2021, the answer would have been sitting there in plain sight.

Then do exactly the same exercise on your own people. Not "who owns this system" on the org chart, which is a fiction maintained for the org chart's benefit. Ask instead: if this person were unavailable for a month, what would we be unable to do?

You will not like the answer. You are not supposed to. But the answer is what you actually have, as opposed to what your documentation claims you have.

And then the boring part

The fix is not a wiki page. It is a second person, doing the work, badly at first, while the first person is still there to correct them.

That is expensive. It is visibly inefficient — you have two people on a job that one person can do faster and better, and someone will point that out in a planning meeting. It is also the only thing that transfers the compressed history, because the only way to acquire pattern recognition is to see the patterns fail.

We eventually rebuilt the billing knowledge. It took roughly seven months and two people, and the second person is now the one who gets called at 2am.

We should have started three years earlier, when Ahmed was still bored on Thursdays.

The dotenv-ng announcement is here, and the histories above are public — dotenvy, dotenv. Go and count your own Ahmeds. Then check whether anyone is quietly preparing to fork you.