Written by Ram Rachum, developer of GarlicSim.
Text
Open-source developers, please provide a roadmap!
This is the first part of the FOSS gripes series, in which I’ll talk about a few issues in the open-source world that I find annoying or counter-productive.
Today’s issue is roadmaps. TLDR: Open-source developers, please provide a roadmap!
Present-oriented and future-oriented projects
A roadmap tells you (1) where the project currently is and (2) where it’s going to be in the future. Some open-source projects are so mature and feature-complete, that the “future” part isn’t so important. For example, no one would be interested in a roadmap of the SVN project. You can argue whether SVN is a good tool or a bad tool, but you can’t argue with the fact that it’s a very mature and feature-complete piece of software. A mature project like SVN is all about the present. One uses a project like SVN because of what it is, not because of what it’s going to be.
To contrast, some projects are more about the future than about the present. Many of the more interesting open-source projects are in this category. My own project GarlicSim is in this category as well. A couple of extreme examples of future-oriented projects are Paul Graham’s Arc, which aims to be “the hundred-year language”, and ReactOS, which aims to be an open-source drop-in replacement for Windows.
A present-oriented project, like SVN or PHP, is one which stopped growing. It reached adulthood and now it will work diligently for as many years as possible before a younger project will retire it. A future-oriented project is like a child. It can’t do much useful stuff yet, it might be buggy and severely lacking in features, but if you invest in its development it might grow to be a very powerful and successful project.
One reason that there’s a lot of buzz around future-oriented projects is because people want to be already familiar with the technology of the future before it becomes the present, so by the time the future-oriented project is mature, they will be positioned to take full advantage of it. For example, GarlicSim supports Python 3 not because Python 3 is currently a useful technology, but because it’s going to be a useful technology in a few years from now, and when that time comes GarlicSim’s Python 3 support will be ready for action.
Most of the open-source projects we use are somewhere in the middle; they’re partly present-oriented and partly future-oriented. Like young adults, they are currently productive, but their days of glory are still ahead of them.
How roadmaps fit in
As I said before, a roadmap tells you where the project is and where it’s going to be. This is very important for projects which are future-oriented or even partly future-oriented. If I see an open-source project which is currently experimental or unstable, but might become a big deal in a few years from now, then I want to know exactly what its development team is planning and how they see that project’s future! Otherwise I’ll be reluctant to use this project.
If project “FooBarnicator” is going to be the next revolution in field X, I want to know exactly how they’re going to conquer that field and by what time they think they will become a proven technology. This may sound like a pretty obvious thing, but if you’d look at websites of many open-source projects, you’ll see that they don’t seem to understand this. Many open-source projects simply don’t have a roadmap on their website.
So this goes out to all open-source developers: Please put a roadmap on your project’s homepage! If you’ll give your users a clear description of what you’re planning and what your long-term goals are, they’ll be more likely to start using your technology.
How a roadmap should look like
A roadmap should tell you where the project is, and where it’s going to be. Here’s an example of a roadmap from GarlicSim’s homepage:
Present:
- GarlicSim is at version 0.6.2, which is an alpha release. At this experimental stage of the project, backward compatibility will not be maintained. However, I will be available to assist in issues related to backward compatibility.
Near future:
- GarlicSim 0.7 will be released by June 1st, 2011. Planned features: Crunching on the cloud using PiCloud and a Mayavi-based physics simpack.
Future:
- By January 1st, 2014, a polished and user-friendly version of GarlicSim will be available. This version will be usable by the general population of scientists and engineers, including those that don’t know Python.
This specific roadmap goes a step further and says where the project is going to be both (a) in the near future and (b) in the distant future.
But… it’s an open-source project!
Ah, yes. Open-source developers are so reluctant to give anything that even remotely resembles a deadline or a release date. I understand where they’re coming from, but it’s still a mistake. The reason they’re reluctant to give release dates is because open-source projects have very limited resources. Usually the core developers have day jobs and they can only work on the open-source project in their spare time. Meaning that progress on the project is (a) slow and (b) unpredictable. Therefore they are afraid to say “We’ll have feature Y by April” because maybe they won’t have time to work on it, and then they’ll have to disappoint their audience.
Solution: Be pessimistic, keep a lot of safety distance
Just because development is slow and unpredictable, doesn’t mean you can’t give an estimate on when it will be done. The solution is simple: Give a pessimistic estimate. If you feel like it’s going to take around one month for that new release, say that the release will be made in three months. I know, it hurts to tell people it’s gonna take three months when you feel that it’s going to take only one month. Do it anyway. People don’t care so much about efficiency; they care a lot about predictability and long-term progress— Otherwise projects like SVN or PHP wouldn’t be so popular in the first place. Better say three months and possibly make it early then say one month and then run the risk of being late and disappointing your users.
Also, the short-term unpredictability of progress on open-source development is a non-issue in the long run; over a bigger time period, the peaks and valleys in the project’s progress average out to a uniform rate of progress. Slow, but uniform and predictable. And people don’t care about slow progress: Just look at all the crappy technologies that we still use in 2011.
Final words: Open-source developers, please provide a roadmap on your project’s homepage.
———
Thanks to Amir Rachum and Shlomi Fish for reading drafts of this essay.
