INFRAESTRUCTURA SOCIAL Y POLÍTICA

INFRAESTRUCTURA SOCIAL Y POLÍTICA

(Basado en el libro Producing Open Source Software)

Las primeras preguntas que la gente suele preguntar acerca de software libre son "¿Cómo funciona?
¿Qué mantiene a que un proyecto en marcha? ¿Quién toma las decisiones?" No satisfacen las
respuestas sobre la meritocracia, el espíritu de cooperación, el código habla por sí mismo, etc. El hecho
es que la pregunta no es fácil de responder. La meritocracia, la cooperación y la ejecución de código son
todos parte de la respuesta, pero no se explica cómo los proyectos realmente se ejecutan basados en el
día a día, y no dicen nada acerca de cómo se resuelven los conflictos.

Este documento trata de mostrar los fundamentos estructurales que los proyectos exitosos tienen en
común. Quiero decir "éxito", no sólo en términos de calidad técnica, sino también la salud operativa y
capacidad de supervivencia. Salud operacional es la capacidad actual del proyecto para incorporar
nuevas contribuciones de código y nuevos desarrolladores, y para responder a los reportes de errores.
La supervivencia es la capacidad del proyecto de existir independientemente de cualquier participante
individual o patrocinador, pensar en ella como la probabilidad de que el proyecto continuaría incluso si
todos sus miembros fundadores pasen a realizar otras cosas. El éxito técnico no es difícil de lograr, pero
sin una base robusta de desarrolladores y base social, un proyecto puede ser incapaz de manejar el
crecimiento que trae el éxito inicial, o la salida de personas carismáticas.

Hay varias maneras de lograr este tipo de éxito. Algunos incluyen una estructura formal de gobierno, por
la que los debates se resuelven, los nuevos desarrolladores están incluidos, las nuevas características
son planeadas, y así sucesivamente. Otros implican menos estructura formal, pero más autocontrol,
para producir una atmósfera de equidad en la que la gente puede confiar como una forma de facto de la
gobernabilidad. Ambos caminos conducen al mismo resultado: un sentido de permanencia institucional,
con el apoyo de los hábitos y procedimientos que son bien comprendidos por todos los que participan.
Estas características son más importantes en sistemas auto-organización que en los controlados
centralmente, ya que en los sistemas de auto-organización, todo el mundo es consciente de que unas
cuantas manzanas podridas pueden echar a perder todo el barril, al menos por un tiempo.

Bifurcabilidad
El ingrediente indispensable que une a los desarrolladores en un proyecto de software libre, y los hace
dispuestos a ceder cuando sea necesario, es la portabilidad del código: la capacidad de cualquier
persona para llevar una copia del código fuente y utilizarlo para iniciar un proyecto de la competencia,
conocido como una bifurcación. Esto hay que evitarlo a toda costa.

Forks, o más bien la posibilidad de bifurcación, son la razón de que no hay verdaderos dictadores en
proyectos de software libre. Esto puede parecer una afirmación sorprendente, teniendo en cuenta que
es muy común escuchar a alguien llamado el "dictador" o "tirano" en un proyecto de código abierto
dado. Pero este tipo de tiranía es especial, muy diferente de la comprensión convencional de la palabra.

Imagina un rey cuyos súbditos pudieran copiar todo su reino, en cualquier momento y pasar a gobernar
la copia del reino como mejor les parezca.

MIGUEL ORQUERA 1
 INFRAESTRUCTURA SOCIAL Y POLÍTICA

Es por eso que incluso los proyectos que no están organizados formalmente como democracias son, en
la práctica, democracias cuando se trata de tomar decisiones importantes. Replicabilidad implica
bifurcabilidad; bifurcabilidad implica consenso. Es muy posible que todo el mundo está dispuesto a
someterse a un líder (el ejemplo más famoso es Linus Torvalds en el desarrollo del kernel de Linux), pero
esto es porque eligen hacerlo, de una manera voluntaria y limpia. El dictador no tiene poder mágico
sobre el proyecto. Una propiedad fundamental de todas las licencias de código abierto es que no tiene
una de las partes más poder que cualquier otra en la decisión de cómo el código puede ser cambiado o
usado. Si el dictador tuviera que empezar de repente a tomar malas decisiones, habría inquietud,
seguida finalmente por la revuelta y una bifurcación. Son excepciones, por supuesto, las cosas rara vez
llegan tan lejos, porque el dictador compromete primero.

A continuación se va a analizar dos casos de cómo se organiza la toma de decisiones en los proyectos, en
las que la mayoría de las decisiones van bien. Estos dos ejemplos son extremos un tanto idealizados;
muchos proyectos caen en algún lugar a lo largo de un continuo entre ellos.

Los dictadores benevolentes

El modelo de dictador benevolente es exactamente lo que suena: el poder de decisión final recae en una
sola persona, que, en virtud de la personalidad y la experiencia, se espera que lo use sabiamente.

Aunque " dictador benévolo " (o BD) es el término estándar para este papel, sería mejor pensar en él
como "árbitro aprobado por la comunidad" o "juez”. En general, los dictadores benevolentes en realidad
no toman todas las decisiones, o incluso la mayoría de las decisiones. Es poco probable que una persona
tenga la suficiente experiencia para tomar siempre buenas decisiones en todas las áreas del proyecto, y
en todo caso, los desarrolladores expertos no se quedarán en el proyecto a menos que tengan alguna
influencia en la dirección del proyecto. Por lo tanto, los dictadores benevolentes comúnmente no
imponen mucho. En su lugar, dejan que las cosas funcionen por sí solas a través del debate y la
experimentación siempre que sea posible. Ellos participan en los debates, pero las decisiones las toman
desarrolladores que tiene más experiencia en el área que se discute. Sólo cuando es claro que no se
alcanzará el consenso, y que la mayoría del grupo quiere que alguien tome la decisión para que el
desarrollo pueda seguir adelante, es cuando el BD decide: "Esta es la forma en que va a ser." La
renuencia a tomar decisiones por decreto es un rasgo compartido por casi todos los dictadores
benevolentes exitosos; es una de las razones por las que mantienen ese rol.

¿Quién puede ser un Buen Dictador Benevolente?

Ser un BD requiere una combinación de rasgos. Es necesario, en primer lugar, una sensibilidad bien
afinada a la propia influencia en el proyecto, que a su vez trae la autolimitación. En las primeras etapas
de una discusión, no se debe expresar opiniones y conclusiones con mucha firmeza, ya que los demás se
sienten como que no tiene sentido para el disenso. La gente debe tener la libertad de lanzar sus ideas al
aire, aunque sea ideas estúpidas. Es inevitable que el BD publicará una idea estúpida de vez en cuando
también, por supuesto, y por lo tanto el papel también requiere la capacidad de reconocer y admitir
cuando se ha tomado una mala decisión - aunque esto no es más que un rasgo que cualquier buen
desarrollador debe tener, sobre todo si se queda en el proyecto mucho tiempo. Pero la diferencia es que
el BD puede darse el lujo de fallar de vez en cuando sin tener que preocuparse por el daño de su
credibilidad a largo plazo. Los desarrolladores con menos antigüedad no se sienten tan seguros, por lo

MIGUEL ORQUERA 2
 INFRAESTRUCTURA SOCIAL Y POLÍTICA

que el BD debe emitir críticas o decisiones contrarias con cierta sensibilidad por el peso que sus palabras
tienen en el proyecto, tanto técnica como psicológicamente.

El BD no necesita tener habilidades técnicas más agudas que cualquier otra persona en el proyecto. Él
debe estar lo suficientemente capacitado para trabajar en el código por sí mismo, y para entender y
hacer comentarios sobre cualquier cambio que se trate, pero eso es todo. La posición de BD no se
adquiere por tener extraordinarias habilidades en la codificación. Lo que es importante es la experiencia
y el sentido general en el diseño -no necesariamente la capacidad de producir un buen diseño por sí
mismo, sino en la capacidad de reconocer un buen diseño, sea cual sea su origen.

Es común que el dictador benevolente sea uno de los fundadores del proyecto, pero esto es más una
correlación que una causa. El tipo de cualidades que hacen que uno pueda iniciar con éxito un proyecto:
competencia técnica, capacidad para persuadir a otras personas a unirse, etc. son exactamente las
cualidades que cualquier BD necesita. Y, por supuesto, los fundadores comienzan con una especie de
autoridad automática, que a menudo puede ser suficiente para que surja una dictadura benevolente sin
la menor resistencia de los otros involucrados en el proyecto.

Recuerda que el potencial de la bifurcación va en ambos sentidos. Un BD puede bifurcar un proyecto

con la misma facilidad que cualquier otra persona, y algunos de vez en cuando lo han hecho, cuando se
sentían que la dirección que querían llevar el proyecto era diferente de donde la mayoría de otros
desarrolladores quería ir. Debido a la bifurcabilidad, no importa si el dictador benevolente es root
(privilegios de administrador del sistema) en los principales servidores del proyecto o no. A veces la
gente habla de control del servidor, como si se tratara de la máxima fuente de poder en un proyecto,
pero en realidad es irrelevante. La posibilidad de agregar o quitar privilegios de acceso en un servidor en
particular afecta sólo a la copia del proyecto que reside en ese servidor. El abuso prolongado de ese
poder, ya sea por el BD o alguien más, sólo conduciría a que el desarrollo se traslade a un servidor
diferente.

El que un proyecto tenga un dictador benevolente o no, depende en gran medida de quién está
disponible para tomar ese rol. Como regla general, si se trata de algo muy obvio para todos quien
debería ser BD, entonces ese es el camino a seguir. Pero si no hay ningún candidato obvio para ser el BD,
entonces el proyecto probablemente debería utilizar un proceso de toma de decisiones descentralizada,
como se describe en la siguiente sección.

La democracia basada en el consenso

Conforme los proyectos maduran, tienden a alejarse del modelo de dictadura benevolente y hacia
sistemas más abiertamente democráticos. Esto no es necesariamente por la insatisfacción con un BD
particular. Se trata simplemente de que la gobernanza basada en grupos es más "evolutivamente
estable", para tomar prestada una metáfora biológica. Cada vez que un dictador benevolente falle, o
amplíe la responsabilidad de toma de decisiones, es una oportunidad para que el grupo se asiente en un
nuevo sistema, no dictatorial, estableciendo una constitución, por así decirlo. El grupo podrá no
aprovechar la oportunidad en la primera vez, o en la segunda, pero al final lo harán; una vez que lo
hacen, la decisión es poco probable que se revierta. Una vez que un proyecto ha pasado de ser liderado
por un individuo carismático a un sistema más formal, basado en el grupo, rara vez se mueve hacia
atrás.

MIGUEL ORQUERA 3
 INFRAESTRUCTURA SOCIAL Y POLÍTICA

Los detalles de cómo funcionan estos sistemas varían ampliamente, pero hay dos elementos comunes:
uno, el grupo trabaja por consenso la mayor parte del tiempo; dos, hay un mecanismo de votación
formal al cual recurrir cuando no se puede alcanzar el consenso.

Consenso significa simplemente un acuerdo con el que todo el mundo está dispuesto a vivir. No es un
estado ambiguo: un grupo ha llegado a un consenso sobre una cuestión determinada cuando alguien
propone que se haya llegado a un consenso, y nadie contradice la afirmación. La persona que propone el
consenso debe, por supuesto, especificar el asunto sobre el cual se logró el consenso, y qué acciones se
tomarán en base a éste.

La mayoría conversación en un proyecto es sobre temas técnicos, tales como la manera correcta de
corregir un cierto error, si se debe o no agregar una función, cómo documentar las interfaces, etc. La
gobernabilidad basada en el consenso funciona bien porque se combina a la perfección con la discusión
técnica en sí. Al final de la discusión, no hay a menudo un acuerdo unánime sobre qué rumbo tomar.
Alguien envía un mensaje de conclusión, que es a la vez un resumen de lo que se ha decidido y una
propuesta implícita de consenso. Esto proporciona una última oportunidad para que alguien más pueda
decir "Espera, yo no estoy de acuerdo en eso. Tenemos que reconsiderar esto un poco más."

Para las pequeñas decisiones, no controversiales, la propuesta de consenso es implícita. Por ejemplo,
cuando un desarrollador se compromete de forma espontánea a una corrección de errores, el
comprometerse es una propuesta de consenso: "Asumo que todos coincidimos en que este error debe
ser corregido, y que esta es la manera de arreglarlo". Si nadie opina en contrario, se supone que hay
consenso.

El control de versiones le permitirá relajarse

El hecho de que el código fuente del proyecto se mantiene bajo el control de versiones significa que la
mayoría de las decisiones pueden ser fácilmente deshecha. La forma más común de que esto suceda es
que alguien realice un cambio pensando equivocadamente todo el mundo sería feliz con él, sólo para
encontrarse con objeciones después de los hechos. Es típico de este tipo de objeciones comenzar con
una disculpa por no haber participado en las discusiones anteriores, aunque esto puede ser omitido si el
opositor no encuentra ningún registro de tal discusión en los archivos de las listas. De cualquier manera,
no hay ninguna razón para que el tono de la discusión sea diferente después de que el cambio se ha
realizado. Cualquier cambio puede ser revertido, al menos hasta que se introducen cambios
dependientes (es decir, nuevo código que quedaría huérfano si el cambio original se retirara
repentinamente). El sistema de control de versiones da al proyecto una manera de deshacer los efectos
de decisiones malas o apresuradas. Esto, a su vez, libera a la gente a confiar en sus instintos acerca de
cuánta retroalimentación es necesaria antes de hacer algo.

Esto también significa que el proceso de establecimiento de consenso no tiene por qué ser muy formal.
La mayoría de los proyectos se guían por el tacto. Los cambios menores pueden entrar sin discusión o
con mínima discusión seguida de unos gestos de acuerdo. Para cambios más significativos,
especialmente los que tienen el potencial de desestabilizar un montón de código, la gente debe esperar
un día o dos antes de asumir que hay consenso, la razón es que nadie debe ser marginado en una
conversación importante simplemente porque él no revisa el correo electrónico con la frecuencia
suficiente.

MIGUEL ORQUERA 4
 INFRAESTRUCTURA SOCIAL Y POLÍTICA

Por lo tanto, cuando alguien está seguro de que sabe lo que hay que hacer, sólo debe seguir adelante y
hacerlo. Esto se aplica no sólo a las correcciones de software, sino también para las actualizaciones del
sitio web, cambios en la documentación, y cualquier cosa poco probable que sea controversial. Por lo
general, sólo habrá unos pocos casos en los que una acción tiene que ser deshecha, y éstos se pueden
controlar en una base de caso por caso.

Cuando El consenso no puede ser alcanzado, Voto

Inevitablemente, algunos debates no alcanzan consenso. Cuando todos los demás medios de superar un
estancamiento fallan, la solución es votar. Pero antes de que se procederá a la votación, debe haber un
claro conjunto de opciones en la boleta electoral. Los tipos de preguntas que vienen a votación implican
a menudo, aspectos multifacéticos complejos. En cualquier discusión compleja, por lo general hay una o
dos personas que juegan el papel de intermediario honesto: publicar resúmenes periódicos de los
distintos argumentos y hacer el seguimiento de dónde están los puntos fundamentales de desacuerdo (y
de acuerdo). Estos resúmenes ayudan a todos a medir cómo se ha avanzado, y recordar a todos los
aspectos que siguen siendo objeto de discusión. Esos mismos resúmenes pueden servir como prototipos
para una hoja de votación, si se debe recurrir a una votación. Si los intermediarios honestos han estado
haciendo bien su trabajo, pueden llamar a una votación válida cuando llegue el momento, y el grupo
estará dispuesto a utilizar una hoja de votación con base en su resumen de los problemas. Los
intermediarios pueden ser participantes en el debate; no es necesario que permanezcan por encima de
la refriega, siempre y cuando permanezcan neutrales en la documentación de las discusiones.

MIGUEL ORQUERA 5