Cultivando la Noosfera - Propiedad y código abierto

Que significa propietario cuando la propiedad es infinitamente reduplicable, altamente maleable, y la cultura que la rodea no coercibe relaciones de poder?

Realmente, en el caso de la cultura de código abierto ésta es una pregunta fácil de responder. El propietario de un proyecto de software es aquel que tiene el derecho exclusivo, reconocido por la comunidad, a distribuir versiones modificadas.

(Al discutir sobre propiedad en ésta sección usaré el singular, ya que todos los proyectos son propiedad de alguna persona. Debe ser entendido, sin embargo, que los proyectos pueden ser propiedad de grupos. Examinaremos las dinámicas internas de esos grupos más tarde en éste ensayo.)

Coincidiendo con las licencias standard de código abierto, todas las partes son iguales en el juego evolucionario. Pero en práctica hay una muy bien reconocida distinción entre los parches oficiales, aprobados e integrados en el software por los mantenedores públicamente reconocidos, y los parches de terceras partes. Los parches que no sean oficiales son poco comunes, y generalmente no confiables.

Esta redistribución pública es un punto en disputa fundamentalmente fácil de establecer. La costumbre anima a la gente a corregir el software para uso personal cuando es necesario. La costumbre es indiferente para la gente que redistribuye versiones modificadas dentro de un grupo de desarrollo. Es solamente cuando las modificaciones son puestas en la comunidad de código abierto, a competir con el original, que la propiedad se convierte en un punto en disputa.

Existen, en general, tres formas de adquirir la propiedad de un proyecto de código abierto. Uno, el más obvio, es fundando el proyecto. Cuando un proyecto tiene sólo un mantenedor y todavía se encuentra activo, la costumbre no permite cuestionar quien es dueño del proyecto.

El segundo camino es que la propiedad del proyecto sea pasada hacia ti por el propietario anterior. Es bien entendido en la comunidad que los propietarios de los proyectos tienen derecho a pasar el proyecto a sucesores competentes cuando no están dispuestos o no pueden invertir el tiempo necesario en el desarrollo o trabajo de mantenimiento.

Es significante que en el caso de proyectos mayores, éstas transferencias de control son generalmente anunciadas.

Para proyectos menores, es suficiente con cambiar la historia incluida en el proyecto para notar el cambio de propiedad. Si el anterior propietario no transfirió voluntariamente el control, él o ella deben reasegurarse el control con el soporte de la comunidad, objetando públicamente dentro de un período razonable de tiempo.

La tercera forma de adquirir la propiedad de un proyecto es observar que éste necesite trabajo y el propietario ha desaparecido o perdido interés. Si quieres hacer esto, es tu responsabilidad hacer un esfuerzo para encontrar al propietario. Si no lo encuentras, entonces puedes anunciar el relevamiento (como por ejemplo en un newsgroup de Usenet dedicado a la aplicación o tema correspondiente), diciendo que el proyecto parece estar huérfano y que estás considerando tomar responsabilidad de él.

La costumbre demanda que permitas pasar cierto tiempo antes de seguir con un anuncio en el que te declares el nuevo propietario. En éste intervalo, si alguien más anuncia que estaba trabajando en el proyecto, su reclamo esta sobre el tuyo. Es bien considerado dar pública noticia de tus intenciones más de una vez. Mejor aún si lo anuncias en foros relevantes (newsgroups, listas de correo); y más aún si demuestras paciencia esperando por respuestas. En general, el esfuerzo más visible de permitir al anterior propietario u otros a responder, mejora tu demanda si no se presenta ninguna respuesta.

Si has pasado por éste proceso en busca de los usuarios del proyecto, y no hay objeciones, entonces puedes proclamarte propietario del proyecto huérfano y tomar nota de ello en el archivo de la historia del proyecto. Esto, si embargo, es menos seguro que el paso de mando a través del anterior propietario, y no puedes esperar ser considerado completamente legítimo hasta que hayas hecho mejoras substanciales en busca de la comunidad de usuarios del proyecto.

He observado éstas costumbres en acción por veinte años, yendo más allá de la historia pre-FSF de software de código abierto. Hay varias características interesantes. Una de las más interesantes es que los hackers las han seguido sin estar completamente conscientes de ellas. Verdaderamente, lo anterior puede ser el primer resumen consciente y razonable que haya sido escribido.

Otra es que, por costumbres inconscientes, las han seguido con notable consistencia. He observado literalmente la evolución de cientos de proyectos de código abierto, y todavía puedo contar el número de violaciones significantes que he observado o escuchado con mis dedos.

Una tercera característica es que mientras éstas costumbres han evolucionado a través del tiempo, lo han hecho en una dirección consistente. Esa dirección ha llevado a animar a más responsables, a ser más notorio públicamente, y más cuidado en preservar los créditos y cambios en la historia de los proyectos en formas que establezcan la legitimidad de los actuales propietarios.

Estas características sugieren que las costumbres no son accidentales, sino que son producto de cierto tipo de agenda implícita o modelo generativo en la cultura de código abierto que es completamente fundamental en la forma en la que opera.

Una anterior respuesta apuntó a que la contrastante cultura hacker de Internet con la cultura cracker/pirata ilumina los modelos generativos de los dos bastante bien. Retornaremos a los cracker para contrastarlos más adelante en éste ensayo.