Software complification [update]

You may remember my rant from a couple of weeks ago, regarding the ever-increasing complexity of modern browsers. There are two bullet points with respect to that topic:

• There are no big news, except
• Despite xz-compression, the chromium source tarball has finally broken warp three: It's now 306 MiB in size. An updated version of the illustration of the different browser size tarballs is given below.

The Windowsification of Unix

For quite a while, Microsoft Windows has exhibited a property that seems to be common in living organisms while being quite uncommon in the world of operating systems: Its ability to age and the subsequent inevitable need to die and get reborn.
To put this in more technical rather than biological terms: After a couple of months up to a low one digit number of years (in a base 3 number system) the continuous degradation of perceived performance in a Windows system, plus the ever-increasing clutter of what-the-hell-is-this-files on the C: partition becomes such a PITA that the easiest solution is to lock oneself in at home on a lonely Friday night with a sixpack of beer and reinstall Windows and all apps.
This of course was completely unknown to Unix-like folks who never really needed to reinstall their machines, mostly due to the Unix philosophy to do as much as possible with simple tools and use simple text files for configuration of the whole OS. For instance, the last time I installed my home server from scratch was more than 6 years ago and the reason was relocating overseas, not a software issue.
And then came Android. "Did you try factory reset?" is a standard question to all kinds of problems with Google's great approach at transferring the much-loathed concept of ageing software from Windows on top of a Linux-based software stack. In the past weeks, my 18-months old Android mobile phone became gradually suspiciously slow and apps started to crash more often. Yesterday it decided to give up even trying to start them: The error message "Unfortunately, the process com.google.process.gapps has stopped." appeared in very quick repetition such that it became hard to operate the device at all in order to attempt all the salvage recipes that the internet offers. Before you ask: No, I did not attempt the ones that involved sacrificing a virgin when the moon is waning gibbous; only the ones that seemed to be sensible from a technical point of view: Clearing caches, resetting apps to initial state and reapplying updates, this kind of thing, and - of course - reboot the device a bazillion times. What helps on Windows shall help on Android, right? The fuck it did. So I finally gave in, did a factory reset, and will probably spend the next weeks noticing small things that were not properly restored by Google's glorious backup-and-restore feature, starting with the local music files. Thank you Google for breaking Linux to the point that it behaves like Windows 95.

Software complification - Please make it stop

Today I have something more visual than my usual text rants: An image! Yay! Because an image is more expressive than words. Have a look a this:

This graph lists the sizes of the source tarballs of different browsers hitting the FreeBSD ports tree over the past decade. (By the way, Git, Python and Google docs were my friends in creating this.) It illustrates two major points I want to talk about:

• Starting with Firefox in 2004 (red line colour) and a tarball size of 29.7 MiB, the code base gained weight very slowly until September 2009 where it started to gain a little faster (in the graph this is roughly where the leading '0' of '01/01/2011' is placed.
  Coincidence? I don't think so. Less than a year earlier, in December 2008, Google released a public beta of Google Chrome and it became blindingly clear to most developers how powerful web apps can become if powered by the right technology. Chrome's release changed the game. It fuelled the development of new features in browsers to a velocity that we haven't seen before and sparked the development of browsers that are quite possibly the most complex piece of software you have installed on your devices.
  Then, after the open source release of Chromium (Chrome's non-commercial code parts) things really took a spin and the code base size of the leading browser implementations increased close to exponentially over the next 4 years to the point of my blog post today, at which Chromium's source can be downloaded xz-compressed into a 279.8 MiB tarball, with Firefox's tarball measuring 170 MiB in size and Seamonkey's 193.6 MiB. Without Chrome sparking this trend, for all we know we could still be at less than 40 MiB for Firefox and the slow JavaScript interpreter we all learned to hate. So far so good.
• Now comes the issue with this. Apparently for a while now we are locked into a mindset in which each new browser release has to be filled with an ever-growing list of new, cool, features. Features that, I'd argue, in part only serve edge cases and more often than not do not concern the average user. Pushing features at every cost has its price. Firefox's recent vulnerability which allowed malicious PDF documents (!) to read local hard drive files is but one example that justifies the question What the hell is missing in current browsers? Do we really need a PDF viewer built into the browser? I have no problem downloading the PDF file and open it in a PDF viewer app. The same goes for other features: Ever-increasing numbers of supported audio and video codecs, offline-applications, "Pocket" (never used it), built-in instant messaging apps, you name it. Focusing development teams (or communities) of a finite sizes strongly to features comprises the danger of omitting the necessary code refactoring, purging the code base of unused or rarely-used components, and old-fashioned maintenance releases which may improve performance, memory efficiency, security without delivering new exciting features. I am not alone here. Enjoy this well-written statement by Paul-Peter Koch who explains a lovely edge-case feature to us: Navigation transition. Quite possible that you have never heard of it before. Read the post and be stunned that this kind of stuff actually exists in your browser.
• Tiny extra point: Seamonkey, in a simplified approximation, is Firefox plus E-Mail client plus IRC client plus HTML-Editor. The graph above also shows (comparing Firefox with Seamonkey) how huge the browser code base is compared to the rest of Seamonkey's components.

So please, please, please, for heaven's sake: You Googles, Mozillas, Microsofts and players in the industry. Stop complicating things and strive for the lean, lightweight, small, fast, secure software that we really need and give the dev teams the chance to implement them.