Archive for October, 2005

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.

Yesterday one of the folks at the Mozilla Corporation mentioned that he still has trouble describing the relationship between the Mozilla Corporation and the Mozilla Foundation cleanly and easily. He asked me to write something. I tried out a description David Ascher had suggested a few weeks back, and a discussion followed. I’ve tried to capture the gist below. Many thanks to David for providing the first two sentences, which of course frame the discussion.

The Mozilla Corporation is a private corporation with a single shareholder. That shareholder is a 501( c) (3) non-profit dedicated to the public benefit. This means that the Mozilla Corporation — like all corporations — focuses on satisfying its shareholder(s). In this sense organization is very standard. However, in most cases a corporation satisfies shareholders by producing a financial return on investment — dividends and / or higher stock price. This is where the Mozilla Corporation and its shareholder differ from the standard model. The goal of the Mozilla Foundation is to promote the health of the World Wide Web itself by providing free, open source client software. In other words, to serve the public good. So the Mozilla Corporation satisfies its shareholder by promoting this public benefit, not by seeking to maximize revenue.

The Mozilla Corporation should be a professional, run well organization. It must continue to work with and lead the open source community in our shared efforts to create great software and enable growth and diversity on the web. It must work well with commercial entities using Firefox and building on Firefox. It should treat its employees with respect and be a great place to work. It must recognize and support the contributions of non-employee contributors who play such a critical role. It should generate revenue to support the Mozilla project where appropriate.

So some of our activities will look business-like — that’s how one works well with commercial entities, and this is critical to long term success. Other activities will not look at all like “business as ususal.” They will be driven by our open source DNA and our community. And our ultimate goal is most distinctly not business as usual; it is supporting the health and vitality of the web itself.

Every once in a while I realize that I am unquestionably part of a particular demographic group. This happens periodically as I look at our late 1990’s vintage Subaru Outback Wagon and realize how many gazillions of people in our area drive this car. I had another, odder moment a while back. In this case I’d call the demographic group “Silicon Valley Family.” My husband, son and I were returning from Calgary. At the Calgary airport, one goes through US Customs before getting on the airplane rather than when one lands. This particular day the airport was quite empty, there were no lines and we walked right up to the Customs Officer. My son is under 10 and so I was explaining that in some places crossing a national boundary is a very big deal, and talking to the customs officer can be very tense. Who knows, maybe he’ll be in a tense border crossing some day and understanding the value of behaving appropriately will be important.

The three of us arrive at the customs officer. He fiddles with our passports for a bit, then asks “Are you related?” What an odd question. After a moment I answer “Yes, we’re married and this is our son.” He looks at us for a moment and then asks our son “How old are you?” A moment of hesitation occurs, part shyness and part testing out a new idea since this is the first person to ask my son his age since his birthday a day or two before. A rather long series of questions follow, which my son manages to answer. It’s not threatening, but it’s odd. And it’s long.

Then the customs officer turns to my husband and asks “What do you do?” It’s a formal tone of voice, an Official question, not chatty at all. My husband answers ” I write software for Stanford University.” The customs officer turns to me and asks the same question. I start to answer “I run a . . .” I hesitate, as I used to say “I run a non-profit organization that makes software” and that response is not accurate enough for me now. So I end up saying “I run a . . . software company.” Now I feel strange.

The officer turns to my son and says “And what do you do?” He adds, in an iroinic tone of voice, “And are you working already?” My son thinks hard. He’s been following the conversation carefully and knows some answer is expected. After a moment he gets it, thinking I suppose to the educational games he’s been playing during vacation. His face brightens, his voice grows confident, and he announces “I USE the software!”

The Customs Officer has met his match. He almost even laughs, then ends the interview and waves us on. And there we have it. The Silicon Valley family — software everywhere.