MozillaZine

Full Article Attached 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, gerv@mozilla.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.


#14 Re: Newsforge - Learning from Mozilla's Mistakes

by macpeep

Wednesday October 24th, 2001 2:03 AM

You are replying to this message

I'm surprised this hasn't generated more response yet.. Anyway, I'll bite. :)

First I'll give some background so we can perhaps avoid all the mud slinging that usually takes place. I'm a software developer myself with relatively long experience. I work for a company in Finland that makes a 3D game engine for handheld devices (PDA's, 3G & 4G mobile phones & dedicated game devices and similar). The game engine is cross platform in very much the same way that Mozilla is - there's an underlaying framework that abstracts the hardware and CPU.

There are many things similar with Mozilla and the product I work on for a living. Both are large scale, cross platform apps where performance is absolutely crucial. The approaches to these are very different however. Mozilla has a large developer base (even in the "internal" Netscape developers) and an even larger "feedback" base. Thousands of people test and report bugs and about as many people have loud voices regarding what they love and hate about Mozilla. The product at work has a developer base of about 20 developers of which some work on tools. It's a very classic closed source development project that adapt the "extreme programming" ideas with strict guidelines for milestones, testing, schedules etc. Mozilla does a lot of this in the same way, but there is one very obvious difference.

The thing Mozilla lacks or has been lacking is a clear target to shoot for. If you're an athlete, you usually set a goal.. "I will run 100 meters in under 10 seconds at the Olympics in XXXX in the year 20XX." With a clear goal, you can then lay out milestones on the route to this goal and measure your performance and compare it to how you should be performing. If you're just going with "I'll just try to run a lot every day and do the best I can.", chances are that you're not going to be that sucessful. Schedules and measurable performance is everything. I'm using the word "performance" here in the meaning of "progress".

I don't think there's anything wrong with open source in itself. I believe that the current problems are more or less because of Mozilla's development process, not open source. I believe that what's missing is the guts to define a bold target (3 years ago) and then go for that and not stray off the target. Now everyone is being a captain and everyone is steering in different directions. While some say "1.0 is needed" and write documents about why it's needed, others say "you're being silly. 1.0 is just a number. let's call it 1.0 now and be over with it". Without a person at the helm (like Linus Torvalds for example), it's very hard to get a coherent strategy and goal for the project. JWZ was that person in many ways. While he hadn't set a public 1.0 goal for one year after the initial release, that was clearly his personal goal and he left as a result of not being able to make that goal. Mozilla today is slowly improving but is very far behind the implicit schedules that people (end users, web developers and fans) expected. That wouldn't be so bad if we weren't also so far behind the performance (speed, size, stabilty, quality, market share etc.) that the same people expected and expect.

The "1.0" document by Brendan Eich is a good start, I think. We need a date and a set of features and performance metrics to shoot for. We need to be aware that all of these may not be met, but we need to list them and write them down and then start working towards them. The date can't be pushed around forever because what happens then is what has been happening in the past couple of years: developers lose hope, the product loses market share (product being "Netscape & Mozilla" - you know what I mean) and the project loses credibility.

If this insults someone, developers in particular, I'm sorry. That's not my intention. I see problems with the project, as I've done for a long time. I want to see those problems fixed. I have absolutely no interest in just plain and simple diss Mozilla. I don't believe anyone on this site has. It's clear that people experience Mozilla in different ways, however, but that can be a strength.