Version Zero Forever: When 0.9 Becomes a Permanent Address
Photo: Totalaero (talk), CC BY 3.0, via Wikimedia Commons
Every dependency audit eventually hits the same awkward moment: you find a library that does exactly what you need, the commit activity is healthy, the issues are triaged — and the version number reads 0.9.4. It has read 0.9.4 for four years.
Is that a red flag, or is it just a number?
The perpetual-beta project is one of the most common and least examined phenomena in open-source infrastructure. Some of the most widely deployed tools in the American tech ecosystem lived at sub-1.0 versions for the better part of a decade, powering production workloads at companies that would never ship a product without an SLA. Others are genuinely abandoned code wearing a plausible-looking changelog. Telling them apart requires looking past the version string entirely.
Why 1.0 Is a Contract, Not a Celebration
A 1.0 release is not a birthday. It is a public commitment: the API surface is stable, breaking changes will follow a deprecation policy, and downstream consumers can upgrade on a predictable cadence. That is an expensive promise. For a maintainer with no institutional backing, deferring it is often the rational choice — the project keeps full freedom to reshape its internals without a migration guide.
The problem is that the version number is the only signal most adopters check. A 0.x label can mean "deliberately pre-stable" or "the maintainer stopped believing in this project two years ago and nobody told the README." The version string cannot distinguish ambition from entropy. That distinction lives elsewhere in the repository.
The Four Signals That Matter More Than the Number
When we audit projects stuck below 1.0, we look at four things in order.
First, the stability of the API surface itself. Compare the public interface in the current release against the one from eighteen months ago. A project whose exports have not meaningfully changed since 2022 is functionally stable, whatever the semver says. A project whose core abstractions are rewritten every quarter is unstable, whatever the semver says. The number is a claim; the diff history is the evidence.
Second, the shape of the changelog. Healthy pre-1.0 projects show a pattern: deprecations announced, breaking changes batched, migration notes written even for minor bumps. A changelog that reads "misc fixes" for thirty consecutive releases suggests nobody is tracking surface area at all — which means the eventual 1.0, if it comes, will be a label slapped on drift.
Third, the stated reason. Search the issues and discussions for the words "1.0" or "stable." The best projects have a public checklist: these five things must land, this RFC must resolve, then we cut the release. The worst have a maintainer who answers the question with "eventually" and moves on. An explicit, testable definition of done for the 1.0 is the single strongest signal that the beta is a phase and not a habitat.
Fourth, who else is pinned to it. If a project at 0.9 sits in the lockfiles of major US companies, in production, for years, the market has effectively certified it. Adoption at scale is a form of due diligence performed by other people, for free.
The Adopter's Checklist
Before committing to a perpetual-beta dependency, we recommend answering six questions in writing:
- Has the public API changed materially in the last two release cycles?
- Does the project document a concrete path to 1.0, or explain why it refuses one?
- Are breaking changes accompanied by migration guidance, however informal?
- Is there more than one person with merge rights who has shipped a release in the past year?
- Do consumers with meaningful production exposure exist, and are they visible?
- If the project went dark tomorrow, how expensive is a fork or a replacement?
Three or more confident answers suggest a deliberate design choice: a maintainer who understands what stability costs and is choosing honesty over ceremony. Three or more blanks suggest the version number is doing exactly what it was designed to do — warning you.
What Maintainers Owe the Doubters
There is a flip side. If you maintain a project that has sat at 0.x for years, the ambiguity is costing you adopters whether you like it or not. Two low-cost repairs are worth making.
Publish a stability policy — a short document stating which parts of the API you consider frozen, which are experimental, and what would have to change for a 1.0. This costs an afternoon and converts your version number from a liability into a position. Alternatively, if the project is functionally done and you simply do not want the obligations of a stable label, say so plainly. "This project is feature-complete and will remain at 0.9 by choice; treat the API as stable at your own discretion" is a more useful sentence than four years of silence.
The open-source ecosystem runs on incomplete information. A version number is one of the only pieces of metadata every adopter reads, and one of the least reliable. Closing that gap — with a policy, a checklist, or an honest refusal — is release engineering in its most literal form: engineering the release signal itself, so the next auditor who hits your 0.9.4 knows whether they have found a home or a headstone.
