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.

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

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:

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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:

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

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.

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.