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.