Capítulo 3. Infraestructura Técnica

Los proyectos de software libre dependen de tecnologías que aportan la captura selectiva e integración de la información. Mientras mejor se sean usadas estas tecnologías y se persuada a otros para utilizarlas, mayor será el éxito del proyecto.

Esto se vuelve más cierto mientras el proyecto crece. Un buen manejo de la información es lo que previene a un proyecto open source de colapsar bajo el peso de la Ley de Brook,^[25] la cual afirma que asignar fuerza de trabajo adicional a un proyecto retrasado lo demorará aún más. Fred Brooks observó que la complejidad de las comunicaciones en un proyecto se incrementa alcuadradodel número de participantes. Cuando solo unas pocas personas están involucradas, todos pueden hablar entre todos fácilmente, pero cuando cientos de personas están involucradas, ya no es posible que cada uno de los individuos se mantengan constantemente al tanto de lo que todos los demás están haciendo. Si dirigir bien un proyecto de software libre se trata de hacer que todos se sientan como si estuviesen trabajando juntos en la misma habitación, es obvio preguntar: ¿Qué sucedería si todas las personas en una habitación atestada de gente hablase a la vez?

Este problema no es nuevo. En una habitación no metafórica atestada, la solución es un procedimiento parlamentario : guías formales acerca de cómo tener discusiones en tiempo real en grupos grandes, cómo asegurarse de que las disensiones más importantes no se pierdan entre comentarios irrelevantes, cómo formar subcomites, cómo reconocer y registrar cuando se toman decisiones, etc. Las partes más importantes en un procedimiento parlamentario especifican como deben interactuar los grupos con su sistema de manejo de información. Algunos comentarios se hacen para el registro, otros no. El registro mismo es sujeto a manipulación directa y se entiende que no es una transcripción literal de lo que ha ocurrido, sino que es una representación a lo que el grupo está dispuesto a acordar sobre lo sucedido. El registro no es monolítico, sino que toma diferentes formas para diferentes propósitos. Comprende los minutos de encuentros individuales, una colección completa de todos los minutos de todos los encuentros, sumarios, agendas y sus anotaciones, reportes de comités, reportes de corresponsales no presentes, listas de acción, etc.

Dado que Internet no es realmente una habitación, no debemos preocuparnos acerca de replicar aquellas partes de los procesos parlamentarios que mantiene a algunas personas calladas mientras las demás hablan. Pero cuando nos referimos a técnicas de manejo de la información, proyectos open source bien dirigidos son como procesos parlamentarios en esteroides. Ya que todas las comunicaciones en los proyectos open source suceden por escrito, sistemas muy elaborados han evolucionado para enrutar y etiquetar apropiadamente los datos, para minimizar las repeticiones de forma que se eviten divergencias espuriosas, para almacenar y buscar los datos, para corregir información incorrecta u obsoleta y para asociar bits dispares de información con cada uno mientras que nuevas conexiones son observadas. Los participantes activos en los proyectos open source integran muchas de estas técnicas y a menudo realizaran complejas labores manuales para asegurar que la información sea dirigida correctamente. Pero todo el esfuerzo depende al final de un sofisticado soporte informático. Tanto que sea posible, los mismos medios de comunicación deben realizar éste enrutamiento, etiquetado y registro y debería mantener la información al alcance de los humanos de la manera más conveniente posible. En la práctica, por supuesto, los humanos siguen necesitando intervenir en muchos puntos durante el proceso y también es importante que estos programas hagan ésta intervención lo más conveniente. Pero por lo general, si los humanos se encargan de etiquetar y enrutar información acertadamente desde su primera entrada en el sistema, entonces el software debería estar configurado para dar el máximo uso posible a esa metadata.

El consejo de éste capítulo es intensamente práctico, basado en las experiencias con aplicaciones y patrones específicos. Pero el objetivo no es sólo enseñar una colección particular de técnicas. Es también demostrar, utilizando pequeños ejemplos, la actitud general que mejor fomentará el correcto uso de los sistemas de manejo de información en el proyecto. Esta actitud incluye una combinación de habilidades técnicas y don de gentes. Las habilidades técnicas son esenciales porque las aplicaciones de manejo de información siempre requieren cierta configuración y además una cierta cantidad de mantenimiento y puesta apunto mientras nuevas necesidades vayan surgiendo (por ejemplo, mirad la discusión de como manejar el crecimiento del proyecto en “Pre-filtrado del gestor de fallos” más adelante en éste capítulo). El don de gentes es necesario porque la comunidad humana también requiere de cierto mantenimiento: no siempre es inmediatamente obvio como utilizar estas herramientas para obtener una ventaja completa y en algunos casos los proyectos tienen convenciones conflictivas (por ejemplo, la discusión de como crear cabeceras Reply-to en los mensajes salientes de las lista de correos, en “Listas de Correo / Foros de Mensajes”). Todos los involucrados en el proyecto van a necesitar ser animados, en el momento correcto de la forma correcta, para que sigan manteniendo la información del proyecto bien organizada. Mientras más involucrado esté el contribuyente, más complejas y especializadas serán las técnicas que se esperará que aprendan.

El manejo de información no tiene soluciones rápidas ya que existen demasiadas variables. Pueden que finalmente se tenga todo configurado justo como se desea y tener a la mayoría de la comunidad participando pero luego el crecimiento del proyecto hace de estas practicas no escalables. El puede que el crecimiento del proyecto se estabilice y que la comunidad de usuarios y desarrolladores acuerden una relación confortable con la infraestructura técnica pero llega alguien e inventa un nuevo servicio de manejo de información completo y pronto muchos de los recién llegados empezarán a preguntar que por qué no es utilizado en el proyecto— por ejemplo, esto sucedió en muchos proyectos de software libre anteriores a la invención del Wiki (más en en.wikipedia.org/wiki/Wiki) y más recientemente ha estado pasando en proyectos cuyos flujos de trabajo fueron desarrollados antes de la aparición de los pull-requests de GitHub (ver “”) como la forma canónica de empaquetar las contribuciones propuestas. Muchas cuestiones de la infraestructura son materia de juicio, incluyendo las desventajas entre la conveniencia de aquellos generando información y la conveniencia de aquellos quienes la consumen o entre el tiempo requerido para configurar el software de manejo de la información y los beneficios que le brinda al proyecto.

Cuidado con la tentación de automatizar demasiado, esto es, automatizar cosas que realmente requieren de atención por parte de los humanos. La infraestructura técnica es importante, pero lo que hace que los proyectos de software libre funcionen es el cuidado—y la expresión inteligente de éste cuidado—de los humanos involucrados. Principalmente, la infraestructura técnica está para ofrecer medios fáciles para aplicar dichos cuidados.