Grado de madurez de un proyecto de software libre desarrollado en comunidad

A lo largo de los próximos meses seguiremos con nuestra idea de promocionar ModularIT y añadir algunas mejoras y documentación, tanto en castellano como en inglés. Aunque a nuestro ritmo, seguimos avanzando hacia lo que esperamos se convierta en un proyecto de comunidad maduro. Andamos discutiendo un poco sober algunos pasos a seguir durante los próximos meses.

Esto me lleva ha llevado a tratar de definir qué es un proyecto de comunidad maduro. ¿Cómo se mide la madurez de un proyecto?

El número de personas que contribuyen al proyecto no es una medida demasiado eficaz en este caso. Existen proyectos con muy pocos desarrolladores con un gran éxito y solvencia y otros que, a pesar de tener una gran comunidad, no es posible considerarlos proyectos de desarrollo en comunidad. Hay varios ejemplo pero uno de los más interesantes es aquel en el que una empresa tiene la sartén por el mango del desarrollo y, aunuqe libera el software y la documentación, no libera el know-how o no desarrolla en abierto.

El nivel de uso o popularidad tampoco en un factor definitivo. Hay productos libre de desarrollo en comunidad muy usados que son bastante inmaduros y viceversa. Ejemplos pos ambos lados hay muchos.

El nivel de madurez de la documentación o la cantidad de información publicada dice mucho del las bondades de un proyecto sin embargo, existen proyectos muy consolidados que carecen de documentación al nivel de otros aspectos del mismo. También hay algunos ejemplos, pocos, de proyectos bien documentados sin ningún tipo de comunidad alrededor. Existen ejemplos de iniciativas de comunidad que tienen el apartado organizativo y legal bien trabajado mientras que otros no prestan importancia excesiva a esos elementos. Algunos muy relevantes han tenido problemas por estos detalles y otros parecen convivir fantásticamente con el caos organizativo pues el debate se estructura debidamente.

El factor económico es otro elemento a tener en cuenta. Existen ejemplos de proyectos pequeños tremendamente rentables frente a otros enormes y de impacto global que no se mantienen económicamente por lo que deben recurrir a llamadas desesperadas a la comunidad para recabar fondos. Quiere esto decir que la supervivencia económica tampoco es un factor definitivo.

Existen factores adicionales pero las conclusiones para casi todos ellos son similares. No parece que haya un único elemento clarificador para establecer el grado de madurez de un proyecto de desarrollo en comunidad. Tampoco creo que dos o tres de ellos analizados simultáneamente definan el grado de madurez en un porcentaje lo suficientemente relevante como para permitirnos establecer un patrón a partir del cual comenzar un análisis comparativo serio usando la estadística. Me conformaría por ahora con poder aplicar el arte de la magia de los números como antesala de la ciencia.

Resulta difícil comparar si no puedes determinar las variables independientes del sistema.

Y tal vez sea ese parte del problema. Determinar el grado de madurez de un proyecto de desarrollo de software libre en comunidad, es decir, comparar unos proyectos con otros, requiere primero del establecimiento de las variables a estudiar, su relación y los entornos de laboratorio que se utilizarán para fijar todas las variables salvo aquella objeto de estudio en un entorno controlado, pasando posteriormente a evaluar el impacto que provocan esas variaciones en el propio sistema. Así, podrá entenderse mejor los cambios reales. Vamos, metodología básica de experimentación.

Arriba se han apuntado algunos factores que pueden convertirse en magnitudes independientes, pero hay más. Últimamente han salido varios desarrolladores enseñando estadísticas de commits que permiten hacer análisis de interés sobre la evolución de un proyecto. He asistido a alguna charla o conferencia en la que se han presentado estudios primarios sobre proyectos libres utilizando los grandes repositorios conocidos por todos como Sourceforge o Freshmeat. Y como yo no soy experto en la materia, probablemente todo este post carece de sentido porque hay gente que ha estudiado el tema y ha obtenido primeras conclusiones de interés. Si este es el caso, ruego al lector que me apunte los enlaces para salir de mi ignorancia. mi rss está saturado pero puedo borrar algunas entradas para dar cabida a nuevas 😉

Esta disertación tiene sentido para mí puesto que ando estableciendo el roadmap de ModularIT. Para su definición, casi todos los factores que estoy teniendo en cuenta son de carácter interno. Esto es lógico porque aún no somos más que un aspirante a proyecto de desarrollo en comunidad. Pero existe un pequeño espacio para definir tareas que importen a otros o que ayuden a otros a participar. Por tanto, si dispusiera de una definición clara de madurez, esto es, si existiera un punto final, sería posible en teoría establecer una ruta a seguir. Como no la hay… pues no queda más remedio que emplear muchas dosis de observación de otros proyectos, aplicar intuición y debate.

He tenido a lo largo de estos años la oportunidad de vivir de modo cercano dos proyectos muy distintos, LTSP primero y KDE después. También conozco Debian (he trabajado con desarrolladores de ese proyecto y he compartido tiempo y disertado con muchos algunos más), Ubuntu y ahora estoy comenzando a dar pasos pequeños en el conocimiento de GNOME (superficiales todavía). Me interesan especialmente el proyecto Apache y el kernel, pero mi tiempo es limitado…. De todos se aprende algo…pero no debe uno centrarse sólo en casos de éxito. Los fracasos enseñan. El caso twiki nos afecta en la empresa y es muy interesante, así como Compiere, PXES, los CMS en php y otros que hemos conocido en Grupo CPD con más o menos profundidad. Atesoramos alguna experiencia también en proyectos propios fallidos de la que hemos aprendido mucho.

Pero estamos en lo de siempre, si no sistematizas el aprendizaje, no es posible transmitir la experiencia a gran escala. Y para eso es necesario conocer el problema. No es posible conocer sin experimentar, ni experimentar sin definir, ni definir sin acuerdo. Y en el aspecto sobre el que ando liado no hay maldito acuerdo.

Esta es la parte dolorosa de estar situado en vanguardia, la conciencia que se adquiere sobre el error. Del mismo modo, se siente una especial exitación. Es la satisfacción de la curiosidad.

Maldita sea….hoy me gusta mi trabajo.