The Board That Never Ships: Auditing the Roadmap as a Marketing Artifact

Every open-source project eventually faces the same temptation. Someone opens an issue asking where the project is headed, a maintainer replies "great question, we should make this public," and within a week a Kanban board appears — three columns, a handful of cards, a link in the README. The community applauds. The maintainers feel accountable. And then, in most cases, nothing changes for eighteen months.

The roadmap is the only artifact in a project's repository that typically escapes the discipline applied to everything else. Code gets reviewed. Changelogs get dated. Releases get tagged. But the roadmap? The roadmap is vibes.

The Three Failure Patterns

Spend an afternoon auditing public roadmap boards — we did, across two dozen mid-sized projects — and the same pathologies repeat.

The eternal 80%. An item sits in a "In Progress" column with a half-finished draft PR attached, sometimes for years. The card signals momentum without delivering it. No one closes it because closing it would be an admission; no one finishes it because the maintainers' actual priorities moved on long ago.

The goodwill purchase. A feature lands in "Planned" the same week a competitor project ships something similar, or a vocal issue thread starts gaining traction. The card's purpose is not scheduling — it's de-escalation. "It's on the roadmap" is a socially acceptable way of saying "please stop filing comments," and it costs nothing.

The vote that evaporates. Community feature requests get upvoted, triaged into the board, and then quietly lose to whatever the core team was going to build anyway. The board performs democracy while the merge queue performs reality.

None of this is usually malicious. It's what happens when a planning document has no maintenance cost and no expiration date. Cards don't rot; they just accumulate.

What an Honest Roadmap Owes Its Readers

If a project publishes a roadmap, it's making a claim about the future. Like any claim in engineering, it should be falsifiable. We'd argue every public roadmap item needs three fields, and none of them are optional:

1. A date or time horizon. "Q3 2025" or "within two releases" — anything a reader can check later. "Planned" with no timestamp is a press release, not a plan.
2. A named owner. Not "the team." A person, or an explicit "unassigned — seeking contributor." Ownership is what distinguishes a commitment from a wish.
3. A terminal state. Shipped, dropped, or deferred — with a note explaining why. A roadmap where items can only ever move forward is a roadmap that's lying by omission.

This is essentially a scoreboard: a fixed, checkable record of what was promised and what happened. It's less visually satisfying than a Kanban board. It's also impossible to quietly abandon.

Projects That Already Do This

The pattern isn't hypothetical. Rust's RFC process forces every proposal through a documented lifecycle with explicit outcomes, including rejection — and the public archive of declined RFCs is arguably more valuable than the accepted ones, because it tells you what the project won't do. Kubernetes publishes release-themed cadences with hard dates and feature freeze checkpoints that hold even when individual features slip. SQLite, famously, publishes no roadmap at all — which is at least honest, if not helpful.

The worst offenders are usually projects that adopted a public board for optics during a growth spurt and never built the muscle to maintain it. The board becomes sediment. New visitors read it as current; maintainers read it as archaeology; nobody updates it.

A Modest Proposal for Asterix and Beyond

For our own project, we've moved to a roadmap format that looks suspiciously like release notes for the future: a flat table, one row per commitment, columns for horizon, owner, and status, with a quarterly audit where any row untouched for two cycles gets explicitly marked "deferred" with a reason. The deferred rows stay visible. Hiding them would defeat the point.

The pushback we expected — "this makes us look bad when we miss things" — turned out to be the benefit. A roadmap you occasionally fail at is credible. A roadmap you never fail at is a brochure.

If your project's public board can't survive an audit — if you'd be embarrassed to add dates and owners to every card — that's not a roadmap problem. It's a prioritization problem wearing a roadmap costume. Fix the underlying commitment first. Then publish it.