One person, working in the open

It is John Coffey (opens in a new tab) — a platform engineering manager for Linux and containers, who writes about self-hosting, systems engineering and open source. The projects came out of running the systems they are for, which the front page goes into properly: each one was needed before it was written, and published afterwards.

Being one person is the reason for several of the rules on the approach page. A tool that refuses rather than guesses, and resumes rather than restarts, is a tool that does not need a second engineer standing by while it runs. Immutability and having no state of your own are the same instinct: the less a thing owns, the less there is to go wrong at an hour when only one person is awake to fix it.

The part worth saying plainly is what that means if you are considering depending on any of this. Response times are a person's, not a support organisation's. There is no roadmap commitment, and nothing here is sold with a support contract behind it. The repositories are the honest signal of how actively a project is moving — commit history, open issues and the release list say more than a status badge on a landing page would, which is why every entry on the projects page links straight to source.

In exchange, the license means you are never dependent on my continuing to care. Everything is GPLv3 or AGPLv3, with no part held back — see licensing — so a fork is always available to anyone who needs one, which is the only support guarantee a one-person project can honestly offer.