En 2006, Yochai Benkler y Helen Nissenbaum publicaron en la revista The Journal of Political Philosophy el artículo Commons-based Peer Production and Virtue (BENKLER y NISSENBAUM: 2006), donde se planteaban la virtud y el procomún producido mediante procesos colaborativos entre iguales. Aun cuando otros autores se habían aproximado a este fenómeno desde una perspectiva económica o política [1], el acercamiento de los autores al tema suponía una perspectiva novedosa, planteándose como pregunta central de su artículo la de «¿qué significa en términos éticos que muchos individuos se encuentren cooperando productivamente con extraños y conocidos en una amplitud nunca antes vista?» (BENKLER y NISSENBAUM: 2006, 394). Los autores postulaban que una sociedad que provee oportunidades para el comportamiento virtuoso propicia más individuos virtuosos y que la práctica de un comportamiento virtuoso efectivo puede tener como consecuencia que más personas adopten las virtudes como propias y que perciban tales atributos en su auto-definición como individuos.
El propósito del presente artículo es referenciar los conceptos tratados por estos autores, describir las prácticas concretas que realizan los autores de software libre, la condición de procomún digital de sus desarrollos, y señalar cómo esas prácticas pueden generar mejores ciudadanos que se adaptan a las categorías éticas enumeradas y descritas en el artículo. Para ello, tras comentar los puntos relevantes del artículo de BENKLER y NISSENBAUM, me referiré al concepto de ciudadanía, a las prácticas del software libre y cómo tales prácticas y el procomún resultante (el código informático) sirven como modelo exigible para su positivización normativa dentro del núcleo duro de un sistema democrático.
Si bien en el artículo objeto de estudio los autores no dan una definición de lo que se entiende por procomún, HESS y OSTROM (2003, 114) nos recuerdan los conceptos de LESSIG, el mismo BENKLER y LITMAN, que toman de artículos de estos autores: Para LESSIG, «el procomún es una parte de nuestro mundo, aquí y ahora, que todos podemos disfrutar sin el permiso de ningún otro» [2]. Para BENKLER, «el procomún se refiere a los dispositivos institucionales que suponen la abstención del gobierno de designar a cualquier persona para que tenga un poder de decisión primario sobre el uso de un recurso» [3]. Para LITMAN, el procomún equivale a la noción de dominio público utilizada en la propiedad intelectual [4]. No debemos olvidar, por otra parte, la noción de LAFUENTE (en GUTIERREZ: 2012) para quien el procomún es un bien que es de todos y no es de nadie:
Lo que es de todos y de nadie al mismo tiempo. En el castellano antiguo más que describir una cosa, da cuenta de una actividad que se hace en provecho de todos. El procomún, los commons, en todo caso, no es definible, porque evoca la existencia de bienes muy heterogéneos que van desde los viejos pastos comunales a los nuevos mundos de la biodiversidad, el folclore o la gastronomía.
Junto con esta noción, es preciso señalar que el procomún opera en los cuatro entornos señalados por LAFUENTE (2007): el cuerpo, el medio ambiente, la ciudad y el digital, siendo este último el que nos ocupa, puesto que es el entorno del código informático, de las relaciones que se producen a su amparo y de los repositorios donde se almacena lo escrito por los desarrolladores.
Cuando se escribe software que se desea compartir, se utiliza un repositorio públicamente accesible en el que se escriben las sucesivas versiones a medida que se van produciendo. Los desarrolladores utilizan un software especial de control de versiones que permite conocer en qué momento qué persona escribió qué parte de código. Conocer el qué, quién y cuándo se ha escrito una parte del código es la misión de este tipo de software, que ha sufrido una evolución conceptual desde el primero de los programas. En un principio, los más utilizados eran el CVS (Concurrent Version System) y SVN (Subversion), y ambos tenían un diseño semejante: existía un repositorio central contra el que los desarrolladores “atacaban”, subiendo y bajando del mismo las diferentes versiones que se iban produciendo por cada una de las personas intervinientes. Este sistema evolucionó al actual, en el que ya no existe el concepto de un servidor central sino que la función de éste se ha sustituido por un sistema descentralizado donde lo relevante es la copia que tiene cada desarrollador en su ordenador, siendo uno de ellos (el líder del proyecto) el depositario de la rama master (a la que podríamos llamar, el tronco del desarrollo). Ejemplos de este segundo sistema descentralizado de control de versiones lo tenemos en los softwares Git, Bazaar y Mercurial. En este tipo de software descentralizado, las subidas y bajadas no se realizan a un servidor central sino que se intercambian entre los desarrolladores (lo que no obsta para que exista un servidor público para que se pueda acceder al último de los desarrollos o a las ramas que se van escribiendo en paralelo con el tronco principal).
Ambos sistemas obligan a trabajar en red y a establecer un protocolo de comunicación entre los participantes, protocolo no formal y que se canaliza a través de una lista de correo. En resumen, en los desarrollos abiertos de software, los participantes tienen al menos dos focos de atención: el repositorio del código, donde conocen las modificaciones que se van produciendo, y una lista de correo electrónico para coordinarse entre sí, intercambiar ideas o tomar decisiones sobre el desarrollo.
La producción colaborativa por pares, por iguales, generada en este entorno es un proceso de producción social (BENKLER y NISSEMBAUM: 2006, 400) que se caracteriza por su descentralización y por una motivación no fundada en órdenes o premios, sino en clave social. El objeto producido por los agentes tiene unas características estructurales de modularidad, granularidad e integración entre componentes de bajo coste que permiten que los desarrolladores puedan trabajar asíncronamente.
Para estos autores (2003: 402) las empresas del procomún tienen, desde una perspectiva puramente económica, dos ventajas sobre los mercados y las firmas jerarquizadas: una ganancia informacional ya que no se produce el aplanamiento de la cultura corporativa y se produce un más apropiado aprovechamiento de los recursos personales ya que hay una mayor riqueza de dónde pueden encajar las habilidades personales de cada uno de los colaboradores. Por último, y esto es un aspecto fundamental para los análisis acerca de la virtud de estos proyectos, «por definición las empresas de producción colaborativa no se fundamentan en el precio, esto es, carecen de pagos marginales por sus contribuciones a los contribuyentes».
Con un ejemplo lo entenderemos mejor: tomemos la Wikipedia como una empresa del procomún en la que la producción colaborativa es quien genera la producción. Atendiendo a las características señaladas por estos autores, la Wikipedia funciona descentralizadamente, no hay órdenes ni premios y la motivación de sus colaboradores no es monetaria. La enciclopedia escrita colaborativamente es modular (sus componentes son páginas que pueden ser escritas por cualquiera), es granulable (las tareas a realizar o a acoplar pueden ser desde la corrección de erratas tipográficas hasta encargarse de escribir y supervisar un conjunto de páginas que supongan un campo de conocimiento –por ejemplo: teorías éticas contemporáneas– ), la integración entre sus componentes (las páginas) es de un coste mínimo. Por último, no existe una cultura empresarial, aun cuando existan unas normas de edición y una obligación de neutralidad, y la versatilidad es evidente puesto que los miles de apartados escritos o por escribir permiten el mejor aprovechamiento de las capacidades personales y habilidades de los voluntarios.
El enfoque de BENKLER y NISSENBAUM tiene como objeto servir de fundamento para el desarrollo de políticas públicas ya que «los sistemas técnicos y los aparatos pertenecen a la política y a la vida moral tanto como las prácticas, leyes, regulaciones, instituciones y normas que habitualmente son vistas como los vehículos de los valores morales y políticos». Si no se siguen estas políticas que tienen en cuenta estas prácticas, «podríamos perder la oportunidad de beneficiarnos de un sistema socio-técnico diferente que promueve no sólo la producción cultural e intelectual, sino que constituye un espacio para el desarrollo del carácter humano» (2006: 417). Sin embargo, entiendo que esta visión utilitarista debería completarse con otra perspectiva: aun en el caso en que no se promuevan políticas públicas en las que se implementen estas prácticas, se produce un beneficio individual útil para desarrollarse como ciudadanos. Estos actos obligan a una serie de prácticas personales y procedimentales muy ligadas a la necesidad de transparencia dentro de una comunidad por lo que, finalmente, no sólo es la propia comunidad la que se beneficia (aun no existiendo políticas públicas) ya que las prácticas se realizan en espacios públicos y enriquecen el procomún digital.
Estos autores dividen las virtudes en cuatro grupos (2006, pp. 405–408), de los que los dos primeros hacen referencia a virtudes de la auto-estima, mientras que los dos últimos tienen un nítido componente de la virtud hacia el otro:
Ahora bien, tal y como apunté, es interesante relacionar estas virtudes no sólo con la posibilidad de la producción de políticas públicas sino con el concepto de prácticas ciudadanas. Según GORCZEVSKI y BELLOSO (2011, 68–75) la ciudadanía no supone un concepto unívoco, sino que se trata de un concepto polisémico en el que identifican nueve modelos: liberal, comunitarista, neorrepublicana, diferenciada, multicultural, postnacional, cosmopolita, transnacional y transcultural, cada una producto de unas determinadas tesis e incidente en diferentes características. Coincide en esta apreciación VELASCO (2006, 193), para quien:
Ciudadanía es una categoría multidimensional que simultáneamente puede fungir como concepto legal, ideal político igualitario y referencia normativa para las lealtades colectivas. Implica en principio una relación de pertenencia con una determinada politeia (o comunidad política), una relación asegurada en términos jurídicos, pero también denota una forma de participación activa en los asuntos públicos. Por un lado, supone una condición de status y, por otro, define una práctica política.
En definitiva, el concepto de la ciudadanía puede desbrozarse bien como un status conseguido por el individuo, bien como un conjunto de prácticas deseables. Y es en este conjunto de prácticas deseables donde podemos realizar la conexión entre las prácticas del software libre y las prácticas ciudadanas.
En las comunidades de desarrolladores que escriben código informático, existen unas prácticas que parten de un prius, que es la existencia de una comunidad. Es cierto que no en todo desarrollo de software existe una pluralidad de individuos que participan en la creación, pero ello no obsta para que, aun siendo una sola persona, ésta siga unas prácticas por si en el futuro algún voluntario se presta a colaborar o decide utilizar el código escrito hasta una fecha para desde ahí crear una obra derivada. Todo desarrollo de software comienza por una persona escribiendo una línea de código bien como respuesta a una necesidad expresada en el seno de una comunidad, bien como obra en solitario alrededor de la que en el futuro pudiera instituirse una comunidad. Estas prácticas atienden tanto a la existencia de otros individuos con lo que el desarrollador se relaciona como a procedimientos que son hábitos de trabajo y cuyo conocimiento es requisito imprescindible para la pertenencia a la comunidad. El grupo, por tanto, supone la existencia tanto de un modelo relacional como de un modelo procedimental cuyo conocimiento, además del propio de la materia objeto de desarrollo determina la posibilidad de poder realizar aportaciones [5].
Para entrar en este tipo de comunidades, no son necesarias las credenciales, sino que basta el conocimiento; se trata de sistemas abiertos de entrada y de salida de personas, sin ninguna necesidad de dar explicaciones. La voluntariedad de las aportaciones implica que no existe ningún tipo de obligación, como tampoco ningún reproche moral o social aun cuando se abandone un proyecto en cualquier momento. Son habituales las entradas y salidas de una misma persona, o una mayor o menor dedicación al proyecto, con motivo de, por ejemplo, tener descendencia, realizar una tesis doctoral, un cambio laboral… Si bien las credenciales no son necesarias para entrar en una comunidad, no por ello deja de existir la posibilidad de trazabilidad de un usuario. En la actualidad, existen numerosas empresas que no solicitan al candidato un CV, sino que le preguntan cuál es su cuenta de usuario en Github [6]. Esta trazabilidad en la red del trabajo de un usuario supone una política de reputación que debe cuidarse e implica una transparencia de lo que un individuo puede llegar a realizar.
A mayor abundamiento, una de las prácticas habituales es la de Show me the code [7]. «Hablar es barato, muéstrame el código». Dado que las características de un producto no se describen, sino que se escriben y se publican en un servidor accesible para todos, cualquier integrante de la comunidad de desarrolladores puede opinar sobre la calidad del código y además, al tratarse de un programa de software, probarlo, ejecutando el código para verificar su correcto funcionamiento. Las consecuencias de esta práctica son la interdicción de la impostura y, nuevamente, la máxima transparencia.
La primera de las prácticas que debe ser citada es el fork o escisión. La escisión es un elemento de importancia fundamental por su transparencia y el enriquecimiento que produce. Si bien en un principio una escisión traía causa de la existencia de un disenso dentro de la comunidad ya que uno, varios o todos los desarrolladores decidían que había de tomarse otro rumbo bien por motivos tecnológicos, bien legales (casos de relicenciamiento), produciéndose así dos ramas en el código, sin embargo en la actualidad y debido al software con el que se controlan las versiones, el fork es el sistema primigenio de funcionamiento. El disenso que se practica mediante el fork no supone necesariamente una ruptura con la comunidad sino, en muchas ocasiones, un enriquecimiento puesto que permite afrontar la solución a un problema mediante la creación de varias y diferentes herramientas. En este sentido, nos acercaríamos al concepto de ARENDT sobre el enriquecimiento que el disenso genera en la pluralidad de la democracia, en lugar del reprobable pensamiento único.
En la actualidad la escisión es el segundo de los pasos para la creación: lo primero que hace un desarrollador cuando le gusta un software escrito por otro desarrollador es copiarlo en su propio ordenador. Una vez copiado, el segundo acto que ejecuta es escribir sobre el código copiado, por lo que ya está mutando el código inicial (esta mutabilidad supone apartarse formalmente del código inicial, desarrollándolo). El tercero de los pasos será publicarlo en un servidor accesible al público y comunicarse (no necesariamente) con el autor o autores del código inicial para mostrarle sus modificaciones, que pueden ser integradas por aquellos, en el caso de que les convenza. Podemos en este sentido señalar que la escisión tiene el sentido de la bifurcación de PRIGOGINE o de la propensidad de POPPER: el código, dado que es un texto que se escribe, permite muy fácilmente la escisión, la bifurcación, la propensidad.
Estos actos implican necesariamente, al menos, lo siguiente:
a) Un ejercicio personal de transparencia. La obra se escribe a la luz pública, por lo que la crítica puede venir de cualquier persona a lo largo del mundo. El autor está sometido al escrutinio público.
b) Un ejercicio de generosidad. La obra se pone a disposición pública con una licencia que permita su copia, ejecución, modificación y publicación; esto es, se regala al procomún digital.
La existencia de forks implica una necesaria política deliberativa para la resolución de conflictos, lo que nos lleva a la autorregulación. Esta política no está escrita sino que se va produciendo según aparecen los conflictos. No obstante, es una práctica ya estandarizada la de las votaciones en la lista de correos que funciona de la siguiente manera: uno de los proponentes de una idea la somete a consideración de la comunidad mediante un correo electrónico a la lista. Se señala una fecha límite para estar o no de acuerdo con la propuesta y los integrantes van votando mediante correos en los que señalan “+1” en caso de estar de acuerdo o “-1” en caso contrario además de, en su caso, realizar una explicación sobre el motivo del voto. De esta manera, la resolución de conflictos se realiza mediante una participación democrática de una persona, un voto, en donde existe una autonomía de los integrantes, si bien la existencia de uno o varios líderes carismáticos influye en las posturas de los demás integrantes de la comunidad.
Los desarrolladores siguen otra práctica procedimental interesante, consistente en el «Release early, release often»: libera pronto, libera a menudo (RAYMOND: 1999, 38). De esta manera, el programador atiende a la comunidad y comunica lo más fluidamente posible la evolución de la obra creada, lo que implica en principio una mayor comunicación con los demás miembros de la comunidad, un mayor intercambio de información, aunque su contenido sea código informático. No obstante, tiene su lógica pensar que cuantos más commits (publicaciones de código en el repositorio), más comunicación se producirá por los canales adyacentes (normalmente correo electrónico de la lista específica ya explicada, donde se suscriben los desarrolladores para comunicarse entre sí y discutir la marcha de la implementación).
Por último, ha de señalarse que la existencia de una comunidad, de una producción transparente, de políticas deliberativas, del fork y las liberaciones rápidas de código como sistema de trabajo, implican, obligan y modelan un espacio público deliberativo. Obliga puesto que sin tal espacio público deliberativo previo este sistema de producción es imposible; a su vez, la necesidad de mecanismos distribuidos ha modelado el espacio público que se necesita para poder deliberar y desarrollar código y, por último, la existencia de un repositorio de código de esta naturaleza implica la existencia de una comunidad existente (o pretérita, pero cuyo código puede ser retomado por cualquier persona y continuar el desarrollo que se hallaba parado).
Repasemos las virtudes concretas que se han señalado en estos modelos de desarrollo:
No es difícil inferir que el ejercicio continuado de este tipo de prácticas implica necesariamente entrenarse en hábitos virtuosos útiles para el desarrollo de la democracia, aun cuando por parte de los organismos estatales no se fomenten políticas públicas que las implementen. El crecimiento ciudadano, en este caso, se produce de abajo-arriba y no de arriba-abajo; por utilizar un término anglosajón, este tipo de prácticas generan movimientos grass-roots habituados a trabajar en grupo, horizontalmente y en busca de un objetivo común a todos los integrantes.
La existencia de este tipo de prácticas en la producción del código informático no sólo es recomendable por los modos de producción descritos en el apartado anterior, sino que podemos ir más allá y defender su obligatoriedad en determinados supuestos de producción de código utilizado por el Estado. No sólo se trata de implementar conductas virtuosas en los ciudadanos sino defender que un código producido mediante las interacciones señaladas reúne unas características especiales de posibilidad de auditoría. Además, según LAFUENTE et al. (2009, 5), «El software libre favorece la cultura abierta: Abierto es el concepto que reúne una constelación de rasgos propios de las estructuras horizontales, distribuidas, cosmopolitas, auditables y meritocráticas». Los supuestos en que defiendo que el software libre ha de ser obligatorio legalmente son los siguientes:
1. Donde el código informático sea extensión de la norma jurídica. Un nuevo Conde de Romanones diría: Haga usted la ley y el reglamento y déjeme a mí la aplicación informática. Por ejemplo, en un sistema donde la declaración de la renta de las personas físicas ha de hacerse mediante una aplicación informática, si el código no incorpora la casilla para las deducciones fiscales por hijo, entonces mediante un desarrollo defectuoso del código, se habrá cambiado la ley y el reglamento. La razón en este supuesto es el principio de legalidad.
2. Donde el código intervenga en la conexión de organismos públicos. No cabe tener que investigar [8] qué conexiones dispara un ordenador sin autorización o sin conocimiento del usuario y qué datos envía dónde. En este caso, la razón es la soberanía nacional.
3. Donde el código gestione datos de tipo estratégico del Estado, por ejemplo seguridad nacional. No hacerlo así, atentaría contra la soberanía nacional.
4. Cuando exista una solución libre y gratuita, no habrá de utilizarse una opción privativa y de pago. La razón es la racionalización del gasto público.
Sin Software Libre, no hay una sociedad libre. Sin una sociedad libre no hay ciudadanos libres. Sin ciudadanos libres, no hay democracia. Las prácticas del Software Libre suponen unas guías para que los ciudadanos se habitúen a unas prácticas que generen no sólo una mejor democracia sino unos elementos integrantes del núcleo duro de la misma. El tratamiento dado por BENKLER y NISSENBAUM sobre la virtud supone una importante guía, que debe detallarse explicando los actos concretos y los métodos de trabajo utilizados por los desarrolladores y que en su artículo se obvian. De hoy en adelante, no cabe concebir una democracia sin el desarrollo de las virtudes explicadas en el presente artículo, sin perjuicio de que si bien es un requisito necesario, no es suficiente ya que no puede olvidarse un open data ciudadano y una apertura de las APIs (DE LA CUEVA: 2008, 185). Las nuevas formas de producción colectiva, al integrar en su metodología procedimientos altamente relacionales y auditables, contribuyen con su transparencia y riqueza informacional al desarrollo de un ecosistema del procomún digital que debe servir como guía virtuosa de la ciudadanía.
BENKLER, Yochai y NISSENBAUM, Helen (2006). Commons-based Peer Production and Virtue. The Journal of Political Philosophy, volumen 14, número 4, 2006, pp. 394-419. Accesible en línea: http://www.nyu.edu/projects/nissenbaum/papers/jopp_235.pdf Fecha de última consulta: 21 de junio de 2012.
DE LA CUEVA, Javier (2008). Derecho y Tecnología: la apertura de las APIS, Propiedad Intelectual. Nuevas tecnologías y libre acceso a la cultura, Universidad de las Américas, Puebla, Méjico, pp. 173–185. Accesible en línea: http://www.ccemx.org/img_act_x_tipo/propiedadint.pdf Fecha de última consulta: 21 de junio de 2012.
GUTIERREZ, Bernardo (2012). Entrevista a Antonio Lafuente: Los hackers son los científicos de la nueva Ilustración. Código abierto. Blogs 20minutos.es [Internet], 23 de enero. Accesible en línea: http://blogs.20minutos.es/codigo-abierto/2012/01/23/el-estado-nacion-es-torpe-burocratico-y-homogenizador/ Fecha de última consulta: 21 de junio de 2012.
GORCZEVSKI, Clovis y BELLOSO, Nuria (2011). A necessária revisão do conceito de cidadania: movimentos sociais e novos protagonistas na esfera pública democrática, Santa Cruz do Sul, Brasil, EDUNISC. Accesible en línea: http://www.unisc.br/portal/pt/editora/e-books/335/a-necessaria-revisao-do-conceito-de-cidadania-movimentos-sociais-e-novos-protagonistas-na-esfera-publica-democratica.html Fecha de última consulta: 21 de junio de 2012.
HESS, Charlotte y OSTROM, Elinor (2003). Artifacts, Facilities, And Content: Information as a Common-pool Resource. Law & Contemporary Problems, marzo 2003, número 66, pp. 111–145. Accesible en línea: http://scholarship.law.duke.edu/cgi/viewcontent.cgi?article=1276&context=lcp Fecha de última consulta: 21 de junio de 2012.
LAFUENTE, Antonio (2007). Los cuatro entornos del procomún. Archipiélago. Cuadernos de Crítica de la Cultura, noviembre 2007, número 77-78, pp. 15–22. Accesible en línea: http://digital.csic.es/bitstream/10261/2746/1/cuatro_entornos_procomun.pdf Fecha de última consulta: 21 de junio de 2012.
LAFUENTE, Antonio (coord.); CASAS, Luis; DE LA CUEVA, Javier, GONZALEZ-BARAHONA, Jesús y MACHON, Pablo (2009), La oportunidad del Software Libre: capacidades, derechos e innovación, Informe realizado por encargo de la Escuela de Organización Industrial (Ministerio de Industria) para hacer un estudio sobre la viabilidad de una política de implantación del SL en las administraciones públicas, Madrid. Accesible en línea: https://digital.csic.es/handle/10261/38114 Fecha de última consulta: 21 de junio de 2012.
RAYMOND, Eric S. (1999). The Cathedral & The Bazaar. Sebastopol (EEUU), O’Reilly. Accesible en línea: http://catb.org/~esr/writings/homesteading/cathedral-bazaar/index.html Fecha de última consulta: 21 de junio de 2012.
VELASCO, Juan Carlos (2006). La noción republicana de ciudadanía y la diversidad cultural. Isegoría, 2006, número 33, pp. 191–206. Accesible en línea: http://digital.csic.es/bitstream/10261/4042/1/velasco_isegoria_2005.pdf Fecha de última consulta: 21 de junio de 2012.
[1] Veáse STALLMAN, Richard M. (2004), Software libre para una sociedad libre, Madrid, Editorial Traficantes de Sueños. Accesible en línea: http://biblioweb.sindominio.net/pensamiento/softlibre/softlibre.pdf Fecha de última consulta: 21 de junio de 2012. También puede consultarse HIMANEN, Pekka (2001), La ética hacker y el espíritu de la era de la información, Barcelona, Ediciones Destino, y si bien esta obra es anterior a los planteamientos de STALLMAN, los mismos son más historicistas y sociales que éticos, a pesar de su título.
[2] Según citado en HESS y OSTROM (2003): en Lawrence Lessig, Code and the Commons, Keynote Address at the Conference on Media Convergence, held at Fordham University Law School (Feb. 9, 1999). Accesible en línea: http://cyber.law.harvard.edu/works/lessig/fordham.pdf Fecha de última consulta: 21 de junio de 2012.
[3] Según citado en HESS y OSTROM (2003): Yochai Benkler, The Commons as a Neglected Factor of Information Policy, Remarks at the Telecommunications Policy Research Conference (Sept. 1998). Accesible en línea http://www.benkler.org/commons.pdf Fecha de última consulta: 21 de junio de 2012.
[4] Según citado en HESS y OSTROM (2003): Jessica Litman, The Public Domain, 39 EMORY L.J. 965, 975 (1990).
[5] Hasta tal punto es así que un texto clásico es el de Cómo hacer preguntas de manera inteligente, que implica un protocolo de actuación sobre cómo preguntar. De esta manera, ante la aparición de un newbie (un novato) que comienza a hacer preguntas sin haber intentado obtener previamente por sí las respuestas, no se le responde sino que se le envía al texto de Cómo hacer preguntas de una manera inteligente. Accesible en línea http://www.sindominio.net/ayuda/preguntas-inteligentes.html Fecha de última consulta: 21 de junio de 2012.
[6] Github (http://github.com) es una página web que sirve de repositorio público para los proyectos de un desarrollador. Por ejemplo, la cuenta de usuario del autor de este artículo es http://github.com/jdelacueva, donde pueden consultarse los trabajos que desarrollo.
[7] La expresión «Show me the code», es uno de los axiomas del software libre. Proviene de un mensaje de Linus Torvalds a la lista de correo de desarrollo del kernel de Linux: «Talk is cheap: Show me the code». Accesible en línea https://lkml.org/lkml/2000/8/25/132 Fecha de última consulta: 21 de junio de 2012.
[8] Esto se realiza mediante la instalación de un sniffer, un software que archiva los datos que se transmiten a través de una interfaz.
