In my experience, the best maps contain historical notes and sightseeing tips. A software roadmap in particular must keep integrating the present as it passes by, or it soon becomes useless. That kind of map records design decisions and their rationales. More important, such a map reflects unforeseen terrain and unexpected inventions as they emerge, rather than starting from some (unrealistic) fixed architecture and proceeding through mundane implementation.

brief history

It has been over five months since I posted to mozilla.general my then-current thoughts on the Mozilla browser development schedule. That schedule listed only one large feature, mail/news integration, and put off enumerating the rest until "later, [...] barring a better idea."

Since then, a lot of great work has been done by all mozilla.org developers, fixing warnings and bugs, porting and cleaning up code, improving performance, refining downloadable chrome, setting up the autoconf build system, etc. But the mail/news code from Netscape never arrived. The features most demanded by content developers (incremental layout with reflow, correct CSS, a Level-1 DOM) have been hard to implement on the old codebase. And developers who have wanted to "just add a hook", a la Emacs and its extension languages, have found the old layout and FE code less hospitable than they would like.

Well, now is later, and we do have a better idea or three.

where we're going

It's time to stop banging our heads on the old layout and FE codebase. We've pulled more useful miles out of those vehicles than anyone rightly expected. We now have a great new layout engine that can view hundreds of top websites. We have a convincing proof-of-concept for an XPFE. Why not use these two new projects in Mozilla, to solve a bunch of longstanding problems? All of the following combined to say that it is time for the Mozilla browser project to use XPFE and NGLayout:

the judgment of the module owners;
the fervent wishes of web content authors; and
my personal judgment as mozilla.org technical bigshot

Not only will many bugs and lacks be resolved, the road ahead can better support a full mail client, user-scriptable hooks, and many other clients and proxy-like modules.

Moving to XPFE and NGLayout means moth-balling all of the old-style FEs, and of course mozilla/lib/layout and its friends. Coordinated development will cease right away on the old layout code, XFE, and all of the other FEs.

Note however that most back-end modules carry forward with XPFE and NGLayout; many already work with NGLayout as-is, while some have been #ifdef'ed. While we won't break old layout and FEs intentionally, evolution of all the back-end modules common to old and new layout will tend to rot the old codebase. We've already CVS-tagged the mozilla tree with the label MozillaSourceClassic_19981026_BASE to facilitate mothballing and archaeology (there's also a MozillaSourceClassic_19981026_BRANCH branch tag for retrograde development).

re-introduction

This document will serve as a narrative roadmap for mozilla browser development. It won't be a schedule, although schedules should be attempted that refer to the terrain recorded and projected here. It will state rules of the road, or the design principles we'd like to employ, to build on the value of XPFE, NGLayout, and modularity using XPCOM. It will list major items of work. And I'll update it over time to reflect reality.

Nothing (apart from accurate history) in this roadmap should be taken as irrevocable. Although we try to avoid unduly revisiting decisions, we welcome all developer comments and corrections. Let controversy bloom if it needs to. Just give us your evidence and reasons, and we at mozilla.org will correct our course and this map to match the actual terrain.

design principles

Here are the browser road rules. Some of these points are concrete design decisions more than highfalutin' principles. But we think they reflect sound ideas (for example, autoconf captures feature dependencies better than our old Unix build system's platform macros and consequent #if defined(linux) || ... tests in the code).

External development counts more than convenience or ease-of-habit for internal-to-Netscape developers. The Netscape X-heads, for example, have moved all of their mail usage except for I'm-out-sick-today and any truly-proprietary messages to the mozilla.unix newsgroup. Likewise with NGLayout hackers and the mozilla.layout group. So it shall be for all development.
Fresh mail and news clients will be designed and implemented jointly by Netscape and external developers, using open source methods, and this time with an open source database (which I think is likely to be Berkeley DB). The new mail/news code will use NGLayout for HTML rendering. It shall use as much XPFE-like cross-platform widgetry as it can; it shall use thin-mail techniques akin to Ender and Shack.
As much as possible, UI structure should be implemented using HTML or XML and the NGLayout engine. Style should be expressed using CSS where doing so makes sense, and doesn't require non-standard extensions to CSS. Structure that can be queried, modified, and superposed from remote sources should probably be RDF, expressed in its XML syntax. Actions should be implemented (or at least, be implementable) via well-defined events and their JavaScript handlers
Modules will use XP-IDL and XPCOM to specify and query their programmatic interfaces. That way, all modules are scriptable without requiring all interface creators to write repetitive-yet-tricky script-engine glue by hand. Also, parts of the system may be distributed across thread, process, and machine boundaries using automatically generated stubs. This distribution potential is a distant second goal, except where single-threaded code restrictions require us to implement an apartment threading model.
Any scripting hooks above and beyond the scriptable-C++ entry points that we get by using XP-IDL must be designed and specified using IDL extensions. The crucial principle here is to make all useful parts of the browser easy to script. What's more, events must be easy to "hook" or handle in a flexible way, say using JavaScript. More on this point will be written in the XPCOM-Connect document.
autoconf will be the one true Unix-hosted build system for the modules you checkout and build en masse to make a browser that runs on Unix. Module owners will have to maintain only their module's Makefile.in and configure.in scripts for Unix, not both of those and gmake Makefiles. (This principle does not apply to NSPR, which is a separately-built prerequisite of the browser; it may be that the Berkeley DB follows NSPR into separately-built prerequisite status, eventually.)
X-heads believe the time is right to move from Motif to GTK+, the leading fully-open-source X-based UI toolkit. The general principle here, mentioned above in the mail/news paragraph in connection with Berkeley DB, and of course behind autoconf adoption, is that Mozilla must use the best open source solution to solve a well-understood problem.

major work items

Each of the following tasks constitutes a major milestone. This list isn't even partially ordered, but it should be, to express dependencies. It should be topologically sorted and scheduled, too (later). It shall be refined to include sub-tasks and missing items of work. For now, it's a roughly-ordered brain dump of what I think we'll all be doing in the next few months:

NGLayout completion. See the NGLayout Project Page for detailed to-do lists and schedules.
In light of the "open source solution" principle, the widget library used by NGLayout needs to be ported from Motif to GTK+.
The old composer/editor was tightly coupled to old layout. NGLayout has a rich DOM API that perhaps (with more event work) could form the basis for the new editor. In any case, Mozilla must have an HTML composer/editor, and it should be embeddable via an OBJECT or TEXTAREA TYPE="text/html" tag.
XPFE design and implementation. There is a very preliminary set of design documents , but they are subject to change and evolution based on the design principles above, and interested developers' input.
Back-end modules such as RDF and JavaScript are more-or-less ready to go, but their interactions, especially their execution model interactions, need analysis. Also, memory consumption and things like garbage collector scheduling require a "whole system" analysis.
Mail/news XPFE and modular back-ends need to be designed and implemented, or in a few cases evolved from existing Mozilla code such as mozilla/lib/libmime.
The XP-IDL compiler and IDL specs for all interfaces must be written, tested, and deployed as part of the build system.
The JavaScript XPCOM-Connect runtime, by which JS can call C++ methods using runtime type information, and convert results to JS types, must be built. The good news is that some of it will resemble LiveConnect. The bad (or good, for hackers who enjoy it) news is that we need some assembly code to implement each platform's Invoke method, where platform is a pair: (cpu instruction set architecture, compiler-and-cpu-determined calling conventions).
Conversion of all Unix builds to autoconf. Currently, NGLayout is built by mozilla/nglayout.mk. If we follow the existing browser build model, it should be built by the Makefile generated from mozilla/Makefile.in and mozilla/configure.in.
For Windows builds, at the least mozilla/nglayout.mak and mozilla/client.mak need to unify under the latter name. But it seems possible to use autoconf even on Win32, along with cygwin32 tools. Perhaps some ATL-like dependency will prevent it, but it should be given a fair shot.