Tag: roadmap

Posted on

New Roadmaps

Mozilla is a huge project, now cursed with success. It did not start that way. To think about where to go, we should mull over how we got here.

Over the years since the first major roadmap, I’ve tried to steer the project toward the shortest path to the next port of call that was not going to leave us cannibalizing the ship and ourselves, for want of supplies and fresh crew (more contributors). Doing this without running out of stores and existing crew along the way required good luck, along with a hard-nosed attitude about what to keep and what to throw overboard.

Some paths were long, for instance the reset in late 1998 around Gecko, XPCOM, and an XPFE. This was a mistake in commercial software terms, but it was inevitable given Netscape management politics of the time, and more to the point, it was necessary for Mozilla’s long-term success. By resetting around Gecko, we opened up vast new territory in the codebase and the project for newcomers to homestead.

More recent journeys to better ports were much more in tune with the Internet zeitgeist. The best example was FIrefox as the new model application.

Firefox changed everything for us, for the industry, and most important, for browser users. We have heard repeatedly from people who feel as though their computers are friendly tools again, instead of spyware-ridden zombies infected via the default browser. These folks now see the web as fun and empowering, not static or even degrading over time.

Now, having given the default browser a little competition, and helped advance the causes of simple yet powerful UI, web content standards, and user innovation toolkits and networks such as XUL extensions, their own extensions (e.g., GreaseMonkey’s user scripts), and AJAX/DHTML/whatever new-style web apps, we must journey again to an even better place, with another hundred million downloads, and even more users worldwide.

We see the Web outpacing traditional desktop and operating system software development. Great web services and mashups abound in the new, over-hyped era. In spite of the hype, these new Web apps usefully point to the immense, hardly-realized value of people connected by the Internet.

Firefox is “just a browser”, but it has an evolving role to play in this world. The browser is a platform, as threatened in 1995 and dismissed with the death of Netscape. Yet every web app is hobbled by stagnant content standards from five or ten years ago. There is no good reason for this.

There is no reason why browsers should not innovate, along with plugins, applications, and operating systems, to support modern hardware-assisted graphics, dynamic programming languages, and richer content types. The reach of the web still favors the browser over any particular OS or non-Web platform.

Therefore in order to innovate nearer to “Web time” on the Firefox user interface and extension fronts, we propose to develop the front end of Firefox 2 and the platform for Firefox 3 concurrently, with Firefox 2 releasing in less than a year. The details have been drafted in a product roadmap that Chris Beard has written. (Many of you know Chris as an active driver and product manager in the project since Firefox 1.0 launched. He’s been a huge help, and I’m very grateful for his contribution here.)

The back end code, Gecko and other modules such as the JavaScript engine, will occupy the Mozilla source tree “trunk” development during the Gecko 1.9 milestone, which is already under way. The major efforts are to:

  • rearchitect our rendering layer to support hardware-accelerated graphics;
  • selectively improve architecture in the layout engine, to fix longstanding bugs;
  • improve web author productivity with better content languages and debugability;
  • move XUL to the next level in concert with the rendering and programming improvements;
  • make XULRunner the embedding vehicle for Firefox and all modern XUL applications.

Mike Shaver and I have gathered together the requirements and plans of many folks in a new platform roadmap.

These roadmap drafts are rough, and although much work has already been done in the directions outlined by these documents, much more remains, and our plans will change as needed. But plan we must, perhaps more than ever in the project’s history. We have reached the big time now, and there is no turning back or coasting along.

Your comments are welcome.

Posted on

New roadmap coming

This roadmap update has been much-delayed, as we have juggled priorities and sweated security releases on the AVIARY_1_0_1 branch. Sorry for the delay; I will keep the roadmap up to date much more frequently from now on.

The new roadmap restarts the document with as little repeating boilerplate as possible. Highlights:

  • The main point is to focus near-term work on the Mozilla 1.8 milestone, which is the basis for the rv:1.8 Gecko codebase in Firefox 1.1 and XULRunner.
  • We would like to branch 1.8 by the end of June, in order to open the trunk up for general Mozilla 1.9 alpha 1 milestone development. Sooner would be better, and later is hard to justify.
  • A high priority for Firefox 1.1 at this point is to finish the end-to-end support for the incremental app/extension update work being done based on bsdiff, which has been spearheaded by Darin Fisher.
  • We have also made several major architecture changes (e.g., XPCNativeWrapper automation) for improved chrome scripting security, with one more to land, so security is another high priority that may justify late-breaking changes.
  • Apart from update and security, we won’t take any big changes on the 1.8 branch, instead focusing on quality and polish. So now is the time to cut low-priority or “nice to have, but …” items from your 1.8 buglists.
  • Pending testing results from Deer Park Alpha 1, which just released, we will have a better idea of the order of work remaining.
  • There will be a second Deer Park Alpha, to line up with the 1.8b3 trunk milestone. Here’s the usual diagram, free of hard dates:

branching-2005-05-04

We will construct a detailed schedule for the rest of the release. Until we have a more “real” schedule, the roadmap will be fuzzy about dates. Apart from the absolute priority that Firefox 1.1 be able to update itself in small background-downloaded increments, and that its security and quality be at least as high as Firefox 1.0.x, we have already enabled new platform features such as SVG and <canvas>. These new richer-graphics-for-the-web features are in usable shape, and they deserve testing and experimental usage in XUL and even HTML. We want developer feedback, which we will incorporate into future releases.

In order to help both our XUL platform and (more important) the open-standards-based web to compete with next-generation OSes and their proprietary frameworks, we are rearchitecting Gecko’s graphics subsystem. Here is a picture of Gecko emphasizing its graphics infrastructure as of the 1.8 milestone and Firefox 1.1:

fftracinsm1

Here is where we are headed in 1.9:

gfx-arch-19

We are joining forces with the Cairo Graphics project (this will be no surprise to anyone following the project, in particular roc‘s blog). Together, we can move faster and on more platforms, toward a hardware-accelerated 2D future, and beyond.

As with any large rearchitecture, there will be bumps along the way. But we are not going to rewrite the world at once (never again!). We aim to make changes in smaller increments, that can be done during the 1.9 alpha cycles. So the 1.9 schedule, which I won’t even bother to depict yet, will have a good number of alphas.

Anyway, this is a blog item’s worth of roadmap content, which will show up in a more polished form in the main roadmap soon. Your comments are welcome.

/be