Sólo conocemos dos modos de construir cosas extremadamente complejas. Una es mediante ingeniería, y la otra mediante evolución.
Esta cita se debe a Daniel Hillis. La nombro en relación a una entrada sobre si es relevante o no que un ERP sea libre (definición de ERP).
El problema de ese tipo de software es que se ha vuelto tan complejo que es completamente inmanejable. De este modo, las empresas que adoptan una determinada solución, quedan atrapadas en ese proveedor, porque el software es tan complejo de gestionar que ni la misma empresa ni algún otro proveedor se podría hacer cargo de esa gestión.
Puede parecer que el hecho de que sea libre o no, no es relevante. En realidad, lo que sí es relevante es cómo se diseña el software. Si se ha hecho en un grupo pequeño y controlado, diseñado desde cero conforme a estrictos requisitos, debido a su complejidad, acaba dando lugar a una mala solución. En otras palabras, puede que si es libre o no carezca de relevancia. Pero si se ha construido por ingeniería o por evolución sí que es relevante. Casualmente, la mayoría del software libre se desarrolla por evolución, y la mayoría del software propietario por ingeniería.
En la entrada original que mencionaba se pone como ejemplo la pila Linux+Apache+MySQL+PHP, que tan usada ha sido tradicionalmente en el mundo del desarrollo web. Estamos ante un ejemplo de solución desarrollada por evolución. Cada parte de la solución ha sido desarrollada por equipos diferentes. Es más, todas las partes de la solución son proyectos de software libre, que en mayor o menor medida se han desarrollado por evolución más que por ingeniería.
En realidad, esta idea no es nueva. En 1997 Eric Raymond exponía las mismas ideas en su artículo “La catedral y el bazar”. El software no libre suele construirse como se hacían antiguamente las catedrales. Un grupo cerrado de diseño, una obra inmensa, se tardaban años en finalizarla. El software libre funciona más como un bazar. Cada pequeño puesto realiza su trabajo, cada uno persigue su interés, pero sin embargo pueden llegar a construir algo complejo por medio de colaboraciones. No sé si Raymond tenía la frase de Hillis en mente cuando escribió su trabajo, pero la idea es básicamente la misma.
Puede que esto sólo sea un ejemplo, y existan contraejemplos de soluciones libres que han fallado, o de soluciones propietarias muy complejas que se desarrollan con éxito.
La evolución de proyectos de software viene siendo estudiada desde hace 30 años. El pionero en estudiar la evolución de un proyecto de software fue Manny Lehman. Su trabajo se puede resumir en las conocidas como leyes de Lehman. Estas leyes son las conclusiones que se extrajeron al estudiar la evolución de OS-360, que es un ejemplo de un sistema complejo diseñado por ingeniería.
Algunas de estas leyes no se cumplen en el caso de proyectos de software libre. Por ejemplo, según Lehman, conforme un proyecto de software evolucion, su crecimiento se hace más lento, porque se vuelve más complejo. Al ser más complejo, requiere más esfuerzo realizar un cambio, así que se harán menos cambios en el mismo intervalo de tiempo.
Sin embargo, algunos proyectos de software libre parecen estar acelerándose en su evolución. El caso mejor estudiado es el del desarrollo del kernel Linux
En la gráfica (haz click en la imagen) se ve el coste que hubiera costado desarrollar Linux desde cero sobre el tiempo. Por ejemplo, en un punto determinado, si se decidiera hacer lo mismo desde cero, tendría el coste indicado por la gráfica. Ese valor es proporcional al tamaño. He puesto esa gráfica porque no he encontrado ninguna otra, pero lo que quiero resaltar es el crecimiento en tamaño. Cada color indica una de las ramas de desarrollo.
Lo que es más relevante de esta gráfica es que cuanto más grande es Linux, más rápido crece. La principal excusa que suele ponerse para explicarlo es que el número de personas que aportan código está creciendo también. Sin embargo, el número de personas que participan en Linux está creciendo sólo linealmente, como muestra el siguiente gráfico (extraído del artículo enlazado):
Es decir, es cierto que el número de personas está incrementándose. Pero el código crece a un ritmo más rápido que el ritmo al que crece el número de personas. Por tanto, la productividad individual de los programadores está incrementándose. En otras palabras, están aprendiendo, y por tanto pueden escribir más código con el mismo esfuerzo.
En mi opinion es debido a que el software libre (o en general, el software desarrollado mediante evolución) se desarrolla mediante un proceso de aprendizaje, de modo que a medida que el proyecto evoluciona, la productividad es más alta, y el crecimiento se sostiene o se acelera. Este fenómeno se observa en otros sistemas también. Por ejemplo, pongamos el caso de la distribución Debian GNU/Linux. En el gráfico siguiente se muestra en el eje vertical el tamaño de Debian en millones de SLOC, y en horizontal el tiempo. Cada barra es una de las versiones estables de Debian (haz click en la imagen):
Si nos fijamos en el crecimiento que hubo entre Woody y Sarge, nos damos cuentas de un hecho notable. Debian incluye la mayoría del software libre que existe para GNU/Linux. Si algo no está en Debian, es que es no muy popular (aunque hay una excepción importante, que es el caso de Java antes de que fuera libre). Por tanto, podemos asumir que el tamaño de Debian es una buena medida del tamaño de todo el software libre más popular que existe ahí fuera. Hasta la liberación de Woody, existían unos 100 millones de SLOC de software libre escrito. Eso supone unos 6 años de historia desde la primera versión estable de Debian. En resumen, en 6 años se escribieron unos 100 millones de líneas de código.
Entre Woody y Sarge transcurrieron tres años de desarrollo. En esos tres años el tamaño se dobló. Es decir, se escribieron otros 100 millones de SLOC, pero en la mitad de tiempo (3 años). Por tanto, la tasa de crecmiento en ese período fue el doble que la tasa en el período anterior. En otras palabras, en 3 años se creó tanto software libre como en toda la historia del software libre hasta Woody.
Lo que quería resaltar con este caso es esa explosión en el desarrollo durante esos tres años.
Por tanto, parece que en los casos mostrados, que son los dos sistemas muy complejos, un diseño por evolución ha dado lugar a sistemas que funcionan correctamente. Pero lo que es más importante, es que esos sistemas contravienen las leyes de evolución. No sólo son más complejos, sino que también crecen más rápido. Quizás si se hubieran diseñado desde cero, si se hubieran creado por ingeniería, su comportamiento sería diferente.
Esto deja muchas cuestiones todavía abiertas. ¿Hasta cuándo se incrementará la velocidad de crecimiento? ¿Existe un límite físico para el tamaño de un proyecto de software? ¿Existe un límite en la capacidad de aprendizaje de los desarrolladores? ¿Supondrá problemas este crecimiento tan rápido? ¿O por el contrario este crecimiento posibilita una rápida adaptación del proyecto al entorno?
Pero la cuestión que más me interesa a mí ahora mismo es cuál es el mecanismo detrás de este fenómeno. En la naturaleza ya se han dado fenómenos similares de crecimiento explosivo. Por ejemplo, durante el período cámbrico se produjo un crecimiento explosivo en el número de especies que existían en la naturaleza. Menciono este ejemplo porque existen investigaciones que muestran que un modelo matemático basado en el concepto de coopetición es capaz de explicar la dinámica de la evolución de las especies, incluídos fenómenos como la explosión cámbrica. Quizás se podrían aplicar los mismos conceptos y modelos para explicar por qué existe este patrón de crecimiento en el caso de software desarrollado por evolución. Es una lástima, porque no creo que llegue a tiempo como para que incluya esta idea desarrollada en mi tesis doctoral.
En cualquier caso, lo que intentaba demostrar es que en el caso de un proyecto muy complejo, sí que es relevante el hecho de que sea libre, porque un proyecto de software libre puede desarrollarse por evolución, lo que posibilita que se realize con éxito y de manera más rápida que en un entorno cerrado.
