Part 2 Article Index (coming soon)
|
Summary and Conclusions
In its five years, the Mozilla Organization has cranked out lots of code and built a browser suite with lots of neat features. The lion's share of code development and contribution came from paid coders and developers -- particularly AOL-Netscape employees.
Things appear to be changing, however. Now it seems that AOL-Netscape has been reducing its labor and infrastructure contributions to the Mozilla Organization and Project. That could mean an even greater role for, and reliance upon, independent, volunteer coders and programmers for Mozilla Projects development.
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.
The proposed Mozilla Roadmap changes are a recognition of problems and the need to address problems of a bloated and buggy Mozilla code-base and what now has become a fragmented and unfocused Mozilla development community -- in part reflected in the development of the integrated Mozilla browser suite by part of the Mozilla community plus the development of the Phoenix and Minotaur stand-alone browser and e-mail client by other parts of the Mozilla community.
Likely, the most important articulation in the 2 April 2003 Mozilla
Roadmap changes document is the recognition by Mozilla Organization management that Mozilla is not working well and that it needs some major changes. An important component of that articulation is the recognition and admission that the Mozilla code-base is too complex, too unwieldy, too bloated, and too buggy.
Before one can solve problems, one must first recognize and admit the problems. It is rather apparent from the 2 April 2003 Mozilla
Roadmap document that the Mozilla Organization recognizes the problems.
The reasoning behind these new roadmap elements comes down
to preferring quality over quantity. We must do less, but
better . . . (Mozilla Development Roadmap, Brendan Eich and David Hyatt, 2 April 2003. 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.)
However, this is not the first time that Mozilla Organization Chief Technical Officer, Brendan Eich, has called for increased quality and a slowdown on adding new features.
As part of the October 2001 changes to the Mozilla Development Roadmap, Brendan Eich, revised his Mozilla 1.0 Definition in an effort and attempt to bring Mozilla's escalating bug problems and schedule slippage under control.
Inter alia, Eich's Manifesto called for a feature freeze
and a focused effort to get the Mozilla bug problems under control
-- a good project management move. However, in less than a week
from the posting of Brendan Eich's Mozilla 1.0 Manifesto, the lizards decided to add a calendar-module and other new features to the Mozilla browser-suite code-base.
Table 1 and Figure 1 show that after
Eich called for a feature freeze and increased quality in his
October 2001 Manifesto, Mozilla bugginess continued to increase. In October 2001, there were 8,819 open, targeted bug reports in Bugzilla, the Mozilla bug-tracking database. There also were 18, 857 open new, assigned, and reopened bugs reports listed in Bugzilla.
At the time the latest major Mozilla browser suite edition, Mozilla 1.3, was released on 13 March 2003, there were 12,244 open, targeted bug reports in Bugzilla, and 30,575 open new, assigned, and reopened bugs reports listed in Bugzilla. That's an increase in 3,425 open targeted-bugs from the date of Eich's October 2001 Manifesto to March 2003 and an increase of 11,988 open new, assigned, and reopened bugs reports during that same period.
Please keep in mind that the bugs data is a dynamic sort of thing. Some bugs are being fixed and/or resolved while new bugs are being entered into the Bugzilla database. The above bug report count figures are for open/not-fixed/not-resolved bug reports listed in the Bugzilla bug-tracking database on the specified dates. The meaning of bug counts and how to interpret bug counts is beyond the scope of this article. We have treated that elsewhere.
The point here is that there are many more open bugs listed in Bugzilla now then there were about seventeen-months ago when Brendan Eich last called for more quality (less bugginess) and fewer feature additions in his October 2001 Manifesto. The Mozilla community did not do a very good job of cooperating with Eich's call for better quality then -- will it follow Eich's current call for better quality and fewer feature additions now?
Time will tell, although Lizard history suggests not. Unfortunately, the Mozilla folks cannot even learn from their own mistakes. For more about that please see an excellent article, Learning from Mozilla's mistakes, by Robin "Roblimo" Miller on NewsForge.com. (Link in the Resources section at the end of this article.)
Eich and Hyatt's 2 April 2003 Mozilla Roadmap document
is a good start to getting the Mozilla Project and Mozilla products
development on the right track. Problems are identified and discussed.
The regular restatement that quality is more important
than quantity is well-placed in this document.
If anything, Eich's and Hyatt's 2 April 2003 Mozilla Roadmap does not cut deep enough. But at least it is a good start, again, at trying to bring the Mozilla Project and Mozilla products development in focus and under control.
The big question is whether the Lizard-Landers can and will change their spots and accept the guidance that Brendan Eich and David Hyatt are trying to provide. Stay tuned, this certainly is far from a finished story.
