What is Open-Source Roadmap?
A public plan, published by an open-source project or a company, that shows what is being built, considered or shipped next. It is usually kept in the open on GitHub or a project site so users and contributors can follow and influence it.
Definition
An open-source roadmap is a publicly visible plan of upcoming work for a software project. It answers the questions users and contributors ask most: what is coming in the next release, what is being explored, what has been decided against, and where help is wanted. Unlike an internal product roadmap, it lives where anyone can read it, and in many projects anyone can comment on or propose items. The phrase covers two related things. The first is the roadmap of an open-source project itself, such as a language, framework or self-hosted app, where the plan has to reflect what volunteer and corporate maintainers can realistically deliver. The second is a public roadmap published by a company, sometimes for a closed-source product, using open tools and processes, for example a GitHub repository of roadmap issues organised by quarter. Projects publish roadmaps in a few common formats. A board, such as a GitHub Projects board with a roadmap (timeline) layout, shows issues on a timeline using start and target date or iteration fields, with markers for milestones. Milestones group the issues and pull requests planned for a release and show a due date and completion percentage. Design-proposal processes such as Rust RFCs, Python PEPs and Kubernetes Enhancement Proposals (KEPs) record substantial changes as documents reviewed in public, so the roadmap emerges from accepted proposals. Release or iteration plans list what a team intends to ship in a given version. And a simple roadmap page on the project website groups items into statuses like released, next release and exploring. A good open-source roadmap is honest about uncertainty. Most label items by confidence (exploring, planned, in progress, shipped) rather than promising dates, link each item to an issue or proposal where discussion happens, and say clearly where feedback should go. Because contributors are not employees, the roadmap also works as a recruiting tool: it shows newcomers which work matters and where they can help.
When to Use Open-Source Roadmap
Use "roadmap" for the forward-looking plan, "changelog" or "release notes" for what already shipped, and "backlog" for the full, unprioritised list of work. A roadmap is a curated subset of the backlog with an order and, ideally, a reason. How to publish one for your own project: - Pick one source of truth. For most GitHub-hosted projects that is a GitHub Projects board with a roadmap layout, fed by real issues, so the roadmap updates as work moves. - Use milestones for concrete releases (v2.3, v3.0) and labels or a status field for confidence (exploring, planned, in progress, shipped). - For large or controversial changes, require a written proposal (an RFC, design doc or enhancement proposal) and link it from the roadmap item. - Prefer time buckets (now, next, later, or quarters) over exact dates unless you control the staffing. - State where feedback goes: issue comments, GitHub Discussions, a forum or community calls. - Review it on a schedule, for example every release, and archive stale items rather than letting them rot. When evaluating an open-source tool, a maintained public roadmap is a useful health signal alongside commit activity, release cadence and issue response times. A roadmap that has not changed in a year, or a repository that says conversations are locked, tells you more than a polished marketing page. Check the last update date before relying on it for planning.
Open-Source Roadmap in Practice
- Kubernetes: the kubernetes/enhancements repository holds Kubernetes Enhancement Proposals (KEPs) and tracks each enhancement through alpha, beta and stable stages on per-release Enhancements Tracking Boards.
- Rust: the rust-lang/rfcs repository runs the RFC process, a consistent, public path for proposing and reviewing substantial changes to the language.
- Python: Python Enhancement Proposals (PEPs) are design documents that propose new features and record decisions, starting with PEP 1, which defines the process.
- TypeScript: the TypeScript wiki has a Roadmap page listing features planned for given releases, linked to per-version iteration plans published as GitHub issues.
- Mastodon: joinmastodon.org/roadmap groups work into Released, Next release and Exploring, with items tied to version numbers.
- GitHub: the github/roadmap repository publishes GitHub's own product roadmap as labelled issues on a project board arranged by expected quarter, with an Exploratory column for undated items.
Common Mistakes
- Publishing exact dates the maintainers cannot control. Missed dates erode trust faster than vague time buckets.
- Keeping the roadmap in a separate document that drifts from the issue tracker. Link roadmap items to real issues, milestones or proposals.
- Treating the roadmap as a promise to users rather than a statement of intent, then facing backlash when priorities change. Say so explicitly.
- Not saying where feedback goes, so requests end up as duplicate issues or are lost in social media replies.
- Letting the roadmap go stale. An abandoned roadmap signals an abandoned project, even when the code is still maintained.