Tabla de contenidos
La mayoría de los proyectos de software libre fracasan.
Tratamos de no prestar mucha atención a los fracasos. Solamente los proyectos que tienen éxito llaman la atención, y hay tantos proyectos de software[2] que aún cuando solo un pequeño porcentaje tiene éxito, el resultado es de una apreciable cantidad de proyectos. Pero tampoco prestamos atención a los fracasos porque no los contamos como un evento. No existe un momento puntual en el que un proyecto deja de ser viable; simplemente se los deja de lado y se deja de trabajar en ellos. Puede haber un momento en que se hace un cambio final al proyecto, pero quienquiera que lo haga, normalmente no sabe en ese momento que ese cambio fue el último. Tampoco hay una definición clara del momento en que un proyecto se acaba. ¿Podrá ser cuando se haya dejado de trabajar en él por seis meses? ¿O cuando su base de usuarios deja de crecer, sin antes haber excedido la base de programadores? ¿Y qué pasaría si los programadores de un proyecto lo abandonan porque se dan cuenta que estaban duplicando el trabajo de algún otro—y si se unen todos en el otro proyecto, y lo amplían para incluir ahí su esfuerzo realizado? ¿Acaso el primer proyecto finalizó, o simplemente cambió de lugar de residencia?
Dada esta complejidad, es imposible obtener un número preciso para un promedio de fracasos. Pero la evidencia de lo que ha ocurrido en dos décadas con proyectos con fuente abierta y curioseando un poco en sitios de alojamiento de múltiples proyectos, y otro poco en Google, se llega siempre a la misma conclusión: el porcentaje es muy alto, probablemente algo así como el 90–95%. Este número crece aún más si se incluyen los proyectos que sobreviven pero son disfuncionales: aquellos que producen un código que funciona, pero no son placenteros ni amigables, o no progresan tan rápidamente ni son tan confiables como tendrían que ser.
En este libro se habla de cómo evitar los fracasos. Se examina no solamente cómo se hacen bien las cosas, sino también cómo se hacen mal, para que se puedan reconocer desde el comienzo, y se corrijan los problemas. Tengo la esperanza que después de que se lea este libro, se adquiera un repertorio de técnicas no sólo para evitar los errores comunes en el desarrollo de programas de fuente abierta, sino también para manejar el crecimiento y el mantenimiento de un proyecto exitoso. El éxito no es un juego para que haya un solo ganador, y este libro no busca producir un solo ganador que salga airoso de una competición. Así pues, una parte importante de impulsar un proyecto de fuente abierta es trabajar en armonía con otros proyectos relacionados entre sí. Y a la larga, cada proyecto exitoso contribuye al bienestar de todo el mundo del software libre.
Sería muy tentador afirmar que los proyectos de software libre fracasan por las mismas razones que los proyectos de software propietario. Ciertamente el software libre no tiene el monopolio de los requisitos descabellados, las especificaciones vagas, del manejo pobre de los recursos, fases de diseño insuficientes, y tantas otras complicaciones ya conocidas en la industria del software. Se ha escrito mucho sobre estos temas, por lo que no se duplicarán esos esfuerzos en este libro. Más bien se intentará describir los problemas particulares al software libre. Cuando un proyecto de software libre se estanca, a menudo es porque los programadores (o la dirección) no caen en cuenta de los problemas típicos del desarrollo de software de fuente abierta, aunque pareciera que estan muy bien preparados para las dificultades más conocidas del desarrollo de software de fuente cerrada.
Uno de los errores más comunes es tener expectativas desproporcionadas sobre los beneficios propios de la fuente abierta. Una licencia abierta no es una garantía de tener una legión de programadores activos que de repente se ofrecen para el proyecto, ni tampoco un proyecto con problemas se cura por el sólo hecho de pasarlo a fuente abierta. De hecho es todo lo contrario: abrir un proyecto puede agregar una serie de complicaciones, y resultar a corto plazo más costoso que manejarlo dentro de casa. Abrirlo va a significar acomodar el código para que sea comprensible a gente extraña, crear la documentación de desarrollo y una lista de correos, y a menudo redactar la documentación del proyecto por primera vez. Todo esto significa mucho trabajo. Y además, si aparece algún programador interesado, habrá que soportar el peso agreqado de contestar sus preguntas por un tiempo, antes de ver el beneficio que se recibe por su presencia. Como dijo el programador Jaime Zawinski comentando los días ajetreados cuando se lanzaba el proyecto Mozilla:
La fuente abierta anda, pero no es definitivamente la panacea. Hay que advertir con cautela que no se puede encarar un proyecto moribundo, rociarlo con el polvo mágico de la "fuente abierta" y tener de repente todo en funcionamiento. El software es difícil. Las cosas no son tan simples.
Una equivocación relacionada es escatimar en la presentación y el empaquetado, creyendo que esto se puede hacer después, cuando el proyecto esté encaminado. La presentación y el empaquetado comprenden una amplia serie de tareas, todas en torno a reducir la barrera de ingreso al proyecto. Hacer un proyecto atractivo para un no iniciado significa documentarlo para el usuario y el programador, establecer un sitio web para los recien llegados, automatizar cuanto sea posible la compilación e instalación del software, etc.
Desgraciadamente muchos programadores dan a este trabajo una importancia secundaria comparado con el código. Hay un par de razones para esto. De entrada se puede percibir como trabajo no productivo, porque aparentemente beneficia más a los que no están familiarizados con el proyecto. A su vez, los que desarrollan el código no necesitan realmente del empaquetado. Ya conocen como instalar, administrar y usar el software, porque ellos lo escribieron. En segundo lugar, los conocimientos para hacer bien la presentación y el empaquetado son a menudo completamente diferentes a los que se requieren para escribir el código. La gente tiende a concentrarse en lo que más sabe, aún cuando podría ser más útil al proyecto que se dediquen un poco a lo que no les resulta tan familiar. En el Capítulo 2, Primeros Pasos se trata la presentación y el empaquetado en detalle, y explica por qué es importante que sean una prioridad desde el comienzo del proyecto.
Después se introduce la falacia de que no se requiere una dirección del proyecto cuando es de fuente abierta, o a la inversa, que las mismas prácticas de gestión usadas para un proyecto hecho en casa van a funcionar bien en un proyecto de fuente abierta. El manejo de un proyecto de fuente abierta no siempre resulta visible, pero cuando éste es exitoso tiene lugar detrás de las bambalinas de una u otra forma. Un pequeño experimento mental será suficiente para mostrar por qué. Un proyecto de fuente abierta consiste en una colección de programadores al azar—los que ya de por sí son gente con diferentes mentalidades— que muy probablemente nunca se han visto, y que quizás tienen objetivos personales muy diferentes para trabajar en el proyecto. El experimento consiste en imaginar sencillamente qué va a pasarle a dicho grupo sin dirección. Salvo por un milagro, el proyecto va a colapsar y diluirse muy rápidamente. Las cosas no funcionarán simplemente por sí solas, por más que los deseos sean grandes. Pero la administración, aún cuando sea muy activa, es a menudo informal, sutil, y de bajo perfil. Lo único que mantiene unido al grupo de desarrollo es el convencimiento compartido de que juntos pueden hacer más que individualmente. Entonces el objetivo de la dirección es mayormente asegurar que continúen con ese convencimiento, estableciendo estándares de comunicación, cuidando que los programadores útiles no queden marginados debido a idiosincrasias personales, y en general procurando que el proyecto sea un lugar acogedor para los programadores. Las técnicas específicas para realizar esto se discuten a lo largo de este libro.
Finalmente, hay una categoría general de los problemas que podría llamarse "fallas de orientación cultural". Hace veinte años, o quizás sólo diez, hubiera sido prematuro hablar de una cultura global de software libre, pero ahora ya no es así. Lentamente ha emergido una cultura visible, y aún cuando ésta no es monolítica —por lo menos es tan propensa al disentimiento interno y al corporativismo como cualquier cultura limitada geográficamente— tiene, ciertamente, un núcleo básico consistente. Los proyectos de fuente abierta más exitosos muestran algo o el total de las características de ese núcleo. Se premian ciertos tipos de conductas y se castigan otros. Se crea una atmósfera que incita a la participación espontánea, a veces a expensas de una coordinación central. Se tienen conceptos de lo que es ser amable o ser rudo que difieren substancialmente de lo que prevalece fuera. Lo más importante es que los participantes que son asiduos tienen ya interiorizados esos conceptos y comparten un cierto consenso sobre la conducta que es aceptable. Los proyectos no exitosos a menudo se desvían apreciablemente de ese núcleo, aunque sin intención, y no tienen un consenso sobre lo que razonablemente constituye una conducta predeterminada razonable. Esto quiere decir que cuando surgen los problemas la situación se viene abajo rápidamente, porque los participantes carecen de un conjunto de reflejos culturales determinados que les permita resolver sus diferencias.
Esa última categoría, los fallos de navegación culturales, incluye un interesante fenómeno: ciertos tipos de organizaciones son estructuralmente menos compatibles con el desarrollo de código abierto que otras. Una de las grandes sorpresas para mí en la preparación de la segunda edición de este libro fue darme cuenta de que, en general, mis experiencias indican que los gobiernos se adaptan menos naturalmente a la participación en proyectos de software libre que en el sector privado, corporaciones con fines de lucro, quedando las que son sin fines de lucro en algún lugar entre los dos. Hay muchas razones para ello (ver ???), y los problemas son superables sin duda, pero vale la pena señalar que cuando una organización ya existente — en particular, una jerárquica, y sobre todo una jerárquica, aversa al riesgo, y publicitariamente sensible — inicia o se une a un proyecto de código abierto, por lo general se necesitan algunos ajustes.
Este libro es una guía práctica, no un estudio antropológico o un libro de historia. Sin embargo, un conocimiento efectivo de los orígenes del software libre actual es una base esencial para cualquier consejo práctico. Una persona que entienda esta cultura puede viajar sin límites en este mundo de la fuente abierta, encontrándose con muchas variaciones en costumbres y dialectos, y a la vez estar en la condición de participar cómoda y efectivamente en cualquier lado. Por el contrario, una persona que no entiende esta cultura encontrará que el proceso de organizar y participar en un proyecto es algo difícil y lleno de sorpresas. Puesto que el número de gente que desarrolla software libre sigue creciendo a grandes saltos, habrá muchos en ésta última categoría—ésta es mayormente una cultura de inmigrantes recientes, y continuará así por mucho tiempo. Si crees que eres uno de estos, en el próximo título se presentarán algunos antecedentes útiles para las discusiones que vendrán después, tanto en este libro como en Internet. (Por otro lado, si ya has trabajado en proyectos de fuente abierta por algún tiempo, puede ser que conozcas mucho sobre esta historia, y y sea mejor saltar a la siguiente sección.)
Compartir el software tiene tanta historia como el software mismo. En los primeros tiempos de los ordenadores, los fabricantes se dieron cuenta que vendrían avances competitivos en la innovación del hardware y no prestaron mucha atención al software como una ventaja para el desarrollo de sus negocios. Muchos de los usuarios de las primeras máquinas eran científicos o técnicos que podían modificar y ampliar el software que incluía la máquina. A veces los usuarios distribuían sus aportes no solamente al fabricante, sino también a otros usuarios que tenían máquinas similares. A menudo los fabricantes toleraban esto, e incluso lo estimulaban: para ellos cualquier mejora en el software, fuera cual fuese su procedencia, contribuía a que el hardware resultase más atractivo para otros usuarios potenciales.
Aunque esta primera época se parece de muchas maneras a la cultura actual del software libre, difiere fundamentalmente en dos aspectos: primero que había poca estandarización del hardware— era un momento de mucha innovación en el diseño de los ordenadores, pero la diversidad en las arquitecturas hacía que cualquier cosa resultara incompatible con la otra. El software que se escribía para una máquina generalmente no servía para otra. Los programadores se inclinaban hacia una arquitectura en particular o familia de arquitecturas y en ellas se hacían expertos (mientras que hoy se adquiere experiencia en un lenguaje de programación o una familia de lenguajes y se espera que esa experiencia se pueda luego transferir a cualquier hardware en que se vaya a trabajar). Puesto que un experto se inclinaba a sólo un tipo de ordenador, la acumulación de sus conocimientos tenía el efecto de hacer más atractivo ese ordenador tanto para él como para sus colegas, por lo que los fabricantes tenían gran interés en difundir tanto como pudieran la codificación y el conocimiento de alguna máquina específica.
En segundo lugar, no se había generalizado Internet. Aunque habían menos restricciones legales que hoy para compartir, había más restricciones técnicas: Hablando comparativamente, los medios para transmitir datos de un lado a otro eran difíciles y engorrosos. Había algunas pequeñas redes locales, aptas para compartir información entre empleados del mismo laboratorio de investigación o compañía. Pero quedaba por superar una serie de trabas si se quería compartir con el mundo. Estas trabas se superaban en muchos casos. A veces eran grupos varios que se contactaban independientemente, enviándose discos o cintas por correo, y a veces eran los fabricantes mismos que servían como centrales de intercambio de los aportes individuales. También ayudaba que muchos de los que desarrollaban los primeros ordenadores trabajasen en las universidades, en donde era costumbre publicar los avances. Pero la realidad de la transmisión de datos implicaba que siempre que se los quería compartir se topaba con un impedimento que era proporcional a la distancia (física u organizacional) que el software tenía que viajar. Era imposible compartir algo con todo el mundo sin resistencias, tal como se puede hacer hoy.
A medida que maduraba la industria, ocurrían simultáneamente algunos cambios interrelacionados. La gran diversidad de los diseños del hardware finalmente cedieron el paso a unos pocos ganadores —ganadores por tener una tecnología superior, o una comercialización superior, o una combinación de ambas cosas. Al mismo tiempo, no coincidente en su totalidad, el desarrollo de los así llamados lenguajes de programación de "alto nivel" significaba que se podía escribir un programa de una sóla vez en un lenguaje, y luego traducirlo automáticamente ("compilarlo") para que funcionase en diferentes tipos de ordenadores. Las consecuencias de esto no se quedaron perdidas en los fabricantes de hardware: un usuario podía ahora emprender un mayor esfuerzo de ingeniería de software sin encerrarse en una arquitectura particular. Cuando esto se combinaba con la disminución gradual de las diferencias en la calidad de funcionamiento entre los ordenadores, y mientras los diseños menos eficientes eran eliminados, un fabricante que se centraba en el hardware como único beneficio podía divisar una disminución de sus ganancias en el futuro. La potencia de computación pura se convertía en un bien fungible, mientras que el software se convertía en el diferenciador. Aparecía como una buena estrategia vender software, o al menos, tratarlo como parte integral de las ventas del hardware.
Esto significó que los fabricantes tuvieran que ser más estrictos defendiendo los derechos de copia de los códigos. Si los usuarios hubieran continuado simplemente con su costumbre de compartir y modificar los códigos de manera libre y gratis, hubieran instalado en forma independiente las mejoras que ahora empezaban a ser vendidas como "valor agregado" por los proveedores. Peor aún, el código compartido podría haber caído en las manos de los competidores. La ironía de esto es que ocurría al mismo tiempo que Internet estaba ganando terreno. Justamente, cuando se hacía técnicamente posible compartir el software y se caían los obstáculos, los cambios en el mundo de los negocios hacían del compartir algo económicamente indeseable, por lo menos desde el punto de vista propio de una compañía. Los proveedores imponían sus controles, ya sea negando el acceso al código a los usuarios que corrían el programa en sus máquinas, o mediante acuerdos de no difundir el código, lo que hacía que el compartir fuera imposible.
Mientras se extinguía el mundo del intercambio de códigos se cristalizaba una contra reacción al menos en la mente de un programador. Richard Stallman trabajaba en el laboratorio de inteligencia artificial en el Instituto Tecnológico de Massachussets en la década de 1970 e inicios de 1980, la época y el lugar de oro para la costumbre de compartir los códigos. El laboratorio de IA tenía una fuerte "ética de hacker"[3] y no sólo se estimulaba al personal de los proyectos sino que era de esperar que todos los avances hechos en el sistema fueran compartidos. Como luego escribiría Stallman:
No le llamábamos "software libre" a nuestro software porque ese término no existía; pero era precisamente eso. Toda vez que alguien de otra universidad quería llevar y usar un programa, nosotros se lo ofrecíamos con gusto. Si se veía que alguien usaba un programa distinto e interesante, se le podía pedir el código fuente, para poder leerlo, cambiarlo o fusionar partes de él en un programa nuevo.
Esta comunidad edénica colapsó con Stallman poco después de 1980, cuando los cambios que venían ocurriendo en el resto de la industria finalmente alcanzaron al laboratorio de IA. Una compañía que se iniciaba incorporaba a muchos de los programadores del laboratorio para trabajar en un sistema operativo similar al que habían desarrollado allí, pero ahora bajo una licencia exclusiva. Al mismo tiempo, el laboratorio de IA adquiría nuevos equipos que llegaban con un sistema operativo de marca registrada.
Stallman vio la gran trama de lo que estaba sucediendo:
Los ordenadores modernos de la época, como el VAX o el 68020, venían con sus sistemas operativos propios, pero ninguno era un software libre: se debía firmar un acuerdo de no revelar los contenidos para poder recibir una copia ejecutable.
Lo cual significaba que el primer paso para usar un ordenador era prometer que no había que ayudar al prójimo. La comunidad de cooperación estaba prohibida. La regla que establecían los dueños del software propietario era: "si compartes con tu vecino, eres un pirata. Si quieres cambios, nosotros los haremos, si nos lo pides."
Y por su personalidad peculiar decidió ofrecer resistencia a esta nueva ola. En lugar de continuar trabajando en el diezmado laboratorio de IA, o aceptar el trabajo de escribir código en alguna de las compañías nuevas, en las que su trabajo iba a quedar bajo llave, renunció al laboratorio y comenzó el proyecto GNU y la Fundación de Software Libre (FSF por sus siglas en Inglés). El objetivo del GNU[4] era desarrollar un sistema operativo y un conjunto de aplicaciones completamente libres y abiertas, donde nunca se impediría a la gente hackear o compartir sus cambios. En esencia, estaba empeñado en recrear lo que se había destruido del laboratorio de IA, pero a una escala global, y sin las vulnerabilidades que ponían a la cultura del laboratorio de IA en un estado de posible desintegración.
Además de trabajar en el nuevo sistema operativo, Stallman inventó una licencia de copyright cuyos términos garantizaban que los códigos permanecerían gratis en perpetuidad. La Licencia Pública General GNU es una ingeniosa pieza de judo legal: dice que los códigos pueden ser copiados y modificados sin ninguna restricción y que ambas copias y trabajos derivados (a saber, las versiones modificadas) deben ser distribuidas bajo la misma licencia que el original, sin poner restricciones adicionales. En efecto, se usan las leyes del copyright para conseguir un efecto contrario al que apunta el copyright tradicional: en lugar de limitar la distribución del software, prohíbe que nadie, ni siquiera el autor, limite su distribución. Para Stallman, esto era mejor que si hubiera puesto su código en el dominio público. Si hubiera estado en el dominio público, cualquier copia podría haber sido incorporada a los programas propietarios (como en ocasiones se sabía que había sucedido con códigos que tenían licencias permisivas [5]). Aunque una incorporación como ésta no hubiera disminuido la disponibilidad de los códigos originales, hubiera significado que los esfuerzos de Stallman iban a beneficiar al enemigo—al software propietario. La Licencia Pública General puede entenderse como una forma de proteccionismo del software libre, porque impide que el software no-libre se aproveche de los códigos que están bajo esta licencia. La Licencia Pública General y su relación con otras licencias del software libre se discuten en detalle en el Capítulo 9, Licencias, Copyrights y Patentes.
Con la ayuda de nuevos programadores, algunos de los cuales compartían la ideología de Stallman y otros que simplemente querían ver abundante código disponible en forma gratuita, el Proyecto GNU comenzó entregando versiones libres para reemplazar muchos de los componentes críticos de sistemas operativos. Gracias a la estandarización expandida del hardware y software para ordenadores, se hizo posible usar los reemplazos GNU en sistemas no-libres, y mucha gente lo hizo. El editor de texto de GNU (Emacs) y el compilador C (GCC) tuvieron especial éxito, ganando muchos seguidores leales, no por términos ideológicos, sino simplemente por los méritos técnicos. Alrededor del año 1990, GNU había producido la mayor parte de un sistema operativo libre, con excepción del núcleo—la parte por la que realmente la máquina arranca y se hace responsable de manejar la memoria, el disco y otros recursos del sistema.
Desafortunadamente el proyecto GNU había elegido un diseño de núcleo que resultó más difícil de implementar de lo esperado. La consiguiente demora impedía que la Fundación de Software Libre ofreciera la primera versión de un sistema operativo enteramente libre. La pieza final fue instalada en su lugar por Linus Torvalds, un estudiante de computación finlandés quien con la ayuda de voluntarios de todo el mundo había completado un núcleo libre usando un diseño más conservador. Le llamó Linux, y cuando fue combinado con los programas GNU existentes y otros softwares libres (Especialmente el Sistemas de Ventanas X) tuvo como resultado un sistema operativo completamente libre. Por primera vez se podía arrancar un ordenador y hacerlo trabajar sin usar ningún software propietario.[6]
Muchas partes del software de este nuevo sistema operativo no fueron producidas por el proyecto GNU. De hecho, el GNU no fue el único grupo que trabajaba para producir un sistema operativo libre (por ejemplo, el código que luego fue NetBSD y FreeBSD estaba ya en desarrollo en ese momento). La importancia de la Fundación de Software libre no solamente residía en los códigos que se escribían, sino en el tratamiento político del tema. Al hablar del software libre como una causa en lugar de una conveniencia, era casi imposible que los programadores no tomasen una postura política de ello. Aún los que no estaban de acuerdo con la Fundación de Software Libre tuvieron que enfrentar la causa, aunque más no sea para proponer una posición diferente. La efectividad que tuvo la Fundación de Software Libre en el proceso de difusión residió en la vinculación del código al mensaje, por medio de la Licencia Pública General y de otros textos. Al mismo tiempo que se difundían los códigos, se distribuía también el mensaje.
Había muchas otras cosas sucediendo en la escena naciente del software libre, sin embargo, y pocas eran tan explícitas ideológicamente como el Proyecto GNU de Stallman. Uno de los sucesos mas importantes fue la Berkeley Software Distribution (BSD), una reimplementación gradual del sistema operativo Unix, que hasta finales de la década de los 70' había sido un proyecto de investigación relativamente propietario de AT&T—hecho por programadores de la Universidad de California en Berkeley. El grupo BSD no hizo una declaración política sobre la necesidad de que los programadores se unieran y compartieran unos con otros, pero practicaron la idea con talento y entusiasmo, coordinando un esfuerzo masivo de desarrollo distribuido en el cual la línea de comandos y las librerías, y eventualmente el núcleo del sistema operativo Unix, fueron reescritos desde cero, en su mayoría por voluntarios. El proyecto BSD resultó un primer ejemplo de desarrollo de un software libre no-ideológico, y también sirvió como campo de entrenamiento para muchos desarrolladores que continuarían activos en el mundo del software libre.
Otro proyecto de desarrollo cooperativo fue el X Window System, un entorno gráfico de computación libre y transparente en la red, desarrollado en el MIT a mediados de la década de 1980 en coparticipación con empresas que tenían el interés común de estar en condiciones de ofrecer a sus clientes un sistema operativo con ventanas. Lejos de oponerse al software propietario, la licencia X permitía deliberadamente que se hicieran extensiones propietarias encima del nucleo libre—cada miembro del consorcio quería tener la oportunidad de mejorar la distribucion X predeterminada y consiguientemente ganar una ventaja competitiva con respecto a los otros miembros. El X Windows[7] era un software libre, pero fundamentalmente como una manera de nivelar el campo de juego entre intereses de las empresas competidoras e incrementar la estandarización, y no por el deseo de poner fin a la dominación del software propietario. Todavía hay otro ejemplo, el TeX de Donald Knuth, un sistema de tipografía que surgió unos años antes que GNU. Ofreció una versión bajo terminos que permitían que cualquiera modifique y distribuya el código, pero que no se llamara "TeX" a no ser que superara una serie de pruebas de compatibilidad muy estrictos (este es un ejemplo de una clase de licencia libre "protectoras de marcas registradas" de las que se hablará más en el Capítulo 9, Licencias, Copyrights y Patentes). Knuth no estaba tomando partido para un lado ni para el otro en la cuestión del software libre contra el propietario, solo necesitaba un sistema mejor de impresión para cumplir con su objetivo real—un libro sobre programación de ordenadores—y no encontró escollos para presentar al mundo su sistema una vez que estuvo hecho.
Aún sin tener un listado completo de proyectos y licencias, se puede afirmar con seguridad que para el fin de la década de los 80' había una buena cantidad de software libre y una amplia variedad de licencias. La diversidad de licencias reflejaba una diversidad de motivaciones correspondientes. Incluso algunos de los programadores que eligieron la Licencia Pública General de GNU estaban mucho menos motivados ideológicamente que el proyecto GNU mismo. Aunque disfrutaban trabajando en el software libre, muchos desarrolladores no consideraron al software propietario una lacra social. Había quienes sentían un impulso moral de liberar al mundo del "acaparamiento de software" (un término que usaba Stallman para el software no libre), pero otros estaban más motivados por un entusiasmo técnico, o por el placer de trabajar con colaboradores de pensamiento afín, o simplemente por el deseo humano de la gloria. Pero las motivaciones disparatadas no intervinieron en forma destructiva en todo este confín. Esto pudo ser porque, en oposición a lo que acontece en otras formas creativas como la prosa o las artes visuales, el software debe superar pruebas semi-objetivas para ser considerado un éxito: debe funcionar y estar razonablemente libre de errores. Esto otorga a todos los participantes del proyecto una especie de pie de igualdad común, una razón y un encuadre para trabajar juntos sin preocuparse mucho de otros títulos o motivaciones que no sean los conocimientos técnicos.
Además, los desarrolladores tenían otra razón para permanecer juntos: acontecía que el mundo del software libre estaba produciendo códigos de muy alta calidad. En algunos casos se podía demostrar que eran técnicamente superiores a las alternativas del software no libre que se les acercaban; en otros casos eran al menos comparables y por supuesto, costaban menos. Mientras que solo unos pocos pudieron estar motivados para usar software libre por razones estrictamente filosóficas, la gran mayoría se sentía feliz de usarlos porque cumplían mejor con las tareas. Y entre los usuarios, algún porcentaje estaba siempre listo para donar su tiempo y habilidad para ayudar a mantener y mejorar el software.
Esta tendencia de producir buenos códigos no era ciertamente universal, pero se repetía por todas partes con frecuencia en aumento en los proyectos de software libre. Las empresas que dependían fuertemente del software lo empezaron a notar gradualmente. Muchos de ellos descubrieron que ya estaban usando software libre en las operaciones de todos los días, sólo que no lo sabían (los gerentes de alto rango no siempre saben todo lo que ocurre en las dependencias de la tecnología informática). Las corporaciones comenzaron a tomar cartas activas en los proyectos del software libre, contribuyendo con tiempo y equipos, y a veces subvencionando directamente al desarrollo de programas libres. Estas inversiones podían, en el mejor de los casos, retornar multiplicadas muchas veces. Las subvenciones solo pagaban a una cantidad pequeña de programadores expertos para que dedicaran su trabajo de tiempo completo, pero cosechaban los beneficios de las contribuciones de todos, incluso de voluntarios no pagos, y programadores pagados por otras corporaciones.
Cuando las corporaciones prestaron mayor atención a los programadores de software libre se enfrentaron con nuevas formas de presentación. Una de ellas fue la palabra "libre", cuya traducción al inglés también significa "gratis". Al escuchar por primera vez el término "software libre" muchos pensaron erróneamente que solamente significaba "software de costo cero". Es verdad que todo software libre es gratis[8], pero no todo el software gratis es libre. Por ejemplo, durante la guerra de los navegadores de la década de los '90 Netscape y Microsoft repartían gratis sus navegadores en la disputa por ganar la mayor participación en el mercado. Ninguno de estos navegadores era libre en el sentido que tiene el "software libre". No se dispone del código fuente, y si se lo tuviera, no se tiene el derecho de modificarlo o redistribuirlo.[9] Lo único permitido era bajar los programas ejecutables y hacerlos funcionar. Los navegadores no eran más libres que los softwares empaquetados y comprimidos que se compran en un negocio; sólo que el precio era mas bajo.
Esta confusión en la palabra "libre" se debe a una desafortunada ambigüedad de lenguaje, en este caso del inglés. En otras lenguas romances aparece la diferencia entre precio bajo y libertad porque existen las palabras gratis y libre que se distinguen con facilidad. Pero siendo el inglés el lenguaje puente dentro de Internet, pasó esto a significar que un problema con el inglés era también un problema para los demás. Este malentendido suscitado por la palabra "libre" era tan penetrante para los angloparlantes que los programadores de software desarrollaron una formula estándar que repetían: "Es libre (free) como la libertad, no como la cerveza gratis (free)" Aún así, tener que explicar esto una y otra vez resulta fatigante. Muchos programadores sentían, no sin razón, que la palabra ambigua (en inglés) "libre" (free) estaba obstaculizando la comprensión del público en relación a este software.
Pero este problema se profundizó más aún. La palabra "libre" llevaba consigo una inevitable connotación moral: si la libertad era un fin en sí mismo, no importaba si el software libre resultaba ser mejor o más rentable para ciertos negocios en ciertas circunstancias. Estos últimos efectos aparecían como secundarios, por otras motivaciones que no eran, en el fondo, ni técnicas ni comerciales, sino morales. Más todavía, la postura de "libre como la libertad" llevaba a una flagrante incoherencia de las corporaciones que subvencionaban algunos programas libres para algunas áreas de sus negocios, pero continuaban comercializando software propietario en otras.
Estos dilemas llovían sobre una comunidad que ya estaba aplastada por una crisis de identidad. Los programadores que en verdad escriben el software libre no se sienten necesariamente identificados con el objetivo central -si lo hay- del movimiento del software libre. Sería engañoso decir que las opiniones van de un extremo al otro, porque esto implicaría la falsedad de imaginar que nos movemos en una línea de pensamiento, cuando en realidad es una distribución multidimensional. Sin embargo, si estamos dispuestos a obviar las sutilezas, por el momento pueden diferenciarse dos amplias categorías. Un grupo se alinea bajo el punto de vista de Stallman, para quien la libertad de compartir y modificar es lo más importante, y por lo tanto si no se habla de libertad se está esquivando el núcleo principal de la cuestión. Otros piensan que el software es el argumento más importante a su favor, y se sienten incómodos con la proclamación del software propietario como algo inherentemente malo. Algunos de los programadores de software, aunque no todos, creen que el autor (o el empleador, en el caso de trabajo pagado) debería tener el derecho de controlar las cláusulas de la distribución y que no se necesita agregar un juicio moral en la selección de algunas cláusulas particulares. Otros no creen eso.
Por mucho tiempo no se necesitó examinar o articular estas diferencias, pero el éxito floreciente del software libre hizo que esta cuestión fuera inevitable. En 1998 un grupo de programadores creó el término fuente abierta como una alternativa para "libre" y fueron ellos quienes crearon la Iniciativa por el Código Abierto(OSI por sus siglas en Inglés). [10] La Iniciativa por el Código Abierto creía que el término "software libre" llevaba a una confusión potencial, y que la palabra "libre" era tan solo un síntoma del problema general: que el movimiento necesitaba una estrategia de mercadeo para lanzarlo al mundo de las grandes empresas, y que hablar de moral y de los beneficios sociales del compartir no iba a tener vuelo en las juntas directivas de las empresas. Tomando sus propias palabras para aquel momento:
La Iniciativa por el Código Abierto es un programa de mercadeo para el software libre. Significa fundar el "software libre" sobre bases sólidas y prácticas más que en una discusión acalorada. La sustancia ganadora no ha cambiado, sí en cambio la actitud de perdedores y su simbolismo. ...
La aclaración que debe hacerse a muchos técnicos no es acerca del concepto de fuente abierta, sino sobre el nombre. ¿Por qué no llamarle, como se ha hecho tradicionalmente, software libre?
Una razón definitiva es que el término "software libre" se confunde fácilmente de manera que lleva a terrenos conflictivos. ...
Pero la verdadera razón del cambio de cartel es una razón de comercialización. Estamos ahora tratando de lanzar nuestro concepto al mundo corporativo. Tenemos un producto ganador, pero nuestra posición, en el pasado, ha sido terrible. El término "software libre" se ha malentendido entre las personas de negocios, quienes confunden el deseo de compartir con una conducta anticomercial, o peor todavía, con un robo.
Los CEOs y CTOs de grandes corporaciones ya establecidas nunca comprarán "software libre." Pero si mantenemos la misma tradición, la misma gente y las mismas licencias de software libre y les cambiamos el nombre poniéndole "código abierto", — entonces sí lo comprarán.
Algunos hackers encuentran esto difícil de creer, porque son técnicos que piensan en términos concretos y substanciales, y no entienden la importancia de la imagen de algo cuando uno lo está vendiendo.
Para el mercadeo la apariencia es la realidad. La apariencia de que estamos dispuestos a bajarnos de nuestras barricadas y a trabajar con el mundo corporativo importa tanto como la realidad de nuestras conductas o convicciones, y de nuestro software.
(de opensource.org. O más bien, antiguamente de ese sitio — la OSI ha retirado esas páginas desde entonces, a pesar de que todavía se pueden ver en web.archive.org/web/20021204155057/http://www.opensource.org/advocacy/faq.php y web.archive.org/web/20021204155022/http://www.opensource.org/advocacy/case_for_hackers.php#marketing [sic].)
En ese texto aparecen las puntas de muchos icebergs de controversia. Se refiere a "nuestras convicciones", pero discretamente evita decir con exactitud de qué convicciones se trata. Para algunos, puede ser la convicción de que el código desarrollado en concordancia con un proceso abierto será un código mejor; para otros pudiera ser la convicción de que toda información debiera ser compartida. Aparece el uso del término "robo" para referirse (posiblemente) al copiado ilegal—una costumbre que muchos objetan alegando que pese a todo no es un robo si el propietario original todavía tiene el artículo. Hay una sospecha inquietante de que el movimiento de software libre podría ser acusado por equivocación de anticomercialismo, aunque queda por examinar detenidamente la cuestión de si esta acusación tendría alguna base real.
Esto no quiere decir que el sitio web de la OSI sea incoherente o engañoso. No lo es. En realidad es un ejemplo de lo que la OSI sostiene que le faltaba al movimiento del software libre: una buena comercialización, donde "buena" significa viable en el mundo de los negocios. La Iniciativa de Fuente Abierta brindó a mucha gente exactamente lo que buscaban—un vocabulario para referirse al software libre como una metodología de desarrollo y una estrategia para los negocios, en lugar de una cruzada moral.
La aparición de la Iniciativa por el Código Libre cambió el panorama del software libre. Formalizó una dicotomía que por mucho tiempo no tuvo un nombre, y al hacerlo forzaba al movimiento a reconocer que tenía una política interna al mismo tiempo que una externa. Hoy, el efecto es que ambos lados han tenido que encontrar un terreno común, puesto que la mayoría de los proyectos incluye a programadores de ambos campos, como también otros participantes que no encajan claramente en una categoría. Esto no impide que se hable de motivaciones morales—por ejemplo, a veces aparecen convocatorias con recaídas en la tradicional "ética de hackers". Pero es raro que un desarrollador de software libre / fuente abierta entre a cuestionar abiertamente las motivaciones básicas de otros. La contribución encubre al contribuyente. Si alguien escribe un buen código, no se le pregunta si lo hace por razones morales o porque su empleador le paga, o porque está engrosando su currículum, o lo que sea. Se evalúa la contribución en términos técnicos, y se responde con fundamentos técnicos. Inclusive organizaciones explícitamente políticas como el proyecto Debian, cuyo objetivo es ofrecer un entorno computacional 100% libre ("libre como la libertad"), no tienen peros para integrarse con el código no libre y cooperar con programadores que no comparten exactamente los mismos objetivos.
[2] Traté de calcular el número, mirando sólo el número de proyectos registrados en los sitios de alojamiento más populares, y lo más cerca que pude calcular como respuesta está en entre una centena de mil y doscientos mil. Eso todavía sería mucho menor que el número total de proyectos de software libre en Internet, por supuesto, ya que sólo cuenta los que optaron por utilizar uno de los principales sitios de alojamiento.
[3] Stallman usa la palabra "hacker" tiene el significado de "alguien que ama la programación y disfruta si hace algo inteligente" y no con el sentido más reciente de "alguien que se conecta como un intruso en los ordenadores"
[4] Siglas que significan "GNU No es Unix" donde "GNU" en esa expansión resulta un infinitamente largo pie de página.
[5] Ver “Terminología” para más información sobre licencias "permisivs" versus licencias "copyleft" al estilo GPL. Las FAQ de opensource.org son también un buen recurso sobre esto—veropensource.org/faq#copyleft.
[6] Un sistema operativo libre para ordenadores compatibles con IBM, llamado 386BSD, había aparecido poco antes que Linux. Sin embargo, era mucho mas difícil conseguir un 386BSD y hacerlo funcionar. Linux tuvo tanta resonancia no solo porque era libre, sino porque realmente tenía una probabilidad alta de hacer arrancar exitosamente al ordenador una vez que se instalaba.
[7] Preferían que se llamara "X Windows System", pero en la práctica se le llama comunmente "X Windows", porque tres palabras es demasiado complicado.
[8] Se podría cobrar algo por repartir las copias del software libre, pero puesto que no se les puede impedir a quienes lo reciben ofrecerlo gratis después, el precio vuelve a cero inmediatamente.
[9] El código fuente del Navegador de Netscape apareció eventualmente bajo una licencia de fuente abierta, en 1998, y vino a ser la base del navegador Mozilla. Ver mozilla.org.
[10] El sitio web de la OSI es opensource.org.