On April 3, 2003, mozilla.org announced the largest shift in their development roadmap since the decision to scrap the worn Netscape Communicator codebase and begin anew with Gecko and XPFE. The basic points are:

  1. Switch Mozilla's default browser component from the XPFE-based Navigator to the standalone Mozilla Firefox browser.
    Firefox has been shown to be significantly faster and lighter in all respects, and as development continues it continues to speed up and thin down. Its robust extension support is much more usable and versatile than Mozilla's, and it doesn't have with every possibly-useful feature built into it like Mozilla does. The interface is also simpler, partly because Firefox is only a browser and not an application suite, and partly because of the decisions of the Mozilla Firebird team, which were much freer from inertia than those which produced the Mozilla Navigator interface. The Preferences dialog especially highlights this.

  2. Develop further the standalone mail companion application to Mozilla Firefox already begun as Minotaur, but based on the new XUL toolkit used by Firefox (this variant has been codenamed Thunderbird).
    The same rationales which apply to the browser apply to the mail client. The only real difference is that while the standalone XUL browser is already feature-complete and usable, the standalone XUL mail client is in its infancy. The plan is for Thunderbird to hook into Firefox as an extension if the user desires.

  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 Firefox and Thunderbird, and working aggressively on the next two items.
    There is a perception that the year-old and static 1.0 milestone is significantly behind the times. This is bolstered by mozilla.org's own recommendation that people not committed to the 1.0 branch use 1.3 instead. A new stability point will give third party developers a chance to use all of the improvements to the Mozilla core without having to track the sometimes hazardous trunk, and frees up the Mozilla developers to make major changes.

  4. Fix crucial Gecko layout architecture bugs, paving the way for a more maintainable, performant, and extensible future.
    Many ideas were integrated into Gecko early on that have been proven to be dead ends. They have persisted because other code was built on top of it assuming many of its quirks. It is also divided up in ways that do not improve its modularity, resulting in a system that is more opaque, rather than less.

  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 Firefox.
    Mozilla is a very large project, and like other large projects a certain 'decomposition' of the development process would help to streamline things. Since I am a user and not a developer, further explanation would be better found on the Mozilla web page.

This re-architecting of the Mozilla suite will bring many changes to the project. The other parts of the SeaMonkey suite, including Composer, the Calendar, Chatzilla, and the DOM Inspector have had to find their own way through alll this. Composer and Calendar have been split into separate applications (outside the mozilla.org umbrella) as Nvu and Mozilla Sunbird, respectively, while Chatzilla has been re-released as a Mozilla Firefox extension. Mozilla Firefox itself had to be ported to Mac OS X, to replace the Mozilla suite for that system. This bold new move by the Mozilla developers should result in a lighter and more usable Mozilla application.

The Mozilla roadmap is found at http://www.mozilla.org/roadmap.html .


This writeup is released into the public domain by D.G. Roberge.