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 en ), 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. A medida que el proyecto avanza, se tiende a pasar del modelo del dictador benevolente a los sistemas más abiertaente democráticos. Este paso no se produce necesariamente por la insatisfacción causada por un DB. Es que el gobierno basado en el grupo llega a ser estable en su evolución, para usar así una metáfora biológica. Siempre que un dictador benevolente se baja o intenta difundir la responsablidad de tomar decisiones entre todos por igual, se da la oportunidad para que el grupo se asiente en un nuevo sistema no-dictatorial—estableciendo una constitución, por así decirlo. Puede ser que el grupo no aprovecha la primera oportunidad, ni quizás tampoco la segunda, pero en algún momento lo hará; y una vez hecho, es muy difícil que esta decisión se vuelva atrás. Y el sentido comun lo explica: si un grupo de N individuos tuviera que investir una persona con poderes especiales, eso significaría que N - 1 personas tuvieron que aceptar que sus influencias individuales se disminuyan. Normalmente la gente no quiere hacer cosas como esa. Y si las hiciera, todavía la dictadura que de allí resulte sería condicional: el grupo que unge a un DB, es claramente el grupo que puede deponer al DB. Por lo tanto, una vez que el proyecto a pasado de un liderazgo carismático individual a un sistema más formal basado en el grupo, muy rara vez vuelve para atrás. Los detalles de cómo funcionan esos sistemas varían ampliamente, pero hay en ellos dos elementos comunes: uno, el grupo funciona por consencio la mayoría del tiempo; dos, hay un mecanismo formal de votaciones para los casos en que el consenso no puede alcanzarse. Consenso significa solamente un acuerdo que todos aceptan de una vez por todas. No es un estado ambiguo: un grupo alcanza el consenso en un asunto particular cuando alguien expresa que se ha alcanzado un consenso y nadie contradice esa afirmación. La persona que propone el consenso debe, por cierto, dejar en claro cual es el consenso alcanzado, y que acciones deben tomarse en consecuencia de él, si es que ésto no resulta obvio. La mayoría de las conversaciones de un proyecto son sobre los asuntos técnicos, como el modo correcto de corregir algún error, la conveniencia o no de agregar un asunto, la forma estricta como un documento se enlaza, etc. Un gobierno basado en el consenso funciona bien porque se entrelaza con la discusión técnica y se confunde con ella silenciosamente. Al terminar una discusión, generalmente hay acuerdo sobre cual es el camino a seguir. Alguien hace una intervención conclusiva, que es al mismo tiempo un resumen de lo que se ha ido decidiendo y queda como una propuesta implícita de consenso. Esto ofrece una última oportunidad para que alguien diga "Un momento, no estoy de acuerdo. Debemos reconsiderar esto un poco más" En decisiones de poca importancia que no ofrecen discusión, la propuesta de consenso es implícita. Por ejemplo, cuando un desarrollador hace un commit de una reparación de error, el mismo commit es la propuesta de consenso: "Supongo que todos estamos de acuerdo en que este error debe ser corregido, y esta es la manera de hacerlo." Por supuesto, el desarrollador no lo dice; simplemente hace el commit de la reparación, y los demás no se preocupan de manifestar su acuerdo, porque el silencio es el consentimiento. Si alguien hace el commit de un cambio que resulta no tener consenso, se produce simplemente una discusión sobre el cambio como si todavía no estuviera incluido como cambio. La explicación de por qué esto funciona es el tema de la próxima sección. Mantener el código fuente del proyecto bajo el control de versión significa que la mayoría de las decisiones pueden fácilmente deshacerse. La manera corriente para que esto pase es que alguien haga commit de un cambio pensando que todos van a aceptarlo con gusto, y después encontrarse con las objeciones ante el hecho. Una forma típica de esas objeciones es comenzar con las disculpas del caso por no haber intervenido en discusiones anteriores, aunque esto se puede omitir si el discrepante no encuentra registros de tales discusiones en los archivos de la lista de correos. En cualquier caso, no hay motivos para que el tono de la discusión sea diferente después del cambio introducido que antes. Cualquier cambio puede ser revertido, al menos antes de que se introduzcan cambios dependientes (es decir, nuevo código que se daña si el cambio original es quitado de repente). El sistema de control de versión permite que el proyecto deshaga los efectos de malas ideas o propuestas ligeras. Esto, a su vez, le da la libertad a la gente para que confíe en sus instintos y aprenda cuanta consulta es necesaria antes de hacer algo. También significa que el proceso de consensuar no necesita ser muy formal. Muchos proyectos manejan esto por instinto. Los cambios menores pueden ir sin discusión, o con una discusión mínima seguida por algunos acuerdos. En cambios de mayor importancia, especialmente aquellos que pueden desestabilizar una parte del código, la gente espera uno o dos días antes de suponer que hay consenso. La razón es que nadie puede ser dejado de lado en una conversación importante simplemente por no haber inspeccionado su correo con la frecuencia debida. Entonces, cuando alguien se siente seguro que sabe lo que tiene que hacer, no para en mientes y lo hace. Esto se aplica no sólo al software fijo, sino a las actualizaciones de la Web, a cambios en la documentación y a cualquier otra cosa que no sea controversial. Generalmente se darán pocos casos en los que la acción tenga que ser deshecha, y estos pueden ser tratados individualmente en cada caso. Por supuesto que no se debe incentivar a la gente para que sea obstinada. Hay todavía una diferencia psicológica entre una decisión bajo discusión y una que ya haya tenido efecto, por más que se diga que es técnicamente reversible. La gente siente que el momento es un aliado de la acción, y que se sentirán más reacios a revertir un cambio que a prevenirlo en el primer instante. Si un desarrollador se abusa de este principio y rápidamente hace commits de cambios que generan controversia, ciertamente la gente puede y debe quejarse, y mantener a ese desarrollador en un estándar estricto hasta que las cosas mejoren. Inevitablemente, algunos debates no llegarán al consenso. Cuando no haya otro medio de salir del callejón, la solución es votar. Pero antes que se llegue a la votación, debe aclararse unas cuantas opciones del ballotage. De nuevo en este caso el proceso de discusión técnica se integra suavemente con los procedimientos de toma de decisión del proyecto. El tipo de asuntos que llega a votación implican a menudo temas complejos, llenos de facetas. En cualquiera de tales discusiones complicadas, hay a menudo una o dos personas que hacen las veces de negociador honesto: aportan periódicamente la síntesis de los argumentos y siguen las líneas de los puntos centrales del desacuerdo (y del acuerdo). Estas síntesis ayudan a que todos estimen el progreso que se va haciendo, y les recuerda a todos cuáles asuntos quedan pendientes. Estas síntesis podrán servir como modelos para una propuesta de votación, en caso de que ésta se vuelva necesaria. Si los negociadores honestos se han desempeñado bien en su oficio, estarán en condiciones de llamar a votación cuando llegue el tiempo, y todos querrán usar las propuestas vertidas en esas síntesis para organizar la votación. Los negociadores también serán partícipes del debate; no es necesario que ellos queden fuera de la votación, en tanto puedan entender y representar los puntos de vista de los demás, y no dejen que sus sentimientos partidarios les impidan producir síntesis del estado del debate en una forma neutral. Normalmente la organización de la votación no cae en la controversia. Cuando llega el tiempo de votar, el desacuerdo ha sido analizado y reducido a unas pocas cuestiones, bien etiquetadas y acompañadas de descripciones concisas. De vez en cuando un desarrollador hará una objeción sobre la forma de votar. A veces esta preocupación es legítima, por ejemplo, cuando una opción importante ha sido dejada de lado o no ha sido presentada con precisión. Pero otras veces un desarrollador puede tratar de impedir lo inevitable, quizás porque se da cuenta que el voto no va acompañar su idea. Ver en para ver como tratar este tipo de obstruccionismo. Recuerde de especificar el sistema de votación, puesto que hay varias formas, y la gente puede tener falsas expectativas sobre el procedimiento que va a ser usado. Una buena opción es la votación por aprobación, en la que cada votante puede votar por todas las opciones que quiera, dentro de las opciones presentadas. La votación por aprobación se resuelve simplemente explicando y contando, y a diferencia de otros métodos, solo requiere una ronda de votación. Ver para mas detalles acerca de la votación por aprobación y otros sistemas de votación, pero tratar de no caer en un debate largo sobre cuál deba ser el sistema que se use (ya que se verán atrapados en el círculo de tener que votar para decidir cómo votar!) Una razón para defender la votación por aprobación como una buena opción es que es difícil que alguien se oponga—es lo más transparente que puede ser una votación. Finalmente, voto secreto, voto abierto. No hay necesidad de guardar secretos o aparecer como anónimos en una votación sobre asuntos que se han debatido públicamente. Cada participante pone su voto en la lista de correo del proyecto, de modo que cualquier observador pueda hacer el conteo y verificar el resultado, y que todo quede archivado. Lo más difícil en la votación es determinar cuando se debe votar. Generalmente la votación tiene que ser algo fuera de lo común—el último resorte cuando todas las otras opciones han fallado. No tome a la votación como el gran camino para resolver los debates. No lo es. Finaliza la discusión, y por tanto finaliza el pensamiento creativo sobre el problema. Mientras la discusión está en el tapete, existe la posibilidad de que alguien aporte una solución nueva, que sea del agrado de todos. Sorprendentemente, esto ocurre a menudo: un debate abierto puede producir un giro nuevo del pensamiento sobre el problema, y llevar a una propuesta que eventualmente satisfaga a todos. Aún cuando no surja una propuesta nueva, todavía es mejor negociar una solución de compromiso que poner un voto. Luego de una solución de compromiso, todos quedan algo insatisfechos, mientras que después de una votación unos quedan contentos y otros en desánimo. Desde un punto de vista político, la primera situación es preferible: al menos cada uno puede sentir que su desánimo es el precio de su accionar. Puede estar insatisfecho, pero todos lo están. La ventaja principal de la votación es que se cierra la cuestión y se puede seguir adelante. Pero el arreglo se hace por un conteo de votos, en lugar de un diálogo racional que conduzca a todos a la misma conclusión. Cuanto más experiencia tiene la gente en proyectos de fuente abierta, les encuentro menos dispuestas a querer arreglar las cuestiones por medio de la votación. Tratarán primero de explorar las soluciones que previamente no hayan sido consideradas, o entrar en soluciones de compromiso más ajustadas de lo que planearon en un comienzo. Hay varias técnicas para prevenir una votación prematura. La más obvia es decir simplemente "no creo que ya estemos listos para una votación", y explicar por qué no. La otra es pedir que sin compromiso se levanten las manos. Si la respuesta tiende claramente hacia un lado, necesariamente va a inclinar al otro grupo a querer encontrar soluciones de compromiso, obviando así la necesidad de la votación formal. Pero la manera más efectiva es simplemente ofrecer una solución nueva, o un nuevo punto de vista para una sugerencia antigua, de modo que la gente se re-conecte con los temas en lugar de repetir meramente los mismos argumentos. En algunos casos raros, todos pueden concordar que las soluciones de compromiso presentadas son perores que cualquiera de las soluciones en consideración. Cuando esto ocurre, la votación no es tan objetable, por un lado porque es muy probable que se va a llegar a una solución superior, y por otro porque la gente no se va a desanimar con el resultado, cualquiera sea la opción que gane. Aún en estos casos, no hay que apurarse en votar. La discusión que arriba en una votación es lo que educa al electorado, y detener pronto la discusión puede disminuir la calidad del resultado. (Fijarse que este consejo de ser reacio a las votaciones no se aplican a la votación sobre cambio-inclusión que se describe en en . Allí, la votación es más bien un mecanismo de comunicación, un medio de registrar el propio compromiso en el proceso de revisión de cambio de modo que todos puedan decir cuánta revisión ha recibido un cambio dado.) Al tener un sistema de votación aparece la cuestión del electorado: ¿A quién le corresponde votar? Este asunto puede convertirse en delicado, porque fuerza a que el proyecto reconozca oficialmente que hay gente con mayor compromiso, o con mejores apreciaciones que los otros. La mejor solución es simplemente tomar la distinción existente, el acceso a los commits, y asociar los privilegios del voto en eso. En proyectos en que existan accesos completos y parciales a los commits, la cuestión de permitir el voto a los que tienen commit parcial dependerá en gran manera de los procesos por los que el commit parcial fue otorgado. Si el proyecto lo maneja con liberalidad, por ejemplo como una manera de mantener muchas herramientas de contribución de terceras partes en el repositorio, entonces debe dejarse en claro que el acceso al commit parcial hace referencia a los commits, no a la votación. Naturalmente la implicación inversa se mantiene: puesto que los que tienen commit completo tendrán privilegios de votación, deben elegirse no solo como programadores, sino también como miembros del electorado. Si alguien muestra tendencias disruptivas u obstruccionistas en la lista de correo, el grupo debe ser muy cauto en incluirlo entre los que hacen commits, auque sea una persona capacitada técnicamente. E sistema de votación debe ser usado para elegir a los nuevos miembros que hacen commit, sea completo o parcial. Y aquí aparece una de las circunstancias raras en donde el voto secreto es apropiado. No pueden ponerse los votos para los que hacen commits en una lista de correo pública, porque se pueden herir los sentimientos y la reputación de un candidato. En lugar de eso, la forma común es que los que tienen voto lo pongan en una lista de correo privada donde solamente estén los que pueden hacer commits, para proponer que alguien sea habilitado para hacer commits. De esta manera todos pueden expresarse libremente, sabiendo que la discusión es privada. A menudo no habrá desacuerdo, y no se necesitará votar. Luego de esperar unos días para asegurarse que todos tuvieron oportunidad de responder, el proponente envía un mail al candidato y le ofrece el acceso a los commits. Si hay desacuerdo, se inicia una discusión como para cualquier otro asunto, con la posibilidad de terminar en una votación. Para que este proceso sea abierto y transparente, tambien tiene que ser secreto el hecho que hay una discusión en curso. Si la persona en consideración sabe lo que está ocurriendo, y luego no se le ofrece un acceso de commit, puede concluir que él ha perdido el voto, y sentirse herido por ello. Por supuesto, si alguien explícitamente pide el acceso al commit, entonces no hay nada que hacer sino considerar la propuesta y explícitamente aceptarle o rechazarle. Si ocurre lo segundo, tiene que hacerse con sumo tacto, con una explicación clara: "Nos agradan tus aportes, pero todavía no hemos visto lo suficiente", o "Hemos tenido en cuenta todos tus aportes, pero se han tenido que hacer considerables ajustes antes de poder aplicarlos, por lo que todavía no nos sentimos confiados para darte el acceso al commit. Esperamos que esto cambie con el tiempo". Recordar que lo que se dice puede caer como un golpe, dependiendo del grado de confianza que se tenga con la persona. Tratar de verlo desde su punto de vista, en el momento que se escribe el mail. Puesto que agregar un nuevo miembro que pueda hacer commits es una decisión más secuencial que otras decisiones, algunos proyectos tienen requerimientos especiales para el voto. Por ejemplo, puede requerirse que la propuesta reciba por lo menos n votos positivos y que no tenga ningún voto negativo, o que cierta supermayoría vote a favor. Los parámetros exactos no son importantes; la idea principal es que el grupo debe ser cuidadoso al otorgar acceso a los commits. Similarmente, o todavía más estrictamente, se aplican requerimientos especiales a la votación para quitar el acceso a los commits, y ojalá que eso nunca sea necesario. Ver en para más aspectos sobre la no votación para agregar o quitar acceso a los commits. Para ciertas clases de votaciones, puede ser útil expandir el electorado. Por ejemplo, si los desarrolladores no tienen una idea clara para decidir si una interfase dada se adapta al modo como la gente realmente usa el software, una solución es hacer una votación entre todos los suscriptos en la lista de correo del proyecto. Estas son realmente encuestas más que votaciones, pero los desarrolladores pueden acordar que los resultados sean vinculantes. Como en cualquier votación, hay que asegurarse de informar a los participantes que hay una opción escrita: si a alguien se le ocurre una opción mejor que no está en la lista, su respuesta puede llegar a ser el resultado más importante de la votación. Algunos proyectos permiten un tipo especial de voto que se conoce como veto. El veto es la manera que tiene un desarrollador para detener un cambio apresurado o mal considerado, por lo menos por un tiempo suficiente para que todos puedan discutirlo más. Entender el veto como algo que está entre una objeción fuerte y una discusión sin fin. El sentido exacto del veto varía de un proyecto a otro. Algunos proyectos hacen que sea difícil contrarrestar un veto; otros permiten que sea superado por el voto de una simple mayoría, quizás luego de una forzada demora producida por más discusión. Un veto debe ser acompañado por una explicación exhaustiva; el veto presentado sin esa explicación debe ser considerado inválido. Junto con los vetos se introduce el problema del abuso del veto. A veces los desarrolladores están demasiado ansiosos en levantar la presión con el pedido de veto, cuando lo que realmente se requiere es más discusión. Se puede evitar el abuso del veto empezando por ser uno mismo contrario al uso del veto, y haciendo notar con tacto cuando alguien usa el veto muy a menudo. Si fuera necesario, se puede recordar para el grupo que los vetos tienen fuerza de obligación siempre y cuando el grupo esté de acuerdo—después de todo, si una gran mayoría de desarrolladores quieren X, de una u otra manera van a conseguir X. O bien el desarrollador que propuso el veto lo retira, o el grupo va a quitarle fuerza al significado del veto. A veces se escribe un "-1" para contabilizar el veto. Esta costumbre viene de la Fundación del Software Apache, quienes tienen un proceso muy estructurado de votos y votaciones, que está en . Las normas de Apache se han difundido a otros proyectos, y se pueden ver sus acuerdos usados de distinta forma en muchos lugares del mundo de la fuente abierta. Técnicamente "-1" no siempre indica que hay un veto formal de acuerdo a las normas de Apache, pero informalmente se considera que representa un veto, o por lo menos una objeción muy fuerte. Igual que con las votaciones, los vetos se pueden aplicar con efectos retroactivos. No es correcto rechazar un veto porque el cambio en cuestión haya sido puesto en commit, o porque la acción está asumida (a no ser que se trate de algo irrevocable, como por ejemplo una edición de prensa). Por otro lado, un veto que llega semanas, o meses tarde no tiene la posibilidad de que se lo tome muy en serio, ni tendría que ser así. En cierto momento, el número de acuerdos y arreglos que circulan por el proyecto pueden llegar a ser tan grandes que se necesita registrarlos en algún lugar. Y para dar legitimidad a esos documentos, hay que tener bien claro que están basados el las discusiones de las listas de correo y en acuerdos que ya estaban en vigencia. Cuando se los escribe, se hace referencia a las líneas de los archivos de la lista de correo y cada vez que no se está seguro sobre un punto, se pregunta de nuevo. El documento no debe contener sorpresas: Éste no es fuente de los acuerdos, sino solamente la descripción de ellos. Por supuesto, si es aceptado, la gente comenzará a citarlo como si fuera una fuente de autoridad, pero eso sólo significa que refleja con exactitud la voluntad de todos los del grupo. Este es el documento aludido en . Naturalmente, cuando el proyecto recién comienza, se tendrá que esbozar una guía, sin que por esto se excluya la confección de una posterior historia del proyecto. Pero, a medida que la comunidad madura, se pueden hacer ajustes del lenguaje para reflejar la manera final a la que se ha llegado. No se debe pretender que uno lo ha dicho todo. Ningún documento puede captar todo lo que la gente necesita saber para participar en un proyecto. Muchos de los acuerdos del proyecto permanecen tácitos, nunca explicitados, sin embargo aceptados por todos. Algunas cosas son muy obvias para incluirlas, y resultarían distractivas al lado del material que no es obvio y es importante. Por ejemplo, no tiene sentido escribir en la guía una instrucción como "Sea educado y respetuoso con los otros miembros de la lista de correos, y no incite a las discusiones acaloradas" o "Escriba código sin errores, claros y limpios." Por supuesto que son cosas deseables, pero no existe un universo concebible donde estas cosas no sean deseables, por lo que no vale la pena mencionarlas. Si alguien es grosero en la lista de correos, o escribe el código con errores, no van a dejar de hacerlo sólo porque la guía del proyecto lo dice. Estas situaciones requieren atención en el momento que aparecen, y no bastan las normas generales que dicen que hay que ser buenos. Además, si el proyecto tiene líneas específicas sobre cómo escribir un código bueno, entonces esas líneas de la guía deber escribirse con todo el detalle que sea posible. . Una buena manera de determinar qué debe incluirse en el documento es referirse a las preguntas que los recién llegados hacen, y a las quejas de los desarrolladores con experiencia. Esto no quiere decir que necesariamente tienen que convertirse en un informe FAQ—posiblemente el documento necesita una estructura narrativa más coherente que la que puede ofrecer el FAQ. Tiene entonces que seguir el mismo principio basado en la práctica, que hay que incluir asuntos que realmente se producen, y no tanto tratar de anticiparse a los asuntos que pueden producirse. . Si el proyecto tiene un dictador benévolo, o si tiene miembros con poderes especiales (presidente, secretario general, o lo que sea), entonces el documento es una buena oportunidad de escribir los procedimientos de la sucesión de poderes. A veces eso puede ser tan simple como nombrar cierta gente como reemplazantes en el caso en que el DB abandone el proyecto por alguna razón. Generalmente, si hay un DB, es sólo él quien puede decidir el nombre de un sucesor. Si se elige una comisión, entonces el procedimiento de la elección y el nombramiento de los integrantes de la comisión tiene que estar descrito en el documento. Si al comienzo no existe un procedimiento, entonces hay que conseguir un consenso en la lista de correos antes de escribir sobre el procedimiento. Hay gente que puede ser sensible con las estructuras jerárquicas, por lo que el asunto tiene que ser tratado con delicadeza. Quizás lo mas importante es dejar en claro que las reglas pueden ser reconsideradas. Si los acuerdos descritos en el documento comienzan a frenar el proyecto, recordar a todos que fue pensado como una reflexión viviente de las intenciones del grupo, no para provocar frustración y bloqueo. Si alguien toma por hábito pedir que las reglas se reconsideren cada vez que una regla se considera, no siempre conviene debatir el tema con ella—a veces el silencio es la mejor táctica. Si hay mas de uno que se une a las quejas, la campana ha sonado, y será lógico suponer que algo necesita ser cambiado. Si nadie se une a la queja, entonces esa persona no representa a nadie, y las reglas quedarán como están. Dos buenos ejemplos de una guía para un proyecto es Subversion hacking.html en , y los documentos de gobierno de la Fundación de Software Apache, en y . La Fundación de Software Apache es de hecho una colección de proyectos de software, organizada legalmente como una corporación sin fines de lucro, de modo que sus documentos tienden a describir los procedimientos de gobierno más que las convenciones de desarrollo. Vale la pena leerlas, porque representan una experiencia acumulada en muchos proyectos de fuente abierta.