Cotto and I were talking a little bit about roadmaps the other day. Jim Keenan volunteered us to do it, and I think it was a pretty good idea. If Christoph is going to serve as the Lead Architect (tasked with maintaining a cohesive vision for Parrot and helping to set project priorities) and if I’m going to be the Product Manager (Making sure Parrot is a good product and satisfies the needs of our users), it would seem like we would be a good pair to get the conversation started.

We didn’t actually discuss a roadmap per se, but we did talk about how to talk about a roadmap, when the time comes. That’s just as valuable really.

In Parrot, as in most open-source projects, we have volunteers to do all the work. People come to Parrot when they are interested in it, and leave when they cease to be. People vote with their effort: If there are things they want to work on, they will do them. Otherwise, they may do nothing. Even if we do come up with a comprehensive roadmap, there’s no way to say that anybody will actually do the things we list. We can suggest things and encourage, but if nobody signs themselves up it won’t get completed. It’s that simple.

Sometimes when people get very vested in the success of the project they may volunteer to do things that need to get done but that they don’t otherwise have an interest in. This is fine in small amounts, but done too much this leads to burnout. We would like to avoid burnout.

The problem with Parrot’s roadmaps in the past, one of many problems perhaps, is that we listed a bunch of nice-to-haves that in retrospect turn into lists of never-got-dones. Parrot’s roadmap, as far back as I can remember it, contains more reminders of things we failed to do or failed to do on time than it does success stories. That’s not sounding like a particularly useful tool to me.

Making a roadmap is more than just taking the list of all the things in the world that we want and grouping a handful of them under a particular release. This is what we had been doing, and it really falls short. Instead, what we need to do is consider what people will actually want to do and be able to do by that time. In short, we need to get a lot more realistic.

First thing, we don’t put an item on the roadmap unless it has an associated “champion”. That is, we don’t just throw up a list of nice-to-haves, we only put up tasks that have interested volunteers. If nobody is interested nobody will work on it and it won’t get done. It doesn’t make any sense for us to put items like this, which are destined to fail, onto our roadmap. In a year we’ll look back and just recognize it as yet another failure.

We really need fewer failures.

I would much rather under-promise and over-deliver than continue to do things the other way around like we have. Modest pleasant surprises are always better than disappointments. The quiet dance we’ve been doing of reassigning roadmap tickets in Trac from a recently-passed release to the next one in line is getting old.

We’re talking about getting into a regular schedule for quarterly PDS meetings. I think each PDS will happen on the last weekend of the month of a supported release (January, April, July, October). In early January then, we are going to try to put together a roadmap to help us get to 4.0. Then in January of 2012 we start putting together a roadmap to take us to 5.0. So on and so forth until 2025 when Parrot is 100% perfect in all ways, is coded in solid gold, and is running on top of Skynet.

Right?

So, we don’t have a roadmap to display yet, but we have a timeline for when we will start to make a roadmap. That’s good, because it gives me a timeframe, a deadline for when we need to start putting those things together. It’s also not for Christoph and I to mandate a roadmap either. That’s not how Parrot’s community process works. However, if we can narrow down the wishlist to a list of likely candidates, we can help to really focus the discussion in a productive way.

In the coming days and weeks I’ll post about some projects that I think are good candidates for making it onto the Parrot roadmap for 2011. I’d be very happy to hear from users about things that they wish Parrot would do in the coming year. Being a little more specific than “Improve performance” would be appreciated!