Introducción

¿Qué tipo de programadores voluntarios componen el movimiento del software libre y cómo se organizan para trabajar juntos? Este artículo propone una aproximación tanto a la filosofía de trabajo y comportamiento de los participantes en el desarrollo de software libre como a algunas dinámicas de grupo, roles y normas que surgen para lograr con éxito la consecución orgánica y descentralizada de proyectos de programación con código abierto en Internet. Además de la bibliografía especializada nos basaremos en algunos ejemplos de comunicaciones y de recursos online para la gestión de tareas relativas a dicho desarrollo, así como en declaraciones de lo que los propios protagonistas del fenómeno de software libre (Eric S. Raymond, Richard Stallman, Linus Trovalds etc.) opinan sobre esta comunidad multitudinaria y transnacional de desarrolladores y sobre los comportamientos individuales que la integran.

La actitud hacker

Entre la inmensa comunidad de participantes voluntarios en el desarrollo de software libre existe una tendencia generalizada en la denominación entre éstos como hackers, término que como se verá hace referencia a una manera propia y peculiar de relacionarse tanto con el código como con el resto de programadores y colaboradores.

Dicho término requiere primeramente una distinción respecto a la creencia común de que el hacker es por definición alguien que penetra en sistemas ajenos con intenciones maliciosas, nada más lejos de la realidad en tanto que se trata de una persona que "disfruta explorando los detalles de sistemas programables y cómo ampliar sus capacidades, a diferencia de la mayoría de usuarios que prefieren aprender lo mínimo necesario" o de "alguien que programa entusiastamente (hasta obsesivamente) o se divierte programando en vez de teorizando sobre programación"(1). En ese sentido, pues, diríase que se establece por consenso entre los iniciados una diferencia clara respecto a la primera definición, para la cual el término cracker pasa a ser el más apropiado a la hora de caracterizar las prácticas ilícitas de determinados programadores (respecto a los cuales no nos detendremos en este análisis).

La actividad del hacker, por tanto, pasa inicialmente por una inquietud personal que conduce a un programador o incluso a alguien no versado en la informática a dedicar horas y esfuerzos no remunerados al desarrollo del código o algún otro aspecto relacionado con el mismo, ya sea por una motivación intrínseca (basada en la diversión que supone el descubrimiento creativo, o bien basada en un compromiso adquirido respecto a otros hackers, como veremos que sucede de modo destacado en el caso de la comunidad de software libre) o ya sea por una motivación extrínseca, menos frecuente pero también significativa (donde la finalidad última puede ser la de mejorar las propias habilidades de programación y por ende aumentar la capacitación profesional)(2).

Según explica Himanen en La ética del hacker y el espíritu de la era de la información (2002), la motivación intrínseca, cuando relaciona la pasión por programar con el trabajo en colaboración de cualquier grupo de hackers, constituye una responsabilidad de índole social impulsada por la necesidad de aportar algo valioso a la comunidad creativa de desarrolladores y usuarios, así como de ser reconocido públicamente por ello.

O en palabras de Torvalds (2002), en referencia a la comunidad de desarrolladores del kernel de Linux, "no se trata de hacer mucho dinero. La razón por la que los hackers de Linux hacen algo es que lo encuentran muy interesante y les gusta compartir eso tan interesante con los demás. De repente, se obtiene entretenimiento del hecho de estar haciendo algo interesante, a la vez que se alcanza una repercusión social. Se logra así este efecto de la red Linux, donde hay multitud de hackers que trabajan juntos porque disfrutan con lo que hacen".

Considerando que generalmente las virtudes proclamadas de un programador, no sin cierta ironía, son la pereza, la impaciencia y el orgullo (virtudes pasionales que contrastarían con las de la comunidad: diligencia, paciencia y humildad)(3), no es de extrañar que el paso siguiente para cualquiera que, una vez motivado, se inicie en el complejo mundo del desarrollo de software libre sea adoptar una determinada actitud que le garantizará su quehacer dentro de la comunidad hacker.

Según la glosa en The Cathedral & the Bazaar Raymond (2001), tal actitud consiste en asimilar que (a) "el mundo está repleto de problemas fascinantes a la espera de ser resueltos", (b) "nadie debería resolver el mismo problema dos veces", (c) "el aburrimiento y el trabajo pesado son perniciosos", (d) "la libertad en buena" y (e) "la actitud no es substituto de capacidad". Tales preceptos, pese a su ambigüedad o posible extrapolación más allá del mundo de la programación, caracterizan un tipo de voluntarismo basado en la ejercitación esforzada de la inteligencia, el aprovechamiento y gestión racional del tiempo(4), la resistencia al autoritarismo y la tensión constante de los propios límites que conforman un arte de hacer las cosas, en beneficio personal y comunitario, que han llevado la manipulación del código a los grados actuales de calidad y eficacia que detenta el desarrollo voluntario de software libre.

No obstante, más concreta y decisivamente que tal actitud, existen unas habilidades reconocidas como indispensables para poder participar en las diversas tareas modulares de programación de cualquier proyecto de código abierto (en lo que atañe estrictamente a programadores, no a otros participantes en procesos paralelos de colaboración como pueden ser tareas de documentación, administración, etc.). Aunque obvias, sirva también el resumen de Raymond como muestra: (a) "saber o aprender a programar", (b) "conseguir uno de los Unixes de código abierto, ponerlo en marcha y usarlo" y (c) "aprender a usar Internet y a escribir en HTML"(5).

A ello hay aún que sumar, a nivel funcional o si se quiere relacional, que ni poseer ni adquirir estas habilidades garantiza automáticamente el correcto discurrir de un hacker en un grupo de desarrolladores o de usuarios, ya que derivado principalmente del concepto de economía del tiempo existe un amplio abanico de comportamientos improcedentes o inadecuados a la hora de solicitar ayuda o información en cualquier lista de correo o foro virtual.

Citando de nuevo a Raymond, parece existir un amplio consenso implícito(6) sobre cómo formular preguntas a la comunidad de manera inteligente y práctica, del que cabría destacar extensamente varias para el tema que nos ocupa: "Antes de hacer una pregunta técnica por correo, en un grupo de noticias o en el foro de un sitio web, haz lo siguiente: intenta encontrar una respuesta leyendo el manual, leyendo la FAQ, buscando en la web o preguntándole a un amigo con más experiencia"; "Elige el foro con cuidado. Ten cuidado al elegir dónde planteas tu pregunta. Seguramente te ignorarán o te tacharán de perdedor si: publicas tu pregunta en un foro en el que se encuentra fuera de lugar (off topic), publicas una pregunta muy elemental en un foro en el que se esperan preguntas técnicas avanzadas (o viceversa) o publicas el mensaje al mismo tiempo en grupos de noticias muy diferentes"; "Escribe de manera clara respetando la ortografía y la gramática"; "Envía las preguntas en formatos que sean fáciles de entender. Si artificialmente haces tu pregunta difícil de leer, tendrá más probabilidades de ser ignorada en favor de una que no lo sea"; "Usa títulos específicos y con sentido. En las listas de correo o en los grupos de noticias, la cabecera del mensaje es tu oportunidad de oro para atraer la atención de expertos cualificados en aproximadamente 50 caracteres o menos"; "Sé preciso e informativo sobre tu problema. Describe los síntomas de tu problema o error con cuidado y claramente, el entorno en el que ocurre (máquina, SO, aplicación, 'loquesea'), la investigación que llevaste a cabo para entender el problema antes de hacer la pregunta, los pasos de diagnóstico que llevaste a cabo y cualquier cambio reciente en tu ordenador o combinación de software que pueda resultar relevante"; "No solicites que te respondan por correo privado. Los hackers creen que resolver problemas debería ser un proceso público y transparente durante el cual un primer intento de respuesta puede y debería corregirse si alguien con más conocimientos percibe que la respuesta es incompleta o incorrecta. Además, obtienen parte de su recompensa por responder al verse que son competentes y que poseen conocimientos suficientes por parte de sus iguales"; "Concluye con una breve nota sobre la solución. Envía una nota tras haber resuelto el problema a todos los que te ayudaron; hazles saber cómo acabó todo y agradéceles de nuevo su ayuda. Si el problema atrajo el interés general en una lista de correo o grupo de noticias, entonces será apropiado publicar la nota allí".

Si respecto a estas indicaciones tomamos como ejemplo el conocido mensaje inicial de Linus Torvals de 1991 solicitando colaboración para desarrollar el kernel del sistema operativo que es hoy Linux (y que en sólo cuatro años logró que más de 15.000 personas en más de 90 países hubieran contribuido con comentarios, informes de errores, parches y fragmentos), veremos que cumple con todas ellas, a la vez que significativamente juega con un lenguaje informal para establecer complicidades ("¿Añoras los buenos tiempos de minix.1-1, cuando los hombre eran hombres y escribían sus propios drivers?"), invita a las modificaciones ("he disfrutado haciéndolo, y alguien más podría divertirse leyéndolo e incluso modificándolo para sus propias necesidades") e incluye agradecimientos personales ("estoy usando el estudio de Earl Chews ahora mismo -gracias por un sistema bueno y que funciona, Earl").

En ese sentido, y tomando a Torvalds como modelo de coordinador de proyecto, estas últimas serían dotes estratégicas de comunicación necesarias, o al menos ideales, para cualquier otro hacker que aglutine y coordine la participación voluntaria de programadores en torno a un desarrollo de software libre, donde para Torvalds, en ese rol, "las capacidades y habilidades de mando resultaron ser tan importantes como las técnicas"(7), algo aplicable hoy día a infinidad de iniciativas similares en curso.

Estrechamente relacionado con los atributos hasta ahora mencionados sobre el hacker, sea éste coordinador, administrador o parte de un equipo de desarrolladores, existe asimismo una serie de grandes tabúes respecto al trabajo sobre el código en sus sucesivas versiones, como son los de no producir bifurcaciones o forkings (que llevan a soluciones paralelas incompatibles e incluso a disputas entre los participantes, con el derroche de esfuerzos comunitarios que ello supone), evitar la distribución de parches pirateados (que pueden crear problemas de compatibilidad) y, como mayor e imperdonable falta, la eliminación subrepticia del nombre de algún participante de la lista de créditos(8).

Otras faltas o acciones poco recomendadas (aunque en menor grado) serían por ejemplo el utilizar un grandilocuente o absurdo nickname, dejarse llevar por guerras de flames o adoptar actitudes excesivamente narcicistas (respecto a este último aspecto regresaremos más adelante, debido a su importancia funcional).

Asimismo, existen otros aspectos clave a destacar relacionados con la actitud apropiada durante la participación en el proceso de desarrollo de software libre, como serían los englobados bajo la denominada ética de la red o nética, cuya vinculación con la actividad del hacker (más allá del concepto de netiqueta, que por ejemplo desaconseja la utilización de expresiones inadecuadas en la comunicación, no comentar las variables o ignorar las FAQs de las aplicaciones) abarcan cuestiones como la de que todo hacker debe ser juzgado tan sólo en base a sus méritos como programador y colaborador dentro del marco de la comunidad(9), o un altruismo de base no moral ni metafísica sino materialista, que en vez de estímulos económicos debe basarse en la cooperación social, entendida como el mejor modo de apoyar un modelo que permite la distribución y expansión de mejores aplicaciones para todos los participantes(10).

No obstante, esta ventaja cualitativa que ofrece el software libre basado en una ética materialista, en tanto que fruto de la cooperación abierta de sus desarrolladores, ha sido y es a menudo visto como un efecto positivo pero secundario paralelo a las principales banderas del movimiento, que son la libertad y la comunidad. En palabras del propio Stallman(11), "necesitamos el software libre para que los usuarios de ordenadores puedan cooperar libremente. Esta es la única razón por la que yo he rechazado el software propietario. Que el software libre lleve además a un software eficiente y potente ha sido para mí una sorpresa y me alegro de ello. Pero esto es un extra. Hubiera elegido el software libre aunque hubiera sido menos eficaz y menos potente. Porque yo no malvendo mi libertad por simples cuestiones de conveniencia".

Respecto a esta cuestión, que refleja una división de fondo entre dos tendencias ideológicas de diverso grado en el seno de la comunidad hacker en relación al código propietario (y por ende de prácticas que acepten o no la vinculación de cualquier aspecto o detalle del mismo con proyectos de software libre), según se adopte una actitud hostil al software comercial o se defiendan posiciones más pragmáticas se verá definitivamente influido cualquier proyecto y producto, dado que ambas actitudes "implican diferentes agendas, así como diferentes comportamientos de adaptación y de cooperación"(12).

Al margen relativo de dicha polémica, sin embargo, lo que caracterizaría finalmente y con cierta urgencia la actitud hacker (en tanto que partícipe de un proceso complejo y global de cooperación y desarrollo que constantemente suma participantes e intereses, tanto comunitarios como comerciales) sería el acompañar a ese interés en el software abierto, a través del propio ejemplo personal, de todo aquello que hasta ahora se ha citado como normas implícitas e explícitas, motivaciones y tabúes. Según Stallman (1999), es la única garantía de que la comunidad siga creciendo en paralelo a la libertad del software con el que el hacker trabaja y se relaciona.


Un sistema complejo dinámico y meritocrático

Probablemente contagiada de esa tendencia a la economía del tiempo y del trabajo que detentan los hackers en el desarrollo de software libre, la gestión de proyectos en este campo se caracteriza (en contraste con los procesos productivos de software propietario) por una reducción operacional al mínimo indispensable, donde por ejemplo las necesidades técnicas surgen de manera natural y se establece un proceso informal sin limitaciones de tiempo relacionadas con los recursos y sin un final pautado al inicio del proyecto(13). También determinado por los factores motivacionales y la actitud citados al principio, los requisitos se producen a través de los canales establecidos de comunicación con una alta concurrencia de contribuciones y sugerencias por parte de los desarrolladores en tanto que usuarios finales(14), en un ciclo corto de desarrollo basado en la continua publicación de versiones, que a su vez pasará por una dilatado proceso de detección de errores.

Como muestra de esto último, sirvan de ejemplo las comunicaciones del boletín de correo de Hispalinux, donde se anuncia periódicamente la publicación de versiones beta de diferentes proyectos, invitando a la comunidad de suscriptores a ponerlas en funcionamiento y notificar errores y bugs en general(15).

Otra fuente conocida de recursos web para la correcta y coordinada gestión de feedback y detección de errores sería el sitio SourceForge, donde por ejemplo existen secciones fijas para cada proyecto en que es posible la detección y asignación modular de bugs(16).

O si volvemos al desarrollo del kernel de Linux como proceso paradigmático de la dinámica que se establece a los desarrollos de software libre, veremos que no hubo inicialmente un grupo definido de arquitectura para desarrollar su diseño, ni un plan o calendario aprobado previamente por managers, sino tal como describen Yun Moon y Sproull (2000) un uso instrumental de Internet en tanto que infraestructura tecnológica ubicua, red a través de la cual se establecieron dinámicas de participación voluntaria mediante el uso principalmente de bulletin boards y de listas de correo(17).

No obstante, lejos de carecer de estructura jerárquica, dicha dinámica depende de un sutil juego de capacitaciones, prestigio y autoridad regido por un sistema de roles donde la figura del coordinador se torna imprescindible, el cual entre otras funciones asignadas actúa como dinamizador, filtro y supervisor del equipo cambiante y discontinuo de desarrolladores(18).

Considerándolo como un entramado complejo de intercambios, donde la retroalimentación de todo el proceso se basa asimismo en el marco legal de la licencia Gnu GPL de accesibilidad recíproca, no es de extrañar que aquellos usuarios que aportan buenos conjuntos de código reciban mayor feedback, el cual al aumentar en comentarios positivos y aceptación elevan el prestigio del programador en cuestión y éste, por consiguiente, puede ir abarcando más módulos o responsabilidades en sus tareas. Si a esto sumamos el hecho de que también está bastante instaurada desde los inicios la costumbre de dejar firmas personales en el código, veremos que la cuestión del reconocimiento y el prestigio aparece como una pieza fundamental para entender en su conjunto el sistema de colaboración voluntaria del que estamos hablando, donde el comportamiento de consenso actúa tanto respecto al código como respecto al facilitador del mismo, seleccionando en su evolución aquellos que cualitativamente aportan mejores soluciones.

Este reconocimiento personal no sólo afecta a los programadores, ya que a menudo se hace extensivo a aquellos participantes que contribuyen de modo destacado a tareas paralelas de documentación, traducción o administración (si volvemos al ejemplo del desarrollo del kernel de Linux, nos encontramos con que Torvalds también hace mención en sus agradecimientos a este tipo de hackers, sin diferenciación alguna en cuanto a méritos respecto al resto). Según defiende Cox (1998), tras separar a los participantes valiosos del ruido, hay también que tributar respecto hacia a los no programadores, "esa gente a menudo olvidada que mantiene páginas web o cambia logs, las listas de correo y la documentación son igualmente importantes".

La reputación como engranaje del sistema, que va de lo individual a lo compartido, funciona de una manera dual en tanto que, por un lado, motiva a los programadores a contribuir, y por otro los fija a patrones específicos de colaboración e interacción(19). Esto es, a medida que alguien adquiere relevancia en un proyecto, se va apropiando de forma diríase que natural con nuevas responsabilidades como mantenedor o coordinador.

A pesar de ello, los cambios de liderazgo también suelen ser frecuentes, dado que la condición de máxima autoridad en cualquier módulo o solución no está condicionada a personas concretas, sino que puede pasar de miembro a miembro cuando se considera que existe alguna necesidad de relevo, ineficacia u otro factor humano que afecta al proyecto o a la comunidad, e incluso en ese caso la decisión debe ser adoptada por consenso entre los participantes.

Esta libertad y potencial alternancia de roles(20) debe ser considerada un factor clave en cada nivel modular de desarrollo (un factor intrínseco al sistema y que es independiente de sus constituyentes) que contribuye a facilitar una participación abierta y dinámica mucho más adaptativa que en sistemas cerrados como el software propietario, en el cual se suele restringir a sus participantes. Además, planteado desde la teoría de los sistemas complejos, cabe considerar que esta alternancia de roles de prestigio refleja un funcionamiento donde el todo es más importante que la suma de las partes, donde cada agente reacciona constantemente con el resto en paralelo, en una interdependencia en que cada decisión técnica depende de las de los demás miembros de la comunidad y cada acierto o error contribuye, desde un punto de vista global, a la performatividad del proceso de manipulación de código.

Cuando surgen flames o disputas a causa de conflictos relacionados con riesgos de forking, errores, incompatibilidades, etc., la figura del mayor responsabilidad debe por norma apelar a la comunidad para lograr un consenso, y pese a que no suelen darse situaciones formales de voto o claros equilibrios de poder, en base a ello dicha figura acostumbra a tener la última palabra a la hora de rechazar o aceptar las posibles soluciones.

Avanzando según ese modelo, la evolución de estos procesos (que podría considerarse darwiniana, en cierto sentido) acaba por dar resultados en tanto que la eficacia individual es sometida constantemente a revisión en pos de la eficacia de grupo. De ese modo, la inevitable cooperación entre voluntarios acaba siendo mucho más decisiva para lograr resultados de calidad y velocidad de desarrollo que cualquier esfuerzo individual aislado: "este modelo está diseñado para garantizar que, a largo plazo, sea la verdad la que determine al grupo de evaluadores y no al revés. Al igual que el grupo evaluador académico, el grupo evaluador de la red hacker conserva su posición sólo mientras sus decisiones se correspondan con las que resulten aceptadas para el conjunto de la comunidad de iguales. Si el grupo evaluador es incapaz de hacerlo, la comunidad se salta su arbitraje y crea nuevos canales. Esto significa que, en el fondo, el estatuto de la autoridad está abierto a cualquiera y se basa sólo en el rendimiento y la conservación de los resultados, pero nadie puede conservar el puesto a perpetuidad. Nadie puede asumir una posición en la que su trabajo no sea revisado y evaluado por sus iguales, como el de cualquier otro"(21).

Entre los riesgos que implica esta relación entre liderazgo y prestigio, no obstante, el de forking (bifurcación) siempre es elevado, ya que al atraer más atención la figura de líder de proyecto se contribuye a fomentar en ocasiones la decisión del resto de voluntarios de crear iniciativas paralelas en las que su trabajo destaque más que bajo el denominador común de otro hacker(22). En ese sentido, sin embargo, es infrecuente en tanto que tabú o norma aceptada implícitamente que los participantes desarrollen su trabajo en múltiples forks de un determinado producto, algo que además de poco práctico resulta en el derroche de energía y de tiempo útil del que nos hablaba Raymond.

No obstante, ya sea para las fases de diseño, implementación, integración o pruebas, diríase que cuando el desarrollo del software abierto cuenta con una masa crítica de voluntarios y figuras predominantes se asegura de algún modo la cooperación necesaria para su evolución al margen de entornos o situaciones competitivas puntuales.

Considerando esta meritocracia técnica desde el punto de vista cultural, por contraste con economías autoritarias o de intercambio, Raymond asigna a la comunidad de desarrollo de software libre el concepto de cultura altruista o del regalo (gift culture), para la cual el estatus social viene determinado por el prestigio que implica lo que uno ofrece o soluciona desinteresadamente (en este caso, hablamos de artefactos complejos como son las piezas de código, que requieren un ejercicio crítico constante y colaborativo para poder distinguir de modo objetivo lo bueno de lo malo). También en ese sentido, y en última instancia, la única medida disponible del éxito la constituye la reputación adquirida en base a la calidad entre el resto de desarrolladores, que en el contexto que nos ocupa constituye unos de los mayores reclamos de atención y colaboración posibles.

Sin embargo, destaca el hecho de que al adentrarse en las motivaciones admitidas por la mayoría de hackers, el aspecto crucial del prestigio es comúnmente rechazado(23), probablemente debido a una concepción occidental del ego que pasa por negar ese tipo de satisfacción personal como motor de la actividad creativa.

En ese sentido, no sólo se produce un rechazo generalizado a admitir la influencia de la cuestión del prestigio, sino que entre las virtudes de los líderes de proyecto se cuenta de modo destacado la humildad, donde como ya se ha dicho las dotes de convocatoria y de mando son tan o más importantes que las técnicas, y donde el código que uno ha generado o modificado o ayudado a optimizar es su verdadera carta de presentación y, en teoría, su razón de ser en el grupo.

Si a ello sumamos la poca tolerancia al ruido informacional en las listas y foros destinados a la gestión o el desarrollo, comprobamos que nuevamente se trata de una tendencia o actitud adaptativa que beneficia al conjunto de la cooperación necesaria para avanzar en cualquier proyecto. En otras palabras, el tiempo y espacio que uno emplea hablando sobre sí mismo resulta redundante, innecesario y poco práctico cuando el que ha de tener siempre la palabra es el propio código.

Finalmente, cabe preguntarse si las estructuras de autoridad y permisos mencionadas, concretamente respecto a la resolución de conflictos, implican la existencia de pautas de comportamiento adquiridas por imitación y ejemplo (como la norma habitual de que un coordinador respetuoso deba consultar con los desarrolladores principales de un módulo o subsistema, especialmente en las decisiones clave que afectan al fragmento de código en que estos han invertido tiempo y responsabilidad), o que la antigüedad de participación (individual o de grupo) en un desarrollo confiere automáticamente más poder de decisión a la hora de solventar de modo conjunto problemas técnicos o de procedimiento.

Resumidas en las máximas de que "la autoridad depende de la responsabilidad" y de que "la antigüedad gana", estas dos muestras de comportamiento consensuado de grupo se derivarían de actitudes individuales adquiridas, según lo que se ha dado en considerar la actitud del hacker, en los procesos voluntarios y participativos de desarrollo de software libre.


Bibliogafía

COX, Alan (1998): 'Cathedrals, Bazaars and the Town Council', Slashdot.
URL: http://slashdot.org/features/98/10/13/1423253.shtml [Última consulta: 22/04/05]

FELLER, Joseph y Brian FITZGERALD (2001): Understanding Open Source Software Development, London, Addison Wesley.
URL: http://safari.oreilly.com/0201734966 [Última consulta: 20/04/05]

GLEIZES, Jérôme y Aris PAPATHEODOROU (2000): 'La passion du libre' (entrevista a Richard Stallman), Multitudes.
URL: http://multitudes.samizdat.net/article.php3?id_article=214 [Última consulta: 06/03/05]

HIMANEN, Pekka (2002): La ética del hacker y el espíritu de la era de la información, Barcelona, Destino.

KIESLER, Sara, BUTLER, Brian, SPROULL, Lee y Robert KRAUT (2002): 'Community effort in online groups: who does the work and why?', MIT.
URL: http://opensource.mit.edu/papers/butler.pdf [Última consulta: 03/04/05]

KRISHNAMURTHY, Sandeep (2002): 'Cave or Community?: An Empirical Examination of 100 Mature Open Source Projects', First Monday.
URL: http://www.firstmonday.dk/issues/issue7_6/krishnamurthy/ [Última consulta: 28/04/05]

KUWABARA, Ko (2000): 'Linux: A Bazaar at the Edge of Chaos', First Monday.
URL: http://firstmonday.org/issues/issue5_3/kuwabara/index.html [Última consulta: 02/04/05]

LAKHANI, Karim R. y Bob WOLF (2001): 'Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects', MIT.
URL: http://opensource.mit.edu/papers/lakhaniwolf.pdf [Última consulta: 23/04/05]

MARCO, María Jesús (2003): 'Free software contributions to improve traditional software management projects', (informe de investigación).
URL: http://cv.uoc.edu/~ddoctorat/treballs/2003/tic/mmarco.pdf [Última consulta: 02/02/05]

RAYMOND, Eric S. (2001): The Cathedral & the Bazaar (Revised Edition), Sebastopol (Calif.), O'Reilly.
URL: http://safari.oreilly.com/0596001088 [Última consulta: 23/04/05]

STALMAN, Richard (1999): 'We Must Talk About Freedom', en Open Sources: Voices from the Open Source Revolution (cap. 5), Ed. Chris DiBona, Sam Ockman y Mark Stone, Sebastopol (Calif.), O'Reilly.
URL: http://safari.oreilly.com/1565925823 [Última consulta: 02/04/05]

TORVALDS, Linus (2002): '¿Por qué el hacker es como es? La ley de Linus' en La ética del hacker y el espíritu de la era de la información (Prólogo), Barcelona, Destino.

VIDAL, Miquel (2000): 'Cooperación sin mando: una introducción al software libre', Sindominio.
URL: http://www.sindominio.net/biblioweb/telematica/softlibre/sl.html [Última consulta: 04/04/05]

WALL, Larry (1999): 'Diligence, Patience, and Humilty', en Open Sources: Voices from the Open Source Revolution (cap. 10), Ed. Chris DiBona, Sam Ockman y Mark Stone, Sebastopol (Calif.), O'Reilly.
URL: http://safari.oreilly.com/1565925823 [Última consulta: 02/04/05]

YUN MOON, Jae y Lee SPROULL (2000): 'Essence of Distributed Work: The Case of the Linux Kernel', First Monday.
URL: http://firstmonday.org/issues/issue5_11/moon/index.html [Última consulta: 04/04/05]


Notas:

 ^ 1. Acepciones extraídas de una definición de The Jargon File, diccionario online de jerga hacker con réplicas en varios sitios web. URL: http://catb.org/~esr/jargon/html/H/hacker.html Para una definición más extensa y contrastada entre hacker y cracker, véase el término en la página de Wikipedia. URL: http://en2.wikipedia.org/wiki/Hacker

 ^ 2. Lakhani y Wolf (2003). En una encuesta a aproximadamente 700 usuarios de SourceForge implicados en el desarrollo de software libre, el 61% de los participantes alegó factores de motivación relacionados con una sensación de creatividad personal, donde la mayoría dedicaba varias horas semanales adicionales respecto a su trabajo y admitía perder el sentido del tiempo durante la programación. Dicha mayoría definió su actividad como una forma de creación y consumo productivo de software que implicaba satisfacción personal a la vez que un resultado útil para la comunidad.

 ^ 3. Wall (1999).

 ^ 4. Volviendo a las palabras de Himanen (2002): "un aspecto central en la peculiar manera de trabajar de los hackers es su relación con el tiempo. Linux, Internet y el ordenador personal no se desarrollaron en una oficina, de nueve de la mañana a cinco de la tarde. Cuando Torvalds programó sus primeras versiones de Linux, solía trabajar de madrugada y se levantaba a primera hora de la tarde para continuar. A veces, dejaba de elaborar la codificación de Linux para dedicarse a jugar con el ordenador o hacer algo completamente distinto. Esta libre relación con el tiempo ha sido siempre típica de los hackers, personas que gustan de seguir su propio ritmo de vida".

 ^ 5. Más allá de utilizar un navegador o hacer páginas personales, Raymond se refiere aquí a habilidades para manejarse con soltura a nivel comunicacional y técnico en el que considera el recurso comunitario más importante para el hacker. Véanse, a modo de ejemplo, URLs de wikis como http://wiki.escomposlinux.org/ o http://wiki.hispalinux.es/

 ^ 6. Aunque precisamente la cantidad de enlaces, traducciones y réplicas del documento de Raymond How To Ask Questions The Smart Way explicitan de modo recurrente tal consenso. URL: http://www.catb.org/~esr/faqs/smart-questions.html

 ^ 7. Yun Moon y Sproull (2000). Además de en este artículo, el contenido íntegro o parcial del mensaje citado de Linus Torvalds se extiende como referencia y modelo de comunicación por Internet en infinitud de sitios web. Basta con hacer una búsqueda en Google con las palabras clave del autor y la cabecera del mensaje para que muestre cifras de miles de coincidencias.

 ^ 8. Raymond (2001).

 ^ 9. Kuwabara (2000).

 ^ 10. Vidal (2000).

 ^ 11. Gleizes y Papathéodorou (2000).

 ^ 12. Raymond (2001).

 ^ 13. Marco (2003).

 ^ 14. Sin embargo, hay tesis que sugieren que la mayoría de proyectos de software libre basados en la cooperación son desarrollados por un porcentaje relativamente bajo de participantes. Así, en un estudio centrado en cien proyectos en etapa madura de SourceForge, se halló que sólo un reducido número de los mismos generaba un grado alto de discusión, a la vez que se constataba que los proyectos de más antigüedad eran los que se beneficiaban de una mayor participación. Véase Krishnamurthy (2002).

 ^ 15. Véase, por ejemplo, la URL https://listas.hispalinux.es/pipermail/docbook-ayuda/2003-March/000784.html

 ^ 16. Véase una de estas secciones, en concreto respecto al programa de audio Audacity. URL: http://sourceforge.net/tracker/?group_id=6235&atid=106235

 ^ 17. La dinámica de comunicación mediante estos recursos técnicos no se produjo espontáneamente, sino que es heredera de las prácticas habituales a principios de los años sesenta en el Laboratorio de Inteligencia Artificial del MIT y en laboratorios similares en universidades como Stanford o Carnegie Mellon, así como de la amplia intercomunicación universitaria que posibilitó la posterior difusión de ARPANET.

 ^ 18. Imanen (2002). Esta dinámica se detecta también en el característico proceso de aprendizaje de los hackers, donde los avances personales retroalimentan todo el sistema cuando se hacen públicos, poniéndose a disposición del resto de participantes bajo la mirada crítica destacada de las figuras de prestigio, en lo que constituiría una evolución paralela al desarrollo del código y un modelo a seguir por tendencias e instituciones pedagógicas respecto a tal proceso descentralizado de aprendizaje.

 ^ 19. Kuwabara (2000).

 ^ 20. En este sentido, Butler, Kiesler, Sproull y Kraut (2002) muestran en una encuesta de participación que los miembros que poseen un rol de liderazgo formal y consistente acostumbran a realizar mayores esfuerzos en pos de la estabilidad del grupo que el resto de participantes regulares.

 ^ 21. Himanen (2002).

 ^ 22. Feller y Fitzgerald (2001).

 ^ 23. Raymond (2001).