Cultivando la Noosfera - teoría promíscua, practica puritana

A través de todos éstos cambios, sin embargo, prevaleció una amplia teoría de consenso de lo que era "software libre" o "código abierto". La expresión más clara de ésta teoría en común puede ser encontrada en varias licencias de código abierto, todas las cuales tienen cruciales elementos en común.

En 1997 éstos elementos en común fueron destilados en la Debian Free Software Guidelines, las cuales se convirtieron en la Open Source Definition (OSD). Bajo las guías definidas por la OSD, una licencia de código abierto debe proteger el derecho incondicional de cualquier parte a modificar (y distribuir versiones modificadas de) software de código abierto.

De éste modo, la teoría implícita de la OSD es que cualquiera puede hackear cualquier cosa. Nada previene a media docena de personas a tomar cualquier producto de código abierto, duplicar el código fuente y evolucionar con él en diferentes direcciones.

En la práctica, esas divisiones casi nunca ocurren. Las divisiones en los proyectos principales son muy raras, y siempre acompañadas de la justificación pública. Esta claro que, en casos como la división GNU Emacs/XEmacs, o gcc/egcs, o las varias fisuras de los grupos BSD, que los divisores sintieron que iban contra una norma claramente fuerte de la comunidad.

De hecho la cultura de código abierto tiene un elaborado pero inadmitido conjunto de costumbres propietarias. Estas costumbres regulan quien puede modificar el software, las circunstancias en las cuales puede ser modificado, y (especialmente) quien tiene el derecho a redistribuir versiones modificadas a la comunidad.

Los tabúes de una cultura tiran sus normas en alivios agudos. Por lo tanto, sería útil si resumimos algunos aquí.

• Hay una gran presión social contra la división de proyectos. Esto no sucede excepto una gran necesidad, con mucha justificación pública, y con otro nombre.
• Distribuir cambios en un proyecto sin la cooperación de los moderadores no se produce, excepto en casos especiales como la portación de arreglos triviales en el software.
• No se quita el nombre de una persona de los créditos del proyecto sin el consentimiento explicito de la misma.

En el resto de éste ensayo, examinaremos éstos tabúes y costumbres de propiedad en detalle. Inquiriremos no sólo en como funcionan sino que revelan sobre la dinámica social e incentivos estructurales de la comunidad de código abierto.