From: rssfeeds@jmason.org  Thu Sep 26 16:33:47 2002
Return-Path: <rssfeeds@example.com>
Delivered-To: yyyy@localhost.example.com
Received: from localhost (jalapeno [127.0.0.1])
	by jmason.org (Postfix) with ESMTP id D4D9216F03
	for <jm@localhost>; Thu, 26 Sep 2002 16:33:45 +0100 (IST)
Received: from jalapeno [127.0.0.1]
	by localhost with IMAP (fetchmail-5.9.0)
	for jm@localhost (single-drop); Thu, 26 Sep 2002 16:33:45 +0100 (IST)
Received: from dogma.slashnull.org (localhost [127.0.0.1]) by
    dogma.slashnull.org (8.11.6/8.11.6) with ESMTP id g8QFRfg24223 for
    <jm@jmason.org>; Thu, 26 Sep 2002 16:27:41 +0100
Message-Id: <200209261527.g8QFRfg24223@dogma.slashnull.org>
To: yyyy@example.com
From: "hyatt@mozilla" <rssfeeds@example.com>
Subject: A Line in the Sand
Date: Thu, 26 Sep 2002 15:27:41 -0000
Content-Type: text/plain; encoding=utf-8
X-Spam-Status: No, hits=0.0 required=5.0
	tests=AWL
	version=2.50-cvs
X-Spam-Level: 

URL: http://www.mozillazine.org/weblogs/hyatt/#85443841
Date: Not supplied

Bug 22056 has to do with enabling different toolbar modes. It's a pretty basic 
browser feature that has been missing from Navigator for years. Even simplified 
browsers like Chimera have this feature. Neil did some excellent work in 22056 
and his code finally landed. It naturally spiked startup time and window time 
slightly, and so it ended up being backed out because of Mozilla's no tolerance 
policy for regressions.

While this "line in the sand" policy is in many ways a good one, I feel like it 
misses the point. There is a natural tendency when designing applications to 
add features in every new version of the software. Only rarely do you see 
features removed. With each passing version, you get more and more bloated, 
relying on faster machines and more memory to save the day. Who cares if the 
user interface is now full of 3000 menu items? You still support every last 
feature since version 1.0, so no customers can possibly be dissatisfied!

You can really only cram so many features into a product before its size 
requirements and performance requirements have to change. This is an obvious 
rule. It's like you start with an empty elevator that says "Capacity: 10 
people." The elevator stops at the first floor (version 1.0) and a bunch of 
people (features) get on. Continuing on its journey, the elevator stops at the 
second floor, and still more people get on. The elevator is now full, and it 
continues to the third floor (version 3.0). Unfortunately the elevator is full, 
but there are a bunch of people waiting at the third floor to get on. Some of 
them squeeze in anyway, past the fat person from the first floor (the Mozilla 
sidebar feature) who is taking up enough space for 3 people. Everyone wishes 
he'd get off at the third floor or even the fourth floor, but he doesn't. 
Someone (the Mozilla wallet feature) from the second floor cuts one on the way 
to the third floor, so he's useless, and everyone wishes he'd get off too. He 
doesn't though. Nobody does. People keep piling in at floor after floor, until 
eventually the elevator support cable snaps and everybody dies.

We need to forcibly eject people from the elevator. Remove the features that 
nobody wants and replace them with the features that matter. Cull out the 
features that didn't work in Mozilla 1.0 and make sure they aren't there in 
Mozilla 2.0. Make more of the features optional plugins so that geeks who want 
some of the more obscure features (and that have powerhouse machines) can go 
download them on their own. Only if we actively fight the trend towards bloat 
will we finally produce an awesome Mozilla browser.


