Is Mozilla Falling Apart?
Major Morphing in Mozilla Project Organization and Objectives Proposed
Part 1: Mozilla Management Reorganization and Splitting the Browser-Suite into Stand-Alone Products
Mike Angelo -- 12 April 2003 (c)
For the most part, there is nothing all that new in this Roadmap adjustment. The 2 April 2003 Mozilla Roadmap is more a reflection of the direction in which the Mozilla Project already has moved in respect to the products it is developing and the priorities assigned to Mozilla products. Once again, the Mozilla Roadmap and development plan is following what the Mozilla developers already are doing rather than leading Mozilla development.
The faux-egalitarian model of CVS access and pan-tree hacking that evolved from the earliest days of Mozilla is coming to an end . . . there is no substitute for leadership by an "application czar". (Mozilla Development Roadmap, Brendan Eich and David Hyatt, 2 April 2003. Link in Resources section on page 3.)
Proposed Objectives and Changes
Some underlying objectives of the 2 April 2003 Roadmap proposal are to clean up code-architecture, simplify the code-base, get rid of bugs, and improve overall quality. Under the new Roadmap proposal these objectives would take precedence over adding new features. The . . . new roadmap . . . comes down to preferring quality over quantity. We must do less, but better . . . (Mozilla Development Roadmap, Brendan Eich and David Hyatt, 2 April 2003) Sounds good!
If the proposed Mozilla Roadmap changes are put into effect, it appears that the focus of Mozilla development will shift from the current Mozilla browser-suite development to a collection of independent Internet-related applications; (1) Phoenix, a stand-alone Web browser, (2) Minotaur/Thunder-bird, a stand alone e-mail and news client, and (3) Gecko, the layout engine that underlies the Mozilla Web-browser suite, Phoenix, and Minotaur -- plus XUL and the Mozilla Applications Programming Framework (APF).
This roadmap is a proposal. We are pointing in a direction toward which we think the Mozilla project should move. (Ibid.)
Some of the proposed changes could make the resulting Mozilla Project products more competitive with KDE's Konqueror browser/file-manager and the KMail e-mail client for the GNU/Linux operating systems and with Microsoft's Internet Explorer browser and Outlook e-mail client for the Windows operating systems -- also Safari, a KHTML-based Web browser for the Mac.
Mozilla v Internet Explorer, Konqueror, and Safari
Microsoft's Internet Explorer (IE) kicked the Netscape/Mozilla browsers off the MS Windows desktop a long time ago -- in computer time. It will be interesting to see if the proposed Mozilla Project changes increase Mozilla Project browsers usage on the MS Windows desktop.
Meanwhile, now that the KDE Konqueror Web-browser has tabbed-browsing, Konqueror easily could replace the Mozilla browser on the Linux desktop. Up to the incorporation of tabbed-browsing in the Mozilla browser, the choice between Konqueror and Mozilla was pretty much of a toss-up and the major Linux distributions included both browsers. Although, Mozilla's tabbed-browsing perhaps did give the Mozilla browser a slight edge over the Konqueror browser. Now that Konqueror has tabbed-browsing too, Mozilla has lost that edge.
Konqueror appears to be a cleaner, more solid, more stable, and better-developed product than does the Mozilla browser. Additionally, Konqueror is well integrated into the K Desktop Environment (KDE). The same Konqueror user interface, layout engine, and underlying architecture provide well-integrated Web browsing, file management, and FTP services. Additionally the Konqueror browser/file-manager's Universal Viewer easily can display not only HTML and XML files, it also can display text (.txt), RTF (.rtf), and other such text-based documents plus a nice assortment of graphic file formats.
It's not just the Konqueror user interface (UI) that is better than the Mozilla browser. The KDE/Konqueror layout engine, KHTML, seems to be better than the Mozilla Gecko layout engine. KHTML is simple, clean, efficient, and stable. One cannot honestly make such a statement for Mozilla's Gecko engine. However, if the Mozilla community accepts the 2 April 2003 Roadmap proposal, and carries through on the plan, then Gecko might become simple, clean, efficient, and stable too.
In the end, khtml's code is a lot simpler. Perhaps more importantly, the code looks a lot more like a description of the way the layout process works. After hearing a short explanation of what's what, I can understand some of khtml's code almost as well as the equivalent code in Mozilla.
How can Mozilla get from here to there? We need to concentrate on architectural cleanup rather than adding new features. (David Baron's weblog, 23 January 2003. Link in the Resources section at the end of this article. David Baron is a Mozilla Project manager (driver), is a Mozilla hacker, and was a student at Harvard University until February 2003.)
Reduction in Developer and Infrastructure Resources
There have been indications for some time now that AOL has pulled people and resources off the Mozilla Project. Clues to that also appear in the proposed Mozilla Roadmap changes document:
Along the way, of course, Mozilla has received very generous support from Netscape, mainly in the form of paid contributors and infrastructure. (Mozilla Development Roadmap, Brendan Eich and David Hyatt, 2 April 2003)
However, it's not clear that we will have all the tinderbox and other resources needed to keep two different toolkit-based browser applications well-tested. (Ibid, Emphasis added.)
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. (Ibid, Emphasis added.)