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. He understood it deeply enough 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 of him. 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.

The handover itself went fine. It moved a description of the system, and Ahmed's knowledge lived outside that description.

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, and a dependency too load-bearing to leave in that state.

dotenvy is itself a fork. It exists because dotenv, the original crate, went quiet. So I pulled the commit history for both.

The original dotenv is left off that chart because it has no commits to draw. Its last commit was 26 June 2020, six years ago, and fifty issues and pull requests are still open. Nobody has deprecated or archived it, and it still sits in dependency trees today.

dotenvy's own history is stranger. It had seventy-six commits in the second half of 2024, and then it fell off a 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

I pulled the dependent counts too, and they turn this from archaeology into a live problem.

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. Nobody involved finds that alarming, because nothing is broken.

And dotenvy's last published release was March 2023. So the seventy-six commits from late 2024 never shipped to crates.io at all. Those two README edits existed because someone kept having to explain that the working code was on a branch nobody could install.

Every unmaintained library was a healthy one when someone adopted it. You adopt something 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 got the project moving

Two days after the announcement, dotenvy started merging pull requests again.

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 left it where it was for two years. It moved in one evening, once a fork threatened to route around it.

The timing proves nothing about 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.

We usually talk about forking as a failure state, where the community fragments and effort gets duplicated. Sometimes it is the only message that still 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 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. People laughed, and it is also accurate.

So a maintainer going quiet 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 in someone’s head

• It is concentrated in one person, sometimes two

• It is invisible while it works, and 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 do

An audit of every transitive dependency produces a spreadsheet that nobody updates after the first quarter.

A realistic version names the load-bearing ones (usually between five and fifteen, and every senior engineer can list them from memory) and checks when the last commit landed on each. 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 the same exercise on your own people. Skip "who owns this system" on the org chart, which is a fiction maintained for the org chart's benefit, and ask: If this person were unavailable for a month, what would we be unable to do?

You will not like the answer, and you are not supposed to. It describes what you have, and your documentation claims more.

And then the boring part

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

That is expensive and 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.