On Roadmaps and Teams, Part Two

In my last post, On Roadmaps and Teams, Part One, I argued that the only goals we should put on our roadmap are those which:

  • we, the Parrot Project as a whole, are absolutely committed to deliver; and
  • for which we have a team committed to delivering those goals.

There are many things which would be great to have in Parrot, and the more developers we have, the more of them we can achieve. But roadmap goals are different from all other goals in that the Parrot Project as a whole is promising to deliver on them; and the Project has organized teams of developers working to deliver on those promises. If we can't organize a team to work on a particular goal, then that goal does not qualify for placement on the roadmap.

As I hinted at the end of my last post, I'm taking a strong stand on this because otherwise we will never create a virtual machine that other software developers will be enthusiastic about using. Note the word 'other' in the previous sentence. In this context, 'other' developers mean people who don't want to 'work on' Parrot, who couldn't care less what's 'inside' Parrot, but who want to 'use' Parrot as the basis for dynamic languages and other applications.

And I'm not just talking about any Parrot users. We need users who are going to use Parrot in production situations in business, government, organizations and scientific research or who are going to embed Parrot in applications and devices having a wide consumer base. We need users for whom the decision to use -- or not use -- Parrot will have a major impact on their professional operations. When we get those types of users, Parrot will be an indisputable success.

To attract those types of users, we have to have a product whose features meet the users' needs at the moment in time when they are considering using Parrot -- right then, not three years down the road. We have to have a product whose features we can accurately describe and actively promote. The only way we're going to get those features is if we prioritize their development as roadmap goals. And the only way that such prioritization will happen is if we have groups of Parrot developers pledge to each other and to the Project as a whole that they will make it happen.

Production users need production-ready features. Production-ready features must be prioritized over other features, i.e., they must be roadmap goals. Roadmap goals must have teams dedicated to their achievement.

At this point you might be thinking, "This approach to our work is great but seems very abstract. What would it be like if we tried to put it into practice?"

That will be the subject of my next post.