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.