Liderazgo y toma de decisiones en el bazar en Software libre

De wiki EOI de documentación docente
Revisión del 00:37 28 feb 2012 de Jesús G Barahona (Discusión | contribuciones) (Página creada con «{{Sección |Título=Liderazgo y toma de decisiones en el bazar |Libro=Software libre |Capítulo=Ingeniería del software libre |Número sección=2 |Introducción=Raymond su...»)

(dif) ← Revisión anterior | Revisión actual (dif) | Revisión siguiente → (dif)
Saltar a: navegación, buscar


Estado de desarrollo de la sección: esbozo esbozo

Wikilibro: Software libre > Capítulo 6: Ingeniería del software libre

Sección 2

Liderazgo y toma de decisiones en el bazar
Raymond supone que todo proyecto de software libre ha de contar con un dictador benevolente, una especie de líder -que generalmente coincide con el fundador del proyecto- que ha de guiar el proyecto y que se reserva siempre la última palabra en la toma de decisiones. Las habilidades con las que ha de contar esta persona son principalmente las de saber motivar y coordinar un proyecto, entender a los usuarios y codesarrolladores, buscar consensos e integrar a todo aquél que pueda aportar algo al proyecto. Como se puede observar, entre los requisitos más importantes no se ha mencionado el que sea técnicamente competente, aunque nunca esté de más.

Con el crecimiento en tamaño y en número de desarrolladores de algunos proyectos de software libre han ido apareciendo nuevas formas de organizar la toma de decisiones. Linux, por ejemplo, cuenta con una estructura jerárquica basada en la delegación de responsabilidades por parte de Linus Torvalds, el dictador benevolente. De esta forma, vemos cómo hay partes de Linux que cuentan con sus propios dictadores benevolentes, aunque éstos vean limitado su poder por el hecho de que Linus Torvalds sea el que decida en último término. Este caso es un ejemplo claro de cómo la alta modularidad existente en un proyecto de software libre ha propiciado una forma de organización y toma de decisiones específica [narduzzo:modularity:03].

Nota: Existen voces que dicen que la forma de organizarse dentro de los proyectos de software libre se asemeja a la del equipo quirúrgico propuesta por Harlan Mills (de IBM) a principios de la década de los setenta y popularizada por Brooks en su mítico libro The Mythical Man-Month [brooks:mmm:75]. Aunque se pueden dar casos donde el equipo de desarrollo de alguna aplicación de software libre esté formado por un diseñador- desarrollador principal (el cirujano) y por muchos codesarrolladores que realizan tareas auxiliares (administración de sistemas, mantenimiento, tareas especializadas, documentación...), no existe en ningún caso una separación tan estricta y definida como propone Mills/Brooks. En cualquier caso, como bien apunta Brooks en el caso del equipo quirúrgico, en el software libre el número de desarrolladores que tienen que comunicarse para crear un sistema grande y complejo es más reducido que el número total de desarrolladores.

En el caso de Fundación Apache nos encontramos con una meritocracia, ya que cuenta con un comité de directores formado por personas que han contribuido de manera notable al proyecto. En realidad, no se trata de una rigurosa meritocracia en la que los que más contribuyen son los que gobiernan, ya que el comité de directores es elegido democrática y periódicamente por los miembros de la Fundación Apache (que se encarga de gestionar varios proyectos de software libre, entre ellos Apache, Jakarta, etc.). Para llegar a ser miembro de la Fundación Apache, se ha de haber aportado de forma continuada e importante a uno o varios proyectos de la fundación. Este sistema también es utilizado en otros proyectos grandes, como es el caso de FreeBSD o GNOME.

Otro caso interesante de organización formal es el GCC Steering Commitee. Fue creado en 1998 para evitar que nadie se hiciera con el control del proyecto GCC (GNU Compiler Collection, el sistema de compilación de GNU) y refrendado por la FSF (promotora del proyecto GNU) pocos meses después. En cierto sentido es un comité continuador de la tradición de uno similar que había en el proyecto egcs (que durante un tiempo fue paralelo al proyecto GCC, pero más tarde se unió a éste). Su misión fundamental es asegurarse de que el proyecto GCC respeta la Declaración de objetivos (Mission Statement) del proyecto. Los miembros del comité lo son a título personal, y son elegidos por el propio proyecto de forma que representen, con cierta fidelidad, a las diferentes comunidades que colaboran en el desarrollo de GCC (desarrolladores de soporte para diversos lenguajes, desarrolladores relacionados con el núcleo, grupos interesados en programación empotrada, etc.).

El liderazgo de un proyecto de software libre por parte de una misma persona no tiene por qué ser eterno. Se pueden dar básicamente dos circunstancias por las que un líder de proyecto deje de serlo. La primera de ellas es la falta de interés, tiempo o motivación para seguir adelante. En ese caso, se ha de pasar el testigo a otro desarrollador que tome el rol de líder del proyecto. Estudios recientes [barahona03:_unmoun] demuestran que en general los proyectos suelen tener un liderazgo que cambia de manos con frecuencia, pudiéndose observar varias generaciones de desarrolladores en el tiempo. El segundo caso es más problemático: se trata de una bifurcación. Las licencias de software libre permiten tomar el código, modificarlo y redistribuirlo por cualquier persona sin que haga falta el visto bueno del líder del proyecto. Esto no se suele dar generalmente, salvo en los casos en los que se haga con el fin de evitar deliberadamente precisamente al líder del proyecto (y un posible veto suyo a la aportación). Estamos ciertamente ante una especie de golpe de estado, por otro lado totalmente lícito y legítimo. Es por ello que uno de los objetivos que busca un líder de proyecto al mantener satisfechos a sus codesarrolladores es minimizar la posibilidad de que exista una bifurcación.

< Sección anterior
La catedral y el bazar

Sección siguiente >
Procesos en el software libre