Es obvio, que en todo proyecto software (y a\u00fan m\u00e1s si estamos hablando de proyectos de software libre), hay gente que conoce m\u00e1s a fondo los detalles del proyecto mientras que otros s\u00f3lo conocen una peque\u00f1a parte. Hasta cierto punto esto es una manera de aprovechar al m\u00e1ximo los pocos recursos disponibles permitiendo que la gente se especialice en problemas concretos. Pero si el n\u00famero de “generalistas” (es decir, aquellos que saben como funciona todo y tienen la visi\u00f3n de hacia d\u00f3nde deber\u00eda ir el proyecto y el c\u00f3mo se ha llegado hasta aqu\u00ed) es peque\u00f1o, el proyecto est\u00e1 en una situaci\u00f3n de riesgo. S\u00ed, el c\u00f3digo seguir\u00e1 siempre ah\u00ed pero todo el conocimiento acerca del c\u00f3mo<\/em> y el porqu\u00e9<\/em> de ese c\u00f3digo se podr\u00eda perder.<\/p>\n Por desgracia muchos proyectos software de sobra conocidos tienen un bus factor muy peque\u00f1o lo que afecta a su futura sostenibilidad\u00a0<\/a>. Esta imagen de xkcd ilustra muy gr\u00e1ficamente este problema:<\/p>\n <\/p>\n El bus factor tambi\u00e9n se llama a veces truck factor<\/strong> o pony factor<\/strong>. De forma un tanto ir\u00f3nica a veces tambi\u00e9n se le llama “boss factor”, ya que m\u00e1s que un autob\u00fas el gran peligro que acecha la disponibilidad de un programador a colaborar en un proyecto es la opini\u00f3n del jefe de turno que puede llegar a la conclusi\u00f3n que contribuir al mundo del software libre no es una buena inversi\u00f3n de los recursos de la empresa.<\/p>\n No hay una f\u00f3rmula universal. Siempre se empieza a partir del an\u00e1lisis 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\u00ed, ese conocimiento se va agregando para calcular qu\u00e9 programadores acumulan un conocimiento suficiente para formar parte del bus factor.<\/p>\n A partir de ah\u00ed, cada organizaci\u00f3n decide la f\u00f3rmula a usar para calcular la acumulaci\u00f3n de conocimiento y el umbral m\u00ednimo. Por ejemplo, algunos<\/a> se limitan a tener en cuenta el n\u00famero de commits global mientras que nosotros usamos una f\u00f3rmula bastante m\u00e1s compleja que tiene en cuenta, para cada archivo, tanto el impacto de cada commit (en funci\u00f3n del n\u00famero de l\u00edneas a\u00f1adidas o eliminadas) como su ordenaci\u00f3n temporal (puedes indicar que los commit m\u00e1s recientes dan m\u00e1s puntos que los antiguos ya que reflejan un conocimiento m\u00e1s actual).\u00a0 A partir de esa informaci\u00f3n 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\u00e1is curiosidad, una explicaci\u00f3n detallada de este m\u00e9todo de c\u00e1lculo del bus factor la pod\u00e9is encontrar aqu\u00ed<\/a>.<\/p>\n Si quer\u00e9is calcular de una forma f\u00e1cil y r\u00e1pida (y sin programar) el bus factor de vuestros propios proyectos, pod\u00e9is utilizar <\/strong>Kibble, de Apache<\/strong>.<\/a>\u00a0 Su demo online incluye el bus factor como una de las visualizaciones predefinidas.<\/p>\n El bus factor se puede calcular tambi\u00e9n sobre otras partes del proyecto, no s\u00f3lo el c\u00f3digo<\/strong>. Por ejemplo, el \u00e9xito 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\u00e1lisis de las discusiones en el issue tracker\u00a0<\/em>te ayudar\u00e1 a identificar qu\u00e9 personas son claves en la gesti\u00f3n de la comunidad. Mejor que a esos no los eches (o que te asegures de tratarlos bien para que no se te vayan).<\/p>\n Como curiosidad final, os muestro el bus factor de un proyecto tan importante como WordPress<\/a>. La imagen recoge el bus factor de WordPress en su versi\u00f3n inicial y en la versi\u00f3n 4.2 (la \u00faltima en el momento que hicimos este an\u00e1lisis, a d\u00eda de hoy vamos por la 4.9.6). Como pod\u00e9is ver, en su primera versi\u00f3n el bus factor de WordPress\u00a0 era 1 (su co-fundador Matt Mullenweg<\/a>) pero en la versi\u00f3n 4.2. hab\u00eda ya subido a 10.\u00a0WordPress ha hecho un muy buen trabajo en involucrar a m\u00e1s gente en su desarrollo<\/strong> (mucha parte culpa es de la manera en qu\u00e9 WordPress organiza su liderazgo rotativo<\/a>).<\/p>\n Ver esta evoluci\u00f3n da mucha m\u00e1s 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.<\/p>\n <\/p>\n![\"El](\"https:\/\/imgs.xkcd.com\/comics\/dependency.png\")
<\/p>\n\u00bfC\u00f3mo se calcula el bus factor?<\/h2>\n
![\"Bus](\"https:\/\/ingenieriadesoftware.es\/wp-content\/uploads\/2018\/06\/kibble-busfactor.png\")
<\/a><\/p>\nEjemplo: el bus factor en WordPress<\/h2>\n
![\"Bus](\"https:\/\/ingenieriadesoftware.es\/wp-content\/uploads\/2018\/06\/wordpress-busfactor.png\")
<\/a><\/p>\n