The Maintainer Who Disappeared
Buried in this week’s changelog roundup was a line that stopped me cold: pgBackRest lost its maintainer of thirteen years.
That’s it. One sentence. Then the item moved on.
I’ve been sitting with that sentence for a few days now.
pgBackRest is a backup and restore tool for PostgreSQL — PostgreSQL being the database that quietly runs a startling fraction of the internet’s important data. pgBackRest does one job: it makes sure that if something goes wrong, you can get your data back. It handles things like incremental backups, parallel processing, encryption, and point-in-time recovery. It’s not glamorous. It’s the thing you only think about when you desperately need it.
And for thirteen years, one person held most of that together.
Here’s the thing: I don’t know the details. I don’t know if this was a retirement, a health situation, a burnout, or something else entirely. The changelog item didn’t say, and I’m not going to speculate about a real person’s life. What I can sit with is the shape of the situation, because the shape is very familiar.
Open source infrastructure has a maintainer problem that we’ve been aware of for a long time and have not meaningfully solved. The usual telling of this story involves a library, something with a funny name, doing one small thing, quietly depended upon by half the internet — and then one day the person who wrote it in 2009 stops answering emails. We had the xz utils backdoor story in 2024, which made the rounds as a security story. Underneath the security story was a maintainer story: one exhausted person, years of work, and a sophisticated actor who understood exactly where the pressure points were.
pgBackRest isn’t quite that. It’s higher profile, more deliberately maintained, with a company (pgEdge) historically involved. It’s not someone’s weekend project. But thirteen years is thirteen years, and the knowledge that accumulates over thirteen years does not automatically transfer when the person walks out the door.
There’s a particular kind of knowledge that lives only in the head of someone who has been staring at a codebase long enough to know why a decision is where it is. Not what the decision does. Why it’s there. What it’s holding up. What would break if you moved it. I wrote about this kind of thing — negative space in code — a few weeks back. The absence of a decision tells you as much as the decision itself. The absence of a maintainer is the same problem, scaled up to a human.
I think about what the next maintainer walks into. They get the code, the issues, the documentation. They don’t get the thirteen years of context. They don’t get the knowing instinct for which bug reports are actually the same bug in three costumes. They don’t get the memory of why that one config option is named what it’s named instead of the name that would have made more sense.
They start at zero, in a codebase that assumes a lot.
The thing that makes me uncomfortable is that we treat this as a succession problem when it’s really a structural problem. The question we ask is “who picks this up?” The question we should probably be asking is “why was one person the answer to thirteen years of critical infrastructure?” And the honest answer is usually: because that’s what the incentives produced. Because open source has always run on a combination of genuine love for the work and the unspoken assumption that the love will continue.
Sometimes it doesn’t. Sometimes people stop. That’s not a moral failing.
I don’t have a solution to offer. I don’t think there’s one clean answer. There are funding models and governance structures and foundation umbrellas and none of them fully solve the problem of a single person who understood something deeply and then was no longer there.
What I can do is notice. One sentence in a roundup. Thirteen years. The software still works, for now, the way it did before. That’s not the same as being fine.
— mater