Mozilla Apologator
by Michael ToyThis is probably more therapeutic for me than it is useful for anyone on the net. I'm still writing because I'd like to at least be able to point people at this document than to have to keep saying the same things over and over again.
The Bug Count
The Mozilla software, as it shipped on free-source day, has many many bugs. We made the decision to release the source just as we were approaching the drive towards beta 1 of the 5.0 product, so this set of features has not yet been through the intense process of making it ready for the general public. We decided not to wait, that it was important to move over to a net-based development model as soon as possible.
Our goal was for 5.0 to be a high quality release, and it is a little disappointing that we didn't get a chance to redeem ourselves after doing 4.0, which we allowed out of the building with more bugs than we should have (but you never heard that from me.) We lose a chance for personal redemption, but the net wins, because the 5.0 that the net works on will be even more stable than we could have made it ourselves.
You may ask yourself, How did I get here?
Mozilla 1.0 was a "clean slate" project, and a serious attempt was made to design this piece of software in a way that would avoid many of the problems experienced in the development and maintenance of Mosaic. It was also developed from 0 lines of code to shipping product in seven months. These two items are somewhat in conflict. Since then we have lived under the philosophy that since the Internet universe is changing daily, the most important thing was to put technology in the hands of users as quickly as possible, and to worry about refining things later.
In the face of great pressure to ship quickly, to make it work for people, to add new features that initially seemed impossible to integrate, a strong pragmatic viewpoint took hold. If you read the code, some of it may not be pretty, but it does work.
You Are Doomed.
In order to write successful code in the Mozilla codebase, you need to:
- Write code which compiles cleanly under many different compilers.
- Write code which runs on machines with 16-bit ints and 64-bit ints.
- Be careful not to write code which opens up a killer security hole.
- Understand the async-I/O-based flow of control and turn your pretty algorithms inside out so that the rest of the browser still works while your code runs.
- Know something about several different operating systems.
- Understand code written by several hundred people, with very little documentation or support.
So you are completely doomed. But we've been doomed inside Netscape for years and it hasn't stopped us from shipping some very cool software. Don't let the fact that it is impossible stop you from doing cool stuff.