Traditionally, our Roadmap has been a short, very high level document that identifies the key issues of an era and sets direction in those areas. I’d like to see us try out a new approach to our roadmap going forward.
It would be very helpful for the Platform roadmap to become more of a working document, one that sets a global framework for what we’re doing, and is also tied structurally to other, more detailed planning documents. It should help engineering contributors relate their work to the overall plan, and should help everyone see what’s planned and how the pieces tie together. We should have an explicit plan for the Mozilla “platform” (often known as “Gecko”) and we should have an explicit plan for the products, starting with Firefox. Perhaps the two plans together are the Roadmap, or perhaps we have a product roadmap and a platform roadmap, I’m not sure. But in any case the two must be closely related.
I’ll outline here a plan for the platform piece, with the understanding that the product piece will follow closely. Mike Shaver, with Brendan’s encouragement, has started the effort to produce a platform roadmap along the lines I describe below.
More specifically, here’s a plan:
The Platform Roadmap remains a short, high-level document, but would provide a level more detail than our current and past roadmaps. For example, the next iteration should describe the technology capabilities of the Mozilla platform in the 1.9 release. It should have an outline of the major areas of technology that we know we’re working on for our 1.9 release, plus a summary of the rationale for these areas and a general statement of what we hope to accomplish in the 1.9 cycle. This document must have an owner who is responsible for the overall integrity of the plan, for including the correct areas of technology, and for figuring out how they relate together and for the ongoing vitality of the document. In my mind, this person is Mike Shaver, in close collaboration with Brendan Eich. By close collaboration I mean that Brendan is integral to the process and the document isn’t complete until Brendan signs off on it. By designating Mike Shaver as the owner I mean that it is Mike’s job to drive this process, to make sure the document gets written (either by writing it himself, or getting others to write pieces) and to sign off on the content as well. This means Mike is responsible for getting the deliverable done while needing key input from others. It’s a bit of a juggling act, and one for which Mike is uniquely suited.
The Platform Roadmap should provide pointers (links, references, etc.) to the more detailed planning and implementation work being done by the contributors. For example, there should be pointers to more detailed information on the state of our graphics initiatives such as cairo and SVG integration. The goal would be that someone can look at the Platform Roadmap, see that we’re working on a set of initiatives, follow pointers to those projects and get more detailed goals, schedules and status.
This detailed project-based information would be maintained by the contributors working in this area. This should help give the groups of contributors a way to describe what they are doing, and to have greater involvement and ownership in determining the deliverables, a reasonable schedule, etc. This second level of information will take some work to get pulled together. Perhaps not as much as might be expected, since many of the contributors working on major initiatives have documentation and status information available already and we can point to that information from the Platform Roadmap. In some cases we will have more planning to do. And in all cases the contributors will need to make sure that the description and status of their initiatives remains accurate. But of course, we need to do this in any case. I’d like to see the Roadmap become an organizing framework that allows us to get the most use out of that work.
This means that the Roadmap becomes something that the organization as a whole works on, works with, and relies on. That allows other organizations interested in Mozilla technology to rely on it as well, and to get better, more up to date information about what we’re doing than we currently provide.
This type of “roadmap” is something different from the past. It combines the high-level direction setting of past roadmaps with a new operational role. Mike Shaver is ready to take this on, Brendan is working closely with him and pushing to make this successful, and they plan to have a draft Platform Roadmap posted in the next couple of days. It will be a draft, it will undoubtedly need revision and have plenty of room for improvements. But I’m optimistic we’ve got a plan that lets us make progress. And that’s good news.