Roadmaps are valuable for open source projects

I sometimes see open source projects laugh at the idea of having a roadmap, as if they could ever plan that far in the future. For small hobby projects, I agree that roadmaps aren’t very useful. But as you start to build a community around your project, you’ll find value in a roadmap. Your project’s roadmap isn’t an iron-clad promise, but it is a statement of your intent. With apologies to George Box: all roadmaps are wrong, but some are useful.

Why roadmaps?

If your roadmap is wrong, why put the effort into maintaining one? Think about the analogy. If you’re planning a trip, you look at the roadmap to figure out the route you plan to take. But if you find that a bridge is out or a particular stretch of road on your route is closed, you don’t barrel ahead. It doesn’t even require avoiding a disaster to change your plan. Maybe you see a historical marker and you stop to take a look. Or you detour on a more scenic route. But with a roadmap, you at least know what direction to head, which is an important part of getting where you want to go.

In your project, the roadmap shows what you plan on implementing and when(ish). This is helpful information for your users because it lets them know what’s coming. If they need a feature that’s not coming for a while, they can help you implement it or they can choose to go with another option.

But the roadmap is also useful for contributors because it tells them what’s most important to work on from the project’s perspective. Working on near-term features will be more helpful than working on long-term features, everything else being equal. You can also make clear what features could be brought forward (e.g. “I’d accept a contribution to add this now if someone wrote it”) and what needs to be done later because it depends on other work (or just because you’re not ready for the growth or complexity that would bring).

For most open source projects, I’d argue that the contributor value for a roadmap outweighs the user value (even though the user value is still important). The moment you go from one contributor (that’s you, dear reader) to two, you have to start coordinating. The project roadmap is an excellent tool for that.

Useful roadmaps

So you’re sold on the value of roadmaps. Now how do you make one that’s wrong-but-useful?

Timeline

For an established project, maintaining a two or three phase roadmap is reasonable. The first phase is the current release — meaning the release you’re currently working on, not the one currently supported. These are the things you plan to ship soon. As I describe in chapter nine of Program Management for Open Source Projects, you may need to slip some of these features to a later release, but overall it should be fairly accurate.

The second phase is the next release — what you plan to work on after the release you’re on now ships. This is a fuzzier plan, but the features tied to the next release will more likely than not ship as planned.

Beyond that, you can optionally have a “future” phase. This is “stuff we know we’ll do, but we’re not sure when.” Of course, you’ll want to be careful not to let it become an endless dumping ground. More on that in a moment.

If your project is just getting started, a longer timeline may be better. If you plan on frequent releases and know there are a lot of features you’ll add, you can add more releases.

You’ll notice I used “timeline” as the heading, but I haven’t yet discussed the calendar. If you can predict the release timing (see chapter 8!), you can add approximate dates. But if you have no idea when a release will actually ship, then don’t worry about it. Version numbers are sufficient.

Updating the roadmap

The best time to update a roadmap is when it changes. Duh. But what does that mean? Don’t sit around and wait for the Regularly-Scheduled Day of Roadmap Updatery™. When you think of something to put on the roadmap, put it on the roadmap. When you figure out that a feature needs to slip, update the roadmap. When you decide something is never getting done, remove it from the roadmap.

Tracking the roadmap

I haven’t talked about tooling yet because it doesn’t matter as much as simply having a roadmap. The best tool to use is your bug/issue tracker. Add the roadmap items as a feature/enhancement and associate them with the appropriate upcoming release. Easy peasy. This keeps the information together, including the details necessary if someone wants to implement it.

But anything else that works for you is fine. If it’s a wiki page or a file in the git repo or a slide in a presentation deck. Whatever you’ll keep updated and easy-to-find is the right place to track.

This post’s featured photo by Javier Allegue Barros on Unsplash