El componente final del software libre es la coordinación. Para muchos participantes y observadores, esta es la innovación central y el significado esencial del código abierto: la posibilidad de tentar potencialmente a un gran número de voluntarios a trabajar gratuitamente en un proyecto de software, aprovechando la ley de los grandes números, "la producción entre pares", "las economias del don", y las "economias sociales auto-organizadas". La coordinación en el software libre es de un tipo distinto de la que emergió en los noventa, directamente de los temas de compartir código fuente, concebir sistemas abiertos y escribir licencias de copyright --- todos precursores de las prácticas de coordinación. Las historias que rodean estos temas encuentran su continuación en aquella del kernel del sistema operativo Linux, del servidor web Apache, y de Herramientas de Gestión del Código Fuente; en conjunto estas historias revelan cómo la coordinación funcionaba y como se veía en los noventa.
La coordinación es importante porque aúna y resuelve la distinción entre formas técnicas y sociales en un significativo todo para los participantes. De una parte está la coordinación y administración de personas, de la otra la coordinación del codigo fuente, parches, correciones, informes de errores, versiones y distribuciones - pero en conjunto hay un significativa práctica tecnosocial de administración, toma de decisiones, y ACCOUNTING/contabilidad, que conduce a la producción colaborativa de software y redes complejos. Esta coordinación no sería nada excepcional, ya que esencialmente imita practicas corporativas de ingeniería establecidas excepto por un hecho clave: no tiene objetivos. La coordinación en el software libre privilegia la adaptabilidad sobre la planificación. Esto supone más que simplemente permitir cualquier tipo de modificación; la estructura de la coordinación en el software libre da de hecho prioridad a una apertura generalizada al cambio, mas que al seguimiento de planes, metas o ideales compartidos dictados o controlados por una jerarquía de individuos.
La adaptabilidad no significa azar o anarquía, sin embargo; es un forma muy específica de resolver la tensión entre la curiosidad individual y virtuosismo de los hackers, y la coordinación colectiva necesaria para crear y usar software y redes complejos. Ningún hombre es una isla, pero ningún archipielago es una nación, por asi decirlo. La adaptabilidad preserva el "placer" y la "diversión" de programar sin sacrificar la cuidadosa ingenieria de un producto estable. Linux y Apache deben entenderse como el resultado de este tipo de coordinación: experimentos con la adaptabilidad que han funcionado, para sorpresa de muchos que han insistido en que la complejidad requiere de planificación y jerarquía. Las metas y la planificación son THE PROVINCE OF GOVERNACE / terreno de la gobernabilidad: la práctica de fijar objetivos, orientación y definición de control, pero la adaptabilidad es la provincia / terreno de la crítica, y es por esto que el software libre es un público recursivo: se posiciona al margen del poder y ofrece una crítica constructiva en la forma de WORKING ALTERNATIVES / crear las alternativas. No es el dominio de lo nuevo (después de todo Linux es sólo un REWRITE / una reescritura de UNIX), sino el dominio de empresa colectiva crítica y con una RESPONSIVE PUBLIC DIRECTION / el dominio de una crítica y receptiva orientación pública hacia un compromiso colectivo.
Linux y Apache son más que piezas de software; son organizaciones de un tipo nada familiar. Mi llamado a que son "publicos recursivos" es útil en la medida en que da un nombre a una práctica que no es corporativa ni académica, no es lucrativa ni sin ánimo de lucro, no es gubernamental ni no-gubernamental. El concepto de público recursivo incluye, dentro del espectro de actividad política, la creación, modificación, y mantenimiento de software, redes y documentos legales. Mientras que un "público" en la mayoria de las teorías es un grupo de personas y un discurso que da una forma expresiva a cierta preocupación, el "público recursivo" pretende sugerir que los geeks no solo dan una forma expresiva a un tipo de preocupaciones (p.e., que el software debe ser libre o que los derechos de propiedad intelectual son muy expansivos) sino que también dan una forma infraestructural concreta a los medios de expresión ITSELF / en sí misma. Linux y Apache son herramientas para crear nuevas redes por las cuales expresiones de nuevos tipos pueden ser garantizadas y por las que posteriores experimentos con la infraestructura pueden continuar. Para los geeks, el hacking y la programación son variantes de la libertad de expresión y la FREEDOM OF ASSEMBLY / el derecho de reunión.
De UNIX a Minix a Linux
Linux y Apache son dos casos paradigmáticos del software libre en los noventa, tanto para los hackers como para los académicos del software libre. Linux es un núcleo de sistema operativo tipo UNIX, BOOSTRAPPED OUT / iniciado a partir / surgido a partir del sistema operativo MINIX creado por Andrew Tanenbaum. Apache es la continuación del proyecto original del NATIONAL CENTER FOR SUPERCOMPUTING APPLICATIONS (NCSA, Centro Nacional de Aplicaciones de Supercomputación) para crear un servidor web (el programa original de Rob McCool llamado httpd), BOOTSTRAPPED OUT / iniciado a partir / surgido a partir de una colección distribuída de gente que usaba y mejoraba ese software.
Tanto Linux como Apache son experimentos en coordinación. Ambos proyectos desarrollaron sistemas de toma de decisiones a partir de la práctica: un sistema de votación en el caso de Apache y una estructura jerárquica de tomadores de decisiones, con Linus Torvalds como dictador benevolente, en el caso de Linux. Ambos proyectos tambien exploraron herramientas tecnicas novedosas , especialmente herramientas de Gestión del Código Fuente (SCM, Source Code Management) como el Concurrent Versioning System (CVS). Ambos se citan como ejemplos de como la "diversión", el "placer" o el interés determina la participación y de cómo es posible mantener y animar a la participación y la ayuda mutua en vez de NARROWING THE FOCUS / restringir el centro o de eliminar caminos para la participación.
Más allá de estos experimientos específicos, las historias sobre Linux y Apache se detallan aquí porque ambos proyectos fueron activamente centrales para la construcción y la expansión de Internet de la década de los 90 al permitir a un número masivo de sitios corporativos y no corporativos instalar y ejecutar servidores en Internet de forma barata. Si Linux y Apache no fueran más que proyectos de aficionados con unos cuantos miles de TINKERERS / manitas interesados, en vez de los componentes técnicos centrales de una red planetaria emergente, probablemente no representarían el mismo tipo de transformación revolucionaria ULTIMATELY BRANDED / finalmente nombrada "movimiento" en 1998-99.
La creación del kernel de Linux por Linus Torvalds es frecuentemente citada como el primer ejemplo de un modelo de desarrollo de "Software de Código Abierto" real, y se ha convertido rápidamente en el más estudiado de los proyectos de software libre. A partir de su aparición a finales de 1991, Linux creció desde un pequeño kernel que apenas funcionaba en una alternativa completamente funcional a varios de los sistemas UNIX comerciales que habían aparecido a raiz de las UNIX WARS de los ochenta, Se ha converido en lo suficientemente versátil como para ser usado en PCs de escritorio con muy poca memoria y pequeñas CPU hasta en "CLUSTERS" que facilitan una potencia de computo MASSIVELY PARALLEL.
Cuando Torvalds comenzó, estaba bendecido por una ávida audiencia de hackers deseosa de ver ejecutandose un sistema UNIX en ordenadores personales y por un estilo de ánimo personal que produjo una enorme POSITIVE FEEDBACK / reacción positiva. Torvalds es reconocido frecuentemente por crear, con su "estilo de gestión" una "nueva generación" de software libre, una generación más joven que la de Stallman o Raymond. Linus y Linux no son de hecho la causa de este cambio, sino el resultado de estar en el sitio adecuado, en el momento adecuado y de reunir un número de componentes. En realidad, el título de la relexión semi-autobiográfica de Linux sobre Linux, "Sólo por diversión: la historia de un revolucionario accidental", describe el caracter de su creación.
La "diversión" mencionada en el título refleja el hecho de priorizar la adaptibilidad a la planificación. Los proyectos, las herramientas, la gente o el código divertidos eran aquellos que no estaban determinados por normas e ideas preexistentes. La diversión, para los geeks, estaba relacionada (especialmente para estudiantes universitarios y hackers aficionados) con la repentina disponibilidad de un mundo subterráneo de redes y software que se expandía cada vez más rápido, especialmente Usenet e Internet; pero también de redes exclusivamente universitarias, medios en línea, juegos y herramientas para navegar por información de todos los tipos. Buena parte de esta actividad ocurría sin el beneficio de ninguna teorización explícita, con la posible excepción del discurso de "comunidad" (que vio la luz en letra de molde en 1993 por obra de Howard Rheingold, y fue presentado en una forma primigenia en las páginas de Wired y Mondo 2000) que se desarrolló a lo largo de la década de los 90. Durante el final de los años 80 y principios de los 90 se dio un gran aumento de la experimentación con posibilidades colaborativas, con Internet como medio. Especialmente atractivo fue [PÁGINA 214], que fue construido con herramientas libres y gratuitas que, de hecho, estaban abiertas también a la modificación y reutilización creativa. Era una forma de trabajar que reflajaba el medio casi académico y casi comercial del que UNIX era un ejemplo: ni investigación pura divorciada de un contexto comercial, ni por completo en el dominio de la voracidad comercial y la propiedad intelectual.
La diversión incluía crear listas de correo gracias a la rápida expansión de software como list-serv y majordomo; el mantenimiento y moderación colectivos de Usenet; la creación de Multi-User Dungeons (MUDs) y Mud Object Orienteds (MOOs), herramientas que ofrecían a los videojugadores y geeks de Internet una forma de crear conjuntamente medios software y descubrir muchos de los problemas que emergen a la hora de gestionarlos y moderarlos. También incluía la creciente panoplia de "servicios de información" que se estaban construyendo alrededor de Internet, como archie, gopher, Veronica, WAIS, ftp, IRC... Todos ellos necesarios para acceder a la creciente riqueza que suponía la información generada por la comunidad que reptaba en los subterráneos de Internet. El sentido y la práctica de la forma de coordinarse de cada uno de estos proyectos estaba disponible para todos: algunos estaban organizados estrictamente como proyectos de investigación universitaria (gopher), mientras que otros fluían con más naturalidad y estaban abiertos a la participación (e incluso al control) de los miembros que contribuían en ellos (MOOs y MUDs). El asunto de las licencias era explícito en algunos, poco claro en otros y totalmente ignorado en los demás. Algunos proyectos tenían líderes autocráticos, mientras que otros experimentaban con todo, desde la democracia representativa al anarquismo.
El diseño y la adaptibilidad
El papel de Tanenbaum en la historia de Linux es normalmente el del hombre de paja: un viejo y malhumorando profesor de ciencias de computación que se opone al joven y revolucionario Torvalds. Tanenbaum en sí ha tenido una cierta reputación revolucionaria ya que Minix fue utilizado en aulas alrededor del mundo y se podía instalar en los ordenadores personales IBM (algo que ningún otro vendedor de la versión comercial de UNIX llegó a lograr), pero a la vez era un blanco natural para gente como Torvalds: un profesor titular que apoya una versión de libro de texto sobre un sistema operativo. Así que, a pesar del hecho de que una gran cantidad de personas utilizaba o conocía Minix como un sistema operativo UNIX (el número estimado de suscriptores del grupo de discusión comp.os.minix fue 40 000), Tanenbaum estaba rotundamente desinteresado en la colaboración o la depuración colaborativa, especialmente si la depuración significaba también creación de extensiones y adición de características que pudiesen hacer el sistema más grande y más difícil para usar como una herramienta básica de enseñanza. Para Tanenbaum este era el punto crucial: "Continuamente he estado recibiendo ofertas de memoria virtual, paginación de memoria, enlaces simbólicos, sistemas de ventanas y todos los tipos de características. En la mayoría las he rechazado porque, todavía, intento mantener el sistema lo suficientemente simple de entender para los estudiantes. Puedes meter todas estas cosas en tu versión, pero yo no [PAGE 218] las pondré en la mía. Creo que esto es lo que más le fastidia a la gente que dice: Minix no es free, y no los 60$".11
Asimismo, mientras que Tanenbaum simpatizaba con los objetivos de la FSF (en la medida que claramente quiso que la gente use, actualice, realce y aprende del software), no simpatizaba con la idea de tener 40 000 desconocidos que "mejoran" su software. En otras palabras, las metas de Minix continuaron siendo las de un investigador y autor de un libro de texto: ser útil en clases y bastante barato para ser extensamente disponible y utilizable en el mayor número de ordenadores baratos.
Por el contrario, el proyecto "diversión" de Torvalds no tenía objetivos. Al ser un chulo estudiante de 19 años con lo poco bueno que hacer (sin libros de texto para escribir, sin estudiantes, becas, proyectos de investigación o reuniones del comité), Torvalds, para mejorar su proyecto, estaba encantado de aceptar toda la ayuda ya preparada que pudo encontrar. Y con 40 000 usuarios de Minix disponía de un grupo de colaboradores más o menos instantáneo. Para comparar, el público de Stallman para EMACS, en los principios de la década de los 80, estaba limitado a cien computadoras diferentes que podían ser traducidas / convertidas en miles, pero, desde luego, no en decenas de miles de usuarios. El esfuerzo de Tanenbaum de crear una generación de estudiantes que no sólo comprende (comandos) internos de un sistema operativo, sino, más específicamente, comprende los (comandos) internos del sistema operativo UNIX, creó una fuente enorme de competentes y entusiastas hackers de UNIX. Esa labor de portar UNIX no sólo a varias máquinas sino, también, a una generación de mentes, estableció un escenario para este evento y es un aspecto esencial, aunque muchas veces ignorado, del éxito de Linux.
Muchos relatos de la historia de Linux están centrados en la lucha entre Torvalds y Tanenbaum, una lucha llevada por comp.os.minix con el título: "Linux está obsoleto".12 Tanenbaum argumentó que Torvalds estaba reinventando la rueda: escribiendo un sistema operativo que, según el punto de vista de última generación, estaba ya obsoleto. Por otro lado, Torvalds declaró que era mejor hacer algo rápido y sucio que funcionase, invitar contribuciones y luego preocuparse por hacerlo de última generación. Lejos de ilustrar algún tipo de conservatismo anticuado por parte de Tanenbaum, el debate destaca una distinción entre las formas de coordinación y los significados de colaboración. Para Tanenbaum los objetivos de Minix eran o pedagógicos, o académicos: enseñar las bases de sistema operativo o explorar nuevas posibilidades en el diseño de sistema operativo. Según este modelo Linux incumplía ambos: no podía ser utilizado en clases porque [PAGE 219] pronto sería demasiado complejo y repleto de características para ser enseñado, y no estaba ampliando las fronteras de la investigación porque era un sistema operativo caducado. Torvalds, por el contraste, no tenía objetivos. Lo que movía su progreso era un compromiso con la diversión y una bastante indefinida impresión de lo que le interesaba a él y a los demás, desde el principio fijado casi totalmente en contra de Minix y otros sistemas operativos libres como FreeBSD. De tal modo, esto/Linux sólo pudo surgir fuera de contexto - que determinó los límites de su diseño - de UNIX, sistemas abiertos, Minix, GNU y BSD.
Ambos Tanenbaum y Torvalds operaron bajo el modelo de coordinación donde una persona fue responsable en última instancia por el proyecto entero: Tanenbaum supervisó Minix y aseguró que permaneciera fiel a sus objetivos de servir a la audiencia pedagógica; Torvalds supervisaba Linux, pero él incorporaría tantas características diferentes cuantas los usuarios querían o podían contribuir. Rápidamente, con un grupo de 40 000 colaboradores potenciales, Torvalds estaría en la misma situación en la que estuvo Tanenbaum, es decir, obligado a tomar decisiones sobre los objetivos de Linux y sobre cuáles mejoras añadir a él y cuáles no. Lo que hace la historia de Linux tan interesante para seguir es el hecho de que aparentemente Torvalds no tomó ninguna decisión: aceptó casi todo.
Los objetivos y planes de Tanenbaum para Minix eran claros y formados de manera autocrática; al fin y al cabo, el control, la jerarquía y la restricción son apropiadas para la aula. Sin embargo, Torvalds quería hacer más. Él quería continuar aprendiendo y probando alternativas, y con Minix como la única manera ampliamente accesible de hacerlo, su decisión de partir los caminos empieza a tener sentido; obviamente estaba acompañado en su deseo de explorar y extender lo que había aprendido. No obstante, Torvalds enfrentó los problemas de coordinación de un proyecto nuevo y tomó decisiones parecidas en cuanto a su rumbo. En aquel instante, Linux fue un tema de mucha reflexión tanto para los de dentro como para los de afuera. A pesar de la imagen de Linux como un bazar anárquico o una dictadura autocrática, la realidad es más sutil: incluye una jerarquía de colaboradores, (técnicos de) mantenimiento y "tenientes fiables", y un sentido sofisticado, informal e intuitivo de "buen gusto" conseguido durante la lectura e incorporación del trabajo de los co-desarrolladores.
Aunque Torvalds fue capaz de mantenerse a cargo como un individuo durante los primeros años de Linux (aprox. entre 1991 y 1995), con el tiempo empezó a delegar parte de este control a personas que tomarían decisiones acerca de los diferentes sub-componentes del kernel. [PAGE 220] De este modo era posible incorporar más "parches" (trozos del código) aportados por voluntarios: distribuyendo una parte del trabajo de su evaluación a gente diferente que / que no sea Torvalds. Esa jerarquía informal se transformó despaciosamente en una formal, como indica Steven Weber: "La de facto concesión final de autoridad tuvo lugar cuando Torvalds públicamente empezó a redireccionar las sumisiones relevantes a los tenientes. En 1996 la estructura de decisión se volvió más formal con una explícita diferenciación entre desarrolladores CREDITED/con mérito y técnicos de mantenimiento. ...Si esto suena bastante como una estructura de decisión jerárquica es porque lo fue, si bien es cierto que la participación en ella era totalmente voluntaria".13
Casi todas las decisiones que tomaron Torvalds y los tenientes eran del mismo tipo: incorporar o no un trozo de código sometido por un voluntario. Cada una de estas decisiones era técnicamente compleja: insertar el código, recompilar el kernel, probar si esto funciona o si produce algunos errores de programación, decidir si vale o no guardarlo, repartir una nueva versión con un listín de cambios aplicados. A pesar de que varios dirigentes oficiales obtuvieron la autoridad para hacer estos cambios, la coordinación, técnicamente, era todavía informal. Desde/dado que todos ellos estaban trabajando sobre el mismo complejo objeto técnico, hacía falta que en última instancia una persona (Torvalds) verifique la versión final, incluyendo todos los (sub)componentes, para asegurar que funcionaba sin averiar.
Semejantes decisiones tenían muy poco que ver con cualquier tipo de objetivos o planes de diseño, sino con el hecho de si el parche aportado "funcionó", una expresión que refleja enseguida los criterios técnicos, estéticos, legales y de diseño que no están registrados en ninguna parte del proyecto, por lo tanto, el privilegio de adaptabilidad ante planificación. En ningún momento estos parches han sido asignados o solicitados, aunque Torvalds es merecidamente reconocido por animar a la gente a trabajar sobre problemas particulares, pero sólo si ellos querían. En consecuencia, el sistema se transformó de manera sutil e imprevista, divergiendo su diseño original, supuestamente retorcidamente "monolítico", en una configuración novedosa que reveló los intereses de los voluntarios y los criterios implícitos de los dirigentes.
Parcheado y Voto
El servidor Web Apache y el grupo Apache (ahora llamado Apache software Foundation) aportan un segundo ejemplo esclarecedor del cómo y el por qué de la coordinación en el Sofware Libre de los años noventa. Como en el caso de Linux, el desarrollo del proyecto Apache ilustra como la adaptabilidad se prima sobre la planificación y, en particular, como ésto pretende resolver las tensiones existentes entre la curiosidad individual y el virtuosismo y el control colectivo y la toma de decisiones. Es también la historia de la progresiva evolución de la coordinación, los mecanismos simultáneamente técnicos y sociales para coordinar personas, código, parches y votos.
El proyecto Apache emergió de un grupo de usuarios del servidor Web httpd (HyperText Transmission Protocol Daemon) original, creado por Rob McCool en el NCSA, basado en el trabajo llevado a cabo por el proyecto WORLD WIDE WEB de Tim Berners-Lee en el CERN. Berners-Lee había redactado una especificación para WORLD WIDE WEB que incluía el lenguaje de marcado HTML, el protocolo de transmisión http y un juego de librerías que implementaban el código conocido como libwww, que éste había ENTREGADO al dominio público. 15
El NCSA de la Universidad de Illinois, en Urbana-Champaign, tomó ambos proyectos www, creando posteriormente el primer nevegador ampliamente usado, Mosaic (dirigido por Marc Andreessen) y httpd. Httpd era de dominio público hasta la versión 1.3. El desarrollo se ralentizó cuando McCool fue ATRAÍDO HACIA Netscape, junto con el equipo que creó Mosaic. A principios de 1994, cuando la WORLD WIDE WEB se empezó a extender, muchos individuos y grupos EMPLEABAN/CORRÍAN servidores Web que usaban httpd; algunos de ellos habían creado extensiones y corregido errores. Éstos eran desde investigadores universitarios hasta corporaciones como Wired Ventures, que lanzaron la versión en red de su revista (HotWired.com) en 1994. La mayoría de los usuarios se comunicaban principalmente a través de Usenet, en los grupos de noticias comp.infosystems.www.*, compartiendo experiencias, instrucciones y actualizaciones del mismo modo que otros proyectos de software remontándose hasta el comienzo de los grupos de noticias de Usenet y Arpanet.
Cuando el NCSA fue incapaz de responder a la mayoría de las correciones y extensiones propuestas, un grupo de unos cuantos de los usuarios más activos de httpd se empezaron a comunicar a traves de una lista de correos llamada new-httpd en 1995. La lista era mantenida por Brian Behlendorf , el webmaster de HotWired, en un servidor que gestionaba llamado hyperreal; sus participantes eran aquellos que habían depurado httpd, creado extensiones y añadido funcionalidad. La lista era el medio principal de asociación y comunicación para un grupo diverso de personas de varios lugares alrededor del mundo. Durante el año siguiente, los participantes discutieron cuestiones relacionadas con la coordinación, la identidad de y los procesos involucrados en parchear el "nuevo" httpd, versión 1.3.16.
Parchear un fragmento de software es una actividad peculiar, similar a depurar, pero más como una suerte de diseño ex post facto. El parcheado cubre el espectro de los cambios que se puedan realizar: desde corregir brechas de seguridad y errores que impidan que el software compile hasta mejorar las características y el rendimiento. Un gran número de los parches que inicialmente unieron a este grupo nacieron de necesidades que cada miembro individual tenía al elaborar una función para un servidor Web. Estos parches no se debieron a ninguna decisión de diseño ni de planificación por parte del NCSA, McCool, o el grupo formado, pero la mayoría fueron lo suficientemente útiles como para que todos ganasen con su uso, porque corregían los errores que cualquiera se encontraría o podría encontrarse. Como resultado, la necesidad de una PUBLICACIÓN coordinada de new-http era clave para el trabajo del grupo. Esta nueva versión de httpd del NCSA no tenía inicialmente nombre, pero Apache era un candidato habitual; el origen algo apócrifo del nombre es que era un "SERVIDOR PARCHEADO".17 [¿¿POSIBLE NdeT?? - “a patchy webserver.”]
Al comienzo, en febrero y marzo de 1995, el ritmo de trabajo de los distintos miembros de new-httpd difería bastante, pero era en general extremadamente rápido. Incluso antes de que hubiese una PUBLICACIÓN oficial del nuevo httpd, el grupo tuvo que enfrentarse a cuestiones de procedimiento, como Roy Fielding posteriormente explicó: "Apache arrancó con la conciencia de solventar primero las cuestiones procedimentales, incluso antes de que el desarrollo comenzase, porque era claro desde el principio que un conjunto de voluntarios geograficamente distribuidos, sin lazos organizativos tradicionales, iba a requerir un proceso único para poder tomar decisiones."18
La necesidad de procedimientos surgió de modo más o menos orgánico, según el grupo desarrollaba mecanismos para gestionar los distintos parches: asignandoles identificadores, probándolos, e incorporándolos "a mano" en THE MAIN SOURCE-CODE BASE / CÓDIGO FUENTE PRINCIPAL. Según esto ocurría, algunos miembros de la lista se encontraban ocasionalmente perdidos, confundidos por los procedimientos o la eficiencia de los demás miembros, tal como en este mensaje de Andrew Wilson al respecto de la gestión de Cliff Skolnick de la lista de errores:
Cliff, te puedes concentrar en obtener una copia actualizada de la lista de fallos/mejoras por favor. Ya he perdido la pista de lo que demonios se supone que está pasando. También, cual es el estado de este Apache PRE-PRE-PRE RELEASE? Es un pre o no lo es con seguridad? Y es la cosa pre-pre-etc la misma cosa en la que se supone que Cliff está trabajando?
Que fsck (JUEGO DE PALABRAS INTRADUCIBLE) está pasando? Ay, ay, ay! Andrew Wilson. 19
A lo cual Rob Harthill respondió, "Está volviendose engorroso. Sigo pensando que todos juntos deberíamos implementar un solo parche cada vez. A la marcha (y horas) a la que algunos trabajan, podríamos manejar un par de parches al día... si ésto es aceptable para el resto del grupo, creo que deberíamos ordenar los parches y empezar un proceso sistemático de discusión, implementación y pruebas".20
Algunos miembros encontraron este ritmo de trabajo estimulante, mientras que otros hicieron un llamamiento para ralentizar o parar para estudiar la situación. Cliff Skolnick creó un sistema de gestión de los parches y propuso que los miembros de la lista votasen para así determinar que parches serían incluidos.21 Rob Harthill votó primero.
Aquí están mis votos para la actual lista de parches, mostrada en http://www.hyperreal.com/httpd/patchgen/list.cgi Aplicaré un voto de -1 tengo un problema con él 0 aún no lo he probado (no he conseguido entenderlo o lo que sea) +1 lo he probado, me ha gustado y no tengo problemas con él. [Aquí Harthill proporciona una lista de votos para cada parche.] Si este sistema de votación os parece bien, usémoslo para cribar aquello con lo que estemos contentos. Un voto "-1" debería vetar cualquier parche. Parece que somos como 6 o 7 los que comentamos activamente sobre los parches, así que sugeriría que una vez un parche obtenga un voto de +4 (sin vetos), lo podemos añadir a un alpha.22
Los votos de Harthill inmediatamente instigaron la discusión sobre varios parches, votos posteriores, y sobre el proceso (p.ej., cuantos votos y vetos eran necesarios), todo mezclado en una oleada de mensajes de correo electrónico. El proceso de votación estaba lejos de ser perfecto, pero permitía cierto consenso en lo que "apache" llegaría a ser, esto es, qué parches sería incorporados en una publicación "oficial" (aunque no demasiado pública): Apache 0.2, el 18 de marzo.23 Sin un sistema de votación el grupo de colaboradores pordría haber continuado aplicando parches de forma individual, cada uno en su propio contexto, corrigiendo los problemas que se presentasen a cada usuario, pero ignorando aquellos que fuesen irrelevantes o innecesarios en ese contexto. Con un proceso de votación, sin embargo, podría surgir un acuerdo al respecto de un probado y aprobado new-httpd. Segun se refinaba el proceso, los miembros buscaron a un voluntario para TOMAR votos, abrir y cerrar las votaciones una vez a la semana y construir una nueva versión de Apache cuando las votaciones hubieran finalizado. (Andrew Wilson fue el primer voluntario, a lo cual Cliff Skolnick respondió, "Supongo que la primera votación es para votar a Andrew como el VOTE TAKER :-).")24 El proceso de "parche y voto" que surgió en las primeras etapas de Apache no era enteramente novedoso; muchos colaboradores señalaron que el proyecto FreeBSD emplaba un proceso similar, algunos apuntaron la necesidad de un "coordinador de parches" y otros se mostraron preocupados pues "usar parches se pone muy feo, my rápidamente."25
La importancia del sistema de "parche y voto" residía en que calaramente representaba la tensión entre el virtuosismo de los desarrolladores individuales y un proceso en grupo dirigido a crear y mantener un fragmento de software común. Era una manera de equilibrar la habilidad de cada individuo frente a un deseo común de proporcionar y promover un servidor estable, libre de errores y de dominio público. Como Rob Fielding y otros lo describirían en retrospectiva, esta tensión era parte de la ventaja de Apache.
A pesar de que el Apache Group toma decisiones como un todo, el verdadero trabajo del proyecto es llevado a cabo por individuos. El grupo no escribe código, diseña soluciones, documenta productos, o provee soporte a nuestros clientes; los individuos lo hacen. El grupo proporciona un clima para la colaboración y una excelente prueba de fuego para ideas y código, pero el impulso creativo necesario para solventar un problema en particular, rediseñar un fragmento del sistema, o corregir un determinado error es casi siempre aportado por voluntarios individuales trabajando por su cuenta, para sus propósitos y no a instancias del grupo. Los competidores erróneamente asumen que Apache será incapaz de enfrentarse a tareas nuevas o inusuales debido a la percepción de que actuamos como un grupo en lugar de seguir a un único lider. Lo que no consiguen ver es que, al permanecer abiertos a nuevos colaboradores, el grupo tiene un suministro ilimitado de ideas innovadoras, y es que los individuos que deciden perseguir sus propias ideas son la verdadera fuerza motriz de la innovación.
A pesar de que la apertura se presenta generalmente como la clave de las innovaciones de Apache, dicha afirmación es algo falaz: los parches son sólo eso, parches. Cualquier cambio a gran escala en el código no se podría lograr aplicando parches, especialmente si cada parche ha de someterse a un severo proceso de votación para ser incluido. La unica forma de hacer cambios radicales (especialemente cambios que requieren iteraciónes y pruebas para quedar bien) es acometer diversas "ramas" de un proyecto o diferenciar entre publicaciones internas y externas; en resumen, bifurcar el proyecto temporalmente con la esperanza de que pronto converja en su raiz estable. Apache se topó con este problema bien temprano con la reescritura "Shambhala" de httpd a cargo de Robert Thau.
Shambhala nunca fue del todo oficial: Thau lo llamaba su servidor de NOODLING/"cacharrear", o un proyecto de "garaje". Comenzó como su intento de reescribir httpd como un servidor que pudiera manejar y procesar múltiples peticiones al mismo tiempo. Como experimento, era enteramente su proyecto propio, al que ocasionalmente se refería en la lista new-httpd: "Todavía hackeando Shambala, y siendo discreto hasta que funcione lo suficientemente bien como para hablar de él"27. A mediados de junio de 1995, contaba con una versión funcional, la cual anunció, bastante modestamente, a la lista como "un proyecto de garaje para explorar posibles nuevas direcciones que pensaba que quizá fueran útiles como para que el grupo se dedique a ellas."28 Otro miembro de la lista, Randy Terbush, lo probó y le dedicó una crítica entusiasta, y hacia finales de junio había dos usuarios manifestando sus virtudes. Pero como realmente nunca había sido oficialmente identificado como una bifurcación, o un camino de desarrollo alternativo, esto llevo a Rob Harthill a preguntar: "Entonces, ¿cuál es la situación al respecto de Shambhala y Apache? ¿Aquellos que os habéis cambiado estáis abandonando Apache y este proyecto? Si tal es el caso, ¿Necesitáis una lista separada para discutir sobre Shambhala?"29
Harthill había asumido que el código base de la NCSA estaba "probado y testado" y que Shambhala representaba una escisión, una bifurcación: "La cuestión es, ¿deberíamos ir todos en una dirección, seguir según están las cosas, o Shambhala debe seguir su propio camino?"30 Su pregunta puso de relieve la MISCOMMUNICATION/falta de comunicación: Thau lo había planeado como un reemplazo "DROP-IN" para le httpd de la NCSA, y que su intención era hacerlo en núcleo del servidor Apache, si conseguía hacerlo funcionar. Harthill, que había dedicado no poco tiempo de duro trabajo parcheando el codigo de servidor existente, no estaba contento, e hizo explícitos los asuntos del núcleo.
Quizá fue la elección de expresiones de rts [Robert Thau], tales como "proyecto de garaje" y que tiene un nombre diferente, quizás no leí sus correos meticulosamente, quizás no eran suficientemente explícitos, lo que sea... Es una pena que nadie que utilice Shambala (que debería haberse dado cuenta de lo que está pasando) no expusiese el asunto semanas atrás. Sólo puedo asumir que rst fue demasiado modesto como para exponernos Shambala, o por lo menos una discusión a su respecto, de una manera más vigorosa. Recuerdo decir al respecto "ésto es lo que pretendo hacer, detenedme si pensáis que no es buena idea." ¿Por que demonios nadie dijo nada?... Algún otro tuvo la misma impresión que yo del trabajo de rts? Vamos gente, si queréis ser parte de este grupo, ¡colabrad!31
Harthill’s injunction to collaborate seems surprising in the context of a mailing list and project created to facilitate collaboration, but the injunction is specific: collaborate by making plans and sharing goals. Implicit in his words is the tension between a project with clear plans and goals, an overarching design to which everyone contributes, as opposed to a group platform without clear goals that provides individuals with a setting to try out alternatives. Implicit in his words is the spectrum between debugging an existing piece of software with a stable identity and rewriting the fundamental aspects of it to make it something new. The meaning of collaboration bifurcates here: on the one hand, the privileging of the autonomous work of individuals which is submitted to a group peer review and then incorporated; on the other, the privileging of a set of shared goals to which the actions and labor of individuals is subordinated.32 Indeed, the very design of Shambhala reflects the former approach of privileging individual work: like UNIX and EMACS before it, Shambhala was designed as a modular system, one that could “make some of that process [the patch-and-vote process] obsolete, by allowing stuff which is not universally applicable (e.g., database back-ends), controversial, or just half-baked, to be shipped anyway as optional modules.”33 Such a design separates the core platform from the individual experiments that are conducted on it, rather than creating a design that is modular in the hierarchical sense of each contributor working on an assigned section of a project. Undoubtedly, the core platform requires coordination, but extensions and modifications can happen without needing to transform the whole project.34 Shambhala represents a certain triumph of the “shut up and show me the code” aesthetic: Thau’s “modesty” is instead a recognition that he should be quiet until it “works well enough to talk about,” whereas Harthill’s response is frustration that no one has talked about what Thau was planning to do before it was even attempted. The consequence was that Harthill’s work seemed to be in vain, replaced by the work of a more virtuosic hacker’s demonstration of a superior direction. In the case of Apache one can see how coordination in Free software is not just an afterthought or a necessary feature of distributed work, but is in fact at the core of software production itself, governing the norms and forms of life that determine what will count as good software, how it will progress with respect to a context and [PAGE 229] background, and how people will be expected to interact around the topic of design decisions. The privileging of adaptability brings with it a choice in the mode of collaboration: it resolves the tension between the agonistic competitive creation of software, such as Robert Thau’s creation of Shambhala, and the need for collective coordination of complexity, such as Harthill’s plea for collaboration to reduce duplicated or unnecessary work.
Check Out and Commit
Las configuraciones sociales y técnicas que prestan Linux y Apache son posibles gracias a las herramientas que se construyen y utilizan, desde las de seguimiento de errores y listas de correo hasta los servidores Web y kernels en sí mismos. Cualquiera de estas herramientas juega un papel muy concreto en la aparición de estas organizaciones: sistemas de Administración de Código Fuente (SCM's). Son herramientas para coordinar a la gente y el código; permiten a un gran número de personas dispersas geográficamente trabajar simultáneamente en el mismo objetivo; el mismo código fuente, sin la necesidad de la supervisión de una coordinación central y sin el riesgo de pisarse unos a otros. La historia de los SCM's – especialmente en el caso de Linux – también ilustra la profundidad recurrente del problema: a saber, ¿el software libre sigue siéndolo si se crea con herramientas que no son libres? Las herramientas SCM, como el Sistema de Control de Versiones Concurrentes (CVS) y Subversión, se han convertido en extremadamente comunes para programadores de software Libre; en realidad es extraño encontrar un proyecto, incluso dirigido por una sola persona, que no haga uso de estas herramientas. Su función básica es permitir a dos o más programadores trabajar en los mismos archivos al mismo tiempo y proveer retroalimentación donde las ediciones resultan conflictivas. Cuando crece considerablemente el número de programadores, un SCM puede convertirse en una herramienta para gestionar lo complejo. Realiza un seguimiento de los que han “comprobado” archivos; permite a los usuarios bloquear archivos si desean asegurare de que nadie realiza cambios en el mismo momento; muestra y no pierde de vista los cambios conflictivos que dos usuarios hagan de un mismo archivo; puede emplearse para crear bifurcaciones “internas” o “ramas” que pueden ser incompatibles entre ellas, pero sigue permitiendo probar cosas nuevas a los programadores y, si todo va bien, unir después las ramas al tronco. En modos avanzados se puede emplear para “dar vida” a cambios sucesivos de un código, para poder así visualizar su evolución.
Además de las funciones de mera coordinación, los SCMs también se emplean como forma de distribución; generalmente los SCM's permiten a cualquiera comprobar el código, y restringir a aquellos que puedan CHECK IN o “comprometer” el código. El resultado es que los usuarios pueden tener un acceso instantáneo a la versión más actualizada de un trozo de software, y los programadores pueden diferenciar entre RELEASES/liberaciones estables, que tienen pocos errores, e “inestables” o versiones experimentales que están en construcción y necesitarán el apoyo de los usuarios dispuestos a probar y depurar las últimas versiones. Las herramientas SCM automatizan algunos aspectos de coordinación, reduciendo no sólo el trabajo que implica sino también abriendo nuevas posibilidades para la coordinación.
La genealogía de los SCMs se puede observar en el ejemplo de la creación de Ken Thompson de una cinta DIFF, que empleó para distribuir cambios que habían contribuido a UNIX. Donde Thompson vió UNIX como un espectro de cambios y el departamento legal de Bell Labs series de versiones, las herramientas SCM combinan estas dos aproximaciones gestionando las revisiones cada minuto, asignando a cada modificación (cada DIFF) un número de versión, y guardando la historia de todos estos cambios en el software para que puedan ser deshechos con precisión si se pretende descubrir cuáles producen errores. Escrito por Douglas McIlroy, “DIFF” es en sí mismo un trozo de software, una de las populares herramientas de UNIX que hace una cosa así. El programa DIFF compara dos archivos, línea a línea, y extrae las diferencias entre ellos en un formato estructurado (mostrando series de líneas con códigos que indican cambios, añadidos o supresiones). Dadas dos versiones de un texto, se puede ejecutar DIFF para encontrar las diferencias y realizar las modificaciones oportunas para sincronizarlos, tarea que de otra forma resulta tediosa y, teniendo en cuenta la exactitud del código fuente, propensa a errores humanos. Un útil efecto secundario de DIFF (cuando se combina con un editor como ed o EMACS) es que cuando alguien hace una serie de cambios en un archivo y ejecuta DIFF tanto en el archivo original como en el modificado, el resultado (I.E., sólo los cambios) puede ser utilizado para reconstruir el archivo original a partir del modificado. Así pues DIFF permite una forma inteligente y economizadora de espacio de guardar las modificaciones que en cualquier momento se han realizado de un archivo, en lugar de conservar las copias completas de cada nueva versión, se guardan sólo los cambios. Es decir, control de versión. DIFF – y programas como este – se convierten en la base para gestionar la complejidad de un gran número de programadores trabajando en el mismo texto al mismo tiempo.
Uno de os primeros intentos de formalizar un control de versiones fue el Sistema de Control de Revisiones (RCS) de Walter Tichy, de 1985.35 RCS guardaba la pista de las modificaciones de los distintos archivos utilizando DIFF y permitiendo a los programadores ver todos los cambios que se habían realizado al mismo. RCS, sin embargo, no podía realmente mostrar la diferencia entre las modificaciones entre un programador y otro. Todas las modificaciones eran iguales en este sentido, y cualquier duda que pudiera surgir sobre el motivo de la realización de una modificación se quedaba sin resolver.
Con la idea de añadir sofisticación a RCS, Dick Grune, en la Vrije Universiteit, Amsterdam, comenzó a escribir guiones que utilizaran RCS como un multi-usuario, un sistema de cotrol de versiones accesible a través de internet, que finalmente se convirtió en el Sistema de Versiones Concurrentes. CVS permitía que múltiples usuarios comprobaran una copia, realizaran modificaciones, y acometieran esos cambios, y comprobaría o bien prevendría o marcaría modificaciones conflictivas. Finalmente, cvs se hizo más útil cuando los programadores pudieron usarlo de forma remota para comprobar código fuente desde cualquier lugar desde Internet. Permitió a la gente trabajar a velocidades diferentes, en momentos diferentes, y lugares diferentes, sin necesidad de que una persona se quedara al cargo de centralizar las comprobaciones y comparaciones de las modificaciones. Los CVS crearon una forma de control de versiones descentralizada para una escala de colaboración muy amplia; los desarrolladores podían trabajar offline en el software, y siempre con la versión más actualizada, aun trabajando en el mismo objeto.
Tanto el proyecto Apache como el de kernel Linux usan SCM's. En el caso de Apache el original sistema de parche y voto rápidamente empezó a minar la paciencia, tiempo y energía de los participantes en el momento en que el número de colaboradores y parches comenzó a crecer. Desde el principio del proyecto, el contribuyente Paul Richards instó al grupo a utilizar CVS. Había tenido una amplia experiencia con el sistema en el proyecto Free-BSD y estaba convencido de que suponía una alternativa mejor que el sistema de parche y voto. Algunos otros colaboradores habían tenido mucha más experiencia con él no obstante, pero hasta un año después de que Richard comenzara sus amonestaciones no se adoptó CVS. Sin embargo, CVS no es un simple sustituto de un sistema de parche y voto; necesita una organización diferente. Richards reconoció el intercambio. El sistema de parche y voto creaba un nivel alto de garantía de calidad y revisión equitativa de los parches que las personas presentaban, mientras que el sistema CVS permitía a una persona realizar cambios que no alcanzaban el mismo nivel de garantía cualitativa. El sistema CVS permitía ramas – estable, comprobando, experimental – con diferentes niveles de garantía de calidad, mientras que el sistema de parche y voto estaba inherentemente orientado hacia una versión final y estable. Tal como mostró el caso de Shambhala, bajo el sistema de parche y voto las versiones experimentales continuarían siendo proyectos sumergidos no oficiales, más que servir como ramas oficiales con gente responsable para acometer modificaciones.
Aunque los SCM’s son en general buenos para gestionar modificaciones conflictivas, también es cierto que sólo pueden hacerlo hasta cierto punto. Permitir a cualquiera consignar una modificación, en todo caso, puede resultar un caótico desastre, tan complicado de desenredar como lo sería sin un SCM. En la práctica, por tanto, la mayoría de proyectos designaron el derecho a “consignar” modificaciones a un puñado de personas. El proyecto Apache, por ejemplo, mantuvo el sistema de voto pero lo convirtió en un sistema para “consignadores” en lugar de parches en sí mismos. Los de confianza – aquellos con el misterioso “buen gusto”, o la intuición técnica – se convirtieron en la esencia del grupo.
El kernel de Linux también hubo de luchar con varios problemas en torno a los SCM’s y la gestión de la responsabilidad que implicaba. La historia del así llamado árbol VGER y la creación de un nuevo SCM llamado Bitkeeper es ejemplar a este respecto.36 Hacia 1997, los desarrolladores de Linux comenzaron a utilizar CVS para gestionar las modificaciones en el código fuente, no sin resistencia. Torvalds se encontraba todavía al cargo de las modificaciones al árbol estable oficial, pero en cuanto otros “lugartenientes” subieron a bordo, la complejidad de las modificaciones en el kernel crecieron. Uno de esos lugartenientes era Dave Miller, que mantuvo un “espejo” del árbol estable del kernel de Linux, el árbol VGER, en un servidor en Rutgers. En septiembre de 1998 estalló una lucha entre los desarrolladores en torno a dos temas relacionados: uno, el hecho de que Torvalds no estaba incorporando (parcheando) las contribuciones que le habían sido enviadados por algunas personas, incluyendo sus lugartenientes; y dos, como resultado, el repositorios de CVS VGER ya no estaba sincronizado con el árbol estable que mantenía Torvalds. Como consecuencia surgía la amenaza de que aparecieran dos versiones de Linux.
Como bien recoge Moody en Rebel Code, se produjo una gran protesta que culminó en la famosa frase que pronunció Larry McVoy: “Linus no se amplia”. Con esto quería decir que la capacidad de Linux para crecer como proyecto aumentando la complejidad, manejando una miríada de usos y funciones (“ampliarse”), queda constreñida por el hecho de centralizarse en Linus Torvalds. Según todos, Linus era y sigue siendo brillante en lo que hace – pero está todo centralizado en él. Esta situación es peligrosa porque da cabida a la bifurcación. Una bifurcación supondría una o más versiones proliferando bajo diferentes liderazgos, situación más bien similar a la distribución de UNIX. Tanto las licencias como los SCM’s están diseñados para evitar esto, pero como último recurso. La bifurcación implica disolución y confusión – versiones de lo mismo compitiendo e incompatibilidades potenciales imposibles de manejar.
No obstante la bifurcación no ocurrió, pero tan sólo porque Linus se fue de vacaciones y regresó renovado y preparado para continuar y asumir la responsabilidad. Sin embargo se había dado lugar a una crisis, y esto llevó a los desarrolladores a valorar nuevas formas de coordinación. Larry McVoy se ofreció a crear un nuevo formato de SCM que permitiese una respuesta más flexible al problema que el árbol VGER representaba. Sin embargo, la solución propuesta, llamada Bitkeeper, generaría más controversia que la que la precipitó.