EssayBy Taiki Noda / 野田大貴05 / 204 min read日本語版 →

Keeping My Solo OSS From Dying Quietly: Notes After gpdf v1.0

An indie post listed the dumb ways open-source projects die. Here are three survival tactics I run on gpdf and gsql as a solo side-job maintainer.

This morning's Hacker News surfaced a post titled "Dumb Ways for an Open Source Project to Die" — a technical essay cataloguing the anti-patterns by which open-source projects fade out, written with the dry bitterness of someone who has maintained projects for years. Reading it, I realized I'm sitting at exactly the moment the post is about. gpdf shipped v1.0 in March 2026, and I haven't yet decided how I want to defend it against a quiet death.

"Dying quietly" is really an absence of decisions

The anti-patterns the author lists — neglected PRs, no public roadmap, no release cadence — look like a surface-level checklist. But one level down, they share a single root: a state where decisions stop being made, for a long time. Issue priority isn't decided. Release timing isn't decided. Whether to merge or close an outside PR isn't decided. Projects don't die because activity stops; they die because the decision-making stops.

This hits solo OSS hardest. A corporate project has at least someone who carries the decision backlog, but when you're running multiple Pure Go libraries on the side like I am, that backlog lives in one head only. The single muscle that matters most for long-term maintainability, I think, is the ability to return a 200-millisecond "we're not doing this right now" to one specific issue.

Three mechanisms I have wired into gpdf so it doesn't die

gpdf v1.0 shipped in March 2026. In the two months since release, I've deliberately put three mechanisms in place.

The first is declaring up front that outside PRs are not welcomed. gpdf is MIT-licensed, so cloning and forking are entirely free, but the README states that PRs to the canonical repo will generally not be merged. That can read as cold. The reality I've concluded, though, is that merging a third-party PR means future-me carries responsibility for someone else's code — which is not survivable under a side-job maintenance model. The same conclusion antirez reached when he switched DS4 to solo OSS mode: reports and feature requests come in through Issues, and I rewrite the patch in my own hands.

The second is fixing the release cadence at twice a year and letting smaller changes pile up in main. Whenever I try to release more frequently than that, something from another product inevitably eats the schedule and the release stalls midway. Committing to two releases per year up front means I can answer incoming issues with "this will be in the next release" and the psychological weight drops. The mere fact that a date exists is itself a device that forces decisions.

The third is keeping failed benchmarks in the _benchmark directory as-is. Those numbers underpin claims in my own blog posts, and three-month-later me needs to be able to trace where any given number came from. A lot of OSS deaths are really cases of the rationale behind past decisions evaporating, so leaving a paper trail of decisions is itself a life-extension tactic, in my view.

gsql is still in the "dies easily" stage

To be honest, gsql is operating on a weaker stance than gpdf. It hasn't cut a v1 yet, and several issues from the Reddit demand test sit in a "decide later" state. Borrowing the article's language, my gsql already shows a few of the signs of preparing to die quietly.

What makes the difference, I think, is whether a project has gone through the release ritual once. To ship gpdf v1.0, I was forced to decide questions like "does PDF/A compliance ship in v1?" and "do we expose the digital-signature API in v1?". The ritual sharpened my muscle for making decisions. gsql hasn't been through that ritual, so the decision backlog keeps accumulating.

Writing this paragraph, I just decided to slot a gsql v0.x → v1.0 cut into Q3 2026. If writing a blog post is what drags a decision out of me, that might itself count as one of the mechanisms.

Common questions

Isn't "not welcoming outside PRs" just closed-mindedness?

I can hear how it sounds. But in the range I've observed, solo OSS projects that welcome outside PRs and survive long-term almost always satisfy one of two conditions: the maintainer's day job is adjacent to that OSS, or the project has more than one committer. My situation is neither. My day job is contract software work for a startup, I'm the only committer, and gpdf gets maintained on evenings and weekends.

Under that structure, merging an outside PR leaves review responsibility behind the moment the merge button is pressed — and when that patch breaks something six months later, I'm the one fixing it. If instead I receive the request via an Issue, understand the intent, and rewrite it in my own hand, the entire codebase stays internally consistent inside my head. It's not closure so much as designing the project to fit the structure that I can actually sustain.