Cultivando la Noosfera - Causas del conflicto

En los conflictos sobre software de código abierto podemos identificar cuatro problemas principales:

<!--[if !supportLists]-->·        <!--[endif]-->Quién realiza las decisiones del proyecto?

<!--[if !supportLists]-->·        <!--[endif]-->Quién obtiene crédito o culpabilidad por algo?

<!--[if !supportLists]-->·        <!--[endif]-->Cómo reducir la duplicación del esfuerzo y prevenir versiones modificadas?

<!--[if !supportLists]-->·        <!--[endif]-->Qué es lo correcto, técnicamente hablando?

<!--[if !supportEmptyParas]--> <!--[endif]-->

Si le echamos una segunda mirada al último problema (“Qué es lo correcto?”), éste tiende a desaparecer. Por cada pregunta así, o hay una forma objetiva de decidir o no la hay. Si la hay, se termina el problema y todos ganan. Si no la hay, se reduce a “Quién decide?”.

En conformidad, los tres problemas que una teoría de resolución de conflictos tiene que resolver sobre un proyecto son (A) donde se para en decisiones técnicas, (B) como decidir que contribuyentes tienen crédito y cómo, y (C) cómo mantener un grupo y producto para que no se fisure.

El rol de las costumbres de propiedad en la resolución de los problemas (A) y (C) es claro. La costumbre afirma que los propietarios del proyecto toman las decisiones. Hemos observado previamente que la costumbre también esfuerza mucha presión contra la dilución de los proyectos.

Es instructivo notar que estas costumbres tienen sentido aun si uno se olvida del juego de la reputación y las examina dentro de un puro modelo de mano de obra de la cultura hacker. En esta vista estas costumbres tienen menos que ver con la disolución de los incentivos de reputación que protegiendo el derecho de un obrero a ejecutar su visión en su forma elegida.

El modelo de mano de obra no es, sin embargo, suficiente para explicar las costumbres hacker sobre el problema (B). Para analizar esto, necesitamos llevar la teoría lockeana un paso adelante y examinar los conflictos y la operación de los derechos de propiedad dentro de los proyectos así bien como entre ellos.