You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

mozilla development roadmap

Brendan Eich, David Hyatt

table of contents

introduction

Welcome to the Mozilla development roadmap. This is the third major roadmap revision, with a notable recent change to the status of the integrated Mozilla application suite, 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.

Most of this document reflects the new application architecture proposal made last year. The effort resulting from that proposal has finally borne fruit, or to mix metaphors, hatched new application creatures: Firefox and Thunderbird.

The new, significant roadmap update hoped for early in 2004 has been postponed. See Brendan's roadmap blog for thoughts that may feed into it. An interim roadmap update focused on the "aviary 1.0" releases of Firefox 1.0 and Thunderbird 1.0, and the 1.8 milestone that will follow, is coming soon.

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 Firefox (formerly Firebird) 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. Focus development efforts on the new standalone applications: the browser currently code-named Firefox, the Mozilla Thunderbird mail/news application, and standalone composer and other apps based on the the new XUL toolkit used by Firefox and Thunderbird. We aim to make Firefox and Thunderbird our premier products, and encourage extension authors and other ISVs to target these applications for their work as well.
  2. Updated: Continue to perform sustaining maintenance, including security updates, on the SeaMonkey application suite's final stable branch (1.7.x) for enterprises and other organizations with large existing Mozilla deployments.
  3. Fix crucial Gecko layout architecture bugs, paving the way for a more maintainable, performant, and extensible future. All Mozilla applications benefit from such Gecko improvements.
  4. 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 Firefox.

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. Firefox 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. 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.
  4. 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 retiring the SeaMonkey application suite, or its XPFE front end, in the foreseeable future. Several companies have shipped and will ship products based on this venerable component of the application suite, and on the entire suite. Many organizations deploy it or a derivative of it, such as Netscape 7.x. We intend to keep supporting these deployments in at least a conservative, sustaining engineering fashion. However, we still intend to focus on evolving Mozilla toward the more flexible application architecture pioneered by Firefox and Thunderbird. That's where our innovative engineering effort should go.
  • 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 focusing on the new standalone applications including Firefox, 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, we will continue to provide daily and milestone builds of Firefox 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 Firefox (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.7alpha).

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 Firefox, a.k.a. the Mozilla Browser, as an extension.

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.

Architecture

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 list

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.7alpha) to that better place, at least the following things need to be done:

  • Reduce the number of MOZ_PHOENIX #ifdefs added to files built by both browsers, ideally to zero.
  • Continue to support and develop 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.

Again, we're only pointing the way here. The detailed plan of attack should be developed in the newsgroups and via Bugzilla. But we intend to implement the new application architecture in the next several milestones, and we still aim to focus application development energy on the new apps, while sustaining SeaMonkey for enterprises and similar deployments. 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:

Tree Management Diagram

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:

milestone start freeze branch ideal release actual release
1.8alpha6 22-Nov-2004 4-Jan-2005 n/a 6-Jan-2005 12-Jan-2005
1.8beta1 6-Jan-2005 9-Feb-2005 n/a 11-Feb-2005 ?
1.8beta2 11-Feb-2005 16-Mar-2005 n/a 18-Mar-2005 ?
1.8 18-Mar-2005 n/a 30-Mar-2005 ? ?
1.9alpha1 30-Mar-2005 11-May-2005 n/a 13-May-2005 ?
1.9alpha2 13-May-2005 22-Jun-2005 n/a 24-Jun-2005 ?

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.7b?), 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: