¿Cómo se creó Linux? Los procesos detrás de la gestión de 13.500 desarrolladores

Probablemente ha utilizado Linux hoy – especialmente si no tiene un iPhone. Y si has navegado por la web hoy, hay una gran probabilidad de que el sitio web que visitaste también fuera servido por Linux.

Linux es un sistema operativo, pero a diferencia de software como Microsoft Windows y macOS, Linux fue desarrollado por una comunidad auto-organizada de voluntarios.

Con el tiempo, con el esfuerzo de más de 10.000 desarrolladores y procesos en evolución para gestionar la escala de trabajo, el kernel de Linux ha crecido a más de 20.000.000 de líneas de código en total. Forma la base estable de…

• Todos los teléfonos y tabletas Android del planeta
• 66% de los servidores del mundo
• 100% de los 500 principales superordenadores

Esta tecnología no surgió de un equipo orquestado con un grueso libro de políticas y capas de gestión. Surgió de unas pocas políticas cuidadosamente elegidas y culturalmente integradas, y de una misión compartida.

En este post, analizo cómo una tecnología tan esencial, compleja e importante pudo producirse de forma tan eficaz sin la estructura de gestión tradicional. Pero primero…

¿Por qué el kernel de Linux es tan impresionante?

Un kernel es el núcleo mismo de un sistema operativo. Es el orquestador de todos los demás procesos de software de tu ordenador o smartphone, repartiendo los recursos y proporcionando una forma de comunicación entre el hardware y el software.

En palabras de G. Pascal Zachary, el kernel de un sistema operativo puede compararse con «un jefe de personal doméstico tan diligente que sirve a la familia de arriba en cualquier momento, de noche o de día de guardia, atendiendo todas las peticiones». El núcleo mantiene la máquina en funcionamiento, sin importar lo que se encuentre. Fue un salto esencial desde el mundo en el que los ordenadores podían ejecutar sólo una aplicación a la vez, hasta el mundo que conocemos hoy.

El kernel de Linux, basado en UNIX, fue desarrollado a principios de los años 90 por Linus Torvalds.

En 1991, Torvalds había publicado la primera versión -sólo 10.000 líneas de código- y despertó el entusiasmo de la comunidad de desarrollo de software con el humilde anuncio por correo electrónico que se ve arriba.

Potenciados por el poder de colaboración de Internet por primera vez en la historia, los desarrolladores contribuyeron con sus propias habilidades de codificación y su tiempo de prueba de forma gratuita mientras la base de usuarios del kernel explotaba en tamaño. Si estaban dispuestos a experimentar, los usuarios podían tratar de improvisar un parche si encontraban algo roto, y discutir cómo mejorar el software.

Como Eric S. Raymond analiza en su libro sobre el primer software de código abierto, The Cathedral and The Bazaar, la gestión de Linus Torvalds de los desarrolladores del kernel creció hasta ser eficiente, auto-organizada, y más que capaz de producir posiblemente una de las piezas de software más complejas y ampliamente utilizadas en el planeta.

En este artículo, examino los procesos y las políticas que han surgido como apoyo necesario para el proyecto del núcleo de Linux a medida que ha evolucionado a lo largo de los años.

¿Cómo, sin un proceso formal, siendo un estudiante de informática de 21 años, guió Torvalds el proyecto del kernel hasta las cotas que alcanzó…

…Y qué tiene de difícil la gestión de los desarrolladores, de todos modos?

Según una investigación de Geneca, más del 75% de los ejecutivos de negocios y de TI creen que sus proyectos de software están destinados al fracaso. La dificultad de producir software fiable y de gestionar a los que lo hacen ha dado lugar a innumerables libros de gestión, estudios de productividad y marcos de liderazgo.

«La enorme complejidad del software significa que es imposible probar todos los caminos», escribe el director general de Kynetix, Paul Smyth, en Finextra. «Una aplicación de software es como un iceberg: el 90% no es visible. La mayor complejidad de la aplicación se encuentra bajo la línea de flotación».

Cualquier proyecto de software de tamaño significativo, ya sea un CRM o un sistema operativo como Microsoft Windows, es demasiado grande para que quepa en la cabeza de una sola persona. Requiere el conocimiento compartido y la colaboración de muchos contribuyentes. ¡Esto significa que los desarrolladores trabajan en partes especializadas de la aplicación al tiempo que necesitan comprender cómo su trabajo afecta al conjunto.

«Ninguna mente puede comprenderlo todo», comentó el director de un equipo de 250 desarrolladores de software de Microsoft mientras construían un sistema operativo desde cero, según G. Zachary en Show stoppers! un libro que cuenta la historia de un equipo de desarrolladores de software de Microsoft que se apresuraba a completar Windows NT en 1993.

Cuanto más grande es el proyecto, más lentamente se pueden implementar los cambios. Las investigaciones de Steve McConnell lo demuestran, al descubrir que el código se escribe a un ritmo entre 5 y 10 veces más lento en proyectos de más de 10.000.000 de líneas. Además, un estudio de las prácticas de desarrollo de Microsoft reveló que hay aproximadamente entre 10 y 20 errores por cada 1.000 líneas de código.

A pesar del tamaño del proyecto y del número de colaboradores, el desarrollo del núcleo de Linux se produce rápidamente y su gran y entusiasta base de usuarios capta los errores y escribe parches para enviar rápidamente las mejoras.

En sus primeros días de desarrollo -alrededor de 1991- no era inaudito que Torvalds publicara más de un nuevo núcleo al día. Ahora, en una etapa más madura y del que dependen el 80% de los teléfonos inteligentes y la mayoría de los servidores de Internet, el período de lanzamiento deseado es de 8 a 12 semanas. En cada lanzamiento, el kernel recibe una media de 10.000 parches de 2.000 desarrolladores, todos ellos luchando con más de 20.000.000 de líneas de código.

¿Cuáles son las técnicas y procesos de gestión necesarios para orquestar este nivel de colaboración y productividad? Bueno, no fueron redactados por un jefe de departamento o un autor de libros de negocios. Se desarrollaron de forma orgánica, con la orientación del «dictador benévolo» del proyecto, Linus Torvalds.

Incluso en su forma incipiente, el núcleo de Linux contaba con la colaboración de cientos de voluntarios que enviaban su trabajo directamente a Torvalds para su revisión. ¿Cómo gestionó un hacker antisocial y malhumorado las disputas, las contribuciones y la comunicación entre miles de desarrolladores durante casi dos décadas?

Cómo se documentan las políticas, los procesos y los 15.000.000 de líneas de código

A diferencia de lo que ocurre en una organización tradicional, los nuevos desarrolladores del kernel no se incorporan estrictamente a la comunidad, sino que se espera que hayan leído y comprendido completamente la documentación introductoria. El enfoque del proyecto del kernel en la documentación era una necesidad tanto por la complejidad técnica como por el gran número de desarrolladores.

En el repositorio de documentación del kernel existen numerosas preguntas frecuentes, instrucciones y guías de inicio, y aún más en las wikis creadas y mantenidas por desarrolladores del kernel de todo el mundo.

La forma en que se escribe y mejora la documentación refleja la forma en que se desarrolla el kernel; de forma colaborativa, abierta e incremental.

Al aprovechar los ojos y las especializaciones de un enorme grupo de personas, la documentación puede crearse, probarse y corregirse de forma mucho más eficiente que si lo hiciera un equipo más pequeño y dedicado. Para adaptar la ley de Linus a términos que un editor de contenidos podría entender mejor: con suficientes ojos, todos los errores tipográficos son obvios.

Además de material para el soporte técnico, la comunidad de desarrollo del kernel ha creado una biblioteca de documentación de procesos diseñada para suavizar el lado humano de la colaboración.

En la página del índice de «A guide to the Kernel Development Process», un párrafo dice:

«El propósito de este documento es ayudar a los desarrolladores (y a sus gerentes) a trabajar con la comunidad de desarrollo con un mínimo de frustración. Es un intento de documentar cómo funciona esta comunidad de una manera que sea accesible para aquellos que no están íntimamente familiarizados con el desarrollo del kernel de Linux (o, de hecho, el desarrollo de software libre en general)»

Nadie nace con un conocimiento innato del sistema de control de versiones git, o de cómo enviar un parche a una lista de correo. Es por eso que el proceso de desarrollo debe ser documentado – ¡explicar la misma información básica a una persona a la vez no escala!

Cómo se gestiona la comunicación entre 1000s de desarrolladores

Las conversaciones entre los desarrolladores ocurrieron al aire libre, en las listas de correo de desarrollo del núcleo. A día de hoy, el correo electrónico sigue siendo la herramienta preferida por su sencillez. Estas listas de correo fueron archivadas y organizadas, conformando un cuerpo de documentación e historia viva.

El efecto de comunicarse en público tiene un efecto similar a los beneficios de usar una herramienta como Slack hoy en día – cualquier información se hace segura y se puede buscar, en lugar de evaporarse. Sin embargo, para gestionar semejante manguera de información, el proyecto del kernel desarrolló una política de comunicación y la distribuyó como parte de la documentación.

La comunicación y la colaboración a tal escala no eran posibles antes de Internet, por lo que los primeros proyectos como éste necesitaban escribir y distribuir soluciones rápidas y efectivas para la gestión de la comunidad, la etiqueta y los problemas de presentación del código.

La documentación del kernel incluye reglas para el envío de parches, de modo que facilita a otros la revisión, edición y prueba del código contribuido. Esto significa que los parches deben ser enviados por correo electrónico en texto plano, no adjunto. Los parches deben ser enviados una sola vez por correo electrónico, y obedecer las directrices específicas de estilo de codificación:

Esta rígida estandarización es absolutamente necesaria para un proyecto tan grande como el núcleo, como lo es para proyectos de cualquier tamaño. Ayuda a reducir los errores en un espacio en el que un solo error puede tener un efecto dominó que produce un código inestable en el futuro, o hace perder el tiempo a muchos probadores y desarrolladores.

Cómo se toman (no) las decisiones críticas

Citando a Torvalds:

«El nombre del juego es evitar tener que tomar una decisión. En particular, si alguien te dice «elige (a) o (b), realmente necesitamos que decidas sobre esto», estás en problemas como gerente. Es mejor que las personas que diriges conozcan los detalles mejor que tú, así que si acuden a ti para una decisión técnica, estás jodido. Está claro que no eres competente para tomar esa decisión por ellos». – Documentación del desarrollo del núcleo de Linux

Además de evitar una jerarquía de gestión, el proyecto Linux tenía reglas claras y documentación que ayudaba a tomar decisiones sin necesidad de discusiones, debates o (muchas) guerras de fuego en las listas de correo. Un vistazo a los archivos le mostrará que la parte de la guerra de llamas no siempre es posible, pero lo que sí es posible es crear una política que anule la carga de la decisión.

«Por lo tanto, la clave para evitar grandes decisiones se convierte en simplemente evitar hacer cosas que no se pueden deshacer. No te dejes arrastrar a un rincón del que no puedas escapar. Una rata acorralada puede ser peligrosa; un directivo acorralado es simplemente lamentable».

Show Stoppers! revela que la filosofía de Bill Gates es similar. Él «admiraba a los programadores y los ponía invariablemente al frente de los proyectos, en los que podían gestionar y programar a la vez, para evitar una situación en la que los gestores profesionales, sin experiencia en programación o con conocimientos desfasados, tuvieran el control».

Cómo se orientan los contribuyentes en torno a un fuerte objetivo común

En el caso de Linux, como ocurre con muchos proyectos populares de código abierto, el núcleo no surgió habiendo sido diseñado de forma colaborativa por un gran grupo de contribuyentes, sino que se fue mejorando de forma incremental sin tomar decisiones que desestabilizaran la fuerte base de trabajo existente hasta el momento. Esto enlaza bien con la filosofía de Torvalds sobre la toma de decisiones en la gestión, pero también con una filosofía incrustada en el propio código.

Linux se basa en UNIX, que es un sistema operativo anterior diseñado en torno a un conjunto de principios de tipo zen. Como se indica explícitamente en la filosofía de UNIX:

«Diseña y construye software, incluso sistemas operativos, para probarlo pronto, idealmente en semanas. No dude en desechar las partes torpes y reconstruirlas»

Tanto Torvalds como Raymond (que trató de replicar el éxito de la construcción de la comunidad de Torvalds) descubrieron que publicar pronto y con frecuencia ayudaba a reunir a los colaboradores en torno a un proyecto emocionante y en crecimiento en el que pueden ver un futuro. Raymond lo redujo a dos cosas clave que un proyecto no puede dejar de hacer cuando se lanza al mundo:

1. Correr
2. Convencer a los potenciales co-desarrolladores (usuarios) de que el proyecto puede evolucionar en algo grande pronto

Es con estos mismos principios con los que se lanzan muchas de las startups de hoy en día – Process Street incluida:

Arriba está Process Street en 2014. Regístrese para obtener una cuenta y ver hasta dónde hemos llegado.

¿Es este un proceso repetible?

En la superficie, la repentina unión de una de las más intrincadas creaciones humanas parece alquimia. Sin embargo, al separar los componentes es más fácil ver un proceso subyacente. En el momento de escribir La catedral y el bazar, Eric S. Raymond dirigía simultáneamente el desarrollo de un cliente de correo electrónico de código abierto. Al abrirlo, Raymond intentaba replicar la participación de la comunidad y el éxito final del proyecto del kernel.

Muchos de los principios básicos del modelo Bazaar, como él lo acuñó, serán inmediatamente familiares para cualquiera en el mundo de las startups:

• Todo buen trabajo de software comienza rascando el picor personal de un desarrollador.
• Tratar a tus usuarios como co-desarrolladores es la ruta menos molesta para mejorar rápidamente el código y depurar eficazmente.
• Liberar pronto. Publica a menudo. Y escuche a sus clientes.
• Si cuenta con una base de beta-testers y co-desarrolladores lo suficientemente grande, casi todos los problemas se caracterizarán rápidamente y la solución será obvia para alguien.
• Si trata a sus beta-testers como si fueran su recurso más valioso, responderán convirtiéndose en su recurso más valioso.
• Lo siguiente mejor que tener buenas ideas es reconocer las buenas ideas de sus usuarios. A veces esto último es mejor.
• A menudo, las soluciones más sorprendentes e innovadoras surgen al darse cuenta de que tu concepto del problema era erróneo.
• Para resolver un problema interesante, empieza por encontrar un problema que te resulte interesante.
• Si el coordinador de desarrollo dispone de un medio de comunicación al menos tan bueno como Internet, y sabe dirigir sin coacciones, muchas cabezas son inevitablemente mejores que una.

En definitiva, es un proceso repetible. Y uno que ha sido adoptado con éxito desde el mundo del código abierto a la mentalidad de las startups. Se manifiesta en agile, lean, six sigma, y en las actitudes y políticas que las startups de hoy han desarrollado. Aunque no se menciona a menudo en la misma conversación, la metodología que se desarrolló en torno a los primeros sistemas operativos comparte mucho con la idea actual de iterar sobre un producto mínimo viable.