El mes pasado Linus Torvalds lanzó un curioso aviso a los desarrolladores del kernel de Linux: en agosto se le habían juntado “varios eventos familiares”, entre ellos “una boda y un cumpleaños importante”; y, con tanto viaje, no creía que fuese a tener mucho tiempo para revisar los parches de la siguiente release, pidiendo disculpas de antemano por el “pequeño caos” y los posibles retrasos.

El aviso deja muy claro que el kernel de Linux tiene una enorme dependencia de una única persona, algo que sorprende en un proyecto tan importante. ¿En serio la fecha de una release depende de que Linus tenga o no muchos eventos familiares? ¿Es que nadie más puede hacer su trabajo?

¿Y si a Linus le ocurriese algo realmente grave, como una enfermedad, o si le atropellase un autobús?

Esta dependencia de unos pocos desarrolladores clave en un proyecto de software es lo que en el mundo IT se conoce como bus factor, aludiendo precisamente a qué pasaría sí un día a esas personas les atropellase un autobús. Por ejemplo, si la salida de un único desarrollador puede paralizar un proyecto, se dice que tiene un bus factor de 1.

El problema del bus factor en Linux se ha reportado muchas veces, y se reaviva cuando ocurren problemas. En 1998 Linus la lió haciendo un merge, y mientras arreglaba el problema dejó a un montón de desarrolladores colgados, ya que nadie más que él podía aprobar sus cambios. Las numerosas quejas cabrearon tanto a Linus que acabó cogiéndose unos días libres y mandando a todo el mundo a tomar por saco.

En otra ocasión, Linus decidió irse al rincón de pensar durante un tiempo, y para no bloquear la release le pidió a Greg Kroah-Hartman que terminara el trabajo. Es la única vez que una versión de Linux ha sido liberada por alguien distinto a su creador en más de tres décadas.

Más recientemente, la release de una versión se retrasó un día porque literalmente a Linus "se le olvidó hacerlo" (y, una vez más, nadie más podía hacerlo en su lugar).

A pesar de todos estos incidentes, Linus ha comentado varias veces que no ve necesario delegar su trabajo ni tampoco designar un sucesor, una situación que irrita y preocupa a algunos desarrolladores.

Esta aversión a delegar es común a muchos proyectos en los que, como ocurre en Linux, su creador original actúa como Benevolent Dictator For Life (o BDFL), y de hecho una de las primeras menciones al bus factor de un proyecto ocurrió en 1994 cuando uno de los maintainers de Python se preguntó qué pasaría si Guido Van Rossum sufriera un accidente.

El bus factor es un gran problema para todos los proyectos de código abierto en los que una única persona realiza casi todo el trabajo (normalmente sin percibir un salario). Si esta persona pierde la motivación por continuar el proyecto o deja de tener tiempo para ello, puede afectar a millones de usuarios. Por ejemplo, algo tan crítico como sudo no es más que el side project de un desarrollador llamado Todd C. MIller, desde hace más de 30 años.

El caso más perverso de bus factor es aquel en el que los desarrolladores son conscientes del riesgo que supone para su proyecto, pero aun así no hacen nada para evitarlo, en la idea de que mantenerlo así les convierte en imprescindibles (por ejemplo, ocultando información a sus compañeros, evitando el pair programming, no documentando o escribiendo código lo más ofuscado posible para que sólo ellos puedan entenderlo).

Tristemente, estas situaciones son frecuentes en el mundo empresarial. Si unimos a esto la alta tasa de rotación que sufren algunas empresas del sector IT, es fácil darse cuenta del riesgo latente que sufren hoy en día muchos proyectos de software, sin necesidad de que a nadie le atropelle un camión.

Uno de los casos más sonados de "evento bus factor" ocurrió el 3 de agosto de 2023 cuando Bram Moolenaar, creador y BDFL del popular editor de texto Vim desde 1991, falleció de forma repentina. El resto de voluntarios encontraron numerosos problemas para retomar la gestión del repositorio y resto de herramientas, incluso cuando Bram había sido lo bastante precavido como para designar a un sucesor en la Deceased User Policy del proyecto en GitHub.

Pero sin duda el caso más canónico (y tróspido) de proyecto afectado por el bus factor es el de TempleOS, un sistema operativo de temática bíblica construido entre 2003 y 2017 por un único desarrollador, Terry A. Davis.

El bueno de Terry padecía esquizofrenia y trastorno bipolar, y durante esos quince años desarrolló su sistema operativo (del cual probablemente fuese también su único usuario), según él, por indicación directa de Dios, y en contacto permanente con extraterrestres. En 2018 Terry murió... arrollado por un tren, y por supuesto ese evento supuso también el final del proyecto.

Y, aunque el término bus factor proviene del mundo del desarrollo de software, lo cierto es que puede aplicarse a casi cualquier aspecto de la operativa de una empresa.

Es muy normal que una startup tenga un bus factor de 1, al menos en su etapa de early stage. Al fin y al cabo, ¿para qué contratar a alguien si puedes encargarte tú de todo?. El problema es que llega un punto en el que la cosa se te va de las manos. Es en este punto donde puedo hablar de mi propia experiencia.

Hace cuatro años mi empresa no estaba precisamente en su etapa inicial (éramos casi 50 empleados), pero mis tareas como fundador seguían incluyendo la gestión de proyectos, redacción de ofertas, recruiting, marketing, ventas, redes sociales... y por supuesto también el desarrollo de software. Mi socio también cargaba con su parte (y contabilidad, nóminas, impuestos...), y para más inri, en muchos casos las tareas de uno no las sabía hacer el otro. Era una locura. Si el bus factor de la empresa no era 1, desde luego estaba peligrosamente cerca.

Cada vez teníamos más claro que la situación no era sostenible, y por supuesto ni siquiera sentíamos que estuviésemos haciendo las cosas bien. El riesgo, además, era palpable.

En cualquier caso, la decisión estaba en nuestras manos. Si queríamos dar un salto de calidad no quedaba otra que invertir fuertemente en estructura, automatizar procesos y compartir tareas. Volvernos prescindibles. Superar nuestra aversión a delegar para seguir creciendo. Y a conseguir este objetivo nos entregamos en los años que siguieron.

Echando la vista atrás, no tengo la menor duda de que aumentar nuestro bus factor fue la mejor decisión que pudimos tomar. De repente teníamos tiempo para asistir a eventos, impartir charlas técnicas, hacer networking o planificar una estrategia de crecimiento inorgánico, y todo ello sin sentir que estuviéramos desatendiendo nuestras tareas del día a día.

Y lo mejor de todo: también me permitió disfrutar plenamente de dos bajas de paternidad sabiendo que, por fin, ningún proceso crítico de la empresa dependía únicamente de mí.

Es posible que durante este mes de agosto te hayas cogido un par de semanitas de vacaciones, que hayas desconectado a tope, y que aun así tu proyecto o tu empresa hayan seguido funcionando con normalidad. Si ese ha sido tu caso, solo puedo decirte una cosa: ENHORABUENA. Puedes decir tranquilamente que te lo has montado mucho mejor que el mismísimo Linus Torvalds 🙂

¿Quieres ayudarme a difundir este texto?