¿Qué es el bus factor?
El bus factor intenta medir el “número de programadores que, si fueran atropellados por un autobús, dejarían al proyecto sin capacidad de reacción ni continuación”. Básicamente, es una manera de calcular la concentración de la información relevante del proyecto en un grupo de desarrolladores del mismo. Como regla general, cuánto más bajo el bus factor, peor, ya que esto implica que el proyecto depende demasiado de un grupo pequeño de gente que si se fuera (o les atropellaran a todos de golpe 🙂 ), dejaría el proyecto sin un montón de información relevante para poderlo continuar sin, casi casi, empezar de cero.
Es obvio, que en todo proyecto software (y aún más si estamos hablando de proyectos de software libre), hay gente que conoce más a fondo los detalles del proyecto mientras que otros sólo conocen una pequeña parte. Hasta cierto punto esto es una manera de aprovechar al máximo los pocos recursos disponibles permitiendo que la gente se especialice en problemas concretos. Pero si el número de “generalistas” (es decir, aquellos que saben como funciona todo y tienen la visión de hacia dónde debería ir el proyecto y el cómo se ha llegado hasta aquí) es pequeño, el proyecto está en una situación de riesgo. Sí, el código seguirá siempre ahí pero todo el conocimiento acerca del cómo y el porqué de ese código se podría perder.
Por desgracia muchos proyectos software de sobra conocidos tienen un bus factor muy pequeño lo que afecta a su futura sostenibilidad . Esta imagen de xkcd ilustra muy gráficamente este problema:
El bus factor también se llama a veces truck factor o pony factor. De forma un tanto irónica a veces también se le llama “boss factor”, ya que más que un autobús el gran peligro que acecha la disponibilidad de un programador a colaborar en un proyecto es la opinión del jefe de turno que puede llegar a la conclusión que contribuir al mundo del software libre no es una buena inversión de los recursos de la empresa.
¿Cómo se calcula el bus factor?
No hay una fórmula universal. Siempre se empieza a partir del análisis de los commits de cada programador individual. Se asume que cada commit implica un cierto conocimiento de ese programador sobre los ficheros a los que afecta el commit. A partir de ahí, ese conocimiento se va agregando para calcular qué programadores acumulan un conocimiento suficiente para formar parte del bus factor.
A partir de ahí, cada organización decide la fórmula a usar para calcular la acumulación de conocimiento y el umbral mínimo. Por ejemplo, algunos se limitan a tener en cuenta el número de commits global mientras que nosotros usamos una fórmula bastante más compleja que tiene en cuenta, para cada archivo, tanto el impacto de cada commit (en función del número de líneas añadidas o eliminadas) como su ordenación temporal (puedes indicar que los commit más recientes dan más puntos que los antiguos ya que reflejan un conocimiento más actual). A partir de esa información se asigna un cierto porcentaje de “propiedad” sobre el archivo a cada programador que lo ha tocado. Estos porcentajes se van agregando a nivel de subdirectorio, directorio y proyecto hasta llegar a un porcentaje de propiedad sobre el proyecto global que es la medida que usamos para filtrar los programadores clave del proyecto. Para los que tengáis curiosidad, una explicación detallada de este método de cálculo del bus factor la podéis encontrar aquí.
Si queréis calcular de una forma fácil y rápida (y sin programar) el bus factor de vuestros propios proyectos, podéis utilizar Kibble, de Apache. Su demo online incluye el bus factor como una de las visualizaciones predefinidas.
El bus factor se puede calcular también sobre otras partes del proyecto, no sólo el código. Por ejemplo, el éxito de un proyecto depende mucho de su capacidad para tratar bien a los usuarios y responder de una forma eficiente y eficaz a sus preguntas. Un análisis de las discusiones en el issue tracker te ayudará a identificar qué personas son claves en la gestión de la comunidad. Mejor que a esos no los eches (o que te asegures de tratarlos bien para que no se te vayan).
Ejemplo: el bus factor en WordPress
Como curiosidad final, os muestro el bus factor de un proyecto tan importante como WordPress. La imagen recoge el bus factor de WordPress en su versión inicial y en la versión 4.2 (la última en el momento que hicimos este análisis, a día de hoy vamos por la 4.9.6). Como podéis ver, en su primera versión el bus factor de WordPress era 1 (su co-fundador Matt Mullenweg) pero en la versión 4.2. había ya subido a 10. WordPress ha hecho un muy buen trabajo en involucrar a más gente en su desarrollo (mucha parte culpa es de la manera en qué WordPress organiza su liderazgo rotativo).
Ver esta evolución da mucha más tranquilidad a las empresas, siempre reacias a confiar en proyectos individuales. Aunque Matt se fuera, WordPress se queda y eso es un factor muy a tener en cuenta a la hora de escoger algo tan importante como tu plataforma de presencia online.
Últimos comentarios