Mozilla Bug Week
Monday October 22nd, 2001
Many of you are familiar with the Bug Day's that we started a few years ago. Well, with the number of people wanting to help out skyrocketing these last few months, firstname.lastname@example.org and others have decided that a bug week was in order. They'll be running it from Saturday October 27th to Sunday November 4th, and they'll have plenty of smart people on hand to help folks learn the bug system, learn how to use the various other web tools, and of course, learn some tips on how to contribute code to the Mozilla effort. Click the Full Article link to get all the details.
#17 It's the autonomy, stupid!
Wednesday October 24th, 2001 7:03 AM
You are replying to this message
Roblimo certainly gets some details wrong in that article <http://www.newsforge.com/…e.pl?sid=01/10/20/1841215> . his description of volunteer Mozilla contributors as people working `for free' for Netscape is as silly as describing any Linux kernel hacker as someone working `for free' for Red Hat, or any BSD hacker as someone working `for free' for Apple. He understates the impact of the initial Mozilla code release being basically unusable, and of the 1999 decision to rewrite Mozilla from scratch. And he has his dates wrong, implying that Netscape was already an AOL subsidiary by the time the Mozilla code was released. However, his main complaint -- the lack of autonomy of those running the Mozilla Project -- is definitely valid, and I think that lack of independence is the main reason for the failure of the project thus far.
Lest I be accused of trolling, I hurry to note that by `failure' I don't mean the complete death of Mozilla through being unable to forestall Microsoft's hegemony on the Web such that the DOM, CSS, and eventually HTML and HTTP become Microsoft-only closed standards which are prohibitively difficult to keep up with. (That might be true, but it will take another five years or so before we can tell. The most important bugs filed in Bugzilla currently aren't the crasher bugs, or the performance bugs, or the API freeze bugs, or even the user interface bugs; they're the Tech Evangelism bugs.) By `failure' I mean that after three and a half years, the Mozilla browser is roughly equivalent in quality to Microsoft's Internet Explorer 4.0 browser, which was released just over four years ago. (Mozilla is way ahead on standards compliance and number of supported platforms, which most users don't care about; and it's way behind on performance and user interface quality, which most users do care about.) To be sure, Mozilla may be catching up in many respects, but it may not be catching up fast enough to make a difference.
The lack of an independent Mozilla Foundation or similar <http://foundation.gnome.org/> , with a basic constitution <http://www.debian.org/devel/constitution> and a clear goal (e.g. `to build the best and most widely-ported Web browser in the world'), has (directly or indirectly) caused a number of systemic problems in Mozilla development. A few examples.
* The Mozilla Organization is funded largely by a single Mozilla distributor, one which currently does not add very much closed-source value to Mozilla, with the result that the Mozilla Organization has to tread lightly to avoid the appearance of competition with that distributor. Instead of being honest about this, Mozilla staff have created a `Mozilla is not for end users' meme, backed up by incorrect claims that an open-source user community is incapable of providing its own marketing <http://linux.com/> or technical support <http://www.debian.org/support> . By itself, I wouldn't mind any of that -- *except* that `Mozilla is not for end users' has become an excuse to have a Heath-Robinson-style user interface, something which no Mozilla distributors have the skills and resources to fix in their own versions. So Mozilla distributions languish for lack of usability.
* For the same reason of avoiding competition, the mission of the Mozilla Organization is not to `coordinate the development of a great Web browser', but (rather hand-wavingly) to `act as the virtual meeting place for the Mozilla code' <http://mozilla.org/mission.html> . This provides leeway for the Mozilla CVS trunk to host distractions such as IRC clients and Web page editors -- and yes, I *do* think that if those weren't in the Mozilla trunk then the other parts of Mozilla would develop more quickly.
* Mozilla's bug database system is modelled on the previous Netscape bug database, so it was inadvertently designed with closed-source development assumptions built in. The idea of default assignees and QA contacts for components, for example, makes sense when one person is paid to fix/verify all the bugs in a given component --- but it is harmful if trying to attract volunteer contributors. <http://groups.google.com/…0student.canterbury.ac.nz> In addition, many new contributors are under the impression that all they have to do is attach a patch to the bug report, when the Mozilla Project actually puts much greater demands on them than that; again, this would be much less of a problem if Mozilla was closed-source and programmers were being paid to get their patches checked in.
I'm sure this situation will get better over time, that these problems are just the growing pains of a community struggling towards independence. But currently, the Mozilla Project is of most use for an example of how not to run an open-source project, secondly for its bug database software, and thirdly for its Web browser.