Roles en un proyecto de Software Libre

Si planeas empezar con un proyecto de Software Libre desde cero, puede que este apartado sea irrelevante. Parece que los roles empiezan a ser importantes cuando hay una cierta cantidad involucrada. Pero definir y saber qué y quién va ha realizar determinadas tareas, puede ser crucial en ciertos momentos para que el proyecto siga adelante. Es fácil que un proyecto de Software Libre tenga muchos colaboradores, por su propia naturaleza.

En 1975, Fred Brooks definió la Ley de Brooks, decía que cuando un proyecto de software crece, lo hace de manera exponencial, y cuando además está retrasando su salida el Manager tiende añadir a mas gente nueva al proyecto para terminar antes. Esto es un grave error pues esa gente nueva no conoce el modelo y tiene que ponerse al día, y al final acaban picando código alocadamente.
En Software Libre cuando mas grande es el proyecto, más propenso a tener roles. Como una gran orquesta, en la que cada uno debe dar su parte en su debido tiempo. Consiguiendo así una armonía.

Paso a describir una serie de roles básicos en cualquier proyecto:

Desarrolladores

Los creadores de código. Deben informar de sus cambios, no sirve de nada ser un lobo solitario y desarrollar por tu cuenta. Eligen que entorno de desarrollo se va a utilizar, aunque hay casos en los que no hay definido un IDE. Sus objetivos están dirigidos por lo que dicta la comunidad, pero sin llegar a la pasividad. No todos los desarrolladores tienen derecho a commit en el repositorio del proyecto, pues hay casos que deben ser revisados. Una vez realizado ese commit, hay que actualizar la lista de funcionalidades o errores corregidos.

Maintainers


Existen muchas subcategorias:

  • Patch Manager: Puede que el desarrollador no da a basto con los Bugs, y el Patch Manager debe canalizar esto. Debe acotar los bugs, ver cual es importante o no, si existe el patch que alguien lo revise o ellos mismos.
  • Manager de traduccion: documentación, código, internacionalización u localización. Portar código de un lenguaje de programación hacia a otro. Los mensajes de la interfaz. Los manuales. 
    • Internacionalizacion trata de adaptar el software para otras culturas y/o idiomas, favorece la protabilidad. Da soporte para distintas monedas, soporte para unicode.
    • Localizacion son los mensajes de la interfaz de usuario.
  • Documentation manager: la guia del usuario, es una tarea tediosa. Se pueden vender como guías.
  • Issue Manager: Parecido al patch manager, pero también atiende a las peticiones. Encaja la oferta con la demanda.
  • FAQ Manager: Cuando un proyecto es grande es necesario. La tarea es sencilla, leer los foros y wikis en busca de preguntas. Tratar de buscar las mas frecuentes. Se formula bien la pregunta y se responde, y reorganizarlo para que no exista preguntas duplicadas y organizarlo por categorías.
  • Release Manager: Se encarga de las nuevas release, en Ubuntu son cada 6 meses. Suele ser un cargo que cambia mucho de persona, porque es una tarea agotadora. Tiene en la cabeza el RoadMap, tiene que cumplirlo, y si se desvía, trata de que haya consenso. Coordina todo para que haya homogeneidad.

Documentation writer

Lo que más importa es que escriba bien y no mucha cantidad. Lo mas conciso posible, con posibilidad de crear una guia del desarrollador. Un buen ejemplo GNOME Project system-admin-guide. También debe escribir/revisar la documentación de Man.

Distribution Developer

Se encarga de la homogeneidad del proyecto de paqueteria. Revisa las licencias. 

Traductores

Hasta que el desarrollador no termina, no empiezan a traducir. Esto es debido porque puede haber cambios finales, en el que se muestre o se deje de mostrar un mensaje por pantalla. Por lo que tienen un esfuerzo extra antes de la siguiente release, pues siempre se están cambiando código contiuamente.

Tester

Personas encargadas de probar el programa, su correcto funcionamiento, o incluso forzar para que de errores. El skill de estos tester no es meramente técnico, cade vez es más social y útil por que da una visión más amplia del usuario final.

Community Manager

Construir, alimentar y expandir la comunidad, son las prioridades de esta persona. Que exista buen ambiente, proporciona atajos para encontrar a la persona que quieres, pues si alguien se quiere incorporar a realizar una tarea muy específica, es preferible que tenga contacto con las personas que han desarrollado o modificado esa parte de código. Al final puede acabar como un relaciones publicas. Cualquier proyecto colaborativo es necesario este rol, no solamente en proyectos de software. Ayudan a encontrar fuentes de ingresos. No se encarga directamente en todo, delega todo. Tiene un rango multidisciplinar. Son gente hiperactiva. Escuchan. Ayuda la colaboracion entre varios roles. Periodicamente hacen brainstorming, conferencias, para aportar nuevas ideas. Recomendaciones y guias de buena conducta.

Project Leader

Persona mas relevante o influencia en el proyecto, o por ser el fundador o porque te lo hayas ganado (Meritocracia). Por ser el fundador es fácil, por estar desde el principio y puso las reglas, el ejemplo mas claro es Linus Torvalds. Por meritocracia, es más difícil, se pueden equivocar sin tantos problemas como el fundador, pues el fundador lo debe conocer mejor que nadie. A veces se encuentran dictadores benevolentes, cuando se detecta que hay opiniones enfrentadas, se pide la actuación del dictador benevolente y se aplica su decisión.Capturan la esencia de la motivación del proyecto.

Todos estos roles no tienen porque ser obligatorios. Aunque muchos de ellos son indispensables, como los desarrolladores y un community manager que promocione el proyecto. Incluso se pueden crear nuevos roles, como los encargados del diseño de la aplicación, como su iconografía y darle un resultado vistoso. Antes este rol no tenía mucho sentido, pero poco a poco, la interfaz del usuario ha ido tomando un papel importante en el desarrollo de software. Por otro lado, llegar a conseguir uno de estos roles en ciertos proyectos, puede ser muy fácil en algunos casos o todo lo contrario. En el proyecto Apache tiene un proceso fuerte para incorporar a nuevas personas.

La finalidad de estos roles, es saber lo que tiene que hacer cada persona, en cada momento. También ayuda a involucrar a más gente el proyecto, que no tienen skill de programador, pero quieren colaborar igualmente. Nunca hay que rechazar una colaboración ;)


0 comentarios:

Publicar un comentario