El caso trivial es en el que el proyecto tiene un solo propietario / mantenedor. En ese caso no hay conflicto posible. El propietario toma todas las decisiones y recoge todo el crédito y toda culpa. Los únicos conflictos posibles son sobre problemas de sucesión (quien reemplaza al propietario si éste desaparece o pierde interés). La comunidad también tiene un interés, bajo el problema (C), en prevenir la división del proyecto. Estos intereses son expresados por una norma cultural que un propietario / mantenedor debe públicamente pasar su título a alguien si él o ella no puede seguir manteniendo el proyecto.
El caso no trivial más simple es cuando un proyecto tiene múltiples co-mantenedores trabajando bajo un único dictador benevolente que posee el proyecto. La costumbre favorece éste modo para proyectos de grupo; se lo ha visto trabajar en proyectos tan grandes como el kernel de Linux o Emacs, y resuelve el problema de “quien decide” en una forma que no es peor que las otras alternativas.
Típicamente, una organización con un dictador benevolente evoluciona de una organización propietario / mantenedor a medida que el fundador atrae contribuyentes. Aun si el propietario se mantiene como un dictador, introduce un nuevo nivel de posibles disputas sobre quien obtiene crédito por ciertas partes del proyecto.
En ésta situación, la costumbre coloca una obligación en el propietario / dictador en darle crédito justamente a los contribuyentes (a través de, por ejemplo, menciones en el README o en el archivo de la historia del proyecto). En términos del modelo de la propiedad lockeana, esto significa que contribuyendo a un proyecto ganas parte de la reputación que éste recibe (positiva o negativa).
Persiguiendo ésta lógica, vemos que un dictador benevolente no es propietario enteramente de su proyecto. Aunque tiene el derecho de tomar las decisiones, él en efecto canjea acciones de la reputación total obtenida a cambio del trabajo de otros.
Mientras el proyecto del dictador benevolente cosecha más participantes, ellos tienden a desarrollar dos hileras de contribuyentes; los contribuyentes ordinarios y los co-desarrolladores. Un camino típico para convertirse en co-desarrollador es tomando responsabilidad de una parte importante del proyecto. Otro camino es tomar el rol de caracterizar y arreglar muchos bugs. En éstas formas u otras, los co-desarrolladores son los contribuyentes que hacen una continua y substancial inversión de tiempo en el proyecto.
El rol del que toma parte importante de un proyecto es particularmente importante para nuestro análisis y merece mayor examinación. A los hackers les gusta decir que “a la autoridad le sigue la responsabilidad”. Un co-desarrollador que acepta la responsabilidad de mantener una parte importante de un proyecto generalmente obtiene el control de la implementación de esa parte del proyecto y sus interfaces con el resto del proyecto, sujeto sólo a la corrección del líder del proyecto. Observamos que ésta regla efectivamente crea propiedades adjuntas en el modelo lockeano dentro de un proyecto, y tiene exactamente el mismo rol de prevención de conflictos como otros límites de propiedades.
Por costumbre, el dictador es esperado que consulte con sus co-desarrolladores sobre decisiones clave. Un líder sabio, reconociendo la función de las propiedades internas de los límites del proyecto, no interferirá o revertirá decisiones hechas por los co-desarrolladores.
Algunos proyectos muy grandes descartan el modelo del dictador benevolente completamente. Una forma de hacer esto es poner a los co-desarrolladores en un comité en el que votan las decisiones (como Apache). Otra forma es rotando el dictador, cuyo control es pasado ocasionalmente de un miembro a otro dentro de un círculo de privilegiados co-desarrolladores; los desarrolladores de Perl se organizan de éste modo.
Tales arreglos complicados son ampliamente considerados inestables y difíciles. Esta dificultad es una función del azar de los designados por el comité, y de los comités en sí mismos; éstos son problemas que la cultura hacker entiende conscientemente. Sin embargo, pienso que un poco de la incomodidad que sienten los hackers sobre las organizaciones de comité o de rotación es porque son difíciles de encajar en el modelo lockeano que los hackers usan para razonar sobre casos simples. Es problemático, en éstas complejas organizaciones, hacer una contabilidad de la propiedad en el sentido del control o de la propiedad de la reputación. Es difícil ver donde están las fronteras internas, y de éste modo es difícil evadir el conflicto a menos que el grupo disfrute de un excepcional alto nivel de armonía y confianza.
