Cultivando la Noosfera - ¿Cómo valorar un regalo?

Hay modelos consistentes en la forma en que la cultura hacker valora las contribuciones y retornos de sus pares. No es difícil observar las siguientes reglas:

<!--[if !supportLists]-->1.      <!--[endif]-->Si no funciona tan bien como esperaba que funcione, no es bueno. No importa que tan inteligente y original es la idea.

Esta regla no es una demanda de perfección; al software beta y experimental se le permite que tenga bugs. Es una demanda que el usuario sea capaz de estimar los riesgos.

Esta regla subraya el hecho de que el software de código abierto tiende a permanecer en estado beta durante largo tiempo, y de que no se realizan versiones 1.0 hasta que los desarrolladores estén muy seguros de que no tendrán una sorpresa desagradable. En el mundo del código cerrado, la versión 1.0 significa: “No toques esto si eres prudente.”; en el mundo del código abierto se lee como: “Los desarrolladores están apostando sus reputaciones en esto.”

<!--[if !supportLists]-->2.      <!--[endif]-->El trabajo que extiende la noosfera es mejor que el trabajo que duplica una pieza existente de territorio.

La forma ingenua de poner esto sería: El trabajo original es mejor que duplicar las funciones del software existente. Pero no es en realidad así de simple. Duplicar las funciones de software cerrado cuenta tan original si haciendo eso rompes un protocolo cerrado o formato cerrado.

Así, por ejemplo, uno de los proyectos de más alto prestigio en el presente mundo de código abierto es Samba (el código que permite a las máquinas Unix actuar como clientes o servidores del protocolo propietario de Microsoft SMB para compartir archivos). Hay muy poco trabajo creativo para desarrollar aquí; es mayormente un problema de obtener correctamente los detalles de ingeniería inversa. Sin embargo, los miembros del grupo Samba son percibidos como héroes porque neutralizan un esfuerzo de Microsoft de cerrar con llave poblaciones enteras de usuarios y acordonar una gran sección de la noosfera.

<!--[if !supportLists]-->3.      <!--[endif]-->El trabajo que se incluye dentro de una distribución es mejor que el trabajo que no se incluye. El trabajo que está dentro de todas las distribuciones principales es más prestigioso.

Las distribuciones principales incluyen no sólo las grandes distribuciones de Linux como Red Hat, Debian, Caldera, y S.u.S.E., sino también otras distribuciones que se entiende que tienen reputación por sí mismas para mantener y certificar calidad (como las distribuciones BSD o la colección de fuentes de la Free Software Foundation).

<!--[if !supportLists]-->4.      <!--[endif]-->La utilización es la forma más sincera de adulación.

Confiar en el juicio de otros es básico para el proceso de crítica. Es necesario porque nadie tiene tiempo para probar todas las alternativas posibles. Entonces el trabajo usado por montones de gente es considerado mejor que el trabajo usado por unos pocos.

El haber hecho trabajo tan bueno que a nadie le interesa usar las alternativas es por lo tanto ganador de un gran prestigio.

<!--[if !supportLists]-->5.      <!--[endif]-->La continua devoción al trabajo difícil y aburrido (como el debugging, o escribir documentación) es más prestigioso que hacer las cosas divertidas y fáciles.

Esta norma es como la comunidad recompensa las tareas necesarias a las que los hackers no se inclinarían naturalmente. Es en cierto sentido contradecida por:

<!--[if !supportLists]-->6.      <!--[endif]-->Las extensiones de funciones no triviales son más prestigiosas que los parches de bajo nivel y el debugging.

La forma en que esto parece funcionar es que agregando una característica se obtiene una mayor recompensa que arreglando un bug (a menos que el bug sea muy grande). Pero cuando estos comportamientos se extienden a través del tiempo, una persona que hace largo tiempo que presta atención y arregla hasta los bugs más ordinarios puede bien tener el mismo prestigio que alguien que ha puesto la misma cantidad de esfuerzo en agregar pequeñas características.

Una persona ha resaltado que estas reglas interactúan en formas interesantes y no necesariamente recompensan la máxima utilidad posible todo el tiempo. Pregúntale a un hacker si es más probable convertirse en una persona conocida por una herramienta nueva de su propia autoría o por extensiones a la herramienta de otra persona, y puedes estar seguro que contestaría con la primera opción. Pero pregunta sobre:

<!--[if !supportLists]-->(a)    <!--[endif]-->una herramienta nueva que es usada unas pocas veces al día en background por el sistema operativo pero que rápidamente se convierte en un asesino de categoría

versus

<!--[if !supportLists]-->(b)   <!--[endif]-->varias extensiones a una herramienta existente las cuales no son originales o asesinas de categoría, pero son usadas diariamente por un gran número de usuarios

y es muy probable obtener cierta duda antes de que el hacker elija la opción (a).

Esta persona también agregó en referencia al autor de éste ensayo: “El caso (a) es fetchmail; el caso (b) son tus tantas extensiones de Emacs, como vc.el y gud.el”. Y verdaderamente tiene razón; es más probable que me etiqueten como el autor de fecthmail que como el autor de extensiones de Emacs, a pesar que la última tiene más utilidad.

Lo que puede estar pasando aquí es que el trabajo con una original marca de identidad se hace notar más que el trabajo agregado en una marca existente. El elucidar estas reglas, y lo que ellas nos dicen sobre la cultura hacker, harían un buen tópico para mayor investigación.