Mozilla development roadmap

Brendan Eich, David Hyatt

Welcome to the Mozilla development roadmap. This is the third major roadmap revision since the original roadmap that set Mozilla on a new course for standards compliance, modularity, and portability in 1998. The previous roadmap documented milestones and rules of development through Mozilla 1.3, and contains links to older roadmaps.

We have come a long way. We have achieved a Mozilla 1.0 milestone that satisfies the criteria put forth in the Mozilla 1.0 manifesto, giving the community and the wider world a high-quality release, and a stable branch for conservative development and derivative product releases. See the Mozilla Hall of Fame for a list of Mozilla-based projects and products that benefited from 1.0.

Since 1.0, on the main-line "trunk" development path continuing up to 1.3, we have improved on the footprint and performance work begun during the 0.9.x milestones, fixing many longstanding flaws in the standards-compliant, modular, and portable codebase begun in 1998. We've seen the emergence of great features such as tabbed browsing, popup blocking, and http://paulgraham.com-inspired Bayesian spam filtering, along with faster, more focused browser projects such as Mozilla Firebird (formerly Phoenix) and Camino (formerly Chimera).

a new roadmap

But incremental development of the kind we've had since 1.0 is not enough for a healthy open source project. It's clear to us that Mozilla needs a new roadmap, one that charts a path to an even better future. Below we will propose a new application architecture based on the Gecko Runtime Environment (GRE), which can be shared between separate application processes. Before discussing the rationales and trade-offs, here are the implications and key elements:

1. Switch Mozilla's default browser component from the XPFE-based Navigator to the standalone Mozilla Firebird browser. Note: the standalone browser's user interface is defined entirely using XUL. So in preferring it, we are not deprecating XUL. We are demonstrating how XUL is a sound basis for fast, cross-platform applications such as Mozilla Firebird.
2. Develop further the standalone mail companion application to Mozilla Firebird based on the new XUL toolkit used by Firebird, codenamed Mozilla Thunderbird. Note: the new toolkit is a compatible reimplementation of the XPFE toolkit, with added features such as customizable toolbars. We are not starting a new C++ GUI toolkit, we are simply moving to the next generation XUL toolkit.
3. Deliver a Mozilla 1.4 milestone that can replace the 1.0 branch as the stable development path, then move on to make riskier changes during 1.5 and 1.6. The major changes after 1.4 involve switching to Mozilla Firebird and Thunderbird, and working aggressively on the next two items.
4. Fix crucial Gecko layout architecture bugs, paving the way for a more maintainable, performant, and extensible future.
5. Continue the move away from an ownership model involving a large cloud of hackers with unlimited CVS access, to a model, more common in the open source world, of vigorously defended modules with strong leadership and clear delegation, a la NSPR, JavaScript, Gecko in recent major milestones, and Phoenix.

The reasoning behind these new roadmap elements comes down to preferring quality over quantity. We must do less, but better, and with sound extension mechanisms, so that (for example) the community does not fight over user interface pigeon-holes such as the main menu items.

Another, non-UI, extensibility example: Gecko needs to support emerging XML and related standards, some experimentally and conditionally, without everyone having to hack into nsCSSFrameConstructor.cpp (and that enormous file should be eliminated or greatly simplified by incremental change, during 1.5, 1.6, and probably beyond). It should be possible, using good primitives (HTML and XUL widgets, SVG) and styling and composition tools (CSS, XBL) to avoid an explosion of new C++ code and rendering object bloat.

discussion

When Netscape released its original browser codebase as open source on March 31, 1998, the expectation, product plans, checkin rights, and indeed, code structure, all militated toward a continuation of the big suite of applications (browser, mail, editor) first heavily promoted as "Communicator" in the Netscape 4 days. This "swiss army knife" approach continued when we reset Mozilla around Gecko, XPFE, and scriptable XPCOM interfaces in late 1998. Along the way, of course, Mozilla has received very generous support from Netscape, mainly in the form of paid contributors and infrastructure.

The result has been a rich and complex application suite with a large set of back-end modules for the user-interface front ends. Many very good things have come from this ambitious integration, including XUL and XBL.

Yet, if the goal were merely to "rewrite the browser", XUL would have been a false economy. True, as intended, it allowed us to write a cross-platform application front end once, instead of writing native-OS-toolkit-based front ends for at least three platforms. But we ended up spending at least as many people and as much time on the various applications in the suite, and on integrating those application components, as we would have spent developing native browser-only front ends and one browser back end.

This critique supposes that Mozilla and major contributors such as Netscape might have been content to develop only a browser, and not a mail user agent, news reader, HTML editor, and application framework. Even in hindsight, it seems unlikely that "just a browser" would have sufficed. Beyond the worthy cross-platform mail and composer applications it enabled, XUL has been a huge win (a "true economy") for customizers, localizers, distributors, and portable application developers. Without making it our primary focus, we've developed a fairly high quality, web-oriented cross-platform application framework: Mozilla-the-platform.

Nevertheless, ignoring the valuable user-interface itch-scratching, and considering only the minimal set of goals for each application in Mozilla-the-application-suite, the cost of integration has been high. Unintegrated applications tend to be faster to load, smaller on average in dynamic memory consumption, and more robust and crashproof.

Another example of the high cost of app-suite integration is the inherently overloaded and complicated user interface (just one example out of too many: the File / New sub-menu). The target audience of the suite was never clear, and seemed to shift back and forth with prevailing business- and voluntary-contributor-driven winds. Hyatt's blog is an effective summary of the case against this approach. Simply put: great applications cannot be managed as common land, with whoever is most motivated in a particular area, or just the last to check in, determining the piecewise look and feel of the application.

Gecko also suffered from over-reach. Not because too many integrated applications were built on top of it -- those helped shake out many design and implementation bugs -- but because it was naively quite "modular" without actually being easy to extend. At the same time, parts of Gecko are still baroque due to early design limitations and an accumulation of code to patch around core problems.

summary rationale

In short, and in the same order as the roadmap element list above, the reasons for this new plan are:

1. Mozilla Firebird is simply smaller, faster, and better -- especially better not because it has every conflicting feature wanted by each segment of the Mozilla community, but because it has a strong "add-on" extension mechanism. We recognize that different users need many different features; such demand is legitimate on its face. Attempting to "hardwire" all these features to the integrated application suite is not legitimate; it's neither technically nor socially scaleable.
2. What's good for the browser is good for the mail application, too. Mozilla's integrated mail has many fine features, but it suffers from too many integration points with the other apps, and it remains a complicated front end maintained by too few people, most of whom have different day jobs now.
3. The 1.0 branch is almost a year old. It's time to move from 1.0 to 1.4 for mozilla.org-blessed stable development and product releases, to get all the stability, performance, and security fixes made on the trunk since 1.0 into the hands of distributors and users. Many distributors have plans to make this migration. This migration frees the trunk to make more aggressive changes during 1.5 and 1.6, but still with the incremental daily build discipline, and the quarterly alpha/beta/final milestone testing feedback loops.
4. Gecko stalwarts are leading an effort to fix those layout architecture bugs and design flaws that cannot be treated by patching symptoms. Those bugs stand in the way of major improvements in maintainability, footprint, performance, and extensibility. Just by reducing source code complexity, Gecko stands to become much easier to maintain, faster, and about as small in dynamic footprint, yet significantly smaller in code footprint.
5. The faux-egalitarian model of CVS access and pan-tree hacking that evolved from the earliest days of Mozilla is coming to an end. Many of the original hackers have moved on, leaving unowned and under-owned modules behind. The combination of over-reach, turnover, and legacy CVS access grants has led mozilla.org to institute code review requirements beyond those required by the relevant module owner (if there is an owner).

about ownership...

The last point is controversial. Let's dwell on it for a moment, and try to clarify it by exclusion.

• Super-review is generally a fine thing, and two levels of review, one from a domain expert and another from a strong generalist, often pay off for scary changes (big or small). We are not discouraging it where it does pay.
• We do not mean to disparage the valuable pan-tree cleanup and build system hacking done often by only a few dedicated volunteers -- that kind of work should continue.
• Nor do we mean to insist that owners are always right, or that they have "tenure" and cannot be replaced.

Having knocked down all those straw men, the important point that remains standing is this: it is almost always better to have a competent owner who rules decisively, than to have no owner and live in a state of indecision (N.B.: a committee of more than one or two is not an effective owner). This point is especially true for top-down application design and policy setting, particularly for user-interface design. For coherent UI within an application, there is no substitute for leadership by an "application czar". For cross-application consistency where it is needed, we expect such czars to communicate, cooperate, and consolidate things such as common default keybindings.

It is time for Mozilla to "return to normalcy": great software is originated by one or a few hackers building up and leading a larger team of people who test, clean up, extend, and grow to join or replace the first few. Code review, like testing, is an auditing procedure that cannot make excellent code from mediocre input.

Therefore we will promote strong ownership by relieving vigilant owners, on a case-by-case basis, of mandatory super-review requirements, for modules that the super-reviewers deem sufficiently well-owned. And where ownership is weak or missing, we will take steps to find an owner, or absent any candidates, to reduce our dependencies on the under-owned or unowned code. If we can "limp" along for a while without an owner for some crucial module, we will do so -- but experience has shown that almost always leads to a much more serious condition than a limp.

what all this does not mean

In the same vein of clarifying by counter-example, here is a list of more things that we are not proposing:

• We are not trying to stop volunteers and companies from developing the XPFE-based browser. Several companies have shipped and will ship products based on this venerable component of the application suite, and on the entire suite. However, we intend to focus on switching to separate applications based on the new application architecture. Therefore it is quite possible that the XPFE-based browser may bit-rot fairly quickly, so that the 1.4 branch contains its only working form. If enough contributors sign up to keep the XPFE-based browser working, mozilla.org will consider supporting that browser on the trunk beyond 1.4. However, it's not clear that we will have all the tinderbox and other resources needed to keep two different toolkit-based browser applications well-tested. We request that those companies and organizations shipping products based on Mozilla-the-application-suite let us know their plans in light of this new proposed roadmap.
• We are not deprecating XUL in favor of front ends based on native GUI toolkits. Nor are we deprecating Camino, Mozilla's Gecko-based browser that has a native OS X front end. Both approaches have their wins, and their loyal fans. The Mozilla community has embraced both approaches (even producing a version of Phoenix for OS X that tests well).
• Therefore, in switching browsers, we are not dropping XUL on the Mac. We aim to ensure that Mozilla's cross-platform applications and toolkit remain both cross-platform and viable as applications that people actually use. And we need the same kind of embedded Gecko test coverage on the Mac that we get on other platforms. So, when we switch the default-built browser to Mozilla Firebird, we will provide daily and milestone builds of it for OS X.
• Several crucial tools integrated with the XPFE-based browser, the DOM inspector and Venkman (the JavaScript Debugger), must be supported in the new, standalone browser, as add-ons.
• The other integrated components of the Mozilla application suite, Calendar, Chatzilla, and Composer (the HTML editor application), are not going away, either. We're not sure yet how they'll evolve -- whether they'll become standalone toolkit applications (and if so, based on which XUL toolkit), or popular add-ons to Mozilla Firebird (if so, they will need to use its new XUL toolkit). But we're committed to supporting them to the fullest extent required by their owners, including providing daily and milestone builds of them for community testing and feedback.

application architecture

Let's begin the new application architecture proposal by recapitulating the relevant facts and defining some terms.

There are currently two major classes of applications being built using Mozilla's technology. The first class of applications are embedding applications. They use Mozilla's layout engine, but write their own code for user interface features that exists outside of the laid-out HTML or XML document view. The second class of applications are toolkit applications. They are built on top of Mozilla itself and designed to be cross-platform. The user interface elements are defined in XUL and rendered by Gecko itself.

Both classes of applications will be able to make use of the Gecko Runtime Environment (GRE) to enable the sharing of a single installation of Gecko. Applications may even share profiles, although the inter-process communication work to support sharing profiles among applications running in separate processes is not done yet (as of 1.4alpha).

Toolkit applications will also support extensions, specially designed add-ons that can be layered on top of the core application to provide additional functionality. In the case of the browser application, examples of such add-ons include mouse gestures, the site navigation toolbar, the DOM inspector, and the JavaScript debugger.

In addition, we propose that certain toolkit applications should themselves be extensions, meaning that they can be built both as standalone applications and as add-ons installed into other applications. An example of such an application is Thunderbird, a.k.a. Mozilla Mail, which will be capable of either running as a standalone application or being installed directly into Mozilla Firebird, a.k.a. the Mozilla Browser, as an extension.

(We expect many fans of the current, integrated browser/mail application to demand such an add-on, and we will work to provide it before switching the default-built browser.)

The idea is to move from the over-integrated application suite to simpler toolkit applications, to remove more advanced functionality from the default configurations, but to provide robust tools for building your own browser by layering those extensions that you want to use on top of the base. In an attempt to avoid an explosion of unique builds that have to be supported by mozilla.org, we will likely ship with all of the popular extensions installed but disabled, so that they can be easily turned on by those who wish to use them, and uninstalled by those who don't.

A picture should make this architecture clear.

This picture shows Mail as both an Application (inside a square) and an Extension (the circle with an arrow pointing to the Browser application that Mail extends). The pure extensions, which are never applications as well, are shown at the top.

to do

This roadmap is a proposal. We are pointing in a direction toward which we think the Mozilla project should move. To get from where we are today (1.4alpha) to that better place, at least the following things need to be done:

• Eliminate the MOZ_PHOENIX #ifdefs added to files built by both browsers.
• Un-fork any files forked by Phoenix, where the XPFE side of the fork has since seen significant bugfixes not made to the Phoenix side. Whether the solution is to move such files to a shared location, or to merge fixes but continue maintaining both "tines" of the fork, or to deprecate and obsolete the XPFE tine, we can't say in general. But something needs to be done, and soon (fixes will continue to be made on the XPFE tine during 1.4).
• Ensure that small build options (low-level JS debugger support, MathML, rich text editing) that may have been excised from Phoenix previously are configured into the default build.
• Create or procure existing add-ons for:
  • DOM inspector
  • Venkman
  • The site navigation toolbar
  • Mail integration (<ctrl-M> for message compose, etc.)
• Develop Thunderbird based on the new XUL toolkit.
• Provide enough tinderbox machines to cover both old and new browser builds, during the transition period.

Again, we're only pointing the way here. The detailed plan of attack should be developed in the newsgroups and via Bugzilla. It's clear now that we will not be able to switch to Mozilla Firebird by the Mozilla 1.5 final milestone. Instead, we expect Mozilla 1.5 to coincide with Mozilla Firebird 0.7. But we intend to implement the new application architecture in the next several milestones, till most of the community is won over to the new apps. We invite your comments, preferably in the mozilla.seamonkey newsgroup.

milestone schedule

As the previous roadmap documented, the Mozilla project has been following a quarterly milestone plan that emphasizes regular delivery of stable new-feature releases, ideally with risky changes pushed into an "alpha" minor milestone, followed by stabilization during a "beta" period, then a shorter freeze during which only "stop-ship" bugs are found and fixed.

Many in the community have asked for a longer alpha period. But with too long an alpha, we fail to collect and act on feedback including automatic crash reports from a sufficiently large group of testers. Still, we're convinced that a longer alpha than beta makes sense, so we have moved one week from beta to alpha. Here is the updated milestone schedule:

Tabulating the milestones to show the proposed dates, with trunk freeze, branch creation, and milestone release dates distinguished from one another (the next milestone's start date is the previous one's branch date), yields:

As always, the milestone freeze time is 11:59 P.M. Pacific Time (see the tinderbox page for notices) on a Tuesday.

If you are planning a Mozilla-based product release whose schedule does not jibe well with the above milestones, we welcome your feedback (we will keep confidential information to ourselves, and will take appropriate safeguards as necessary).

how you can help

C and C++ hackers: tinderbox now measures code footprint, so let's start working to reduce it rather than increase it. Resist the all-too-common tendency to add more code. Try to remove code, simplify over-complicated code, undo premature optimizations, and purge gratuitous use of XPCOM and its not-quite-XPCOM precursors. If you have to add a new feature, make sure it's bundled in the right library, which may mean adding a new library. All additions to modules linked into the minimal embedding browser builds must be approved by drivers.

Mozilla embedders: we need your input to Bugzilla, marking bugs with embed, footprint, mlk, perf, and other relevant keywords. Use Bugzilla's new request-tracking capabilities to nominate bugs as blocking upcoming milestones (e.g., blocking1.4b?), and please comment in the bug with a convincing argument for why you require the fix by that milestone. Mozilla project management will help ensure that bugs are assigned to hackers who can target their fixes so as to satisfy as many milestone-keyword nominations as possible.

Bug assignees, and especially helpers who can offload Futured or untargeted bugs from their nominal assignees and fix those bugs: please make a pass at targeting your assigned bugs across the mozilla1.5 and mozilla1.6 milestones, using the criteria application and layout re-architecture for 1.5 and 1.6 as your guides. Please try to offload bugs to helpers, pinging drivers@mozilla.org if you cannot find anyone to help fix futured or untargeted bugs that you believe should be fixed soon.

Community members: please use Bugzilla's milestone nomination feature wisely, and do not change the Target Milestone of anyone else's bug without the assignee's consent. You may of course vote for bugs also to help inform prioritization (but remember that patching beats voting). Finally, please help keep advocacy and "me-too" comments out of the bug system.

project management

To drive developers looking to help toward bugs needing assistance in a timely fashion, to moderate risk, and to aid commercial projects based on Mozilla in managing their product releases, mozilla.org has created a group of project managers, drivers@mozilla.org.

The current drivers are:

• David Baron, dbaron@dbaron.org
• Chris Blizzard, blizzard@redhat.com
• Scott Collins, scc@mozilla.org
• Asa Dotzler, asa@mozilla.org
• Brendan Eich, brendan@mozilla.org
• Chris Hofmann, chofmann@netscape.com
• Randell Jesup, rjesup@wgate.com
• Michael Kaply, mkaply@us.ibm.com
• Robert O'Callahan, roc+moz@cs.cmu.edu
• Tim Rowley, tor@cs.brown.edu
• Mike Shaver, shaver@mozilla.org
• Seth Spitzer, sspitzer@mozilla.org
• Dan Veditz, dveditz@cruzio.com

Copyright © 1998-2003 The Mozilla Organization
Last modified July 24, 2003