Sunday, April 27, 2008

Software Bloat

Although a belated response, this is an attempt to respond to some of the ideas presented in this newsgroup message, and a few other ideas hinted at in subsequent postings, as well as not publicly espoused.

One of the great culprits of modern computer society is the idea of software bloat: that an application has grown too large to be effective. Microsoft Windows and Office are regularly accused of this sin, but even Thunderbird and Firefox are accused; I'm sure that one could dredge up opinions as to why the Linux kernel or X is too bloated. But are these terms fairly applied?

An adage holds that 80% of features are used by only 20% of users, but the problem is that the only-used 20% is different for each user. I personally don't use mail-merge in office applications at all, but I tend to heavily use the advanced outlining options, for example. Does this mean that the mail-merge feature should be stripped? What about macros--evil for most of the public but invaluable for those who heavily rely on them?

I recall reading Slashdot's response to the awesomebar in Firefox. The average response consisted of yelling why it was such a bad idea to include it, most likely by those who never used it before. I had the same response at first, but quickly found it invaluable: going to a specific bugzilla bug allows me to type the bug number, or heading to RFC 3977 by typing just that. And for that site where I remember the title but not the freaking URL, well, that explains itself. In fact, now, I get annoyed when I realize that I am not using the awesomebar because the regular URL bar is so cumbersome. So is the awesomebar bloat? To non-users, yes, but to users, no.

A more specific example to me is Thunderbird. The aforementioned post consisted of a rant (I'm not going to glorify it) as to why Thunderbird should stick to email and only email, no RSS, no calendar, no NNTP, no address book, no... half of it. Would it be better? The RSS component probably detracts from Thunderbird by being half-implemented (I will slyly add in that news has had even worse problems, and few call for that to be stripped out unless prompted), but would one complain if it was well-implemented? I think not. And there are strong reasons, too.

But there is no clear line to draw when excluding features. News is a worthwhile component to include in an email reader: it is quite close to IMAP in many regards. If one includes news support, why not include uuencode? It's useful for multinational stuff or alt.binaries. Why not then yEnc? Combine-and-decode? X-Face? Advanced message scoring? Feature XYZ? At some point, someone can call it all "bloat", but where is the line you need to draw that makes it not bloat?

What's the alternative to bloat? Look at the ultimate example of bloat, Windows; the non-bloated alternative is Linux (Mac is somewhere in between). You have several varieties of Vista, but hundreds of Linux: Debian, Ubuntu, Gentoo, Slackware, OpenSUSE, Red Hat, Fedora Core, etc. Your desktop? The big ones are GNOME or KDE, but FVWM, Fluxbox, Blackbox, XFCE, and many more exist; cross-interoperability, especially between GNOME and KDE, is not close to what Windows provides. In the place of broken one-size-fits-all, we have a multitude of alternatives which can do poor jobs of talking to each other.

The answer, many claim, is in the idea of pluggability. But, here too, the line is very blurry. At what point do you say that extension XYZ should be included into the core? This is what happened with RSS: it first existed as an extension and was later integrated. Although not well-versed in Firefox history, I would be willing to posit that extensions there too have similarly become incorporated. The sum response is that more plugins are included into the core until someone, once again, screams about the bloat, forks, creates a leaner version, which then becomes just as bloated, ad infinitum.

So, what can one do about bloat? In my opinion, the true, final answer is to let the user decide for him or herself what features are needed. Being able to easily compile the source code with options to turn off feature X goes a long way to this. Increasing modularity helps, and, perhaps most importantly, the biggest single help would be to have true, open, universally-supported standards, not just for online communication, but through interprocess and interplatform communications in all regards (i.e., standards closer to an ODF specification than to XML).


Flackrum said...

I think a level of psychology & philosophy is in play when it comes to Firefox. Whether it was core or add-on functionality (or both) that led to memory consumption and slow response time in v2.x, in the end the user 'felt' slowness and attributed it to bloat.

When the next version comes along, they want less of that 'feeling', whether it holds true for v3 or not, and take up arms to ensure slimness and snappiness are never trumped in the future.

Mix in the perspective of "only load and run what I want, when I want" that's prevalent in linux communities (not disparaging that at all, the philosophy rocks), and you end up with a combo that combines to urge some to fight ze evil bloat.

Slashdot, in particular, tends to be an echo chamber of criticism and should be tempered with other sources of commentary/reaction.

It might be useful to explain the benefits of adding to core functionality instead of add-ons when the new core functionality is showcased.

1. Does it speed the browser up to incorporate said function into the core code (as opposed to being an add-on)? Is the memory difference insignificant in relation to the gains vs. the previous version? etc..

2. Is sufficient user-friendliness/efficiency/utility/etc. achieved by ensuring it's part of the default setup? Do the naysayers realize how many FF users never install an add-on or how the addition of a particular function could enhance newcomer retention? etc..

Anonymous said...
This comment has been removed by a blog administrator.
Mook said...

Unfortunately, configurations don't scale like that. It only works when the developers make an effort to keep everything working with the quadratically increasing number of configurations.

At some point I used to build Firefox with --disable-places (I think I was one of the last). Eventually it was better to just give up investing in the time and go with what somebody else was maintaining. When was the last time you built with --enable-default-toolkit=xlib?

Anonymous said...

We agree that different people want different things from the same application. Therefore, it's a step in the right direction to make the application modular.

Setup should offer a choice of what components to install. To take an ease of post-install customization one step further, there should be a separate UI to enable/disable additional major components. This whole new setup step and UI may not be relevant for Firefox because browser itself is the only major component. But for a program, such as Thunderbird, a newsreader, rss reader, etc. can be made into such major additional optional components.

Either a simple checkbox in Settings or an additional tab in Add-ons manager could do the trick.

Havvy said...

I'd like to see something similar to what you suggested happen to firefox.

Make it so you can take out a module, and replace it with a different module. If a person wants bookmarks/history/(anything else in places) separate from places, they should be able to uninstall places, and install the bookmarks/history/ect. branches, or better yet, have it so you can have both on at once, that way, you have the best way of choosing things. I'm not just saying this for places either. It's just an example. Another example might be...the search bar in the top right corner...

Anonymous said...

hello, this is the first time i visit here, your article is pretty interesting. i like it so much.