Cómo evitamos el 'foso de alquitrán'

BLOG INVITADO: RICARDO GALLI, DE SOFTWARE LIBRE

• Dirección: mnm.uib.es/gallir/
• Autor: Ricardo Galli, fundador de Meneame.net, espacio donde el usuario es parte activa de todo. Profesor de Sistemas Operativos de la Universitat de les Illes Balears, pertenece a la Free Software Foundation, siendo impulsor del software libre.
• Descripción: Desde su bitácora, Galli promueve el nuevo concepto llamado web 2.0, donde se busca que, cada vez en mayor medida, las aplicaciones tradicionales se conviertan en aplicaciones enfocadas al usuario final.

Atención: El siguiente apunte puede afectar negativamente a la sensibilidad de los lectores sin las debidas precauciones para evitar creer las fantasías descriptas. Algunos de los síntomas que se pueden presentar son: incredulidad sistemática a los comerciales de empresas de software, carcajadas inexplicables al leer PC Actual y revistas similares, considerar irrelevantes a los colegios oficiales o las campañas de ingenieros de primera, dejar de preocuparse por reclamar que el gobierno le quite de decretazos de la condición de mileurista, obsesión por programar. Antes de continuar lea atentamente las instrucciones de Métrica 3. Si aparecen algunos de los síntomas anteriores lave su cerebro cuidadosamente y consulte a su director de proyectos de forma inmediata.

Un tar pit es un foso de alquitrán (o brea, o tea), en estos fosos de zonas de EEUU se han encontrado restos de mamuts atrapados hace millones de años. Pero en informática tiene un significado especial, se refiere a la dificultad de gestionar grandes proyectos de software. La idea, e incluso el dibujo de portada (que inspiró a otras portadas de libros de sistemas operativos como éste  o el de la imagen de la derecha), es del libro The mythical Man Month.

En el año 1999 Neal Stephenson uso el mismo término en su también mítico In the Beginning was the Command Line para explicar la idea de la “fosilización”

 

The fossil record–the La Brea Tar Pit–of software technology is the Internet… Executives at companies like Microsoft must get used to the experience–unthinkable in other industries–of throwing millions of dollars into the development of new technologies, such as Web browsers, and then seeing the same or equivalent software show up on the Internet two years, or a year, or even just a few months, later.

   

By continuing to develop new technologies and add features onto their products they can keep one step ahead of the fossilization process, but on certain days they must feel like mammoths caught at La Brea, using all their energies to pull their feet, over and over again, out of the sucking hot tar that wants to cover and envelop them.

Pero la historia continúa, como una pesadilla. La ultísima referencia es de un artículo del Washington Post En Microsoft, un triste lección de software

 

The tar pit has regularly engulfed large corporate efforts to introduce comprehensive software “solutions.” … But unlike computer hardware … software isn’t rooted in the physical world. It’s still written, painstakingly, line by line and character by character; essentially, it’s all made up. Software straddles the wide-open realm of the imagination… And so far, it has proved uniquely resistant to engineering discipline.

Toda esta introducción a la mítica figura del tar pit –nadie debería considerarse un ingeniero informático sin conocer este tipo de historias– viene porque en LWN han publica una muy buena reflexión de cómo podemos o hemos podido evitar el efecto del foso de alquitrán  en los proyectos de de software libre, en particular del núcleo Linux.

Por una lado confirma las predicciones de Brooks en The mythical Man Month. Durante la fase de desarrollo y estabilización del Linux 2.4 se vivieron unos [tres] años sumergidos en ese foso de alquitrán. Una de las soluciones fue la estructuración más formal del grupo de lugartenientes de Linus Torvalds. Esta es una de las soluciones ya explicadas por Brooks casi 30 años antes: formar “equipos de cirugía” (surgical teams) como los médicos que acompañan a los cirujanos expertos.

Pero según LWN hay dos aspectos fundamentales que permitieron salir y mantenerse fuera del tar pit y que no fueron siquiera previstos por Brooks:

1. Revisión de pares. Curiosamente, la revisión de pares es uno de los criterios fundamentales de la ciencia, y es fundamental para el software libre. Por ejemplo, hay muchos “parches” para Linux que están olvidados por la falta de revisión. Seguramente, en el ambiente de esa década donde la informática estaba dominada por las grandes corporaciones y el mercado de software privativo estaba naciendo, parecía inconcebible que pudiese existir en el software una comunidad coherente aunque diversa y dispersa como la científica.

2. Equipos de desarrolladores independientes. A Brooks le puede haber parecido un método muy poco eficiente para desarrollar software, porque la coordinación es menor lo que genera mucho esfuerzo y código duplicado que al final se descarta.

Internet seguramente tiene mucho que ver con la posibilidad que existan estos tipos de grupos, y sin duda esto sumado a la revisión de pares ha permitido el “desarrollo darwiniano” de los proyectos de software libre de tamaño considerable. Una consecuencia inmediata es que los programadores están obligados a mantener un ciclo de versiones estables de períodos muy cortos (típicamente mes o mes y medio para el Linux).

Y se me acaba de ocurrir una tontería, si un sistema operativo completo como un GNU/Linux es el reflejo de una evolución darwiniana, ¿es el software privativo el reflejo del “Diseño Inteligente”?. Al menos eso parecen decir los comerciales de Microsoft

Pero lo mejor de todo viene al final y que también considera una condición fundamental para evitar el tar pit: evitar el vaporware. Y eso se ha podido hacer muy bien en el software libre: show me the code.

Las promesas no cuentan, sólo el código.