Ir al contenido principal

Ralsina.Me — El sitio web de Roberto Alsina

The Steady State of Open Source

The Steady State The­o­ry says, in rough terms that the uni­verse has been and will be more or less as it cur­rent­ly is, be­cause there are par­al­lel pro­cess­es of cre­ation and de­struc­tion.

So, gal­ax­ies ex­haust but then there are new galax­ies, and the thing, as a whole, re­mains un­changed, in a way. Sure, it's not the same galaxy, and noth­ing that was in the old gal­axy re­main­s, but if you avoid specific­s, things are the same.

I feel the same thing hap­pens in the free soft­ware uni­verse. The two forces are re­ac­tion and fea­tures.

Re­ac­tion is the cre­ative force. Most, if not al­l, free soft­ware is re­ac­tive. It itch­es, I scratch, scratch­ing is re­ac­tive. There are many ex­am­ples:

  • There is no free desk­­top! Let's cre­ate KDE!

  • KDE is not the right kind of free, sort of! Let's cre­ate GNOME!

  • KDE and GNOME are too heavy, bloat­ed and what­ev­er! Let's cre­ate XFCE!

  • XFCE is not as lean and mean as be­­fore! Let's cre­ate LXDE!

  • LXDE is (we'll find some­thing) let's cre­ate WHAT­EV­ER-DE!

This even hap­pens with­in a pro­jec­t:

  • Hey, we cre­at­ed KDE!

  • KDE 1.x has no ob­­ject mod­­el and GNOME does, let's do KDE 2.0 on COR­BA!

  • Hey, that sucked, let's do KDE 2.0 on DCOP and KPart­s!

  • Well, that's old an crufty, let's do KDE 3.0 clean­er!

  • KDE 3.x looks old, let's throw all the UI away and do KDE 4!

And I am sure those fa­mil­iar with any soft­ware prod­uct that has lived long enough to go through ma­jor rewrites and up­heaval can do sim­i­lar list­s.

How­ev­er, some­times, the com­plains just don't go away.

  • Net­s­cape 4.x is slow and crufty! We rewrote it as Mozil­la!

  • Mozil­la (Sea­­Mon­key) is slow and crufty! We rewrote it as Fire­­fox!

  • Fire­­fox is slow and crufty! We wrote Chrome us­ing we­bkit!

And guess what peo­ple say about Chrome? It's slow.

So, the les­son there seems to me that writ­ing a lightweight, gen­er­al­ly use­ful, web brows­er is im­pos­si­ble. Why? Be­cause of fea­tures.

As projects age, they grow fea­tures. Like the strange ear and nose hair men start grow­ing in their 30s, fea­tures are a fact of the life­cy­cle. And with fea­tures come code, be­cause that's how you do fea­tures.

And code is a li­a­bil­i­ty, as (I hope) you all know. The more code you have, the more ex­pen­sive it is to add things, and to be swift about im­prov­ing your ap­pli­ca­tion. Most suc­cess­ful projects die, or grow senes­cen­t, hob­bled by the weight of their fea­tures.

So how does a project stay young? I can think of a few ways.

It may have a be­nign (or evil, for that mat­ter) dic­ta­tor, with the right amount of hos­til­i­ty to­wards fea­tures (Lin­ux). It may be so exquisite­ly mod­u­lar that fea­tures don't cou­ple with each oth­er (emac­s). It may rein­vent it­self ev­ery 5 years and throw ev­ery­thing away (KDE). It may have a very clear fo­cus on one fea­ture and a cul­ture around it (Bac­u­la).

And for each of those mech­a­nism­s, there are in­count­able ex­am­ples of projects with too an­noy­ing dic­ta­tors, projects ov­erengi­neered to ab­sur­di­ty, stalled rewrites that nev­er re­lease and ab­so­lute fo­cus on a fea­ture noone cared about.

Sor­ry, the uni­verse is a tough place.


Contents © 2000-2024 Roberto Alsina