Browsers, Mozilla, Netscape, KDE Konqueror, Linux: MozillaQuest Magazine - Morphing in Mozilla Project Organization and Objectives Proposed - Part 1 Mozilla Management Reorganization and Splitting the Browser-Suite into Stand-Alone Products -Page 2

Getting Started with Wireless Network Technology

MozillaQuest the on-line computer magazine

April 12, 2003

Digital Photography

Graphics

Multimedia

Web Page Design

Web Tools

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) -- Page 2

Part 1 Article Index

Proposed Objectives and Changes

Mozilla v Internet Explorer, Konqueror, and Safari

Reduction in Developer and Infrastructure Resources

Responding to Realities -- It's Time for Leaner, Meaner, and Cleaner Mozilla Products and Code-Bases

Mozilla Roadmap Changes and the Linux Community

Summary and Conclusions

Resources

Part 2 Article Index (coming soon)

Definitions

Baroque: Feature-encrusted; complex; gaudy; verging on excessive. Said of hardware or (especially) software designs, this has many of the connotations of elephantine or monstrosity . . . (Free On-Line Dictionay of Computing (FOLDOC) Link in Resources section at the end of this article.)

Elephantine: Used of programs or systems that are both conspicuous hogs (owing perhaps to poor design founded on brute force and ignorance) and exceedingly hairy in source form. An elephantine program may be functional and even friendly, but (as in the old joke about being in bed with an elephant) it's tough to have around all the same (and, like a pachyderm, difficult to maintain). (Ibid.)

Hog: Favoured term to describe programs or hardware that seem to eat far more than their share of a system's resources, especially those which noticeably degrade interactive response. (Ibid.)

Responding to Realities -- It's Time for Leaner, Meaner, and Cleaner Mozilla Products and Code-Bases

In part the proposed Mozilla Roadmap revisions appear to address problems of creeping complexity, bloat, and bugginess in the Mozilla code-base -- and a reduction in the number of full-time developers working on the Mozilla project.

The reasoning behind these new roadmap elements comes down to preferring quality over quantity. We must do less, but better . . . (Ibid, Emphasis added.)

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. (Ibid, Emphasis added.)

Gecko also suffered from over-reach . . . parts of Gecko are still baroque due to early design limitations and an accumulation of code to patch around core problems. (Ibid, Emphasis added. Please see Definitions in sidebar.)

The April 2003 Mozilla Roadmap changes also seem to be Lizard-Land history repeating itself. Five years ago, Netscape Communications Corporation open-sourced its Netscape Communicator code-base, put that code-base in the public domain, and set up the Mozilla Organization to shepherd the Mozilla Project -- including further development of the Netscape Communicator code. Shortly after that, the Mozilla organization threw out the Netscape code -- claiming it was too bloated and too unwieldy with which to work.

Then over the next few years, the Mozilla organization went about building an all-new code-base -- that likely now is even more bloated and unwieldy than the original code-base the Mozilla Organization threw out in 1998. Thus, as before, the Mozilla Organization appears to be on the verge of throwing-out at least some of the work involving more than a thousand people-years because, just as four-years ago, the existing code-base is too bloated and too unwieldy with which to work.

This might be the only way to solve the overwhelming, complexity, bloat, and bugs problems now extant in the Mozilla code-base. Nevertheless it is a shame that things have come down to discarding the Mozilla browser-suite as it exits now. Yet, it is something that should have been done several years ago. Of course, had the Mozilla Organization brought the code bloat, performance, and bugs problems under control several years ago, which they did not, then there would not now be, nor have been then, a need to discard the Mozilla browser suite.

The proposed Roadmap changes do not call for throwing code out, per se. And the proposed changes even seem to suggest that will not happen. For example, consider:

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. (Mozilla Development Roadmap, Brendan Eich and David Hyatt, 2 April 2003)

But, on the other hand:

. . . it is quite possible that the XPFE-based browser [XPFE = cross-platform front end] may bit-rot fairly quickly, so that the 1.4 branch contains its only working form. (Ibid.)

Mozilla Roadmap Changes and the Linux Community

The 2 April 2003 proposed Mozilla Roadmap changes appear in part to be aimed at addressing the realities of AOL-Netscape pulling some, if not many, of its employees off Mozilla Project development.

Other than AOL-Netscape, perhaps the biggest area from which the Mozilla Organization and Project has drawn moral support and development contribution is the Linux community. Two of the three major Linux distributors, Mandrake and SuSE, provide quality implementations of both the GNOME and KDE desktop suites. They use KDE as the default desktop and Konqueror as the default KDE browser. Up to now they also have been supportive of the Mozilla browser suite and they do include a Mozilla package with their distributions.

The third, Red Hat, is GNOME-centric and very supportive of the Mozilla browser suite. Red Hat Linux 8 and 9 use Mozilla as their default browser. However, Red Hat 8 and 9 include KDE's Konqueror browser and file manager too.

Now that KDE's Konqueror browser and file-manager has tabbed-browsing, that could tip the Mandrake and SuSE scales more towards supporting KDE and its Konqueror browser and file-manager and less towards supporting the Mozilla Organization and its products. However, the 2 April 2003 Roadmap changes could help the Mozilla Organization to maintain the current level of program deployment, moral support, and development contribution from Mandrake, SuSE, and other Linux distributions that it now enjoys.

Just how the 2 April 2003 Mozilla Roadmap changes might affect Mozilla product positioning in Linux distributions depends on how the implementation of these changes unfolds -- and the quality of the next round of the Mozilla products.

For example, in an e-mail discussion we asked Mandrake founder, Gaël. Duval, if Mandrake Linux would shift to the Phoenix browser or stay with the Mozilla browser? He replied:

It depends on how good these softwares are going to be. If Phoenix and Minotaur are really better than Mozilla, we can certainly shift to them. Anyway it's certainly a bit too early to give you a clear and definitive answer on this topic.

Joseph Eckert, SuSE's Vice-President for Corporate Communications, passed on these comments about the Mozilla Roadmap changes in an e-mail discussion:

For the near future we think we will distribute the next long-life tree (Mozilla 1.4.x) in the next distributions. This version will be the classic Mozilla suite.

The current truth is, that we have to switch to the new scheme as soon as it is stable enough to distribute it, because we don't have the resources to maintain "our own" Mozilla suite. So we think we have to use mozilla.org's solution in the future after Mozilla 1.4.

Maintaining the classical Mozilla instead of swapping to Phoenix/Minotaur would increase our maintenance and development costs. Moreover, the Mozilla community will probably focus on Phoenix/Minotaur and will stop or slow down the development of new features/bugfixes for Mozilla, so we would loose that Mozilla community manpower.

Currently, I don't know any software we distribute which depends only on Mozilla. Other third party vendors are usually supporting IE or Netscape, but not Mozilla, like the Lotus Notes client (browser version) coming soon. So we don't risk losing support for that software.

Last but not least, having a browser and mailer separately allows us to provide just a browser where we need just a browser and not a browser+mail solution, e.g. for the SLEC [SuSE Linux Enterprise Client], where we have KMail and therefore only need the browser functionality of Mozilla.

So we would switch to Phoenix and Minotaur as soon as the software has proven to be stable.

Where major players such as IBM and Sun throw their moral and development support can have major impacts. A case in point is the current legal flap between SCO-Caldera and IBM over IBM's tremendous support of the GNU/Linux operating system. SCO-Caldera's perception of such support is that IBM's contributions to GNU/Linux are so powerful as to effectively kill Unix as a server/enterprise grade operating system.

IBM and Sun also are strong moral supporters and development contributors to the Mozilla Organization and Mozilla Project. However, both IBM and Sun seem to be shifting from Unix-centric to Linux-centric development and marketing. If IBM and/or Sun should shift from Mozilla browser-suite deployment to the currently superior KDE Konqueror browser/file-manger and KMail products, that could further reduce moral and development support for Mozilla. The proposed 2 April 2003 Mozilla Roadmap changes could be important to Mozilla software products maintaining a presence in IBM's and Sun's Linux deployments.

<---- Back to Page 1

Continued on Page 3 ----->