a new roadmap of mozilla

carlos

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 Phoenix browser.

2. Develop further the standalone mail companion application to Phoenix already begun as Minotaur, but based on the new toolkit used by Phoenix (this variant has been codenamed Thunderbird).

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 Phoenix 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.



summary rationale

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

1. Phoenix 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 (Phoenix) is good for the mail application (Minotaur, leading to Thunderbird), 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).


original URL: http://www.mozilla.org/roadmap.html