[ The opinions expressed by authors on Linux Today are their
own. They speak only for themselves and not for Linux Today. -lt ed
]
By Mike Cornall
This is in response to Monty Manley’s column,
“What went wrong with Mozilla?”
Mr. Manley seems to have collected together, into a single
column, every misconception currently being spread about Mozilla.
That helps me, because it makes it easy to respond to, and refute
those misconceptions.
So, without further delay, I will review Mr. Manley’s essay,
point by point . . .
> “Perfection (in design) is achieved not when there
is nothing more to add, but rather when there is nothing more to
take away.” — Antoine de Saint-Exupery
I’ve always liked that quote, and it’s important for any artist
or systems developer to keep it in mind.
But, as to Mr. Manley’s claim that the Mozilla team has wasted
time adding unnecessary frills, his arguments are unconvincing, and
he fails to back it up with evidence. Examples cited by Mr. Manley,
such as e-mail and XUL, are not frills.
> If at some point in the future a seminar is ever
given on how *not* to conduct a large-scale Open Source software
project, Mozilla would make a dandy example.
Nonsense. The Mozilla team has built a huge (in terms
of function and scope) product in a very short time.
The initial team knew what they had to do. They started with a
clean-up of the code. They put an organization, procedures, and
tools, in place, to allow a large number of developers to work in
parallel. They started with corporate funding, but kept the project
open, so that there are now more Mozilla developers outside of AOL,
than inside. And they weren’t afraid to take radical steps, when
necessary.
I wouldn’t be surprised if a future seminar points to Mozilla as
a good example of how to run an Open Source project.
> A long series of lamentable mistakes, most of them
avoidable, have caused the Mozilla project to languish unfinished
for more than a year beyond its projected release
date.
There has been only one major error, which was the initial
decision to try to preserve the original Netscape code. That
attempt cost the better part of a year, and ended in failure. But,
to the credit of AOL and the Mozilla team, they didn’t quit.
Instead, they took the bold step of starting over with fresh code,
in effect, committing to a rewrite of Netscape from scratch.
Thus, the problem was recognized and resolved, and a lesson was
learned (or learned again, i.e. that upgrading old code often takes
longer than a rewrite). That was a costly miscalculation, but it
was hardly a “series of lamentable mistakes”, and it may not have
been as easy to avoid as hindsight might suggest.
Thus, Mozilla started over, approximately a year and one-half
ago, with new targets. If we were to accept Mr. Manley’s contention
that Mozilla is now “more than a year beyond its projected release
date”, then we would have to believe that they planned to rewrite
Netscape in just six months, which is ridiculous.
> Had Mozilla simply tasked itself with writing the
best, standards-compliant browser on the market, all would have
been well.
|
I wouldn’t be surprised
if a future seminar points to Mozilla as a good example of how to run an Open Source project. |
Only if your definition of “well” is extremely short-sighted. It’s
true that the Mozilla team could have finished sooner by producing
a simple browser for a limited set of platforms (say Windows and
Linux), using native widget sets. But if they had done so, then
that’s all that they would have.
Fortunately, the Mozilla team was not so short-sighted. At each
turn, the Mozilla team asked an important question: Is it better to
build this function, or is it better to build a general tool to
provide this function?
Because of the Mozilla team’s bold decisions, we now have:
- A highly cross-platform browser, which is already being ported
to most major platforms. - The Gecko page renderer, which has already been picked up and
used in other products. - The XUL dynamic user-interface builder, which has already been
used in other products. - The Bugzilla bug tracking system, which has already been used
by other projects. - A cross-platform widget set, which allows for easy porting to
other platforms, and is an attraction in itself for new platforms
such as the Sony PlayStation. - The most standards-compliant browser available, including
support for newer standards not yet addressed by IE. - A more powerful e-mail product, to help attract corporate
Outlook users to Linux (though Outlook has recently been doing a
good job of that all by itself). - A much more powerful basic HTML editor, including a show-codes
mode. - Many new browser features, including a fully customizable user
interface.
If the Mozilla team had followed Mr. Manley’s advice, then IE
really would have ended up dominating the Internet, because Mozilla
would not be ready to compete in the area of dynamic content. As it
stands, Mozilla is on track to being a cross-platform powerhouse,
which can not only compete in its own right, but will energize the
next generation of Internet appliances.
> Gecko, the rendering engine used by Mozilla, has
been in fine working shape for nearly a year.
And anyone who wants to use Gecko to create a simple browser can
do so. In fact, more than one group is doing so, for
example, the Galeon browser.
> But at some point, the Mozilla team fell prey to
the idea that it had to be a *platform*; it had to provide its own
GUI, scripting language, mail/news client, Java support, on and on
and on. Furthermore, it was to be pervasively multiplatform — it
should build on Macs, PCs, Linux boxes, Solaris,
whatever.
First of all, multiplatform support was not a whim — it was a
major part of the original Netscape, and was a mandatory
requirement for the new Mozilla. Likewise for the mail and news
clients.
Second, the Mozilla team did not build Java support, rather,
they wisely included a Java interface, so that any Java VM can be
plugged into Netscape.
Third, the GUI (widget set), and scripting language (XUL),
greatly simplified the job of making Mozilla cross-platform, while
at the same time providing useful tools for other Open Source
projects.
> And it had to do this in the face of a huge
corporate restructuring and the defections of several key
developers.
The only “huge corporate restructuring”, of which I am aware,
took place among the administrative staff of Netscape, after
merging with AOL, and did not affect the developers.
I am also only aware of one defection of a key developer. There
may have been others, but so what? There will always be
disagreements among individuals regarding project direction. What
matters is that the Mozilla project has successfully carried
on.
> Anyone with a software engineering background can
see that this is a recipe for disaster.
And yet there has been no disaster, which is not surprising,
since the situation was not as Mr. Manley described.
> The phenomenon is known as “feature creep”, and it
devils software projects both small and large. Mozilla is a
textbook case.
The Mozilla project has had a series of objectives, and has been
quite hard-nosed about sticking to them. I’m not aware of
significant “feature creep”. But, of course, Mr. Manley considers
cross-platform support, and XUL to be “feature creep”. I will
repeat: cross-platform support was a mandatory requirement, and XUL
was a good case of building a tool to do the job, rather than
blindly jumping in with brute force coding.
> Longtime Unix users remember Netscape Navigator 3.0
with much fondness — some liked it so much they use it still. It
was lean, it was fast, and it was stable as a rock. It was
standards-compliant.
Mr. Manley again either doesn’t know the history, or is
mischaracterizing it.
The code underlying Netscape Navigator 3.0 was already a mess.
The original Netscape was basically thrown together as fast as
possible. The original developers stated that it was their intent,
from the beginning, to rewrite the code, but they never found the
time to do it.
It’s true that Navigator was quite stable, at least at first.
But many will remember that once Microsoft started pushing IE, many
web pages started including HTML or Javascript that caused
Navigator to crash. It became a race to keep Navigator upgraded,
and following each upgrade, one would usually have a few months
before new crashes started occurring. Strangely, the new crashes
seemed to start some time after the next release of Frontpage, but
I’m sure it was just a coincidence.
It’s also true that Navigator was standards-compliant, since in
those days, what Netscape implemented was the standard.
But those were much simpler standards, and times have changed.
> How this wonderful program turned into the botch
that was Navigator/Communicator 4.0 is a by-now familiar story —
Netscape got lazy and lost their edge.
This, again, is a mischaracterization of what happened.
Netscape got into a standards race with Microsoft. Meanwhile,
however, Microsoft started giving away IE for free, then tied it to
Windows, then signed agreements with the OEMs that forbade them to
pre-install Navigator/Communicator on their PCs (as documented in
the DOJ case). Thus Netscape found itself with the need to add a
lot of functionality quickly, using the old, hard-to-maintain
Navigator code, but without any funding.
The result was that Netscape was forced to sell out to AOL. The
good news was that, in the process, Navigator/Communicator was
released as Open Source.
> They crammed a lot of terrible code into the
browser, bloated it beyond belief, and made it the crash-prone joke
that it is today.
I keep reading this claim, but it does not match with my own
experience.
I ran Communicator 4.0, on Windows NT 4.0, and it was fairly
stable. Yes, it would crash once every few weeks, but the
alternative at the time, IE 4.0, used to crash multiple times a
day, sometimes taking NT with it. Mind you, I did take certain
steps to keep Communicator stable, which included turning off Java,
shutting down Communicator at the end of each day (to release
leaked memory), and avoiding ZDNet pages (whose Javascript seemed
to cause serious memory leaks for Netscape).
I agree that Communicator is bloated, but it’s not nearly as bad
as, say, MS Office. For example, in my NT days, the surest way I
knew to slow my PC to a crawl, and crash NT, was to embed Excel
charts in a Word document, then try to adjust them. Apparently,
128MB of memory wasn’t enough to do the job.
Later on, when I started using Communicator on Linux, I again
ran into some problems (especially with Communicator 4.61), but
still not serious (as long as I kept an eye on its memory usage).
Now, I’m using Communicator 4.73, which seems to be quite a bit
better, and hasn’t crashed yet. I would also like to point out that
neither Communicator, nor any other program, has ever crashed Linux
on me.
I still run Communicator with Java turned off, which seems to be
the most important stability factor. But that shouldn’t surprise
us, since, as we all know, Netscape gave up on trying to perfect
their Java VM, in favour of letting users plug in their own
preferred VM for each platform.
Finally, if Communicator is such a joke, why do between 15% and
30% of Windows users still insist on running it? Wouldn’t it be
much easier to simply accept IE (which is already loaded into
memory as part of Windows)? Given Microsoft’s recent security
problems, I would suggest that most users consider IE to be a
joke.
> Even Netscape realized this (too late), which is
why they embarked on a project to rewrite the browser from the
ground up. The Mozilla project lost most of the first year of its
existence to a direction-change; it was decided to “componentize”
the browser. While this was eventually achieved, a lot of the code
produced until that point had to be thrown out.
Ah, so Mr. Manley does know some of the history, and yet, he
still gets it wrong, or mischaracterizes it.
The Mozilla project did not start out to “rewrite the
browser from the ground up”, rather, they started out to rework the
existing code, which is just the sort of pragmatic approach that
Mr. Manley recommends. But that approach didn’t work (because the
code was in such bad shape), and after almost a year, they decided
that they needed a new approach. It was at that point that they
started over with what was essentially a rewrite.
> More developer time and effort wasted.
It wasn’t more time wasted. It was the only
major case of time wasted.
> But the other pieces of software — the mail/news
client, the XUL-driven “shell”, the editor, and so on — have
sucked up developer effort at a ferocious rate.
As previously stated, the mail/news client is an essential
deliverable (or else Netscape 6.0 would not be able to act as a
replacement for Communicator), and XUL has probably saved more time
than it cost to build, while providing many additional benefits
such as branding (allowing ISPs to customize the appearance of
Netscape).
> The current iteration of the browser, (M16 as I
write this) is just as crash-prone and slow as the browser it is
intended to replace!
This, more than anything else, appears to be intentional
FUD.
If anything, M16 should be more crash-prone, and
slower than the browser it is intended to replace. Why?
Because M16 is development software! It hasn’t even
reached alpha-stage yet. Surely Mr. Manley knows that.
> It seems obvious that the Mozilla crew bit off far
more than they could chew, but I think a deeper problem is that the
development team reached too far.
The Mozilla team was ambitious, and in light of the way
their product is coming together, and being adopted by other
products and platforms, it appears that their ambition has paid
off.
> They are trying to re-invent an entire *platform*
when all most people want is a good browser that doesn’t
crash.
As previously stated, a “good browser that doesn’t crash”
wouldn’t have been enough. If they had done only that, then they
might as well have done nothing, because then there would be no
Internet appliance revolution, and Microsoft might have ended up
controlling Internet protocols.
> Mozilla is full of neato technology that half-works
or doesn’t work at all, and does it all v-e-r-y
s-l-o-w-l-y.
Let me repeat: Mozilla is still d-e-v-e-l-o-p-m-e-n-t
s-o-f-t-w-a-r-e.
> I think most would agree that Microsoft “won” the
browser war.
I don’t agree at all. Within two years:
- 10% or more of desktop users will be running Linux.
- 10% or more of Internet users will be using an Internet
appliance or game console (probably running Mozilla). - 10% or more of Internet users will be AOL (former IE) users
running Netscape. - 10% or more of Internet users will be existing Windows Netscape
users who held out for Mozilla.
Thus, in two years, IE’s percentage of the browser market will
be down to 60%, and still dropping. A business would be very
foolish to standardize on IE-only Internet protocols, because it
will cause them to lose a lot of clients.
> Nearly every Windows and Mac user has switched to
IE, and most Unix/Linux users would too if only it were available
on their platform.
But IE is available for Unix. Unfortunately, Microsoft
followed Mr. Manley’s pragmatic, quick-and-dirty approach when
porting IE to Unix, and the result is a bloated mess that nobody
uses.
> Mozilla may (eventually) be finished, but it is
increasingly unlikely that it will be relevant to anyone except
Linux users.
After the initial false start, the Mozilla team will have
rewritten the browser in less than two years. And if that isn’t
amazing enough, they will have produced the world’s most
standards-compliant browser, and it will include revolutionary
features that allow it to become a true web-application platform
(something Microsoft has only talked about).
Also, through its cross-platform support, Mozilla will
revolutionize the Internet appliance industry.
I call that relevant.
> Mozilla has squandered a lot of goodwill and user
perseverance over the past two years.
Nonsense — Mozilla hasn’t squandered a thing. The development
has taken the required amount of time. Forces friendly to
Microsoft, however, have certainly used that time to try to
undermine Mozilla’s reputation.
Anyone who has experimented with the major milestones can see
how much progress has been made (say, between M14 and M16), yet
these milestones are only months apart. It’s clear that Mozilla
development is proceeding at a brisk pace.
To the Mozilla developers, I say, “Carry on — you’re doing a
fine job.” And to Netscape, for releasing the source, and to AOL,
for funding the project, I say, “Thank-you.”