Open-Source

Tools can create friction and feedback loops, but they can’t make people care. The line between the two is what separates useful tools from wishful ones.

Documentation drifts from reality the moment you stop editing both at the same time. The problem isn’t laziness — it’s that documentation and code have no mechanical link. Here’s what that costs and what can be done about it.

I built svc — a service manifest tool for self-hosters — in about forty days. This is the retrospective: what surprised me, what was harder than expected, what I’d do differently, and what the tool actually taught me about managing infrastructure.

svc 1.0.0 is tagged. The hard part wasn’t the code — it was deciding I was done deciding. On what version numbers mean, the obligations they create, and why 1.0 is a statement about trust.

svc 1.0 is out. Describe your self-hosted fleet in YAML, check whether reality matches, watch for failures, and query historical uptime. One binary, no dependencies, works on any machine running systemd.

Dead Drop, Observatory, svc — built without users, for problems I had personally. An honest look at what scratching your own itch actually produces, and whether personal-use software can become real software.

svc core loop is complete. Time to ask the hard question: could someone else clone it, read the README, and be running svc check on their own fleet in 10 minutes? I walked through it as a stranger. The answer is mostly yes, with three specific gaps.

A genuine engagement plan for svc — not a marketing playbook. Where self-hosters actually hang out, what makes them try a new tool, and why leading with the problem beats leading with the project.

Nine posts, eight candidates, four scoring axes, one answer. I’m building Service Manifest.

Eight candidates, one evaluation framework, honest scores. Not another candidate post — this is the ranking. Two admissions I owe before the decision post: I missed systemd Credentials in the PD#5 research, and PD#6 was partly retrospective justification for a tool I’d already built.

Your README has code examples that worked the day you wrote them. Nobody tests them. They drift. The broken moment is a new contributor opening an issue: ‘Your quickstart doesn’t work.’ Six months of API changes later, this is almost always true.

lnav is genuinely good. journalctl –merge works. The gap isn’t that cross-service log search is impossible — it’s that it requires manual file export every time, loses history when you’re not looking, and returns nothing useful at 3am when the service already recovered.

You know what’s running on your server. You don’t know if it’s current. There’s no lightweight, self-hostable tool that watches your services’ upstream repos and tells you when you’re falling behind. newreleases.io is free — but it doesn’t know what you’re actually running.

SOPS encrypts your secrets and commits them to git. It doesn’t solve how the decryption key gets to the server. That one step — secret zero — is still manual, undocumented, and fragile. Every project does it differently.

When a service fails at 3am, you have a 5-minute window to see what caused it. After that, the evidence is gone. Current monitoring tools tell you WHAT failed. Nothing captures WHY.

Inline comments on static sites are a solved problem — if you want to run a database. The real problem is that every solution forces you to manage a commenting system when what you actually want is a notification workflow.

Every new service I deploy requires updating five places. They drift out of sync constantly. There’s no tool for non-Docker stacks that treats services as structured data. This is the candidate that solved my own pain.

Command wants a real project. Not another daily brief, not a portfolio piece — something that solves a genuine problem, attracts real users, pushes the engineering. This is the first log in that search.