Re: Bloatware and the 80/20 Myth (was some unrelated subject)

[Havoc Pennington <hp redhat com>]

"Marco" <m fioretti inwind it> writes: 
> Oh, and I forgot to said that many of the reasons used in the article
> to justify bloat are perfectly valid.... for commercial closed software.
> 
> Release dates, market windows.... We are the one supposed to "release
> when it's good and ready, and the hell with deadlines", right? Or not?
> 

It doesn't really work that way, because many open source developers are
still motivated by the same basic thing as commercial developers -
they want to have lots of users. If you're writing software you want
to be really useful, as an altruistic thing or for ego boost or
whatever your motive, then you want a lot of users. Especially in
areas where there's tight competition (see GNOME/KDE).

And the fact is that you will get far more users with more features
than you will with "hey, we have no features, but dangit the code is
small." 

You just can't get users with this feature matrix:

                  You      Them
 small size        x 
 Whiz-bang                   x
 Gee-whiz                    x
 Cool-as-hell                x
 Dang-neat                   x

Won't happen. That's how the system is set up.

I agree that there's a segment of users - users with less money, users
creating embedded devices - that considers small size a must-have
feature. However, there are also segments of users that consider all
those other things must-have, and those users are more vocal and
numerous by far, especially in the largely technical audience of
current open source software.

So structural incentives are just set up to make small size a low
priority, even for volunteer developers.

I'm not saying no one should consider bloat an issue - my own code is
probably overoptimized on average - just that in practice, people
don't have that much incentive to, because on average/in general,
"users" do not really care about bloat as much as other stuff.
(Whatever they may say if you ask them, what they actually use shows
their real preferences.)

This is assuming bloat is within "basically usable" parameters - if a
feature is so slow that it's annoying to use, that feature gets
nullified. So e.g. if my spell checker takes a full minute to spell
check one email, I effectively don't have a spell checker. What I'm
talking about here is bloat that isn't really noticeable in the course
of using a specific feature. The kind of bloat you only _really_
notice if you run "top" or "free" or "df".

Havoc