En esta quinta entrega de la serie de posts sobre la gestión de software libre (traducción del texto original de Benjamin Mako Hill), "Mako" nos adentra en una de las partes más importantes sobre los proyectos de software libre, la de relacionarnos con desarrolladores que no forman parte de una empresa y lo que ello conlleva. En posts posteriores seguiremos en en esta "gran parte". En este, vemos cómo delegar trabajo a nuestros desarrolladores.

¡Qué aproveche!.

Manteniendo un proyecto: relacionándose con desarrolladores.

Una vez has puesto en marcha tu proyecto, has superado las más importantes trabas¹ en el proceso de desarrollo de tu programa. Tener unos buenos cimientos es esencial, pero el proceso de desarrollo es en sí mismo igualmente importante y provee las mismas oportunidades de fracaso. En las dos secciones siguientes, describiré el funcionamiento de un proyecto tratando el cómo mantener un esfuerzo de desarrollo a través de interacciones con desarrolladores y usuarios.

Liberando tu programa, éste se convierte en software libre. Esta transición es más que solamente una gran base de usuarios. Liberando tu programa como software libre, tu software se convierte en software de la comunidad de software libre. La dirección del desarrollo de tu software se reorganizará, desviará, y estará totalmente decidida por tus usuarios y, en gran parte, por otros desarrolladores de la comunidad.

La gran diferencia entre el desarrollo de software libre y el desarrollo de software propietario es la base de desarrolladores. Como líder de un proyecto de software libre, necesitas atraer y mantener desarrolladores de una manera que simplemente los líderes de proyectos de software propietario no tiene porqué preocuparse. Como la persona que lidera el desarrollo de un proyecto de software libre, tienes que aprovechar el trabajo de los colegas desarrolladores tomando decisiones responsables y por responsabilidad elegir no tomar decisiones. Debes dirigir a los desarrolladores sin ser prepotente o mandón. Necesitas esforzarte por ganar respeto y nunca olvidar darlo.

Delegando trabajo.

Ahora mismo, hipotéticamente me has seguido a través del comienzo de la programación de un componente de software, la creación de un sitio web y un sistema de documentación, hemos seguido adelante y (como se tratará en la Sección llamada Liberando Tu Programa) la hemos liberado al resto del mundo. El tiempo pasa, y si todo va bien, habrá personas interesadas y querrán ayudar. Los parches comienzan a llegar.

Como el padre de cualquier niño que crece, es el momento de estremecerse, sonreír y hacer lo más difícil en la vida de un padre: Es el momento de soltarlo.

Delegar es la manera política de describir este proceso de “soltar”. Es el proceso de pasar alguna responsabilidad y poder sobre tu proyecto a otro desarrollador responsable e implicado. Es difícil para cualquiera que haya invertido mucho tiempo y energía en un proyecto pero es esencial para el crecimiento de todo proyecto de software libre. Una persona sola no puede hacer tanto. Un proyecto de software libre no es nada sin la implicación de un grupo de desarrolladores. Un grupo de desarrolladores sólo puede mantenerse con respeto y con liderazgo y delegación responsables.

Cuando tu proyecto progresa, notarás a personas dedicando cantidades significantes de tiempo y esfuerzo para tu proyecto. Serán las personas que enviarán más parches, que crearán más entradas en las listas de correo, y entablando conversación en largos emails de debate. Es tu responsabilidad contactar con estas personas e intentar traspasar hacia ellos algún poder o responsabilidad de tu puesto como mantenedor del proyecto (si quieren). Hay varias maneras fáciles de hacerlo:

Como descargo de responsabilidad, delegar no tiene porqué significar que sea regulado por comité. En muchos casos lo es y se ha probado que funciona. En otros casos ha creado problemas. Gestionando proyectos al estilo Código Abierto defiende que “Los proyectos de Software de Código Abierto funcionan mejor cuando una persona es el claro líder de un equipo y toma las decisiones importantes (cambios de diseño, fechas de liberación, etcétera)”. Yo creo que esto es por lo general cierto pero quería instar a los desarrolladores a considerar las ideas de que el líder del proyecto no tiene porqué ser el fundador del proyecto y estos importantes poderes no necesitan recaer todos en una persona sino que el encargado de liberaciones puede ser diferente del jefe de desarrollo. Estas situaciones son políticamente delicadas por lo que sé prudente y asegúrate de que es necesario antes de correr a dar poderes a las personas.

Cómo delegar

Puedes encontrar que otros desarrolladores parecen incluso más experimentados o con más conocimientos que tú. Tu trabajo como mantenedor no significa que debas ser el mejor de los más brillantes. Significa que eres responsable de mostrar buen juicio y de reconocer qué soluciones son

mantenibles y cuáles no.

Como todo, es más fácil observar a otros delegar que hacerlo tú mismo. En una frase: está pendiente de otros desarrolladores capacitados que demuestran interés e implicación prolongada en tu proyecto e intenta traspasar responsabilidad hacia ellos. Las siguientes ideas podrían ser buenas para comenzar o ser buenas fuentes de inspiración:

Permite a un gran grupo de personas el acceso de escritura a tu repositorio CVS y haz verdaderos esfuerzos hacia el gobierno por comité.

Apache es un ejemplo de un proyecto que es llevado por un grupo de desarrolladores que votan las cuestiones técnicas importantes y la admisión de nuevos miembros y todos ellos tienen acceso de escritura en el repositorio principal de fuentes. Su proceso está detallado online.

El proyecto Debian es un ejemplo extremo de gobierno por comité. En números actuales, más de 700 desarrolladores tienen responsabilidad total para aspectos del proyecto. Todos estos desarrolladores pueden subir ficheros al servidor FTP principal, y votar las cuestiones más importantes. La dirección del proyecto está determinada por el contrato social del proyecto y unos estatutos. Para facilitar este sistema, hay equipos especiales (por ejemplo el equipo de instalación, el equipo de Lengua Japonesa) así como un comité técnico y un líder de proyecto. La responsabilidad principal del líder es, “nombrar delegados o decidir delegaciones al comité técnico”.

Aunque ambos proyectos operan en una escala que no será la de tu proyecto (al menos al principio), su ejemplo es de ayuda. La idea de Debian sobre un líder de proyecto que no puede hacer más que delegar sirve como una caricatura de cómo un proyecto puede implicar y motivar un número enorme de desarrolladores y crecer a un tamaño enorme.

Nombra públicamente a alguien como el encargado de liberaciones para una liberación específica.

Un encargado de liberaciones normalmente responsable de coordinar pruebas, hacer respetar un congelamiento de código, ser responsable de la estabilidad y el control de calidad, crear el empaquetado del software, y colocarlo en el lugar apropiado para su descarga.

Esta utilización del encargado de liberaciones es una buena manera de darte un respiro y traspasar a otra persona la responsabilidad de aceptación o rechazo de parches. Es una buena manera de definir claramente una parte del trabajo en el proyecto haciéndolo pertenecer a cierta persona y es una gran manera de darte un espacio para respirar.

Delega el control de toda una división².

Si tu proyecto decide tener divisiones (como se detalla en la Sección de nombre Divisiones estables y de desarrollo), podría ser buena idea nombre a alguien para que sea el jefe de una división. Si prefieres centrar tu energía en liberaciones de desarrollo y en la implementación de nuevas funcionalidades, pasa el control total sobre liberaciones estables a un desarrollador idóneo.

El autor de Linux, Linus Torvalds, declaró y coronó a Alan Cox como “ el hombre de los núcleos³ estables”. Todos los parches para nucleos estables van a Alan y, si Linus tuviese que dejar de trabajar en Linux por alguna razón, Alan Cox sería más que apropiado para adoptar ese rol como digno heredero del mantenimiento de Linux.