Tabla de contenidos
Las primeras preguntas que la gente se hace sobre el software libre son "¿Cómo funciona? ¿Cómo se mantiene el proyecto? ¿Quién toma las decisiones? Siempre quedo insatisfecho con respuestas conciliadoras sobre la estima del mérito, el espíritu de cooperación, el código que se expresa por si mismo, etc. El caso es que sobre esto no hay una respuesta fácil. La meritocracia, la cooperación, y un código que funciona son partes de ella, pero aportan muy poco para explicar como funciona realmente un proyecto en el andar de todos los días, y nada dice sobre cómo se resuelven los conflictos.
Este capítulo trata de mostrar la estructura subyacente que los proyectos exitosos tienen en comun. Me refiero con el término "exitosos" no solamente a la calidad técnica, sino también a la salud operacional y la capacidad de sobrevivencia. La salud operacional es la capacidad efectiva del proyecto de incorporar las contribuciones de nuevos códigos y nuevos desarrolladores, y de asumir la responsabilidad de los informes de errores que ingresan. Capacidad de sobrevivencia es la posibilidad de que el proyecto exista independientemente de algún participante o auspiciante en particular— tómelo como la posibilidad que tiene el proyecto para continuar aún cuando alguno de sus miembros fundadores tuviera que pasar a ocuparse de otras cosas. El éxito técnico no es difícil de alcanzar, pero sin una base robusta de desarrollo y un fundamento social, un proyecto puede resultar incapaz de manejar el crecimiento que el éxito inicial aporta, o la ausencia de algún individuo carismático.
Hay varias maneras de alcanzar este tipo de éxito. Algunas suponen una estructura formal de supervisión, por la que se resuelven los debates, se aceptan (o rechazan) nuevos desarrolladores, se planifican nuevas características, etc. Otras requieren menos estructura formal, pero más aplicación en conciencia, para producir una atmósfera de armonía en la que la gente puede confiar como una formade facto de supervisión. Ambos caminos llevan al mismo resultado: un sentido de permanencia institucional, ayudado por los hábitos y procedimientos que son bien comprendidos por todos los que participan. Estas características son todavía más importantes en los sistemas que se organizan a si mismos que en aquellos que están controlados centralmente, porque en los sistemas que se organizan a si mismos, cada uno es conciente que unas pocas manzanas pueden arruinar todo el cajón, al menos por un tiempo.
El ingrediente indispensable que une a los desarrolladores en un proyecto de software libre, y que los lleva a comprometerse cuando es necesario es la "forkabilidad" del código: la capacidad de cada uno de tomar una copia del código fuente y usarlo para abrir un proyecto que compita con el original, evento que se conoce como "fork". Lo que aparece como paradójico aquí es que la posibilidad de los "forks" es una fuerza mucho mayor en los proyectos de software libre que los "forks" reales, los que son muy raros. Puesto que un "fork" es malo para todos (por razones que se examinan en detalle en “Forks” en Capítulo 8, Coordinando a los Voluntarios), cuanto más seria sea la amenaza de un "fork", tanto mas son las personas que se comprometen a evitarlo.
Los "forks", o más bien la posibilidad de que se produzca un "fork", es la razón por la cual no hay verdaderos dictadores en los proyectos de software libre. Esto puede ser una expresión sorprendente, considerando que es muy común oir que alguien es llamado el "dictador" o el "tirano" en algún proyecto de fuente abierta. Pero esta tiranía es especial, muy diferente de lo que comúnmente se entiende por esa palabra. Imaginaos un rey cuyos súbditos pudieran copiar todo su reino en cualquier momento y trasladarse a la copia para gobernarla como creen que corresponde. ¿No sería el gobierno de ese rey muy diferente de otro cuyos súbditos están obligados a permanecer bajo su gobierno, sin importar lo que él haga?
Por esta razón aún aquellos proyectos que no están organizados formalmente como democracias, son en la práctica democracias en el momento en que se toman las decisiones importantes. La replicabilidad incluye a la "forkability"; "forkability" incluye al consenso. Podría bien darse el caso de que todos quieran apoyarse en un líder (el ejemplo más famoso es el de Linus Torvalds durante el desarrollo del kernel de Linux), pero esto es porque ellos así lo eligen, de una manera ajena a todo cinicismo y en una forma no siniestra. El dictador no tiene un dominio mágico sobre el proyecto. Una propiedad de todas las licencias de fuente abierta es que no se le da a una parte más poder que a cualquier otra para decidir cómo se debe usar o cambiar el código. Si el dictador de repente comenzara a tomar malas decisiones, se produciría una agitación, seguida eventualmente por un levantamiento y por un "fork". Excepto que, por supuesto, muy rara vez las cosas llegan tan lejos, porque antes el dictador busca soluciones de compromiso.
Pero, sólo porque la forkability pone un límite al abuso de poder que uno puede ejercer en un proyecto, eso no quiere decir que no hayan diferencias importantes en el modo como se gobiernan los proyectos. Nadie desea que en todas las decisiones se llegue a la pregunta de última instancia de quien está considerando un fork. Eso pasaría rápidamente a ser muy agobiante, restando energía necesaria para el trabajo efectivo. Las dos secciones que siguen examinan los modos de organizar los proyectos para que la mayoría de las decisiones se tomen naturalmente. Estos dos ejemplos son los casos extremos idealizados; muchos proyectos quedan de alguna manera incluidos entre esos casos.
El modelo de un dictador benevolente es precisamente lo que se describe así: La autoridad final de la toma de decisiones reside en una persona, de quien se espera que, por la fuerza de su personalidad o experiencia, la use sabiamente.
Auque el término estándar de esta función es "dictador benévolo" (o DB), sería mejor que lo imaginemos como un "árbitro aprobado por la comunidad" o un "juez". En general, los dictadores benevolentes no toman realmente las decisiones, ni siquiera la mayoría de las decisiones. No es probable que una persona pueda tener todo el conocimiento para tomar decisiones buenas y coherentes en todas las áreas de un proyecto, y además, los desarrolladores de calidad no se acercarán al proyecto a no ser que tengan alguna influencia en su dirección. Por lo que los dictadores benevolentes no se comportan como mandones. Por el contrario, dejan que las cosas funcionen por sí solas por el intercambio de ideas y la experimentación, siempre que eso sea posible. Ellos mismos participan en esas discusiones, como un desarrollador cualquiera, a menudo delegando a un administrador de area que tenga mas conocimiento. Solamente cuando queda claro que no se puede alcanzar un consenso, y cuando la mayoría del grupo desea que alguien guíe la decisión para que el desarrollo pueda seguir adelante, pisan firme y dicen: "Esta es la forma que tiene que ser". Una característica compartida por casi todos los dictadores benevolentes exitosos es que tienen un rechazo a tomar decisiones con un "así tiene que ser"; esta es una de las razones por la permanecen en la función.
Ser un DB requiere una combinación de características. Se necesita, antes que nada, una cierta delicadeza para juzgar su propia influencia en el proyecto, lo que a su vez lleva a sujetar los primeros impulsos. En los primeros pasos de una discusión uno no debe expresar opiniones y conclusiones con tanta seguridad que los otros sientan que es inútil opinar en contra. La gente debe sentirse libre de ventilar sus ideas, aunque sean tontas. Es inevitable que el DB sugiera alguna idea tonta de vez en cuando, y por lo tanto esta función requiere la disponibilidad de reconocer cuando uno haya tomado una mala decisión— si bien es ésta una característica sencilla que cualquier buen desarrollador debe tener, especialmente si permanece en el proyecto por mucho tiempo. Pero la diferencia es que el DB puede darse el lujo de equivocarse de vez en cuando sin tener que lamentar daños permanentes en su credibilidad. Los desarrolladores más jóvenes pueden no tener tanta seguridad, y por eso los DB deben expresar sus críticas o decisiones en contra con mucha delicadeza para contrapesar la fuerza psicológica y técnica que tienen sus palabras.
El DB no necesita tener una habilidad técnica superior que supere a todos los que están en el proyecto. Tiene que saber lo suficiente como para trabajar en el código, y entender y comentar cualquier cambio en consideración, y eso es todo. La posición del DB no se adquiere ni mantiene en virtud a una habilidad de codificar intimidatoria. Lo que si es importante es la experiencia y un sentido general del diseño —no necesariamente la habilidad de producir un buen diseño a pedido, pero si la habilidad de reconocer el buen diseño, provenga de donde proveniere.
Es común que un dictador benevolente sea el fundador del proyecto, pero esto es más una correlación que una causa. El tipo de cualidades que permite poner en marcha con éxito un proyecto son exáctamente las cualidades que cualquier DB debe tener— competencia técnica, habilidad de persuadir para que otro se una, etc.—. Y por supuesto, los fundadores se inician con una cierta senioridad automática, que puede ser suficiente a menudo para que el dictador benevolente aparezca por el camino de menor resistencia para todos aquellos a quienes les incumbe.
Recordar que la amenaza de un fork vale para los dos sentidos. Un DB puede hacer un fork de un proyecto tan facilmente como cualquier otro, y ocasionalmente lo han hecho, cuando sienten que la dirección que está tomando el proyecto es diferente de donde la mayoría de los desarrolladores quieren ir. Por causa de la forkabilidad, poco importa si el dictador benevolente tiene privilegios de root (que corresponden al administrador del sistema) en el servidor principal del proyecto. A veces la gente se refiere al control del servidor como si fuera la mayor fuente de poder en un proyecto, pero de hecho es irrelevante. La posibilidad de agregar o quitar las palabras clave para hacer commit en un servidor afecta solo a la copia del proyecto que reside en el servidor. Un abuso constante de ese poder, sea por el DB o por cualquier otro, va a terminar simplemente con un cambio del desarrollo en un servidor diferente.
Si el proyecto tendrá un dictador benevolente o si va a funcionar mejor con un sistema menos centralizado, depende ampliamente de quién es el que va a cumplir con esa función. Por lo general es algo muy obvio desde el comienzo saber quién va a ser el DB, y entonces todo se encamina en ese sentido. Pero si no hay un candidoto obvio para el DB, puede ser que el proyecto se incline a usar un proceso descentralizado de tomas de decisión, como se va a describir en la prósima sección.