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“Gente difícil” en Capítulo 6, Comunicaciones 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 http://en.wikipedia.org/wiki/Voting_system#List_of_systems 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 “Stabilizing a Release” en Capítulo 7, Empaquetado, Liberación, y Desarrollo diario. 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“Committers” en Capítulo 8, Coordinando a los Voluntarios 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 http://www.apache.org/foundation/voting.html. 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í.