"Free4all" 1. Agradecimientos Este es solo un libro sobre el movimiento del software libre. No sería posible sin el arduo trabajo y la dedicación de miles, si no millones, de personas a las que les gusta pasar su tiempo libre pirateando código. Te saludo. Gracias. Muchas personas me hablaron durante el proceso de elaboración de este libro, y sería imposible citarlas a todas. La lista debe comenzar con los millones de personas que escriben y contribuyen a las diversas listas de software libre. Las cartas, notas y publicaciones en estas listas son una maravillosa historia de la evolución del software libre y un recurso invaluable. La lista también debería incluir las docenas de periodistas en lugares como Slashdot.org, LinuxWorld, la revista Linux, Linux Weekly News, Kernel Traffic, Salon y el New York Times. Debo mencionar específicamente el trabajo de Joe Barr, Jeff Bates, Janelle Brown, Zack Brown, Jonathan Corbet, Elizabeth Coolbaugh, Amy Harmon, Andrew Leonard, Rob Malda, John Markoff, Mark Nielsen, Nicholas Petreley, Harald Radke y Dave Whitinger. Escribieron piezas maravillosas que serán un excelente primer borrador de la historia del movimiento de código abierto. Solo algunas de las piezas se citan directamente en las notas al pie, en gran parte por razones prácticas. Todo el cuerpo de sitios web como Slashdot, Linux Journal, Linux World, Kernel Notes o Linux Weekly News debería ser una lectura obligatoria para cualquier persona interesada en el movimiento del software libre. Hay cientos de personas en las ferias comerciales de Linux que se tomaron el tiempo para mostrarme sus productos, camisetas o, en un caso, hieleras llenas de cerveza. Casi todos los que conocí en las conferencias estaban felices de hablar sobre sus experiencias con el software de código abierto. Todos fueron una gran fuente de información, y ni siquiera sé la mayoría de sus nombres. Algunas personas fueron más allá del llamado del deber. John Gilmore, Ethan Rasiel y Caroline McKeldin leyeron borradores cuando el libro estaba sin terminar. Sus comentarios fueron cruciales. Muchos amigos, conocidos y sujetos del libro tuvieron la amabilidad de leer versiones un poco más pulidas, pero lejos de estar completas: L. David Baron, Jeff Bates, Brian Behlendorf, Alan Cox, Robert Dreyer, Theo de Raadt, Telsa Gwynne, Jordan Hubbard, James Lewis Moss, Kirk McKusick, Sam Ockman, Tim O'Reilly, Sameer Parekh, Bruce Perens, Eric Raymond y Richard Stallman. Hay algunas personas que merecen un tipo diferente de agradecimiento. Daniel Greenberg y James Levine hicieron un gran trabajo dando forma a la concepción del libro. Cuando comencé, eran solo algunas ideas en papel. Mis editores, David Conti, Laureen Rowland, Devi Pillai y Adrian Zackheim, fueron en gran parte responsables de esta transición. Kimberly Monroe sufrió mis errores mientras llevaba el libro a través de sus etapas de producción. Tomaron un montón de comentarios incoherentes sobre un fenómeno social y ayudaron a convertirlo en un libro. Finalmente, quiero agradecer a todos en mi familia por todo lo que me han dado a lo largo de mi vida. Y, por supuesto, Caroline, quien editó grandes porciones con una devoción servil por la gramática y el estilo. Visite http://www.wayner.org/books/ffa/ para actualizaciones, correcciones y comentarios adicionales. --------------------- Free4All. Copyright 2000 por Peter Wayner. Algunos derechos reservados: Esta es una versión completa de] la versión electrónica gratuita del libro publicado originalmente por HarperCollins. El libro todavía está protegido por derechos de autor y está sujeto a una licencia que le otorga los derechos limitados para hacer copias completas con fines no comerciales. Le invitamos a leerlo en formato electrónico sujeto a estas condiciones: 1) No puede realizar obras derivadas. Debe reproducir la obra en su totalidad. 2) No puede vender versiones. 3) Usted remite a todos los que reciben una copia al sitio web donde pueden obtener la última versión corregida. http://www.wayner.org/books/ffa/ Próximamente se publicará una licencia completa desarrollada por Creative Commons (www.creativecommons.org). Escriba a p3@wayner.org si tiene alguna pregunta o sugerencia. Visite http://www.wayner.org/books/ffa/ para la PRIMERA EDICIÓN PDF Diseño de página para esta y la edición original en papel diseñada por William Ruoto, consulte No impreso en papel sin ácido. Datos de catalogación en publicación de la Biblioteca del Congreso Wayner, Peter, 1964 Free4All: cómo Linux y el movimiento del software libre socavaron a los titanes de la alta tecnología / Peter Wayner. pag. cm. ISBN 0-06-662050-3 1. Linux. 2. Sistemas operativos (Computadoras) 3. Programas informáticos libres. I. Título. QA76.76.063 W394 2000 005.4'469 dc21 00-023919 00 01 02 03 04 V/RRD 10 9 8 7 6 5 4 3 2 1 ------------------------------------- 3. Batalla Un mundo donde el dinero era el rey, la codicia era el bien y el dinero el poder se salió de su eje y dejó de girar, aunque fuera por un segundo, en enero de 1999. Microsoft, el gran gigante del software e imparable motor del dinero en efectivo, se defendía en una sala de audiencias en Washington, D.C. El Departamento de Justicia afirmó que Microsoft era un monopolio y estaba usando este poder para eliminar a los competidores. Microsoft lo negó todo y afirmó que el mundo estaba lanzando amenaza tras amenaza competitiva en su camino. No eran un monopolio, eran simplemente una empresa muy competitiva que logró resistir las hondas y flechas de otros competidores igualmente despiadados para robar su cuota de mercado. El juicio se convirtió rápidamente en la peor pesadilla de todos, ya que los abogados, los economistas y los programadores llenaron la sala del tribunal con una mezcla espesa de tecnopalabrería y lenguaje legal. En las gradas, los nerds informáticos pronunciaron acrónimos de tres letras (TLA) mientras hablaban sobre la creación de sistemas operativos. Luego, los nerds legales comenzaron a dividirlos en acrónimos de una letra y probaron para ver cuál de las tres letras era realmente la que cometió el crimen. Entonces los economistas se adelantaron y ofrecieron sus teorías sobre cuándo un monopolio es un monopolio. ¿Eran suficientes tres letras en colusión? ¿Qué hay de dos? Todos en la sala del tribunal comenzaron a temer pasar el día encerrados en una habitación pequeña mientras Microsoft intentaba negar lo que era obvio para prácticamente todos. En el otoño y principios del invierno de 1998 y 1999, el Departamento de Justicia presentó a sus testigos, quienes explicaron cómo Microsoft había torcido los contratos, modificado el software y torcido los brazos para asegurarse de que él y solo él obtuviera la mayor parte del negocio de las computadoras. Muchos de los que vieron el juicio pronto desarrollaron la opinión de que Microsoft había adoptado una mezcla de tácticas del matón del patio de la escuela, el jefe de la mafia local y la madre del infierno. El Departamento de Justicia sacó a relucir una serie de testigos que produjeron amplia evidencia que sugería que los clientes de computadoras del mundo comprarán productos de Microsoft a menos que Microsoft decida lo contrario. Los competidores deben ser sancionados. En enero, los periodistas que cubrían el juicio se quejaban en voz baja de esta interminable pérdida de tiempo. El caso del Departamento de Justicia fue tan convincente que vieron todo el juicio como un simple retraso en lo que eventualmente se convertiría en un fallo que de alguna manera dividiría o encadenaría a Microsoft. Pero Microsoft no iba a dejarse intimidar ni presionar para dividirse. El juicio les permitió presentar su versión de la historia y tenían una lista. Claro, todos parecían usar productos de Microsoft, pero eso era porque eran geniales. No fue porque no hubiera competidores, sino porque los competidores simplemente no eran lo suficientemente buenos. A mediados de enero, Richard Schmalensee, decano de la Sloan School of Management del Instituto Tecnológico de Massachusetts, subió al estrado para defender a Microsoft. Schmalensee había trabajado para la Comisión Federal de Comercio y el Departamento de Justicia como economista que examinaba el mercado y los efectos del comportamiento anticompetitivo. Estudió cómo se comportan los monopolios y, para él, Microsoft no tenía poder de monopolio. Ahora, Microsoft le estaba pagando generosamente como testigo experto para repetir esta opinión en la corte. El argumento de Schmalensee era simple: los competidores están apareciendo por todas partes. Microsoft, dijo en su testimonio directo, "está en una lucha constante por la supervivencia competitiva. Esa lucha, la carrera por ganar y el miedo perpetuo del vencedor a ser desplazado, es la fuente de vitalidad competitiva en la industria del software de microcomputadoras". Schmalensee incluso tenía algunos competidores listos. "El iMac claramente compite directa y ferozmente con las computadoras compatibles con Intel que ejecutan Windows", dijo sin mencionar que Microsoft había rescatado a Apple varios meses antes con una inversión de cientos de millones de dólares. Cuando Steve Jobs, el iCEO de Apple, anunció el trato a una multitud de amantes de Mac, la multitud abucheó. Jobs los hizo callar y trató de argumentar que los días de dura competencia con Microsoft habían terminado. La escena capturó tan bien el dominio total de Microsoft que la película para televisión The Pirates of Silicon Valley la usó para ilustrar cómo Bill Gates había ganado todas las canicas. Después del anuncio de la inversión, Apple comenzó a comercializar el navegador web Internet Explorer de Microsoft como navegador preferido en sus máquinas. El competidor de Microsoft, Netscape, se volvió un poco más difícil de encontrar en el iMac. Después de ese trato, Steve Jobs incluso comenzó a hacer declaraciones de que los viejos enemigos jurados, Apple y Microsoft, ahora eran más socios que competidores. Schmalensee no se centró en esta faceta de la nueva actitud de Apple hacia la competencia. A continuación, Schmalensee sacó a relucir BeOS, un sistema operativo creado por Be, una pequeña empresa con unos 100 empleados dirigida por el exejecutivo de Apple Jean-Louis Gass e. Esta empresa había atraído millones de dólares en fondos, dijo, y a algunas personas realmente les gustó. Eso lo convirtió en un competidor. Schmalensee no mencionó que Be tuvo problemas para regalar el sistema operativo BeOS. Gass e se acercó a varios fabricantes de PC para ver si incluirían BeOS en sus máquinas y darían a los usuarios la oportunidad de cambiar entre dos sistemas operativos. Gass e descubrió, para sorpresa de nadie, que los contratos de Microsoft con los fabricantes hacían difícil, si no prácticamente imposible, poner BeOS en manos de los clientes. Microsoft controlaba gran parte de lo que el usuario podía ver e insistía en tener un control casi total sobre la experiencia del espectador. Schmalensee no mencionó estos detalles en su testimonio. BeOS pudo haber estado tan encerrado como un prisionero en una celda sin ventanas en un manicomio con paredes de piedra en una isla en medio del océano, pero BeOS seguía siendo un competidor por el amor de la bella doncella. Sin embargo, el último competidor fue el que más sorprendió a todos. Schmalensee vio a Linux, un programa gratuito, como un gran competidor potencial. Cuando dijo Linux, en realidad se refería a una colección completa de programas conocidos como software de "código abierto". Estos fueron escritos por un grupo de programadores que compartieron todo el código fuente del software a través de Internet. El software de código abierto flotaba en Internet controlado por una variedad de licencias con nombres como GNU General Public License (GPL). Decir que el software estaba "controlado" por la licencia es un poco exagerado. En todo caso, las licencias fueron redactadas deliberadamente para prohibir el control. La GNU GPL, por ejemplo, permite a los usuarios modificar el programa y regalar sus propias versiones. La licencia hizo más para obligar a compartir todo el código fuente que para controlar o restringir. Era más una anti-licencia que cualquier otra cosa, y su autor, Richard Stallman, a menudo la llamaba "copyleft". Schmalensee no mencionó que la mayoría de la gente pensaba que Linux era una herramienta extraña creada y utilizada por hackers en cuartos oscuros iluminados por monitores de computadora. No mencionó que muchas personas tenían problemas para que Linux funcionara con sus computadoras. Se olvidó de mencionar que los manuales de Linux venían con subtítulos como "Disk Druid-like 'fstab editor' disponible". No profundizó en el hecho de que para muchos de los desarrolladores, Linux era solo un pasatiempo con el que incursionaban cuando no había nada interesante en la televisión. Y ciertamente no mencionó que la mayoría de la gente pensaba que todo el proyecto Linux era el trabajo de un genio loco y sus discípulos raros que aún no se habían dado cuenta del hecho de que la Unión Soviética ya había fracasado a lo grande. La gente de Linux realmente pensó que compartir haría del mundo un lugar mejor. Los programadores gordos que gastaron sus riquezas en opciones sobre acciones en Porsches y vinagr e balsámico se reían en momentos como este. Schmalensee no mencionó estos hechos. Simplemente ofreció Linux como una alternativa a Windows y dijo que los fabricantes de computadoras podrían cambiarlo en cualquier momento. Maricón. Por lo tanto, Microsoft tenía competidores. En el juicio, el discurso rápidamente se convirtió en una discusión sobre qué es realmente un competidor digno y qué no lo es. ¿Había suficientes aplicaciones disponibles para Linux o Mac? ¿Qué califica como "suficiente"? ¿Eran estos realmente dignos? Durante el contrainterrogatorio, Schmalensee explicó que no estaba presentando a Mac, BeOS o Linux como competidores que iban a apoderarse del 50 por ciento del mercado. Simplemente argumentó que su existencia demostraba que las barreras producidas por el llamado monopolio de Microsoft no eran tan fuertes. Si personas racionales estaban invirtiendo en la creación de empresas como BeOS, entonces el poder de Microsoft no era absoluto. Después, la mayoría de la gente se decidió rápidamente. Todo el mundo había oído hablar de Macintosh y sabía que en ese entonces la sabiduría convencional dictaba que pronto fallaría. Pero la mayoría de la gente no sabía nada sobre BeOS o Linux. ¿Cómo podía una empresa ser competidora si nadie había oído hablar de ella? Apple y Microsoft tenían comerciales de televisión. BeOS, al menos, tenía un presidente carismático. No hubo presentador de Linux, ni jingle de Linux, ni anuncio de 30 segundos de Linux en los principales medios de comunicación. En ese momento, solo los proyectos mejor financiados en la comunidad de Linux tenían suficiente dinero para comprar espacios en la televisión por cable de acceso comunitario nocturno. ¿Cómo podría alguien sin dinero competir con una empresa que contrató a los Rolling Stones para generar entusiasmo en el lanzamiento de un producto? Cuando la gente escuchó que Microsoft estaba ofreciendo un producto gratis como un competidor digno, comenzaron a reírse aún más fuerte por la desfachatez de la compañía. ¿No era el dinero la única razón por la que el país tenía un juicio? ¿No había tanta demanda de programadores informáticos que muchas empresas no podían contratar tantos como necesitaban, sin importar cuán alto fuera el salario? ¿Cómo podía Microsoft creer que alguien compraría la suposición de que un grupo de nerds pseudocomunistas que vivían en su extraña tecno-utopía donde todo el software era gratuito alguna vez crearían un software que podría competir con la compañía más rica del mundo? A primera vista, parecía que el caso de Microsoft se estaba hundiendo tanto que tuvo que recurrir a estrategias ridículas. Era como si General Motors le dijera al mundo: "No deberíamos tener que preocuparnos por arreglar autos que contaminan porque un colectivo de hippies en Ithaca, Nueva York, está renovando bicicletas viejas y regalándolas". Fue como si Exxon descartara los problemas del hundimiento de los petroleros al explicar que los cantantes populares habían escrito una balada realmente genial para enseñar a los pájaros y las nutrias a lamerse para limpiarse después de un derrame de petróleo. Si nadie cobró dinero por Linux, probablemente fue porque no valía la pena comprarlo. Pero a medida que todos comenzaron a mirar un poco más profundo, comenzaron a ver que Linux se estaba tomando en serio en algunas partes del mundo. Resultó que muchos servidores web ya se ejecutaban en Linux u otro primo libre conocido como FreeBSD. Una herramienta de servidor web gratuita conocida como Apache había controlado más del 50 por ciento de los servidores web durante algún tiempo y estaba superando gradualmente a los productos de Microsoft que cuestan miles de dólares. Muchos de los servidores web ejecutaron Apache sobre una máquina Linux o FreeBSD y realizaron el trabajo. El software funcionó bien y el precio inexistente facilitó la elección. Linux también estaba conquistando a algunos de los físicos, diseñadores de armas, biólogos y científicos más serios del mundo. Algunos de los mejores laboratorios del país habían conectado grupos de PC baratos y los habían convertido en supercomputadoras que eran altamente competitivas con las mejores máquinas del mercado. Una nueva empresa comenzó a ofrecer "supercomputadoras" por 3.000 dólares. Estas máquinas usaban Linux para mantener el flujo de datos mientras los bastidores de las computadoras se conectaban y traqueteaban durante horas en simulaciones complicadas. Había otros indicios. Los usuarios de Linux se jactaban de que su sistema rara vez fallaba. Algunos afirmaron tener máquinas que habían estado funcionando durante un año o más sin ningún problema. Los usuarios de Microsoft (y Apple), por otro lado, se habían acostumbrado a los bloqueos frecuentes. La "pantalla azul de la muerte" que aparece en los monitores de los usuarios de Windows cuando algo va irremediablemente mal es el blanco de muchas bromas. Los usuarios de Linux también se jactaron de la calidad de su interfaz de escritorio. La mayoría de los no iniciados pensaron en Linux como un sistema de hackers construido para nerds. Sin embargo, recientemente se han afianzado dos shells operativos muy buenos llamados GNOME y KDE. Ambos ofrecían al usuario un entorno que se parecía a Windows pero era mejor. Los hackers de Linux comenzaron a jactarse de que podían equipar a sus novias, madres y amigos con cajas de Linux sin pena. Algunas personas con poca experiencia en computadoras estaban adoptando Linux sin problemas. La creación de sitios web y supercomputadoras no es una tarea fácil y, a menudo, se realiza en cuartos traseros, fuera de la vista de la mayoría de las personas. Cuando la gente empezó a darse cuenta de que los hippies del software libre se las habían arreglado poco a poco para apoderarse de una gran parte del mundo de los servidores web y la supercomputación, se dieron cuenta de que tal vez la afirmación de Microsoft era viable. Los servidores web y las supercomputadoras son máquinas construidas y operadas por personas serias con jefes que quieren algo a cambio de entregar cheques de pago. No son solo juguetes sentados en el garaje. Si estos muchachos del software libre hubieran conquistado escenarios tan serios, tal vez podrían manejar la oficina y el escritorio. Si el mundo del software libre hubiera creado algo utilizable por las madres de los programadores, entonces tal vez fueran competidores viables. Quizás Microsoft tenía razón. 3.1 Durmiendo Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Mientras Microsoft enfocaba sus ojos y oídos en Washington, uno de sus mayores competidores dormía hasta tarde. Cuando Richard Schmalensee se preparaba para subir al estrado en Washington, D.C., para defender la escandalosa fortuna de Microsoft contra las hondas y flechas de una inquisición del gobierno, Alan Cox todavía dormía. No se levantó hasta las 2:00 p. m. en su casa de Swansea, en la costa sur de Gales. Esto no es demasiado extraño para él. Su esposa, Telsa, se queja con frecuencia de que es imposible hacer que se mueva todas las mañanas sin una dosis de Jolt Cola, del tipo que está sobrecargado de cafeína. La noche anterior, Cox y su esposa fueron a ver La Máscara del Zorro, la última película que describe cómo Don Diego de la Vega asumió la identidad secreta del Zorro para liberar al pueblo mexicano de la tiranía de Don Rafael Montero. En esta versión, Don Diego, interpretado por Anthony Hopkins, elige a un huérfano, Alejandro Murrieta, interpretado por Antonio Banderas, y le enseña a ser el próximo Zorro para que la lucha continúe. Su tema resuena con los escritores de software de código abierto: un pequeño grupo de guerreros talentosos y apasionados que se defienden del malvado opresor. Cox lleva un diario abierto y publica las entradas en la web. "Es una película bonita, con algunas acrobacias geniales y un juego de personajes", escribió, pero Sin embargo, podrías haber encajado la trama, incluidos todos los giros, en el reverso de una caja de cerillas. Eso hizo que se sintiera un poco pesado, por lo que solo obtuvo un 6 sobre 10, aunque me siento extremadamente satisfecho porque detecté uno de los errores en la película mientras la miraba, no al consultar imdb más tarde. Por imdb, se refería a Internet Movie Database, que es una de las listas más completas de créditos, resúmenes y fallas de películas disponibles en la red. Los usuarios de Internet escriben con sus propias reseñas y sinopsis de argumentos, que la base de datos cataloga diligentemente y pone a disposición de todos. Es un libro de referencia con miles de autores. En este caso, el gran fallo de la película es el hecho de que uno de los anchos de vía del tren utiliza el sistema métrico. México se convirtió a este sistema en 1860, pero la película está ambientada en 1841. Ups. Arrestado. Telsa escribió en su diario, que también publica en la red bajo el título "El diario más preciso. De verdad". Lo arrastró al cine para ver al Zorro. Debí haber recordado que había hecho algo de esgrima y encontró algo diferente. También afirmó que había detectado un error muy oscuro. Después revisé en IMDB y quedé asombrado. ¿Cómo vio esto? Cox es un gran oso de hombre que usa una larga barba de mago marrón. Tiene una mente analítica y ágil que constantemente desarma un sistema y lo prueba en busca de debilidades. Si está jugando un juego, juega hasta que encuentra un truco o una escapatoria que le dará la ventaja ganadora. Si está trabajando en la casa, a menudo termina entrometiéndose en las cosas hasta que las arregla y las mejora. Por supuesto, también los rompe a menudo. A su esposa le encanta quejarse de los golpes y estruendos que se producen en la oficina de su casa, donde suele trabajar hasta las 6:30 de la mañana. Para su esposa, estos estruendos, golpes y charlas nocturnas son la fuente de las quejas desganadas inherentes a todo matrimonio. Ella obviamente ama tanto sus idiosincrasias como la oportunidad de discutir cuán extrañas pueden ser. En enero, Telsa estaba tratando de encontrar una forma de automatizar su cafetera conectándola a su computadora. Ella escribió en su diario, Alan es reacio a involucrarse en cualquier intento de hacer que una cafetera se encienda a través de la computadora ahora porque parece pensar que eventualmente la encenderé sin agua y provocaré un incendio. Yo no soy el que soldó los espaguetis enlatados a la cacerola antiadherente. O prende fuego al wok. Mas de una vez. Una vez con quince invitados en la casa. Pero ahí estamos. Para el resto del mundo, esta necesidad de perder el tiempo y jugar con las máquinas es más que una fuente de comedia marital. Cox es una de las grandes amenazas para el dominio continuo de Microsoft, a pesar de que encontró la forma de soldar los espaguetis a una sartén antiadherente. Es uno de los principales desarrolladores que ayudan a mantener el kernel de Linux. En otras palabras, es uno del grupo de programadores que ayuda a guiar el desarrollo del sistema operativo Linux, el que Richard Schmalensee siente que es una gran amenaza para Microsoft. Cox es una de las pocas personas en las que Linus Torvalds, el creador de Linux, confía para tomar decisiones importantes sobre direcciones futuras. Cox es un experto en las entrañas de red del sistema y es responsable de asegurarse de que la mayoría de las nuevas ideas que la gente sugiere para Linux se consideren cuidadosamente y se integren correctamente. Torvalds se remite a Cox en muchos asuntos sobre cómo las computadoras basadas en Linux se comu nican con otras computadoras a través de una red. Cox trabaja mucho para encontrar formas eficientes para que Linux haga malabarismos con varias conexiones sin ralentizarse ni estancarse. El grupo que trabaja con Cox y Torvalds opera sin estructura oficial. Millones de personas usan Linux para mantener sus computadoras en funcionamiento, y todas ellas tienen copias del código fuente. En la década de 1980, la mayoría de las empresas comenzaron a mantener el código fuente de su software lo más privado posible porque les preocupaba que un competidor pudiera aparecer y robar las ideas que la fuente explicaba. El código fuente, que está escrito en lenguajes como C, Java, FORTRAN, BASIC o Pascal, está destinado a ser leído por programadores. La mayoría de las empresas no querían que otros programadores entendieran demasiado sobre las entrañas de su software. La información es poder, y las empresas instintivamente jugaron sus cartas cerca de su pecho. Sin embargo, cuando Linus Torvalds comenzó a escribir Linux en 1991, decidió regalar el sistema operativo de forma gratuita. Incluyó todo el código fuente porque quería que otros lo leyeran, comentaran y tal vez lo mejoraran. Su decisión fue tanto una ruptura radical con el procedimiento de programación estándar como una decisión práctica. Era un mal estudiante en ese momento, y este sistema operativo era simplemente un pasatiempo. Si hubiera tratado de venderlo, no habría obtenido nada por él. Ciertamente no tenía dinero para construir una empresa que pudiese pulir el software y comercializarlo. Así que simplemente envió copias a través de Internet. Compartir software ya había sido respaldado por Richard Stallman, un programador legendario del MIT que creía que mantener el código fuente en privado era un pecado y un crimen contra la humanidad. Un programador que comparte el código fuente permite que otros aprendan, y esos otros pueden contribuir con sus ideas a la mezcla. El código fuente cerrado deja a los usuarios frustrados porque no pueden aprender sobre el software ni corregir ningún error. Stallman se separó del MIT en 1984 cuando fundó la Free Software Foundation. Esta se convirtió en la organización que patrocinó el gran proyecto de Stallman para liberar el código fuente, un proyecto que llamó GNU. En la década de 1980, Stallman creó herramientas muy avanzadas como el editor de texto GNU Emacs, que la gente podía usar para escribir programas y artículos. Otros donaron su trabajo y el proyecto GNU pronto incluyó una amplia gama de herramientas, utilidades y juegos. Todos ellos fueron distribuidos de forma gratuita. Torvalds miró a Stallman y decidió seguir su ejemplo con código fuente abierto. El software libre de Torvalds comenzó a atraer a personas a las que les gustaba jugar con la tecnología. Algunos simplemente lo miraron. Otros jugaron durante unas horas. Gratis es un poderoso incentivo. No permite que el dinero, las tarjetas de crédito, las órdenes de compra y la aprobación del jefe se interpongan en el camino de la curiosidad. Algunos, como Alan Cox, se divirtieron tanto desarmando un sistema operativo que se quedaron y comenzaron a contribuir al proyecto. Con el tiempo, más y más personas como Alan Cox descubrieron el pequeño proyecto de Torvalds en la red. Algunos durmieron hasta tarde. Otros mantuvieron el horario normal y trabajaron en oficinas. Algunos simplemente encontraron errores. Otros arreglaron los errores. Aún otros agregaron nuevas características que querían. Lentamente, el sistema operativo pasó de ser un juguete que satisfizo la curiosidad de los informáticos a una herramienta utilizable que impulsa supercomputadoras, servidores web y millones de otras máquinas en todo el mundo. Hoy, alrededor de mil personas trabajan regularmente con personas como Alan Cox en el desarrollo del kernel de Linux, el nombre oficial de la parte del sistema operativo que Torvalds comenzó a escribir en 1991. Puede que esa no sea una estimación precisa porque muchas personas verifican durante unas semanas cuando un proyecto requiere su participación. Algunos siguen todo, pero la mayoría de la gente solo está interesada en los pequeños rincones. Muchos otros programadores han contribuido con varias piezas de software, como procesadores de texto u hojas de cálculo. Todos estos se agrupan en paquetes que a menudo se denominan Linux simple o GNU/Linux y los envían empresas como Red Hat o más grupos ad hoc como Debian.[^1] Si bien Torvalds solo escribió el kernel central, la gente usa su nombre, Linux, para representar todo un cuerpo de software escrito por miles de personas. No es exactamente justo, pero la mayoría lo deja pasar. Si no hubiera existido el kernel de Linux, los usuarios no tendrían l a capacidad de ejecutar software en un sistema completamente gratuito. El software gratuito tendría que interactuar con algo de Microsoft, Apple o IBM. Por supuesto, si no fuera por todo el resto del software libre de Berkeley, el proyecto GNU y miles de otros garajes en todo el mundo, el kernel de Linux tendría poco que hacer. [1]: /Linux Weekly News/ mantiene una lista completa de distribuidores. Estos van desde operaciones pequeñas, de uno o dos hombres, hasta las más grandes y corporativas como Red Hat: Alzza Linux, Apokalypse, Armed Linux, Bad Penguin Linux, Bastille Linux, Best Linux (finlandés/sueco), Bifrost, Black Cat Linux (ucraniano/ruso), Caldera OpenLinux, CCLinux, Chinese Linux Extension, Complete Linux, Conectiva Linux (brasileño), Debian GNU/Linux, Definite Linux, DemoLinux, DLD, DLite, DLX, DragonLinux, easyLinux, Enoch, Eridani Star System, Eonova Linux, e-smith server and gateway, Eurielec Linux (español), eXecutive Linux, floppyfw, Floppix, Green Frog Linux, hal91, Hard Hat Linux, Immunix, Independence, Jurix, Kha0s Linux, KRUD, KSI-Linux, Laetos, LEM, Linux Cyrillic Edition, LinuxGT, Linux-Kheops (francés), Linux MLD (japonés), LinuxOne OS, LinuxPPC, LinuxPPP (mexicano), Linux Pro Plus, Linux Router Project, LOAF, LSD, Mandrake, Mastodon, MicroLinux , MkLinux, muLinux, nanoLinux II, NoMad Linux, OpenClas sroom, Peanut Linux, Plamo Linux, PLD, Project Ballantain, PROSA, QuadLinux, Red Hat, Rock Linux, RunOnCD, ShareTheNet, Skygate, Slackware, Small Linux, Stampede, Stataboware, Storm Linux, SuSE, Tomsrtbt, Trinux, TurboLinux, uClinux, Vine Linux, WinLinux 2000, Xdenu, XTeamLinux y Yellow Dog Linux. Oficialmente, Linus Torvalds es el árbitro final del kernel y quien toma las decisiones finales sobre las nuevas funciones. En la práctica, el grupo funciona como una "ad-hocracia" laxa. A algunas personas les puede interesar una función en particular, como la capacidad de interactuar con Macintosh, y escriben un código especial que facilita esta tarea. Otros que ejecutan bases de datos realmente grandes pueden querer sistemas de archivos más grandes que puedan almacenar más información sin límites. Todas estas personas trabajan a su propio ritmo. Algunos trabajan en sus casas, como Alan Cox. Algunos trabajan en laboratorios universitarios. Otros trabajan para empresas que usan Linux y alientan a sus programadores a desconectarse para que satisfaga sus necesidades. El equipo está unido por listas de correo. La lista de correo de Linux Kernel conecta a Cox en Gran Bretaña, Torvalds en Silicon Valley y otros en todo el mundo. Publican notas en la lista y discuten ideas. A veces estallan peleas verbales y, a veces, todos están de acuerdo. A veces, las personas encienden una vela escribiendo código nuevo para mejorar el kernel, y otras veces simplemente maldicen la oscuridad. Cox ahora es una de varias personas responsables de coordinar la adición de un nuevo código. Él prueba la compatibilidad y guía a los autores de Linux para asegurarse de que estén trabajando juntos de manera óptima. En esencia, prueba cada pieza de software entrante para asegurarse de que todos los indicadores funcionen con el sistema de medición correcto para que no haya fallas. Intenta eliminar las incompatibilidades que estropearon al Zorro. A menudo, otros duplicarán el trabajo de Cox. Algunas características nuevas son muy populares y muchos cocineros se preocupan por esto. La tecnología para acelerar computadoras con múltiples CPU permite que cada computadora aproveche la potencia adicional, por lo que muchos miembros de la lista la prueban con frecuencia. Quieren las máquinas más rápidas que puedan obtener, y suavizar el flujo de datos entre las CPU es la mejor manera de permitir que las máquinas cooperen. Otras características no son tan populares, y son abordadas por las personas que las necesitan. Algunas personas quieren conectar sus cajas Linux a Macintosh. Hacer eso sin problemas puede requerir algo de trabajo en el núcleo. Otros pueden querer agregar un código especial para habilitar un dispositivo especial como una cámara de alta velocidad o un tipo extraño de unidad de disco. Estos grupos a menudo trabajan solos pero coordinan sus soluciones con la multitud principal. Idealmente, podrán encontrar algunos parches que resuelvan su problema sin romper alguna otra parte del sistema. Es un proceso muy social y político que se desarrolla en cámara lenta a través de mensajes de correo electrónico. Una persona hace una sugerencia. Otros pueden estar de acuerdo. Alguien puede discutir con la idea porque parece poco elegante, descuidada o, lo que es peor, peligrosa. Después de algún tiempo, se desarrolla un consenso aproximado. Los problemas fáciles se pueden resolver en días o incluso minutos, pero las decisiones complicadas pueden esperar mientras el debate continúa durante años. Cada día, Cox y sus colegas virtuales analizan minuciosamente las listas tratando de descubrir cómo hacer que Linux sea mejor, más rápido y más útil. A veces se saltan para ver una película. A veces van de excursión. Pero una cosa que no hacen es pasar meses acurrucados en salas de conferencias tratando de encontrar argumentos legales. Hasta hace poco, la gente de Linux no tenía dinero para abogados, y eso significa que no se desviaron tratando de descubrir cómo hacer que personas grandes y poderosas como Richard Schmalensee le dijeran a un tribunal que no existe el monopolio en el negocio de los sistemas operativos de computadoras. . 3.2 Demandas contra hackers Schmalensee y Cox no podrían ser más diferentes entre sí. Uno es un tecnócrata de carrera que se mueve fácilmente entre el gobierno y el MIT. El otro es lo que solía conocerse como un profesor distraído, del tipo que trabaja cuando está realmente interesado en un problema. Da la casualidad de que Cox está bastante intrigado con la construcción de un mejor sistema operativo que las diversas ediciones de Windows que forman la base del dominio de Microsoft en la industria informática. La batalla entre Linux y Microsoft se alinea para ser la pelea clásica entre gente como Schmalensee y gente como Cox. Por un lado están los ejércitos de abogados, cabilderos, vendedores y ejecutivos caros que están armados con patentes, demandas y legislación. Son expertos en mover las palancas del poder hasta que los engranajes se alinean correctamente y miles de millones de dólares se derraman en sus bolsillos. Saben cómo congraciarse, adularse, suplicar o incluso amenazar hasta que se pongan el manto de la autoridad y comanden la piedad y la devoción del mundo. La gente compra Microsoft porque es "el estándar". Nadie decretó esto, pero de alguna manera ha llegado a ser. Por otro lado, hay un grupo de tipos a los que les gusta jugar con las computadoras y harán cualquier cosa para desarmarlas. No son como el tipo de la canción de John Mellencamp que canta "Lucho contra la autoridad y la autoridad siempre gana". Algunos pueden tener una actitud, pero la mayoría solo quiere mirar el interior de sus computadoras y reorganizarlas para conectarlas a máquinas de café o redes. Quieren juguetear con las entrañas de sus máquinas. Si sueldan unos espaguetis por dentro, que así sea. Normalmente, estas batallas entre los trajes y los geeks no amenazan el orden establecido. Hay estudiantes universitarios en todo el mundo que construyen automóviles que funcionan con energía solar, pero en realidad no representan una amenaza para las industrias petrolera o automotriz. "21", un restaurante en Nueva York, hace una gran hamburguesa, pero no van a sacar a McDonald's del negocio. Los experimentalistas y los perfeccionistas por lo general no chocan con las corporaciones que dependen de la dominación mundial para sus ganancias. Excepto cuando se trata de software. El software es diferente a los autos o las hamburguesas. Una vez que alguien escribe el código fuente, copiar el código fuente cuesta casi nada. Eso hace que sea mucho más fácil para los manitas como Cox tener un efecto global. Si Cox, Stallman, Torvalds y sus amigos tienen suerte con algo que es mejor que Microsoft, entonces el resto del mundo puede compartir su invento por casi nada. Eso es lo que hace que Cox, Torvalds y sus amigos sean una amenaza creíble sin importar la frecuencia con la que se acuesten hasta tarde. Es fácil drogarse solo con la idea. Se supone que unos cuantos tipos que duermen hasta tarde y trabajan en dormitorios no alcanzarán a un motor de efectivo como Microsoft. No se supone que creen un motor de servidor web que controle más de la mitad de la web. No se supone que creen una interfaz gráfica de usuario para dibujar ventanas e íconos en la pantalla que sea mucho mejor que Windows. No se supone que creen supercomputadoras con precios de etiqueta de $3,000. El dinero no se supone que pierda. Por supuesto, las personas que trabajan en proyectos de software libre tienen ventajas que el dinero no puede comprar. Estos programadores no necesitan abogados para crear licencias, negociar contratos o discutir sobre los términos. Su software es gratuito y los abogados pierden interés rápidamente cuando no hay dinero disponible. Los chicos del software libre no necesitan escudriñar la copia publicitaria. Cualquiera puede descargar el software y simplemente probarlo. Los programadores tampoco necesitan sentarse en un rincón cuando su computadora falla y se quejan del idiota que escribió el software. Cualquiera puede leer el código fuente y corregir los fallos. En otras palabras, la gente en el mundo del software libre está disfrutando de la libertad. Están en lo alto del sueño americano original de la vida, la libertad y la búsqueda de la felicidad. Los fundadores de los Estados Unidos de América no se propusieron crear un país próspero donde los ciudadanos pasaran sus días preocupándose de si podrían comprar nuevos vehículos utilitarios deportivos cuando se adquirieran las opciones sobre acciones. Los fundadores solo querían asegurar las bendiciones de la libertad para la posteridad. De alguna manera, la riqueza siguió. Esta hermosa historia es fácil de aceptar: un grupo de personas comenzó intercambiando software genial en la red y terminó descubriendo que su intercambio gratuito creaba un software mejor que el que una corporación podría producir con una montaña de dinero en efectivo. Los programadores descubrieron que la cooperación sin restricciones facilitaba la contribución de todos. Ninguna etiqueta de precio mantuvo alejados a los demás. No hay estereotipos ni prejuicios que excluyan a nadie. El software y el código fuente estaban en la red para que cualquiera pudiera leerlos. La cooperación abierta también resultó ser una competencia abierta porque el mejor software ganó la mayor atención. Las comadrejas corporativas con la oreja del presidente no pudieron detener el envío de un proyecto de software libre. Ninguna reorganización o reducción podría impedir que las personas trabajaran en software libre si quisieran piratear. La libertad de crear era más poderosa que el dinero. Esa es una imagen idílica, y el éxito inicial de Linux, FreeBSD y otros paquetes gratuitos hace que sea tentador pensar que el éxito se acumulará. Hoy en día, los servidores de código abierto alimentan más del 50 por ciento de los servidores web en Internet, y eso no es un logro pequeño. Conseguir que miles, si no millones, de programadores trabajen juntos es bastante sorprendente dado lo extravagantes que pueden ser los programadores. La facilidad de copiar hace pensar que Alan Cox podría levantarse tarde y aun así mover el mundo. Pero la década de 1960 también fue una época supuestamente idílica en la que la paz, el amor y el compartir iban a crear un hermoso planeta donde todos se entregaban a los demás en una eterna trenza dorada de respeto mutuo y cariño. Todos asumieron que el mismo espíritu que tan rápida y fácilmente impregnaba los campus universitarios y las fiestas de amor en los parques estaba destinado a arrasar el mundo. Las comunas realmente estaban sucediendo, hombre. Pero de alguna manera, el ritmo maravilloso nunca se impuso más allá de esos pequeños nidos de fácil cuidado y generosidad. De alguna manera, la gente comenzó a regresar, consiguiendo trabajos reales, tomando hipotecas reales y comprando de nuevo en el mundo donde el dinero era el rey. A lo largo de los años, el mismo final triste ha caído sobre muchas comunas, visiones utópicas y vibraciones hipnóticas. La libertad es genial. Permite que los inventores brillantes trabajen independientemente de las ruedas del poder. Pero el capital es otra bestia poderosa que impulsa la innovación. Las grandes comunas a menudo fracasaron porque nunca convirtieron su arduo trabajo en dinero, lo que les dificultaba ahorrar e invertir. Regalar cosas puede ser realmente maravilloso, pero no construye un nido de huevos. Ahora mismo, el movimiento del software libre se encuentra en un momento crucial de su historia. En el pasado, una cultura de dar y compartir abiertamente permitió que miles de programadores construyeran un gran sistema operativo que era, en muchos sentidos, mejor que cualquier cosa que viniera de las mejores compañías. Muchas personas comenzaron a trabajar en Linux, FreeBSD y miles de otros proyectos como pasatiempos, pero ahora se están despertando y encuentran a IBM, HewlettPackard, Apple y todos los demás grandes llamando a su puerta. Si los niños podían crear algo tan bueno como Linux, todos comenzaron a preguntarse si estos niños realmente tenían suficientes cosas buenas para llegar hasta el final y durar nueve entradas contra los mejores bateadores de poder. Tal vez el movimiento del software libre crezca más rápido y mejor a medida que más personas se unan. Más usuarios significan más ojos en busca de errores. Más usuarios significan más programadores que escriben nuevo código fuente para nuevas funciones. Más es mejor. Por otro lado, compartir puede ser genial, pero ¿puede vencer el poder del capital? Los empleados de Microsoft pueden ser simples siervos motivados por el sueño de que algún día sus exiguas opciones de acciones valdrán lo suficiente como para jubilarse, pero tienen una gran cantidad de efectivo que los impulsa. Este capital se puede cambiar muy rápidamente. Si Bill Gates quiere que 1000 programadores creen algo, puede agitar su mano. Si quiere comprar 1000 computadoras, le toma un segundo. Ese es el poder del capital. Linus Torvalds puede estar en la portada de las revistas, pero no puede hacer nada con un gesto de la mano. Debe encantar y engatusar a las miles de personas en la lista de correo de Linux para hacer un cambio. Muchos de los proyectos de software libre pueden generar un gran código, pero tienen que rogar por las computadoras. Los programadores podrían incluso sorprenderlo y encontrar una solución aún mejor. Lo han hecho en el pasado. Pero sin dinero significa que nadie tiene que hacer lo que alguien dice. En el pasado, el movimiento del software libre era como las películas en las que Mickey Rooney y Judy Garland daban un gran espectáculo en el granero. Esa parte no cambiará. Los niños geniales con un sueño seguirán lanzando grandes programas que serán maravillosos regalos para el mundo. Pero los espectáculos que son encantadores y frescos en un granero pueden volverse escasos y débiles en un gran escenario de Broadway. Los fallos y la funcionalidad básica de Linux y el software gratuito no parecen tan malos si sabes que los construyen los niños en su tiempo libre. Crear herramientas reales para empresas reales, madres, estaciones de policía y usuarios serios en todas partes es otro asunto. Es posible que todos esperen que compartir, cuidar y tener curiosidad sean suficientes, pero nadie lo sabe con certeza. Quizá el capital acabe ganando. Tal vez no lo haga. Es libertad versus seguridad; es compartir abiertamente frente a opciones sobre acciones; es cooperación versus intimidación; son los geeks contra los trajes, todo en una pelea de derribo, pirateo hasta el cansancio, el ganador se lo lleva todo. --------------------------------- 4. Listas Mientras Alan Cox dormía hasta tarde y Microsoft ponía a Richard Schmalensee en el estrado, el resto del mundo del software de código abierto se ocupaba de sus propios problemas. Algunos recién se estaban levantando, otros estaban en la mitad de su día y otros simplemente se iban a dormir. Esto no se debe solo a que a los hackers de código abierto les gusta trabajar en horarios extraños durante todo el día. Algunos lo hacen. Pero también viven en todo el mundo en todas las diferentes zonas horarias. El sol nunca se pone en el imperio del código abierto. El 14 de enero de 1999, por ejemplo, Peter Jeremy, un australiano, anunció que acababa de descubrir un posible problema Y2K en el software de control de la base de datos central que ayudó a mantener el código fuente de FreeBSD. Lo anunció publicando una nota en una lista de correo que envió el mensaje a muchos otros usuarios de FreeBSD. El problema era que el software simplemente agregaba los dos caracteres "19" al comienzo del año. Cuando llegó el nuevo milenio, aproximadamente un año después, el software comenzaría a escribir la nueva fecha como "19100". Ups. El problema era en gran parte cosmético porque solo ocurría en algunos de los programas de soporte utilizados por el sistema. FreeBSD es un primo cercano del kernel de Linux y lo precede en algunos aspectos. Desciende de una larga tradición de investigación y desarrollo de sistemas operativos en la Universidad de California en Berkeley. El nombre BSD significa "Berkeley Software Distribution", el nombre dado a una de las primeras versiones del código fuente del sistema operativo que Berkeley hizo para el mundo. Ese pequeño paquete creció, se transformó y absorbió muchas otras contribuciones a lo largo de los años. Referirse a Linux y FreeBSD como primos es un término apropiado porque comparten gran parte del mismo código fuente de la misma manera que los primos comparten algunos de los mismos genes. Ambos toman prestado el código fuente y las ideas del otro. Si compra un disco con FreeBSD, lo que puede hacer de compañías como Walnut Creek, puede obtener muchos de los mismos paquetes de software que obtiene de un disco de Red Hat Linux. Ambos incluyen, por ejemplo, algunos de los compiladores GNU que convierten el código fuente en algo que las computadoras pueden entender. FreeBSD, de hecho, tiene algunos de sus propios fanáticos y devotos. El sitio de FreeBSD enumera miles de empresas, grandes y pequeñas, que utilizan el software. Yahoo, el gran directorio de Internet, centro de juegos y operación de noticias, utiliza FreeBSD en algunos de sus servidores. Lo mismo ocurre con Blue Mountain Arts, la compañía de tarjetas de felicitación electrónicas que es consistentemente uno de los sitios más populares en la web. Sin duda, hay miles más que no figuran en el sitio de FreeBSD. Después de todo, el software producido por el proyecto FreeBSD es gratuito, por lo que la gente puede regalarlo, compartirlo con sus amigos o incluso fingir que lo está "robando" haciendo una copia de un disco en el trabajo. Nadie sabe realmente cuántas copias de FreeBSD existen porque no hay razón para contar. Es posible que Microsoft necesite contar cabezas para poder facturar a todos por usar Windows, pero FreeBSD no tiene ese problema. Esa mañana, el mensaje de Peter Jeremy se envió a todos los que se suscribieron a la lista de correo de FreeBSD. Algunos usuarios que se preocuparon por el error Y2K podrían tomar el parche de Jeremy y usarlo para reparar su software directamente. No necesitaban esperar a que alguna burocracia central emitiera un juicio sobre la información. No tuvieron que esperar a que el chico Y2K de FreeBSD se pusiera a investigar el cambio. Todos podían simplemente insertar la solución porque tenían todo el código fuente disponible. Por supuesto, la mayoría de la gente nunca usa todas sus libertades. En este caso, la mayoría de la gente no tuvo que molestarse en lidiar con el parche de Jeremy porque esperaron la versión oficial. La infraestructura de FreeBSD absorbió los cambios en sus bóvedas de código fuente y los cambios aparecieron en la siguiente versión completamente actualizada. Esta nueva versión completa es donde la mayoría de las personas comenzaron a usar la corrección. Jeremy es un programador que creó una solución fácil de usar para otros programadores. Sin embargo, la mayoría de las personas no son programadores y quieren que su software sea fácil de usar. La mayoría de los programadores ni siquiera están interesados ​​en hurgar dentro de sus máquinas. Todos quieren que la solución se solucione sola o se acerque lo más posible. El mensaje de Jeremy fue solo uno de los cientos que se filtraron a través de la comunidad de FreeBSD ese día. Algunos cayeron en oídos sordos, algunos generaron comentarios mocosos y algunos atrajeron mucha atención. Las listas de correo eran ecologías bastante complejas donde las ideas florecían y crecían antes de desvanecerse y morir. Por supuesto, no es justo categorizar el mundo de FreeBSD como una anarquía totalmente descentralizada. Hay un equipo central dirigido por un hombre, Jordan Hubbard, que organiza el liderazgo de un grupo central de programadores dedicados. El grupo administra el sitio web, mantiene una versión actualizada de FreeBSD y patrocina docenas de listas dedicadas a diferentes rincones o funciones. Una lista se enfoca en conectar los discos duros SCSI rápidos y de alto rendimiento que son populares entre las personas que exigen sistemas de alto rendimiento. Otro se concentra en construir suficiente seguridad para mantener alejados a los atacantes que podrían intentar colarse a través de Internet. Ese 14 de enero, un hombre en Gran Bretaña, Roger Hardiman, estaba ayudando a un hombre en Suiza, Reto Trachsel, a conectar una tarjeta de video Hauppauge a su sistema. Se estaban comunicando en la lista de correo multimedia dedicada a encontrar formas de agregar funciones de audio y video a los sistemas FreeBSD. Trachsel publicó una nota en la lista solicitando información sobre cómo encontrar el software del controlador que aseguraría que los datos que salen del receptor de televisión Hauppauge estarían generalmente disponibles para el resto de la computadora. Hardiman señaló una solución, pero advirtió: "Si su tarjeta Hauppauge tiene el chip de audio decodificador estéreo MSP34xx, es posible que no obtenga sonido cuando vea televisión. Debería arreglar esto en la próxima semana o dos". Soluciones como estas flotan en la comunidad de FreeBSD. A la mayoría de las personas realmente no les importa si pueden ver la televisión con su computadora, pero algunas sí. El fácil acceso al código fuente y los controladores significa que unos pocos pueden salir y hacer lo que quieran sin pedir permiso a una gran empresa. Las grandes empresas como Microsoft y Apple, por ejemplo, tienen proyectos internos que están produciendo un software impresionante para crear y mostrar extravagancias multimedia en las computadoras. Pero tienen una visión estricta del mundo: la empresa es productora de herramientas de alta calidad que llegan al consumidor que las usa y las paga de una forma u otra. La ecología de listas es más orgánica y antijerárquica. Todo el mundo tiene acceso al código fuente. Todos pueden hacer cambios. Todos pueden hacer lo que quieran. No hay necesidad de que la administración de FreeBSD se reúna y decida "Multimedia es bueno". No es necesario que un equipo de proyecto priorice y enumere los elementos de acción y los mejores entregables. Alguien en Suiza decide que quiere conectar un receptor de televisión a su computadora y, qué se sabe, alguien en Gran Bretaña ya resolvió el problema. Bueno, lo resolvió si no tiene un chip decodificador estéreo MSP34xx en su tarjeta. Pero eso también debería arreglarse tarde o temprano. 4.1 Gratis no significa aprovechado Hay miles de otras listas de correo que vinculan miles de otros proyectos. Es difícil ponerles un número porque los proyectos crecen, se fusionan y se desvanecen a medida que los intereses de las personas aumentan y disminuyen. Los mejores florecen y los demás simplemente se van. La vida en las listas de correo suele ser un poco más brutal y corta que la vida en la tierra. El trabajo en el proyecto necesita dividirse. Los voluntarios necesitan organizarse para poder escribir un gran software. Ese 14 de enero, un nuevo miembro de la lista WINE estaba aprendiendo cómo funciona el voluntariado. El tipo publicó una nota en la lista que describía su dispositivo de música portátil Diamond RIO que te permite escuchar archivos MP3 cuando quieras. "Creo que el equipo de desarrollo de WINE debería dejarlo todo y trabajar para que este programa funcione, ya que no parece que Diamond quiera lanzar una utilidad de Linux para Rio", escribió. WINE significa "WINE Is Not an Emulator", que es una broma que solo los programadores y los amantes del software libre pueden entender. Primero es un juego con el acrónimo recursivo del proyecto GNU ("GNU no es UNIX"). También es un poco una declaración política para los programadores. Un emulador es una pieza de software que hace que una computadora actúe como otra. Una empresa llamada Connectix, por ejemplo, vende un emulador que permite que una Macintosh se comporte como una PC con Windows para que cualquiera pueda usar su software de Windows en la Mac. Los emuladores, sin embargo, son bastante lentos porque constantemente traducen información sobre la marcha. Cualquiera que haya intentado mantener una conversación con alguien que habla un idioma diferente sabe lo frustrante que puede ser necesitar un traductor. El proyecto WINE es un ambicioso intento de eliminar uno de los elementos estructurales más importantes del monopolio de Microsoft. El software escrito para Windows solo funciona cuando la gente compra una versión de Windows de Microsoft. Cuando compra un emulador Connectix para Mac, obtiene una versión de Windows incluida. El proyecto WINE es un grupo de personas que intentan clonar Windows. Bueno, no clonarlo todo. Solo quieren clonar lo que se conoce como la API Win32, una panoplia de características que facilitan la escritura de software para una máquina de Microsoft. Un programador que quiera crear un nuevo botón para una computadora con Windows no necesita escribir todas las instrucciones para dibujar un marco con sombreado tridimensional. Un empleado de Microsoft ya ha incluido esas instrucciones en la API de Win32. Hay millones de funciones en estos kits que ayudan a los programadores. Algunos reproducen archivos de audio, otros dibujan imágenes o películas complejas. Estas características facilitan a los programadores la creación de software para Windows porque parte del trabajo más repetitivo ya está terminado. El clon WINE de Win32 es un ejemplo fascinante de cómo el código abierto comienza lentamente y se acelera. Bob Amstadt inició el proyecto en 1993, pero pronto se lo entregó a Alexandre Julliard, quien ha sido la fuerza principal detrás de él. El proyecto, aunque todavía está lejos de estar terminado, ha producido algunos logros impresionantes, haciendo posible ejecutar programas importantes como Microsoft Word o Microsoft Excel en una caja de Linux sin usar Windows. En esencia, el software WINE está haciendo un trabajo lo suficientemente bueno actuando como Windows para engañar a Excel y Word. Si puedes engañar a los primos, no está mal. La página de inicio de WINE (www.winehq.com) estima que más de 90.000 personas usan WINE regularmente para ejecutar programas para Microsoft Windows sin comprar Windows. Alrededor de 140 o más personas contribuyen regularmente al proyecto escribiendo código o corrigiendo errores. Muchos son aficionados que quieren la emoción de hacer que su software funcione sin Windows, pero algunos son programadores corporativos. Los programadores corporativos quieren vender su software al mercado más amplio posible, pero no quieren tomarse el tiempo para reescribir todo. Si pueden hacer que su software funcione bien con WINE, entonces las personas que usan Linux o BSD pueden usar el software que fue escrito para Microsoft Windows. El nuevo usuario que quería que su reproductor RIO funcionara con su computadora Linux pronto tuvo un duro despertar. Andreas Mohr, un programador alemán, respondió: En lugar de sugerir al equipo de WINE que "deje todo" para que funcione algo relativamente menor como PMP300, ¿podría instalar WINE, probarlo, leer la documentación/informes de errores y publicar un informe de error útil aquí? Hay millones de aplicaciones de Windoze muy útiles e impresionantes. .. (Después de todo, esa es solo mi opinión personal, tal vez eso fue un poco demasiado duro ;-) La mayoría de los nuevos usuarios de software libre pronto descubren que la libertad no siempre es fácil. Si desea obtener software gratuito, tendrá que trabajar un poco. A veces tienes suerte. El hombre en Suiza que publicó su nota el mismo día descubrió que alguien en Gran Bretaña estaba resolviendo sus problemas por él. Sin embargo, nadie estaba trabajando en el software RIO y asegurándose de que funcionara con WINE. La sugerencia de Mohr fue presentar un informe de error que clasifique la usabilidad del software para que los programadores que trabajan en WINE puedan modificarlo. Este es solo el primer paso en la experiencia del software libre. Alguien tiene que darse cuenta del problema y solucionarlo. En este caso, alguien necesita conectar su reproductor de MP3 Diamond RIO a una caja de Linux e intentar mover archivos MP3 con el software escrito para Windows. Idealmente, el software funcionará perfectamente y ahora todos los usuarios de Linux podrán usar reproductores RIO. En realidad, puede haber problemas o fallas. Algunos de los gráficos en la pantalla pueden estar equivocados. Es posible que el software no descargue nada en absoluto. El primer paso es que alguien pruebe el producto y escriba un informe detallado sobre lo que funciona y lo que no. En el momento de escribir este artículo, nadie ha dado un paso al frente. No hay informes sobre el jugador Diamante en la base de datos WINE. Tal vez el nuevo usuario no tuvo tiempo. Tal vez no era lo suficientemente sofisticado técnicamente para hacer funcionar WINE en primer lugar. Todavía no es un sistema simple de usar. En cualquier caso, su brillante idea se quedó en el camino. Las listas de correo zumban con charlas ociosas sobre ideas ingeniosas y extravagantes que nunca llegan a buen término. Algunas personas ven esto como una limitación del mundo del software libre. Sin embargo, una corporación puede enviar un equipo de programadores para crear soluciones. Estas empresas tienen dinero para gastar en pulir un producto y asegurarse de que funcione. Connectix, por ejemplo, fabrica un emulador que permite a los usuarios de Mac jugar juegos escritos para Sony PlayStation. La compañía emplea a un número considerable de personas que simplemente juegan todos los juegos de Sony de principio a fin hasta que desaparecen todos los errores. Es un trabajo duro, pero alguien tiene que hacerlo. WINE no puede pagarle a nadie, y eso significa que las grandes ideas a veces son ignoradas. Sin embargo, la comunidad del software libre no ve esto necesariamente como una limitación. Si el jugador de RIO fuera realmente importante, alguien más vendría y se haría cargo del proyecto. Alguien más haría el trabajo y presentaría un informe de error para que todos pudieran usar el software. Si no hay nadie más, quizás el software RIO no sea tan importante para la comunidad Linux. El trabajo se hace cuando alguien realmente se preocupa lo suficiente como para hacerlo. Estas listas de correo son las fibras que unen a la comunidad de código abierto con la red de mentes. Antes del correo electrónico, no eran más que un puñado de rebeldes que vagaban por los páramos y traqueteaban en sus sótanos inventando máquinas monstruosas. Ahora son mecanismos perfectamente sintonizados coordinados por mensajes, notas y misivas. No son locos que rugen en las cenas sobre la mala tecnología de las corporaciones tipo Borg. Ahora tienen amigos. Una persona puede ser un escama, pero un grupo puede estar en algo. -------------------- 5. Imagen Considere esta imagen: Microsoft es un megalito construido por un hombre con un ego imponente. Puede que no sea justo agrupar a todos los siervos en las granjas de cubículos corporativos en Redmond en un gran ejército de autómatas, pero ciertamente evoca una imagen sorprendente que no es del todo inexacta. Los empleados de Microsoft son ferozmente leales y, a menudo, más dedicados a la causa que la abeja obrera promedio. Bill Gates construyó la empresa desde cero con la ayuda de varios amigos de la universidad, y este grupo mantiene un estricto control sobre todas las partes del imperio. El sabor de la organización lo establece un hombre con la mente y el ego para microgestionarlo todo. Ahora considere la imagen de los miembros de la revolución del software libre. Prácticamente todos los artículos periodísticos y reportajes coloridos que describen al grupo hablan de un ejército heterogéneo de programadores desaliñados y barbudos que están demasiado pálidos por pasar sus días frente a la pantalla de una computadora. A los escritores les encanta evocar una imagen de un grupo que parece salido de alguna película de fantasía distópica como Mad Max o A Boy and His Dog. Ellos son los forasteros. Son una banda muy unida de marginados rebeldes que planean liberar a la gente de su esclavitud de Microsoft y devolverle a la gente el poder usurpado por el Sr. Gates. ¿Que quieren ellos? ¡Libertad! ¿Cuándo lo quieren? ¡Ahora! Solo hay un problema con esta imagen ordenada y lista para Hollywood: está lejos de ser verdad. Si bien Microsoft es una gran corporación con riendas de control que mantienen a todos en línea, no existe una organización fuerte o incluso débil que ate al mundo del software de fuente abierta. El movimiento, si pudiera llamarse así, está formado por individuos, cada uno libre de hacer lo que quiera con el software. Ese es el punto: no más grilletes. No más hegemonía corporativa. Solo código fuente puro que se ejecuta rápido, limpio y ligero, directamente durante la noche. Esto no significa que la imagen esté del todo mal. Se sabe que algunas de las luminarias como Richard Stallman y Alan Cox lucen largas barbas al estilo Rip van Winkle. Algunas personas son sorprendentemente pálidas. Algunos podrían bañarse con un poco más de frecuencia. La cafeína es demasiado popular entre ellos. Algunas personas parecen ser objeto de burla por parte de los idiotas del equipo de fútbol de la escuela secundaria. Pero hay muchos contraejemplos. Linus Torvalds conduce un Pontiac y vive en una casa respetable con una esposa y dos hijos. Trabaja durante el día en una gran empresa y pasa las tardes comprando y haciendo recados. Su vida se clasificaría perfectamente como una comedia de situación de finales de la década de 1950 si su esposa, Tove, no fuera una ex campeona finlandesa de kárate y los camiones no llegaran a su casa para entregar computadoras de última generación como una monstruosidad de 200 libras. con cuatro procesadores Xeon. Le dijo a VAR Business: "Un camión grande lo trajo a nuestra casa y el conductor estaba realmente confundido. Dijo: '¿No tienes un muelle de carga?'". Pensándolo bien, ese es el tipo de travesuras que impulsan la mayoría de las comedias de situación. . No hay una manera fácil de clasificar a los muchos contribuyentes de código fuente gratuito. Muchos tienen hijos, pero muchos no. Algunos no los mencionan, algunos se deslizan en referencias a ellos y otros los exhiben con orgullo. Algunos están casados, otros no. Algunos son abiertamente homosexuales. Algunos existen en una especie de utopía presexual de la adolescencia temprana. Algunos de ellos todavía están en la adolescencia. Algunos no lo son. Algunos colaboradores se describen justamente como "haraganes", pero muchos no lo son. Muchos son droides corporativos que trabajan en granjas de cubículos durante el día y crean proyectos de software libre por la noche. Algunos trabajan en bancos. Algunos trabajan en bases de datos para departamentos de recursos humanos. Algunos construyen sitios web. Todos tienen un trabajo diario y muchos se mantienen limpios y listos para ser promovidos al siguiente nivel. Bruce Perens, uno de los líderes del grupo Debian, solía trabajar en la fábrica de ostentación de Silicon Valley, Pixar, y ayudó a escribir parte del software que creó el éxito Toy Story. Aún así, me dijo: "En el momento en que se estrenaba Toy Story, había un transbordador espacial volando con la distribución Debian GNU/Linux controlando un experimento biológico. La gente decía '¿Estás orgulloso de trabajar en Pixar?' y luego diría que el software de mi afición se estaba ejecutando en el transbordador espacial ahora. Ese fue un punto de inflexión cuando me di cuenta de que Linux podría convertirse en mi carrera". De hecho, no es exactamente justo categorizar a muchos de los programadores de software libre como una banda suelta de programadores rebeldes que buscan destruir a Microsoft. Es una gran imagen que alimenta la necesidad de los medios de resaltar el conflicto, pero no es exactamente así. El movimiento del software libre comenzó mucho antes de que Microsoft fuera una palabra familiar. Richard Stallman escribió su manifiesto estableciendo algunos de los preceptos en 1984. Tuvo cuidado de impulsar la noción de que los programadores siempre solían compartir el código fuente del software hasta la década de 1980, cuando las corporaciones comenzaron a desarrollar el negocio del software envuelto. En los viejos tiempos de las décadas de 1950, 1960 y 1970, los programadores siempre compartían. Si bien se sabe que Stallman levanta el dedo medio ante el nombre de Bill Gates por el placer de informar de un escritor de la revista Salon, no busca a Microsoft per se. Solo quiere devolver la informática a los viejo s tiempos cuando la fuente era gratuita y era posible compartir. Lo mismo vale para la mayoría de los otros programadores. Algunos contribuyen con el código fuente porque les ayuda con su trabajo diario. Algunos se quedan despiertos toda la noche escribiendo código porque están obsesionados. Algunos lo consideran un acto de caridad, una especie de noblesse oblige. Algunos quieren corregir los errores que les molestan. Algunos quieren fama, gloria y el respeto de todos los demás programadores de computadoras. Hay miles de razones por las que se escribe nuevo software de código abierto, y muy pocas de ellas tienen algo que ver con Microsoft. De hecho, es una mala idea pensar que la revolución del software libre tiene mucho que ver con Microsoft. Incluso si ganan Linux, FreeBSD y otros paquetes de software libre, es probable que Microsoft continúe volando felizmente de la misma manera que IBM continúa prosperando incluso después de perder el cinturón del campeón mundial de informática de peso pesado ante Microsoft. Cualquiera que pase su tiempo concentrado en la imagen de una banda heterogénea de rufianes y huérfanos que luchan contra el leviatán de Microsoft seguramente se perderá la verdadera historia. La lucha es realmente solo un subproducto de la mayoría de edad del negocio de la información. El comercio de computadoras está madurando rápidamente y convirtiéndose en una industria de servicios. En el pasado, la fabricación de computadoras y software se realizaba en líneas de ensamblaje y en granjas de cubículos. La gente compraba artículos envueltos en plástico en los estantes. Eran artículos que se fabricaban. Ahora, tanto las computadoras como el software se están convirtiendo en mercancías baratas cuya única fuente de ganancias es la personalización y la manipulación manual. El dinero real ahora está en servicio. En el camino, los visionarios del software libre tropezaron con un hecho curioso. Podrían regalar software y la gente devolvería las mejoras. Duplicar el software no cuesta prácticamente nada, por lo que no fue tan difícil regalarlo después de escribirlo. Al principio, esto era una especie de cosa pseudocomunista, pero hoy parece una decisión comercial brillante. Si el software se está convirtiendo en una mercancía con un precio que cae casi a cero, ¿por qué no ir hasta el final y ganar todo lo que pueda compartiendo libremente el código? Las ganancias podrían provenir de la venta de servicios como programación y educación. La revolución no se trata de derrotar a Microsoft; es solo un cambio en la forma en que el mundo compra y usa las computadoras. La revolución es también el último episodio de la batalla entre los programadores y los trajes. En cierto sentido, es una batalla por los corazones y las mentes de las personas que son lo suficientemente inteligentes como para crear software para el mundo. Los programadores quieren escribir herramientas desafiantes que impresionen a sus amigos. Los trajes quieren controlar a los programadores y canalizar su energía para poner más dinero en los bolsillos de la corporación. Los trajes esperan mantener la dedicación de los programadores dándoles sueldos jugosos, pero no está claro si los programadores realmente quieren el dinero. La libertad de hacer lo que quieras con el código fuente es intrínsecamente gratificante. Los demandados quieren mantener el software bajo llave para poder venderlo y maximizar los ingresos. La revolución del software libre se trata realmente de un grupo de programadores que dicen: "Al diablo con el dinero. Realmente quiero el código fuente". La revolución también se trata de definir la riqueza en el ciberespacio. Microsoft promete crear herramientas geniales que nos ayudarán a llegar a donde queramos ir hoy, si seguimos emitiendo cheques cada vez más grandes. El movimiento de código abierto promete software prácticamente sin limitaciones. ¿Cuál es una mejor oferta? Los millonarios de Microsoft probablemente creen en el software propietario y sugieren que la empresa no habría tenido el éxito que tuvo si no hubiera proporcionado algo que la sociedad deseaba. Ellos crearon cosas buenas, y la gente los recompensó. Pero el movimiento de código abierto también ha creado un gran software que muchos piensan que es mejor que cualquier cosa que haya creado Microsoft. ¿Está mejor la sociedad con una infraestructura informática controlada por una gran máquina corporativa impulsada por dinero en efectivo? ¿O compartir el código fuente crea un mejor software? ¿Estamos en un punto en el que el dinero no es el mejor vehículo para lubricar los motores del avance social? Muchos en el mundo del software libre están reflexionando sobre estas preguntas. Cualquiera que sintonice la batalla entre Microsoft y el mundo esperando ver una buena lucha a la antigua por el dominio del mercado se perderá la verdadera emoción. Claro, Linux, FreeBSD, OpenBSD, NetBSD, Mach y los miles de otros proyectos de software libre van a salir adelante. Microsoft va a contraatacar con miles de patentes defendidas por ejércitos de abogados. Algunos de los programadores pueden incluso ser un poco raros, y algunos tendrán derecho a usar el adjetivo "harapán". Pero la verdadera revolución no tiene nada que ver con si Bill Gates mantiene su título de Rey de la Colina. No tiene nada que ver con si los programadores se quedan despiertos hasta tarde y trabajan desnudos. No tiene nada que ver con la mala apariencia, las barbas extravagantes, los vasos de botella de Coca-Cola, las gabardinas negras o cualquiera de los otros estereotipos que alimentan la imagen de los medios. Se trata de la mercantilización gradual del software y el hardware. Se trata de la necesidad de libertad y la búsqueda de crear software genial. Se trata de un mundo que acaba de descubrir cuánto se puede lograr cuando la información se puede duplicar por casi nada. La verdadera lucha es averiguar cuánto tiempo la sociedad puede seguir colgando diez dedos del borde del tablero mientras nos dejamos llevar por la ola de la libertad. ¿Hay suficiente energía en la ola y suficiente gracia en la sociedad para montarla hasta la orilla? ¿O vendrá algo malvado, algo malo o algo descuidado y lo arruinará? ------------------------ 6. Universidad 6.1 Hablar en lenguas Fui parte del movimiento del software libre durante muchos años, pero no lo sabía. Cuando era estudiante de posgrado, publiqué el código fuente de un proyecto. En 1991, ese era el tipo de cosas que se hacían en las universidades. La publicación del código fuente de un proyecto formaba parte de la publicación de un artículo sobre el mismo. Y la academia puso la publicación bastante alta en su lista. Mi primer gran lanzamiento se produjo en mayo de 1991 cuando hice circular un programa que permitía a la gente ocultar mensajes secretos como texto inocuo. Mi programa convertía cualquier mensaje en una simpática jugada por jugada de un partido de béisbol, como "¡No hay contacto en Mudsville! Es una bola rápida con alas. No hay madera en esa. Está descorchando lo que parece una bola de saliva. ¡Woooosh! ¡Strike! Está fuera de allí." El mensaje secreto estaba codificado en la elección de frases. "Está fuera de allí" significaba algo diferente de "Él se lo abre a Orville Baskethands". El programa permitió que la información mutara a otras formas, al igual que los monstruos que cambian de forma de The X-Files. Envié un anuncio al influyente grupo de noticias comp.risks y pronto cientos de personas pidieron copias gratuitas del software. Creé este programa porque el Senador Joe Biden presentó un proyecto de ley en el Senado que requeriría que los fabricantes de todas las redes informáticas proporcionen una forma para que la policía obtenga copias de cualquier mensaje. La Oficina Federal de Investigaciones, entre otros, temía tener problemas para obtener pruebas si las personas podían codificar los datos. Mi software ilustró lo difícil que sería detener el flujo de información. La mejor parte, y quizás la más sorprendente, de todo el florecimiento del correo electrónico se produjo cuando un tipo que nunca había conocido, D. Jason Penney, convirtió el programa Pascal en desvanecimiento en el C más popular. Lo hizo por su cuenta y envió el nuevo software convertido de vuelta a mí. Cuando le pregunté si podía distribuir su versión, dijo que era mi programa. Solo estaba ayudando. Nunca pensé mucho más en ese proyecto hasta que comencé a escribir este libro. Si bien dos o tres personas al mes escribían pidiendo copias del software, nunca se convirtió en más que un poco de investigación sobre los fundamentos de los códigos secretos y un poco de truco matemático. Era más un ejercicio académico que un prototipo de algo que pudiera rivalizar con Microsoft y hacerme rico. En el pasado, pensé que el proyecto nunca se convirtió en más que un lindo juguete porque no había mercado para él. El producto no era fácilmente útil para las empresas, y nadie inicia una empresa sin la esperanza de que millones de personas necesiten desesperadamente un producto. Los proyectos necesitaban programadores y los programadores cuestan dinero. Simplemente supuse que otros proyectos de software libre caerían en el mismo abismo de falta de financiación. Ahora, después de investigar el mundo del software libre, estoy convencido de que mi proyecto fue un pequeño éxito. La contribución de Penney no fue solo una extraña aberración, sino un evento relativamente común en Internet. Las personas están bastante dispuestas a tomar una pieza de software que les interese, modificarla para adaptarla a sus necesidades y luego devolverla al mundo. Claro, la mayoría de las personas solo tienen unas pocas horas a la semana para trabajar en tales proyectos, pero se suman. El trabajo de Penney hizo que mi software fuera más fácil de usar para muchos programadores de C, por lo que se difundió aún más. De hecho, es posible que subconscientemente haya estado menospreciando el proyecto. Tomó solo tres o cuatro días de mi tiempo y un poco más de Penney, pero era una versión completa de un poderoso sistema de encriptación que funcionó bien. Sí, no fluía dinero, pero eso puede haberlo hecho más exitoso. Penney probablemente no me habría dado su versión C si hubiera sabido que la iba a vender. Probablemente habría exigido una parte. Los abogados se habrían involucrado. Todo el proyecto se habría enredado con contratos, fechas de lanzamiento, licencias de distribución y otras molestias que simplemente no valían la pena por una forma ordenada de ocultar mensajes. Claro, el dinero es bueno, pero el dinero también trae problemas. 6.2 Efectivo versus compartir Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. En las décadas de 1980 y 1990, los programadores de las universidades aún compartían mucho con el mundo. La noción de compartir el código fuente con el mundo debe mucho a la tradición académica de publicar los resultados para que otros puedan leerlos, pensar en ellos, criticarlos y, en última instancia, ampliarlos. Muchas de las agencias gubernamentales que otorgan subvenciones, como la Fundación Nacional de Ciencias y la Agencia de Proyectos de Investigación Avanzada de Defensa, fomentaron este intercambio al exigir explícitamente que las personas con subvenciones liberen el código fuente al mundo sin restricciones. Gran parte de Internet fue creada por personas que otorgaron este tipo de contratos e insistieron en estándares compartidos que no eran propietarios. Esta tradición ha caído en tiempos más difíciles a medida que las universidades se obsesionaron más con las ganancias asociadas con las patentes y la investigación por contrato, pero la idea es tan poderosa que es difícil de des plazar. El movimiento del software libre en particular le debe mucho al Instituto Tecnológico de Massachusetts. Richard Stallman, el hombre al que se atribuye el inicio del movimiento, comenzó a trabajar en los laboratorios informáticos del MIT en la década de 1970. Se le atribuye el mérito de desencadenar la revolución porque escribió el Manifiesto GNU en 1984. El documento explicaba en detalle por qué es esencial compartir el código fuente de un programa con otros. Stallman se tomó el asunto en serio porque también practicó lo que escribió y contribuyó con varios programas excelentes, incluido un editor de texto con miles de funciones. Por supuesto, Stallman no se atribuye el mérito de haber tenido la idea de compartir el código fuente. Recuerda con mucho cariño sus primeros años en el MIT y habla de cómo la gente compartía su código fuente y software sin restricciones. Las computadoras eran nuevas, complicadas y temperamentales. La cooperación era la única forma en que alguien podía lograr algo. Es por eso que IBM compartió el código fuente con los sistemas operativos en sus mainframes a principios de la década de 1960. Esta tradición comenzó a desvanecerse a principios de la década de 1980 cuando comenzó la revolución de las microcomputadoras. Las empresas se dieron cuenta de que la mayoría de la gente solo quería un software que funcionara. No necesitaban el código fuente y todas las instrucciones que solo los programadores podían leer. Por lo tanto, las empresas aprendieron rápidamente que podían quedarse con el código fuente y mantener a sus clientes relativamente contentos mientras dejaban fuera a la competencia. Eran reyes que construyeron un muro para mantener alejados a los intrusos. El Manifiesto GNU surgió como la reacción más radical a la tendencia de bloquear el código fuente. Mientras que mucha gente miró el Manifiesto GNU con confusión, otros se convirtieron parcialmente. Comenzaron a donar el código que habían escrito. Algunos arrojaron programas de utilidad aleatorios a la sopa, algunos ofrecieron juegos y algunos enviaron paquetes sofisticados que ejecutaban impresoras, redes o incluso redes de impresoras. Algunos incluso se convirtieron en discípulos completos y comenzaron a escribir código a tiempo completo para el proyecto GNU. Este crecimiento fue ignorado en gran medida por el mundo, que quedó fascinado con el crecimiento de Microsoft. Sin embargo, cada vez más programadores pasaban más tiempo mezclándose con el proyecto GNU, y se estaba afianzando. A principios de la década de 1980, un sistema operativo conocido como UNIX se había vuelto muy popular en universidades y laboratorios. AT&T lo diseñó y construyó en Bell Labs durante la década de 1970. Al principio, la empresa compartió el código fuente con investigadores e informáticos de universidades, en parte porque la empresa era un monopolio al que solo se le permitía vender servicios telefónicos. UNIX fue solo un experimento que la compañía comenzó para ayudar a ejecutar la próxima generación de conmutadores telefónicos, que ya se estaban convirtiendo en computadoras especializadas. Al principio, el proyecto era solo un ejercicio académico, pero toda la investigación y el intercambio ayudaron a crear un buen sistema operativo con una amplia audiencia. UNIX resultó ser bastante bueno. Cuando la compañía telefónica comenzó a dividirse en 1984, la gente de AT&T se preguntó cómo podrían obtener ganancias de lo que era una inversión sustancial en tiempo y dinero. Comenzaron pidiendo a las personas que usaban UNIX en las universidades que firmaran acuerdos de confidencialidad. Stallman vio esto como control mental y la muerte de una gran tradición. Muchos otros en las universidades fueron más pragmáticos. AT&T había dado mucho dinero y recursos a la universidad. ¿No era justo que la universidad devolviera algo? Stallman miró esto un poco diferente. Sí, AT&T estaba siendo amable cuando otorgaba becas a la universidad, pero ¿no eran siempre amables los amos cuando daban cuencos de gachas a sus esclavos? La versión binaria que AT&T comenzó a distribuir al mundo fue simplemente una papilla para Stallman. Los sumos sacerdotes y unos pocos afortunados pudieron leer el código fuente. Llegaron a comer bistec y langosta para untar. Stallman vio a esta fuerza corporativa central y controladora como el enemigo, y comenzó a nombrar su trabajo GNU, que era un acrónimo recursivo que significaba "GNU's Not UNIX". El proyecto GNU tenía como objetivo producir un sistema operativo completo que hiciera todo lo que UNIX hizo sin el costo moral, emocional o ético. Los usuarios podrían leer el código fuente del sistema operativo de Stallman y modificarlo sin firmar un duro acuerdo de confidencialidad redactado por equipos de abogados. Serían capaces de jugar con su software en total libertad. Stallman señala que nunca tuvo como objetivo producir un sistema operativo que no costara nada. El mundo puede estar fascinado con la noción de una etiqueta de precio de cero, pero para Stallman, eso fue solo un efecto secundario de compartir sin restricciones. Su sueño era crear un sistema independiente que pudiera hacer todo con software libre, pero aún faltaba mucho para que fructificara, y Stallman fue lo suficientemente inteligente como para comenzar con un proyecto manejable. Comenzó produciendo un editor de texto conocido como GNU Emacs. El programa fue un gran éxito porque era altamente personalizable. Algunas personas solo usaron el programa para editar documentos, pero otras lo programaron para realizar tareas más sofisticadas, como leer su correo electrónico y generar respuestas automáticas. La gerencia le dijo a un programador que tenía que incluir muchos comentarios en su código fuente, por lo que programó GNU Emacs para insertarlos automáticamente. Un profesor creó una versión de GNU Emacs que insertaría automáticamente elogios aleatorios en las solicitudes a su secretaria.[^2] Prácticamente todo en Emacs se podía cambiar o personalizar. Si no le gustó presionar la tecla Eliminar para corregir un carácter mal escrito, puede hacer qu e la tecla 6 haga lo mismo. Esto podría dificultar la escritura de números, pero el usuario era libre de arruinar su vida tanto como quisiera. [2]: "¿Dónde están esos informes que te pedí que copiaras? Estás haciendo un gran trabajo. Gracias por toda la ayuda", en un día. "¿Alguna vez vas a copiar esos informes? Estás haciendo un gran trabajo. Gracias por toda la ayuda", en el siguiente. Microsoft tardó años en ponerse al día con la solución de Stallman, e incluso entonces la implementaron de una manera peligrosa. Permitieron que las personas crearan pequeños programas personalizados para modificar documentos, pero se olvidaron de evitar los ataques maliciosos. código de hacer estragos. Hoy en día, Microsoft Word permite que pequeños programas llamados virus de macro deambulen por todo el planeta. Abra un documento de Word y un virus podría estar al acecho. En la década de 1980, el mundo del software libre se dedicó a proyectos como este. GNU Emacs se convirtió en un gran éxito en el mundo académico donde los administradores de sistemas podían instalarlo gratis y no preocuparse por contar estudiantes o negociar licencias. Además, las mentes inteligentes pudieron apreciar mejor la genial flexibilidad que Stallman había diseñado en el sistema. La gente inteligente perdía el tiempo agregando filtros al editor de texto que escaneaban su texto y lo traducían a, como, Valley Girl talk o más jive urbano. El proyecto GNU creció al aceptar contribuciones de muchas personas de todo el país. Algunos eran programas bastante sofisticados y llamativos como GNU Chess, un programa que era bastante competitivo y tan bueno como todos los paquetes excepto los mejores. La mayoría eran herramientas simples para manejar muchas de las tareas diarias para ejecutar un sistema informático. Los administradores de sistemas, estudiantes y programadores de todo el país a menudo aceptaban trabajos pequeños porque se sentían obligados a arreglar algo. Cuando terminaron, algunos enviaron el código fuente al proyecto GNU. El mayor proyecto de programación de Stallman para GNU durante la década de 1980 fue escribir el compilador GNU C (GCC). Este programa fue una herramienta importante que convirtió el código fuente C escrito por humanos en el código de máquina entendido por las computadoras. El paquete GCC fue una piedra angular importante para el proyecto GNU de varias maneras. Primero, fue uno de los mejores compiladores que existen. En segundo lugar, podría moverse fácilmente de una máquina a otra. Stallman lo transfirió personalmente a varias plataformas grandes diferentes, como la línea de procesadores x86 de Intel. Tercero, el paquete era gratuito, lo que en el caso del software GNU significaba que cualquiera podía usar y modificar el software libremente. El GCC proporcionó un importante efecto armonizador al proyecto GNU. Alguien podría escribir su programa en una máquina construida por Digital, compilarlo con GCC y estar bastante seguro de que se ejecutaría en todas las demás máquinas con GCC. Eso permitió que el software GNU migrara libremente por todo el mundo, de máquina en máquina, de Sun a Apollo, de DEC a Intel. La licencia de GCC también atrajo a muchos desarrolladores e ingenieros curiosos. Cualquiera podía usar el código fuente para sus proyectos, y muchos lo hicieron. Con el tiempo, el compilador pasó de una máquina a otra a medida que los usuarios lo convertían. A veces, un ingeniero de la compañía de chips reelaboraba el compilador para que funcionara en un nuevo chip. A veces, un usuario lo haría por un proyecto. A veces, un estudiante lo hacía cuando le atacaba el insomnio. De alguna manera, se movió de una máquina a otra y llevó consigo todo el resto del software GNU. El siguiente gran salto se produjo a principios de la década de 1990 cuando la gente empezó a darse cuenta de que un sistema operativo completamente gratuito era una posibilidad seria. Stallman siempre había soñado con reemplazar UNIX con algo que fuera igual de bueno y acompañado del código fuente, pero era una tarea grande. Fue la razón por la que inició el proyecto GNU. Lento pero seguro, el proyecto GNU fue ensamblando las piezas para que funcionara. Había cientos de pequeñas utilidades y herramientas más grandes donadas al proyecto GNU, y esas pequeñas partes comenzaban a acumularse. El movimiento del software libre también le debe mucho a Berkeley, o más precisamente a un pequeño grupo en el Departamento de Ciencias de la Computación de la Universidad de California en Berkeley. El grupo de hackers incondicionales, que incluía profesores, investigadores asociados, estudiantes graduados y algunos estudiantes universitarios, había desarrollado una versión de UNIX conocida como BSD (Berkeley Software Distribution). AT&T compartió su versión de UNIX con Berkeley, y los programadores de Berkeley arreglaron, ampliaron y mejoraron el software. Estas extensiones formaron el núcleo de BSD. Su trabajo fue en parte experimental y en parte práctico, pero los resultados fueron ampliamente aceptados. Sun Microsystems, una de las empresas de estaciones de trabajo UNIX de Silicon Valley, usó una versión en sus máquinas a principios de la década de 1990 cuando crearon una nueva versión conocida como Solaris incorporando parte del System V de AT&T. Muchos sienten que BSD y su enfoque sigue n siendo la base de el sistema operativo El gran problema fue que el equipo construyó su versión sobre el código fuente de AT&T. La gente de Berkeley y sus cientos, si no miles, de amigos, colegas y estudiantes que contribuyeron al proyecto regalaron su código fuente, pero AT&T no lo hizo. Esto le dio a AT&T control sobre cualquiera que quisiera usar BSD, y la compañía estaba lejos de estar lista para unirse al movimiento del software libre. Se gastaron millones de dólares en la investigación para desarrollar UNIX. La empresa quería recuperar algo de dinero. El equipo de Berkeley se defendió y Keith Bostic, uno de los miembros del equipo central, comenzó a organizar a las personas para escribir el código fuente que podría reemplazar estos bits. A principios de la década de 1990, había engatusado a suficientes amigos para lograrlo. En junio de 1991, el grupo produjo "Networking Release 2", una versión que incluía casi toda una versión funcional completa de UNIX. Todo lo que necesitaba hacer era agregar seis archivos para tener un sistema operativo completo. AT&T no estaba contento. Había creado una división separada conocida como UNIX Systems Laboratory y quería obtener ganancias. El código fuente gratuito de Berkeley fue una dura competencia. Así que el Laboratorio de Sistemas UNIX demandó. Esta demanda marcó el final del papel preeminente de las universidades en el desarrollo de software libre. De repente, la demanda atrajo la atención de todos y les hizo darse cuenta de que tomar dinero de las corporaciones entraba en conflicto con compartir el código fuente del software. Richard Stallman dejó el MIT en 1984 cuando entendió que la necesidad de dinero de una universidad finalmente superaría su creencia en el intercambio total del código fuente. Stallman era solo un miembro del personal que mantenía las computadoras en funcionamiento. No era un profesor titular que oficialmente podía hacer cualquier cosa. Entonces comenzó la Free Software Foundation y nunca miró hacia atrás. El MIT lo ayudó al principio cediéndole espacio, pero estaba claro que la relación estaba llegando a su fin. Las universidades necesitaban dinero para funcionar. Los profesores de muchas instituciones tenían cuotas que especificaban cuánto dinero de la subvención necesitaban recaudar. Stallman no estaba ga nando dinero regalando su software. Mientras tanto, en la otra costa, la demanda ató a Berkeley y al proyecto BSD durante varios años, y el proyecto perdió energía y tiempo valiosos al dedicarlos a la lucha legal. Mientras tanto, varios otros proyectos de software completamente libres comenzaron a surgir en todo el mundo. Estos comenzaron en sótanos y dependían de las máquinas que poseía el programador. Uno de estos proyectos fue iniciado por Linus Torvalds y eventualmente crecería hasta convertirse en Linux, el motor imparable de la exageración y la gloria. No tenía el dinero del departamento de ciencias de la computación de Berkeley, y no tenía las últimas máquinas que les daban las corporaciones. Pero tenía libertad y la pila de código fuente que provenía de proyectos libres y no afiliados como GNU que se negaba a comprometerse y tomar atajos intelectuales. Aunque Torvalds no se dio cuenta en ese momento, la libertad resultó ser lo más valioso de todo. -------------------------------------------------- 7. arenas movedizas Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. La historia del final de la preeminencia de la universidad en el mundo del software libre es una historia de codicia y poder corporativo. Si bien muchos vieron venir un final infeliz durante muchos años, pocos pudieron hacer mucho para detener la inevitable colisión entre la Universidad de California en Berkeley y su antiguo patrocinador, AT&T. La demanda entre AT&T y la Universidad de California en Berkeley tuvo sus raíces en lo que a los consejeros matrimoniales les encanta llamar una "relación mal concebida". A fines de la década de 1980, el departamento de informática de Berkeley tuvo un problema. Habían estado colaborando con AT&T en el sistema UNIX desde el principio. Habían escrito un buen código, incluido parte del software crucial que formó la base de Internet. Estudiantes, profesores, científicos e incluso comerciantes de Wall Street adoraron el poder y la flexibilidad de UNIX. Todos querían UNIX. El problema era que no todos podían obtener UNIX. AT&T, que había patrocinado gran parte de la investigación en Berkeley, mantuvo mano de hierro sobre su invención. Si quería ejecutar UNIX, entonces necesitaba obtener una licencia de software esencial de AT&T que se encontraba en el núcleo del sistema. Eran los gobernantes supremos del dominio UNIX y esperaban un saludable diezmo por el placer de vivir en él. Una de las personas que querían UNIX era el estudiante finlandés Linus Torvalds, que no podía pagar este diezmo. Estaba lejos de ser el primero, y el conflicto comenzó mucho antes de que comenzara a escribir Linux en 1991. Hacia fines de la década de 1980, la mayoría de las personas en el mundo de la informática conocían bien la cruzada de Stallman contra el dominio corporativo de AT&T y UNIX. La mayoría de los programadores sabían que GNU significaba "GNU's Not UNIX". Stallman no fue la única persona molesta por la actitud de AT&T hacia los acuerdos de confidencialidad y no divulgación. De hecho, su actitud era contagiosa. Algunas personas de Berkeley observaron el crecimiento de las herramientas que surgieron del proyecto GNU y se sintieron un poco usados. Habían escrito muchas piezas de código que llegaron a la versión de UNIX de AT&T. Habían aportado muchas ideas geniales. Sin embargo, AT&T se comportaba como si AT&T fuera el único propietario. Ellos dieron y dieron, mientras que AT&T tomó. Stallman pudo distribuir su código fuente. Stallman llegó a compartir con los demás. Stallman consiguió construir su reputación. Los programadores quedaron entusiasmados con Emacs de Stallman. La gente jugaba GNU Chess en sus oficinas. Otros estaban donando sus herramientas al proyecto GNU. Todos estaban llamando la atención al compartir, excepto la gente de Berkeley que colaboró ​​con AT&T. Esto comenzó a molestar a la gente por el camino equivocado. Había que hacer algo, y la gente de Berkeley empezó a sentir la presión. Algunos en Berkeley se preguntaban por qué los profesores habían entrado en un trato tan fáustico con una gran corporación. ¿Fue la recompensa lo suficientemente grande como para entregar sus almas académicas? ¿De dónde salió AT&T diciéndonos lo que podíamos publicar? Otros fuera de Berkeley miraron y vieron un tesoro de software escrito por académicos. Muchos de ellos eran amigos. Algunos de ellos habían estudiado en Berkeley. Algunos incluso habían escrito parte del código UNIX antes de graduarse. Algunas eran empresas que competían con AT&T. Todos pensaron que podrían resolver sus problemas de UNIX si tan solo pudieran tener en sus manos el código fuente. Tenía que haber alguna forma de liberarlo. Lentamente, los dos grupos comenzaron a establecer contacto ya especular activamente sobre cómo liberar la versión de UNIX de Berkeley de las garras de AT&T. 7.1 Romper el vínculo Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. El primer paso para separar la versión de UNIX de Berkeley del control de AT&T no fue realmente una revolución. Nadie estaba iniciando una guerra civil disparando a Fort Sumter o iniciando una revolución arrojando té en el puerto. De hecho, comenzó mucho antes de la demanda y de Linux. En 1989, algunas personas querían comenzar a conectar sus PC y otros dispositivos a Internet y no querían usar UNIX. Berkeley había escrito parte del software conocido como TCP/IP que definía cómo las computadoras en Internet se comunicarían y compartirían paquetes. Escribieron el software para UNIX porque era uno de los sistemas operativos favoritos en los laboratorios. Otras empresas obtuvieron una copia del código comprando una licencia fuente para UNIX de AT&T. El código TCP/IP era solo parte de la mezcla. Algunos dicen que el costo de la licencia llegó a $250,000 o más y requería que el cliente pagara una tarifa por unidad por cada producto que se enviaba. Esos precios no disuadieron a las grandes empresas como IBM o DEC. Pensaron en UNIX como un sistema operativo para las estaciones de trabajo pesadas y las minicomputadoras vendidas a empresas y científicos. Esos muchachos tenían el presupuesto para pagar un gran hardware, por lo que era posible incluir el costo del sistema operativo UNIX en el paquete. Pero el mundo de la PC era diferente. Estaba lleno de chicos en los garajes que querían construir tableros simples que permitieran que una PC se comunicara en Internet. Estos muchachos eran eficientes y sabían cómo conseguir piezas baratas de todo el mundo. Algunos de ellos habían ido a Berkeley y habían aprendido a programar en las estaciones de trabajo VAXes y Sun que ejecutaban la versión de UNIX de Berkeley. Algunos de ellos incluso ayudaron a escribir o depurar el código. No vieron por qué tenían que comprar una licencia tan grande para algo que gente que no era de AT&T había escrito con la generosa ayuda de grandes subvenciones del gobierno. Algunos incluso trabajaron para corporaciones que dieron dinero para apoyar los proyectos de Berkeley. ¿Por qué no pudieron obtener el código que ayudaron a pagar para desarrollar? Kirk McKusick, uno de los miembros del Grupo de Investigación de Sistemas Informáticos en ese momento, recuerda: "La gente se acercó a nosotros y nos dijo: 'Mira, escribiste TCP/IP. ¿Seguramente no deberías requerir una licencia de AT&T para eso?' Parecían solicitudes razonables. Decidimos comenzar con algo que claramente no era parte del UNIX que recibimos de AT&T. Parecía muy claro que podíamos extraer la pila de TCP/IP y distribuirla sin entrar en conflicto con la licencia de AT&T". Así que el Berkeley Computer Systems Research Group (CSRG) creó lo que llamaron Network Release 1 y lo puso en el mercado por $1,000 en junio de 1989. Ese no era realmente el precio porque el lanzamiento vino con una de las primeras versiones de lo que vendría conocida como la licencia de estilo BSD. Una vez que pagaste los $1,000, podías hacer lo que quisieras con el código, incluso subirlo a Internet y regalarlo. "Pensamos que dos o tres grupos pagarían el dinero y luego pondrían el código en Internet, pero de hecho, cientos de sitios pagaron los mil dólares por él", dice McKusick y agrega, "principalmente para poder obtener una pedazo de papel de la universidad que decía: 'Puedes hacer lo que quieras con esto'". Este movimiento funcionó bien para Berkeley y también para UNIX. La pila Berkeley TCP/IP se convirtió en la versión más conocida del código y actuó como una versión de referencia para el resto de la red. Si tenía una falla, todos los demás tenían que solucionar la falla porque era muy frecuente. Incluso hoy en día, a empresas como Sun les gusta alardear de que su TCP/IP forma la columna vertebral de la Red, y esta es una de las razones para comprar una estación de trabajo Sun en lugar de una NT. Por supuesto, el código en el sistema operativo de Sun tiene una rica herencia basada en Berkeley, y aún puede contener parte del código BSD original para controlar la red. 7.2 Por un centavo Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Con el tiempo, más y más compañías comenzaron a formarse en el Área de la Bahía y más y más se dieron cuenta de que la versión de UNIX de Berkeley era la referencia para Internet. Comenzaron a pedir este bit o ese bit. Keith Bostic escuchó estas solicitudes y decidió que Berkeley CSRG necesitaba liberar la mayor cantidad posible de código fuente. Todos estuvieron de acuerdo en que era una idea utópica, pero solo Bostic pensó que era posible lograrlo. McKusick escribe, en su historia de BSD, "Mike Karels [un compañero desarrollador de software] y yo señalamos que liberar grandes partes del sistema era una tarea enorme, pero estuvimos de acuerdo en que si podía resolver cómo lidiar con la reimplementación los cientos de utilidades y la enorme biblioteca C, luego abordaríamos el kernel. En privado, Karels y yo pensamos que ese sería el final de la discusión". Dave Hitz, un buen amigo de Bostic, recuerda la época. "Bostic era más del tipo autoritario. Simplemente reunía a todos sus amigos para terminar el código. Ibas a cenar a su casa y decía: 'Tengo una lista. ¿Qué quieres ¿hacer?' Creo que hice el comando cp y tal vez el comando mirar". Hitz, por supuesto, está feliz de haber participado en el proyecto. Recientemente fundó Network Appliance, una empresa que empaqueta una versión simplificada de BSD en un servidor de archivos que se supone que es un dispositivo a prueba de balas para los clientes. Network Appliance no necesitaba hacer mucha ingeniería de software cuando comenzó. Simplemente tomaron la versión gratuita de BSD y la conectaron. Bostic persiguió a personas a lo largo y ancho para lograr la tarea. Les dio la descripción publicada de la utilidad o la parte de la biblioteca de la documentación y luego les pidió que la volvieran a implementar sin mirar el código fuente. Esta operación de clonación se conoce como operación de sala limpia porque es totalmente legal si tiene lugar dentro de una sala metafórica donde los ingenieros que están dentro no tienen ninguna información sobre cómo los ingenieros de AT&T construyeron UNIX. Este no fue un trabajo fácil, pero Bostic era bastante devoto y perseguía a la gente en todas partes. Enganchó a todos los que podían codificar en el proyecto y, a menudo, pasó tiempo arreglando cosas después. La tarea tomó 18 meses e involucró a más de 400 personas que recibieron apenas notoriedad y algún agradecimiento después. Los más de 400 nombres están impresos en el libro que escribió con McKusick y Karels en 1996. Cuando Bostic estuvo a punto de terminar, pasó por la oficina de McKusick y preguntó cómo iba el kernel. Esto delató el engaño de McKusick y Karels y los obligó a realizar un duro trabajo de ingeniería. En algunos aspectos, Bostic tenía el trabajo más fácil. Escribir pequeños programas de utilidad que su equipo usó fue un trabajo duro, pero esencialmente estaba preorganizado y segmentado. A lo largo de los años, muchas personas crearon archivos manuales que documentaban exactamente lo que se suponía que debían hacer los programas. Cada programa se podía asignar por separado y las personas no necesitaban coordinar demasiado su trabajo. Estos eran solo platos para una cena compartida. Limpiar el núcleo, sin embargo, era un asunto diferente. Era mucho más grande que muchas de las utilidades más pequeñas y estaba lleno de un código más complicado que formaba un mecanismo estrechamente coordinado. El trabajo descuidado en uno de los archivos de utilidad probablemente afectaría solo a esa utilidad, pero una falla en el kernel de forma rutinaria provocaría la caída de todo el sistema. Si Bostic estaba coordinando una cena compartida, McKusick y Karels tenían que encontrar la manera de crear un restaurante completo que sirviera miles de comidas al día a miles de clientes. Cada detalle necesario para trabajar juntos sin problemas. Para complicar más las cosas, las contribuciones de Berkeley al kernel se mezclaron con las contribuciones de AT&T. Ambos habían agregado partes, pegado nuevas características y creado nuevos poderes a lo largo de los años. Eran socios de facto en el proyecto. En los viejos tiempos, ambos habían compartido su código fuente sin ninguna consideración o preocupación a largo plazo. Pero ahora que AT&T reclamó la propiedad de todo, tenían que encontrar una manera de deshacer todos los cambios y descubrir quién escribió qué. McKusick dice: "Construimos una base de datos convertida línea por línea. Tomamos cada línea de código y la insertamos en la base de datos. Terminas encontrando bastante rápido a dónde migró el código y luego decides si es lo suficientemente grande como para ver si necesitaba una recodificación". Esta base de datos les hizo la vida mucho más fácil y pudieron analizar el código, recodificando rápidamente islotes de código de AT&T aquí y allá. Podrían extraer fácilmente un archivo con el código fuente y dejar que la base de datos marque las partes que podrían ser propiedad de AT&T. Algunas partes fueron rápidamente, pero otras partes se prolongaron. A fines de la primavera de 1991, habían terminado todos menos seis archivos que eran demasiado trabajo. Sería bueno informar que lucharon valientemente hacia adelante, renunciando a todas las distracciones como películas, cafeterías y amigos, pero eso no es cierto. Pusieron y tiraron todo por la puerta y lo llamaron "Network Release 2". El nombre implicaba que esta nueva versión era solo una nueva revisión de su producto anterior, Network Release 1, y esto facilitó la vida de los abogados. Simplemente tomaron la antigua y simple licencia y la reutilizaron. También ocultó el hecho de que esta nueva pila de código tenía solo unos seis archivos por debajo de un sistema operativo completamente desarrollado. La buena noticia sobre el código abierto es que los proyectos suelen tener éxito incluso cuando inicialmente fracasan. Un producto comercial no podría enviarse sin la funcionalidad completa de los seis archivos. Pocos lo comprarían. Además, nadie podía venir, meterse un micrófono bajo el capó y reparar los agujeros. El código fuente propietario no está disponible y nadie quiere ayudar a otra persona en el negocio sin compensación. Sin embargo, el nuevo UNIX casi completo era algo diferente. Era un proyecto universitario y, por lo tanto, parecían aplicarse las reglas universitarias de camaradería e intercambio. Otro programador, Bill Jolitz, recogió Network Release 2 y pronto agregó el código necesario para llenar el vacío. Quedó fascinado con la puesta en marcha de UNIX en un procesador 386, una tarea que era como intentar instalar el último hardware de control de tracción y frenos antibloqueo en un carrito. En ese momento, los científicos informáticos serios trabajaban en máquinas serias de estaciones de trabajo serias y compañías de minicomputadoras. La industria de las PC estaba construyendo juguetes. Por supuesto, había algo de macho en todo el proyecto. En aquel entonces, recuerdo bromear con un amigo que deberíamos intentar que UNIX se ejecutara en el nuevo sistema de aire acondicionado, solo para demostrar que se podía hacer. El proyecto de Jolitz, por supuesto, encontró muchas personas en la red que no pensaron que era solo un juguete. Una vez que puso el código fuente en la Red, un brote de entusiasmo se extendió por las universidades y estaciones de paso del mundo. La gente quería experimentar con un sistema operativo de alta calidad y la mayoría solo podía permitirse hardware relativamente barato como el 386. Claro, lugares como Berkeley podían obtener el dinero de la subvención del gobierno y las grandes donaciones corporativas, pero más de 2000 escuelas estaban esperando. La versión de Jolitz de 386BSD tocó la fibra sensible. Si bien las noticias viajaron rápidamente a algunos rincones, no llegaron a Finlandia. Network Release 2 llegó en junio de 1991, justo al mismo tiempo que Linus Torvalds buscaba un sistema operativo de alto nivel para usar en experimentos. El 386BSD de Jolitz salió unos seis meses después, cuando Torvalds comenzó a profundizar en la creación del sistema operativo que más tarde llamaría Linux. Poco después, Jolitz perdió interés en el proyecto y lo dejó así, pero llegaron otros. De hecho, surgieron dos grupos llamados NetBSD y FreeBSD para llevar la antorcha. Aunque pueda parecer extraño que surgieran tres grupos que construyen un sistema operativo libre sin conocerse, es importante darse cuenta de que Internet era un mundo muy diferente en 1991 y 1992. La World Wide Web era solo un destello en la mente de algunas personas. ojos. Solo las mejores universidades tenían acceso general a la web para sus estudiantes, y la mayoría de la gente no entendía qué era una dirección de correo electrónico. Solo unas pocas empresas relacionadas con la informática, como IBM y Xerox, ponen a sus investigadores en la red. La comunidad era pequeña e insular. Los principales conductos de información eran los grupos de noticias de USENET, que solo leían las personas que podían acceder a través de sus universidades. Esta tecnología era una forma eficiente de compartir información, aunque bastante defectuosa. Así es como funcionaba: de vez en cuando, cada computadora llamaba a sus negociadores e intercambiaba los últimos artículos. La información viajaba como el chisme, es decir, viajaba rápido pero con una distribución muy desigual. Las computadoras siempre se estropeaban o se actualizaban. Nadie podía contar con que todos los mensajes llegaran a todos los rincones del mundo. Las bifurcaciones NetBSD y FreeBSD del kernel BSD continúan existiendo por separado en la actualidad. La gente que trabaja en NetBSD se concentra en hacer que su código se ejecute en todas las máquinas posibles, y actualmente enumeran 21 plataformas diferentes que van desde el omnipresente Intel 486 hasta el desaparecido pero no olvidado Commodore Amiga. El equipo de FreeBSD, por otro lado, se concentra en hacer que su producto funcione bien en Intel 386. Agregaron muchas capas de herramientas de instalación para que sea más fácil de usar para el Joe promedio, y ahora es la versión más popular de código BSD. . Esas dos versiones usaban el último código de Berkeley. Torvalds, por otro lado, no conocía 386BSD, FreeBSD o NetBSD. Si se hubiera enterado, dice, probablemente habría descargado las versiones y se habría unido a uno de esos equipos. ¿Por qué huir y reinventar la rueda? 7.3 AT&T notifica el daño Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Poco después de que Network Release 2 llegara al mundo, comenzaron los verdaderos problemas para BSD. Si bien AT&T realmente no notó 386BSD, NetBSD o FreeBSD, sí notaron una compañía llamada Berkeley Software Design Incorporated. Esta corporación creó su propio sistema operativo tomando Network Release 2 y agregando sus propias versiones de los seis archivos faltantes, pero no lo lanzaron gratis en la red. Comenzaron a poner anuncios en la prensa comercial ofreciendo el código fuente por $995, un precio que, según ellos, era un gran descuento sobre el cargo de AT&T. El lector moderno posterior a Internet debería encontrar esto divertido. Dos o tres grupos e innumerables facciones disidentes estaban distribuyendo el software BSD a través de Internet de forma gratuita y esto no pareció llamar la atención de AT&T, pero la aparición de BSDI vendiendo el mismo producto por casi $ 1,000 hizo sonar las alarmas. Sin embargo, ese fue el tiempo antes de que la infraestructura de Internet se volviera omnipresente. A principios de la década de 1990, la gente solo bromeaba a medias sobre que FedEx era el proveedor de servicios de Internet más eficiente que existía. Era mucho más rápido copiar cientos de megabytes de datos en una cinta magnética y enviarlos a FedEx que intentar copiarlos a través de Internet. En aquel entonces, solo los verdaderos nerds estaban en Internet. Los gerentes y los abogados vestían trajes y obtenían sus noticias de la prensa comercial y los anuncios. La reducción de costos de BSDI fue un gran dolor de cabeza para AT&T. Esta pequeña empresa vendía un producto que AT&T sentía que había guiado, organizado y coordinado a lo largo del tiempo. AT&T comenzó reclamando UNIX como marca comercial y amenazando a BSDI con infringirla. BSDI respondió cambiando los anuncios para enfatizar que BSDI era una compañía separada que no estaba relacionada con AT&T o la subsidiaria que AT&T creó para comercializar UNIX conocida como UNIX System Laboratories, o USL. Eso no funcionó. USL vio que su fuente de ingresos se desvanecía y asumió que la gente aprovecharía la oportunidad de comprar un sistema operativo completo con todo el código fuente por $ 995. El precio parece escandalosamente alto hoy, pero eso es solo después de la dura competencia de precios de la década de 1990. Todavía era una buena oferta en ese momento. Entonces, USL demandó a BSDI por robar el código fuente patentado de AT&T. Este argumento tampoco funcionó. BSDI se dio la vuelta y agitó la licencia Network Release 2 que obtuvieron de Berkeley. Compraron todos menos seis de los archivos de Berkeley, y Berkeley afirmó que todo el código fuente era suyo para venderlo. BSDI escribió los seis archivos que faltaban y estaban bastante seguros de que no recibieron ayuda de AT&T o USL. Por lo tanto, BSDI no robó nada. Si AT&T pensó que era robado, deberían discutirlo con Berkeley. El juez compró el argumento de BSDI y redujo el caso para centrarse en los seis archivos. Este fue un momento crucial en el desarrollo del movimiento de software libre y sus diversos núcleos. AT&T se vio acorralado. Retroceder significaba renunciar a su derecho a UNIX y al maravilloso flujo de tarifas de licencia que seguían llegando. Seguir adelante significaba demandar a la Universidad de California, su viejo amigo, socio y autor de muchos códigos UNIX. Eventualmente, las fuerzas de la codicia y el poder corporativo omnipotente ganaron y la USL de AT&T presentó una demanda nombrando tanto a BSDI como a la Universidad de California. Tomar partido en este caso fue bastante fácil para la mayoría de la gente del mundo académico y del software libre. El CSRG en Berkeley investigó. Publicaron cosas. Se suponía que la investigación universitaria era abierta y de libre distribución. AT&T estaba tratando de robar el trabajo de cientos, si no miles, de estudiantes, investigadores, profesores y otros. Eso no fue justo. En realidad, AT&T pagó algo por lo que obtuvo. Enviaron a sus empleados a Berkeley para obtener títulos de maestría, compartieron el código fuente original de las versiones 5, 6 y 7 y 32/V, e incluso enviaron algo de hardware al departamento de informática. Los creadores originales de UNIX vivieron y trabajaron en Bell Labs cobrando cheques de pago de AT&T. Los estudiantes de Berkeley obtuvieron trabajos de verano en AT&T. No hubo un quid-pro-quo oficial. No estaba muy bien explicado, pero AT&T estaba pagando algo. Algunas personas del lado de AT&T podrían incluso querer pintar el CSRG en Berkeley como lleno de gorrones académicos que trabajaron duro para sacar dinero de las grandes corporaciones sin considerar las implicaciones. La gente de Berkeley debería haber sabido que AT&T iba a querer algo a cambio de sus contribuciones. No existe tal cosa como un almuerzo gratis. Hay algo en este argumento porque ejecutar un proyecto de investigación de alto costo en una escuela de primer nivel requiere una buena cantidad de astucia y sofisticación de marketing. Para la década de 1990, las mejores universidades se habían vuelto muy buenas para hacer promesas vagas y no oficiales con sus súplicas de obsequios corporativos. Este tipo de coquetería y burlas seguramente llevaría a alguien a una pelea. McKusick, por ejemplo, dice que CSRG diseñó la licencia BSD para ser muy liberal para complacer a los donantes corporativos. "Hewlett-Packard invirtió cientos de miles de dólares y lo hizo bajo el entendimiento de que iban a usar el código", dijo. Si BSD no hubiera seguido lanzando código como Network Release 2 en una forma legal clara y fácil de reutilizar, dice, parte de los fondos para el grupo se habrían agotado. Pero también hay un poco de ironía aquí. McKusick señala que AT&T estuvo lejos de ser la compañía más generosa en apoyar al CSRG. "De hecho, incluso tuvimos que pagar nuestra licencia de UNIX", dice antes de agregar, "aunque en ese momento solo costaba noventa y nueve dólares". El apoyo de AT&T al departamento no fue abundante. Los grandes cheques no eran subvenciones directamente. Pagaron la matrícula fuera del estado para los empleados de AT&T que vinieron a Berkeley para recibir sus títulos de maestría. Si bien AT&T podría haber enviado a sus empleados a otro lugar, no hay duda de que existen formas más generosas de enviar dinero a los investigadores. McKusick también señala que AT&T ni siquiera envió mucho hardware. El único hardware que recuerda haber recibido de ellos fueron algunas terminales 5620 y un conmutador basado en circuitos Datakit que, según él, "fue un gran dolor de cabeza que realmente no nos sirvió de mucho". Berkeley estuvo a la vanguardia del desarrollo de estándares basados ​​en paquetes que dominarían Internet. En todo caso, el antiguo conmutador basado en circuitos convenció al equipo de Berkeley de que basar Internet en el antiguo sistema telefónico sería un gran error. Para empeorar las cosas, AT&T a menudo quería que el equipo de BSD incluyera funciones que obligarían a todos los usuarios de BSD a comprar una licencia más nueva y más cara de AT&T. Además, la verificación de la licencia nunca fue una tarea rápida ni fácil. McKusick dice: "Teníamos una persona cuyo trabajo de tiempo completo era mantener feliz a la persona encargada de otorgar licencias de AT&T". Al final, concluye, "Nos pagaron casi nada y obtuvieron una gran ganancia inesperada". Elegir bandos en esta batalla probablemente no valga la pena en este momento porque Berkeley finalmente ganó. El arduo trabajo de los cientos de voluntarios de Bostic y el cuidadoso peinado del núcleo por parte del CSRG dieron sus frutos. El caso de AT&T se desvaneció lentamente cuando la Universidad de California pudo demostrar cuánto de la distribución provenía de fuentes inocentes que no eran de AT&T. Berkeley incluso consiguió algunos buenos golpes propios. Descubrieron que AT&T había eliminado los derechos de autor del código de Berkeley que habían importado a System V y no habían otorgado el debido crédito a Berkeley. La licencia BSD es probablemente una de las menos restrictivas del mundo. Compañías como Apple usan código fuente BSD todo el tiempo. La licencia tiene pocos requisitos más allá de mantener intacto el aviso de derechos de autor e incluir algo de crédito para la Universidad de California. AT&T no prestó atención a esto y no citó las contribuciones de Berkeley en sus comunicados. Ups. El CSRG respondió alegando que AT&T había violado una licencia que puede ser una de las menos restrictivas del mundo. La batalla se prolongó en los tribunales durante más de un año. Se trasladó de la corte federal a la estatal de California. Los jueces celebraron audiencias, los abogados tomaron declaraciones, los empleados leyeron informes, los jueces escucharon argumentos presentados en informes escritos por abogados que acababan de realizar declaraciones. La tasa de consumo de honorarios legales fue probablemente mayor que la de la mayoría de las nuevas empresas de Internet. Cualquier adulto debería echar un vistazo a esta batalla y comprender cómo llegó tan lejos el movimiento del software libre. Mientras la gente de Berkeley se reunía con los abogados y se preocupaba sobre si los jueces elegirían el lado correcto, Linus Torvalds estaba creando su propio núcleo. Comenzó con Linux por su cuenta y eso lo convirtió en un hombre libre. Al final, la Universidad de California resolvió la demanda después de que la USL fuera vendida a Novell, una empresa dirigida por Ray Noorda. McKusick cree que la adopción de la libre competencia por parte de Noorda marcó una gran diferencia, y en enero de 1994 la lucha legal había terminado. Berkeley celebró lanzando un 4.4BSD-Lite completamente gratuito y sin trabas en junio de 1994. Los términos del acuerdo fueron bastante menores. Net Release 2 vino con unos 18.000 archivos. 4.4BSD-Lite contenía todos menos tres. Setenta de ellos incluían un copyright nuevo y ampliado que otorgaba algo de crédito a AT&T y USL, pero no restringía el derecho de nadie a distribuirlos libremente. McKusick, Bostic y los cientos de voluntarios hicieron un gran trabajo asegurándose de que Net Release 2 estuviera limpio. De hecho, dos personas familiarizadas con las negociaciones del acuerdo dicen que Berkeley acaba de borrar algunos archivos para permitir que los abogados de USL salven las apariencias. Nunca lo sabremos con certeza porque los detalles del acuerdo están sellados. McKusick y los demás no pueden hablar de los detalles. Ese es otro gran ejemplo de cómo el sistema legal le falla al pueblo estadounidense e inadvertidamente le da otra ventaja al mundo del software libre. No hay información en el registro para ayudar a los historiadores o dar a las generaciones futuras algunas pistas sobre cómo resolver disputas similares. ---------------------------------- 8. 8. Forastero Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. La batalla entre el departamento de informática de la Universidad de California en Berkeley y AT&T no llegó al sistema judicial hasta 1992, pero la fricción entre la devoción del departamento por compartir y la insistencia de la corporación en el control comenzó mucho antes. Mientras el equipo de BSD luchaba con los abogados, un hombre libre en Finlandia comenzó a escribir su propio sistema operativo sin ningún impedimento legal o institucional. Al principio dijo que era un proyecto que probablemente no llegaría a mucho, pero solo unos años después la gente comenzó a bromear sobre "Total World Domination". Unos años después de eso, comenzaron a usar la frase en serio. En abril de 1991, Linus Torvalds tuvo un problema. Era un estudiante universitario relativamente pobre en Finlandia que quería piratear las entrañas del sistema operativo de una computadora. Las máquinas de Microsoft en ese momento eran las más baratas, pero no eran muy interesantes. El sistema operativo de disco básico (DOS) esencialmente permite que un programa controle la computadora. Windows 3.1 no era mucho más que una interfaz gráfica para DOS que presentaba bonitas imágenes (iconos) para representar los archivos. Torvalds quería experimentar con un sistema operativo real, y eso significaba UNIX o algo parecido a UNIX. Estos sistemas operativos reales hicieron malabares con cientos de programas a la vez y, a menudo, mantuvieron contentos a docenas de usuarios. Jugar con DOS era como practicar tiros de baloncesto por tu cuenta. Jugar con UNIX era como jugar con un equipo que tenía 5, 10, tal vez hasta 100 personas moviéndose alrededor de la cancha en patrones complicados y mecánicos. Pero las máquinas UNIX cuestan una fortuna relativa. Los clientes de gama alta solicitaron el sistema operativo, por lo que, en general, solo las máquinas de gama alta venían con él. Un estudiante universitario pobre de Finlandia no tenía dinero para comprar una estación Sun Sparc de primer nivel. Solo podía permitirse una PC básica, que venía con el procesador 386. Esta era una PC de primera línea en ese momento, pero aún no era particularmente emocionante. Algunas empresas hicieron una versión de UNIX para esta máquina de gama baja, pero cobraron por ella. En junio de 1991, poco después de que Torvalds[^3] comenzara su pequeño proyecto científico, el Grupo de Investigación de Sistemas Informáticos de Berkeley lanzó lo que pensaban que era su versión completamente libre de trabas de BSD UNIX conocida como Network Release 2. Surgieron varios proyectos para portar esto a la 386, y el proyecto evolucionó hasta convertirse en las versiones actuales de FreeBSD y NetBSD. Torvalds ha dicho a menudo que nunca habría iniciado Linux si hubiera sabido que podía descargar un sistema operativo más completo de Berkeley. [3]: Todos en la comunidad, incluidos muchos que no lo conocen, se refieren a él por su nombre de pila. Las reglas de estilo me impiden usar eso en algo tan propio como un libro. Pero Torvalds no sabía sobre BSD en ese momento, y tiene suerte de que no lo supiera. Berkeley pronto se vio invadida por la demanda con AT&T que afirmaba que la universidad de alguna manera estaba enviando la propiedad intelectual de AT&T. El desarrollo del sistema BSD se detuvo bruscamente cuando los programadores se dieron cuenta de que AT&T podía apagarlos en cualquier momento si Berkeley era declarado culpable de regalar el código fuente propiedad de AT&T. Si no pudiera permitirse comprar una máquina UNIX, escribiría su propia versión. Lo haría compatible con POSIX, un estándar para los diseñadores de UNIX, para que otros pudieran usarlo. Minix fue otro sistema operativo similar a UNIX que un profesor, Andrew Tanenbaum, escribió para que los estudiantes experimentaran con las entrañas de un sistema operativo. Torvalds inicialmente consideró usar Minix como plataforma. Tanenbaum incluyó el código fuente de su proyecto, pero cobró por el paquete. Era como un libro de texto para estudiantes de todo el mundo. Torvalds miró el precio de Minix ($150) y pensó que era demasiado. La Licencia Pública General GNU de Richard Stallman se había arraigado en el cerebro de Torvalds, y vio las limitaciones de cobrar por el software. GNU también había producido una amplia variedad de herramientas y programas de utilidad que podía usar en su máquina. Minix estaba controlada por Tanenbaum, aunque con mano mucho más relajada que muchas de las otras compañías en ese momento. La gente podía agregar sus propias características a Minix y algunos lo hicieron. Consiguieron una copia del código fuente por $150. Pero pocos cambios regresaron a Minix. Tanenbaum quería mantenerlo simple y se frustró con la gran cantidad de personas que, como escribió en ese entonces, "quieren convertir Minix en BSD UNIX". Así que Torvalds comenzó a escribir su propio sistema operativo diminuto para este 386. No iba a ser nada especial. No iba a derrocar a AT&T ni a la floreciente Microsoft. Iba a ser un experimento divertido escribir un sistema operativo de computadora que fuera todo suyo. Escribió en enero de 1992: "Muchas cosas deberían haberse hecho de manera más portátil si hubiera sido un proyecto real. Sin embargo, no estoy poniendo demasiadas excusas al respecto: fue una decisión de diseño, y en abril pasado cuando comencé la cosa , no pensé que nadie realmente quisiera usarlo". Aún así, Torvalds tenía grandes ambiciones. Estaba escribiendo un juguete, pero quería que tuviera muchas, si no todas, las características que se encuentran en las versiones de UNIX completas en el mercado. El 3 de julio, comenzó a preguntarse cómo lograr esto y colocó una publicación en el grupo de noticias de USENET comp.os.minix, escribiendo: Hola netlanders, Debido a un proyecto en el que estoy trabajando (en minix), estoy interesado en la definición estándar de posix. ¿Podría alguien indicarme un formato (preferiblemente) legible por máquina de las últimas reglas posix? Los sitios ftp estarían bien. La pregunta de Torvalds era bastante simple. Cuando escribió el mensaje en 1991, UNIX era uno de los principales sistemas operativos del mundo. El proyecto que comenzó en AT&T y Berkeley se distribuía en computadoras de IBM, Sun, Apple y la mayoría de los fabricantes de máquinas de mayor potencia conocidas como estaciones de trabajo. Los bancos y científicos de Wall Street amaban las máquinas más poderosas y amaban la simplicidad y la capacidad de pirateo de las máquinas UNIX. En un intento por unificar el mercado, los fabricantes de computadoras crearon una forma de estandarizar UNIX y la llamaron POSIX. POSIX aseguró que cada máquina UNIX se comportaría de manera estandarizada. Torvalds trabajó rápidamente. En septiembre, estaba publicando notas para el grupo con el asunto "¿Qué es lo que más te gustaría ver en Minix?" Estaba agregando funciones a su clon y quería realizar una encuesta sobre dónde debería agregar a continuación. Torvalds ya tenía buenas noticias para informar. "Actualmente he portado bash (1.08) y GCC (1.40), y las cosas parecen funcionar. Esto implica que tendré algo práctico dentro de unos meses", dijo. A primera vista, estaba haciendo un progreso asombroso. Creó un sistema de trabajo con un compilador en menos de medio año. Pero también tuvo la ventaja de tomar prestado del proyecto GNU. El grupo de proyecto GNU de Stallman ya había escrito un compilador (GCC) y una agradable interfaz de usuario de texto (bash). Torvalds las agarró porque pudo. Estaba de pie sobre los hombros de los gigantes que habían venido antes que él. El núcleo de un sistema operativo a menudo se llama "kernel", que es una de las palabras extrañas que flotan en el mundo de las computadoras. Cuando las personas son correctas, notan que Linus Torvalds creó el kernel de Linux en 1991. La mayoría del otro software, como el escritorio, las utilidades, los editores, los navegadores web, los juegos, los compiladores y prácticamente todo lo demás, fue escrito por otras personas. Si mide esto en espacio de disco, más del 95 por ciento del código en una distribución promedio se encuentra fuera del kernel. Si lo mide por la interacción del usuario, la mayoría de las personas que usan Linux o BSD ni siquiera saben que hay un kernel allí. Los botones en los que hacen clic, los sitios web que visitan y la impresión que realizan están controlados por otros programas que hacen el trabajo. Por supuesto, medir la importancia del núcleo de esta manera es una estupidez. El núcleo es una especie de combinación de la sala de correo, la sala de calderas, la cocina y la lavandería de una computadora. Es responsable de mantener el flujo de datos entre los discos duros, la memoria, las impresoras, la pantalla de video y cualquier otra parte que esté conectada a la computadora. En muchos aspectos, un núcleo bien escrito es como un buen hotel. Los huéspedes se registran, se les asigna una habitación y luego pueden pedir lo que necesiten al servicio de habitaciones y al personal de conserjería perfectamente engrasado. ¿Este nuevo trabajo requerirá 10 megabytes adicionales de espacio en disco? No hay problema señor. En seguida, señor. Estaremos listos con eso. Idealmente, el software ni siquiera sabrá que otro software se está ejecutando en una habitación separada. Si ese otro programa es una herramienta de reproducción de MP3 de rock-and-roll ruidoso, el otro software no se dará cuenta cuando falla y quema su propia habitación. El hotel simplemente navega, ocupándose de los negocios. En 1991, Torvalds tenía una breve lista de características que quería agregar al kernel. Internet era todavía una red pequeña que unía universidades y algunos laboratorios avanzados, por lo que la creación de redes era una preocupación menor. Solo apuntaba al 386, por lo que podía confiar en algunas de las características especiales que no estaban disponibles en otros chips. Las tarjetas de hardware de gráficos de gama alta seguían siendo bastante caras, por lo que se concentró en una interfaz de solo texto. Más tarde arreglaría todos estos problemas con la ayuda de la gente en la lista de correo del kernel de Linux, pero por ahora podía evitarlos. Aún así, piratear el kernel significa anticipar lo que otros programadores podrían hacer para arruinar las cosas. No sabes si alguien intentará hacerse con los 128 megabytes de RAM disponibles. No sabes si alguien va a conectar una vieja y extraña impresora de rueda de margaritas e intentar descargar un archivo PostScript en su garganta. No sabes si alguien va a crear un bucle sin fin que va a escribir números aleatorios en toda la memoria. Los programadores estúpidos y los usuarios tontos hacen estas cosas todos los días, y tienes que estar preparado para ello. El núcleo del sistema operativo tiene que mantener las cosas fluyendo sin problemas entre todas las diferentes partes del sistema. Si uno sale mal debido a un poco de código descuidado, el kernel necesita cortarlo como una extremidad que se está gangrenando. Si un trabajo comienza a calentarse, el núcleo debe tratar de darle todos los recursos que pueda para que el usuario esté contento. El hacker del kernel necesita mantener todas estas cosas en orden. Crear un sistema operativo como este no es tarea fácil. Muchos de los sistemas comerciales fallan con frecuencia sin motivo perceptible, y la mayoría del público simplemente lo toma.[^4] Muchas personas de alguna manera asumen que debe ser su culpa que el programa falle. En realidad, probablemente sea del kernel. O más precisamente, es culpa del diseñador del kernel por no anticipar lo que podría salir mal. [4]: Microsoft ahora reconoce la existencia de un error en las decenas de millones de copias de Windows 95 y Windows 98 que hará que su computadora 'deje de responder (se cuelgue)', ya sabe, lo que llama fallar, después de exactamente 49 días, 17 horas, 2 minutos y 47,296 segundos de funcionamiento continuo. .. . ¿Por qué 49,7? ¿días? Porque las computadoras no cuentan los días. Están contando los milisegundos. Un contador comienza cuando se inicia Windows; cuando llega a 232 milisegundos, que resultan ser 49,7 días, bueno, ese es el número más grande que puede manejar este contador. Y en lugar de dar la vuelta con gracia y comenzar de nuevo desde cero, logra detener todo el sistema operativo". --James Gleick en el New York Times. A mediados de la década de 1970, las empresas y los informáticos ya estaban experimentando con muchos diferentes formas de crear sistemas operativos viables. Si bien las computadoras de la época no eran muy poderosas según los estándares modernos, los programadores crearon sistemas operativos que permitían que decenas, si no cientos de personas, usaran una máquina simultáneamente. El sistema operativo mantendría las diferentes tareas ordenadas y ordenadas. asegúrese de que ningún usuario pueda interferir con otro. A medida que las personas diseñaban más y más sistemas operativos, rápidamente se dieron cuenta de que había una pregunta difícil: ¿qué tan grande debería ser? Algunas personas argumentaron que el sistema operativo debería ser lo más grande posible y estar completo con todas las funciones que alguien podría querer usar. Otros respondieron con diseños simplificados que venían con un pequeño núcleo del sistema operativo rodeado de miles de pequeños programas que hacían lo mismo. Hasta cierto punto, el debate es más sobre la semántica que sobre la realidad. Un usuario quiere que la computadora pueda enumerar los diferentes archivos almacenados en un directorio. No importa si la pregunta la responde un gran sistema operativo que maneja todo o un pequeño sistema operativo que usa un programa para encontrar la respuesta. El trabajo aún debe hacerse, y muchas de las instrucciones son las mismas. Es solo una cuestión de si las instrucciones están etiquetadas como "sistema operativo" o como un programa auxiliar. Pero el debate es también sobre el diseño. A los programadores, maestros y la compañía Lego les encanta creer que cualquier problema se puede resolver dividiéndolo en partes pequeñas que se pueden ensamblar para crear el todo. Todo programador quiere convertir el diseño de un sistema operativo en miles de pequeños problemas que se pueden resolver individualmente. Este sueño suele durar hasta que alguien comienza a ensamblar las piezas y descubre que no funcionan juntas tan perfectamente como deberían. Cuando Torvalds comenzó a crear el núcleo de Linux, decidió que iba a crear una versión más grande e integrada a la que llamó "núcleo monolítico". Este fue un movimiento algo audaz porque la comunidad académica estaba fascinada con lo que llamaron "microkernels". La diferencia es en parte semántica y en parte real, pero se puede resumir por analogía con las empresas. Algunas empresas tratan de construir grandes, integrar sin problemas los pasos de producción. Otros tratan de crear operaciones más pequeñas que subcontratan gran parte del trabajo de producción a otras empresas. Uno es grande, monolítico y lo abarca todo, mientras que el otro es más pequeño, fragmentado y heterogéneo. No es raro encontrar dos empresas en la misma industria que toman diferentes enfoques y piensan que están haciendo lo correcto. El diseño de un sistema operativo a menudo se reduce a la misma decisión. ¿Queremos construir un núcleo monolítico que maneje todos los malabares internamente, o queremos un modelo más pequeño y fragmentado que debería ser más flexible siempre que las partes interactúen correctamente? Con el tiempo, el mundo de los sistemas operativos comenzó a referirse a este núcleo como el kernel del sistema operativo. Las personas que querían crear grandes sistemas operativos con muchas funciones escribieron núcleos monolíticos. Sus enemigos ideológicos que querían dividir el sistema operativo en cientos de pequeños programas que se ejecutan en un núcleo pequeño escribieron micronúcleos. Algunas de las personas más extremas etiquetaron su trabajo como nanokernel porque pensaron que hacía incluso menos y, por lo tanto, era incluso más puro que esos microkernels inflados. La palabra "núcleo" es un poco confusa para la mayoría de las personas porque a menudo la usan para referirse a un fragmento de un objeto o una pequeña fracción. Un argumento extremo puede tener una pizca de verdad. Una película de desastres siempre da a los personajes y al público un núcleo de esperanza al que aferrarse. Los matemáticos usan la palabra de manera un poco diferente y enfatizan la capacidad de la palabra para permitir que una pequeña parte defina un concepto más grande. Técnicamente, el núcleo de una función f es el conjunto de valores, x[1], x[2],. .. x[n] tal que f(x[i])=1, o cualquiera que sea el elemento de identidad. La acción del kernel de una función hace un buen trabajo al definir cómo se comporta la función con todos los demás elementos. Los algebristas estudian el núcleo de una función porque revela el comportamiento general.[^5] [5]: El núcleo de f(x)=x[2] es (-1, 1) e ilustra cómo la función tiene dos ramas. Los diseñadores del sistema operativo usan la palabra de la misma manera. Si definen el kernel correctamente, seguirá el comportamiento del resto del sistema operativo. La pequeña parte del código define el comportamiento de toda la computadora. Si el kernel hace una cosa bien, toda la computadora lo hará bien. Si hace una cosa mal, entonces todo sufrirá. Muchos usuarios de computadoras a menudo notan este efecto sin darse cuenta de por qué existen operaciones donde una compañía controla todo. La mayoría de las computadoras Macintosh, por ejemplo, pueden ser lentas a veces porque el sistema operativo no hace un buen trabajo al hacer malabarismos con la carga de trabajo entre los procesos. El núcleo del sistema operativo no se ha revisado por completo desde los primeros días en que las máquinas ejecutaban un programa a la vez. Esta lentitud persistirá un poco más hasta que Macintosh lance una nueva versión conocida como MacOS X. Esta se basará en el kernel de Mach, una versión desarrollada en la Universidad Carnegie-Mellon y lanzada como software de código abierto. Steve Jobs lo adoptó cuando se fue a NeXT, una empresa que finalmente se volvió a incorporar a Apple. Este kernel hace un trabajo mucho mejor al hacer malabarismos con diferentes tareas porque utiliza la multitarea preventiva en lugar de la multitarea cooperativa. La versión original de MacOS permitía que cada programa decidiera cuándo y si iba a ceder el control de la computadora para permitir que se ejecutaran otros programas. Esta versión de malabarismo de bajo costo se denominó multitarea cooperativa, pero fracasó cuando algún programa en el hotel no cooperó. La mayoría de los desarrolladores de software obedecieron las reglas, pero aun así se cometían errores. Los malos programas bloquearían la máquina. La multitarea preventiva le quita este poder a los programas individuales. Cambia el control de un programa a otro sin pedir permiso. Un cerdo de un programa no puede ralentizar toda la máquina. Cuando el nuevo kernel de MacOS X comience a ofrecer multitarea preventiva, los usuarios deberían notar un comportamiento menos lento y un rendimiento más consistente. Torvalds se sumergió y creó un núcleo monolítico. Esto facilitó la modificación de todas las extrañas interacciones entre los programas. Claro, un microkernel construido alrededor de una arquitectura limpia de paso de mensajes era una forma elegante de construir las entrañas de un sistema operativo, pero tenía sus problemas. No había manera fácil de tratar con excepciones especiales. Digamos que desea que un servidor web se ejecute muy rápidamente en su máquina. Eso significa que debe tratar los mensajes que ingresan a la computadora desde Internet con una velocidad excepcional. Debe enviarlos con el equivalente de entrega especial o FedEx. Debe crear una excepción especial para ellos. Agregar estas excepciones a un microkernel limpio comienza a hacer que se vea mal. El diseño comienza a volverse desordenado y menos elegante. Después de agregar algunas excepciones especiales, el microkernel puede comenzar a confundirse. El kernel monolítico de Torvalds no tenía la elegancia o la simplicidad de un sistema operativo microkernel como Minix o Mach, pero era más fácil de piratear. Los nuevos ajustes para acelerar ciertas funciones fueron relativamente fáciles de agregar. No hubo necesidad de idear una arquitectura completamente nueva para el sistema de paso de mensajes. La desventaja era que las entrañas podían volverse notablemente bizantinas, como la burocracia de una gran empresa. En el pasado, esta complejidad perjudicó el éxito de los sistemas operativos propietarios. La complejidad producía errores porque nadie podía entenderla. El sistema de Torvalds, sin embargo, vino con todo el código fuente, lo que facilitó mucho a los programadores de aplicaciones descubrir qué estaba causando su falla. Para llevar un poco más lejos la metáfora de la burocracia corporativa, el código fuente actuó como la secretaria omnisciente que es capaz de explicarle todo a un ejecutivo estresado. Este conocimiento perfecto redujo el costo de la complejidad. A principios de 1992, Linux ya no era un pasatiempo de medio tiempo para los estudiantes finlandeses. Varios programadores influyentes se interesaron en el código. Era gratis y relativamente utilizable. Ejecutó gran parte del código GNU, y eso lo convirtió en una forma ordenada y económica de experimentar con algunas herramientas excelentes. Más y más personas descargaron el sistema y una fracción significativa comenzó a informar errores y sugerencias a Torvalds. Los volvió a enrollar y el proyecto creció como una bola de nieve. 8.1 Un pasatiempo engendra un proyecto Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. A primera vista, la decisión de Torvalds de crear un sistema operativo no fue extraordinaria. Millones de estudiantes en edad universitaria deciden que pueden hacer cualquier cosa si se esfuerzan un poco más. Los departamentos universitarios de teatro, los periódicos y las revistas de humor comenzaron con este impulso, y la noción no se limita a los estudiantes universitarios. Millones de adultos dirigen equipos de Pequeñas Ligas, construyen maquetas de ferrocarriles, presionan al gobierno local para que cree parques y asumen miles de proyectos grandes y pequeños en su tiempo libre. Cada gran idea tiene un líder que puede producir un sistema para sostenerla. Todos los lotes de los pueblos pequeños tenían niños jugando béisbol, pero algunos muchachos organizaron un programa de ligas menores que estandarizó las reglas y la competencia. Cada pueblo pequeño tenía gente haciendo campaña por los parques, pero un pequeño grupo creó el Sierra Club, que lucha por los parques en todo el mundo. Este talento para organizar el trabajo de los demás es un bien escaso, y Torvalds tenía una habilidad especial para ello. Tuvo la amabilidad de compartir su sistema con el mundo y nunca se enseñoreó de nadie. Sus mensajes estaban llenos de bromas y humor autocrítico, la mayoría de los cuales estaban cuidadosamente marcados con caritas sonrientes (:-)) para asegurarse de que el mensaje fuera claro. Si escribía algo puntiagudo, se disculparía por ser un "impulsivo". Siempre fue amable al dar crédito a otros y notó que gran parte de Linux era solo un clon de UNIX. Todo esto lo hizo fácil de leer y, por lo tanto, influyente. Sin embargo, su mayor truco fue su decisión de evitar el manto del poder. Escribió en 1992: "Aquí está mi posición sobre 'mantener el control', en 2 palabras (¿tres?): No lo haré. El único control que efectivamente he mantenido en Linux es que lo conozco mejor que nadie". Señaló que su control era solo una ilusión causada por el hecho de que hizo un buen trabajo manteniendo el sistema. "He puesto mis cambios a disposición de los sitios ftp, etc. Esos se han convertido efectivamente en lanzamientos oficiales, y no espero que esto cambie por algún tiempo: no porque sienta que tengo algún derecho moral, sino porque tengo No he oído demasiadas quejas". A medida que agregaba nuevas funciones a su sistema operativo, enviaba nuevas copias con frecuencia. Internet hizo que esto fuera fácil de hacer. Simplemente mostraría una nueva versión en un servidor y publicaría un aviso para que todos lo leyeran: venga a descargar la última versión. Dejó en claro que la gente podía votar para destituirlo en cualquier momento. "Si la gente siente que hago un mal trabajo, pueden hacerlo ellos mismos". Podrían simplemente tomar todo su código de Linux y comenzar su propia versión utilizando el trabajo de Torvalds como base. Cualquiera podría romper con el proyecto de Torvalds porque Torvalds decidió enviar el código fuente a su proyecto bajo la Licencia Pública General GNU de Richard Stallman, o GPL. Al principio, lo emitió con una licencia más restrictiva que prohibía cualquier uso "comercial", pero finalmente pasó a la licencia GNU. Esta fue una decisión crucial porque cimentó una promesa con cualquiera que pasara unos minutos jugando con su sistema operativo de juguete para el 386. Establecía que todo el código fuente que escribiera Torvalds o cualquier otra persona sería de libre acceso y compartido con todos. Esta decisión fue un arma de doble filo para la comunidad. Todo el mundo podía tomar el software gratis, pero si comenzaron a circular algún software nuevo creado con el código, tendrían que donar sus cambios al proyecto. Era como papel matamoscas. Cualquiera que comenzó a trabajar con el proyecto se encariñó con él. No podían huir a su propio rincón. Algunos programadores bromean diciendo que esta licencia de papel matamoscas es como el sexo. Si comete un error al conectarse con un proyecto protegido por GPL, lo paga para siempre. Si alguna vez envía una versión del proyecto, debe incluir todo el código fuente. Se puede distribuir libremente para siempre. Mientras que algunas personas se quejaron de la naturaleza pegajosa de la GPL, muchos la vieron como una virtud. Les gustó el código fuente de Torvalds, y les gustó el hecho de que la GPL los convirtió en socios de pleno derecho en el proyecto. Cualquiera podía donar su tiempo y estar seguro de que no iba a desaparecer. El código fuente se convirtió en un cuerpo de trabajo mantenido en confianza común para todos. Nadie podía acordonarlo, cercarlo o tomar el control. Con el tiempo, el proyecto científico favorito de Torvalds y su afición a la piratería crecieron a medida que más personas se interesaban en jugar con las entrañas de las máquinas. El precio era justo y la curiosidad ociosa podía ser poderosa. Algunos se preguntaban qué podía hacer un tipo en Finlandia con una máquina 386. Otros se preguntaban si realmente era tan utilizable como las grandes máquinas de las empresas comerciales. Otros se preguntaron si era lo suficientemente potente como para resolver algunos problemas en el laboratorio. Otros solo querían jugar. Todas estas personas lo intentaron, y algunas incluso comenzaron a contribuir al proyecto. El núcleo floreciente de Torvalds encajaba muy bien con las herramientas que creó el proyecto GNU. Todo el trabajo de Stallman y sus discípulos podía trasladarse fácilmente para trabajar con el núcleo del sistema operativo que Torvalds ahora llamaba Linux. Este fue el poder del código fuente de libre distribución. Cualquiera podía hacer una conexión, y alguien invariablemente lo hacía. Pronto, gran parte del código GNU comenzó a ejecutarse en Linux. Estas herramientas facilitaron la creación de más programas nuevos y la bola de nieve comenzó a rodar. Muchas personas sienten que el verdadero acto de genialidad de Linus Torvalds fue idear un sistema flexible y receptivo para permitir que su sistema operativo de juguete creciera y cambiara. Lanzó nuevas versiones a menudo y animó a todos a probarlas con él. En el pasado, muchos desarrolladores de código abierto que utilizaban la GPL de GNU solo habían lanzado nuevas versiones en los principales hitos del desarrollo, actuando un poco como los desarrolladores comerciales. Después de lanzar la versión 1.0, se refugiaron en sus sótanos hasta que agregaron suficientes funciones nuevas para justificar la versión 2.0. Torvalds evitaba este perfeccionismo y compartía con frecuencia. Si solucionaba un error el lunes, lanzaría una nueva versión esa tarde. No es extraño tener dos o tres nuevas versiones en Internet cada semana. Esto supuso un poco más de trabajo para Torvalds, pero también facilitó la participación de otros. Podían ver lo que estaba haciendo y hacer sus propias sugerencias. Esta libertad también atrajo a otros al partido. Sabían que Linux siempre sería suyo también. Podían escribir funciones interesantes y conectarlas al kernel de Linux sin preocuparse de que Torvalds les arrancara la alfombra. La GPL fue un contrato que duró mucho en el futuro. Era una promesa lo que los unía. El kernel de Linux también tuvo éxito porque fue escrito desde cero para la plataforma de PC. Cuando los hackers de Berkeley UNIX estaban transfiriendo BSD a la plataforma de PC, no pudieron hacer que encajara perfectamente. Estaban tomando una pieza de software diseñada para computadoras más antiguas como la VAX, y recortando esquinas y reescribiendo secciones hasta que se ejecutó en la PC. Alan Cox me señaló: "Las primeras cosas de BSD fueron hechas por gente de UNIX para gente de UNIX. Necesitabas una calculadora y familiaridad con BSD UNIX en máquinas grandes (o mucha lectura) para instalarlo. Tampoco podías compartir un disco entre DOS/Windows y 386BSD o las primeras ramificaciones de este. "Hoy en día, FreeBSD entiende las particiones de DOS y puede compartir un disco, pero en ese momento daba miedo instalar BSD", continuó. El BSD también dio por sentado ciertas piezas de hardware. Las primeras versiones de BSD requerían un 387, un coprocesador numérico que aceleraría la ejecución de números de coma flotante. Cox recuerda que el precio (alrededor de $100) era demasiado para su presupuesto. En ese momento, el mundo del software libre era una organización muy magra. El sistema operativo de Torvalds llenó un agujero crucial en el mundo del software libre e hizo posible que alguien pudiera ejecutar una computadora sin pagarle a nadie por una licencia. Richard Stallman había soñado con este día y a Torvalds se le ocurrió la última pieza importante del rompecabezas. 8.2 Un tipo diferente de prueba Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Durante los primeros meses del trabajo de Torvalds, el grupo BSD estaba atrapado en un pantano legal. Mientras el equipo de BSD estaba involucrado en conversaciones de acuerdos secretos y declaraciones secretas, Linus Torvalds estaba felizmente escribiendo código y compartiéndolo con el mundo en la red. Su vida no era todo melocotones y crema, pero todos sus problemas estaban abiertos. El profesor Andy Tanenbaum, un científico informático bastante respetado y famoso, tuvo un largo debate con Torvalds sobre la estructura de Linux. Miró a Linux y afirmó que Linux habría valido dos F en su clase debido a su diseño. Esto condujo a una gran guerra de llamas que fue tan desagradable como la pelea entre Berkeley y la USL de AT&T. De hecho, para el observador promedio fue aún más desagradable. Torvalds devolvió el fuego de Tanenbaum con palabras fuertes como "fiasco", "daño cerebral" y "apestar". Descartó las malas notas al señalar que supuestamente Albert Einstein obtuvo malas notas en matemáticas y física. Los abogados de alto precio que trabajaban para AT&T y Berkeley probablemente usaron palabras muy caras y educadas para tratar de ocultar los cuchillos que intentaban clavarse mutuamente en la espalda. Torvalds y Tanenbaum se arrancaban el pelo virtual como un festival de graznidos en el programa de Jerry Springer. Pero la guerra de llamas de Torvalds con Tanenbaum ocurrió abiertamente en un grupo de noticias de Internet. Otras personas podrían leerlo, pensar en él, agregar sus dos centavos e incluso tomar partido. Fue un debate muy abierto que descubrió muchas fallas en las versiones originales de Linux y Minix de Tanenbaum. Obligaron a Torvalds a pensar profundamente sobre lo que quería hacer con Linux y considerar sus fallas. Tuvo que escuchar los argumentos de un crítico y varios de sus compañeros en la red y luego presentar argumentos sobre por qué su kernel de Linux no apesta demasiado. Esta lucha abierta tuvo un efecto muy diferente al que se desarrollaba en el sistema legal. Los desarrolladores y los hackers de UNIX evitaron las diversas versiones gratuitas de BSD debido a la nube legal. Si un juez decidiera que AT&T y USL tenían razón, todos tendrían que abandonar su trabajo en la plataforma. Si bien el CSRG trabajó duro para liberarse, los jueces no siempre toman las decisiones que queremos. La pelea entre Torvalds y Tanenbaum, sin embargo, atrajo a la gente al proyecto. Otros programadores como David Miller, Ted T'so y Peter da Silva intervinieron con sus opiniones. En ese momento, solo eran espectadores interesados. Con el tiempo, se convirtieron en parte del grupo de expertos de Linux. Pronto contribuyeron con el código fuente que se ejecutaba en Linux. La emoción de la discusión los obligó a mirar el sistema operativo de juguete de Torvalds y tratar de decidir si su defensa tenía algún sentido. Hoy, David Miller es uno de los mayores contribuyentes al kernel de Linux. Muchos de los debatientes originales se convirtieron en importantes contribuyentes a los cimientos de Linux. Esta pelea atrajo a la gente y los mantuvo involucrados. Mostró que Torvalds se tomaba en serio el proyecto y estaba dispuesto a pensar en sus limitaciones. Más importante aún, expuso estas limitaciones e inspiró a otras personas en la red a dar un paso adelante y tratar de solucionarlas. Todos podían leer los argumentos y participar. Incluso ahora, puedes desenterrar los archivos de esta batalla y leer con detalles insoportables lo que la gente estaba pensando y haciendo. La pelea AT&T/USL-versus-Berkeley aún está sellada. Hasta el día de hoy, todos los devotos de los diversos BSD rechinan los dientes cuando oyen hablar de Linux. Piensan que FreeBSD, NetBSD y OpenBSD son mejores y tienen buenas razones para estas creencias. Saben que fueron los primeros en salir con un sistema completo en funcionamiento. Pero Linux está en la portada de las revistas. Todos los grandes técnicamente sucios ahora están comenzando a usar "Linux" como sinónimo de software libre. Si AT&T nunca demandara, los equipos de BSD serían los que cosecharían la gloria. Serían a ellos a quienes recurría Microsoft cuando necesitaba un competidor plausible. Serían más famosos. Pero eso es llorar sobre la leche derramada. El CSRG de Berkeley vivió una vida de relativo lujo en su mundo enriquecido con grandes donaciones corporativas y gubernamentales. Tomaron el efectivo, y era solo cuestión de tiempo antes de que alguien los reclamara. Sí, al final ganaron, pero llegó demasiado tarde. Torvalds ya estaba fuera de la puerta y atraía a más discípulos. McKusick dice: "Si trazas la base de instalación de Linux y BSD en los últimos cinco años, verás que ambos están en crecimiento exponencial. Pero BSD está atrasado entre dieciocho y veinte meses. Ese es el tiempo que tomó entre Net La versión 2 y el 4.4BSD-Lite libre de cargas. Ese es el tiempo que tardó el sistema judicial en hacer su trabajo". ---------------------------- 9. Crecimiento Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. A lo largo de la década de 1990, el pequeño sistema operativo de juguete creció lenta y silenciosamente a medida que más y más programadores se involucraban en el vórtice. Al principio, el sistema operativo no tenía muchas funciones. Podría ejecutar varios programas diferentes a la vez, pero no podría hacer mucho con los programas. La interfaz del sistema era solo texto. Aún así, esto fue lo suficientemente bueno para algunas personas en laboratorios de todo el mundo. Algunos simplemente disfrutaban jugando con las computadoras. Lograr que Linux se ejecutara en su PC fue un desafío, no muy diferente de instalar un sobrealimentador del mercado de accesorios en un Honda Civic. Pero otros tomaron el proyecto más en serio porque tenían trabajos serios que no podían resolverse con un sistema operativo propietario que venía de Microsoft u otros. Con el tiempo, más personas comenzaron a usar el sistema y comenzaron a contribuir con sus adiciones al bote. Alguien descubrió cómo hacer que el sistema X Window gratuito del MIT se ejecutara en Linux para que todos pudieran tener una interfaz gráfica. Alguien más descubrió cómo incorporar tecnología para interactuar con Internet. Eso marcó una gran diferencia porque todos podían piratear, modificar y jugar con el código y luego subir las nuevas versiones a la red. No hace falta decir que todo el software genial que salió de la Free Software Foundation de Stallman llegó a Linux. Algunos eran simples juguetes como GNU Chess, pero otros eran herramientas serias que eran esenciales para el crecimiento del proyecto. En 1991, la FSF ofrecía lo que podría argumentarse como el mejor editor y compilador de texto del mundo. Otros podrían haber estado cerca, pero los de Stallman eran gratis. Estas fueron herramientas cruciales que hicieron posible que Linux creciera rápidamente de un pequeño kernel experimental a un sistema operativo con todas las funciones para hacer todo lo que un programador podría querer hacer. James Lewis-Moss, uno de los muchos programadores que dedican algún tiempo a Linux, dice que GCC hizo posible que los programadores crearan, revisaran y extendieran el kernel. "GCC es parte integral del éxito de Linux", dice, y señala que esta puede ser una de las razones más importantes por las que "es de buena educación referirse a él como GNU/Linux". Lewis-Moss señala una de las controversias latentes en el mundo del software libre: todas las herramientas y juegos que surgieron del proyecto GNU comenzaron a convertirse en parte de lo que la gente simplemente consideraba "Linux". El nombre del pequeño núcleo del sistema operativo pronto creció para aplicarse a casi todo el software libre que se ejecutaba con él. Esto enfureció a Stallman, quien primero argumentó que un mejor nombre sería "Lignux". Cuando eso no funcionó, se pasó a "GNU/Linux". Algunos ignoraron sus súplicas y simplemente usaron "Linux", lo que sigue siendo un poco injusto. Algunos sienten que "GNU/Linux" es demasiado complicado y, para bien o para mal, simplemente Linux es un atajo apropiado. Algunos, como Lewis-Moss, se mantienen firmes en GNU/Linux. Pronto, algunas personas comenzaron a agrupar CD-ROM con todo este software en un solo lote. El grupo intentaría resolver tantos fallos como fuera posible para que la vida del comprador fuera más fácil. Todos tenían nombres extraños como Yggdrasil, Slackware, SuSE, Debian o Red Hat. Muchos eran solo proyectos de garaje que nunca generaron mucho dinero, pero eso estaba bien. Ganar dinero no era realmente el punto. La gente solo quería jugar con la fuente. Además, pocos pensaron que se podía ganar mucho dinero. La GPL, por ejemplo, dificultó la diferenciación del producto porque requería que todos compartieran su código fuente con el mundo. Si a Slackware se le ocurriera una solución ordenada que mejorara su versión de Linux, entonces Debian y SuSE podrían aprovecharla. La GPL impidió que nadie limitara el crecimiento de Linux. Pero solo los hombres de negocios codiciosos ven el compartir y la competencia como algo negativo. En la práctica, el libre flujo de información mejoró el mercado de Linux al garantizar que fuera estable y estuviera disponible gratuitamente. Si un desarrollador clave de CDROM consigue una nueva novia y deja de pasar suficiente tiempo programando, otra distribución tomará el relevo. Si un huracán arrasara Raleigh, Carolina del Norte, el hogar de Red Hat, entonces todavía habría otro proveedor. Un sistema operativo propietario como Windows es como un conjunto de esposas. Un terremoto en Redmond, Washington, podría causar una seria perturbación para todos. La competencia y la GPL significaron que los usuarios nunca se sentirían atados a un sistema operativo. Si surgían problemas, cualquiera podía simplemente iniciar un grupo disidente y llevar a Linux en esa dirección. Y lo hicieron. Todos los sistemas principales comenzaron como grupos disidentes, y algunos recogieron suficiente impulso y energía para dominar. Con el tiempo, los mejores grupos disidentes crearon sus propios grupos disidentes y el proceso se volvió terriblemente complicado. 9.1 El establecimiento comienza a notar Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. A mediados de la década de 1990, el sistema operativo ya había desarrollado muchos seguidores. En 1994, Jon Hall era programador de Digital, una empresa que luego fue comprada por Compaq. Hall también usa una barba completa y usa el nombre "maddog" como apodo. En ese momento, Digital fabricaba estaciones de trabajo que ejecutaban una versión de UNIX. A principios de la década de 1990, Digital dio un gran salto al crear una versión de procesador de 64 bits de su chip de CPU para estaciones de trabajo, el Alpha, y la empresa quería asegurarse de que el chip encontrara una amplia aceptación. Hall recuerda bien el momento en que descubrió Linux. Le dijo a Linux Today, Ni siquiera sabía que estaba involucrado con Linux al principio. Obtuve una copia del Dr. Dobb's Journal, y allí había un anuncio de "obtenga un sistema operativo UNIX, todo el código fuente y ejecútelo en su PC". Y creo que costaba $99. Y digo, "Oh, wow, eso es genial. Por $ 99, puedo hacer eso". Así que envié a buscarlo, obtuve el CD. El único problema era que no tenía una PC para ejecutarlo. Así que lo puse en mi sistema Ultrix, eché un vistazo a las páginas principales, la estructura de directorios y todo eso, y dije: "Oye, eso se ve muy bien". Luego lo guardé en el archivador. Eso fue probablemente alrededor de enero de 1994. En mayo de 1994, Hall conoció a Torvalds en una reunión de DECUS (Digital Equipment Corporation User Society) y se convirtió en un gran admirador. Hall es un programador de programadores que ha escrito código para muchas máquinas diferentes a lo largo de los años, como IBM 1130 y DEC PDP-8. Comenzó como ingeniero eléctrico en la universidad, pero se dedicó a escribir software "después de ver a un amigo mío frito por 13.600 voltios y 400 amperios, lo que no era un espectáculo agradable". Hall comenzó a jugar con UNIX cuando trabajaba en Bell Labs y se enamoró del sistema operativo. En la reunión, Torvalds ayudó a Hall y a su jefe a configurar una PC con Linux. Esta fue la primera vez que Hall realmente vio ejecutar Linux, y se sorprendió gratamente. Él dijo: "En ese momento, había estado usando UNIX durante probablemente unos quince años. Había usado System V, había usado Berkeley y todo tipo de cosas, y esto realmente se sentía como UNIX. Ya sabes ... Quiero decir, es como tocar el piano Puedes tocar el piano, incluso si es un piano de mierda. Pero cuando es un piano realmente bueno, tus dedos simplemente vuelan sobre las teclas. Así es como se sentía esto. Me sentí bien y quedé realmente impresionado". Esta experiencia convirtió a Hall en un verdadero converso y regresó a Digital convencido de que el proyecto Linux era más que unos niños jugando con un sistema operativo de juguete. Estos llamados aficionados sin sistema centralizado o respaldo corporativo habían producido un sistema muy, muy impresionante que era casi tan bueno como los grandes sistemas comerciales. Hall fue un devoto instantáneo. Muchos involucrados en el proyecto recuerdan su día de conversión con la misma fuerza. Un relámpago despejó la neblina de sus ojos y vieron. Hall se dispuso a intentar que Torvalds reescribiera Linux para que funcionara bien en Alpha. Esta no fue una tarea sencilla, pero ayudó a que el sistema operativo creciera un poco más. La versión original incluía un software que asumía que la computadora estaba diseñada como Intel 386. Esto estaba bien cuando Linux solo se ejecutaba en máquinas Intel, pero eliminar estas suposiciones hizo posible que el software funcionara bien en todo tipo de máquinas. Hall salió a navegar con Torvalds para hablar sobre las entrañas del sistema operativo Linux. Hall me dijo: "Lo llevé al río Mississippi, subí y bajé el Mississippi en el bote fluvial, bebí Hurricanes, y le dije: 'Linus, ¿alguna vez pensaste en portar Linux a un procesador de 64 bits? , como el Alfa?' Él dijo: 'Bueno, pensé en hacer eso, pero la oficina de Helsinki ha tenido problemas para conseguirme un sistema, así que supongo que tendré que hacer el PowerPC en su lugar'. "Sabía que esa era la respuesta incorrecta, así que volví a Digital (en ese momento) y le pedí a un amigo mío, llamado Bill Jackson, que le enviara un sistema a Linus, y lo recibió un par de semanas después de eso. Luego encontré a algunas personas dentro de Digital que también estaban pensando en portar Linux a Alpha. Reuní a los dos grupos y, después de eso, comenzamos con el proyecto Alpha Linux". Esta fue una de las primeras veces que una gran corporación comenzó a tomar nota de lo que estaba sucediendo en los garajes y sótanos de los programadores informáticos más duros. También fue una de las primeras veces que una corporación miró un sistema operativo de código abierto y no reaccionó con miedo o conmoción. Sun siempre fue un gran contribuyente de software de código abierto, pero mantuvieron su sistema operativo propietario. Hall trabajó incansablemente en Digital para asegurarse de que la corporación entendiera las implicaciones de la GPL y vio que era una buena manera de interesarse más en el chip Alpha. Él dice que enseñó a la alta gerencia en Digital cómo "decir la palabra L". Hall también ayudó a iniciar un grupo llamado Linux International, que trabaja para hacer que el mundo corporativo sea seguro para Linux. "Ayudamos a los proveedores a comprender el mercado de Linux", me dijo Hall. "Hay mucha confusión sobre lo que significa la GPL. Menos ahora, pero todavía hay mucha confusión. Les ayudamos a encontrar los mercados". Hoy, Linux International ayuda a controlar la marca registrada del nombre Linux y asegura que se use de manera abierta. "Cuando alguien quería llamarse a sí mismo algo así como 'Universidad Linux', dijimos que eso era malo porque iba a haber más de uno. 'Universidad Linux de Carolina del Norte' está bien. Abre el espacio". Al principio, Torvalds dependía en gran medida de la amabilidad de extraños como Hall. No tenía mucho dinero y el proyecto Linux no le generaba un gran salario. Por supuesto, la pobreza también facilitó que personas como Hall justificaran darle una máquina. Torvalds no era rico monetariamente, pero se hizo rico en máquinas. En 1994, cuando Hall conoció a Torvalds, Linux ya estaba lejos de ser un proyecto científico de un solo hombre. Los disquetes y los CD-ROM que contenían una versión del sistema operativo ya estaban en el mercado, y este mecanismo de distribución fue una de las fuerzas unificadoras cruciales. Alguien podría simplemente gastar unos pocos dólares y obtener una versión que estaba más o menos lista para ejecutarse. Muchos simplemente descargaron sus versiones gratis de Internet. 9.2 Facilidad de uso Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. En 1994, ejecutar Linux nunca fue tan simple como colocar el CD-ROM en la unidad y presionar un botón. Muchos de los programas no funcionaban con ciertas tarjetas de video. Algunos módems no hablaban con Linux. No todas las impresoras se comunicaron correctamente. Sin embargo, la mayor parte del software funcionaba en conjunto en muchas máquinas estándar. A menudo tomó un poco de ajuste, pero la mayoría de las personas podían tener el sistema operativo en funcionamiento en sus computadoras. Este fue un gran avance para el sistema operativo Linux porque la mayoría de las personas podía instalar rápidamente una nueva versión sin perder demasiado tiempo descargando el nuevo código o depurándolo. Incluso los programadores que entendían exactamente lo que estaba sucediendo sintieron que instalar una nueva versión era un trabajo largo, a menudo doloroso, a través de los detalles técnicos. Estos CDROM no solo ayudaron a los programadores, sino que también alentaron a los usuarios ocasionales a experimentar con el sistema. El mercado de CD-ROM también creó un nuevo tipo de voluntario para el proyecto. Alguien tenía que descargar el último código del autor. Alguien tenía que mirar la lista de correo del kernel para ver cuándo Torvalds, Cox y el resto habían acuñado una nueva versión que fuera lo suficientemente estable como para lanzarla. Alguien necesitaba verificar todos los demás paquetes como GNU Emacs o GNU CC para asegurarse de que aún funcionaran correctamente. Esto no requirió el talento de programación obsesivo que creó el kernel, pero requirió algo de dedicación y devoción. Hoy en día, hay muchos tipos diferentes de voluntarios que elaboran estos paquetes. El grupo Debian, por ejemplo, es uno de los más conocidos y más dedicados a los verdaderos principios del código abierto. Fue iniciado por Ian Murdock, quien le puso su nombre y el de su novia, Debra. El grupo Debian, que ahora incluye cientos de miembros oficiales, verifica que el software sea técnicamente sólido y políticamente correcto. Es decir, verifican las licencias para asegurarse de que el software pueda ser distribuido libremente por todos los usuarios. Sus pautas luego se transformaron en la definición oficial de software de código abierto. Otros grupos de CD-ROM se volvieron más comerciales. Debian vendió sus discos para pagar las tarifas de conexión a Internet y otros gastos, pero en gran medida eran una operación de garaje. También lo fueron grupos con nombres como Slackware, FreeBSD y OpenBSD. Otros grupos como Red Hat realmente se propusieron crear un negocio floreciente y, en gran medida, lo lograron. Tomaron el dinero y lo usaron para pagar a los programadores que escribieron más software para hacer que Linux fuera más fácil de usar. Al principio, no había mucha diferencia entre los grupos de mentalidad comercial como Red Hat y los colectivos más idealistas como Debian. El mercado era pequeño, fragmentado y tribal. Pero en 1998, Red Hat había atraído importantes fondos de compañías como Intel, e invirtió más y más dinero para hacer que el paquete fuera lo más presentable y fácil de usar posible. Esta inversión valió la pena porque más usuarios recurrieron instintivamente a Red Hat, cuyas ventas de CD-ROM se dispararon. La mayor parte de este desarrollo vivió en su propio Shangri-La. Red Hat, por ejemplo, cobraba dinero por sus discos, pero publicaba todo su software bajo licencia GPL. Otros podían copiar sus discos gratis y muchos lo hicieron. Red Hat puede ser una empresa, pero la dirección se dio cuenta de que dependía de miles, si no millones, de voluntarios no remunerados para crear su producto. Lento pero seguro, más y más personas se dieron cuenta de Linux, el proyecto GNU y sus primos como FreeBSD. Nadie estaba ganando mucho dinero con las cosas, pero el boca a boca se estaba extendiendo muy rápidamente. Los discos tenían un precio razonable y la gente tenía curiosidad. La GPL animó a la gente a compartir. La gente empezó a pedir prestados discos a sus amigos. Algunas empresas incluso fabricaron copias baratas de los CD-ROM, un acto alentado por la GPL. En la cima de la pirámide estaba Linus Torvalds. Muchos desarrolladores de Linux lo trataron como el rey de todo lo que encuestó, pero él era como los monarcas que fueron despojados por una democracia constitucional popular. Siempre se había centrado en construir un kernel rápido y estable, y eso fue lo que siguió haciendo. El resto de la emoción, el empaque, las características y los juguetes fueron dominio de los voluntarios y colaboradores. Torvalds nunca dijo mucho sobre el mundo fuera de su núcleo, y se desarrolló sin él. Torvalds se mudó a Silicon Valley y tomó un trabajo con la compañía muy secreta Transmeta para ayudar a diseñar la próxima generación de chips de computadora. Hizo un trato especial con la compañía que le permitió trabajar en Linux en su tiempo libre. Sintió que trabajar para una de las compañías como Red Hat le daría a esa versión de Linux un imprimatur especial, y quería evitar eso. Además, Transmeta estaba haciendo cosas geniales. En enero de 1999, el mundo alcanzó a los pioneros. Schmalensee mencionó a Linux en el estrado de los testigos durante el juicio y notificó oficialmente al mundo que Microsoft estaba preocupado por el crecimiento de Linux. El sistema había estado en la pantalla de radar de la empresa durante algún tiempo. En octubre de 1998, un memorando interno de Microsoft que describía la amenaza llegó a la prensa. Algunos pensaron que era solo la forma de Microsoft de ganarse el favor durante la investigación antimonopolio. Otros pensaron que era un tratamiento serio de un tema que era difícil de entender para la empresa. Los medios siguieron el ejemplo de Schmalensee. Todos querían saber acerca de Linux, GNU, el software de código abierto y los efectos mágicos del intercambio generalizado e incondicional. Las preguntas llegaron en maremotos, y Torvalds trató de responderlas una y otra vez. ¿Se arrepintió de haberlo dado todo por la borda? No. Si cobrara algo, nadie habría comprado su juguete y nadie habría aportado nada. ¿Era comunista? No, era más bien apolítico. ¿Los programadores no tienen que comer? Sí, pero ganarán su dinero vendiendo un servicio en lugar de enriquecerse con un código propietario incorrecto. ¿Linux iba a superar a Microsoft? Sí, si se saliera con la suya. World Domination Pronto se convirtió en el lema. Pero también hubo preguntas difíciles. ¿Cómo resistiría el mundo Linux el abrazo de grandes empresas como IBM, Apple, Hewlett-Packard y tal vez incluso Microsoft? Estas eran empresas masivas con programadores pagados y horarios para cumplir. Todo el software de código abierto era tan gratuito para ellos como para cualquier otra persona. ¿Usarían estas empresas su fuerza para monopolizar Linux? A algunos les preocupaba que el dinero destrozara a la comunidad de código abierto. Es fácil lograr que todos donen su tiempo a un proyecto cuando nadie recibe un pago. El dinero cambia la ecuación. ¿Se desarrollaría un abismo entre las empresas ricas como Red Hat y los programadores pobres que simplemente regalaron su arduo trabajo? Muchos querían saber cuándo Linux sería más fácil de usar para los no programadores. Los programadores crearon el sistema operativo para que fuera fácil de desmontar y volver a montar. Esa es una gran característica si te gusta piratear el interior de un kernel, pero eso no entusiasma al usuario promedio de computadoras. ¿Cómo iba a lograr la comunidad de código abierto que los programadores donaran su tiempo para solucionar los problemas técnicos mundanos y cotidianos que confundían y enfurecían a los no programadores? ¿La comunidad de Linux iba a ser capaz de producir algo que un no programador pudiera siquiera entender? Otros se preguntaron si el mundo de Linux alguna vez podría estar lo suficientemente de acuerdo como para crear un paquete de software con cierta coherencia. Hoy en día, los usuarios y programadores de Microsoft se esfuerzan por mantener Windows 95, Windows 98 y Windows NT en orden. Pequeñas idiosincrasias hacen que los juegos se bloqueen y los programas fallen. Microsoft tiene cientos de ingenieros de control de calidad y miles de personal de soporte. Aún así, los pequeños detalles vuelven locos a todos. Las nuevas versiones de Linux aparecen tan a menudo como a diario. Las personas a menudo crean sus propias versiones para resolver problemas particulares. Muchos de estos cambios no afectarán a nadie, pero pueden sumarse. ¿Hay suficiente consistencia para que las herramientas sean lo suficientemente fáciles de usar? Muchos se preguntaron si Linux era adecuado para dominar el mundo. A los programadores les puede encantar jugar con el código fuente, pero el resto del mundo solo quiere algo que entregue el correo electrónico a tiempo. Más importante aún, estos últimos están dispuestos a pagar por esta eficiencia. Tales preguntas han estado molestando a la comunidad de código abierto durante años y todavía no tienen respuestas fáciles hoy en día. Los programadores necesitan comida y la comida requiere dinero. Hacer software fácil de usar requiere disciplina, y la disciplina no siempre está de acuerdo con la libertad total. Cuando la primera ola de publicidad sobre el software libre se extendió por el espíritu de la época, nadie quería concentrarse en estas preguntas difíciles. La alta calidad de los sistemas operativos gratuitos y su uso en sitios de alto perfil como Yahoo! era una buena noticia para el mundo. El éxito de la cooperación incondicional fue embriagador. Si el software libre pudiera hacer tanto con tan poco, podría superar las preguntas difíciles. Además, no tenía que ser perfecto. Solo necesitaba ser mejor que Microsoft. --------------------------------- 10. Libertad Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. La noción encarnada en la palabra "gratis" es uno de los grandes dispositivos de marketing de todos los tiempos. Los fabricantes de cereales saben que los niños se esforzarán a través de tazones de azúcar para obtener un premio gratis. Las tiendas saben que las personas gustosamente les darán sus nombres y direcciones si tienen la oportunidad de ganar algo gratis. A los anuncios de automóviles les encanta enfatizar la libertad que un automóvil nuevo le dará a alguien. Por supuesto, Microsoft también conoce este hecho. Una de sus grandes campañas publicitarias enfatiza la libertad de crear nuevos documentos, escribir novelas largas, jugar con fotografías y simplemente hacer lo que quieras con una computadora. "¿Dónde quieres ir hoy?" preguntan los anuncios de Microsoft. Microsoft también reconoce el poder puro de regalar algo. Cuando Bill Gates vio que el navegador de Netscape emergía como una gran amenaza competitiva, primero compró una versión de la competencia y luego escribió su propia versión de un navegador web. Microsoft regaló sus versiones de forma gratuita. Este movimiento audaz cerró el flujo de ingresos de Netscape, que tuvo que reducir su precio a cero para poder competir. Por supuesto, Netscape no tenía ingresos de un sistema operativo para pagar el alquiler. Netscape se quejó y, finalmente, el Departamento de Justicia presentó una demanda para decidir si el software gratuito de Microsoft era solo un complot para que más personas pagaran mucho dinero por su no tan gratuito sistema operativo Windows. El hecho de que Microsoft ahora esté amenazado por un grupo de personas que están regalando un sistema operativo gratuito tiene mucha ironía. La palabra "gratis" tiene un significado mucho más complicado y matizado dentro del movimiento del software libre. De hecho, a muchas personas que regalan su software ni siquiera les gusta la palabra "gratis" y prefieren usar "abierto" para describir el proceso de compartir. En el caso del software libre, no se trata simplemente de una campaña publicitaria para que la gente se sienta bien con la compra de un producto. Tampoco es un hábil juego de manos de marketing para centrar la atención de la gente en un obsequio mientras el mago cobra el precio completo por un producto. La palabra "gratis" se refiere más a una forma de vida. Las personas que escriben el código lanzan la palabra de la misma manera que la usaron los Padres Fundadores de los Estados Unidos. Para muchos de ellos, la revolución del software libre también fue concebida en libertad y dedicada a ciertos principios como el hecho de que todos los hombres y mujeres tienen ciertos derechos inalienables de cambiar, modificar y hacer lo que qu ieran con su software en la búsqueda de la felicidad. Lanzar sobre la palabra "gratis" es fácil de hacer. Definir lo que significa lleva mucho más tiempo. La Declaración de Independencia se redactó en 1776, pero los gobiernos coloniales lucharon y se esforzaron por crear un gobierno libre mediante la ratificación de la actual Constitución de los Estados Unidos en 1787. La Declaración de Derechos llegó poco después, y la Corte Suprema sigue luchando continuamente con definiendo los límites de libertad descritos por el documento. Se podría decir que gran parte de la historia política de los Estados Unidos es un argumento extenso sobre el significado de las palabras "país libre". El movimiento del software libre no es diferente. Es fácil para una persona regalar su software de forma gratuita. Es mucho más difícil atraer y organizar un ejército para enfrentarse a Microsoft y dominar el mundo. Eso requiere una definición adecuada de la palabra "libre" para que todos entiendan los derechos y limitaciones detrás de la palabra. Todos deben estar en la misma página si se quiere ganar la batalla. Todo el mundo necesita entender lo que significa "software libre". La historia del mundo del software libre también está llena de argumentos extensos que definen la libertad que viene con el código fuente. Muchos se preguntan si se trata más de darle algo a cambio de nada al usuario, o si se trata de empoderarlo. ¿Esta libertad viene con alguna responsabilidad? ¿Cuáles deberían ser? ¿Cómo se ejerce la libertad? ¿Es el aprovechamiento gratuito una parte adecuada de la libertad? En los primeros años de las computadoras, no había argumentos reales. El software era gratuito porque la gente simplemente lo compartía entre sí. Revistas como Creative Computing y BYTE publicaron el código fuente de los programas porque era una manera fácil de compartir información. La gente incluso escribiría los datos ellos mismos. Las computadoras cuestan dinero y lograr que funcionen era parte del desafío. Compartir software era solo parte de la buena vecindad. Si alguien necesitaba pedir prestado tu arado, se lo prestabas cuando no lo estabas usando. Esto cambió cuando las corporaciones reconocieron que podían proteger el software con derechos de autor y comenzar a cobrar dinero por él. A la mayoría de la gente le encantó este arreglo porque la competencia trajo nuevos paquetes y herramientas al mercado y la gente estaba más que dispuesta a pagar por ellos. ¿De qué otra manera van a comer los programadores y los escritores de manuales? Algunas personas pensaron que esto era un desastre. Richard Stallman vio cómo cambiaba el mundo desde su oficina en los laboratorios de inteligencia artificial del MIT. Stallman es el mejor hacker, si usa la palabra en el sentido clásico. Al principio, la palabra solo describía a alguien que sabe programar bien y le encanta hurgar en el interior de las computadoras. Solo tomó su tono más malicioso más tarde, cuando los medios lograron agrupar a todos aquellos con la capacidad de manipular computadoras en el mismo campo peligroso. Los piratas suelen utilizar el término "cracker" para referirse a estas personas. Stallman es un modelo del hacker. Es estridente, súper inteligente, muy lógico y completamente honesto. La mayoría de las corporaciones mantienen a sus hackers encerrados en un cuarto trasero porque estos rasgos parecen ahuyentar a los clientes e inversores que solo quieren dulces mentiras en sus oídos. Stallman nunca fue ese tipo de persona. Observó el floreciente control corporativo del software y no le gustó ni un poco. Su libertad se estaba reduciendo lentamente, y él no era del tipo que simplemente se sentaba y no decía nada. Cuando Stallman dejó el laboratorio de IA en 1984, no quería ser controlado por sus políticas. Las universidades comenzaron a adoptar muchas de las mismas prácticas que las corporaciones en la década de 1980, y Stallman no podía ser una excepción especial. Si el MIT iba a pagarle un salario, el MIT sería dueño de su código y de las patentes que surgieran de él. Incluso el MIT, que es un lugar mucho más genial que la mayoría, no pudo acomodarlo en el personal. No se fue muy lejos, sin embargo, porque después de establecer la Free Software Foundation, mantuvo una oficina en el MIT, primero extraoficialmente y luego oficialmente. Una vez que no estaba "en el personal", las reglas se volvieron diferentes. Stallman recurrió a la consultoría por dinero, pero era una consultoría con un giro. Solo trabajaría para empresas que no pusieran restricciones al software que creó. Esto no fue una venta fácil. Insistía en que cualquier trabajo que hiciera para la Corporación X también podría compartirse con las Corporaciones Y y Z, incluso si fueran competidores directos. No era así como se hacían las cosas en la década de 1980. Esa fue la década en que las empresas descubrieron cómo bloquear el código fuente en un programa distribuyendo solo una versión legible por máquina. Esperaban que esto controlaría su producto y les permitiría restringir a las personas que podrían intentar robar sus ideas y su propiedad intelectual. Stallman pensó que estaba cerrando su capacidad para hurgar dentro de la computadora y arreglarla. Este secreto le impidió compartir sus pensamientos e ideas con otros programadores. La mayoría de los programadores vieron el esquema de cobrar por las versiones binarias bloqueadas de un programa como un mal necesario. Claro, no podían jugar con las entrañas de Microsoft Windows, pero también significaba que nadie podía jugar con las entrañas de los programas que escribieron. El esquema cerró puertas y compartimentó el mundo, pero también le dio más poder al creador de programas. La mayoría de los programadores pensaban que tener poder sobre su propia creación era bastante bueno, incluso si otros tenían más poder. Estar desarmado está bien si todos los demás están desarmados y encerrados en una jaula. Stallman pensó que esto era un desastre para el mundo y se dispuso a convencer al mundo de que tenía razón. En 1984, escribió el Manifiesto GNU, que inició su proyecto GNU y estableció las condiciones para su revolución. Este documento se destacó un poco en medio de la era de Ronald Reagan porque expuso el plan de Stallman para crear una comuna virtual donde las personas serían libres de usar el software. Es uno de los primeros casos en que alguien intentó establecer una definición de la palabra "gratis" para los usuarios de software. Claro, el software y las ideas eran bastante gratuitos hace mucho tiempo, pero nadie se dio cuenta hasta que desapareció la libertad. El escribio, Considero que la regla de oro exige que si me gusta un programa debo compartirlo con otras personas a las que les guste. Los vendedores de software quieren dividir a los usuarios y conquistarlos, haciendo que cada usuario acepte no compartir con los demás. Me niego a romper la solidaridad con otros usuarios de esta manera... Para poder seguir usando las computadoras sin deshonra, he decidido reunir un cuerpo suficiente de software libre para poder vivir sin ningún software. eso no es gratis. El documento es un vistazo maravilloso al naciente mundo del software libre porque es tanto un documento de reclutamiento como una diatriba dirigida a las prácticas comerciales corporativas. Cuando las colonias americanas se separaron de Inglaterra, Thomas Paine explicó los problemas de los ingleses en el primer párrafo de su folleto "Sentido común". En su manifiesto, Stallman no comenzó a usar palabras como "deshonra" hasta el sexto párrafo. Los primeros párrafos detallaron las geniales herramientas que ya había desarrollado: "un editor de texto Emacs con Lisp para escribir comandos de edición, un depurador de nivel fuente, un generador de analizador compatible con yacc, un enlazador y alrededor de 35 utilidades". Luego señaló el trabajo que quería completar pronto: "Se ha compilado un nuevo compilador de C optimizador portátil y puede lanzarse este año. Existe un núcleo inicial, pero se necesitan muchas más funciones para emular Unix". Decía, en efecto, que ya tenía unos jugosos melocoton es creciendo en los árboles de su comuna. Si esto no fuera suficiente, tenía la intención de hacer las cosas un poco mejor que UNIX. Su sistema operativo iba a ofrecer las últimas y mejores ideas de la informática, alrededor de 1984. "En particular, planeamos tener nombres de archivo más largos, números de versión de archivo, un sistema de archivos a prueba de fallas, finalización de nombre de archivo tal vez, soporte de visualización independiente de terminal , y quizás eventualmente un sistema de ventanas basado en Lisp a través del cual varios programas Lisp y programas ordinarios de Unix puedan compartir una pantalla". Lo único que faltaba en la lista de deseos de todos los nerds de las computadoras era un lugar secreto para atracar submarinos en la gruta del sótano. El quinto párrafo incluso explicaba a todos que el nombre del proyecto sería el acrónimo GNU, que significaba "GNU's Not UNIX", y debería pronunciarse con una G fuerte para asegurarse de que nadie lo confundiera con la palabra "nuevo." Stallman siempre se ha preocupado por las palabras, la forma en que se usan y la forma en que se pronuncian. En 1984, UNIX se convirtió en el foco de la animosidad de Stallman porque su desarrollador original, AT&T, estaba presionando para tratar de recuperar algo de dinero después de pagarle a tanta gente en Bell Labs para crearlo. La mayoría de la gente estaba un poco en conflicto por la pelea. Entendieron que AT&T había pagado un buen dinero y apoyado a muchos investigadores con la beneficencia de la empresa. La empresa dio dinero, tiempo y computadoras de repuesto. Claro, fue un fastidio pagar a AT&T por algo y obtener solo una licencia larga redactada por equipos de abogados. Sí, sería bueno si pudiéramos hurgar bajo el capó de UNIX sin firmar un acuerdo de confidencialidad. Sería bueno si pudiéramos ser libres de hacer lo que queramos, pero ciertamente alguien que paga por algo merece el derecho de decidir cómo se usa. Todos tenemos que comer. Stallman no estaba confundido en absoluto. Licencias como la de AT&T restringirían su libertad para compartir con otros. Para empeorar las cosas, las empresas de software querían que él pagara por el privilegio de obtener software sin el código fuente. Stallman explica que sus sentimientos no estaban enfocados en AT&T per se. Las empresas de software estaban surgiendo por todas partes, y la mayoría de ellas bloqueaban su código fuente con licencias propietarias. Era lo típico de los 80, como escuchar música de Duran Duran y Boy George. "Cuando decidí escribir un sistema operativo gratuito, no tenía en mente a AT&T, porque nunca había tenido ningún trato con ellos. Nunca había usado un sistema UNIX. Eran solo una de las muchas compañías que hacían lo mismo. cosa", me dijo recientemente. "Elegí un diseño similar a Unix simplemente porque pensé que era un buen diseño para el trabajo, no porque tuviera sentimientos particulares sobre AT&T". Cuando escribió el Manifiesto GNU, le dejó claro al mundo que su proyecto se trataba más de elegir el camino moral correcto que de ahorrar dinero. Escribió entonces que el proyecto GNU significa "mucho más que simplemente ahorrarles a todos el precio de una licencia de UNIX. Significa que se evitará una duplicación inútil del esfuerzo de programación del sistema. Este esfuerzo puede ir en cambio hacia el avance del estado del arte". Este fue un punto crucial que evitó que Stallman fuera descartado como un chiflado casi comunista que solo quería que todos vivieran felices en una comuna de nerds. El código fuente es una herramienta valiosa para todos porque es legible por humanos, o al menos por humanos que son buenos programando. Las empresas aprendieron a mantener el código fuente en propiedad, y se convirtió casi en un reflejo. Si la gente quisiera usarlo, debería pagar para ayudar a sufragar el costo de crearlo. Esto tenía sentido para los programadores que querían ganarse la vida o incluso enriquecerse escribiendo su propio código. Pero a veces era terriblemente frustrante. Muchos programadores se han tirado de los pelos de dolor cuando su trabajo fue detenido por algún error o característica no documentada enterrada profundamente en el software patentado y supersecreto creado por Microsoft, IBM, Apple o quien sea. Si tuvieran el código fuente, podrían hurgar y descubrir qué estaba sucediendo realmente. En su lugar, ten ían que tratar el software como una caja negra y seguir probándolo con programas de prueba que podrían revelar los secretos ocultos en su interior. Todos los programadores han tenido una experiencia como esta, y todos los programadores sabían que podían resolver el problema mucho más rápido si solo podían leer el código fuente. No querían robar nada, solo querían saber qué estaba pasando para poder hacer que su propio código funcionara. El proyecto GNU de Stallman sería diferente, y explicó: "Las fuentes completas del sistema estarán disponibles para todos. Como resultado, un usuario que necesite cambios en el sistema siempre tendrá la libertad de hacerlos él mismo o contratar a cualquier programador o empresa disponible para hacerlo". hazlos para él. Los usuarios ya no estarán a merced de un programador o empresa que posee las fuentes y está en posición exclusiva para realizar cambios ". Se apresuró a mencionar que la gente sería "libre de contratar a cualquier programador disponible" para asegurarse de que la gente entendiera que no estaba en contra de aceptar dinero por escribir software. Eso estaba bien y era algo que él mismo hacía con frecuencia. Estaba en contra de que las personas controlaran la fuente con barreras legales arbitrariamente complejas que hacían imposible que él o cualquier otra persona hiciera algo. Cuando la gente escuchó por primera vez sus ideas, se obsesionaron con la palabra "gratis". Estos fueron los años de Reagan. Decir que la gente debería simplemente dar su arduo trabajo sonaba muy comunista para todos, y esto fue mucho antes de que cayera el Muro de Berlín. Stallman volvió a examinar la palabra "gratis" y todos sus diferentes significados. Consideró cuidadosamente todas las diferentes connotaciones, examinó las alternativas y decidió que "gratis" seguía siendo la mejor palabra. Empezó a tratar de explicar los matices de significado que buscaba. Su revolución se trataba de la "libertad de expresión", no de la "cerveza gratis". Esto no iba a ser una revolución en el sentido de que las millas de viajero frecuente revolucionaron los viajes aéreos ni en la forma en que las latas de aluminio revolucionaron el consumo de cerveza. No, esto iba a ser una revolución como Rousseau, Locke y Paine usaron la palabra. Más tarde codificó esto en cuatro principios principales: La libertad de ejecutar el programa, para cualquier propósito (libertad 0).[^6] [6]: Los numeró empezando por cero porque eso era lo que hacían los informáticos. Alguien descubrió que era más sencillo comenzar a numerar las bases de datos desde cero porque no tenía que restar 1 con tanta frecuencia. La libertad de estudiar cómo funciona el programa y adaptarlo a tus necesidades (libertad 1). La libertad de redistribuir copias para que puedas ayudar a tu prójimo (libertad 2). La libertad de mejorar el programa y lanzar sus mejoras al público, para que toda la comunidad se beneficie (libertad 3). 10.1 Cerveza gratis Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Si bien Stallman alejó a la gente de la noción de "cerveza gratis", no hay duda de que este elemento resultó ser una parte muy importante de la estrategia y la base de su éxito. Stallman insistió en que cualquiera podía hacer lo que quisiera con el software, por lo que insistió en que el código fuente debía distribuirse libremente. Es decir, nadie podría poner restricciones sobre cómo usaste el software. Si bien esto no hizo que la cerveza fuera gratis, sí significó que podía dar la vuelta y dar una copia a sus amigos o clientes. estuvo bastante cerca. La naturaleza de "cerveza gratis" del software de Stallman también atrajo a los usuarios. Si algunos programadores quisieran probar una nueva herramienta, podrían descargarla y probarla sin pagar por ella. No necesitaban pedirle un presupuesto a su jefe, y no necesitaban encontrar una manera de lidiar con una factura. Solo un clic y el software estaba allí. Las empresas de software comercial continúan imitando esta función mediante la distribución de versiones de prueba que vienen con algunas funciones inhabilitadas o un bloqueo de tiempo que las apaga después de unos días. Por supuesto, la naturaleza de "cerveza gratis" del proyecto GNU pronto condujo a problemas de dinero. El proyecto GNU tomó su tiempo y no generó ingresos reales al principio. Stallman siempre había vivido frugalmente. Dice que nunca ganó más de $ 20,000 al año en el MIT y aún así logró ahorrar en ese salario. Pero cada vez le resultaba más difícil realizar los trabajos asignados en el MIT y escribir el genial código GNU. Si bien Stallman siempre apoyó el derecho de un programador a ganar dinero por escribir código, el proyecto GNU no estaba generando dinero. La mayoría de la gente vio que este conflicto venía desde el principio. Claro, Stallman sería capaz de despotricar y delirar sobre el desarrollo de software corporativo por un rato, pero eventualmente él y sus discípulos necesitarían comer. Cuando terminó el soporte del MIT, Stallman pronto se topó con un hecho sorprendente: podía cobrar por el software que estaba regalando y ganar algo de dinero. A la gente le encantaba su software, pero a menudo era difícil hacer un seguimiento de él. Obtener el paquete entregado en cinta de computadora o en CD-ROM les dio a las personas una copia impresa que podían almacenar para futuras referencias o copias de seguridad. Los manuales en línea también estaban bien, pero el libro impreso sigue siendo una forma muy popular y fácil de usar de almacenar información. La Free Software Foundation de Stallman comenzó a vender manuales impresos, cintas y luego CD-ROM llenos de software para ganar dinero. Sorprendentemente, la gente comenzó a pagar dinero por estas versiones a pesar de que podían descargar las mismas versiones de forma gratuita. Algunas personas disfrutaron señalando la hipocresía en el movimiento de Stallman. Stallman había hablado tanto tiempo que muchos programadores "vendidos" que trabajaban para corporaciones saborearon la ironía. Por fin ese weenie había captado la imagen. Se vio obligado a ganar dinero para mantenerse, y también se estaba vendiendo. Estos cínicos no entendieron lo que Stallman estaba tratando de hacer. La mayoría de nosotros nos habríamos dado por vencidos en este momento. Lo del software libre parecía una buena idea, pero ahora que el dinero se estaba acabando era el momento de conseguir un trabajo de verdad. Al escribir este libro y entrevistar a algunos de los desarrolladores de software libre famosos y no tan famosos, descubrí que algunos estaban involucrados en el desarrollo de software no tan libre con fines de lucro ahora. Stallman, sin embargo, no iba a renunciar a sus ideales, y su mente comenzó a cambiar para adaptarse a esta nueva medida de la realidad. Decidió que no estaría mal vender copias de software o incluso servicios de software siempre y cuando no retuvieras el código fuente y pisotearas la libertad de cualquier persona para usar el código fuente como quisiera. Stallman siempre ha sido excelente para dividir los pelos y crear distinciones jesuíticas, y esta idea fue una de las mejores. A primera vista, parecía un poco chiflado. Si las personas fueran libres de hacer lo que quisieran con el software, podrían simplemente darle una copia a su amigo y su amigo nunca devolvería dinero a la Fundación de Software Libre de Stallman. De hecho, alguien podría comprar una copia de Stallman y luego comenzar a revender copias a otros para socavar a Stallman. La Free Software Foundation y la GNU GPL les dieron la libertad de hacerlo. Era como si un cine vendiera boletos para una película, pero también colocara un gran cartel cerca de la puerta de salida que decía "Oye, está absolutamente bien que dejes esto abierto para que tus amigos puedan colarse sin pagar". Si bien esta libertad total confundió a la mayoría de las personas, no fracasó. Muchos pagaron por cintas o versiones en CD-ROM porque querían la comodidad. Las versiones de Stallman venían con las últimas correcciones de errores y nuevas características. Eran las versiones casi oficiales. Otros sintieron que pagar ayudó a mantener el trabajo, por lo que no se sintieron mal por hacerlo. Les gustó la FSF y querían que produjera más código. A otros simplemente les gustaban más los libros impresos que la documentación electrónica. Comprarlos de Stallman era más barato que imprimirlos. Otros pagaron por los CD-ROM porque solo querían apoyar a la Free Software Foundation. Stallman también encontró otro apoyo. La Fundación MacArthur le dio una de sus subvenciones geniales que le pagaron un buen salario durante cinco años para hacer lo que quisiera. Empresas como Intel lo contrataron como consultor y le pidieron que se asegurara de que parte de su software se ejecutara en chips Intel. La gente estaba bastante dispuesta a pagar por la comodidad porque incluso el software libre no hacía todo lo que debería. Stallman también reconoció que esta libertad introdujo una medida de competencia. Si él podía cobrar por las copias, entonces también podrían hacerlo los demás. El código fuente sería un gran bien común, pero los medios para entregarlo estarían llenos de personas que luchan por hacer el mejor trabajo de distribución del software. Era una noción de Reaganaut bastante dura para un comunista reputado. Al principio, pocos se molestaron en competir con él, pero con el tiempo todo el código GNU comenzó a incluirse en los sistemas operativos de las computadoras. Cuando Linus Torvalds escribió su sistema operativo, el código GNU estaba listo para ser incluido. 10.2 Copia izquierda Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Si la primera gran idea de Stallman fue que el mundo no necesitaba tolerar el código fuente propietario, la segunda fue que podía controlar estrictamente el uso del software GNU con un documento legal innovador titulado GNU General Public License, o GPL. Para ilustrar la diferencia, llamó al acuerdo "copyleft" y se dispuso a crear un documento legal que definiera lo que significaba que el software fuera "libre". Bueno, definiendo lo que pensaba que debería significar. La GPL era un documento legal cuidadosamente elaborado que no colocaba el software en el "dominio público", una designación que habría permitido a las personas hacer realmente lo que quisieran con el software. La licencia, de hecho, registró los derechos de autor del software y luego extendió a los usuarios derechos muy liberales para hacer innumerables copias siempre que los usuarios no dañaran los derechos de otras personas para usar el software. La definición de pisar los derechos de otras personas es la que mantiene en funcionamiento a los departamentos de ciencias políticas de las universidades. Hay muchos electores que enmarcan sus argumentos en términos de proteger los derechos de alguien. Stallman vio la protección de los derechos de otros usuarios en términos muy fuertes y fortaleció un poco su control al insertar una cláusula controvertida. Insistió en que quien distribuya una versión mejorada del programa también debe compartir el código fuente. Eso significaba que alguna empresa codiciosa no podía descargar su editor GNU Emacs, agregar algunas características nuevas y luego vender el paquete completo sin incluir todo el código fuente que crearon. Si la gente se iba a beneficiar del uso compartido de GNU, tendrían que volver a compartir. Era la libertad con un precio. Este compacto fuerte estaba listo para algunos momentos irónicos. Cuando Apple comenzó a tratar de ampliar el alcance de las leyes de propiedad intelectual al demandar a empresas como Microsoft por robar su "apariencia", Stallman se indignó y decidió que no desarrollaría software para las máquinas de Apple como una forma de protesta y despecho. Si Apple iba a contaminar el panorama legal con terribles impedimentos para compartir ideas, entonces Stallman no iba a ayudarlos a vender máquinas escribiendo software para las máquinas. Pero la licencia copyleft de GNU permitía específicamente que cualquier persona distribuyera libremente el código fuente y lo usara como quisiera. Eso significaba que otros podían usar el código GNU y convertirlo para que se ejecutara en Apple si así lo deseaban. Muchos portaron gran parte del software GNU a Mac y distribuyeron el código fuente con él para cumplir con la licencia. Stallman no pudo hacer nada al respecto. Claro, él era el gran líder de la FSF y el au tor de parte de su código, pero había cedido su poder con la licencia. Lo único que podía hacer era negarse a ayudar a la gente a trasladar el software a la Mac. Cuando se trataba de principios, colocó la libertad de usar el código fuente en la parte superior de la jerarquía. 10.3 El virus GNU Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Algunos programadores pronto comenzaron a referirse a la naturaleza pegajosa de la licencia como el "virus GNU" porque infectaba los proyectos de software con su error de libertad. Si un desarrollador quería ahorrar tiempo y obtener algo del software GNU, estaba atascado haciendo que el resto de su trabajo fuera igual de gratuito. Estas esposas doradas a menudo asustaban a los programadores que querían ganar dinero cobrando por su trabajo. Stallman odia esa caracterización. "Llamar a algo 'como un virus' es algo muy vicioso. Las personas que dicen cosas como esa están tratando de encontrar formas de hacer que la GPL se vea mal", dice. Stallman intentó solucionar este problema creando lo que al principio llamó "Licencia pública general de biblioteca" y ahora se refiere como "Licencia pública general menor", un documento que permitía a los desarrolladores de software compartir pequeños fragmentos de código entre sí. en circunstancias menos restrictivas. Un programador puede usar LGPL para vincular fragmentos de código conocidos como bibliotecas. Otros pueden compartir las bibliotecas y usarlas con su código fuente siempre que no las integren por completo. Cualquier cambio que realicen en la biblioteca en sí debe hacerse público, pero no hay ningún requisito para publicar el código fuente del programa principal que usa la biblioteca. Esta licencia es esencialmente una concesión a algunas asperezas en las esquinas donde el mundo de la programación se une al mundo de la ley. Si bien Stallman estaba empeñado en crear una colección perfecta de programas gratuitos que resolvieran las necesidades de todos, estaba lejos de haber terminado. Si la gente iba a usar su software, tendría que usarlo en máquinas fabricadas por Sun, AT&T, IBM o cualquier otra persona que vendiera un sistema operativo propietario junto con él. Entendió que necesitaba comprometerse, al menos para las bibliotecas del sistema. El problema es trazar límites entre lo que es una pila de software propiedad de una persona y lo que es otra pila propiedad de otra persona. La GPL garantizó que el software GNU "infectaría" otros paquetes y obligaría a las personas que usaron su código a unirse a la fiesta y liberar el suyo también. Así que tuvo que idear una definición que explicara lo que significaba para las personas usar su código e "incorporarlo" a otros. Esto es a menudo más fácil decirlo que hacerlo. El mercado ha desarrollado formas de vender software en grandes cantidades a las personas, pero estas son ficciones que camuflan la integración del software. En la práctica moderna, los programadores no solo crean una porción de software fácilmente distinguible conocida como Microsoft Word o Adobe Photoshop. Construyen una variedad de fragmentos más pequeños conocidos como bibliotecas y los vinculan entre sí. Microsoft Windows, de hecho, incluye una gran colección de bibliotecas para crear menús, formularios, áreas de clic y todo lo demás que hacen las interfaces gráficas de usuario. Los programadores no necesitan escribir sus propias instrucciones para dibujarlas en la pantalla e interactuar con ellas. Esto ahorra mucho tiempo y práctica a los programadores, y es una gran parte de lo que Microsoft vende cuando le vende a alguien una caja con Windows. Stallman reconoció que los programadores a veces escribieron bibliotecas que querían que otros usaran. Después de todo, ese era el objetivo de GNU: crear herramientas que otros pudieran usar libremente. Así que Stallman cedió y creó la Licencia Pública Menor, que permitiría a las personas crear bibliotecas que podrían incorporarse a otros programas que no fueran completamente GNU. La biblioteca en sí aún venía con el código fuente y el usuario tendría que distribuir todos los cambios realizados en la biblioteca, pero no había limitación en el paquete más grande. Esta nueva licencia también fue una especie de concesión a la realidad. En el sentido más abstracto, los programas son simplemente cajas negras que toman alguna entrada y producen alguna salida. No hay límite para las jerarquías que se pueden crear conectando estas casillas para que la salida de una sea la entrada de otra. Eventualmente, el bosque de conexiones se vuelve tan denso que es difícil trazar una línea y etiquetar una colección de cajas "ProprietarySoft's SUX-2000" y otra colección "GNUSoft's Wombat 3.14.15". Las conexiones son tan numerosas en un software efectivo y bien escrito que el trazado de líneas es difícil. El problema es similar al que enfrentan los biólogos cuando intentan definir ecosistemas y especies. Algunos dicen que hay dos grupos diferentes de atunes que nadan en el Atlántico. Otros dicen que sólo hay uno. La distinción se dejaría a los académicos si no afectara las leyes internacionales sobre pesca. Algunos grupos que impulsan la visión de una escuela están preocupados de que otros al otro lado del océano estén capturando sus peces. Otros impulsan la teoría de las dos escuelas para minimizar la intromisión de la burocracia del otro lado. Sin embargo, nadie sabe cómo trazar una buena línea. La LGPL de Stallman fue una concesión al hecho de que a veces los programas se pueden usar como bibliotecas y otras veces las bibliotecas se pueden usar como programas. Al final, el programador puede trazar una línea clara alrededor de un conjunto de cajas y decir que la GPL cubre estas funciones sin filtrarse para infectar el software que se vincula con las cajas negras. 10.4 ¿Está la Free Software Foundation en contra de la libertad? Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Aún así, estas concesiones no son suficientes para algunas personas. Muchos continúan protestando contra la definición de libertad de Stallman y caracterizan la GPL como un documento fascista que roba los derechos de cualquier programador que venga después. Ser libre significa tener derecho a hacer lo que quieras con el código, incluso mantener todas tus modificaciones privadas. Para ser justos, la GPL nunca lo obliga a revelar sus cambios en el código fuente. Simplemente te obliga a liberar tus modificaciones si las redistribuyes. Si solo ejecuta su propia versión en su hogar, entonces no necesita compartir nada. Sin embargo, cuando comienza a compartir versiones binarias del software, también debe enviar el código fuente. Algunos argumentan que las corporaciones tienen el potencial de solucionar este vacío legal porque actúan como una sola persona. Una empresa podría revisar el software y "enviarlo" simplemente contratando a cualquiera que quisiera comprarlo. Los nuevos empleados o miembros de la corporación tendrían acceso al software sin enviar la fuente. El código fuente nunca se distribuiría porque no se envió públicamente. Nadie cree seriamente que alguien intente explotar esta disposición con una interpretación tan extrema, pero abre la pregunta de si alguna vez se puede crear una licencia hermética. Estas sutiles distinciones no satisficieron a muchos programadores que no estaban tan entusiasmados con la versión doctrinaria de la libertad de Stallman. Querían crear software libre y tener la libertad de ganar algo de dinero con él. Esta tradición se remonta a muchos años antes de Stallman y es una parte firme de la vida académica. Muchos profesores y estudiantes desarrollaron software y publicaron una versión gratuita antes de iniciar una empresa que comercializaría el trabajo. Usaron el salario de su profesor o el estipendio de estudiante para apoyar el trabajo, y el software libre que contribuyeron al mundo fue pensado como un intercambio. En muchos casos, el gobierno de EE. UU. pagó la creación del software a través de una subvención y el lanzamiento gratuito fue un regalo para los contribuyentes que finalmente lo financiaron. En otros casos, las corporaciones pagaron por partes de la investigación y la publicación gratuita se vio como una forma de devolver algo a la corporación patroci nadora sin convertir la universidad en un hogar para los programadores esclavos mal pagados de la corporación que eran estudiantes solo de nombre. En muchos casos, la distribución gratuita fue un regalo honesto de investigadores que querían dar a su trabajo la mayor difusión posible. Serían recompensados ​​con fama y prestigio académico, lo que puede ser más lucrativo que cualquier cosa menos una buena oferta pública inicial. Compartir conocimientos y crear más de ellos era de lo que se trataban las universidades. Stallman aprovechó esa tradición. Pero muchos otros eran bastante cínicos. Trabajarían el tiempo suficiente para generar una versión que funcionara lo suficientemente bien como para convencer a la gente de su valor. Luego, cuando apareciera la financiación, lanzarían esta versión con errores al "dominio público", cruzarían la calle hacia su propia nueva empresa y reanudarían el desarrollo. La versión de dominio público cumplía con las reglas de la universidad y apaciguaba a las agencias de subvenciones, pero a menudo era casi inutilizable. Los errores eran demasiado numerosos y estaban demasiado escondidos en la cruft para que valiera la pena el tiempo de alguien. Por supuesto, los autores originales sabían dónde acechaban los problemas y los solucionarían antes de lanzar la versión comercial. El líder de esta rama académica del mundo del software libre se convirtió en el Grupo de Investigación de Sistemas Informáticos de la Universidad de California en Berkeley. Las versiones publicadas de Berkeley Software Distribution (BSD) de UNIX comenzaron a surgir en Berkeley a fines de la década de 1970. Su trabajo surgió con una licencia gratuita que otorgaba a todos el derecho de hacer lo que quisieran con el software, incluida la creación de una empresa, agregar algunas funciones interesantes y comenzar a revender el paquete completo. El único problema era que el usuario debía mantener intacto el mensaje de derechos de autor y dar crédito a la universidad en el manual y en los anuncios. Este requisito se relajó en 1999 cuando la lista de personas que necesitaban crédito en proyectos de software creció demasiado. Muchos grupos tomaron la licencia BSD y simplemente reemplazaron las palabras "Universidad de California" con su nombre. La lista de personas que necesitaban ser reconocidas públi camente crecía con cada nuevo proyecto. A medida que las distribuciones crecieron para incluir todos estos nuevos proyectos, el proceso de enumerar todos los nombres y proyectos se volvió oneroso. La Universidad de California eliminó la cláusula que requería crédito publicitario con la esperanza de dar un ejemplo que otros pudieran seguir. Hoy en día, muchos proyectos de software libre comienzan con un debate de "GNU versus BSD" cuando los fundadores iniciales discuten si es una buena idea restringir lo que los usuarios pueden hacer con el código. El lado de GNU siempre cree que los programadores deberían verse obligados a donar el código que desarrollan al mundo, mientras que el lado de BSD presiona por una libertad prácticamente ilimitada. Rick Rashid es una de las principales fuerzas detrás del desarrollo de Windows NT de Microsoft y también un importante contribuyente a nuestro conocimiento sobre cómo construir un sistema operativo de computadora. Antes de ir a Microsoft, fue profesor en Carnegie-Mellon. Mientras estuvo allí, encabezó el equipo responsable del desarrollo de Mach, un sistema operativo que ofrecía funciones multitarea relativamente fáciles de usar basadas en un kernel muy pequeño. Mach permitió a los programadores dividir su software en múltiples "hilos" que podrían ejecutarse de forma independiente mientras compartían el mismo acceso a los datos. Cuando se le preguntó recientemente sobre Mach y la licencia de Mach, explicó que deliberadamente escribió la licencia para que fuera lo más libre posible. En su opinión, la GPL de GNU no era apropiada para la tecnología que se desarrollaba en gran medida con subvenciones del gobierno. El trabajo debe ser lo más libre posible y no debe obligar a "otras personas a hacer cosas (por ejemplo, regalar su trabajo personal) para tener acceso a lo que ha hecho". Dijo, en una entrevista por correo electrónico: "Mi intención era alentar el uso del sistema tanto para uso académico como comercial y se usó mucho en ambos entornos. Accent, el predecesor de Mach, ya había sido comercializado y utilizado por una variedad de compañías Mach continúa siendo muy utilizado hoy en día, tanto como base para el nuevo MacOS de Apple como para variantes de Unix en el mercado (por ejemplo, Unix de 64 bits de Compaq para Alpha)". 10.5 La evolución de BSD Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. La licencia BSD evolucionó a lo largo de un extraño camino legal que se parecía más al deambular de una vaca borracha que a la devoción láser de Stallman. Muchos profesores y estudiantes experimentaron con UNIX en DEC Vaxes que se comunicaban con viejos teletipos y terminales tontas. AT&T le dio a Berkeley el código fuente de UNIX, y esto permitió a los estudiantes y profesores agregar sus instrucciones y funciones al software. Gran parte de su conocimiento sobre el diseño del sistema operativo y muchas de sus correcciones de errores regresaron a AT&T, donde se incorporaron en las próximas versiones de UNIX. Nadie pensó dos veces en que el código fuente estuviera disponible porque el mercado de software empaquetado aún estaba en pañales. El mercado de las computadoras personales ni siquiera nació hasta la segunda mitad de la década de 1970, y la gente tardó algún tiempo en creer que el código fuente era algo que una empresa debía retener y proteger. De hecho, muchos de los programas aún no estaban escritos en lenguajes de alto nivel. Los programadores escribían instrucciones directamente para la computadora, y aunque a menudo incluían algunas instrucciones para humanos, había poca diferencia entre lo que escribían los humanos y lo que leía la máquina. Después de que Bill Joy y otros en Berkeley comenzaron a crear varias piezas de software buenas, otras universidades comenzaron a pedir copias. En ese momento, recuerda Joy, se consideraba un poco desagradable que los investigadores de informática escribieran software y lo compartieran con otros. Los departamentos académicos estaban llenos de muchos profesores que recibieron su formación formal en matemáticas, y tenían la actitud de que las pruebas y análisis formales rigurosos eran la forma ideal de investigación. Joy y varios otros estudiantes comenzaron a rebelarse argumentando que la creación de sistemas operativos funcionales era una investigación experimental esencial. Los departamentos de física apoyaron a los experimentalistas y teóricos. Entonces Joy comenzó a "publicar" su código enviando copias a otros investigadores que lo querían. Aunque muchos profesores y estudiantes de Berkeley agregaron fragmentos al software que se ejecuta en los DEC Vaxes, Joy fue quien lo juntó todo y le dio el nombre. Kirk McKusick dice en su historia de Berkeley UNIX, "... el interés en el trabajo de recuperación de errores en el compilador Pascal generó solicitudes de copias del sistema. A principios de 1977, Joy armó la 'Berkeley Software Distribution'. Esta primera distribución incluía el sistema Pascal y, en un oscuro subdirectorio de la fuente Pascal, el editor vi. Durante el año siguiente, Joy, actuando en calidad de secretario de distribución, envió unas 30 copias gratuitas del sistema". Hoy, Joy cuenta la historia con un poco de distracción desconcertada. Explica que simplemente copió una licencia de la Universidad de Toronto y "borró" "Universidad de Toronto" y la reemplazó con "Universidad de California". Simplemente quería sacar el código fuente por la puerta. Al principio, Berkeley Software Distribution incluía algunas utilidades, pero en 1979 el código se integró estrechamente con el código UNIX básico de AT&T. Berkeley regaló la colección de software en BSD, pero solo los titulares de licencias de AT&T podían usarla. Muchas universidades se sintieron atraídas por el paquete, en parte porque el sistema Pascal era fácil de usar para sus estudiantes. El mundo de las computadoras personales, sin embargo, se estaba enfocando en un lenguaje más simple conocido como Basic. Bill Gates haría de Microsoft Basic uno de sus primeros productos. Joy dice que escribió una carta a AT&T preguntando sobre el estado legal del código fuente de AT&T que se implementó junto con el código BSD. Después de un año, dice, "me respondieron diciendo: 'No tomamos posición' al respecto". Kirk McKusick, quien luego dirigió el proyecto BSD durante los años de la demanda de AT&T, explicó secamente: "Más tarde escribieron una carta diferente". Joy fue solo una de una gran cantidad de personas que trabajaron intensamente en el proyecto BSD desde 1977 hasta principios de la década de 1980. El trabajo era de bajo nivel y sucio para los estándares actuales. Los estudiantes y profesores se apresuraron a trasladar UNIX a las nuevas máquinas que compraron. A menudo, era necesario modificar o actualizar gran parte de las entrañas del sistema operativo para adaptarse a un nuevo tipo de unidad de disco o sistema de archivos. A medida que hacían esto con más y más frecuencia, comenzaron a desarrollar más y más abstracciones de alto nivel para facilitar la tarea. Uno de los primeros ejemplos fue el editor de pantalla de Joy conocido como vi, un paquete simple que podía usarse para editar archivos de texto y reprogramar el sistema. La "batalla" entre el vi de Joy y el Emacs de Stallman es otro ejemplo del cisma entre el MIT y Berkeley. Esta fue solo una de las nuevas herramientas incluidas en la versión 2 de BSD, una colección que se envió a 75 pe rsonas e instituciones diferentes. A fines de la década de 1970, Bell Labs y Berkeley comenzaron a separarse cuando AT&T comenzó a comercializar UNIX y Berkeley mantuvo su trabajo de educación. El profesor de Berkeley, Bob Fabry, pudo interesar a la Agencia de Proyectos de Investigación Avanzada de Defensa (DARPA) del Pentágono para que se inscribiera para apoyar un mayor desarrollo en Berkeley. Fabry vendió a la agencia un paquete de software que se podría utilizar en muchas de las nuevas máquinas que se instalarían en los laboratorios de investigación de todo el país. Sería más fácil de transportar para que la investigación no tuviera que detenerse cada vez que llegaba una nueva computadora. El trabajo en este proyecto se convirtió en las versiones 3 y 4 de BSD. Durante este tiempo, la relación entre AT&T y las universidades fue cordial. AT&T poseía el mercado comercial de UNIX y Berkeley suministraba muchas de las versiones utilizadas en las universidades. Si bien las universidades obtuvieron BSD de forma gratuita, aún necesitaban negociar una licencia con AT&T, y las empresas pagaron una fortuna. Esto no fue un gran problema porque las universidades a menudo son terriblemente miopes. Si comparten su trabajo con otras universidades y profesores, por lo general lo dan por hecho. Puede haber personas por ahí sin citas universitarias, pero esas personas generalmente son vistas como chiflados que pueden ser ignorados con seguridad. De vez en cuando, esos chiflados escriben su propio sistema operativo que se convierte en Linux. La versión BSD de la libertad todavía estaba muy lejos de la de Stallman, pero Stallman aún no la había articulado. Su manifiesto todavía estaba a unos años de distancia. La tensión intelectual entre Stallman y Berkeley creció durante la década de 1980. Mientras Stallman comenzó lo que muchos pensaron que era un viaje quijotesco para construir un sistema operativo completamente gratuito, los estudiantes y profesores de Berkeley continuaron agregando sus mejoras a UNIX sobre el código de AT&T. El código de AT&T era bueno, estaba disponible y muchas de las personas en Berkeley habían ayudado directa o indirectamente a influir en él. En general, estaban felices de mantener el código de AT&T en el centro a pesar de que todos los usuarios de BSD necesitaban negociar con AT&T. Este proceso se volvió cada vez más costoso a medida que AT&T intentaba ganar más y más dinero con UNIX. Por supuesto, a Stallman no le gustó la libertad de la licencia estilo BSD. Para él, significaba que las empresas podían salir corriendo con el trabajo duro y el código fuente compartido de otra, ganar un montón de dinero y no devolver nada. Las empresas y las personas que estaban recibiendo el lanzamiento de la red BSD estaban recibiendo el arduo trabajo acumulativo de muchos estudiantes y profesores de Berkeley (y otros lugares) que donaron su tiempo y esfuerzo para construir un sistema operativo decente. Lo mínimo que estas empresas les debían a los estudiantes eran las correcciones de errores, las extensiones y las mejoras que creaban cuando jugaban con el código fuente y lo pegaban en sus productos. Stallman tenía razón. Muchas de estas empresas "compartieron" vendiendo el software a estos estudiantes y a los contribuyentes que habían pagado por su trabajo. Si bien es imposible volver atrás y auditar los motivos de todos los que usaron el código, hubo muchos que usaron el código BSDstyle para su beneficio personal. Bill Joy, por ejemplo, empezó a trabajar en Sun Microsystems en 1982 y trajo consigo todo el conocimiento que había adquirido en el desarrollo de BSD. Sun siempre fue una tienda muy centrada en BSD, y muchas de las personas que compraron estaciones de trabajo Sun ejecutaban BSD. En ese momento, AT&T todavía controlaba gran parte del núcleo y muchos de los pequeños programas adicionales que hacían de UNIX un sistema utilizable. Pero también hay contraargumentos. Joy ciertamente contribuyó mucho a las diferentes versiones de BSD. Si alguien merece irse y hacerse rico en una empresa como Sun, es él. Además, el código fuente de BSD estaba disponible gratuitamente para todos los interesados ​​y todas las empresas comenzaron con las mismas ventajas. El negocio del software a menudo se considera uno de los mercados más libres debido a las bajas barreras de entrada. Esto significa que las empresas solo deberían poder cobrar por el valor que agregan al código BSD. Claro, todo Internet estuvo influenciado por el código TCP/IP, pero ahora Microsoft, Apple, IBM, Be y todos los demás compiten por la calidad de su interfaz. 10.6 El precio de la libertad total Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. El debate entre la libertad al estilo BSD y la libertad al estilo GNU es uno de los más grandes en el mundo de la programación libre y seguramente continuará durante mucho tiempo a medida que los programadores se unan y experimenten. John Gilmore es un programador que ha trabajado con software desarrollado bajo ambos tipos de licencias. Fue el empleado número cinco de Sun Microsystems, cofundador de la empresa de herramientas de desarrollo de software Cygnus Solutions y uno de los miembros de la junta directiva de Electronic Frontier Foundation. Su trabajo inicial en Sun le dio la riqueza para llevar a cabo muchos proyectos independientes, y ha pasado los últimos 10 años dedicándose a facilitar a las personas de todo el mundo el uso del software de encriptación. Siente que la privacidad es un derecho fundamental y un elemento disuasorio importante del crimen, y ha financiado una serie de proyectos diferentes para promover este derecho. Gilmore también maneja la lista de correo de cypherpunks en una computadora en su casa llamada Toad Hall cerca de Haight Street en San Francisco. La lista de correo está dedicada a explorar cómo crear herramientas de encriptación sólidas que protejan la privacidad de las personas y es bien conocida por el fuerte tono libertario de las deliberaciones. Prácticamente toda la lista cree (y reitera con frecuencia) que las personas necesitan el derecho a proteger su privacidad contra las escuchas privadas y del gobierno. La revista Wired presentó a Gilmore en la portada, junto con sus compañeros de viaje Eric Hughes y Tim May. Una de sus tareas recientes fue crear un paquete de utilidades de encriptación gratuitas que funcionaban en el nivel más bajo del sistema operativo de la red. Estas herramientas, conocidas como Free/SWAN, permitirían que dos computadoras que se encuentran en Internet comiencen a codificar automáticamente los datos que intercambian con algunos de los mejores y más seguros códigos disponibles. Se imagina que los bancos, los laboratorios científicos y los trabajadores a domicilio de todo el mundo querrán utilizar el conjunto de herramientas. De hecho, AT&T actualmente está examinando cómo incorporar el conjunto de herramientas en los productos que está construyendo para vender más servicios de alta velocidad a los trabajadores que se quedan en casa para evitar el viaje. Gilmore decidió utilizar la licencia GNU para proteger el software Free/SWAN, en parte porque en el pasado había tenido malas experiencias con el software totalmente libre. Una vez escribió un pequeño programa llamado PDTar que era una mejora con respecto a la versión estándar de Tar utilizada en Internet para agrupar un grupo de archivos en una gran bolsa de bits fácil de administrar, a menudo conocida cariñosamente como "tarballs". Decidió que no iba a jugar con la licencia GNU de Stallman ni a imponer ninguna restricción al código fuente. Simplemente iba a liberarlo al dominio público y dar a todos libertad total. Esta buena acción no quedó impune, aunque el castigo fue relativamente menor. Él recuerda: "Nunca hice que PDTar funcionara para DOS, pero seis u ocho personas lo hicieron. Durante años después del lanzamiento, recibí correos que decían: 'Tengo este binario para el lanzamiento de DOS y no funciona". A menudo ni siquiera tenían las fuentes que acompañaban a la versión, así que no podía ayudarlos si lo intentaba". Resultó que la libertad total trajo una cierta cantidad de anarquía que le dificultó administrar el proyecto. Si bien la libertad total puede haber alentado a otros a crear sus propias versiones de PDTar, no los obligó a publicar el código fuente que acompañaba a sus versiones para que otros pudieran aprender o corregir sus errores. Hugh Daniel, uno de los evaluadores de la Proyecto Free/SWAN, dice que cree que la Licencia Pública General GNU ayudará a mantener cierta coherencia en el proyecto. "También hay algo mágico con el código GPL que el código abierto no tiene", dijo Da niel. "Por alguna razón, los proyectos no se bifurcan en el espacio GPL. Las personas no toman una copia del código y lo llaman propio. Por alguna razón, hay un sentido de comunidad en el código GPL. Parece haber una versión. Hay un núcleo GPL y hay ramas BSD vacías". Daniel tiene básicamente razón. El código BSD ha evolucionado, o se ha bifurcado, en muchas versiones diferentes con nombres como FreeBSD, OpenBSD y NetBSD, mientras que el kernel Linux UNIX lanzado bajo la GPL de Stallman está limitado a un paquete bastante coherente. Aún así, hay mucha polinización cruzada entre las diferentes versiones de BSD UNIX. Tanto NetBSD 1.0 como FreeBSD 2.0, por ejemplo, tomaron prestado el código de 4.4 BSD-Lite. Además, muchas versiones de Linux vienen con herramientas y utilidades que provienen del proyecto BSD. Pero el punto de Daniel también está nublado con la semántica. Hay docenas, si no cientos, de diferentes distribuciones de Linux disponibles de diferentes proveedores. Muchos difieren en puntos sutiles, pero algunos son marcadamente diferentes. Si bien estas diferencias suelen ser tan grandes como las que existen entre los distintos tipos de BSD, los grupos no las consideran psicológicamente separadas. No se han bifurcado políticamente a pesar de que se han separado de su código. Si bien diferentes versiones pueden ser buenas para algunos proyectos, puede ser un problema para paquetes como Free/SWAN que dependen de la interoperabilidad. Si surgen versiones competidoras de Free/SWAN, entonces todo comienza a sufrir porque el producto fue diseñado para permitir que las personas se comuniquen entre sí. Si el software no puede negociar códigos seguros debido a las diferencias, entonces comienza a fallar. Pero no está claro que la libertad adicional sea responsable de la fragmentación. En realidad, los diferentes grupos BSD surgieron porque tenían necesidades diferentes. El grupo NetBSD, por ejemplo, quería enfatizar el soporte multiplataforma y la interoperabilidad. Su sitio web se jacta de que el lanzamiento de NetBSD funciona bien en 21 plataformas de hardware diferentes y también señala que algunas de estas plataformas de hardware son bastante diversas. Hay 93 versiones diferentes de Macintosh que se ejecutan en los chips 68k de Motorola, incluida la primera Mac. Ochenta y nueve de ellos ejecutan alguna parte de NetBSD y 37 de ellos ejecutan todo. Por eso dicen que su lema es "Por supuesto que ejecuta NetBSD". El grupo OpenBSD, por otro lado, enfatiza la seguridad sin comprometer la portabilidad y la interoperabilidad. Quieren corregir todos los errores de seguridad de inmediato y ser el sistema operativo más seguro del mercado. También existen profundas diferencias personales en la forma en que Theo de Raadt, el fundador de OpenBSD, inició el proyecto después de que el grupo NetBSD lo expulsara de su grupo principal. Por todas estas razones, puede ser difícil argumentar que las libertades provistas por la licencia estilo BSD fueron en gran parte responsables de la fragmentación. Los usuarios del software GNU tienen la misma libertad para hacer nuevas versiones siempre y cuando devuelvan el código fuente a la libre circulación. De hecho, es posible argumentar que las versiones para Macintosh de parte del código GNU comprenden un grupo disidente porque ocurrió a pesar de la mala voluntad que Stallman sentía por la Mac. 10.7 La síntesis del "código abierto" Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. La tensión entre las licencias BSD y GNU siempre se ha enconado como el debate sobre el aborto. Todos eligieron bandos y rara vez se apartaron de ellos. En 1998, un grupo de personas de la comunidad del software libre intentó unificar los dos campos creando un nuevo término, "código abierto". Para asegurarse de que todos supieran que hablaban en serio, comenzaron una organización no incorporada, registraron una marca comercial y crearon un sitio web (www.opensource.org). Cualquiera que quisiera etiquetar su proyecto como "código abierto" tendría que responderles porque controlarían la marca registrada en el nombre. Sam Ockman, un entusiasta de Linux y fundador de Penguin Computing, recuerda el día de la reunión justo antes de que Netscape anunciara que liberaría su código fuente. "Eric Raymond llegó a la ciudad por lo de Netscape. Netscape iba a liberar su software, así que fuimos a Transmeta y tuvimos una reunión para poder asesorar a Netscape", dijo. Explicó que el grupo consideró varias opciones diferentes sobre la estructura. Algunos querían elegir un líder ahora. Otros querían emular un proyecto de código abierto y dejar que emergiera un líder a través de la exhibición de talento y, bueno, liderazgo. Otros querían elecciones. La definición de código abierto surgió del proyecto Debian, uno de los diferentes grupos que se unieron para editar CDROM de versiones estables de Linux. Grupos como estos a menudo se involucran en debates sobre qué software incluir en los discos. Algunos querían ser muy puros y solo incluir software con licencia GPL. En cierta medida, eso obligaría a otros a contribuir con el proyecto porque no conseguirían que el grupo distribuyera su software a menos que tuviera la licencia GPL. Otros querían requisitos menos estrictos que podrían incluir proyectos casi comerciales que aún venían con su código fuente. Hubo algunos proyectos geniales que no estaban protegidos por GPL, y podría ser terriblemente difícil dejar pasar la oportunidad de integrarlos en un paquete. Con el tiempo, uno de los líderes del grupo Debian, Bruce Perens, llegó a crear una definición de lo que era aceptable y lo que no. Esta definición sería lo suficientemente amplia como para incluir la licencia pública general de GNU, las licencias de estilo BSD y algunas otras, como la licencia del Consorcio X del MIT y la licencia Artística. La licencia de X-windows cubre una interfaz gráfica de ventanas que comenzó en el MIT y también se distribuyó gratuitamente con la libertad de BSD. La licencia Artística se aplica al lenguaje de programación Perl, una herramienta que se utiliza con frecuencia para transformar archivos. La metadefinición de Debian abarcaría todos estos. La definición oficial de lo que era aceptable para Debian se inclinaba hacia más libertad y menos restricciones en el uso del software. Por supuesto, esa es la única forma en que alguien podría llegar a una definición que incluyera tanto a GNU como al mucho menos restrictivo BSD. Pero esta también fue la intención del grupo de código abierto. Perens y Eric Raymond sintieron que Stallman todavía sonaba demasiado cuasi-comunista para "hombres de negocios conservadores", y querían la definición de código abierto para evitar insistir en el tipo de intercambio forzado que proporcionaba el virus GNU de Stallman. Aun así, la definición se basó en gran medida en el concepto de GNU de Stallman, y Perens le da crédito al decir que muchas de las pautas de Debian se derivan de la GPL. Una licencia oficial de código abierto para un producto debe proporcionar al programador un código fuente que sea legible por humanos. No puede restringir qué modificaciones se hacen al software o cómo se vende o regala. La definición pasó por alto la diferencia entre BSD y GPU al afirmar: "La licencia debe permitir modificaciones y trabajos derivados, y debe permitir que se distribuyan bajo los mismos términos que la licencia del software original". La definición demostró ser el modelo para más ofertas comerciales como la Licencia Pública de Netscape. En 1998, Netscape comenzó a distribuir el código fuente a su popular navegador con la esperanza de obtener ayuda de Internet y detener la erosión gradual de Microsoft de su territorio. La licencia brindaba a los usuarios amplias oportunidades para realizar cambios y jugar con el software, pero también permitía a Netscape usar los cambios internamente y negarse a compartir lo que hacían con ellos. Este privilegio especial ofendió a algunos usuarios a quienes no les gustó el desequilibrio, pero no molestó a muchos otros que pensaron que era un compromiso razonable para tener la oportunidad de jugar con el código comercial. Netscape, por supuesto, devolvió parte del favor al permitir que las personas mantuvieran sus modificaciones en privado de la misma manera que lo hacía la licencia de estilo BSD. En junio de 1999, la Open Source Initiative reveló un hecho sorprendente. Estuvieron cerca de fracasar en sus intentos de registrar el término "código abierto" como marca comercial. La frase era demasiado común para ser registrada. En cambio, retrocedieron y se ofrecieron a revisar las licencias y clasificarlas oficialmente como "Certificadas por OSI" si cumplían con los términos de la definición de libertad de OSI. Algunos reaccionaron negativamente. Richard Stallman decidió que no le gustaba tanto la palabra "abierto" como "libre". Abierto no captura la esencia de la libertad. Ockman dice: "No creo que sea muy justo. Durante siglos, siempre ha dicho que el término 'software libre' es problemático porque la gente piensa en 'cerveza gratis' cuando debería pensar en 'libertad de expresión'. Estábamos tratando de resolver ese término. Si las masas están confundidas, entonces las corporaciones estadounidenses están aún más confundidas". El debate incluso ha producido más términos. Algunas personas ahora usan la frase "fuente libre" para aplicarla al conglomerado general de GPL y el mundo de fuente abierta. El uso de "software libre" implica que alguien está alineado con la Free Software Foundation de Stallman. El uso de "código abierto" implica que está alineado con la Iniciativa de código abierto más amigable para los negocios. Entonces, "código libre" y "código abierto" funcionan como un compromiso. Otros modifican el significado de libre y se refieren al software protegido por GPL como "GNUFree". Naturalmente, todo este debate sobre la libertad puede alcanzar proporciones cómicas. Los programadores son casi mejores que los abogados para encontrar lagunas, aunque solo sea porque tienen que vivir con un programa que falla.[^7] Stallman, por ejemplo, aplica la GPL a todo lo que sale del proyecto GNU, excepto a la licencia misma. Eso no se puede cambiar, aunque se puede reproducir libremente. Algunos argumentan que si fuera modificable, las personas podrían insertar y eliminar términos a voluntad. Luego podrían aplicar la GPL modificada a la nueva versión del software y hacer lo que quisieran. La intención original de Stallman no cambiaría. La GPL aún se aplicaría a todo el software GNU y sus descendientes, pero no sería la misma GPL. [7]: Los abogados solo ven a sus clientes ir a la cárcel. ---------------------------------------- 11. Fuente Los programadores de computadoras aman Star Wars. Por lo tanto, no debería sorprender que prácticamente todos los miembros de la comunidad de código libre, en un momento u otro, hayan lanzado la frase "Usa la fuente, Luke". Hace un trabajo perfecto al capturar la fe mítica que el mundo de la fuente libre deposita en la capacidad de acceder al código fuente de un programa. Como todos señalan, en la versión original de Star Wars, las tropas rebeldes usaban los planos, la Fuente, a la Estrella de la Muerte que llevaba R2D2 para buscar debilidades. El reino de la fuente libre ha estado impulsando los paralelos desde hace algún tiempo. Cuando AT&T dio a conocer su logotipo redondo con un hoyuelo desplazado, la mayoría de la gente de código libre comenzó a reírse. La empresa que inició la revolución del software libre al impulsar sus derechos de propiedad intelectual y molestar a Richard Stallman había elegido un logotipo que se parecía a la Estrella de la Muerte. Todos decían: "Las mentes imperialistas piensan igual". Algunos incluso se preguntaban y esperaban que George Lucas demandara a AT&T por algún tipo de infracción de marca registrada. Aquellos que usan el sable de luz de intimidación legal deben morir por el sable de luz de intimidación legal. Por supuesto, la gente de código libre sabía que solo su coalición suelta de rebeldes repartidos por la galaxia sería un rival fuerte para el Imperio. La Fuente era información, y la información era poder. The Source también trataba sobre la libertad, una de las mejores y más consistentes reservas de inspiración revolucionaria que existen. Puede que los rebeldes no tuvieran equipos de abogados en los cruceros estelares imperiales, pero esperaban utilizar la Fuente para tejer una resistencia fuerte, eficaz y más poderosa. El mito del acceso abierto al código fuente gratuito es poderoso y ha convertido a muchos en la comunidad en verdaderos creyentes. El código fuente es una lista de instrucciones para la computadora escritas en un lenguaje de programación comprensible para los humanos. Una vez que los compiladores convirtieron el código fuente en la cadena de bits conocida como código binario u objeto, solo las computadoras (y algunos humanos muy talentosos) podían entender las instrucciones. He conocido a varias personas que pueden leer el código binario 8080 a simple vista, pero son un poco diferentes de la población general. Cuando las empresas trataron de mantener en secreto su arduo trabajo e investigación bloqueando el código fuente, construyeron una barrera entre los usuarios y sus desarrolladores. Los programadores trabajarían detrás de paredes secretas para escribir el código fuente. Después de que los compiladores convirtieran la fuente en algo que las computadoras pudieran leer, la fuente sería bloqueada nuevamente. Los compradores solo obtendrían el código binario porque eso es todo lo que las empresas pensaban que necesitaban los consumidores. El código fuente debía mantenerse en secreto porque alguien podría robar las ideas del interior y crear su propia versión. Stallman vio este secreto como un gran crimen. Los usuarios de computadoras deberían poder compartir el código fuente para que puedan compartir formas de mejorarlo. Este intercambio debería conducir a más intercambio de información en un gran circuito de retroalimentación. Algunas personas incluso usaron la palabra "floración" para describir la explosión de interés y la retroalimentación cruzada. Están usando la palabra de la forma en que los biólogos la usan para describir la forma en que las algas pueden surgir, inundando una región del océano. Ideas inteligentes, correcciones de errores brillantes y nuevas características maravillosas aparecen de la nada a medida que la curiosidad humana se amplifica por la generosidad humana en una gran explosión de sinergia intelectual. Lo único que falta en la imagen es un grupo de ewoks peludos que bailan alrededor de una fogata.[^8] [8]: Linux tiene muchas oportunidades de marketing. Torvalds eligió un pingüino llamado Tux como mascota, y varias empresas fabrican y venden pingüinos de peluche para el reino de Linux. El mundo BSD ha abrazado a un lindo demonio, un juego de palabras visual sobre el hecho de que BSD UNIX usa la palabra "daemon" para referirse a algunos de los programas de fondo sin rostro en el sistema operativo. 11.1 El obispo Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Eric Raymond, un hombre que es una especie de filósofo de sillón del mundo del código abierto, hizo un gran trabajo al resumir el fenómeno y crear este mito en su ensayo "La catedral y el bazar". Raymond es un programador serio que pasó algún tiempo trabajando en proyectos como GNU Emacs de Stallman. Vio las ventajas del desarrollo de código abierto desde el principio, tal vez porque es un libertario empedernido. Las soluciones gubernamentales son engorrosas. Empoderar a las personas sin restringirlas es excelente. Raymond se muestra un poco más extremista que otros libertarios, en parte porque no duda en defender la segunda enmienda de la Constitución de los Estados Unidos tanto como la primera. Raymond no se avergüenza de apoyar la posesión generalizada de armas como una forma de empoderar aún más al individuo. No le gusta la Asociación Nacional del Rifle porque están demasiado dispuestos a renunciar a derechos que él siente que son absolutos. A algunas personas les gusta llamarlo la Margaret Mead del mundo del código libre porque pasó algún tiempo estudiando y caracterizando la cultura de la misma manera que lo hizo Mead cuando escribió Coming of Age in Samoa. Esto puede ser un golpe sutil porque Margaret Mead no es realmente el mismo ángel intelectual que fue hace mucho tiempo. Derek Freeman y otros antropólogos plantean serias dudas sobre la capacidad de Mead para ver sin prejuicios. Mead era una gran fanática del amor libre, y muchos afirman que no fue casualidad que encontrara maravillosas historias de sexualidad sin control en Samoa. Freeman volvió a visitar Samoa y descubrió que no era la tierra libre de culpas de los placeres libertinos que Mead describía en su libro. Documentó muchos ejemplos de moderación sexual y vergüenza que Mead aparentemente pasó por alto en su búsqueda de un paraíso. Raymond miró el desarrollo de código abierto y encontró lo que quería encontrar: la maravillosa eficiencia de los mercados no regulados. Claro, a algunas personas les encantaba etiquetar a Richard Stallman como comunista, una descripción que siempre ha molestado a Stallman. Raymond investigó un poco más a fondo y vio que la base del éxito del movimiento del software libre era la libertad que otorgaba a cada usuario el poder completo de cambiar y mejorar su software. Así como Sigmund Freud encontró el sexo en la raíz de todo y Carl Jung descubrió una batalla de animus y anima, el libertario encontró la libertad. El ensayo de Raymond fue uno de los primeros en tratar de explicar por qué los esfuerzos de código libre pueden tener éxito e incluso prosperar sin los incentivos financieros de una empresa de software estándar basada en el dinero. Una de las principales razones que citó fue que un programador podría "rascarse una picazón" que le molestaba. Es decir, un programador podría molestarse por una pieza de software que limitaba sus opciones o tenía un problema técnico molesto. En lugar de maldecir la oscuridad en la cavidad cerebral del programador corporativo que creó el problema, el hacker de código libre pudo usar el código fuente para tratar de encontrar el error. Rascarse con picazón puede ser fundamental para resolver muchos problemas. Algunos errores en el software son bastante difíciles de identificar y duplicar. Solo ocurren en situaciones extrañas, como cuando la impresora se queda sin papel y el módem está sobrecargado por un archivo largo que llega a través de Internet. Entonces, y solo entonces, los dos búferes pueden llenarse hasta el borde, chocar entre sí y bloquear la computadora. El resto del tiempo, el programa flota felizmente, sin encontrar problemas. Estos tipos de errores son notoriamente difíciles de descubrir y caracterizar para los entornos de prueba corporativos. Las empresas intentan ser diligentes contratando a varios programadores jóvenes y colocándolos en una habitación con una computadora. El equipo golpea el software todo el día y desarrolla una animosidad saludable hacia el equipo de programación que tiene que solucionar los problemas que descubren. Pueden detectar muchos errores simples, pero ¿qué sucede si no tienen una impresora conectada a su máquina? ¿Qué sucede si no están imprimiendo cosas constantemente como lo hacen algunos usuarios de oficina? El extraño error pasa desapercibido y probablemente no se solucione. El modelo de desarrollo corporativo trata de resolver esta limitación enviando cientos, miles y, a menudo, cientos de miles de copias a usuarios ambiciosos a los que llamaron "beta testers". Otros los llamaron "tontos" o "voluntarios gratuitos" porque una vez que terminan de ayudar a desarrollar el software, pueden pagarlo. Microsoft incluso cobra a algunos usuarios por el placer de ser probadores beta. Muchos de los usuarios son pragmáticos. A menudo, no tienen más remedio que participar en el esquema porque a menudo basan sus negocios en algunos de los programas que envían estas empresas. Si no funcionara, se quedarían sin trabajo. Si bien es mucho más probable que esta amplia distribución de copias beta encuentre a alguien que esté imprimiendo y sobrecargando un módem al mismo tiempo, no brinda al usuario las herramientas para ayudar a encontrar el problema. Su única opción es escribir un mensaje de correo electrónico a la empresa que diga "Estaba imprimiendo ayer y su software falló". Eso no es muy útil para el ingeniero, y no sorprende que muchos de estos informes se ignoren o no se resuelvan. Raymond señaló que el mundo del código libre puede hacer un gran trabajo con estos desagradables errores. Caracterizó esto con la frase: "Con suficientes ojos, todos los errores son superficiales", que caracterizó como "Ley de Linus". Es decir, eventualmente algún programador comenzaría a imprimir y usar Internet al mismo tiempo. Después de que el sistema fallara varias veces, algún programador se preocuparía lo suficiente por el problema como para investigar la fuente gratuita, hurgar y detectar el problema. Eventualmente, alguien vendría con el tiempo, la energía y el compromiso para diagnosticar el problema. Raymond llamó a esto "Ley de Linus" en honor a Linus Torvalds. Raymond es un gran admirador de Torvalds y piensa que el verdadero genio de Torvalds fue organizar un ejército para trabajar en Linux. La codificación en sí fue un segundo distante. Por supuesto, esperar a que un usuario encontrara los errores dependía de que hubiera alguien con suficiente tiempo y compromiso. La mayoría de los usuarios no son programadores talentosos y la mayoría tiene trabajos diarios. Raymond y el resto de la comunidad de código libre reconocen esta limitación, pero señalan que la persona adecuada a menudo aparece si el error ocurre con la suficiente frecuencia como para convertirse en un problema real. Si el error es lo suficientemente grave, alguien que no sea programador puede incluso contratar a un programador para que introduzca el código fuente. Esperar a que el bicho y el programador se encuentren es como esperar a que Arthur encuentre la espada en la piedra. Pero Raymond y el resto de la comunidad de código libre incluso le han dado la vuelta a esta limitación y la han promocionado como una ventaja. Confiar en los usuarios para rascarse significa que los problemas solo se abordan si tienen distritos electorales reales con una población lo suficientemente grande como para generar el único creyente verdadero con suficiente tiempo libre. Es una especie de mercado libre en el tiempo de las personas para corregir errores. Si la demanda está ahí, se creará la solución. Es la Ley de Say reformulada para el desarrollo de software: "el suministro de errores crea el talento para las correcciones". El desarrollo corporativo, por otro lado, ha estado obsesionado durante mucho tiempo con agregar más y más funciones a los programas para dar a las personas suficientes razones para comprar la actualización. Los gerentes saben desde hace mucho tiempo que es mejor dedicar más tiempo a agregar más trucos y widgets a un programa que corregir sus errores. Es por eso que Microsoft Word puede hacer tantas cosas diferentes con los encabezados y pies de página de los documentos, pero no puede detener la reproducción de un virus Word Macro. La gente de Microsoft sabe que cuando los gerentes corporativos se sientan a decidir si gastar los miles de dólares para actualizar sus máquinas, necesitarán un conjunto de nuevas características atractivas. A la gente no le gusta pagar por la corrección de errores. Por supuesto, las corporaciones también tienen algunas ventajas. Money se asegura de que alguien esté tratando activamente de resolver los errores en el programa. La misma visión de libre mercado garantiza que las empresas que constantemente decepcionan a sus clientes se irán a la quiebra. Este desarrollador tiene la ventaja de estudiar el mismo código fuente día tras día. Eventualmente, aprenderá lo suficiente sobre las entrañas de la Fuente para ser mucho más efectivo que el tipo con la impresora y el módem atascados. Debería ser capaz de atrapar el error 10 veces más rápido que el aficionado al código libre solo porque es un experto en el sistema. Raymond reconoce este problema pero propone que el modelo de fuente libre aún puede ser más efectivo a pesar de la inexperiencia de las personas que se ven obligadas a rascarse la picazón. Una vez más, toca el mundo de la filosofía libertaria y sugiere que el mundo del software libre es como un bazar lleno de muchos comerciantes diferentes que ofrecen sus productos. El desarrollo corporativo, por otro lado, está estructurado como los sindicatos religiosos que construyeron las catedrales medievales. Los bazares ofrecían mucha competencia pero ningún orden. Las catedrales estaban a cargo de equipos centrales de sacerdotes que aprovecharon la riqueza de la ciudad para construir la visión de un arquitecto. Las diferencias entre los dos eran bastante simples. El equipo de la catedral podría producir una gran obra de arte si el arquitecto tuviera talento, el equipo de financiamiento tuviera éxito y la administración pudiera mantener a todos enfocados en hacer su trabajo. Si no, nunca llegó tan lejos. El bazar, por otro lado, consistía en muchos pequeños comerciantes que intentaban superarse unos a otros. Los mejores cocineros terminaron con la mayor cantidad de clientes. Los otros pronto cerraron. La comparación con el software era simple. Las corporaciones reunían los diezmos, empleaban un arquitecto central con una gran visión, administraban el equipo de programadores y enviaban un producto de vez en cuando. El mundo de Linux, sin embargo, permite que todos toquen la Fuente. La gente intentaría arreglar las cosas o añadir nuevas funciones. Las mejores soluciones serían adoptadas por otros y las mediocres quedarían en el camino. Proliferarían muchas versiones diferentes de Linux, pero con el tiempo el mercado de software se fusionaría en torno a la mejor versión estándar. "Desde el punto de vista de la programación del constructor de catedrales, los errores y los problemas de desarrollo son fenómenos complicados, insidiosos y profundos. Se necesitan meses de escrutinio por parte de unos pocos dedicados para desarrollar la confianza de que los ha eliminado todos. Por lo tanto, los largos intervalos de publicación y la inevitable decepción cuando los lanzamientos largamente esperados no son perfectos", dijo Raymond. "En la vista de bazar, por otro lado, asumes que los errores son fenómenos generalmente superficiales, o, al menos, que se vuelven superficiales bastante rápido cuando se exponen a miles de desarrolladores de código ansiosos que golpean cada nueva versión. En consecuencia, usted suelte a menudo para obtener más correcciones y, como efecto secundario beneficioso, tiene menos que perder si se produce un error ocasional". 11.2 Flecha gigante Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Este bazar puede ser una poderosa influencia para resolver problemas. Claro, no está guiado por un arquitecto talentoso y equipos de sacerdotes, pero es un gran juego contra todos. Es bastante improbable, por ejemplo, que el tipo con la impresora sobrecargada y la línea de módem también sea un programador talentoso con una gran visión para resolver el problema. Alguien llamado Arthur solo tropieza con la piedra correcta con la espada correcta de vez en cuando. Pero si el usuario frustrado puede hacer un buen trabajo al caracterizarlo e informarlo, entonces alguien más puede resolverlo. Dave Hitz fue uno de los programadores que ayudó a Keith Bostic a reescribir UNIX para que pudiera estar libre de los derechos de autor de AT&T. En la actualidad, dirige Network Appliance, una empresa que crea servidores de archivos simplificados que ejecutan BSD en su núcleo. Ha estado escribiendo sistemas de archivos desde la universidad, y el software gratuito fue muy útil cuando estaba comenzando su empresa. Cuando comenzaron a construir las grandes máquinas, los ingenieros simplemente buscaron en el grupo de código fuente gratuito para los sistemas operativos y extrajeron gran parte del código que alimentaría sus servidores. Modificaron mucho el código, pero el cuerpo de software libre que ayudó a crear fue un excelente punto de partida. Según su experiencia, muchas personas encontraban un error y lo reparaban con una solución que fuera lo suficientemente buena para ellos. Algunos eran solo niños en la universidad. Otros eran programadores que no tenían ni el tiempo ni la energía para leer el código fuente y comprender la mejor manera de solucionar el problema. Algunos solucionaron el problema por sí mismos, pero sin darse cuenta crearon otro problema en otro lugar. Ordenar todos estos problemas fue difícil de hacer. Pero Hitz dice: "Incluso si lo arreglaron completamente de manera incorrecta, si encontraron el lugar donde desapareció el problema, entonces pusieron una flecha gigante sobre el problema". Eventualmente, suficientes flechas proporcionarían a alguien suficiente información para resolver el problema correctamente. Muchas de las nuevas versiones escritas por personas pueden perderse en el tiempo, pero eso no significa que no hayan tenido un efecto importante en la evolución de la Fuente. "Creo que rara vez se da el caso de que haya personas que hagan de su vida una amplia base de código fuente", dijo. "Hay un montón de personas que son diletantes. El mensaje es: 'No subestimes a los diletantes'". 11.3 Bazar o Catedral Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Cuando Raymond escribió el ensayo, solo estaba tratando de descubrir las diferencias entre varios de los campos en el mundo del código libre. Se dio cuenta de que las personas que ejecutan proyectos de código libre tenían diferentes formas de compartir. Quería explicar qué método de desarrollo de código libre funcionaba mejor que otros. Fue solo más tarde que el ensayo comenzó a tomar un objetivo más serio cuando todos comenzaron a darse cuenta de que Microsoft era quizás el equipo de desarrollo con forma de catedral más grande que existía. Raymond dijo: "Creo que, como todos los demás en la cultura, vagué de un lado a otro entre los dos modos, ya que parecía apropiado porque no tenía una teoría ni conciencia". Vio a Richard Stallman y los primeros años de los proyectos GNU como un ejemplo de desarrollo estilo catedral. Estos equipos solían trabajar durante meses, si no años, antes de compartir sus herramientas con el mundo. El propio Raymond dijo que se comportó de la misma manera con algunas de las primeras herramientas que escribió y con las que contribuyó al proyecto GNU. Linus Torvalds cambió de opinión al aumentar la velocidad de compartir, que Raymond caracterizó como la regla de "liberar temprano y con frecuencia, delegar todo lo que pueda, estar abierto hasta el punto de la promiscuidad". Torvalds ejecutó Linux de la manera más abierta posible, y esto finalmente atrajo a algunos buenos colaboradores. En el pasado, la FSF era mucho más cuidadosa con lo que adoptaba y aportaba al proyecto GNU. Torvalds tomó muchas cosas en sus distribuciones y mutaron tan a menudo como a diario. Ocasionalmente, salían nuevas versiones dos veces al día. Por supuesto, Stallman y Raymond han tenido peleas en el pasado. Raymond tiene cuidado de elogiar al hombre y decir que valora su amistad, pero también lo modera diciendo que es difícil trabajar con Stallman. En el caso de Raymond, dice que una vez quiso reescribir gran parte del código Lisp que estaba integrado en GNU Emacs. Emacs de Stallman permitía a cualquier usuario conectar su propio software a Emacs escribiéndolo en una versión especial de Lisp. Algunos tenían lectores de correo escritos. Otros habían agregado un código de generación automática de comentarios. Todo esto fue escrito en Lisp. Raymond dice que en 1992, "las bibliotecas Lisp estaban en mal estado de varias maneras. Estaban mal documentadas. Había mucho trabajo que se había realizado fuera de la FSF y yo quería abordar ese proyecto". Según Raymond, Stallman no quería que él hiciera el trabajo y se negó a incluirlo en la distribución. Stallman pudo hacer esto porque controlaba la Free Software Foundation y la distribución del software. Raymond podría haber creado su propia versión, pero se negó porque era demasiado complicada y, en última instancia, mala para todos si surgían dos versiones. Por su parte, Stallman explica que estaba contento de aceptar partes del trabajo de Raymond, pero que no quería verse obligado a aceptarlas todas. Stallman dice: "En realidad, acepté una cantidad sustancial del trabajo que Eric había hecho. Tenía varias ideas que me gustaban, pero también tenía algunas ideas que pensé que estaban equivocadas. Acepté con gusto su ayuda, siempre y cuando podía juzgar sus ideas una por una, aceptando algunas y rechazando otras. "Pero posteriormente me pidió que hiciera un acuerdo general en el que se haría cargo del desarrollo de una gran parte de Emacs, operando de forma independiente. Sentí que debía seguir juzgando sus ideas individualmente, así que dije que no". Raymond combinó esta experiencia con el tiempo que pasó observando al equipo de Torvalds impulsar el kernel de Linux y los usó como base para su ensayo sobre la distribución de Source. "Principalmente, estaba tratando de extraer algunos factores que había observado como folclore inconsciente para que la gente pudiera sacarlos y razonar sobre ellos", dijo. Raymond dice: "Alguien señaló que hay un paralelismo con la política. Las instituciones políticas y sociales rígidas tienden a cambiar violentamente si cambian, mientras que las que tienen más juego tienden a cambiar pacíficamente". Hay una buena razón empírica para la fe en la fuerza de la fuente libre. Después de todo, un grupo de personas que rara vez se veían había reunido una gran cantidad de código fuente que estaba pateando el trasero de Microsoft en algunos rincones del mundo informático. Los servidores Linux eran comunes en Internet y cada día eran más comunes. El escritorio estaba esperando ser conquistado. Lo habían hecho sin opciones sobre acciones, sin jets corporativos, sin contratos secretos y sin alianzas potencialmente ilegales con fabricantes de computadoras. El éxito del software del mundo GNU y Linux fue realmente impresionante. Por supuesto, los mitos pueden llevarse demasiado lejos. Programar computadoras es un trabajo duro y, a menudo, frustrante. Compartir el código fuente no hace que los errores o problemas desaparezcan, solo hace que sea un poco más fácil para otra persona profundizar en un programa para ver qué está fallando. El código fuente puede ser simplemente una lista de instrucciones escritas en un lenguaje de programación que está diseñado para que los humanos puedan leerlo, pero eso no significa que sea fácil de entender. De hecho, la mayoría de los humanos no entenderán la mayor parte del código fuente porque los lenguajes de programación están diseñados para ser entendidos por otros programadores, no por la población en general. Para empeorar las cosas, los propios programadores tienen dificultades para comprender el código fuente. Los programas de computadora a menudo son bastante complicados y puede tomar días, semanas e incluso meses entender qué es lo que un extraño código fuente le dice a una computadora que haga. Aprender lo que sucede en un programa puede ser un trabajo complicado incluso para los mejores programadores, y no es algo que se tome a la ligera. Si bien muchos programadores y miembros del mundo del código abierto se apresuran a elogiar el movimiento, también podrán citar problemas con el mito de la Fuente. No es que la Fuente no funcione, dirán, es solo que rara vez funciona tan bien como implica la exageración. Las floraciones rara vez son tan vigorosas y los mercados libres de mejoras rara vez son tan líquidos. A Larry McVoy, un ávido programador, protoacadémico y desarrollador del kit de herramientas BitKeeper, le gusta encontrar fallas en el modelo. No es que no le guste compartir el código fuente, es solo que no es lo suficientemente rico como para asumir proyectos de software libre. "Necesitamos encontrar una manera para que la gente desarrolle software libre y pague sus hipotecas y forme una familia", dice. "Si miras de cerca", dice, "realmente no hay un bazar. En la parte superior siempre es una catedral de una sola persona. Es Linus, Stallman o alguien más". Es decir, el mito de un bazar como una competencia abierta y libre para todos no es exactamente cierto. Claro, todos pueden descargar el código fuente, jugar con él y hacer sugerencias, pero al final del día importa lo que diga Torvalds, Stallman o cualquier otra persona. Siempre hay un gran arquitecto de Chartres que se enseñorea de su dominio. Parte de este problema es el éxito de la metáfora de Raymond. Dijo que solo quería darle a la comunidad algunas herramientas para comprender el éxito de Linux y razonar al respecto. Pero sus dos visiones de una catedral y un bazar tenían tal claridad que la gente se concentraba más en dividir el mundo en catedrales y bazares. En realidad, hay una gran cantidad de mezcla en el medio. Los bazares más eficientes en la actualidad son los centros comerciales suburbanos que tienen una empresa administradora que construye el sitio, alquila las tiendas y crea una experiencia unificada. Las áreas comerciales del centro a menudo fallaban porque siempre había un dueño de tienda que podía arruinar una cuadra entera instalando una tienda que vendiera pornografía. Por otro lado, la religión siempre ha sido una especie de bazar. Martín Lutero dividió efectivamente el cristianismo al introducir la competencia. Incluso dentro de las denominaciones, diferentes parroquias luchan por los corazones y las almas de las personas. El mismo desenfoque se aplica al mundo del software de código abierto. El kernel de Linux, por ejemplo, contiene muchos miles de líneas de código fuente. Algunos ponen el número en 500.000. Algunas personas talentosas como Alan Cox o Linus Torvalds lo saben todo, pero la mayoría solo están familiarizados con los rincones que necesitan saber. Estas personas, que pueden ser miles, son superadas en número por los millones que usan el sistema operativo Linux a diario. Es interesante preguntarse si la proporción entre usuarios técnicamente ungidos y alegres en el mundo del código libre es comparable a la proporción en el dominio de Microsoft. Después de todo, Microsoft compartirá su código fuente con socios cercanos después de que firmen algunos formularios de confidencialidad.[^9] Si bien Microsoft tiene cuidado con lo que les dice a sus socios, solo revelará información cuando haya algo que ganar. Otras compañías ya se lanzaron y comenzaron a ofrecer el código fuente a todos los usuarios que quieran verlo. [9]: Al momento de escribir este artículo, Microsoft no ha publicado su código fuente, pero se sabe que la empresa está examinando la opción como parte de su acuerdo con el Departamento de Justicia. Responder a esta pregunta es imposible por dos razones diferentes. Primero, nadie sabe lo que Microsoft revela a sus socios porque mantiene toda esta información en secreto, por reflejo. Los contratos generalmente se negocian bajo confidencialidad, y la empresa no ha tenido reparos en explotar el poder que proviene de la falta de información. En segundo lugar, nadie sabe realmente quién lee el código fuente de Linux por la razón opuesta. La fuente de GNU/Linux está ampliamente disponible y se descarga con frecuencia, pero eso no significa que se lea o estudie. Los CD de Red Hat vienen con un CD lleno de binarios precompilados y el segundo lleno de código fuente. ¿Quién sabe quién mete el segundo CDROM en su computadora? Todos son libres de hacerlo en la privacidad de su propio cubículo, por lo que no se mantienen registros. Si tuviera que apostar, diría que las proporciones de cognoscenti a usuarios desinformados en los mundos de Linux y Microsoft son bastante similares. Leer el código fuente requiere demasiado tiempo y demasiado esfuerzo para que muchos en el mundo de Linux aprovechen el enorme río de información disponible para ellos. Si esto es cierto o al menos casi cierto, entonces ¿por qué el mundo del código libre ha podido moverse mucho más rápido que el mundo de Microsoft? La respuesta no es que todos en el mundo de la fuente libre estén usando la Fuente, es que todos son libres de usarla. Cuando una persona necesita hacer una pregunta o rascarse una picazón, la Fuente está disponible sin hacer preguntas ni consultar a ningún abogado. Incluso a las 3:00 a.m., una persona puede leer la Fuente. En Microsoft y otras corporaciones, a menudo necesitan esperar a que la persona que dirige esa división o sección les dé permiso para acceder al código fuente. Hay otras ventajas. El mundo del código fuente gratuito dedica una gran cantidad de tiempo a mantener el código fuente limpio y accesible. Un programador que trata de salirse con la suya con una mano de obra descuidada y una mala documentación pagará por ello más tarde cuando otros lleguen y hagan miles de preguntas. Los desarrolladores corporativos, por otro lado, tienen capas de secreto y burocracia para aislarlos de preguntas y comentarios. A menudo es difícil encontrar al programador adecuado en la madriguera de conejos de los cubículos que tiene el código fuente en primer lugar. Se citó a un programador de Microsoft diciendo: "Un desarrollador de Microsoft que trabaja en el sistema operativo no puede rascarse la picazón que tiene con Excel, ni el desarrollador de Excel puede rascarse la picazón con el sistema operativo; le llevaría meses descubrir cómo para compilar, depurar e instalar, y probablemente no pudo obtener el acceso adecuado a la fuente de todos modos". Este problema es endémico en las corporaciones. Los clientes están comprando la versión binaria, no el código fuente, por lo que no hay razón para disfrazar las alas detrás del escenario del teatro. Sin embargo, después de un tiempo, la gente cambia de cubículo, se muda a otras corporaciones y la información desaparece. Si bien las empresas intentan mantener bases de datos de código fuente para sincronizar el desarrollo, los esfuerzos a menudo fracasan. Después de que Apple canceló el desarrollo de su dispositivo portátil Newton, muchos usuarios de Newton estaban furiosos. Habían basado grandes proyectos en la plataforma y no querían reiniciar su trabajo. Muchos preguntaron si Apple podría simplemente regalar el código fuente del sistema operativo en lugar de dejar que se pudra en algún disco duro. Apple eludió estas solicitudes, y esto hizo que algunas personas se volvieran aún más cínicas. Un desarrollador externo especuló: "Probablemente no sería posible volver a crear el sistema o perativo. Todos los desarrolladores se fueron. Todos fueron a Palm, y probablemente no podrían volver a armarlo si quisieran". Por supuesto, las corporaciones intentan combatir esta podredumbre haciendo que sus programadores hagan un buen trabajo al principio y escriban mucha documentación. En la práctica, esto falla un poco porque no es recompensado por la cultura del secreto. Conozco a un programador que trabajó para un proyecto en el MIT. El jefe pensó que estaba siendo inteligente al solicitar comentarios sobre cada procedimiento y, de hecho, lo hizo cumplir con un robot de escaneo de texto automatizado que revisaría el código fuente y contaría los comentarios. Mi amigo se dio la vuelta y conectó una versión de los populares chatterbots de inteligencia artificial como Eliza y canalizó las respuestas al campo de comentarios. Entonces todos estaban felices. El chatterbot llenó el campo de comentarios, la policía de comentarios automatizada encontró algo vagamente inteligente y el programador pasó su tiempo libre haciendo otras cosas. El jefe nunca descubrió el problema. Los programadores son iguales en todo el mundo, y unirse al mundo del código libre no los hace mejores personas ni destruye su descaro. Pero los penaliza si otros vienen e intentan usar su código. Si es inescrutable, descuidado o difícil de entender, los demás lo ignorarán o los acosarán con preguntas. Eso es un fuerte incentivo para hacerlo bien. 11.4 Código abierto y bombillas Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Las limitaciones del poder del código abierto podrían resumirse en la respuesta a la pregunta "¿Cuántos desarrolladores de código abierto se necesitan para cambiar una bombilla?" La respuesta es: 17. Diecisiete para discutir sobre la licencia; 17 para discutir sobre la muerte cerebral de la arquitectura de la bombilla; 17 para discutir sobre un nuevo modelo que abarque todos los modelos de iluminación y que facilite el reemplazo de velas, fogatas, luces piloto y tragaluces con el mismo mecanismo fácil de extender; 17 para especular sobre la conspiración industrial secreta que asegura que las bombillas se quemarán con frecuencia; 1 para finalmente cambiar la bombilla; y 16 que deciden que esta solución es lo suficientemente buena por el momento. El modelo de desarrollo de código abierto es una excelente manera para que personas muy creativas produzcan software fascinante que rompa paradigmas y establezca nuevos estándares de excelencia. Sin embargo, puede que no sea la mejor manera de terminar trabajos aburridos como ajustar una interfaz gráfica o asegurarse de que el software de programación utilizado por los ejecutivos sea lo más resistente posible. Si bien el modelo de desarrollo abierto ha abordado con éxito el problema de la creación de excelentes herramientas, de la creación de un sistema operativo sólido y de la creación de aplicaciones de electrodomésticos muy flexibles, como navegadores web, está muy lejos de ganar la batalla por el escritorio. Algunas personas de código libre dicen que las aplicaciones de escritorio para usuarios promedio están a la vuelta de la esquina y la siguiente parada en el Free Software Express. Otros no están tan seguros. David Henkel-Wallace es uno de los fundadores de la empresa de software libre Cygnus. Esta empresa basó su éxito en el apoyo a las herramientas de desarrollo creadas por la Free Software Foundation de Stallman. Firmarían contratos con empresas para responder cualquier pregunta que tuvieran sobre el uso de las herramientas de software libre. Al principio, las empresas se negaban a pagar por el soporte hasta que se dieron cuenta de que era más barato que contratar personal técnico interno para hacer el trabajo. A John Gilmore, uno de los cofundadores, le gustaba decir: "Hacemos que el software gratuito sea asequible". La empresa creció ayudando a los fabricantes de chips a ajustar el compilador FSF, GCC, para su chip. A menudo, esta era una tarea difícil y ardua, pero era muy valiosa para el fabricante del chip porque los clientes potenciales sabían que podían conseguir un buen compilador para producir software para el chip. Si bien Intel continuó dominando el escritorio, el mercado de chips integrados para productos como estufas, hornos de microondas, VCR u otras cajas inteligentes creció a medida que los fabricantes lanzaban nuevos chips para que fuera más barato y más fácil agregar funciones inteligentes a las cajas que antes eran tontas. . Los ingenieros de las empresas a menudo estaban encantados de descubrir que podían seguir usando GCC para escribir software para un nuevo chip, y esto facilitó la venta del chip. Cygnus siempre distribuyó a la Fuente sus modificaciones a GCC como exigía la Licencia Pública General de GNU. Esto no fue un gran problema porque los fabricantes de chips querían que el software fuera gratuito y fácil de usar para todos. Esto convirtió a Cygnus en uno de los centros de intercambio de gran parte de la información sobre cómo funcionaba GCC y cómo hacerlo más rápido. Henkel-Wallace se apresura a elogiar el poder del código fuente disponible públicamente para los clientes de Cygnus. Después de todo, todos eran programadores. Si veían algo que no les gustaba con GCC, sabían cómo hurgar en el interior y arreglarlo. Ese era su trabajo. "[GCC] es una herramienta de compilación y fue utilizada por los desarrolladores, por lo que fueron lo suficientemente inteligentes. Cuando algo molestaba a alguien, lo solucionábamos. Había un acoplamiento muy estrecho", dijo. Sin embargo, se pregunta abiertamente si el procesador de textos promedio o el usuario de herramientas básicas podrá hacer algo. Él dice: "La desventaja es que es difícil transferir ese conocimiento con un usuario que no es un desarrollador. Digamos que Quicken tiene una característica especial para los abogados. Necesita tener un modelo más formal porque los abogados no son desarrolladores. (Somos afortunados en ese sentido)". Es decir, los abogados no están lo suficientemente instruidos en las entrañas del desarrollo informático para quejarse de la manera correcta. Un programador podría decir: "GCC está optimizando demasiado código muerto que en realidad no está muerto". Otras personas en la comunidad de GCC sabrían lo que está pasando y podrían solucionarlo. Un abogado podría simplemente decir: "Quicken arruinó mi facturación y me hizo facturar veintiséis horas en un día". Esto no identificaría el problema lo suficiente como para que la gente lo resuelva. El abogado no entiende el interior del software como el programador. En situaciones como esta, Henkel-Wallace cree que un equipo de estilo corporativo puede ser el único que puede estudiar los problemas lo suficientemente a fondo como para encontrar soluciones. Intuit, el fabricante de Quicken, es bien conocido por grabar en video a muchos usuarios estándar que usan su producto por primera vez. Esto les permite identificar los puntos ásperos del programa e identificar los lugares donde podría mejorarse. Este incesante alisado y pulido ha convertido al producto en una de las herramientas más conocidas y utilizadas en los escritorios. No está claro que los no programadores podrían haber logrado la misma calidad trabajando junto con la Fuente a su disposición. 11.5 La Fuente Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Hay corrientes más profundas y filosóficas en el mundo del código abierto. La industria de las computadoras personales tiene solo unas pocas décadas. Si bien ha avanzado rápidamente y ha resuelto muchos problemas, todavía hay muy poca comprensión del campo y de lo que se necesita para que una computadora sea fácil de usar. Esta ha sido la gran lucha, y el mundo del código libre puede ser una parte esencial de este viaje. Tim O'Reilly, el editor de muchos libros y un defensor vocal del mundo del código abierto, dice: "Hemos pasado por este período de pensar en los programas como artefactos. Un objeto binario es una cosa. El código abierto es parte del pensamiento de las computadoras como un proceso". En otras palabras, hemos hecho un buen trabajo al crear computadoras que se pueden comprar listas para usar y software que se puede comprar en cajas retractiladas, pero no hemos hecho un buen trabajo al hacer posible que la gente hable con Las máquinas. En gran medida, el proceso ha sido una búsqueda de un buen lenguaje para comunicarse con la computadora. La mayor parte del desarrollo reciente siguió al trabajo en Xerox PARC que creó algunas de las primeras interfaces gráficas de usuario. Apple siguió su ejemplo y Microsoft siguió a Apple. Todos aceptaron la idea de que crear una imagen clara que representara los archivos en una pantalla sería una metáfora clara que facilitaría la interacción de las personas con las computadoras. Arrastrar un archivo a la papelera era de alguna manera más fácil para las personas que escribir un comando críptico como "rm". En la década de 1980, ese tipo de pensamiento gráfico se consideraba brillante. Las imágenes eran más bonitas que las palabras, por lo que era fácil mirar la bonita y limpia pantalla de Macintosh y pensar que era más fácil de usar simplemente porque era más fácil de mirar. Pero las características bonitas simplemente escondían una gran cantidad de complejidad, y aun así era difícil trabajar con las máquinas. Don Norman, un ingeniero de interfaz humano/computadora de Apple, escribió una vez una discusión fascinante sobre el diseño de la compañía del interruptor de encendido y apagado de su computadora. Señaló que el interruptor no podía ser un simple interruptor de alimentación que pudiera apagar y encender porque la computadora necesitaba orquestar el procedimiento de encendido y apagado. Necesitaba cerrar archivos, almacenar datos de forma segura y asegurarse de que todo estuviera listo para comenzar de nuevo. El diseño del interruptor de encendido se hizo aún más complicado por el hecho de que se suponía que funcionaba incluso cuando la computadora fallaba. Es decir, si una mala programación desordena la memoria y estropea el procesador central, se supone que el interruptor de encendido apagará la máquina. Por supuesto, la computadora ni siquiera pudo sumar dos números después de fallar, por lo que ni siquiera pudo comenzar a realizar todo el trabajo administrativo necesario para apagar la máquina. El Macintosh en el que escribí este libro puede fallar tanto que el interruptor de encendido no funciona, y solo puedo reiniciarlo metiendo un clip en un agujero oculto. El trabajo de Norman muestra lo difícil que puede ser idear un lenguaje simple que permita a los humanos y las computadoras comunicarse sobre una tarea que solía resolverse con un interruptor de luz de dos posiciones. Este problema se puede ver en toda la industria. Un tutor de informática me dijo: "Estoy tan cansado de decirle a la gente que apague sus computadoras presionando el botón 'Inicio'". Microsoft Windows coloca todas las funciones en un árbol de menús que surge de un botón llamado "Inicio". Esta puede haber sido una excelente manera de capturar el potencial para hacer cosas nuevas que sintieron que estaban vendiendo, pero sigue siendo confuso para todos los nuevos usuarios de las máquinas. ¿Por qué deberían presionar Start para detenerlo? La búsqueda de este control a nivel de Fuente puede tomar muchos giros extraños. A mediados de la década de 1980, los programadores de Apple se dieron cuenta de que habían ido demasiado lejos cuando simplificaron la interfaz de la Mac. El lenguaje visual de señalar y hacer clic en los íconos puede haber sido excelente para los nuevos usuarios, pero estaba empezando a frustrar a los usuarios sofisticados que querían automatizar lo que hacían. Muchos diseñadores gráficos se encontraban haciendo repetidamente los mismos pasos con los archivos de imagen, y era aburrido. Se preguntaron, ¿por qué la computadora no podía simplemente repetir todas sus instrucciones y ahorrarles todo eso de apuntar y hacer clic? En cierto sentido, los usuarios sofisticados de Mac buscaban la Fuente. Querían poder escribir y modificar programas simples que controlaran su software. El problema era que la pantalla gráfica de la Mac no era realmente adecuada para la tarea. ¿Cómo describirías mover el mouse y hacer clic en un botón? ¿Cómo se te ocurre un lenguaje que signifique "recorta esta muestra y pégala aquí"? Las acciones eran tan visuales que no había palabras ni lenguaje para describirlas. Este problema confundió a Apple durante los siguientes 10 años, y la compañía está terminando poco a poco su solución, conocida como AppleScript. La tarea no ha sido sencilla, pero ha sido gratificante para muchos que utilizan sus Macintosh como cadenas importantes en las líneas de producción de datos. Apple incluyó instrucciones para mover íconos a ubicaciones, cargar archivos, cambiar el color de los íconos e iniciar programas con otros. La mejor extensión fue un truco que hizo que el AppleScript fuera "grabable". Es decir, podría encender una grabadora antes de pasar por los diferentes trabajos. La Mac llevaría un registro de tus acciones y generaría un programa que te permitiría repetir lo que estabas haciendo. Aún así, los resultados estuvieron lejos de ser simples de entender o usar. Aquí hay un fragmento simple de código AppleScript que seleccionará todos los archivos en un directorio con la palabra "Speckle" en su título y los abrirá con otra aplicación: Esta fuente se puede ejecutar una y otra vez para finalizar una tarea. Poner esta herramienta a disposición de los usuarios ha sido un reto para Apple porque les obliga a facilitar la programación. Muchas personas aprenden AppleScript activando la función de grabación y observando lo que sucede cuando hacen lo que harían normalmente. Luego, aprenden a insertar algunos comandos más para realizar la tarea con éxito. Al final, se convierten en programadores que manipulan la Fuente sin darse cuenta. O'Reilly y otros creen que el esfuerzo de código abierto es solo una extensión de esta necesidad. A medida que las computadoras se vuelven más y más complejas, los desarrolladores deben hacer que el funcionamiento interno sea cada vez más abierto para los usuarios. Esta es la única forma en que los usuarios pueden resolver sus problemas y usar las computadoras de manera efectiva. "La vanguardia de la industria informática está en el infoware. No hay mucho jugo en el tipo de aplicaciones que escribimos en los años ochenta y noventa. A medida que tengamos reconocimiento de voz, iremos aún más en la dirección del código abierto, " él dice. "Cada vez hay más recetas escritas. Estas van a migrar a capas cada vez más bajas de software y la computadora tendrá un vocabulario cada vez más grande". Es decir, cada vez más la Fuente necesitará volverse transparente para los usuarios. No es solo una batalla política de Microsoft contra el mundo. No es solo la lucha de un programador meter la nariz en cada rincón de un dispositivo. Se trata de la usabilidad. Cada vez más personas necesitan escribir programas para enseñar a las computadoras a hacer lo que necesitan hacer. El acceso a la Fuente es la única forma de lograrlo. En otras palabras, las computadoras se están convirtiendo en una parte cada vez más grande de nuestras vidas. Su lenguaje es cada vez más comprensible para los humanos, y los humanos hablan mejor el lenguaje de las computadoras. Estamos convergiendo. Cuanto más lo hagamos, más importante será la Fuente. No hay nada que Microsoft o las empresas estadounidenses puedan hacer al respecto. Van a tener que acompañarlos. Van a tener que darnos acceso a la Fuente. ------------------------------- 12. Personas Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Cuando estaba en la universidad, un amigo mío en un grupo de canto a menudo modificaba a su audiencia haciéndoles recitar el "Credo del individualista" de Steve Martin al unísono. Todos proclamarían que eran individuos diferentes, únicos y maravillosamente excéntricos junto con todos los demás en la audiencia. La mordaza funcionó bien porque todos los individualistas también estaban profundamente comprometidos con vivir una vida llena de ironía. El mundo del código libre es una especie de Club Med para este tipo de individualistas. Richard Stallman logró organizar un grupo de personas altamente empleables y lograr que donaran su tiempo de más de $ 50 por hora a un movimiento prometiendo libertad total. Todos los que se presentaron valoraron la libertad mucho más que el dinero que podrían ganar trabajando para grandes empresas. No es un poco sorprendente que todos los librepensadores también presenten las mismas respuestas a la vida. Las grandes mentes piensan igual, ¿verdad? Esta gran colección de dedicados individualistas está predispuesta a momentos de fácil ironía. El negro es, con diferencia, su color favorito. El pelo largo y la barba son comunes. Las camisetas y los pantalones cortos son la regla cuando hace calor, y las camisetas y los jeans dominan cuando hace frío. Nadie usa trajes ni nada tan tradicional. Eso sería una tontería porque no son tan cómodos como las camisetas y los jeans. Encajar con los librepensadores no es difícil. El grupo no es particularmente republicano o demócrata, pero las políticas libertarias son fácilmente comprensibles y ampliamente apoyadas. El control de armas generalmente se considera incorrecto, aunque solo sea porque el gobierno federal pasará a controlar otra cosa cuando termine con las armas. [^10] Los impuestos son malos y a algunos miembros del grupo les gusta soñar con que la economía fluida y sin fricciones de Internet los ahuyentará. A la gente le gusta decir cosas como "Los gobiernos son simplemente topes en la autopista de la información". [10]: De hecho, el gobierno federal ya considera que el software de cifrado es una munición y, a menudo, trata de regularlo como tal. La primera enmienda es muy popular y muchos están seguros de que prácticamente todo lo que hacen con una computadora es una forma de discurso o expresión. El gobierno no debería tener el derecho de controlar el contenido de un sitio web porque seguramente llegará a abusar de ese poder en el futuro. Algunos incluso se enfurecen contra los planes privados para calificar los sitios web por su contenido porque están seguros de que estas herramientas eventualmente serán controladas por quienes están en el poder. En el caso más extremo, la mera creación de una lista de sitios con información no adecuada para niños es establecer la infraestructura para que los futuros nazis comiencen a quemar sitios web. Prácticamente todo el mundo cree que los códigos fuertes y la criptografía son esenciales para proteger la privacidad de una persona en línea. El intento del gobierno de EE. UU. de controlar la tecnología regulando su exportación se considera un ejemplo tonto de cómo los gobiernos intentan hacerse con el poder a expensas de sus ciudadanos. Los delincuentes ya tienen los códigos secretos; ¿Por qué las personas honestas no deberían poder proteger sus datos? La pornografía o las referencias al sexo en las discusiones son raras, aunque solo sea porque el mundo de la libido está fuera del tema principal. No es que el sexo no esté en la mente de la comunidad de software libre, es solo que las imágenes están disponibles tan libremente que no son interesantes. Cualquiera puede ir a www.playboy.com, pero no todos pueden escribir un optimizador de código descendente recursivo. La gente también rara vez jura. Si bien las palabras de cuatro letras son comunes en Wall Street y otros entornos altamente cargados, son raras en el mundo de la tecnología. Gran parte de la comunidad son niños y hombres, o quizás más correctamente "chicos". Si bien hay algunos programadores mayores que continúan cavando la emoción y la lucha del mundo del código libre, muchos son estudiantes de secundaria y universitarios con mucho tiempo extra en sus manos. Muchos de ellos son demasiado inteligentes para la escuela, y escribir software ordenado es un desafío para ellos. Las personas mayores generalmente se atascan con un trabajo y con los pagos de la hipoteca. Es difícil para ellos aprovechar la libertad que viene con el código fuente. Aún así, los más viejos que sobreviven suelen ser los mejores. Ambos tienen un profundo conocimiento y experiencia. La población promedio, sin embargo, está envejeciendo rápidamente. A medida que el software mejora, es más fácil para los trabajadores rígidos llevarlo a los entornos corporativos. Mucha gente se jacta de introducir Linux a escondidas en su oficina y reemplazar a Microsoft en algún servidor oculto. A medida que más y más usuarios encuentran una manera de ganar dinero con el software gratuito, más y más personas mayores (es decir, mayores de 25 años) pueden dedicar algo de tiempo a la revolución. Supongo que me gustaría informar que hay un buen contingente de mujeres participando en el mundo del código libre, pero no puedo. Sería bueno aislar a la comunidad del software libre de las críticas que suele encontrar cualquier grupo de hombres. Por alguna definición o razonamiento legal, estos tipos deben estar practicando alguna discriminación de facto. Alguien probablemente intentará demandar a alguien algún día. Aún así, las mujeres son escasas y es imposible usar muchas de las explicaciones estándar. Después de todo, el software es gratuito. Funciona bien en máquinas que tienen varias generaciones de antigüedad y están disponibles en montones de chatarra corporativa por varios cientos de dólares. Torvalds comenzó a escribir Linux porque no podía permitirse una versión real de UNIX. Difícilmente se puede culpar a la falta de dinero oa la parsimonia de los padres malvados y desagradables con respecto al género que se niegan a comprarle una computadora a sus hijas. De hecho, muchas de las personas en línea ni siquiera conocen el género de la persona que está al otro lado del teléfono. Los apodos indirectos como "303", "nómada", "CmdrTaco" o "Hemos" son comunes. Nadie sabe si eres un niño o una niña en línea. Es casi como el ideal de una existencia sin género propuesto por los soñadores unisex que escribieron cosas como "Free to Be You and Me", tratando de convencer a los niños de que eran libres de perseguir cualquier sueño que quisieran. A pesar de la prevalencia de estas visiones libres de género, las personas que terminaron soñando con un mundo donde todo el software fuera gratuito resultaron ser casi en su totalidad hombres. A la mayoría de los hombres les gustaría que aparecieran algunas mujeres más. Necesitan citas tanto como cualquier chico. En todo caso, la corona de Evil Discriminator podría colocarse sobre las cabezas de las chicas que desprecian a los chicos que son geeks, dweebs y nerds. Una chica no podría encontrar una mejor proporción de hombres aunque lo intentara. Esto puede cambiar en el futuro si organizaciones como LinuxChix (www.linuxchix.org) se salen con la suya. Manejan un sitio dedicado a celebrar a las mujeres que disfrutan del mundo del código abierto y han estado tratando de iniciar capítulos en todo el mundo. El sitio brinda a los miembros la oportunidad de publicar sus nombres y detalles biográficos. Por supuesto, varios de los miembros son hombres y uno es un hombre que se convierte en mujer. El miembro escribe: "Soy transexual (de hombre a mujer, antes de la operación) y en este momento todavía estoy casado legalmente con mi esposa, lo que significa que si permanecemos juntos, eventualmente tendremos un matrimonio legal entre personas del mismo sexo". ." Aún así, no tiene mucho sentido profundizar en esto porque el mundo del código libre rara vez debate este tema. Todo el mundo es libre de usar el software y contribuir con lo que quiera. Si las mujeres quieren venir, pueden. Si no lo hacen, no tienen que hacerlo para cumplir con algún mandato de la sociedad. Nadie se sienta a debatir si tenerlo todo como mujer incluye tener todo el código fuente. Se trata de la libertad de usar software, no de tener citas, aparearse o debatir los roles sexuales en la sociedad. La política racial, sin embargo, es más complicada. Gran parte de la comunidad de Linux está repartida por todo el mundo. Si bien muchos miembros provienen de los Estados Unidos, los principales contribuyentes se pueden encontrar en la mayoría de los países. Linus Torvalds, por supuesto, procedía de Finlandia, uno de los países técnicamente más avanzados del mundo. Miguel de Icaza, el desarrollador líder del escritorio GNOME, proviene de México, un país que muchos en los Estados Unidos perciben como técnicamente subdesarrollado. Jon Hall, a menudo llamado maddog, es uno de los primeros miembros de la América corporativa en reconocer que estaban sucediendo cosas geniales en todo el mundo del software de fuente abierta. Conoció a Torvalds en una conferencia y le envió una computadora digital construida alrededor del chip Alpha cuando descubrió que Torvalds quería experimentar con la migración de su software a una arquitectura de 64 bits. A Hall le encanta especular sobre la difusión del software libre en todo el mundo y dice: "¿Quién sabe de dónde vendrá la próxima gran mente? Podría ser España, Brasil, India, Singapur o me atrevería a decir Finlandia". En general, la revolución del código libre es mundial y rara vez se ve obstaculizada por barricadas raciales y nacionales. Europa está tan llena de desarrolladores de Linux como Estados Unidos, y el Tercer Mundo está pasando rápidamente del costoso Microsoft al Linux económico. El interés por Linux está en auge en China e India. El inglés es, por supuesto, el idioma predeterminado, pero otros idiomas siguen vivos gracias a mecanismos de traducción automática como Babelfish. Esta existencia sin fronteras solo puede ayudar a la difusión del software libre. Muchos países, alegando orgullo nacional, preferirían usar software desarrollado por personas locales. Muchos países desconfían explícitamente del software proveniente de los Estados Unidos porque es bien sabido que el gobierno de los EE. UU. intenta restringir el software de seguridad como el cifrado a pedido de sus agencias de recopilación de inteligencia. En noviembre de 1999, el Ministerio Federal de Finanzas y Tecnología del gobierno alemán anunció una subvención para el proyecto GNU Privacy Guard. ¿Por qué querría un país enviar todo su dinero a Redmond, Washington, cuando podría reforzar un grupo local de hackers adoptando un sistema operativo gratuito? Para todos menos para los Estados Unidos, instalar un sistema operativo gratuito puede incluso ser un gesto patriótico. 12.1 Iconos Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Los arquetipos a menudo son definidos por personas prominentes, y nadie es más central en el mundo del código libre que Richard Stallman. Algunos siguen al hombre como un discípulo, otros dicen que sus puntos de vista fuertes tiñen el movimiento y ahuyentan a la gente normal. Todo el mundo hace todo lo posible para elogiar al hombre y decirte cuánto respetan lo que ha hecho. Casi todos darán la vuelta y seguirán el cumplido con una queja velada como: "Puede ser difícil trabajar con él". Stallman es conocido por ser un hombre muy irrazonable en el sentido en que George Bernard Shaw usó la palabra cuando dijo: "El hombre razonable se adapta a la naturaleza. El hombre irrazonable busca adaptar la naturaleza a sí mismo. Por lo tanto, es solo a través de las acciones de los irrazonables". hombres que la civilización avanza". El hombre razonable todavía estaría esperando en espera mientras la gente de soporte técnico de MegaSoft jugaba con sus balones de fútbol Nerf y bromeaba sobre los pitos que necesitaban ayuda para usar su software patentado. A menudo pienso que solo alguien tan obsesionado y brillante como Stallman podría haber soñado con la Licencia Pública GNU. Solo él podría haberse dado cuenta de que era posible insistir en que todos regalaran el código fuente y les permitieran cobrar por él al mismo tiempo si así lo deseaban. La mayoría de nosotros nos habríamos bloqueado el cerebro si nos encontráramos con el sueño de un mundo de código fuente libre de trabas pero cojeando por la realidad de que necesitábamos dinero para vivir. Stallman se encontró en ese lugar en los primeros días de la Free Software Foundation y luego encontró una manera de salir del dilema cobrando por los CD-ROM y los manuales impresos. El hecho de que otros aún pudieran copiar libremente la información que obtuvieron significaba que no estaba comprometiendo su sueño central. Si Stallman es un producto del MIT, entonces uno de sus opuestos es el grupo de hackers que surgió de Berkeley y produjo el otro software libre conocido como FreeBSD, NetBSD y OpenBSD. El departamento de ciencias de la computación de Berkeley siempre tuvo un vínculo estrecho con AT&T y Sun y compartió gran parte del código UNIX inicial con ambos. Si bien hubo muchas personas en Berkeley que son muy conocidas entre los desarrolladores y los hackers, nadie se destaca como Richard Stallman. Esto se debe a que Stallman es un iconoclasta tan fuerte, no porque Berkeley sea el hogar de los inútiles que no están a la altura. De hecho, el pragmatismo de algunos de los líderes surgidos de la universidad es casi tan grande como el idealismo de Stallman, y este pragmatismo es una de las virtudes celebradas por el círculo de codificadores de Berkeley. Por ejemplo, Bill Joy ayudó a desarrollar gran parte de las primeras versiones de BSD antes de asumir un papel de fuerte liderazgo en Sun Microsystems. Sun tiene una relación polémica con el mundo del software libre. Está lejos de ser una empresa de software libre como Red Hat, pero ha contribuido con una buena cantidad de líneas de software a la comunidad de código abierto. Aun así, Sun protege ferozmente sus derechos de propiedad intelectual sobre algunos paquetes y se niega a distribuir el código fuente con una licencia oficial de código abierto. En cambio, llama a su enfoque "licencia de fuente comunitaria" e insiste en que es lo suficientemente bueno para casi todos. Los usuarios pueden leer el código fuente, pero no pueden quedarse con él y comenzar su propia distribución. Muchos otros de Berkeley siguieron el camino de Joy hacia Sun. John Ousterhout dejó su puesto como profesor en Berkeley en 1994 para trasladarse a Sun. Ousterhout era conocido por desarrollar una herramienta de secuencias de comandos bastante simple pero poderosa conocida como TCL/Tk. Una parte de él, el lenguaje de control de herramientas (TCL), era un lenguaje sencillo similar al inglés que facilitaba a las personas unir diferentes módulos de código. El usuario no tenía que ser un gran programador para trabajar con el código porque el lenguaje fue diseñado para ser sencillo. No había estructuras de datos complicadas ni punteros. Todo era una cadena de texto ASCII. La segunda parte, el kit de herramientas (Tk), contenía una variedad de widgets visuales que podrían usarse para obtener entradas y salidas de un programa. Los más simples eran botones, controles deslizantes o menús, pero muchas personas escribieron complicados que cubrían sus necesidades particulares. El proyecto TCL/Tk en Berkeley atrajo mucha atención de la red. Ousterhout, como la mayoría de los académicos, distribuyó libremente su código e hizo un buen trabajo ayudando a otros a usar el software. Él y sus alumnos reescribieron y ampliaron el código varias veces, y este apoyo constante ayudó a crear aún más seguidores. El software rascó un picor para muchos académicos que eran lo suficientemente inteligentes como para programar las máquinas en su laboratorio, pero abrumados por trabajos más importantes como hacer la investigación que se propusieron hacer. TCL/Tk obtuvo muchos seguidores porque era fácil para las personas aprender una pequeña cantidad rápidamente. Idiomas como C requerían un semestre o más para dominar. TCL podría ser recogido en una tarde. Muchos ven el pragmatismo de la licencia de estilo BSD como una forma de que los hackers de Berkeley faciliten su viaje hacia la producción de software corporativo. La gente desarrollaría las ideas no probadas de salida utilizando dinero público antes de lanzarlo con la licencia BSD. Luego, compañías como Sun comenzarían a revenderlo. Los partidarios de las licencias BSD, por supuesto, no ven el desarrollo corporativo como algo malo. Simplemente lo ven como una forma de que las personas paguen por las campanas y silbatos adicionales que un equipo dedicado e impulsado por el mercado puede agregar al software. La decisión de Ousterhout de mudarse a Sun preocupó a muchas personas porque pensaron que podría conducir a una comercialización del idioma. Ousterhout respondió con un mensaje de correo electrónico que decía que TCL/Tk seguiría siendo gratuito, pero Sun intentaría ganar algo de dinero en el proyecto vendiendo herramientas de desarrollo. "Las mejoras futuras realizadas en Tcl y Tk por mi grupo en Sun, incluidos los puertos para Mac y PC, estarán disponibles de forma gratuita para que cualquiera pueda usarlas con cualquier fin. Mi opinión, y la de las personas a las que les informo en Sun, es que De todos modos, no funcionaría que Sun intentara tomar Tcl y Tk como propietario: alguien (probablemente yo, en un nuevo trabajo) simplemente tomaría la última versión gratuita y comenzaría un camino de desarrollo independiente. Esto sería algo terrible para todos, ya que daría lugar a versiones incompatibles. "Por supuesto, Sun necesita ganar dinero con el trabajo de mi equipo o, de lo contrario, no podrán continuar apoyándonos. Nuestro plan actual es cobrar por las herramientas de desarrollo y las extensiones y aplicaciones interesantes. Equilibrar el público y el rentable será un desafío continuo para nosotros, pero es muy importante tanto para mí como para Sun mantener el apoyo de la comunidad Tcl existente", escribió. En algunos aspectos, el pragmatismo de Ousterhout era completamente diferente al de Stallman. Reconoció abiertamente la necesidad de ganar dinero y también admitió que Sun dejaba TCL/Tk libre porque sería prácticamente imposible convertirlo en propietario. La profundidad del interés en la comunidad hizo probable que una versión gratuita siguiera evolucionando. Stallman nunca haría un trato así con una empresa que distribuye software propietario. En otros aspectos, muchas de las diferencias son solo a nivel de retórica. Ousterhout trabajó para producir un compromiso que dejaría libre a TCL/Tk mientras las ventas de herramientas de desarrollo pagaban las facturas. Stallman hizo lo mismo cuando descubrió una forma de cobrarle a la gente por CD-ROM y manuales. El trabajo de Ousterhout en Sun se convirtió en una empresa llamada Scriptics que, sorprendentemente, se parece a muchos de los otros proveedores de software libre. El núcleo del producto, TCL/Tk 8.1 en este momento, se rige por una licencia de estilo BSD. El código fuente se puede descargar desde el sitio. La propia empresa, por otro lado, vende un producto más mejorado conocido como TCLPro. En muchos sentidos, el verdadero opuesto a Richard Stallman no es Bill Joy o John Ousterhout, es Linus Benedict Torvalds. Si bien Stallman, Joy y Ousterhout son productos del sistema académico de EE. UU., Torvalds es un forastero que se encontró tratando de programar en Europa sin acceso a un sistema operativo decente. Mientras que la gente de Berkeley, MIT y muchas universidades de EE. UU. pudieron acceder a UNIX gracias a las licencias cuidadosamente construidas producidas por el entonces propietario del sistema operativo, AT&T, los estudiantes en Finlandia como Torvalds quedaron excluidos. "No tenía muchas alternativas. Tenía la alternativa comercial [UNIX], que era demasiado costosa. Realmente estaba fuera del alcance de un ser humano normal, y no solo fuera del alcance en un sentido monetario, sino porque años "Antes, los vendedores comerciales de UNIX no estaban interesados ​​en vender a individuos. Estaban interesados ​​en vender a grandes corporaciones y bancos. Entonces, para una persona normal, no había otra opción", dijo a VAR Business. Cuando Linux comenzó a despegar, Torvalds se mudó a Silicon Valley y tomó un trabajo en la firma de investigación supersecreta Transmeta. En Comdex en noviembre de 1999, Torvalds anunció que Transmeta estaba trabajando en un chip informático de bajo consumo con el sobrenombre de "Crusoe". Hay, por supuesto, algunas teorías de conspiración. Transmeta está financiado por una serie de grandes inversores, incluido el cofundador de Microsoft, Paul Allen. El hecho de que eligieran emplear a Torvalds puede ser parte de un plan, piensan algunos, para distraerlo del desarrollo de Linux. Después de todo, la versión 2.2 del kernel tardó más de lo que muchos esperaban, aunque puede deberse a que sus objetivos eran demasiado ambiciosos. Cuando Microsoft necesitó una amenaza coherente para ofrecer al Departamento de Justicia, Transmeta cortésmente puso Torvalds a disposición del mundo. Pocos creen seriamente en esta teoría, pero se susurra constantemente como una broma nerviosa. 12.2 Llamas Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Las peleas y los festivales de llamas de Internet son legendarios, y el mundo del código abierto es uno de los rincones más polémicos de la red. La gente suele usar palabras fuertes como "muerte cerebral", "perdedor", "cojo", "asqueroso" y "estúpido" para describir las ideas de los demás. Si las palabras son la única forma de comunicarse, entonces la batalla por compartir la mente significa que ganan aquellos que manejan las mejores palabras. De hecho, la mayoría de los mejores hackers y miembros del mundo del código libre también son grandes escritores. Pasar días, semanas, meses y años de su vida comunicándose por correo electrónico y grupos de noticias le enseña a la gente cómo escribir bien y llegar al punto rápidamente. Internet es muy textual, y los programadores informáticos de núcleo duro tienen mucha experiencia en escupir texto. Como todo programador sabe, se supone que debes enviar un correo electrónico a la persona que está a tu lado si quieres programar el almuerzo. Esa persona podría estar en medio de algo. Por supuesto, existe el peligro de hacer una generalización radical que implica que el mundo del código libre está lleno de grandes escritores. El hecho es que es posible que no hayamos tenido noticias de los no tan grandes escritores que se sientan al acecho en la red. Si bien algunos de los estudiantes que lideraron las revoluciones de 1968 fueron bastante elocuentes, muchas de las masas teñidas también estaban en la imagen. No te los podías perder. En Internet, la persona silenciosa es invisible. Algunos argumentan que el mundo del software libre ha florecido porque la gente silenciosa adoptó el código fuente disponible gratuitamente. Cualquiera podía descargar el código fuente y jugar con él sin pedir permiso ni gastar dinero. Eso significaba que los niños de 13 años podían comenzar a usar el software sin pedir dinero a sus padres. SCO Unix y Windows NT cuestan mucho dinero. Esta libertad también se extendió a los programadores en el trabajo. En muchas empresas, los responsables informáticos son doctrinarios y oficiosos. A menudo desarrollan rápidamente reacciones instintivas a las tecnologías y utilizan estos estereotipos para tomar decisiones técnicas. El software libre como Linux fue rechazado con frecuencia por los guardianes, quienes pensaron que algo debía estar mal con el software si nadie lo cobraba. Sin embargo, estas actitudes no pudieron detener a los ingenieros que querían experimentar con el software libre, porque no tenía una orden de compra que necesitara aprobación. La cualidad del hombre invisible es una parte importante del mundo del software libre. Si bien he descrito los cuerpos y rostros de algunos de los chicos del cartel de código libre más conocidos, es imposible decir mucho sobre muchos de los otros. La comunidad se extiende a través de Internet en todo el mundo. Muchas personas que trabajan de cerca en proyectos nunca se conocen. El mundo físico con todas sus formas de codificar una posición en una jerarquía se ha ido. Nadie puede decir lo rico que eres por tus zapatos. El color de tu piel no se registra. Se trata de tecnología e ideas tecnológicas. De hecho, hay un cierto grado de Emily Dickinson en el mundo. Así como esa alma seleccionó su propia sociedad y cerró la puerta al resto del mundo, el mundo del software libre frecuentemente se divide y vuelve a dividirse en grupos más pequeños. Si bien hay algo de polinización cruzada, muchos están felices de vivir en sus propios rincones. OpenBSD, FreeBSD y NetBSD son países más separados que socios en el crimen. Evolucionan por su cuenta, ocasionalmente robando ideas y código fuente para cerrar la brecha. Muchos escritores han descrito algunos de sus problemas para sacar provecho del mundo de Silicon Valley. Los guionistas y productores de televisión a menudo inician proyectos para aprovechar la rica textura de los nerds solo para descubrir que no hay nada tan convincente para filmar. Son solo millas y millas de edificios con estructura de acero que contienen acres y acres de cubículos. Claro, hay algunas mesas de ping-pong y máquinas de pinball, pero todo el trabajo está en la mente. Los ojos quieren acción física, y toda la emoción en un mundo de código libre está en las ideas. Pero la gente es gente. Si bien no existe una manera fácil de usar los viejos recursos de raza o ropa para discriminar, el mundo técnico aún desarrolla formas de clasificar a sus miembros y ubicarlos en campamentos. El mundo del software libre tiene sus propias formas de distinguir entre estos campos. La mayor distinción puede estar entre las personas que favorecen la GPL y las que usan la licencia de estilo BSD para proteger su software. Esta es probablemente la decisión más importante que debe tomar un creador de software libre porque controla si otros podrán crear versiones comerciales del software sin contribuir con el nuevo código al proyecto. Las personas que abrazan la GPL tienen más probabilidades de abrazar a Richard Stallman, o al menos menos probabilidades de maldecirlo en público. Tienden a ser iconoclastas e individualistas. Los proyectos de GPL tienden a ser más cultos y están impulsados ​​por una extraña mezcla de personalidad e histeria que no es genial. La gente del lado de la licencia estilo BSD, por otro lado, parece pragmática, organizada y enfocada. Solo hay tres versiones gratuitas principales de BSD UNIX, y son notables porque cada una tiene colecciones de archivos administradas centralmente. El Linux protegido por GPL se puede comprar de al menos seis grupos principales que lo agrupan, y cada uno de ellos incluye paquetes y piezas de software que encuentran por toda la red. La gente con licencia BSD también es menos culta. Los chicos grandes del cartel, Torvalds y Stallman, son hombres GPL. Las versiones gratuitas de BSD, que ayudaron a darle a Linux gran parte de su base, son ignoradas en gran medida por la prensa por todas las razones equivocadas. Los equipos de BSD parecen estar fragmentados porque son todas organizaciones políticas separadas que no tienen vínculos formales. Hay muchos colaboradores, lo que significa que BSD no tiene un líder carismático importante con una historia tan convincente como la de Linus Torvalds. Muchos colaboradores podrían usar este manto y muchos han creado tanto código. Pero la vida, o al menos la descripción que hacen los medios de ella, está lejos de ser justa. El buque insignia del mundo BSD puede ser el grupo de servidores web Apache, que contribuyó en gran medida al éxito de la plataforma. Este equipo central no tiene una persona que se destaque como líder. La mayoría de las personas en el equipo están totalmente empleadas en el negocio web, y varios miembros del equipo dijeron que el equipo de Apache era simplemente una buena manera para que las personas avanzaran en sus trabajos diarios. No fue una cruzada para ellos liberar el código fuente de la cárcel. El servidor web Apache está protegido por una licencia estilo BSD que permite la reutilización comercial del software sin compartir el código fuente. Sin embargo, es un programa separado y muchos usuarios de Linux ejecutan el software en cajas de Linux. Por supuesto, esta devoción por los negocios y la disposición relativamente tranquila no siempre es cierta. A Theo de Raadt, el líder de la facción OpenBSD, le gusta hacer proclamaciones audaces. En su entrevista conmigo, descartó a la Free Software Foundation como terriblemente mal nombrada porque no eras realmente libre de hacer lo que quisieras con el software. De hecho, es fácil llevar estos estereotipos demasiado lejos. Sí, la gente de GPL puede ser agresiva, franca, de pensamiento rápido, impulsiva y tempestuosa. Claro, la gente de BSD es organizada, minuciosa, convencional, dedicada y precisa. Pero siempre hay excepciones a estas reglas, y la gente de cada campamento las detectará rápidamente. Alguien podría señalar que Alan Cox, uno de los firmes guardianes de los kernels de Linux protegidos por GPL, no es particularmente llamativo ni dado a escribir largos manifiestos en la red. Otros podrían decir que Brian Behlendorf ha sido un gran defensor del proyecto Apache. Ciertamente no ha evitado defender la licencia BSD, aunque no de la forma que a Stallman le hubiera gustado. Después de todo, fue uno de los miembros del equipo Apache que ayudó a convencer a IBM de que podían usar el servidor web Apache sin peligro. Después de BSD versus GPL, la siguiente falla más grande es la elección del editor. Algunos usan el vi relativamente simple, que surgió de Berkeley y las primeras versiones de BSD. Otros se adhieren a Emacs de Stallman, que es mucho más barroco y extremo. El campamento vi ama la simplicidad. Los fans de Emacs se jactan de cómo han programado su versión de Emacs para irrumpir en la Casa Blanca, tomar fotografías secretas de personas en posiciones comprometedoras, enrutarlas a través de un reenviador anónimo y negociar un gran reembolso de impuestos, todo con un control complicado: pulsación de tecla meta-trans. Si bien esta guerra es bien conocida, tiene poca importancia práctica. Las personas pueden elegir por sí mismas y sus elecciones no tienen ningún efecto sobre los demás. GPL o BSD pueden afectar a millones; vi versus Emacs no hace una gran diferencia. Es solo una de las interminables controversias de mordaza en el universo. Si Entertainment Tonight estuviera cubriendo el mundo del software libre, pasarían horas catalogando qué estrellas usan vi y cuáles usan Emacs. ¿Shirley MacLaine usó vi o Emacs o incluso wordstar en una vida anterior? Algunas de las otras fallas no son tan nítidas, pero terminan siendo muy importantes. La cantidad de orden o falta de orden es un punto de distinción importante para muchas personas de código libre, y hay un amplio espectro de opciones disponibles. Si bien el hecho de que todo el código fuente se redistribuya libremente enloquece al reino, muchos grupos intentan controlarlo con cantidades variables de orden. Algunos grupos están organizados fanáticamente. Otros son más anárquicos. Cada uno tiene un temperamento particular. Los tres proyectos BSD son bien conocidos por mantener el control de todo el código fuente de todo el software de la distribución. Están administrados de manera muy centralizada y se jactan de mantener todo el código fuente junto en un árbol de compilación. Las distribuciones de Linux, por otro lado, incluyen software de muchas fuentes diferentes. Algunos incluyen el escritorio KDE. Otros eligen GNOME. Muchos incluyen ambos. Algunos de los grupos tienen trabajos cuidadosamente delineados. El grupo Debian elige un presidente y pone personas a cargo de secciones particulares de la distribución. O quizás más correctamente, los individuos se nominan a sí mismos para los trabajos que pueden realizar. El grupo es lo más parecido a un gobierno que existe en el mundo del software abierto. Muchas de las pautas de la Iniciativa de código abierto sobre lo que se ajusta a la definición de "código abierto" evolucionaron a partir de las reglas anteriores redactadas por el grupo Debian para ayudar a definir lo que podría y no podría incluirse en una distribución oficial de Debian. El grupo OpenBSD, por otro lado, abre gran parte del árbol de código fuente a todos los miembros del equipo. Cualquiera puede hacer cambios. Las áreas centrales, por otro lado, todavía están controladas por líderes. Algunos grupos se han convertido en fuerzas de marketing muy eficaces. Red Hat es una empresa bien administrada que tiene equipos de marketing que venden a las personas sobre la actualización de su software, así como equipos de ingeniería con el trabajo de escribir código mejorado para incluirlo en futuras versiones. Red Hat empaqueta su distribución en cajas que se venden a través de canales de venta normales como librerías y catálogos. Tienen una gran presencia en ferias comerciales como LinuxExpo, en parte porque ayudan a organizarlas. Otros grupos como Slackware abrieron recientemente un sitio web. OpenBSD vende copias para ayudar a pagar sus facturas de Internet, no para expandir su fuerza de marketing. Algunas distribuciones solo están disponibles en línea. En muchos casos, no existe un espectro claro definido entre el orden y la anarquía. Los grupos solo tienen sus propias marcas de orden. OpenBSD se jacta de detener las fugas de seguridad y pasar dos años sin una intrusión a nivel de raíz, pero algunas de sus ilustraciones son un poco desaliñadas. Red Hat, por otro lado, ha estado trabajando cuidadosamente para hacer que Linux sea fácil de usar para todos, pero no están tan enfocados en los detalles de seguridad. Por supuesto, esta cantidad de pedido siempre es un término relativo. Ninguno de estos grupos tiene fuertes líneas de control. Todos ellos dependen de las contribuciones de las personas. Los problemas solo se resuelven si alguien se preocupa lo suficiente como para hacerlo. Este desorden está cambiando un poco ahora que compañías serias como Red Hat y VA Linux están entrando en escena. Estas empresas pagan a programadores de tiempo completo para asegurarse de que sus productos estén libres de errores y sean fáciles de usar. Si su gestión hace un buen trabajo, el mundo del software de código abierto puede volverse más ordenado y, de hecho, anticipar más problemas en lugar de esperar a que llegue la persona adecuada con el tiempo y la inclinación para resolverlos. Estas son solo algunas de las principales fallas. Prácticamente todos los proyectos vienen con distinciones técnicas importantes que dividen a la comunidad. ¿Es Java un buen lenguaje u otro intento de control corporativo? ¿Cómo debe manejar el servidor web Apache básico las tarjetas de crédito? ¿Cuál es la mejor manera de manejar los procesadores de 64 bits? Hay miles de diferencias, cientos de fallas, decenas de argumentos arquitectónicos y docenas de licencias. Pero al menos todas las personas están de acuerdo en una cosa: leer el código fuente es esencial. --------------------------------------- 14. Caridad El movimiento de código abierto está lleno de personas que analizan software, buscan errores y buscan soluciones. Estos caballos de batalla silenciosos son la base del éxito del movimiento. Un miembro de este ejército es David Baron, un estudiante universitario que comenzó en Harvard en el otoño de 1998 y descubrió, como la mayoría de los estudiantes, que tenía un poco de tiempo libre. Algunos estudiantes recurren al teatro, algunos al periódico, algunos a la juerga, algunos a los equipos atléticos, algunos a la bebida, y la mayoría elige uno o más de los anteriores. Algunos estudiantes buscan algún trabajo caritativo en su tiempo libre y se ofrecen como voluntarios en un refugio u hospital para personas sin hogar. A los estudiantes de derecho les encanta trabajar en la clínica legal gratuita para los pobres. Baron, sin embargo, es un poco nerd en todos los buenos sentidos de la palabra. Ha estado trabajando en la limpieza del proyecto de navegador de código abierto de Netscape conocido como Mozilla, y cree que es un gran acto de caridad. Baron pasa su tiempo libre hurgando en el motor de diseño de Mozilla responsable de organizar los gráficos, el texto, las ranuras de los formularios, los botones y todo eso de manera consistente. Los diseñadores gráficos quieren que todos los navegadores web en la Red se comporten de manera consistente y han estado agitados para intentar que las compañías de navegadores (Netscape, Microsoft, iCab, WebTV y Opera) se adhieran a un conjunto de estándares desarrollados por la W3C, el Consorcio World Wide Web con sede en el MIT. Estos estándares explican exactamente cómo se supone que los navegadores deben manejar instrucciones de diseño complicadas, como hojas de estilo en cascada. Baron miró estos estándares y pensó que eran una buena idea. Si todos los navegadores web manejaran el contenido de la misma manera, desaparecerían los pequeños botones que dicen "Mejor visto con Microsoft IE" o "Mejor visto con Netscape". Las empresas de navegadores podrían competir en funciones, no en su capacidad para mostrar páginas web más raras. Dejaría fuera a los diseñadores web de la batalla entre Microsoft y Netscape. Los estándares también ayudan a los usuarios, especialmente a los usuarios con diferentes necesidades. Me dijo: "Los estándares (particularmente CSS) fomentan la accesibilidad para los usuarios con todo tipo de discapacidades porque permiten a los autores usar HTML como se pretendía originalmente: como un lenguaje de marcado estructural que pueden interpretar los navegadores que muestran cosas en medios no visuales. o en fuentes muy grandes para usuarios con problemas de visión. Cambiar el HTML en la web de nuevo al marcado estructural también permitirá que estos navegadores produzcan resultados sensibles". Manejar estándares como este siempre es un problema político para las empresas. Cada desarrollador trata de meter los dedos en el viento y ver qué estándares serán importantes y cuáles se quedarán en el camino. Microsoft, Netscape, iCab, WebTV y Opera se han estado preguntando acerca de las hojas de estilo en cascada porque son como un dolor de cabeza. Idealmente, los diseñadores gráficos podrán crear reglas gráficas para un conjunto de páginas web y se aplicarán utilizando las reglas establecidas por el lector. CSS no se trata de "control total por parte del autor de la página", dice Baron. "La idea básica de la cascada es que las preferencias del usuario (a través de la interfaz de usuario del navegador o posiblemente a través de una hoja de estilo CSS del usuario) y las sugerencias del autor (contenidas en las hojas de estilo CSS) se combinan para producir el formato de la página". Un conglomerado de catálogos moderno, por ejemplo, puede tener dos sucursales. Uno estaría dirigido a hombres de mediana edad que adoran sus autos dándoles interminables trabajos de cera y limpiándolos para siempre. Otro podría estar dirigido a las madres jóvenes que adoran a sus hijos, en parte manteniendo el hogar tan limpio como sea posible. Normalmente, la compañía de catálogos usaría diferentes diseñadores para crear catálogos de aspecto muy diferente. Uno vendría con gráficos retro de bordes duros cubiertos con rayas de carreras y el otro con estampados florales. ¿Qué sucede cuando estos catálogos se dirigen a la web? Normalmente, dos diseñadores le darían a dos sitios web diferentes dos apariencias diferentes. ¿Qué pasa si hay un producto de limpieza, digamos un limpiador de llantas de automóvil, que aparece en ambos catálogos? En los viejos tiempos, antes de las hojas de estilo en cascada, ambos diseñadores tenían que hacer cada página por separado. Un sistema bien diseñado de hojas de estilo en cascada permitiría que una página web para el producto se muestre correctamente en ambos sitios. Recogería los estampados florales o las franjas de carreras automáticamente cuando cualquiera de los sitios lo llamara. Estos estándares son notoriamente difíciles de hacer cumplir. Los ejércitos de todo el mundo sueñan con producir soldados rasos perfectos que puedan insertarse en cualquier conflicto en cualquier pelotón sin ningún tipo de reentrenamiento. Los periódicos sueñan con tener reporteros intercambiables que puedan cubrir la Casa Blanca o un partido de cricket en la India. No es de extrañar que la industria web quiera lo mismo. Baron me dijo: "Me interesé en Mozilla porque me interesan los estándares web". Se dio cuenta de que un grupo conocido como Web Standards Project estaba realizando una campaña política para presionar a las empresas de navegadores para que diseñaran las páginas de la misma manera (www.webstandards.org). "Un grupo de desarrolladores se reunió y dijo: 'Los navegadores no son compatibles con los estándares' y esto hace que sea imposible crear páginas", explicó Baron. "Si cada navegador admite los estándares de una manera diferente, entonces debe diseñar una versión diferente del sitio para cada navegador. O, de manera más realista, los diseñadores web recurren a trucos que hacen que la página sea legible en todos los navegadores 'principales' pero no es accesible para personas con discapacidades o personas con computadoras más antiguas". Por supuesto, una cosa es que un diseñador web o un maestro web acepte esta llamada. Baron, sin embargo, era solo un estudiante de primer año de la universidad que enmarcó esto como trabajo voluntario. Cuando se topó con el Proyecto de Estándares Web, escuchó su mensaje y vio una picazón que quería rascarse. "Quiero ver que los estándares se respalden correctamente. Alguien tiene que hacerlo", me dijo. "También podría estar haciendo esto en lugar de jugar y mirar sitios web todo el día. Mucha gente hace trabajo voluntario, pero no mucha gente llega a hacer trabajo voluntario a este nivel. Utiliza lo que sé bastante bien. Muchos estudiantes que son muy inteligentes terminan haciendo trabajo voluntario que no usa sus habilidades. Cuando puedes hacer trabajo voluntario que usa lo que sabes, es aún mejor". Entonces, Baron descargaría las últimas versiones del motor de diseño de Mozilla conocido como Gecko y jugaría con las páginas web. Creaba páginas web extrañas con hojas de estilo extrañas, las cargaba y observaba dónde se rompían. Cuando las cosas salían mal, escribía informes de errores detallados y los enviaba por correo a la gente que hacía la codificación. Formaba parte de un equipo de control de calidad que incluía algunos empleados de Netscape y una amplia variedad de otros usuarios de la red. Esta participación de la comunidad era lo que quería Netscape cuando creó Mozilla. Esperaban que más personas se encargaran de probar el código y al menos presentar quejas cuando las cosas iban mal. Un hacker llamado James Clark, que no está relacionado con el fundador de Netscape con el mismo nombre, introdujo un analizador XML completo, una herramienta para desarmar el último superconjunto de HTML que está captando la atención de los diseñadores de software y web. Baron es una de las pocas personas que conocí mientras escribía este libro que enmarca su trabajo en un proyecto de código abierto como caridad. La mayoría de los devotos se involucran en los proyectos porque les ofrecen la libertad de meterse con el código fuente. La mayoría también cita las ventajas prácticas del código abierto, como las correcciones de errores relativamente rápidas y la estabilidad de los proyectos bien ejecutados. A la mayoría de la gente le gusta distanciarse de los agitadores más políticos del movimiento del software libre, como Richard Stallman, señalando que ellos no están realmente en esto para lograr la segunda venida de la Revolución Comunista. Pocos sugieren que su trabajo es una especie de regalo de su tiempo que podría hacer del mundo un lugar mejor. Pocos comparan su trabajo con el de la gente que limpia albergues u hospitales para personas sin hogar. La mayoría no está en desacuerdo cuando se les señala, pero la mayoría de los hackers de software libre no despliegan la retórica caritativa para explicar lo que están haciendo. Esto puede ser sólo una diferencia de clase. Baron es un estudiante de segundo año, como está escrito, en Harvard y Harvard es, por definición, una escuela de acabado para la clase alta. Incluso el vasto mar de niños de familias de clase media y escuelas públicas termina hablando y actuando como si hubieran salido de Choate o Exeter al final de su tiempo en Harvard. Recogen el noblesse oblige de Kennedy que de alguna manera ordena a los ricos y afortunados que ayuden a los pobres con actos muy públicos de ayuda. Simplemente se filtra en todos esos niños de Harvard. La mayoría de los miembros del software libre, por otro lado, son una especie de parias. Los hackers provienen de todas partes del mundo y de todos los rincones de la jerarquía social, pero pocos de ellos pertenecen a la gente hermosa que se desliza por la vida sobre rieles dorados. Los programadores suelen tener la cabeza en nubes matemáticas extrañas y obtusas en lugar de las nubes sobrecargadas del Olimpo. Se preocupan por construir un software limpio y hacer girar estructuras abstractas maravillosas que se entrelazan en patrones elegantes que se repiten sin fin. Si estuvieran interesados ​​en el poder o el prestigio social, no estarían pasando las noches frente a una terminal esperando que se compile algún código. Pero que el movimiento del software libre no utilice muy a menudo la tarjeta de caridad, no significa que el trabajo sea muy diferente al de los albergues para personas sin hogar. De hecho, tan poco dinero cambia de manos que no hay muchas razones para que la gente descuente sus donaciones de sus impuestos. Las donaciones de tiempo no cuentan. Tal vez algunas empresas podrían borrarlo de sus libros, pero eso es todo. De hecho, Baron tiene razón en que un trabajo como el suyo puede marcar la diferencia para las personas. El software es una parte creciente del costo de una computadora hoy en día. En las PC de gama baja, el sistema operativo de Microsoft puede costar más que el procesador o la memoria. Un sistema operativo gratuito con un navegador web gratuito que funcione correctamente puede ayudar a las miles de escuelas, refugios para personas sin hogar, hospitales y centros recreativos a conectarse a la web a un costo más económico. La organización benéfica de software libre suele ser un poco más limpia. Bill Gates y muchos de los otros millonarios de Microsoft no se avergüenzan de regalar dinero real a escuelas y otras organizaciones necesitadas. Melinda Gates, la esposa de Bill, dirige una fundación benéfica que es muy generosa. En 1999, por ejemplo, la fundación hizo una donación muy real de dinero para la matrícula de estudiantes de minorías. La fundación también ha donado millones de dólares para ayudar a financiar la investigación médica en todo el mundo. Aún así, en otras ocasiones, ha habido un borde astuto en la benevolencia de Gates. En algunos casos, la empresa regala millones de dólares en software de Microsoft. Esto ayuda a que los niños se acostumbren a los productos de Microsoft y actúa como publicidad sutil. Por supuesto, no hay nada nuevo en este tipo de caridad. La mayoría de las corporaciones insisten en que reciben algo de publicidad por sus donaciones. Así es como justifican la benevolencia a sus accionistas. El valor de regalar copias de software es un acto difícil de medir. Un millón de copias de Windows 95 pueden venderse al por menor por alrededor de $100 millones, pero el costo para Microsoft es significativamente menor. Los CD-ROM cuestan menos de un dólar para duplicar, y muchas escuelas probablemente recibieron un CD-ROM para todas sus máquinas. Brindar soporte a los usuarios es un costo importante, pero puede controlarse y limitarse restringiendo la cantidad de empleados dedicados a líneas telefónicas particulares. Determinar el valor de toda la benevolencia debe ser un trabajo duro para los contadores fiscales. La forma en que Microsoft eligió dar cuenta de sus donaciones es un asunto privado entre Gates, el Servicio de Impuestos Internos y su Dios. Considere el ejemplo de una compañía imaginaria de software propietario llamada SoftSoft que regala un millón de copias de su producto WidgetWare de $50 a escuelas y organizaciones benéficas en los Estados Unidos. Esto es, en muchos sentidos, generoso porque SoftSoft solo vende 500.000 copias al año, lo que les da ingresos brutos de $25 millones. Si SoftSoft valora el obsequio al valor total de mercado, tiene una deducción de $50 millones, lo que claramente los coloca en números rojos y fuera del alcance de los impuestos para el año. Probablemente puedan llevar adelante la pérdida y eliminar también las ganancias del próximo año. Es posible que los contadores no elijan ser tan aventureros. El IRS podría insistir en que deduzcan el costo de los bienes entregados, no su precio de mercado potencialmente inflado. Imagine que el costo de la compañía para desarrollar WidgetWare llegó a $21 millones. Si no hubiera ningún regalo, tendrían una buena ganancia de $4 millones. SoftSoft podría dividir los costos de desarrollo de $21 millones entre las 1,5 millones de unidades que se envían. En lugar de deducir el valor de mercado del software, solo deduciría los costos que se le asignaron. Aún así, eso significa que obtienen una deducción de $ 14 millones, que aún está lejos de ser mala. Las empresas más conservadoras pueden presentar deducciones más pequeñas basadas en el costo de duplicar las copias adicionales y el costo de apoyar a las escuelas y organizaciones benéficas. Las medidas contables estrictas serían las más honestas, pero es difícil saber qué hacen las empresas y qué deberían hacer. El software libre, por supuesto, evita todo ese papeleo y contabilidad. El software no cuesta nada, por lo que regalarlo no genera deducción. No hay necesidad de contabilidad de costos complicada o grandes comunicados de prensa. Simplemente se encuentra en el servidor web y la gente lo descarga. Por supuesto, es posible comenzar a contar las descargas y hacer algunas multiplicaciones para obtener números escandalosos. Windows NT puede venderse entre $200 y $1,000. Hay alrededor de 3,7 millones de servidores web que ejecutan Apache, según la última encuesta de Netcraft. Si el 1 por ciento califica como sitios de caridad, Apache atiende a 37,000. Por supuesto, no todos los sitios se ubican en máquinas separadas. Para corregir esto, suponga que cada servidor alberga 10 máquinas y solo hay 3700 máquinas que utilizan Apache. Eso sigue siendo alrededor de $ 3.7 millones en donaciones. Pero números como este realmente no pueden capturar la profundidad del regalo. A Linus Torvalds siempre le gusta decir que comenzó a escribir Linux porque no podía permitirse un sistema operativo decente para su máquina, por lo que pudo hacer algunos experimentos. ¿Quién sabe cuántos niños, adultos e incluso jubilados están pirateando Linux ahora y haciendo algunos experimentos informáticos sofisticados porque pueden hacerlo? ¿Cómo contamos esta beneficencia? El software libre esencialmente elimina la burocracia y el carácter institucional de la caridad. No hay tableros. No hay conteo de regalos. No hay adulación ni adulación. No hay nuevas J. Henry P. Plutocrat Wings para el Museo de Filantropía Franklin P. Moneysucker. Es solo un regalo puro sin gastos generales. También hay una eficiencia fluida en el mundo de la caridad del software libre. Mi profesor de economía solía bromear diciendo que los regalos eran muy ineficientes. Las abuelas siempre compraban suéteres fuera de moda para sus nietos. Si los dejaban solos, los niños regalaban dulces y animales de peluche a sus padres en sus cumpleaños y Navidad. Todas estas malas decisiones deben ser devueltas o desechadas, arruinando la eficiencia de la economía. El profesor concluyó diciendo: "Entonces, muchachos, cuando tengan una cita, no se molesten con las flores. Olvídense de las joyas. Solo denle efectivo". El software libre, por supuesto, no encaja en muchos de los modelos estándar de la teoría económica. Regalar las cosas no cuesta mucho dinero y aceptarlas a menudo requiere un poco de trabajo. Las viejas reglas de la entrega de regalos y la caridad en realidad no se aplican. Imagina que una abuela escribió un software complicado para calcular los patrones para tejer suéteres. Algunos probablemente lo hayan hecho. Si regalan el código fuente, termina en la gran cantidad de código fuente gratuito y otros tejedores pueden encontrarlo. Puede que no ayude a ningún nieto, al menos no durante 20 o 30 años, pero se trasladará al lugar donde pueda hacer el mayor bien con la menor fricción posible. El software pirateado por los niños, por otro lado, fluiría de niño a niño sin llegar a los padres. Las herramientas de software para generar chistes tontos y clasificar tarjetas de chicle harían felices a una generación de niños, y podrían intercambiarlos sin que sus padres o abuelos se interpusieran. Las ineficiencias de la entrega de obsequios a menudo pueden afectar a las organizaciones benéficas, que tienen menos libertad para ser exigentes que los nietos. Las organizaciones benéficas no pueden mirarle los dientes a un caballo regalado. Si una empresa quiere dar a un refugio para mujeres 1.000 impermeables nuevos para hombres, es probable que el refugio los acepte. Rechazarlos puede ofender a los posibles contribuyentes que podrían darles algo de valor en el próximo trimestre. El código fuente gratuito no tiene ninguna de estas ineficiencias. Sitios web como Slashdot, Freshmeat, Linux Weekly News, LinuxWorld, KernelTraffic y cientos de otros portales de Linux o de proyectos específicos hacen un gran trabajo al trasladar el software a las personas que pueden utilizar su valor. La gente escribe el código y luego otras personas descubren el valor que tiene. El código incorrecto o innecesario no se le impone a nadie. El software libre también evita ser pintado como un esquema fiscal cínico. No es raro que los fabricantes de medicamentos donen algunas píldoras excedentes para operaciones de socorro en casos de desastre. En algunos casos, los fabricantes vacían sus estanterías de pastillas que están a punto de caducar y, por tanto, a punto de ser destruidas. Toman un pasivo y lo convierten en un activo deducible de impuestos. Esto puede ser una buena idea cuando se necesitan los medicamentos, pero a menudo son superfluos. En muchos casos, las drogas simplemente terminan en un vertedero. Las organizaciones de socorro aceptan millones de dólares en medicamentos para obtener unos cuantos miles de dólares de los que realmente necesitan. 14.1 Organizaciones benéficas de código abierto Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Por supuesto, hay algunas organizaciones benéficas de código abierto. La Free Software Foundation de Richard Stallman es una organización benéfica 501(c)(3) exenta de impuestos que recauda dinero y solicita donaciones deducibles de impuestos. Este dinero se usa para pagar las computadoras, los gastos generales y los salarios de los jóvenes programadores que tienen grandes ideas para el software libre. El Proyecto Debian también tiene una rama benéfica conocida como Software de interés público que recauda dinero y equipos informáticos para apoyar la creación de más software libre. Estas organizaciones son ciertamente parte del mundo de las deducciones de impuestos, la recaudación de fondos y el complejo industrial de caridad. La Free Software Foundation, por ejemplo, señala que puede hacer arreglos para que todo o parte de su donación a United Way vaya a la Fundación. Pero también hay diferencias. Stallman, por ejemplo, está orgulloso del hecho de que no acepta ningún salario ni reembolso de viajes de la Free Software Foundation. Trabaja 2 meses al año para mantenerse y luego dona los otros 10 meses al año para recaudar dinero para ayudar a otros programadores a trabajar en proyectos de la Fundación. Sus presupuestos también son bastante manejables. Perens señala que el presupuesto de Debian es de unos 10.000 dólares al año y se gasta en gran medida en la distribución del software. Los servidores que admiten mucho tráfico cuestan una buena cantidad de dinero, pero el grupo recibe donaciones de hardware y ancho de banda. El grupo también imprime una gran cantidad de CD-ROM con el software. Los grupos también insisten en que un buen código es más valioso que el dinero. La Free Software Foundation, por ejemplo, enumera los proyectos que necesitan trabajo junto a su solicitud de dinero. Se necesitan voluntarios para escribir documentación, probar software, organizar la oficina y también escribir más código. Jordan Hubbard, el director del proyecto FreeBSD, dice que el dinero no siempre es el mejor regalo. "Acepto donaciones de sumas de más de seis dígitos casi cualquier día", dice, y explica que FreeBSD alienta a las empresas a donar parte del tiempo libre de sus empleados. Sugiere que las empresas asignen un trabajador al proyecto FreeBSD durante uno o dos meses si hay tiempo libre. "Los empleados también nos dan una idea de cuáles son las necesidades de la empresa. Todos esos empleados cooptados traen de vuelta las necesidades de su lugar de trabajo. Esas son relaciones laborales realmente valiosas", continúa. Hubbard también descubrió que el dinero a menudo no es el mejor motivador. Resulta que el hardware a menudo funciona bien para extraer trabajo de los programadores. Le gusta enviar a un programador uno de los periféricos más nuevos, como una unidad de DVD o un joystick, y pedirle que escriba un controlador para la tecnología a cambio. "Es mucho más rentable comprarle a alguien una pieza de hardware de $ 500, lo que a su vez lo motiva a donar miles de dólares en trabajo, algo que probablemente no podríamos pagar de todos modos", dice. El dinero sigue siendo importante, sin embargo, para ocuparse de todos los trabajos que no se pueden realizar despertando la curiosidad de alguien. "El área para la que necesitamos más contribuciones es la infraestructura. Las tareas de secretaría no son divertidas y no quieres que los voluntarios las hagan", dice. Todas estas organizaciones benéficas crecerán en los próximos años a medida que el movimiento del software libre se vuelva más sofisticado. En algunos casos será porque los hackers a los que les encantaba jugar con las computadoras descubrirán que el sistema fiscal es solo otro montón de códigos llenos de errores que buscan ser pirateados. En la mayoría de los casos, sin embargo, creo que será porque las grandes empresas con sus sofisticados abogados fiscales se interesarán. No me sorprendería si una versión futura de este libro incluye un tratamiento muy cínico de los hábitos fiscales de algunas organizaciones de código abierto. Una vez que una idea alcanza una masa crítica, es imposible protegerla de las fuerzas de la corrupción menor y mayor. 14.2 Regalos Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Marcel Mauss fue un antropólogo que estudió las tribus de la esquina noroeste de América del Norte. Su libro Gift: The Form and Reason for Exchange in Archaic Societies explica cómo las tribus como los Chinook, los Tlinget y los Kwakiutl pasaban los meses del otoño dando y asistiendo a grandes fiestas. Cada año, los miembros de la tribu tomaban la recompensa de la cosecha y organizaban un festín para sus amigos. La gente que asistía podía pasar un buen rato, pero luego estaban obligados a dar un festín de igual o mayor valor el próximo año. A muchos antropólogos del mundo del software libre les gusta establecer paralelismos entre estas fiestas, conocidas como potlatches en una tribu, y el mundo libre del software de fuente libre. Los hackers están regalando el código fuente de la misma manera que los miembros de la tribu regalaban salmón o carne de venado. La comparación ofrece una idea de la vida en la comunidad del software libre. Algunas convenciones como LinuxExpo y los cientos de festivales de instalación son como fiestas. Una empresa en una LinuxExpo estaba sirviendo cerveza en su stand para llamar la atención. Por supuesto, Netscape celebró su decisión de lanzar el proyecto Mozilla con una gran fiesta. Luego lanzaron otro en el primer cumpleaños del proyecto. Pero el dar va más allá de las fiestas y las conferencias. Dar grandes paquetes de software crea una posición social de la misma manera que dar un banquete lujoso lo establecerá como un miembro importante de la tribu. Hay una especie de orden jerárquico, y los codificadores de grandes sistemas como Perl o Linux están cerca de la cima. Las personas en la parte superior de la pirámide a menudo tienen más suerte al pedir ayuda a otros programadores, lo que les permite hacer su trabajo un poco mejor. Muchos gerentes justifican dejar que sus empleados contribuyan a la comunidad de software libre porque construyen una red social a la que pueden acceder para terminar sus trabajos oficiales. Pero hay una diferencia entre el potlatch tribal y el software libre. Las fiestas de potlatch construyeron lazos individuales muy fuertes entre personas de la misma tribu que se conocían y trabajaban juntas. Los regalos fluían entre personas que formaban parte de la pequeña comunidad de cada uno. El mundo del código libre, por otro lado, es un gran juego gratuito en ambos sentidos de la frase. El código circula para que todos lo tomen, y solo aquellos que lo necesitan lo cavan. No hay una gran conexión entre el programador y el usuario. Las personas agarran el software y lo toman sin saber realmente con quién tienen ninguna deuda. Solo conozco a algunos de los grandes nombres que escribieron el código que ejecuta la caja de Linux en mi escritorio, y sé que hay miles de personas que también contribuyeron. Sería imposible para mí devolver el dinero a cualquiera de estas personas porque es difícil mantenerlas en orden. Esta gran masa de colaboradores a menudo niega el valor y el prestigio que se obtienen al escribir un código limpio. Dado que nadie puede realizar un seguimiento de todo, las personas tienden a tratar todas las solicitudes de personas desconocidas por igual. El mundo del código libre tiende a tener muchos iguales, solo porque no hay una jerarquía que nos facilite descubrir el lugar del otro. Las corporaciones tienen títulos como vicepresidente ejecutivo y vicepresidente súper ejecutivo. Los militares etiquetan a las personas como soldado raso, sargento o mayor. No hay guías en el mundo del software libre. Aún así, las buenas contribuciones dan como resultado una buena reputación. Es posible que una corrección de errores aquí y una corrección de errores allí no generen un nombre, pero después de un año o dos dan sus frutos. Una buena reputación abre puertas, gana empleos, crea amistades y permite interesar a las personas en nuevos proyectos. El mundo del código libre también es un extraño reflejo de las jerarquías que emergen después de una temporada de ceremonias tribales de potlatch. En las tribus, aquellos que reciben grandes regalos están obligados a devolver el favor con otros aún mayores. Así que los hábiles cazadores y recolectores dan buenos regalos y reciben algo mejor a cambio. Los ricos se hacen más ricos regalando su generosidad. Los menos hábiles terminan al final de la lista. El mundo de la fuente libre, por otro lado, extiende sus riquezas a todos. Hay muchos programadores modestos que disfrutan del código fuente de los grandes programadores, y puede haber miles de millones de no programadores que también los acompañan. Muchos sitios web importantes se ejecutan solo en sistemas operativos gratuitos. ¿Quién sabe qué herramientas baratas de Internet vendrán en el futuro? Los pobres salen adelante sin un gran costo para la economía. La caridad se transmite a todos, no a unos pocos. La eficiencia va más allá. Existe toda una clase de productos para el hogar que son mucho más elegantes y sofisticados de lo que la gente necesita. Una empresa cerca de mí vende sartenes antiadherentes perfectamente utilizables por $ 2.95. Una tienda departamental elegante vende sartenes resistentes de grado industrial que hacen lo mismo por más de $100. ¿Por qué? Hacen grandes regalos para las personas que se casan. Este complejo industrial de bodas agrega accesorios innecesarios, adornos y schmaltz solo para dar a los productos suficiente caché para convertirlos en grandes regalos. El mundo del código libre, por otro lado, no tiene ningún incentivo real para generar un brillo falso y cromado para hacer que sus regalos sean aceptables o lo suficientemente dignos de dar. La gente regala lo que escribe para sí misma y tiende a escribir lo que necesita. El resultado es una colección de software útil y muy eficiente que ayuda a personas reales a resolver problemas reales. La ineficiencia del complejo industrial de bodas, el complejo industrial del Día del Padre, el complejo industrial de Navidad y su necesidad de crear regalos aceptables se han ido. Por supuesto, también hay un cierto elemento de egoísmo en la caridad. El prestigio social que proviene de escribir un buen software libre vale bastante en el mercado laboral. A la gente le gusta enumerar logros como "controlador escrito" o "código contribuido a Linux Kernel 2.2" en su r sum. Dar al proyecto correcto es una insignia de honor porque las personas serias que realizan un trabajo serio aceptaron el regalo. Eso suele ser más valioso y más revelador que una placa o un premio de un jefe tradicional. Rob Newberry es programador en Group Logic, una pequeña casa de software en el norte de Virginia donde una vez hice consultoría. Su título oficial es "Director de tecnología de fajita", y a veces se le conoce como "The Dude", una referencia a un personaje de la película /The Big Lebowski/. Técnicamente, su trabajo es construir y dar soporte a sus productos, que se utilizan para automatizar la industria de la preimpresión. Uno de sus productos, conocido como Mass Transit, moverá archivos a través de Internet y ejecutará una serie de programas automatizados antes de moverlos. Las imprentas los utilizan para aceptar nuevos trabajos, adaptar los datos a sus necesidades realizando tareas como la separación de colores y luego enviar los trabajos a las imprentas. Este trabajo requiere una gran comprensión de los diversos protocolos de red como FTP de NFS. Newberry también es fanático de Linux. Lee la lista de Kernel pero rara vez contribuye mucho a ella. Ejecuta varias versiones de Linux en la casa, y ninguna funcionaba tan bien como él quería con su Macintosh. Así que hurgó en el software, lo arregló y envió su código a Alan Cox, quien vigila la parte del núcleo a la que pertenecían sus arreglos. "Contribuí con algunos cambios a la pila de Appletalk que está en el Kernel de Linux que facilita que una máquina Linux ofrezca servicios de acceso telefónico para usuarios de Macintosh", dijo en un artículo publicado en Salon. "Tal como están las cosas, los usuarios de Mac siempre han podido conectarse a una caja de Linux y usar protocolos IP, pero si querían usar Appletalk sobre PPP, el soporte no estaba allí". Newberry, por supuesto, está haciendo todo esto en su tiempo libre porque lo disfruta. Pero su jefe, Derick Naef, todavía piensa que es genial que esté gastando parte de su energía de programación en un proyecto que no agregará nada de inmediato a la línea de fondo. "Se ha conectado mucho más a esa comunidad y a las listas de correo", explica Naef. "Aquí hay otras personas que también lo están, pero existen todas estas herramientas en el mundo del código abierto. Hay código que se puede incorporar a nuestros proyectos informáticos. Puede reducir sus costos de desarrollo si puede encontrar cosas que puedo usar." Por supuesto, todas estas justificaciones y racionalizaciones no son la razón principal por la que Newberry pasa tanto tiempo hackeando Linux. Claro, puede ayudar a los resultados de su empresa. Claro, podría reforzar su suma de dinero permitiéndole alardear de que tiene algo de código en el kernel de Linux. Pero también ve esto como un poco de caridad. "Obtengo una cierta satisfacción con el trabajo... pero obtengo una cierta satisfacción al ayudar a la gente. Mejorar Linux y especialmente su integración con Mac ha sido un proyecto favorito mío durante algún tiempo", dice. Aún así, resume su verdadera motivación diciendo: "Escribo software porque me encanta hacerlo". Tal vez tengamos suerte de que a tanta gente le guste escribir software de código abierto y regalarlo. ------------------------------ 15. amor Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. No es difícil encontrar malas historias sobre personas que escriben buen código. Una persona en una conferencia de Linux me dijo: "Lo extraño de Linus Torvalds es que todavía no ha ofendido a nadie. Todos los demás líderes se las han arreglado para cabrear a alguien en un momento u otro. Es difícil encontrar a alguien que no es odiado por nadie más". Si bien lo dijo como un cumplido para Torvalds, sonaba como si no se sorprendería si Torvalds hiciera algo presuntuoso, egoísta y petulante. Sería normal para el curso. Hay miles de ejemplos de por qué las personas en la comunidad de código abierto se odian entre sí y hay millones de ejemplos de por qué se molestan entre sí. El grupo está lleno de muchas personas independientes y decididas que no tienen miedo de expresar sus opiniones. Las guerras de llamas surgen una y otra vez a medida que las personas intentan decidir cuestiones técnicas como si tiene más sentido usar números enteros largos o números de punto flotante para mantener la riqueza de una persona en dólares. Por supuesto, el odio es realmente una palabra demasiado fuerte. Si logra identificar a algunas de las personas y les pregunta, sin rodeos, si realmente odian a alguien, dirán: "No". Realmente no les gustan algunas de las decisiones técnicas de esa persona. Estos puntos de fricción se enconan y se conviertan en lo que comúnmente se llamaría odio. Estos debates técnicos son terribles pozos de alquitrán para la comunidad y se comen la energía. Los debates se vuelven frustrantes porque tienen la extraña distinción de ser técnicamente importantes y absolutamente triviales. A todo el mundo le gustaría simplemente navegar por la vida y no preocuparse por pequeños detalles como el tipo de número entero utilizado en un cálculo. Hay millones de estas decisiones que toman tiempo que podría ser mejor empleado imaginando grandes sueños de una noosfera de información continua que proporcione la sabiduría de las edades en una interfaz gráfica simple. Pero todo programador aprende que son los detalles los que cuentan. La NASA perdió una nave espacial cuando un programador usó unidades inglesas en lugar del sistema métrico. Así que el trabajo debe hacerse. De vez en cuando, las peleas se ponen interesantes. Eric Raymond y Bruce Perens son grandes contribuyentes al movimiento de código abierto. De hecho, ambos trabajaron juntos para tratar de definir el significado del término. Perens trabajó con la comunidad que crea la distribución Debian de Linux para llegar a una definición de lo que era aceptable para la comunidad. Esta definición se transformó en una versión más oficial utilizada por la Iniciativa de código abierto. Cuando obtuvieron una definición que les gustó, la publicaron e intentaron registrar el término "código abierto" para asegurarse de que se aplicara con cierta coherencia. No debería sorprender que todo ese arduo trabajo los separó más. A principios de abril de 1999, poco después de que Apple Computer se uniera al mundo del código libre al liberar parte del código fuente de su sistema operativo, Raymond y Perens se encontraron en la garganta del otro. Raymond había trabajado en estrecha colaboración con Apple en el desarrollo de su licencia y la bendijo poco después de que surgiera. Apple estaba tan complacido que puso el respaldo de Raymond en su página web. La decisión fue un gran golpe para el movimiento de código abierto y una fuerte prueba de que las corporaciones estaban adoptando el movimiento. Grandes ejecutivos de grandes empresas como Apple estaban llamando a la puerta del movimiento de código abierto. Raymond pensó que la victoria atraería más atención a la causa. Otros pensaron que Raymond había regalado la granja. Perens y muchos otros miraron la licencia y vieron una pequeña cláusula que parecía peligrosa. La licencia de su código fuente abierto podría retirarse en cualquier momento. Alguien señaló que sería un fastidio hacer mucho trabajo en el sistema de Apple y luego descubrir que algún abogado de Apple podría sacar la licencia. Nadie quería correr ese riesgo. Estallaron guerras de llamas y Perens comenzó a estar públicamente en desacuerdo con Raymond. Para Perens, la licencia de Apple simplemente no era lo suficientemente abierta como para llamarla "código abierto". Raymond no se lo tomó muy bien. Había trabajado duro para construir una coalición fuerte. Había trabajado duro para convencer a las corporaciones de que el código abierto era mucho más que una forma para que los adolescentes experimentaran con el comunismo mientras vivían con los centavos de sus padres. Quería que el mundo del código abierto fuera una máquina suave que funcionara sin problemas y que diera la bienvenida con gracia a Apple a su redil. Ahora, su amigo Bruce Perens estaba efectivamente imitando el famoso comentario de Lloyd Bentsen sobre Dan Quayle: "He conocido el código abierto; he trabajado con el código abierto; y Eric, esta licencia no es de código abierto". Se suponía que todo su anuncio se desarrollaría con la precisión de un reloj de las grandes relaciones públicas corporativas, y ahora alguien había lanzado una granada. Raymond respondió con un escueto correo electrónico que decía: "Si alguna vez vuelves a comportarte como ese idiota perturbador en público, me insultas y pones en peligro los intereses de toda nuestra tribu, lo tomaré como algo personal y encontraré una forma de hacer que te arrepientas. Cuida tus pasos". Esta nota inquietó a Perens, por lo que comenzó a enviar copias por la red. Luego se puso serio y llamó a la policía. Oficialmente, estaba publicitando el desacuerdo para preservar su salud porque Raymond expresa bastante su apoyo a la segunda enmienda. Por lo tanto, la frase "Cuida tus pasos" debe tomarse como una amenaza velada de violencia. Perens defendió su decisión de llamar a la policía y me dijo después: "Cuando no me gusta algo, escribo sobre eso. Bueno, caramba, tal vez Eric estaba amenazando con escribir sobre mí". En la firma al pie de la página. era una cita de Thomas Jefferson, que afirmaba que la pistola era la mejor forma de ejercicio. Al día siguiente, Perens decidió que estaba exagerando un poco y publicó una nueva nota: "Eric dice que solo pretendía amenazarme con 'difamación de carácter, No con ningún tipo de violencia. Por lo tanto, creo que dejaré este tema ahora". Cuando le pregunté sobre el asunto varios meses después de que los ánimos se calmaron, Raymond dijo que el desacuerdo comenzó varios meses antes del evento de Apple cuando Perens y Raymond se enfrentaron sobre si se debería permitir que la editorial O'Reilly use el término "código abierto". " en nombre de su conferencia. "Estaba *en llamas*, y no la iniciativa en sí, sino un partidario crítico", dice Raymond. "Hace algún tiempo tuve que aceptar la renuncia de Bruce de la OSI porque estaba criticando a los aliados públicos en una lista de correo. Si vas a hacerlo público, no puedes abrir la boca como un perro de presa rabioso. Cuando la APSL [Apple Public Source License], convenció a la gente de que todos deberían atacar a Eric y a la OSI", dijo Raymond. Causó más dolor. Perens, por su parte, dijo: "Eric me decepcionó porque ciertamente el código abierto tiene que ver con la libertad de expresión. Debería ser capaz de tolerar una voz disidente. Todo el argumento se trataba de que yo no cediese a su liderazgo. Sintió que mi la disidencia fue dañina. El resultado real fue que Apple tomó mis críticas en serio y tomó todas las sugerencias". Raymond sigue siendo crítico. Él dice: "Apple fue más diplomático con Bruce en público de lo que debería haber sido. La verdad es que su intromisión hizo que las personas dentro de Apple que estaban impulsando el código abierto se metieran en problemas políticos considerables, y lo consideraban un imbécil disruptivo. Sus jefes querían saber, bastante razonablemente, por qué Apple debería molestarse en intentar hacer una licencia de código abierto si todo lo que significaba era que serían atacados por cada caso fallido con una agenda. Al socavar el estatus de OSI como representantes confiables de toda la comunidad, Bruce casi hizo fracasar todo el proceso". Por ahora, los dos trabajan por separado. Perens dice que se reconciliará con Raymond, pero no cree que suceda demasiado pronto. Raymond está feliz de centrarse en el futuro del código abierto y escribir más análisis del movimiento. Han sido separados, y los ánimos están tranquilos. Regalar software parece un acto totalmente altruista. Escribir código es un trabajo duro, y simplemente enviarlo a la red sin restricciones es un regalo bastante agradable, especialmente si el código tardó meses o años en escribirse. Esta imagen de desinterés es tan fuerte que muchas personas asumen que el mundo del software libre está habitado por santos que constantemente hacen cosas buenas por los demás. Parece un gran amor. Pero el amor es más que una cosa muy esplendorosa. Es un bien extraño que nos une emocionalmente de maneras que son más profundas que las plácidas piscinas que reflejan ojos estrellados. Después de la oleada de enamoramiento, el amor fuerte dura si y sólo si responde a las necesidades de todos. La cultura hippie del amor libre duró solo unos pocos años, pero la institución del matrimonio continúa viva a pesar de las cicatrices de batalla y las heridas que son casi mortales. La mitad puede fracasar, pero la otra mitad triunfar. La comunidad del software libre también prospera creando una versión fuerte y trascendente del amor y vinculándola con un documento legal que establece las reglas del pacto. Stallman escribió su primer virus copyleft más de 15 años antes de que comenzara este libro, y el movimiento recién comienza a ganar verdadera fuerza. El mundo del software libre no es solo un maravilloso nido de amor, es un buen ejemplo de cómo las vallas fuertes, la libertad y el respeto mutuo pueden construir relaciones sólidas. Lo importante a tener en cuenta es que la gente del software libre no está más cerca de ser santos que la gente de las compañías de software propietario. Son igual de dados a la emoción, la codicia y el ansia de poder. Es solo que las reglas del software libre tienden a refrenar sus peores instintos y les impiden actuar en consecuencia. Las reglas son a menudo bastante necesarias. El correo electrónico y los servicios de noticias dan a la gente la posibilidad de desahogar su ira rápidamente. Muchos de los programadores son escritores muy competentes, por lo que pueden destrozarse unos a otros con escalpelos verbales. El mundo del código libre está dividido en cientos, si no miles, de campos políticos y muchos se detestan inmensamente. Un grupo me rogó que no les hiciera preguntas sobre otro grupo porque solo escuchar el nombre de alguien me traía terribles recuerdos de dolor y discordia. A pesar de estos argumentos furiosos, a pesar de los fuertes desacuerdos, a pesar de las animosidades personales, los principios de las licencias públicas hacen que todo funcione sin problemas. La gente es tan humana como las ratas que corretean por el laberinto del negocio del software propietario, pero la licencia los mantiene a raya. Las diversas licencias públicas contrarrestan el comportamiento humano de dos maneras clave. En primer lugar, fomentan el debate al convertir a todos en protagonistas del proyecto. Todos tienen derecho a leer, cambiar y, por supuesto, hacer comentarios sobre el software. Hacer que todo esté disponible abre las puertas a la discusión, y la discusión generalmente conduce a discusiones. Pero cuando los argumentos llegan a las manos, como sucede a menudo, el segundo efecto de las licencias de fuente libre entra en acción y modera las consecuencias al tratar a todos por igual. Si Bob y John no se caen bien, no hay nada que puedan hacer para evitar que el otro trabaje en el proyecto. El código está disponible gratuitamente para todos y simplemente no está permitido cerrar la distribución a tu enemigo. No puedes excluir a nadie, ni siquiera a alguien a quien odias. Cualquiera que esté familiarizado con la política corporativa debería ver inmediatamente la diferencia. Mantener a los rivales en la oscuridad es solo una práctica estándar en una corporación. La información es un bien poderoso, y las personas que compiten por el mismo presupuesto la usarán lo mejor que puedan. Los jefes a menudo se mueven para mantener a sus trabajadores alejados de otros grupos para mantener cierto control sobre el flujo de información. La retribución también es común en el mundo corporativo. Muchos gerentes desarrollan rápidamente enemigos en las filas, y los grupos constantemente dedican tiempo a sabotear proyectos. Las solicitudes serán atendidas rápida o lentamente dependiendo de quién las haga. El trabajo se hará o pospondrá según la división que lo solicite. Los gerentes a menudo se quejan de que su trabajo es evitar que sus subordinados se maten entre sí y luego dan la vuelta y comienzan a luchar contra los otros gerentes a su nivel. La gente en el mundo del código libre no es más agradable que la gente en las granjas de cubículos corporativos, pero sus poderes de secreto y retribución están severamente limitados. La Licencia Pública General de GNU requiere que cualquier persona que realice cambios en un programa y luego lo publique, también debe publicar el código fuente al mundo. No se permite apagar a tus enemigos. Este efecto podría llamarse varias cosas diferentes. No es muy diferente de los tratados de desarme mutuo firmados por las naciones. Los equipos atléticos se esfuerzan por este tipo de enfoque puro cuando contratan árbitros para tomar las decisiones difíciles y hacer que todos jueguen con las mismas reglas. El gobierno a veces trata de imponer cierta disciplina en el mercado libre a través de la regulación. Ahora, compare este desarme con una historia sobre la gente pobre que se quedó en el sitio web de Hotmail después de que Microsoft los comprara. Es realmente solo una de un millón de historias sobre política corporativa. Los trabajadores de Hotmail pasaron de ser señores supremos de su dominio de Hotmail a soldados del ejército de Microsoft. Sus decisiones debían promover el incesante crecimiento de la riqueza de Microsoft, no el bien del sitio de Hotmail. Esto probablemente no molestó tanto a la gente de Hotmail como el hecho de que la gente de Microsoft no podía decidir qué quería de Hotmail. Robert X. Cringely describió la situación en un artículo en PBS Online, y citó a un trabajador de Hotmail diciendo: "Envían un nuevo grupo de alto nivel para vernos todas las semanas, pero en realidad no significa nada. El plan cambia constantemente. "Hoy, Hotmail es principalmente una forma de introducir nuevos usuarios en el portal de MSN. Tuvimos por un corto tiempo una característica llamada Centerpoint para comunicarnos directamente con nuestros usuarios, pero fue eliminada como un posible competidor con el portal de MSN. Ninguna característica nueva pudo añadirse porque el equipo de Outlook Express nos vio como competencia y lo saboteó todo". Cringely explicó la fricción corporativa y el estancamiento de esta manera: “Lo que aprendió Hotmail es que en Microsoft casi cualquiera puede decir 'no', pero casi nadie puede decir 'sí'. La forma en que funciona específicamente en Microsoft es que todos dicen "no" a cualquiera que esté debajo de ellos en la estructura organizacional o en el mismo nivel, y "sí" a cualquiera que esté arriba. Dado que las líneas verticales de autoridad son estrechas, esto significa que las personas tienden a estar de acuerdo. solo con sus jefes y el jefe de su jefe y tratan de patear y desgarrar a todos los demás". El mundo del software libre, por supuesto, elimina estas barreras. Si la gente de Hotmail se hubiera unido al equipo de Linux en lugar de a Microsoft, serían libres de hacer lo que quisieran con su sitio web incluso si molestaba a Linus Torvalds, Richard Stallman y al Papa. No serían ricos, pero siempre hay un precio. Usar la palabra "amor" es un poco peligroso porque la palabra se las arregla para incluir el enamoramiento de los adolescentes y el afecto que la gente siente por un auto nuevo o la comida de un restaurante. El amor que encarna la GPL, por otro lado, no es tan divertido y no es particularmente digno de mención. Simplemente abarca la responsabilidad y el respeto mutuos que las personas maduras a veces sienten unas por otras. Es la versión de San Pablo del amor incondicional y eterno, no las punzadas del deseo que mantuvieron despierto a San Agustín en su juventud. Cualquiera que haya pasado tiempo en las trincheras en una granja de cubículos corporativos sabe cuán inútiles pueden ser las batallas entre grupos y divisiones. Si bien la competencia a veces puede producir rivalidades sanas, a menudo solo promueve la discordia. Cualquier veterano de estas guerras debería ver el valor inmediato de los tratados de desarme como la GPL. Permiten que continúen las sanas rivalidades mientras evitan que estallen el secreto y el egoísmo. El movimiento de código libre puede no tener dinero para mover montañas, pero tiene este amor. Este amor también tiene un efecto más tradicional en los hackers que crean el código fuente gratuito. Lo hacen porque aman lo que hacen. Muchas de las personas en el movimiento de código libre están motivadas por escribir un gran software y juzgan su éxito por el reconocimiento que obtienen de sus pares igualmente talentosos. Un "buen trabajo" de la persona adecuada, como Richard Stallman, Alan Cox o Linus Torvalds, puede valer más de $ 100,000 para algunas personas. Es una forma extraña de llevar la cuenta, pero para la mayoría de los programadores en el mundo del código libre es más un desafío que dinero. Cualquier schmoe en Silicon Valley puede ganar un par de millones de dólares, pero solo unas pocas personas selectas pueden reescribir el código de la interfaz de red del kernel de Linux para mejorar el rendimiento del servidor Apache en un 20 por ciento. Llevar la cuenta contando el número de personas a las que les gusta tu trabajo es un sistema extraño, pero que ofrece los mismos incentivos que los negocios. Una buena tienda no insulta a las personas que podrían ser clientes habituales. Un buen proyecto de software libre no insulta a las personas que pueden elegir qué paquete usar. Un buen hombre de negocios facilita que las personas lleguen a la tienda, se estacionen y hagan una compra. Un buen proyecto de software libre facilita que la gente descargue el código, lo compile, lo modifique, lo entienda y lo use. Incluso hay algunas investigaciones que respaldan la idea de que las recompensas pueden disminuir la creatividad de las personas. A Stallman le gusta hacer circular un artículo de 1987 del Boston Globe que describe varios experimentos científicos diferentes que muestran cómo las personas a las que se les paga son menos creativas que aquellas que producen cosas a partir de su amor por el arte. Los estudios evaluaron el éxito de poetas, artistas y maestros que hicieron su trabajo por diversión y lo compararon con aquellos que fueron recompensados ​​por sus esfuerzos. En muchos casos, se trataba de ejercicios breves que podían evaluarse con bastante facilidad. Una científica, Theresa Amabile, le dijo al Globe que su trabajo "refuta definitivamente la noción de que la creatividad puede ser condicionada operantemente". Es decir, no puede encenderlo simplemente invirtiendo algo de dinero en él. Mucha gente del software libre señala que esta es la razón por la que el movimiento del código libre tiene tantas probabilidades de éxito como un gigante corporativo financiado masivamente. Mucha gente no necesita que los científicos les digan que no se puede arrojar dinero a muchos problemas y esperar que desaparezcan. Esta es una dura lección que los gerentes y las empresas aprenden rápidamente. Pero esto no significa que la falta de dinero signifique que el movimiento de fuente libre vencerá a los miles de programadores encadenados en sus conejeras corporativas. Estos estudios solo midieron la "creatividad" y encontraron que la gente que no paga era más "creativa". Eso no es necesariamente un cumplido. De hecho, la palabra se usa a menudo como un eufemismo para "extraño", "raro" o simplemente "malo". Es más a menudo una medida de qué tan diferente es algo en lugar de qué tan bueno es. ¿Prefieres comer en casa de un chef creativo o de un buen chef? Este amor por la creatividad puede ser un problema para el mundo del código libre. La mayoría de la gente no quiere usar una hoja de cálculo creativa para hacer su contabilidad, ya que podría tener problemas con la SEC o el IRS. Quieren un jugador de equipo sólido para muchos de sus trabajos, no uno creativo genial. El mundo del código libre a menudo se considera demasiado artístico y temperamental para emprender la ardua y larga tarea de crear un software bueno y sólido que resuelva los trabajos de bancos, farmacias, aerolíneas y todos los demás. Muchas de estas tareas son abrumadoramente aburridas y difíciles de realizar. Si bien solo implican agregar algunos números y hacer coincidir algunos datos, las tareas deben realizarse correctamente o los aviones se estrellarán. El mundo del código libre no puede confiar en el amor o la creatividad para motivar a las personas a asumir estas tareas. La única solución podría ser el dinero. Por supuesto, es importante reconocer que incluso los trabajos aparentemente aburridos pueden tener soluciones muy creativas. GNU Emacs de Stallman es una solución creativa fascinante y exagerada para el trabajo simple de manipular texto. Es posible que los procesadores de texto y los editores de texto ya no sean tan emocionantes, pero aún es posible encontrar formas creativas de realizar la tarea. --------------------------------- 16. Corporaciones Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Muchas películas sobre adolescentes siguen una fórmula probada por el tiempo: una vez que termine el verano mágico, la pandilla se separará y nunca volverá a ser lo mismo. Bob va a la universidad; Rick se va a casar; y Harry se quedará atrapado en el casco antiguo para siempre. En este momento, el mundo del software libre está experimentando las mismas emociones y dramas a medida que el mundo en general descubre el software de código abierto. En el otoño, llegan las corporaciones y el viejo y genial mundo de los hackfests nocturnos alimentados por pizza y Jolt está en peligro. Algunas personas en el ámbito del software libre crecerán, se educarán y se unirán al establecimiento; algunos se casarán; y algunos se quedarán atrás preguntándose por qué el viejo juego ya no es tan genial. El mundo del código libre está sufriendo un caso agudo de éxito. Muchos de los grandes proyectos como Apache y Sendmail están creciendo y siendo asumidos por corporaciones con balances. Bueno, no exactamente tomado, pero las corporaciones existirán y tratarán de guiar el desarrollo. Otras corporaciones como Apple, Sun y Netscape están experimentando con licencias de código abierto y tratando de ganar dinero compartiendo código. Algunas pintorescas empresas de código abierto como Red Hat se están enriqueciendo con OPI flotantes para recaudar algo de dinero y tal vez comprar algunos Porsche para sus accionistas. Hay mucha mayoría de edad sucediendo. A primera vista, nada de esta corporativización desenfrenada debería asustar a los tipos que construyeron el mundo del software libre en sus ciclos libres. Las corporaciones están llegando al código libre porque es un éxito. Quieren tomar algo del mojo del software abierto y usarlo para impulsar sus propias empresas. Todos los hombres del avión sintonizan Slashdot, compran camisetas y leen el ensayo de Eric Raymond "La catedral y el bazar" con la esperanza de tener una gran idea. Los trajes han renunciado a su quid pro quo habitual: sé un buen nerd, mantén el código funcionando y te dejaremos usar una camiseta en tu oficina del sótano. Ahora quieren intentar mudarse y vivir la vida también. Si Eric Raymond estuviera vendiendo Kool-Aid, estarían peleando por beberlo. La conversación es seria y también está afectando a muchas de las compañías tradicionales. Netscape comenzó el juego lanzando el código fuente a una versión de desarrollo de su navegador en marzo de 1998. Apple y Sun siguieron y comenzaron a regalar el código fuente a parte de su sistema operativo. Por supuesto, Apple obtuvo parte del núcleo de su sistema operativo del mundo del código abierto, pero eso no viene al caso. Todavía están compartiendo parte de su nuevo código exclusivo de Apple. Algunos, no todos. Pero eso es mucho más de lo que compartieron antes. Sun incluso comparte el código fuente con su sistema Java. Si firma los documentos correctos o hace clic en los botones correctos, puede descargar el código ahora mismo. Su licencia es más restrictiva, pero se unen al club, obtienen religión y se suben al carro. La mayoría de los verdaderos devotos están nerviosos por toda esta atención. El mundo del software libre era fácil de entender cuando solo se trataba de hackfests nocturnos e interminables críticas contra AT&T y UNIX. Era simple cuando solo estaba jugando con un código sucio que hacía cosas geniales. En ese entonces, era un gran clubhouse que odiaba a Windoze. Bueno, la verdad es que parte del mundo del software libre irá a la universidad, se graduará con un título en negocios y se volverá respetable. Eric Allman, por ejemplo, está tratando de crear una versión comercial de su popular paquete gratuito Sendmail. La versión gratuita seguirá siendo gratuita, pero puede obtener una interfaz más agradable y algunas funciones más geniales para administrar cuentas si compra. Si las cosas funcionan, algunas de las personas con la versión gratuita querrán todas las funciones adicionales que está agregando. y le pagarán. Por supuesto, nadie sabe qué afectará esto al desarrollo a largo plazo de Sendmail. ¿Solo hará nuevas mejoras en el código propietario? ¿Otras personas dejarán de contribuir al proyecto porque ven a una empresa involucrada? Hay alguna evidencia de que Allman no es el mismo tipo que andaba por la pizzería. Cuando lo contacté para una entrevista, me pasó a su experto en relaciones públicas, quien me respondió queriendo "asegurarse de que esta sea una forma rentable de pasar el tiempo de Eric". Por lo que sabemos, es posible que Eric incluso estuviera usando un traje cuando contrató a un equipo de relaciones públicas corporativas. Algunas de las otras personas del software libre se van a casar. El grupo Apache ha aprovechado su éxito con pequeñas organizaciones de servidores en conexiones con las mejores empresas que venden productos de alta potencia. IBM ahora es un firme partidario de Apache y lo ejecutan en muchos de sus sistemas. Brian Behlendorf todavía programa sus propias citas, bromea con frecuencia y habla libremente sobre su visión de Apache, pero es tan serio como cualquier hombre casado con varios hijos que mantener. No se trata solo de ofrecer algunas páginas web llenas de letras de canciones o curiosidades de Star Wars. La gente está usando Apache para negocios, negocios serios. Todavía puede ser divertido, pero Apache necesita estar aún más seguro de que no están metiéndose la pata. Y, por supuesto, hay miles de proyectos de software libre que se van a quedar atrás pasando el rato en la misma pizzería de siempre. Siempre iban a quedar miles atrás. La gente se emociona con los nuevos proyectos, los mejores protocolos y el código más ordenado todo el tiempo. El viejo código simplemente se marchita. Ocasionalmente, alguien lo redescubre, pero generalmente se olvida y se reemplaza. Pero esta evolución natural no fue dolorosa hasta que los proyectos exitosos comenzaron a terminar en las portadas de las revistas y generar negocios millonarios con capitalistas de riesgo. La gente siempre se preguntará por qué su proyecto no es tan grande como Linux. También habrá miles de proyectos casi geniales que seguirán siendo casi geniales. Todas las distribuciones vienen con muchos programas que hacen algunas cosas geniales. Pero no hay forma de que el centro de atención sea lo suficientemente brillante como para cubrirlos a todos. Solo habrá un Torvalds y todos estarán felices de que sea tan amable cuando le recuerde a la prensa que lo adora que la mayor parte del trabajo fue realizado por miles de otras personas sin nombre. La mayoría de las películas para adolescentes no se molestan en tratar de averiguar qué sucede después de ese último verano fatídico. Simplemente es mejor terminar la película con una carrera dramática o un espectáculo teatral que cristalice toda la unidad y la pasión que se construyó entre este grupo durante sus años de formación. Cantan, bailan, ganan el gran juego, van al baile de graduación y luego a las cámaras les encanta congelar el momento al final de la película. El movimiento del software libre, por otro lado, es demasiado importante y poderoso para detener este libro en una nota culminante. Sería divertido detener el libro en el momento en que Linus Torvalds y Bob Young estaban en todas las revistas. Su gran espectáculo fue un éxito, pero la verdadera pregunta es qué sucederá cuando algunas personas vayan a la escuela, otras se casen y otras se queden atrás. Hasta cierto punto, la afluencia de dinero y corporaciones es una noticia vieja. Noticia muy antigua. Richard Stallman enfrentó el mismo problema en la década de 1980 cuando se dio cuenta de que necesitaba encontrar una manera de vivir sin un sueldo universitario. Se le ocurrió la inteligente idea de que el software y la fuente siempre deben ser gratuitos, pero que cualquiera puede cobrar lo que el mercado pague por las copias. La propia Free Software Foundation continúa financiando gran parte de su desarrollo mediante la creación y venta de CD-ROM y manuales impresos. Esta decisión de dar la bienvenida al dinero no destruyó el software libre. En todo caso, hizo posible que empresas como Red Hat surgieran y vendieran versiones del software gratuito más fáciles de usar. Las empresas compitieron para sacar las mejores distribuciones y no utilizaron los derechos de autor ni otras leyes de propiedad intelectual para limitarse entre sí. Esto ayudó a atraer a más buenos programadores al ámbito porque la mayoría de la gente preferiría pasar su tiempo escribiendo código que haciendo malabarismos con los controladores en su máquina. Buenas distribuciones como Red Hat, Slackware, Debian, FreeBSD y SuSE hicieron posible que todos pusieran en marcha sus máquinas más rápido. No hay ninguna razón por la que el último impulso hacia la corriente principal vaya a ser diferente. Claro, Red Hat está cobrando más y creando mejores paquetes, pero la mayor parte de la distribución aún se rige por la GPL. Cada vez que la gente se queja de que Red Hat cuesta demasiado, Bob Young simplemente señala a la gente las empresas que copian sus CD y cobran sólo $2 o $3 por copia. La GPL evita que mucha gente se aleje demasiado del ideal. La fuente también está todavía disponible. Claro, las demandas corporativas pueden llegar, hacer tratos, emitir comunicados de prensa, recaudar capital de riesgo y hacer algunas ofertas públicas iniciales, pero eso no cambia el hecho de que el código fuente ahora se distribuye ampliamente. ¿No era ese el objetivo de la revolución de Stallman? ¿No quería ser capaz de llegar a las entrañas del software y arreglarlo? La fuente es ahora más omnipresente que nunca. Las corporaciones prácticamente están rogando a la gente que lo descargue y envíe correcciones de errores. Por supuesto, el acceso a la fuente fue solo la mitad de la batalla de Stallman. Un cínico podría gruñir que las corporaciones parecen estar rogando a la gente que haga su trabajo de investigación, prueba y desarrollo por ellos. Están buscando cervezas gratis. Stallman quería libertad para hacer lo que quisiera con la fuente y muchas de las empresas no están listas para deshacerse de todo su control. Apple vende su marca y tuvo cuidado de no abrir el código fuente a su clásica interfaz de escritorio. Lo mantuvieron bajo llave. La mayor parte del código fuente que lanzó Apple es de su próxima versión del sistema operativo, Mac OS X, que vino de la gente de NeXT cuando Apple adquirió esa compañía. ¿De dónde vino ese código? Grandes porciones procedían de las diversas versiones gratuitas de BSD como NetBSD o Mach. Es fácil ser generoso cuando solo escribió una fracción del código. Ernest Prabhakar, el gerente de proyecto del primer esfuerzo de código abierto de Apple conocido como Darwin, describe la táctica que tomó para lograr que la administración de Apple adoptara esta pequeña versión central del sistema operativo BSD sintonizado con la plataforma de hardware Macintosh. "Los primeros catalizadores fueron las universidades. Había muchas universidades como el MIT y la Universidad de Michigan que tenían algunas necesidades de infraestructura de red especializada", dijo. "Nos dimos cuenta de que las piezas que más les interesan son las más comercializadas. Realmente no se agregó ninguna tecnología patentada que tuviéramos que preocuparnos de que copiaran. Hay personas que los conocen mejor que nosotros como la comunidad BSD. Comenzamos a argumentar, si realmente queremos asociarnos con las universidades, simplemente debemos abrir el código fuente y lanzarlo como un sistema operativo completo de estilo BSD. "Queríamos que la gente usara esto en las clases, realmente lo integrara en todo el proceso educativo sin restringir la enseñanza para que se ajuste a algún modelo corporativo", finaliza. Por supuesto, Prabhakar sugiere que también hay algo de interés propio. Apple quiere ser un socio completo de la comunidad BSD. Quiere que el código que comparte se mezcle y se mezcle con el código de los árboles BSD. A la larga, Darwin de Apple y los BSD se acercarán más. En un mundo ideal, ambos grupos prosperarán si evitan duplicar los esfuerzos del otro. Prabhakar dice: "Esto reduce nuestros costos de reintegración. La capacidad de tomar la versión estándar de FreeBSD y volcarla en nuestro sistema operativo fue una gran victoria. Antes de hacer el código abierto, habíamos hecho una pequeña escala de devoluciones". Esta opinión es compartida por otras empresas. IBM es una gran empresa de hardware y una empresa de servicios aún mayor que nunca ha tenido mucha suerte vendiendo software, al menos de la misma manera que Microsoft vende software. Su OS/2 nunca llegó muy lejos del suelo. Han vendido mucho software a las empresas combinándolo con handhandling y servicio a largo plazo, pero nunca han tenido mucho éxito en el negocio del software empaquetado. El código abierto les brinda la oportunidad de reducir los costos de desarrollo de software y concentrarse en brindar servicios y hardware. Obtienen ayuda de desarrollo gratuita de todos y los clientes obtienen más flexibilidad. La licencia de fuente comunitaria de Sun tampoco está exenta de cierto interés propio. A la compañía le gustaría asegurarse de que Java siga siendo "escribir una vez, ejecutar en cualquier lugar", y eso significa controlar cuidadosamente las API y el código para asegurarse de que no surjan idiosincrasias u otros problemas técnicos. Las personas y empresas que deseen ser parte de la comunidad deben cumplir con el obsequio bastante generoso, pero no completo, de Sun al mundo. La página web de la compañía señala con bastante claridad la restricción que Sun impone a su código fuente. "El código fuente modificado no se puede distribuir sin el permiso expreso por escrito de Sun" y "Los programas binarios creados con el código fuente SDK de Java 2 modificado no se pueden distribuir, interna o externamente, sin cumplir con los requisitos de compatibilidad y regalías descritos en el Acuerdo de licencia". Si bien algunos ven esta cláusula como un par de esposas, Bill Joy explica que la Licencia de fuente comunitaria se acerca más a nuestra definición de una comunidad real. "Es una comunidad en un sentido más fuerte", dijo a una audiencia en Stanford. "Si haces mejoras, puedes poseerlas". Después de negociar una licencia con Sun, puede venderlos. Joy también señala que la licencia de Sun requiere algo del intercambio similar a GNU al exigir que todos informen errores. A algunos clientes les puede gustar un dictador que exija obediencia completa a la definición de Java de Sun, pero algunos usuarios están un poco molestos. La libertad de mirar el código no es suficiente. Quieren la libertad de agregar sus propias funciones que se ajusten mejor a sus propias necesidades, un proceso que puede comenzar a balcanizar el reino al crear más y más versiones ligeramente diferentes de Java. A Sun claramente le preocupa que los beneficios de todos estos ajustes no valgan la pena vivir la cacofonía de tener miles de versiones ligeramente diferentes. La publicación del código fuente permite a todos los usuarios ver más información sobre la estructura de Java de Sun y les ayuda a trabajar en la misma página. Este sigue siendo un gran uso del código fuente, pero no es tan gratuito como el uso imaginado por Stallman. Alan Baratz, ex presidente de la división Java de Sun, dice que su Community Source License ha sido un gran éxito. Claro, a algunas personas les gustaría tener la capacidad de tomar el código y crear sus propias versiones, como podrían hacerlo con el software protegido por una licencia de estilo BSD o GNU, pero los desarrolladores de Java realmente quieren la seguridad de que todo es compatible. Como muchos dijeron, "Microsoft quería bifurcar Java para poder destruirlo". Baratz dijo: "Ahora tenemos cuarenta mil licenciatarios de fuentes comunitarias. Los desarrolladores, los creadores de sistemas y los usuarios quieren la tecnología Java de marca. Quieren saber que todas las aplicaciones van a estar ahí. Esa es la razón número uno que los desarrolladores están escribiendo en la plataforma". Es posible que su licencia más restrictiva no haga felices a Stallman y otros devotos del software libre, pero al menos Java se ejecutará en todas partes. Tal vez en este caso, la calidad y la fuerza de la unidad que Sun aporta al mercado es más importante que la completa libertad para hacer lo que quiera. Ya hay varios clones de Java disponibles, como Kaffe. Fueron creados sin la ayuda de Sun, por lo que sus creadores no están sujetos a las licencias de Sun. Pero también hacen todo lo posible para evitar separarse de Sun. Tim Wilkinson, el CEO de Transvirtual, los creadores de Kaffe, dice que planea continuar haciendo que Kaffe sea 100 por ciento compatible con Java sin pagar regalías ni cumplir con la Licencia de fuente comunitaria. Si su proyecto u otros similares siguen prosperando y creciendo, la gente sabrá que la libertad del código abierto puede ser tan importante como la lealtad ciega a Sun. Estos esfuerzos corporativos son bienvenidos en gran medida por el mundo del código abierto, pero la bienvenida no llega con los brazos abiertos o con mucha calidez. El código fuente con algunas restricciones generalmente es mejor que ninguna fuente, pero todavía hay muchas sospechas. Theo de Raadt, el líder del proyecto OpenBSD, dice: "¿Es eso gratis? No miraremos el código fuente de Apple porque nos habremos contaminado". De Raadt probablemente esté exagerando, pero puede tener motivos para preocuparse. USL de AT&T ató el proyecto BSD durante más de un año con una demanda que finalmente perdió. ¿Quién sabe qué podría hacerle Apple a la gente de OpenBSD si hubiera algún debate sobre si algún código debería estar restringido por la licencia de Apple? Es más fácil para todos en OpenBSD evitar mirar el código de Apple para que puedan estar seguros de que la licencia de Apple no le dará a algunos abogados un punto de apoyo en la base de código de OpenBSD. Richard Stallman dice: "Sun quiere que se considere que se unió a nuestro club, sin pagar las cuotas ni cumplir con los requisitos de servicio público. Quieren que los usuarios se conformen con los fragmentos de libertad que Sun les permitirá tener". Continúa, "Sun ha rechazado intencionalmente a la comunidad de software libre mediante el uso de una licencia que es demasiado restrictiva. No está permitido redistribuir versiones modificadas del software Java de Sun. No es software libre". 16.1 Gatos gordos y gatos callejeros Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Las corporaciones también podrían sembrar discordia y dolor al crear dos clases diferentes: los que tienen y los que no tienen. A las personas que trabajan en la empresa y reciben un salario se les pagaría por trabajar en el software, mientras que otras obtendrían una sonrisa alegre y algunas gracias. El código de todos seguiría siendo gratuito, pero algunos de los contribuyentes podrían obtener mucho más que otros. En el pasado, todos pasaban el rato en la red y agregaban sus contribuciones porque era divertido. Esta división ya está creciendo. El software de Red Hat emplea a algunos de los principales colaboradores de Linux, como Alan Cox. Ellos reciben un salario mientras que el resto de los contribuyentes no reciben nada. Los empleados de Sun, Apple e IBM reciben salarios, pero las personas que trabajan en Apache o en las versiones abiertas de BSD no obtienen nada más que la oportunidad de piratear código genial. Un empleado de Microsoft, que habló en segundo plano, predijo un desastre total y absoluto. "Esa gente va a ver a los muchachos de Red Hat conduciendo Porsches y van a dejar de escribir código. ¿Por qué ayudar a alguien más a hacerse rico?". él dijo. Señalé que los celos no eran solo un problema para los proyectos de software libre. ¿No se reunieron muchos empleados contratados de Microsoft y demandaron para recibir opciones sobre acciones? ¿No estaban encerrados también? Aún así, plantea un punto interesante. Conseguir que la gente se una por el bien de un grupo es fácil de hacer cuando nadie se está enriqueciendo. ¿Qué sucederá cuando más dinero comience a llegar a los bolsillos de algunas personas? ¿La gente desertará? ¿Dejarán de contribuir? Los detractores se apresuran a señalar experimentos como el proyecto Mozilla de Netscape, que distribuyó el código fuente a la próxima generación de su navegador. El proyecto recibió mucha publicidad porque fue el primer gran proyecto de código abierto creado por una empresa importante. Crearon su propio sitio web y crearon herramientas serias para realizar un seguimiento de los errores. Aún así, el proyecto no ha generado ningún gran navegador que permita considerarlo un éxito. En el momento de escribir este artículo, unos 15 meses después del lanzamiento, siguen circulando versiones beta cada vez mejores, pero ninguna es tan completa ni tan rica en funciones como la versión normal de Netscape, que sigue siendo propiedad.[^11] [11]: Al momento de escribir esto, la versión M13 de Mozilla se ve muy impresionante. Se está acercando bastante a la versión propietaria de Netscape. A los detractores les gusta señalar que Netscape nunca recibió mucha ayuda externa en el proyecto Mozilla. Gran parte del grupo central del proyecto eran empleados de Netscape y la mayor parte del trabajo fue realizado por empleados de Netscape. Hubo algunos ejemplos brillantes como Jim Clark (sin relación con el fundador de Netscape con el mismo nombre), quien aportó un analizador XML completo al proyecto. David Baron comenzó a piratear y probar el código de Mozilla cuando era estudiante de primer año en Harvard. Pero más allá de eso, no hubo una gran oleada de entusiasmo. Las masas no se levantaron y escribieron cientos de miles de líneas de código y salvaron a Netscape. Pero es igual de fácil presentar el proyecto como un éxito. Mozilla fue el primer gran proyecto patrocinado por una empresa. Nada vino antes, por lo que no es posible compararlo con nada. Es a la vez el mejor y el peor ejemplo. Se podría decir que los devotos civiles rompieron el récord mundial de código fuente contribuido a un proyecto semicomercial. Sí, la mayor parte del trabajo lo realizaban oficialmente los empleados de Netscape, pero ¿cómo se mide el trabajo? Muchos programadores piensan que un buen informe de error es más valioso que mil líneas de código. Claro, algunas personas como Baron pasan la mayor parte de su tiempo probando el código fuente y buscando incompatibilidades, pero eso sigue siendo muy valioso. Es posible que él mismo no haya agregado un nuevo código, pero su conocimiento puede valer mucho más para las personas que eventualmente confían en que el producto esté libre de errores. También es importante medir el alcance del proyecto. Mozilla se dispuso a reescribir la mayor parte del código de Netscape. En los primeros días, Netscape creció a pasos agigantados a medida que la empresa luchaba por agregar más y más funciones para mantenerse por delante de Microsoft. La empresa a menudo no tenía tiempo para reconstruir y rediseñar el producto, y muchas de las nuevas funciones no se añadían de la mejor manera posible. El equipo de Mozilla comenzó tratando de reconstruir el código y colocarlo sobre una base estable para el futuro. Este trabajo estructural duro a menudo no es tan dramático. Los observadores casuales solo notan que el navegador Mozilla no tiene tantas funciones como el viejo Netscape. No se dan cuenta de que está completamente rediseñado por dentro. Jeff Bates, editor de Slashdot, dice que Mozilla puede haber sufrido porque Netscape tuvo tanto éxito. El navegador Netscape ya estaba disponible de forma gratuita para Linux. "No había una gran picazón para rascarse", dice. "Ya teníamos Netscape, que estaba bien para la mayoría de las personas. Este proyecto interesó a un grupo más pequeño que si no hubiéramos tenido Netscape, por lo que no recibió tanta atención". Las experiencias en otras empresas como Apple y Sun han sido más discretas. Estas dos empresas también lanzaron el código fuente de sus principales productos, pero no enmarcaron los lanzamientos como grandes proyectos de granero en los que todos los usuarios se levantarían y harían el trabajo de desarrollo para la empresa. Algunas personas describieron el proyecto de Mozilla como un fracaso porque los empleados de Netscape continuaron haciendo la mayor parte de la escritura del código. Apple y Sun han hecho un mejor trabajo al enfatizar el valor de tener la fuente disponible mientras evitan el sueño imposible de hacer que las personas que compran las computadoras también escriban el sistema operativo. No todas las interacciones entre proyectos de código abierto y corporaciones implican que las corporaciones liberen su código fuente bajo una nueva licencia de código abierto. Mucho más código fluye desde la comunidad de código abierto hacia las corporaciones. Las cosas gratis son tan tentadoras para las empresas como para las personas. En la mayoría de los casos, el flujo no es particularmente novedoso. Las empresas simplemente eligen FreeBSD o alguna versión de Linux para sus máquinas como cualquier ser humano normal. Muchas empresas web utilizan un sistema operativo gratuito como Linux o FreeBSD porque son baratos y fiables. Esto se volverá mucho más común a medida que las empresas se den cuenta de que pueden ahorrar una cantidad sustancial de dinero en la compra de licencias de puestos de empresas como Microsoft. En algunos casos, las interacciones entre el ámbito del código abierto y la granja de cubículos corporativos se vuelven bastante novedosas. Cuando el servidor web Apache se hizo popular, los desarrolladores de IBM reconocieron que tenían una oportunidad interesante a la mano. Si IBM pudiera hacer que el servidor Apache funcionara en sus plataformas, podría vender más máquinas. Apache se estaba volviendo más común y el software común a menudo vendía máquinas. Cuando la gente vino en busca de un nuevo servidor web, los vendedores de IBM pensaron que sería bueno ofrecer algo que fuera bien conocido. La licencia de Apache es bastante floja. IBM podría haber tomado el código de Apache, agregar algunas modificaciones y simplemente publicarlo con su propio nombre. La licencia solo requería que IBM diera algo de crédito al decir que la versión se derivó del mismo Apache. Esto no es difícil de hacer cuando obtienes algo gratis. Otras empresas han hecho lo mismo. Brian Behlendorf, uno del grupo central de Apache, dice: "Hay una empresa que tomó el código de Apache y lo transfirió a Mac. No contribuyeron con nada al grupo de Apache, pero realmente no nos perjudicó hacer eso". ." Sugirió que el karma volvió para atormentarlos porque Apple comenzó a lanzar su propia versión de Apache con el nuevo sistema operativo, limitando efectivamente el mercado de la compañía. IBM es, por supuesto, un viejo maestro en la creación de relaciones fluidas con clientes y proveedores. Eligieron construir una relación más profunda con Apache contratando a uno de los desarrolladores principales, Ken Coar, y pagándole para mantener contentos a todos. "Mi trabajo es multifacético", dice Coar. "No trabajo en las cosas de valor agregado de IBM. Trabajo en el código base de Apache en cualquier plataforma que esté disponible para mí. Sirvo como enlace entre IBM y el grupo Apache, básicamente asesorando a IBM sobre si las cosas que quieren son apropiados. Es un rol interesante pero único. Todo mi código vuelve al código base de Apache". Coar terminó con el trabajo porque ayudó a IBM y Apache a negociar la relación original. Dijo que había una cantidad considerable de incertidumbre en ambos lados. IBM se preguntaba cómo podían obtener algo sin pagar por ello, y Apache se preguntaba si IBM entraría y simplemente absorbería a Apache. "Hubo dudas al respecto desde el lado de Apache de que cualquier tipo de asociación con IBM haría parecer que IBM había adquirido Apache. Era algo que Apache no quería que sucediera o no parecía que sucediera", dijo Coar. Hoy, Coar dice que IBM intenta participar en el proyecto Apache como un par. Parte del código que desarrolla IBM fluirá hacia el grupo y otras partes pueden permanecer como propiedad. Cuando se incorporó el grupo Apache, Coar y otro empleado de IBM, Ken Stoddard, eran miembros. Este tipo de participación a largo plazo puede ayudar a garantizar que el grupo Apache no comience a desarrollar el servidor de manera que perjudique su rendimiento en la máquina de IBM. Si paga a varios tipos que contribuyen con frecuencia al proyecto, puede estar seguro de que el grupo escuchará sus necesidades. No garantiza nada, pero puede comprar una cantidad sustancial de buena voluntad. Por supuesto, es importante darse cuenta de que el grupo Apache siempre estuvo bastante orientado a los negocios. Muchos de los desarrolladores originales ejecutaron servidores web y querían acceder al código fuente. Hicieron dinero vendiendo el servicio de mantenimiento de un sitio web a los clientes, no una copia envuelta de Apache en sí. El trato con IBM no significó que Apache cambiara muchas de sus formas; simplemente comenzó a trabajar con algunos peces más grandes. A primera vista, cada uno de estos ejemplos no sugiere realmente que la llegada de las corporaciones vaya a cambiar mucho en el mundo del código libre. Muchos de los cambios se hicieron hace mucho tiempo cuando la gente se dio cuenta de que algo de dinero que circulaba hacía del mundo del software libre un lugar mucho mejor. Los principios más sólidos aún sobreviven: (1) los hackers prosperan cuando el código fuente está disponible y (2) las personas pueden crear sus propias versiones a voluntad. La llegada de empresas como IBM no cambia esto. El código central de Apache todavía está disponible y sigue funcionando sin problemas. Los módulos aún se conectan y funcionan bien. No hay ningún código que requiera el hardware de IBM para ejecutarse y el comité parece decidido a asegurarse de que no se produzca ninguna adquisición por parte de IBM. De hecho, todavía parece estar en el mejor interés de todos mantener el antiguo modelo de desarrollo. El mercado ama los estándares e IBM podría vender muchas máquinas simplemente ofreciendo una versión estándar de Apache. Cuando los clientes entran buscando un servidor web, la fuerza de ventas de IBM puede simplemente decir: "Este pequeño bebé maneja X mil millones de visitas al día y ejecuta el servidor Apache líder en la industria". La llegada de IBM no es muy diferente de la llegada de un tipo serio y sensato que llega de la red y quiere contribuir con Apache para poder salir adelante en su trabajo como webmaster. En este caso, es solo una corporación, no una persona. Muchos sugieren que IBM tratará gradualmente de absorber más y más control sobre Apache porque eso es lo que hacen las corporaciones. Generan contratos inescrutables y desatan ejércitos de abogados. Esta visión es miope porque ignora cuánto gana IBM al mantener una relación de plena competencia. Si Apache es un programa general que se usa en máquinas de toda la industria, entonces IBM no necesita educar a los clientes sobre cómo usarlo. Muchos de ellos aprendieron en la universidad o en su tiempo libre en las máquinas de sus casas. Muchos de ellos leyeron libros publicados por terceros y algunos tomaron cursos ofrecidos por otros. IBM está descargando efectivamente gran parte de sus costos de educación y soporte en un mercado de proveedores externos. ¿IBM estaría más feliz si Apache fuera el producto líder en el mercado y fuera propiedad exclusiva de IBM? Claro, pero no fue así como resultó. IBM diseñó la PC, pero no pudieron imponer OS/2 a todo el mundo. Sin embargo, pueden fabricar excelentes computadoras, y no es un mal negocio. Al menos, Apache no está controlado por nadie más, y eso hace que el compromiso sea bastante fácil para el ego. A algunos les preocupa que haya una pregunta mayor sin respuesta por la llegada de las corporaciones. En el pasado, existía un vínculo general entre el creador de un producto y el consumidor. Si el creador no hizo un buen trabajo, el consumidor podría castigar al creador no comprando otra versión. Este mercado garantizaría que solo sobrevivieran los mejores. Patrick Reilly escribe: "En un mercado libre, los fabricantes identificables son dueños del producto. Son responsables del desempeño del producto y pueden ser considerados responsables por fallas inexcusables". ¿Qué sucede si surge un error en alguna versión del kernel de Linux y se convierte en varias distribuciones? Realmente no es culpa de los creadores de la distribución, porque solo estaban enviando la última versión del kernel. Y en realidad no es culpa de los creadores del kernel, porque no estaban comercializando el kernel como listo para que todos lo ejecutaran. Simplemente estaban flotando un software genial en la red de forma gratuita. ¿Quién es el responsable del error? ¿Quién es demandado? Reilly lleva el escenario aún más lejos. Imagine que una empresa de distribución inteligente encuentra una solución para el error y la incluye en su distribución. No obtienen una recompensa a largo plazo porque cualquiera de las otras compañías de distribución puede venir y corregir el error. Él escribe: "Los consumidores preocupados por la compatibilidad del software probablemente comprarían las versiones estándar. Pero las empresas perderían ganancias ya que otros consumidores descargarían libremente versiones mejoradas del software de Internet. Eventualmente, las empresas sufrirían una confusión generalizada sobre la amplia variedad de software. versiones de cada producto, incluidas las versiones estándar pirateadas por especuladores". No hay duda de que Reilly apunta hacia una verdadera ruptura en el ciclo de retroalimentación que se supone debe mantener los mercados libres honestos y eficientes. Los nombres de marca son importantes, y el mundo del código libre es un guiso bastante confuso de nombres de marca. Pero también sobreestima la calidad del software que surge de empresas propietarias que supuestamente pueden ser castigadas por el mercado. Muchos usuarios se quejan con frecuencia de errores que nunca se corrigen en el código propietario, en parte porque las empresas propietarias intentan frenéticamente agregar más funciones para poder convencer a más personas de comprar otra versión del software. Los errores tampoco siempre se corrigen en el modelo propietario. Richard Stallman entiende el punto de Reilly, pero sugiere que los hechos no lo confirman. Si este circuito de retroalimentación es tan importante, ¿por qué tanta gente se jacta de la confiabilidad del software libre? Stallman dice: "Él ha señalado un problema teórico, pero si observa los hechos empíricos, no tenemos un problema real. Por lo tanto, es solo un problema para la teoría, no un problema para los usuarios. Los economistas pueden tener una es un desafío explicar por qué SÍ producimos un software tan confiable, pero los usuarios no tienen motivos para preocuparse". --------------------------------------------------------- 16.2 El regreso de los reyes del hardware Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. El mayor efecto de la revolución del software libre puede ser cambiar el poder entre las empresas de hardware y software. Los mayores defensores corporativos del código abierto son IBM, Apple, Netscape/AOL, Sun y Hewlett-Packard. Todas, excepto Netscape, son grandes empresas de hardware que vieron a Microsoft convertir el mundo de las PC en un monopolio de software que gobernaba un negocio de hardware básico. El código fuente gratuito cambia la ecuación y le quita poder a las compañías de software como Microsoft. IBM y Hewlett-Packard ya no están tan en deuda con Microsoft si pueden enviar máquinas con un sistema operativo gratuito. Apple está tomando prestado software de código abierto y lo está utilizando para el núcleo de su nuevo sistema operativo. Estas empresas saben que los clientes acuden a ellas en busca de una computadora que funcione bien cuando viene de fábrica. ¿A quién le importa si el software es gratuito o no? Si hace lo que el cliente quiere, entonces puede ganar dinero con el hardware. El movimiento del software libre empuja el software al ámbito público, y esto facilita el funcionamiento de las empresas de hardware. Las compañías automotrices no se sientan y discuten sobre quién es el dueño de la ubicación de los pedales o la posición de los diales en el tablero. Esas nociones y soluciones de diseño están disponibles gratuitamente para todas las empresas automotrices por igual. Los abogados no necesitan involucrarse en ese nivel de creación de automóviles. Por supuesto, el movimiento del software libre podría conducir a una mayor consolidación en el negocio del hardware. El negocio de los automóviles se fusionó a lo largo de los años porque las grandes empresas pudieron utilizar sus economías de escala para expulsar a las pequeñas empresas. Nadie dominaba la idea de ponerle cuatro ruedas a un automóvil o construir un motor con pistones, por lo que las empresas más eficientes se hicieron grandes. Esto también es una amenaza para el negocio de la informática. Microsoft licenció su sistema operativo a todas las empresas, grandes o pequeñas, que estaban dispuestas a postrarse ante el maestro. Lo mejor para Microsoft era fomentar la libre competencia entre las empresas informáticas. El software libre lleva esto un paso más allá. Si ninguna empresa tiene control sobre el sistema operativo dominante, la competencia se trasladará a los productores más eficientes. Las mismas fuerzas que llevaron a GM al centro de la industria automotriz podrían ayudar a agregar el negocio de hardware. Esta visión sería más preocupante si no hubiera sucedido ya. Intel domina el mercado de chips de CPU y se lleva a casa la mayor parte del precio de una PC. El mercado ya eligió un ganador de esa batalla. Ahora, el software libre podría liberar a Intel de su necesidad de mantener una asociación con Microsoft fortaleciendo a Intel. Por supuesto, los sistemas operativos gratuitos también podrían debilitar a Intel al abrirlo a la competencia. Windows 3.1, 95 y 98 siempre se ejecutaron solo en plataformas Intel. Esto facilitó que Intel dominara el mundo de las PC porque el sistema operativo que tenía más demanda solo se ejecutaría en chips Intel o compatibles con Intel. Microsoft hizo algún intento de romper con esta estrecha asociación mediante la creación de versiones de Windows NT que se ejecutaban en el chip Alpha, pero nunca fueron una parte importante del mercado. El sistema operativo gratuito también pone en juego la mayor parte de Intel. Linux funciona bien en chips Intel, pero también funciona en chips fabricados por IBM, Motorola, Compaq y muchos otros. Al equipo de NetBSD le encanta presumir que su software se ejecuta en casi todas las plataformas disponibles y se dedica a portarlo a tantas como sea posible. A alguien que usa Linux o NetBSD no le importa quién hizo el chip porque el sistema operativo se comporta de manera similar en todos ellos. El código fuente gratuito también amenaza una de las formas tradicionales en que los fabricantes de computadoras diferenciaban sus productos. Apple Macintosh perdió cuota de mercado y clientes potenciales porque se decía que no había mucho software disponible para él. El software escrito para la PC se ejecutaría en la Mac solo usando un programa lento que lo convirtió. Ahora, si todos tienen acceso al código fuente, pueden convertir el software para que se ejecute en su máquina. En muchos casos, es tan simple como volver a compilarlo, un paso que lleva menos de un minuto. Alguien que use una versión Amiga de NetBSD podría tomar el software que se ejecuta en una versión de chip Intel y volver a compilarlo. Esta amenaza muestra que la aparición de los sistemas operativos gratuitos asegura que las empresas de hardware también se enfrenten a una mayor presión competitiva. Claro, es posible que puedan quitarse de encima a Microsoft, pero Linux puede empeorar un poco las cosas. Al final, la mayoría de edad del software libre puede ser una amenaza tan grande para la vieja forma de vida de las corporaciones como lo es para la comunidad del software libre. Claro, los hackers perderán la camaradería fácil de intercambiar código con otros, pero las corporaciones deberán aprender a vivir sin control total. Las empresas de software estarán cada vez más presionadas por las versiones gratuitas, y las empresas de hardware se sorprenderán al descubrir que su producto se convertirá en una mercancía más de lo que era antes. Todo el mundo tendrá que encontrar la forma de competir y pagar la renta cuando gran parte de la propiedad intelectual sea gratuita. Estos son grandes cambios que afectan a los grandes jugadores. Pero, ¿qué significarán los cambios para los programadores que se quedan despiertos hasta tarde tejiendo montañas de código? ¿Serán privados de sus derechos? ¿Renunciarán desesperados? ¿Pasarán a experimentos de código abierto sobre el genoma humano? "El dinero que ingresa no desanimará a la gente ni dividirá a la comunidad, y esta es la razón", dice Eric Raymond. "La demanda de programadores ha sido tan alta durante la última década que cualquiera que realmente se preocupara por el dinero ya se ha ido. Hemos sido seleccionados por nuestra pasión artística". ----------------------------------------- 17. Dinero Todos los que han superado la escuela secundaria saben que el dinero lo cambia todo. Los trabajos desaparecen, el amor se desmorona y las guerras comienzan cuando el dinero escasea. Por supuesto, un buen número de creyentes del código libre no han terminado la escuela secundaria, pero pronto se darán cuenta de esto. El dinero es solo la forma en que pagamos las cosas que necesitamos, como comida, ropa, vivienda y, por supuesto, computadoras más nuevas, más grandes y más rápidas. El concepto de dinero siempre ha sido el talón de Aquiles del mundo del software libre. Todo el mundo se da cuenta rápidamente de las ventajas de compartir el código fuente con los demás. Como dicen en el negocio del software, "es una obviedad". Pero encontrar una manera de mantener el refrigerador abastecido con Jolt Cola confunde a algunos de los mejores defensores del software libre. Stallman trató cuidadosamente de explicar en detalle su solución en el Manifiesto GNU. Escribió: "No hay nada de malo en querer pagar por el trabajo, o buscar maximizar los ingresos de uno, siempre que uno no use medios que sean destructivos. Pero los medios habituales en el campo del software hoy en día se basan en la destrucción. "Extraer dinero de los usuarios de un programa restringiendo su uso es destructivo porque las restricciones reducen la cantidad y la forma en que se puede usar el programa. Esto reduce la cantidad de riqueza que la humanidad obtiene del programa. Cuando hay una opción de restringir, las consecuencias dañinas son la destrucción deliberada". A primera vista, Richard Stallman no tiene que preocuparse demasiado por llegar a fin de mes. El MIT le dio una oficina. Obtuvo una beca de genio de la Fundación MacArthur. Las empresas le pagan para ayudar a portar su software gratuito a sus plataformas. Su reputación dorada combinada con un estilo de vida frugal significa que puede mantenerse con dos meses de trabajo remunerado al año. El resto del tiempo lo dona a la Free Software Foundation. No está en la misma liga que dirigir Microsoft, pero se las arregla. Aún así, la existencia de Stallman está lejos de ser segura. Ha tenido que trabajar duro para desarrollar las líneas de financiación que tiene. Para evitar cualquier conflicto de intereses, la Free Software Foundation no le paga un salario a Stallman ni cubre sus gastos de viaje. Él dice que recibir pagos de corporaciones para portar software ayudó a llegar a fin de mes, pero no ayudó a crear nuevo software. Stallman trabaja arduamente para recaudar nuevos fondos para la FSF, y el dinero sale directamente para pagar a los programadores en nuevos proyectos. Esta lucha diaria por algún tipo de ingreso es uno de los mayores desafíos en el mundo de la fuente libre en la actualidad. Muchas otras personas del software libre están siguiendo el camino de Stallman al vender los servicios, no el software. Muchos de los miembros de Apache Webserver Core, por ejemplo, ganan dinero ejecutando sitios web. Se les paga porque sus clientes pueden escribir www.website.com y ver algo emergente. Al cliente no le importa si es software gratuito o algo de Microsoft que está haciendo malabarismos con las solicitudes. Solo quieren que los gráficos y el texto sigan moviéndose. Algunos consultores están siguiendo los mismos pasos. Varios ahora ofrecen descuentos de alrededor del 25 por ciento si el cliente acepta liberar el código fuente del proyecto como software gratuito. Si no hay gran información patentada en el proyecto, los clientes a menudo aceptan el trato. A primera vista, parece que el consultor está reduciendo sus tarifas en un 25 por ciento, pero a segunda vista, podría estar haciendo que las cosas sean un poco más eficientes para todos sus clientes. Puede reutilizar el software que lanzan sus clientes y nadie lo sabe mejor que él. Con el tiempo, todos sus clientes comparten código y disfrutan de costos de desarrollo más bajos. El modelo de venta de servicios en lugar de código fuente funciona bien para muchas personas, pero todavía está lejos de ser perfecto. El software que se vende como parte de una licencia retractilada es fácil de comprender y presupuestar para las personas. Si paga el precio, obtiene el software. Los servicios a menudo se facturan por hora y suelen ser muy abiertos. Manejar estas relaciones puede ser tan difícil como reunir algo de capital para escribir el software y luego comercializarlo como código envuelto. 17.1 Cisne Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Ha habido una serie de diferentes historias de éxito de empresas creadas en torno a la venta de software libre. Uno de los ejemplos más conocidos es Cygnus, una empresa que se especializa en mantener y portar el compilador GNU C. Originalmente, la empresa comenzó vendiendo contratos de soporte para el software gratuito antes de darse cuenta de que había una gran demanda de desarrollo de compiladores. La filosofía al principio era simple. John Gilmore, uno de los fundadores, dijo: "Hacemos que el software gratuito sea asequible". Sintieron que el software gratuito ofrecía muchas herramientas excelentes que la gente necesitaba y deseaba, pero se dieron cuenta de que el software no venía con soporte garantizado. Cygnus vendería contratos a personas que pagarían por un ingeniero que aprendería el código fuente por dentro y por fuera mientras esperaba para responder preguntas. El ingeniero también podría reescribir el código y ayudar. David Henkel-Wallace, uno de los otros fundadores, dice: "Empezamos técnicamente en 1989, en realidad en 1990. Nuestras primeras oficinas estaban en mi casa en University Avenue [en Palo Alto]. No teníamos garaje, teníamos un cochera. Era un complejo de apartamentos. Conseguimos otro apartamento y los conectamos por ethernet juntos. Cuando nos fuimos, teníamos seis apartamentos". Si bien el Área de la Bahía era técnicamente muy sofisticada, en ese momento Internet era utilizado principalmente por universidades y laboratorios de investigación. Las conexiones comerciales eran raras y solo se encontraban en rincones especiales como el corralito de investigación corporativa, Xerox PARC. Para obtener el servicio de red, Cygnus ideó un plan novedoso para cablear el complejo de apartamentos y vender parte del ancho de banda adicional a sus vecinos. HenkelWallace dice: "Comenzamos nuestro propio ISP [Proveedor de servicios de Internet] como una cooperativa porque no había esas cosas en esos días. Luego, la gente se mudó a esos apartamentos porque tenían Internet". Al principio, la empresa esperaba que el software gratuito les permitiera ofrecer algo que los principales fabricantes no ofrecían: consistencia multiplataforma. El software GNU haría lo mismo en un DEC Alpha, un Sun SPARC e incluso en una caja de Microsoft. Los fabricantes, por otro lado, estaban encerrados en sus propios mundos donde había poca polinización cruzada. Cada empresa desarrolló sus propios editores, compiladores y herramientas de código fuente, y cada una adoptó enfoques ligeramente diferentes. Uno de los otros fundadores, Michael Tiemann, escribe sobre la época: "Cuando se trataba de herramientas para programadores en 1989, el software propietario estaba en un estado deplorable. Primero, las herramientas eran primitivas en las funciones que ofrecían. Segundo, las funciones, cuando estaban disponibles, a menudo tenían limitaciones incorporadas que tendían a romperse cuando los proyectos comenzaban a complicarse. En tercer lugar, el soporte de los proveedores propietarios era terrible... finalmente, cada proveedor implementaba sus propias extensiones propietarias, de modo que cuando usaba las escasas funciones de una plataforma, te convertiste, imperceptiblemente al principio, luego más obviamente, inextricablemente atado a esa plataforma". La solución fue limpiar las herramientas GNU, agregar algunas funciones y vender el paquete a personas que tenían tiendas llenas de diferentes máquinas. Henkel-Wallace dijo: "Íbamos a tener dos productos: herramientas de compilación y herramientas de shell. La gente de sistemas abiertos comprará un montón de SGI, un montón de HP, un montón de máquinas Unix. Bueno, pensamos que las personas que tienen el mismo medio ambiente querría tener las mismas herramientas". Esta visión no funcionó. No vendieron contratos que ofrecieran ese tipo de apoyo. Sin embargo, descubrieron que la gente quería que trasladaran el compilador a otras plataformas. "Los compiladores que la gente obtenía de los proveedores no eran tan buenos y el lado del compilador del negocio estaba ganando dinero desde el primer día", dice Henkel-Wallace. La compañía comenzó a especializarse en portar GCC, el compilador GNU escrito primero por Richard Stallman, a los nuevos chips que surgieron. Mientras gran parte del mundo visible de las computadoras se estandarizaba frenéticamente con chips Intel que ejecutaban los sistemas operativos de Microsoft, un mundo invisible se fragmentaba a medida que florecía la competencia por los sistemas integrados. Todo el mundo estaba haciendo diferentes chips para hacer funcionar las entrañas de los hornos de microondas, teléfonos móviles, impresoras láser, enrutadores de red y otros dispositivos. A estos fabricantes no les importaba si un chip ejecutaba el último software de MS, solo querían que funcionara. Los fabricantes de electrodomésticos hacían que los fabricantes de chips compitieran entre sí para ofrecer la mejor solución al precio más barato, y los fabricantes de chips respondían produciendo una serie de chips nuevos, más pequeños, más rápidos y más baratos. Cygnus comenzó a portar el GCC a cada uno de estos nuevos chips, generalmente después de que el fabricante le pagara. En el pasado, las empresas de chips escribían o licenciaban sus propios compiladores con la esperanza de generar algo único que atrajera las ventas. Cygnus socavó esta idea al ofrecer algo estándar y significativamente más barato. Las empresas de chips se ahorrarían la molestia de crear sus propias herramientas de compilación y también obtendrían algo que fuera bastante familiar para sus clientes. Las personas que usaron GCC en el chip de Motorola el año pasado estaban dispuestas a probar el nuevo chip de National Semiconductor si también ejecutaba GCC. Es posible que la compatibilidad con el software gratuito no haya encontrado muchos interesados, pero Cygnus encontró más que suficientes personas que querían sistemas estándar para sus procesadores integrados. Vender a los fabricantes de procesadores en los contratos de conversión también fue un poco más fácil. Las empresas se preguntaban qué hacían pagando buen dinero por software libre. Simplemente no calculó. Los fabricantes de chips dejaron de preocuparse por esto cuando se dieron cuenta de que los compiladores gratuitos eran solo incentivos para que la gente usara sus chips. Las empresas gastaron millones en comprar bolígrafos, camisetas y otros adornos que regalaron para comercializar los chips. ¿Qué fue diferente en la compra de software? Si hizo felices a los clientes, genial. Las empresas de chips no se preocuparon tanto por perder una ventaja competitiva al regalar su trabajo. Fue solo lagniappe. Cygnus, por supuesto, tenía que preocuparse por la competencia. Por lo general, había algún tipo que trabajaba en la compañía de chips o conocía a alguien que trabajaba en la compañía de chips que decía: "Oye, conozco compiladores tan bien como esos tipos en Cygnus. Puedo descargar GCC también y ofertar menos". Henkel-Wallace dice: "Cygnus rara vez era el postor más bajo. Las personas que se preocupaban por el precio más que nadie eran a menudo los clientes más difíciles de todos modos. Hicimos tratos a un precio justo y creo que la gente estaba contenta con el resultado. Rara vez competimos en precio. ¿Qué es lo que realmente te importa? ¿Conseguir un juego de herramientas que funcione o un precio barato? -------------------------------------------------- 17.2 Cómo la GPL construyó el monopolio de Cygnus Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. La Licencia Pública General GNU también fue un arma secreta para Cygnus. Cuando sus competidores ganaron un contrato, tuvieron que liberar el código fuente de su versión cuando terminaron con él. Todas las nuevas características y conocimientos desarrollados por los competidores fluirían directamente a Cygnus. Michael Tiemann se parece sorprendentemente a Bill Gates cuando habla de este poder: "Afortunadamente, el modelo de código abierto vuelve al rescate. A menos y hasta que un competidor pueda igualar a los más de cien ingenieros que tenemos hoy en día, la mayoría de los cuales son autores principales o mantenedores del software que admitimos, no pueden desplazarnos de nuestra posición como la "verdadera fuente de GNU". código abierto, cualquier valor que agreguen regresa a Cygnus... Ver estos efectos es algo que solo un verdadero fanático del software libre puede hacer. La mayoría de las personas rara vez van más allá de identificar los problemas de entregar el código fuente a un proyecto. No se dan cuenta de que la GPL afecta a todos los usuarios y también obstaculiza a los posibles competidores. Es como un desarme mutuo o un tratado de armamento mutuo que fija las reglas para todos los interesados ​​y los tratados de desarme a menudo son favorecidos por los más poderosos. El dinero que Cygnus gana vendiendo este soporte ha sido bastante sobresaliente. La empresa continúa creciendo cada año y ha sido catalogada como una de las empresas privadas de software más grandes y de más rápido crecimiento. La operación también fue un negocio inicial en el que la empresa utilizó los fondos de los contratos existentes para financiar la investigación y el desarrollo de nuevas herramientas. No aceptaron financiación de firmas de capital de riesgo externas hasta 1995. Esto permitió que los fundadores y los trabajadores conservaran una gran parte de la empresa, uno de los sueños de todas las empresas emergentes de Silicon Valley. En 1999, Red Hot se fusionó con Cygnus para "crear una potencia de código abierto". El éxito de Cygnus no significa que otros hayan encontrado formas de duplicar el modelo. Si bien Cygnus ha encontrado algo de éxito y capital de riesgo, Gilmore dice: "El negocio del software libre les pone los pelos de punta a muchos MBA". Muchos programadores han descubierto que el software libre es solo un regalo gratuito para otros. No han encontrado una manera fácil de cobrar por su trabajo. ------------------------------------- 17.3 Soplones Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Larry McVoy es un programador que mira el mundo del código libre y se estremece. Es un veterano del mundo UNIX que ahora está intentando construir un nuevo sistema para almacenar el código fuente. Para él, regalar el código fuente es un tren de ida sin dinero. Claro, compañías como Cygnus y Red Hat pueden ganar dinero agregando algún servicio adicional, pero la competencia significa que el precio de este valor se reducirá constantemente a cero. No hay grandes costos de capital o regulatorios para restringir la entrada, por lo que siente que el mundo del software libre finalmente expulsará a todos, excepto a los adolescentes adinerados y preuniversitarios que pueden vivir en casa. "Necesitamos encontrar un método sostenible. La gente necesita escribir código y criar familias, pagar hipotecas y todo eso", dice. La solución de McVoy es una extraña licencia que algunos llaman "snitchware". Está desarrollando un producto conocido como BitKeeper y lo está regalando, con varios ganchos muy diferentes adjuntos. Se acercó a esto filosóficamente. Él dice: "Para ganar dinero, necesito encontrar algo que los muchachos del software libre no valoren y que la gente de negocios sí valore. Luego se lo quito a los muchachos del software libre. Lo que encontré es su privacidad". BitKeeper es un tipo de producto interesante que se volvió esencial a medida que los proyectos de software se hacían más grandes y difíciles de manejar. Al principio, los programadores escribieron un programa que era solo un archivo coherente con un principio, un medio, algunas digresiones y luego un final. Estos eran muy autónomos y fáciles de manejar por una sola persona. Sin embargo, cuando más de un programador comenzaba a trabajar juntos en un proyecto, todos necesitaban trabajar en la coordinación de su trabajo entre sí. Una persona no podía empezar a desarmar los menús porque otra podría estar intentando conectar los menús a un nuevo sistema de archivos. Si ambos comenzaron a trabajar en la misma parte, los cambios serían difíciles, si no imposibles, de resolver cuando ambos terminaron. Una vez que un equipo de programadores sale de un lío tan grande como ese, buscan algún software como BitKeeper para mantener el código fuente organizado. BitKeeper es sofisticado y está bien integrado con Internet. Los equipos de programadores pueden estar repartidos por todo el mundo. En momentos particulares, los programadores pueden llamarse unos a otros y sincronizar sus proyectos. Tanto los grandes equipos corporativos estrictamente controlados como los equipos de desarrollo de código abierto sueltos y descoordinados pueden usar la herramienta. La sincronización crea registros de cambios que resumen las diferencias entre dos versiones del proyecto. Estos registros de cambios están optimizados para mover la menor cantidad de información. Si dos programadores no hacen demasiado trabajo, sincronizarlos no lleva mucho tiempo. Los registros de cambios crean un historial completo del proyecto y permiten revertir el proyecto a puntos anteriores si resulta que el desarrollo tomó el camino equivocado. La solución de snitchware de McVoy es publicar los registros de cambios de las personas que no compran una licencia profesional. Estos registros incluyen información detallada sobre cómo se sincronizan dos programas, y cree que esta información debería ser lo suficientemente valiosa para que una empresa comercial la mantenga en secreto. Podrían decir: "Se movió la estructura de control de subastas a la versión de Bob desde la versión de Caroline. Se movió el nuevo motor de gráficos PostScript a la versión de Caroline desde la versión de Bob". McVoy dice: "Si eres Sun o Boeing, no querrás que Internet publique un mensaje como 'Acabo de agregar la bahía de bombas'". Pero para los chicos del software libre, no solo es aceptable, sino que es deseable. Si estás haciendo código abierto, ¿qué tienes que esconder?". BitKeeper es gratuito para que cualquiera lo use, revise y amplíe, siempre y cuando no se metan con la parte que chismea. Si no le importa que el mundo lea sus registros de cambios, entonces no es muy diferente de la licencia de código abierto tradicional. El usuario tiene los mismos derechos para ampliar, revisar y modificar BitKeeper que GNU Emacs, con una pequeña excepción: no puede desactivar la función de soplón. McVoy cree que esta es una compensación comprensible. "De los empresarios se puede extraer dinero. Puede esperar que le paguen. Este es un punto importante que aprendí consultando en Schwab y Morgan Stanley. Insisten en que pagan por el software que obtienen. No quieren pagar nada. Solía ​​pensar que eran idiotas. Ahora creo que son muy inteligentes", dice. El asunto es simple economía, explica. "Creen que si su proveedor recibe suficiente dinero, no será un desastre total. Yo llamo a esto un modelo de software de seguro". Las empresas que pagan por la privacidad con BitKeeper también financiarán un mayor desarrollo. El trabajo no se hará en el tiempo libre de alguien entre los exámenes y el juego de bienvenida. No se hará entre mantener la red en funcionamiento y ayudar a la nueva secretaria a aprender Microsoft Word. Será desarrollado por personas a las que se les paga por hacer el trabajo. "Hay suficiente dinero que regresa a la corporación para que pueda ser respaldada", dice McVoy. "Este es el quid del problema con el modelo de código abierto. También es posible abusar del modelo propietario. Te meten allí, te encierran y luego te violan. Este asunto de esperar que todo salga bien es inaceptable. Necesitas tener un candado. Los directores de MIS insisten en que tengas un candado". Él tiene un punto. Es muy divertido jugar con Linux y ahora es un sistema operativo muy estable, pero tomó varios años llegar a este punto. A muchas personas en el mundo del código libre les gusta decir cosas como: "Solía ​​ser que lo más divertido en Linux era hacer que funcionara". Empresas como Morgan Stanley, Schwab, American Airlines y la mayoría de las demás viven y mueren en función de la calidad de sus sistemas informáticos. Están bastante dispuestos a pagar dinero si ayuda a garantizar que las cosas no salgan mal. La solución de McVoy no ha agradado a todos de la manera correcta. La Iniciativa de código abierto no incluye su licencia de snitchware en una lista de soluciones aceptables. "El consenso de la policía de licencias es que mi licencia NO es de código abierto", dice. "El consenso de mi abogado es que lo es. Pero ya no lo llamo código abierto". Él va por su propio camino. "Tomé mi propia determinación de lo que la gente valora en la comunidad del sistema operativo: tienen que poder obtener la fuente, modificar la fuente y redistribuir la fuente sin cargo. Toda la otra basura es sí, sí, lo que sea", dijo. dice. "El problema con la GPL es que la GPL tiene un hacha que moler, y para moler esa hacha le quita todos los derechos a la persona que escribió el código. Atiende las necesidades de todos en la comunidad excepto la persona que lo escribió." McVoy también ha considerado otras alternativas. En lugar de quitar algo que la gente del software libre no valora, consideró poner algo por lo que las empresas pagarían para deshacerse. El producto podría mostrar anuncios que descargó desde una ubicación central. Esta solución ya es muy conocida en Internet, donde las empresas regalan correo electrónico, soluciones de búsqueda, directorios y toneladas de información para vender anuncios. Esta solución, sin embargo, tiende a arruinar la usabilidad del software. Eudora, el popular programa de correo electrónico, se distribuye con esta opción. McVoy también consideró encontrar una forma de cobrar por los cambios y el soporte para BitKeeper. "El modelo Cygnus no funciona bien porque los convierte en un taller de contratación. Eso significa que en realidad tienes que hacer algo por cada hora de trabajo". Para él, escribir software y cobrar por cada versión puede generar dinero sin trabajo, es decir, sin hacer más trabajo. La casa de apoyo tiene que tener alguien contestando el teléfono en todo momento. Una empresa que vende software empaquetado puede recaudar dinero a medida que la gente compra nuevas copias. McVoy no quiere que este dinero se gaste en propinas a los camareros de los cruceros, aunque no lo descarta. Quiere que el capital lo reinvierta en otras buenas ideas. Quiere recibir algo de efectivo para poder iniciar equipos de desarrollo que busquen proyectos nuevos y más grandes. El modelo Cygnus es demasiado restrictivo para él. Argumenta que una empresa que depende de contratos de soporte debe buscar un cliente para financiar cada proyecto. Cygnus, por ejemplo, tuvo que convencer a Intel de que podían hacer un buen trabajo al trasladar el GCC al i960. Encontraron pocas personas interesadas en el soporte general de GNU, por lo que terminaron concentrándose en GCC. McVoy argumenta que son los ingenieros los primeros en concebir los sueños. Los clientes suelen ser más conservadores y menos capaces de ver cómo una nueva herramienta o pieza de software podría ser realmente útil. Alguien necesita esconderse en un garaje por un tiempo para crear una demostración convincente de la idea. Financiar un sueño requiere capital. Para él, la ausencia de dinero en el mundo del software libre puede ser una verdadera limitación porque el dinero es una forma de almacenar valor. No se trata solo de comprar un Range Rover nuevo y vinagres balsámicos que cuestan más que la cocaína por peso. El dinero puede ser una buena forma de acumular esfuerzo y transportarlo a través del tiempo. Alguien puede trabajar como un perro durante seis meses, producir un gran producto y venderlo por un montón de dinero en efectivo. Diez años después, el efectivo se puede gastar en otra cosa. El trabajo se almacena efectivamente para el futuro. Por supuesto, esta visión no es exactamente cierta. Cygnus ha logrado cobrar lo suficiente por sus contratos para financiar el desarrollo de herramientas adicionales. Agregar nuevas funciones e implementarlas en la distribución general de alguna herramienta GNU es parte del trabajo que el equipo de Cygnus asumió por sí mismo. Estas nuevas características también significan que los usuarios necesitan más soporte. En un nivel, no es muy diferente de un ciclo de desarrollo de software tradicional. Cygnus está haciendo su trabajo por suscripción, mientras que una casa tradicional está creando sus nuevas funciones según las especificaciones. De hecho, a Cygnus le fue tan bien durante un período de tiempo tan largo que descubrió que podía reunir capital. "Una vez que Cygnus tuvo un historial de ganar dinero y entregar a tiempo, los inversores querían una parte", dice Gilmore. Red Hat ha logrado vender suficientes discos CD-ROM para financiar el desarrollo de nuevos proyectos. Han creado una buena selección de herramientas de instalación que hacen que sea relativamente fácil para las personas usar Linux. También ayudan a pagar los salarios de personas como Alan Cox, que contribuyen en gran medida a la evolución del núcleo. Hacen todo esto mientras que otros son libres de copiar sus discos de distribución palabra por palabra. McVoy no discute estos hechos, pero siente que son solo una ocurrencia temporal. El gran crecimiento del interés en Linux significa que mucha gente nueva está explorando el sistema operativo. Hay una gran demanda de la mano y el empaquetado que ofrece Red Hat. Sin embargo, con el tiempo, todos descubrirán cómo usar el producto y el flujo de ingresos debería desaparecer a medida que la competencia elimina la capacidad de cobrar $ 50 por cada disco. Por supuesto, la gente de Cygnus o Red Hat tampoco podría estar en desacuerdo con McVoy. Saben que es un mundo competitivo y creen que su única opción es seguir siendo competitivos encontrando algo por lo que la gente quiera pagar. Lo han hecho en el pasado y probablemente deberían poder hacerlo en el futuro. Siempre hay nuevas características. --------------------------------------- 17.4 Recompensas por Quicker Typer Uppers Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Algunos desarrolladores están comenzando a explorar una tercera forma de combinar el capital con el desarrollo de código abierto tratando de permitir que las empresas y las personas ofrezcan recompensas por el código fuente. El concepto es bastante simple y está adaptado al mundo del software abierto. Digamos que tienes la molesta costumbre de colocar bon mots en francés en medio de las oraciones. Aunque esto parece estúpido para tus amigos, crees que es bastante elegante. El problema es que el corrector ortográfico de su antiguo procesador de textos no está del todo a la moda y solo funciona avec une seule langue. El problema es que has pasado demasiado tiempo estudiando francés y bebiendo café y no lo suficiente estudiando Java, el lenguaje de programación. Estás tr s d sol por la incapacidad de tu procesador de textos para asimilar cuán BCBG puedes ser y revisar la ortografía en dos idiomas. El sistema de recompensas podría ser tu salvador. Publicarías un mensaje diciendo: "¡Atención! Recompensaré con un cheque de $100 a cualquiera que cree un corrector ortográfico en dos idiomas". Si tiene suerte, alguien que sepa algo sobre el código fuente del corrector ortográfico agregará la función en unos minutos. Cien dólares por unos minutos de trabajo no está nada mal. Es muy posible que otra persona esté teniendo el mismo problema para conseguir que su procesador de texto se adapte a sus necesidades. Podrían aportar $50 al fondo común. Si el problema es verdaderamente grande, entonces la olla podría crecer bastante. Esta solución está bendecida con la sensibilidad abierta y de libre mercado que gusta a muchas personas en la comunidad de software abierto. Las recompensas se publican abiertamente y cualquiera es libre de intentar reclamar las recompensas yendo a trabajar. Idealmente, los más informados serán los primeros en completar el trabajo y obtener la recompensa. Varios desarrolladores están tratando de crear una infraestructura firme para el plan. Brian Behlendorf, uno de los miembros fundadores del equipo de desarrollo del servidor web Apache, está trabajando con la empresa de Tim O'Reilly para crear un sitio web conocido como SourceXchange. Otro grupo conocido como CoSource está dirigido por Bernie Thompson y su esposa, Laurie. Ambos trabajarán para crear más software que se publique con fuente libre. Por supuesto, estos proyectos son más que sitios web. Son realmente un proceso, y cómo funcionará el proceso aún no está claro en este momento. Si bien es fácil hacer circular un aviso de que alguien pagará algo de dinero por algún software, otra cosa es hacer que funcione. Escribir software es un proceso frustrante y hay muchas posibilidades de desacuerdo. La pregunta más importante en la mente de cada desarrollador es "¿Cómo puedo estar seguro de que me pagarán?" y la pregunta más grande en la mente de cada sugar daddy es "¿Cómo puedo estar seguro de que el software funciona?" Estas preguntas son parte de cualquier experiencia de desarrollo de software. A menudo hay una gran brecha entre las expectativas de la persona que encarga el software y la persona que escribe el código. En esta sombra hay confusión, traición y confusión. La solución normal es dividir el proyecto en hitos y exigir el pago después de que pase cada hito. Si el codificador está haciendo algo insatisfactorio, el mensaje se transmite cuando el pago no llega. Tanto SourceXchange como CoSource planean trasladar la misma estructura al mundo de los programadores cazarrecompensas. Cada proyecto puede dividirse en varios pasos diferentes y el precio de cada paso puede publicarse por adelantado. Ambos sistemas tratan de aliviar el peligro de la falta de pago al exigir que alguien intervenga y arbitre el final del proyecto. Un revisor debe poder revisar las especificaciones del proyecto y el código final y luego determinar si se debe pagar el dinero. Idealmente, esta persona debería ser alguien respetado por ambas partes. Una parte neutral con la capacidad de tomar decisiones respetables es algo que muchos programadores y consultores agradecerían. En muchas situaciones normales, los contratistas solo pueden acudir a los tribunales para resolver desacuerdos, y el sistema legal no está realmente capacitado para tomar este tipo de decisiones. La empresa con el dinero a menudo puede colgar el pago frente a los programadores y usar esto como palanca para extraer más trabajo. Muchos programadores tienen al menos una historia de terror que contar sobre expectativas demasiado ambiciosas. Por supuesto, la existencia de una parte neutral sabia que pueda ver profundamente los problemas y brindar una solución justa es casi un mito. Juzgar lleva tiempo. SourceXchange promete que se les pagará a estos revisores pares, y este dinero probablemente tendrá que provenir de las personas que ofrecen la recompensa. Son los únicos que ponen dinero en el sistema a largo plazo. Además, el sistema debe hacer felices a las personas que ofrecen recompensas a largo plazo o fracasará. El proyecto CoSource sugiere que los desarrolladores deben crear su propia autoridad que juzgará el final del trabajo y le presentará a esta persona su oferta. Luego, los patrocinadores deciden si confiar en el revisor por pares cuando aprueban el trabajo. Las autoridades serán juzgadas como los desarrolladores, y se publicarán resúmenes de su reputación en el sitio. Si bien no está claro cómo se les pagará a los revisores, no es demasiado esperar que haya algunas personas que lo hagan solo por el placer de tener un dedo en el estofado. Es posible que, por ejemplo, quieran ofrecer la recompensa ellos mismos, pero no puedan aportar mucho dinero. Actuar como revisor les daría la oportunidad de asegurarse de que el software hiciera lo que querían sin gastar mucho dinero. Una de las preguntas más difíciles es cómo administrar el mercado. Una solución abierta permitiría que los patrocinadores paguen cuando el trabajo se haya realizado satisfactoriamente. La primera persona en llegar a la puerta con un código en ejecución que cumpliera con las especificaciones sería la que recibiría el pago. Cualquier otro equipo que apareciera más tarde no obtendría nada. Este enfoque ofrecería las mayores garantías de crear un código que funcione bien lo más rápido posible. Los programadores tendrían un fuerte incentivo para cumplir con las especificaciones rápidamente para ganar el dinero. La desventaja es que el precio subiría porque los programadores estarían asumiendo más riesgos. Tendrían que capitalizar su propio desarrollo y correr el riesgo de que alguien les ganara la puerta. Los patrocinadores ansiosos que necesitan algún código rápidamente deberían estar dispuestos a pagar el precio. Otra solución es adjudicar contratos antes de que se realice cualquier trabajo. Los desarrolladores esencialmente ofertarían por el proyecto y el patrocinador elegiría uno para comenzar a trabajar. El proceso sería bastante formal y favorecería a los programadores experimentados y conectados. Un par de niños que trabajan en su tiempo libre podrían ganar una recompensa abierta, pero estarían en gran desventaja en este sistema. Tanto CoSource como SourceXchange dicen que favorecerán este tipo de negociación preliminar. Si los contratos se otorgan antes de que comience el trabajo, el sistema de recompensas se parece menos a un juego salvaje y más a un mercado neutral para que los programadores de contratos hagan sus tratos. Empresas como Cygnus ya pujaron para que les paguen por trabajos que produzcan código abierto. Estos mercados de recompensas deberán proporcionar cierta estructura y eficiencia para que valga la pena que la gente los use. Un posible beneficio del sistema de recompensas es agregar los deseos de muchos grupos pequeños. Si bien algunas recompensas solo servirán a la persona que las solicita, muchas tienen el potencial de ayudar a las personas que están dispuestas a pagar. Un sistema eficiente debería poder unir a estas personas en un solo grupo y poner su dinero en un solo bote. CoSource dice que intentará reunir las recompensas de muchos grupos pequeños y permitir que las personas paguen con tarjetas de crédito. Utiliza el ejemplo de un grupo de desarrolladores de Linux que se reunirían para financiar la creación de una versión de código abierto de su juego favorito. Cada uno de ellos apostaría $10, $20 o $50 y cuando el bote fuera lo suficientemente grande, alguien daría un paso al frente. Crear un grupo político cohesivo que pueda ofrecer una gran recompensa es un gran trabajo para estos sitios. Por supuesto, hay preguntas más profundas sobre el flujo de capital y la naturaleza de los riesgos en estos enfoques basados ​​en recompensas. En el desarrollo de software tradicional, un grupo paga por la creación del software con la esperanza de poder venderlo por más de lo que cuesta crearlo. Aquí, el programador tendría garantizado un pago fijo si lograba el trabajo. El riesgo del desarrollador no se elimina por completo porque el trabajo puede demorar más de lo esperado, pero el riesgo tradicional de una empresa nueva es mínimo. Puede que no sea una buena idea separar la toma de riesgos de las personas que hacen el trabajo. Esa es a menudo la mejor manera de mantener a las personas enfocadas y dedicadas. Cada uno de estos tres sistemas muestra lo duro que está trabajando la industria del software libre para encontrar una manera de que las personas paguen sus facturas y compartan información con éxito. Empresas como Cygnus o BitKeeper son esfuerzos reales creados por personas serias que no pueden vivir de la generosidad de una universidad o de un flujo constante de subvenciones del gobierno. Su éxito demuestra que es bastante posible ganar dinero y regalar el código fuente, pero no es fácil. Aún así, no hay forma de saber qué tan bien sobrevivirán estas empresas a la competencia brutal que surge del flujo libre del código fuente. No hay barreras de entrada, por lo que cada corporación debe estar constantemente alerta. El negocio se convierte en uno de servicio, no de fabricación, y eso lo cambia todo. No hay jonrones de Grand Slam en ese mundo. No hay explosiones de miles de millones de dólares. Las empresas de servicios crecen con una cuidadosa atención a los detalles y un gran esfuerzo concentrado. -------------------------------------------------- 18. Tenedor Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Una camiseta una vez ofreció esta sabiduría al mundo: "Si amas a alguien, déjalo libre. Si regresa a ti, estaba destinado a ser. Si no regresa, persíguelo y mátalo". " El mundo del software libre gira en torno a dejar que tu código fuente salga al mundo. Si las cosas van bien, a otros les encantará el código fuente, lo llenarán de correcciones de errores y le enviarán todo este arduo trabajo. Será un brillante ejemplo de armonía y otra razón por la cual el mundo del software libre es grandioso. Pero si las cosas no funcionan, es posible que alguien te bifurque y no hay nada que puedas hacer al respecto. "Fork" es un comando de UNIX que le permite dividir un trabajo por la mitad. UNIX es un sistema operativo que permite que varias personas usen la misma computadora para realizar diferentes tareas, y el sistema operativo pretende ejecutarlas simultáneamente saltando rápidamente de una tarea a otra. Una computadora UNIX típica tiene al menos 100 tareas diferentes ejecutándose. Algunos vigilan la red en busca de datos entrantes, algunos ejecutan programas para el usuario, algunos vigilan el sistema de archivos y otros realizan muchas tareas menores. Si "bifurca un trabajo", se las arregla para dividirlo en dos partes que la computadora trata como dos trabajos separados. Esto puede ser bastante útil si ambos trabajos se interrumpen con frecuencia, ya que uno puede continuar mientras el otro se detiene. Esta solución es excelente si dos tareas, A y B, deben realizarse de forma independiente. Si usa una tarea y trata de lograr A primero, entonces B no comenzará hasta que A termine. Esto puede ser bastante ineficiente si A se detiene. Una mejor solución es bifurcar el trabajo y tratar a A y B como dos tareas separadas. La mayoría de los programadores no pasan mucho tiempo hablando de este tipo de bifurcaciones. Están principalmente preocupados por las bifurcaciones en el proceso político. Los programadores usan "bifurcación" para describir un proceso similar en la organización de un proyecto, pero el significado es bastante diferente. Las bifurcaciones de un equipo significan que el grupo se divide y va en diferentes direcciones. Una parte podría concentrarse en agregar soporte para la palabra de moda Alpha, mientras que la otra podría apuntar a la compatibilidad completa con la palabra de moda Beta. En algunos casos, existen profundas divisiones detrás de la decisión de bifurcarse. Un grupo piensa que la palabra de moda Alpha es un trabajo chapucero y descuidado que va a estallar en unos pocos años. El otro grupo odia la palabra de moda Beta con pasión. Disputas como esta suceden todo el tiempo. A menudo se resuelven pacíficamente cuando a alguien se le ocurre la palabra de moda Gamma, que los eclipsa a ambos. Cuando no llega Gamma, la gente empieza a hablar de ir por caminos separados y bifurcar la fuente. Si el polvo se asienta, dos versiones diferentes comienzan a aparecer en la red compitiendo entre sí por los corazones y las CPU de la gente que está ahí fuera. A veces las diferencias entre las versiones son grandes ya veces son pequeñas. Pero ahora hay una bifurcación en la evolución del código fuente y la gente tiene que empezar a tomar decisiones. La comunidad de software libre tiene una actitud extraña hacia las bifurcaciones. Por un lado, la bifurcación es la única razón por la que Stallman escribió el manifiesto del software libre. Quería el derecho y la capacidad de jugar con el software de su computadora. Quería ser libre para cambiarlo, modificarlo y hacerlo pedazos si alguna tarde le apetecía hacerlo. Nadie debería ser capaz de impedir que haga eso. Quería ser totalmente libre. Por otro lado, la bifurcación puede dañar a la comunidad al duplicar esfuerzos, dividir alianzas y sembrar confusión en la mente de los usuarios. Si Bob comienza a escribir y publicar su propia versión de Linux fuera de su casa, entonces le está quitando algo de energía a la versión principal. La gente comienza a preguntarse si la versión que están ejecutando es la versión del Sínodo de Missouri de Emacs o la versión Bautista Cristiana. ¿A dónde envían correcciones de errores? ¿Quien esta a cargo? Los grupos de distribución como Debian o Red Hat tienen que pasar unos minutos tratando de decidir si quieren incluir una versión u otra. Si incluyen ambos, tienen que elegir uno como predeterminado. A veces simplemente levantan las manos y se olvidan de ambos. Es una guerra civil, y esas siempre son peores que una simple guerra. Algunas bifurcaciones evolucionan a partir de personalidades que simplemente se frotan entre sí de manera incorrecta. He escuchado una y otra vez: "Oh, tuvimos que echarlo del grupo porque estaba ofendiendo a la gente". Muchos miembros de la comunidad consideran que este tipo de bifurcación es malo. Usan el mismo tono de voz para describir una bifurcación del código fuente que usan para describir la ruptura de dos amantes. Es triste, desafortunado, desagradable y algo que realmente nunca entenderemos porque no estuvimos allí. A veces las personas toman partido porque tienen una fuerte opinión sobre quién tiene la razón. Por lo general, se apagan y comienzan a contribuir a esa bifurcación de código. En otros casos, las personas no saben cuál elegir y simplemente cierran los ojos y se unen al que tiene el logo más lindo. 18.1 Forks y la amenaza de la desunión Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Eric Raymond una vez tuvo una gran pelea con Richard Stallman sobre la estructura de Emacs Lisp. Raymond dijo: "Las bibliotecas Lisp estaban en mal estado de varias maneras. Estaban mal documentadas. Había mucho trabajo que se había realizado fuera de la FSF que debería integrarse y quería fusionarlo en el mejor trabajo desde fuera ." El problema es que Stallman no quería formar parte del trabajo de Raymond. “Simplemente dijo: 'No llevaré esos cambios a la distribución'. Es su privilegio hacerlo", dijo Raymond. Eso puso a Raymond en una posición incómoda. Podía seguir haciendo el trabajo, crear su propia distribución de Emacs y romper públicamente con Stallman. Si tenía razón y el código Lisp realmente necesitaba trabajo, entonces probablemente encontraría a más de unas pocas personas que aplaudirían su trabajo. Podrían comenzar a seguirlo descargando su distribución y enviándole las correcciones de errores. Por supuesto, si estaba equivocado, configuraría su propio servidor web, haría todo el trabajo, publicaría sus correcciones de Lisp y descubriría que nadie aparecía. Sería ignorado porque a la gente le resultaba más fácil simplemente descargar la versión de Emacs de Stallman, que todos pensaban que era una especie de versión oficial, si es que se podía decir que existía. No usaban demasiado la función Lisp, así que no valía la pena pensar en cómo un tipo en Pensilvania lo había arreglado. Estaban obteniendo lo real del gran hombre mismo. Por supuesto, algo intermedio probablemente sucedería. Algunas personas a las que les importaba Lisp se asegurarían de descargar la versión de Raymond. El resto del mundo seguiría usando la versión normal. Con el tiempo, Stallman podría suavizar y aceptar los cambios, pero podría no hacerlo. Tal vez alguien vendría y crearía una tercera distribución que combinara los cambios de Raymond con los de Stallman en una versión armoniosa. Eso sería genial, excepto que obligaría a todos a elegir entre tres versiones diferentes. Al final, Raymond decidió olvidarse de sus mejoras. "Emacs es demasiado grande y demasiado complicado y la bifurcación es mala. De hecho, hubo un grupo que se cansó tanto de trabajar con él que bifurcaron Emacs. Es por eso que existe X Emacs. Pero las bifurcaciones importantes como esa son eventos raros y yo no quería ser parte de perpetrar otro", dijo. Alguien más tendría que comenzar la guerra civil disparando esos tiros en Fort Sumter. 18.2 Jardín de senderos que se bifurcan de BSD Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Algunos tenedores no son tan malos. A menudo llega un momento en que las personas tienen razones legítimas para tomar caminos diferentes. Lo que es legítimo y lo que no lo es a menudo se decide después de una gran discusión, pero las razones estándar son las mismas que impulsan los proyectos de programación. Una buena bifurcación debería hacer que una computadora ejecute el software un millón de veces más rápido. O podría hacer que el código sea mucho más fácil de portar a una nueva plataforma. O podría hacer que el código sea más seguro. Hay mil razones diferentes, y es imposible medir realmente cuál es la correcta. La única medida verdadera es el número de personas que siguen cada rama de la bifurcación. Si un proyecto tiene varios buenos discípulos y las correcciones de errores llegan rápidamente, entonces la gente tiende a asumir que es legítimo. Las diversas versiones de la distribución de software BSD son algunas de las divisiones más famosas. Todos descienden, de una forma u otra, de las versiones originales de UNIX que surgieron de Berkeley. La mayoría de los actuales evolucionaron a partir de la versión 4.3BSD y Network Release 2 y algunos códigos integrados de la versión 4.4BSD después de que se hizo libre. Todos se beneficiaron del trabajo de cientos de personas que dedicaron su tiempo libre a clonar las funciones controladas por AT&T. Todos ellos están controlados por la misma licencia BSD flexible que otorga a las personas el derecho de hacer prácticamente cualquier cosa que quieran con el código. Todos ellos comparten el mismo demonio lindo como mascota. Ahí es donde terminan las similitudes. El proyecto FreeBSD es posiblemente la versión más exitosa. Tiene una distribución bastante amplia porque sus desarrolladores tienen un buen trato con Walnut Creek CD-ROM Distributors, una empresa que empaqueta grandes paquetes de software gratuito y shareware en la red y luego los vende en CD-ROM. El sistema es bien conocido y ampliamente utilizado porque el equipo de FreeBSD se concentra en hacer que el software sea fácil de usar e instalar en computadoras Intel. Últimamente, han creado una versión Alpha, pero la mayoría de los usuarios ejecutan el software en chips x86. yahoo! utiliza FreeBSD. FreeBSD, por supuesto, comenzó como una bifurcación de un proyecto anterior conocido como 386BSD, iniciado por Bill Jolitz. Esta versión de BSD fue más un ejemplo académico o una prueba de concepto que un gran proyecto de código abierto diseñado para apoderarse del mundo. Jordan Hubbard, alguien que vendría más tarde para crear una bifurcación de 386BSD, dijo sobre la decisión de Jolitz de crear una bifurcación de BSD basada en 386: "La verdadera contribución de Bill fue trabajar con el puerto 386. Era una especie de extraño. Nadie otros vieron el 386 como interesante. Berkeley tenía una actitud miope hacia las PC. Eran solo juguetes. Nadie apoyaría a Intel. Ese era el clima en ese momento. Nadie realmente tomaba las PC en serio. La contribución de Bill fue darse cuenta de que las PC iban lugares." Desde el principio, Hubbard y varios otros vieron la genialidad en la creación de una versión 386 de BSD que se ejecutaba en el hardware más barato disponible. Comenzaron a agregar funciones y pegar correcciones de errores, que distribuyeron como un archivo que modificaba la distribución principal de 386BSD de Jolitz. Esto fue práctico al principio cuando los cambios eran pocos, pero continuó por respeto al creador original, incluso después de que los parches se complicaran. Finalmente, estalló una pelea en 1993. Jordan Hubbard, uno de los forkers, escribe en su historia del proyecto: 386BSD era el sistema operativo de Bill Jolitz, que hasta ese momento había estado sufriendo severamente por casi un año de abandono. A medida que el kit de parches se hinchaba cada vez más incómodamente con cada día que pasaba, estuvimos unánimemente de acuerdo en que había que hacer algo y decidimos tratar de ayudar a Bill proporcionando esta instantánea de "limpieza" provisional. Esos planes se detuvieron bruscamente cuando Bill Jolitz decidió repentinamente retirar su aprobación del proyecto y sin ninguna indicación clara de lo que se haría en su lugar. El equipo de FreeBSD siguió adelante a pesar de la negación. Decidieron bifurcarse. Hoy en día, 386BSD es en gran parte parte de la historia de la informática, mientras que FreeBSD es un sistema operativo vivo y actual, al menos en el momento en que se escribió este libro. El equipo de FreeBSD ha hecho un buen trabajo distribuyendo versiones libres de errores y han sido recompensados ​​con lealtad, discípulos, dinero y computadoras de Walnut Creek. La bifurcación a menudo puede ser buena para la sociedad porque evita que una persona o camarilla frustre a otro grupo. El mundo del software libre está lleno de muchas de las mismas historias de política que flotan en los dispensadores de agua de las corporaciones, pero las historias no tienen por qué terminar de la misma manera. Si un jefe o grupo intenta cerrar un proyecto de software libre, realmente no puede. El código fuente está disponible gratuitamente y la gente es libre de continuar. El proyecto FreeBSD es un ejemplo. Por supuesto, un buen software puede tener efectos antibifurcación. Linus Torvalds dijo en una entrevista: "En realidad, ni siquiera he probado 386BSD; cuando comencé con Linux no estaba disponible (aunque la serie de Bill Jolitz sobre él en Dr. Dobbs Journal había comenzado y era interesante), y cuando 386BSD finalmente salió, Linux ya estaba en un estado en el que era tan utilizable que nunca pensé realmente en cambiar. Si 386BSD hubiera estado disponible cuando comencé con Linux, Linux probablemente nunca habría existido". Entonces, si 386BSD hubiera sido más fácil de encontrar en la Red y hubiera tenido mejor soporte, es posible que Linux nunca hubiera comenzado. Una vez que alguien comienza a bifurcar BSD, una bifurcación rara vez es suficiente. Otro grupo conocido como NetBSD también se hartó del progreso de 386BSD en 1993. Sin embargo, este grupo quería construir una plataforma que funcionara bien en muchas máquinas diferentes, no solo en Intel 386. La gente de FreeBSD se concentró en hacer un buen trabajo. en cajas Intel, mientras que NetBSD quería crear una versión que se ejecutara en muchas máquinas diferentes. Su eslogan se convirtió en "Por supuesto que ejecuta NetBSD". NetBSD se ejecuta en prácticamente todas las máquinas que pueda imaginar, incluidas las máquinas más antiguas y menos actualizadas, como Amiga y Atari. También ha sido adoptado por compañías como NeXT, que incluyeron partes de él en la versión del sistema operativo para Macintosh conocida como Rhapsody. Por supuesto, los chips más comunes como la línea Intel y Alpha también son compatibles. La comunidad NetBSD surgió al mismo tiempo que el mundo FreeBSD. No se dieron cuenta de que cada equipo estaba trabajando en el mismo proyecto al mismo tiempo. Pero una vez que comenzaron a lanzar sus propias versiones, se mantuvieron al margen. "El grupo NetBSD siempre ha sido el más puro. Lo vieron como un vehículo de investigación del sistema operativo. Eso era lo que estaba haciendo CSRG. Su único mandato era hacer una investigación interesante", dijo Hubbard. "Es un conjunto de objetivos muy diferente al que nos concentramos para el 386. Lo importante para nosotros era pulirlo. Pusimos todos nuestros esfuerzos en pulir, no en portar. Esto fue parte de llevar BSD a las masas. Vamos por los números. Vamos por la penetración masiva". Esta orientación significó que NetBSD nunca logró realmente el mismo dominio del mercado que FreeBSD. El grupo recientemente comenzó a distribuir versiones de NetBSD en CD-ROM. FreeBSD, por otro lado, siempre se ha destacado por atraer usuarios nuevos y curiosos gracias a su relación con Walnut Creek. Muchos experimentadores y usuarios de mente abierta tomaron uno de los discos, y algunos se emocionaron lo suficiente como para hacer algunas contribuciones. La asociación con Walnut Creek también ayudó al equipo de FreeBSD a entender lo que tenía que hacer para que su distribución fuera más fácil de instalar y usar. Ese era el negocio de Walnut Creek, después de todo. 18.3 OpenBSD Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. La bifurcación no se detuvo con NetBSD. Pronto, un miembro del mundo de NetBSD, Theo de Raadt, comenzó a molestar a algunas personas. Un miembro del equipo de OpenBSD me dijo: "La razón de la separación de NetBSD fue que echaron a Theo. No lo entiendo completamente. Más o menos dicen que estaba tratando mal a los usuarios de la lista de correo. para ser breve y conciso, pero no hay nada de malo en eso. Fue uno de los miembros fundadores de NetBSD y le pidieron que renunciara". Ahora, cuatro años después de que comenzara la separación en 1995, de Raadt todavía está un poco dolido por su decisión. Dice sobre su decisión de bifurcar BSD nuevamente: "No tenía elección. Realmente me gusta lo que hago. Realmente me gusta trabajar con una comunidad. En el momento en que sucedió todo, yo era el segundo desarrollador más activo en su árbol fuente. Tomaron al segundo desarrollador más activo y lo echaron". Bueno, no lo expulsaron por completo, pero le quitaron la capacidad de "confirmar" cambios en el árbol de fuentes y hacerlos permanentes. Después de la división, de Raadt tuvo que enviar sus contribuciones por correo electrónico a un miembro del equipo para que pudiera verificarlas. Esto no le cayó bien a de Raadt, quien lo vio como una degradación y un impedimento real para trabajar. . La raíz de la división es fácil de ver. De Raadt es enérgico. Piensa y habla rápido sobre todo. Tiene una visión clara de la mayoría del software gratuito y no tiene miedo de compartirlo. Si bien algunos miembros de BSD son caritativos y conciliadores con Richard Stallman, de Raadt no se molesta en ocultar su desprecio por la organización. "La Free Software Foundation es una de las organizaciones más mal nombradas", dice, explicando que solo los licenciatarios al estilo BSD tienen la verdadera libertad de hacer lo que quieran con el software. La Licencia Pública General GNU es un par de esposas para él. De Raadt vive en Calgary y viste su página web personal con una foto de sí mismo en la cima de una montaña con un pañuelo. Si desea enviarle una pizza por cualquier motivo, ha publicado el número de teléfono de su tienda local favorita (403/531-3131). Desafortunadamente, informa que ya no aceptan números de tarjetas de crédito extranjeras. Incluso se las arregla para tener opiniones fuertes sobre cosas simples que aparentemente ama. El ciclismo de montaña es una gran obsesión, pero, dice, "me gusta el barro y desprecio los 'callejones arbolados' (lo que la mayoría de la gente llama caminos forestales)". Esa no es la mejor manera de entablar amistad con personas menos extremas que disfrutan de un paseo dominical por caminos forestales. Si te gustan los gatos, no leas lo que dijo sobre sus mascotas: "Tengo gatos. Sus nombres son Galileo y Kepler, todavía son gatitos. Kepler, la pequeña perra, aparentemente puede teletransportarse a través de las paredes. Galileo es un monstruo bastante genial. Cuando se conviertan en gatos adultos, haré estofado y sopa con ellos. (Kepler solo es bueno para la sopa)". Comentarios desechables como este tienen efectos extraños en la red, donde el texto es la única forma en que las personas pueden comunicarse. No hay gestos faciales o pistas tonales para decirle a la gente que alguien está bromeando, y algunas personas no tienen escáneres bien desarrollados para la ironía o el sarcasmo. A algunos les encantan los francotiradores y los hostigamientos, mientras que otros simplemente se enojan. No pueden dejar que los comentarios sarcásticos se les escapen de la espalda. Eventualmente, los buenos caballeros que sienten que la amabilidad y la cortesía personal aún deben contar para algo en este mundo se enojan y comienzan a intentar hacer algo. Es fácil ver cómo afectó esto a la gente de NetBSD, que lleva a cabo sus negocios de una manera mucho más adecuada. Charles Hannum, por ejemplo, se negó a hablarme sobre el cisma a menos que le prometiera que podría revisar las partes del libro que mencionaban NetBSD. También sugirió que los tenedores no eran particularmente interesantes y que no deberían ser parte del libro. Otros respondieron a las preguntas con cartas más educadas diciendo que la separación ocurrió hace mucho tiempo y que ya no valía la pena hablar de eso. Algunos señalaron que la mayoría de los miembros del equipo actual de NetBSD ni siquiera estaban presentes cuando ocurrió la división. Si bien su silencio puede ser bastante prudente y una mejor manera de pasar la vida, ciertamente no me ayudó a entender los dos lados de la historia. Señalé que no aceptarían código en el árbol de NetBSD si el autor exigía el derecho a revisar la distribución final. Dije que podían emitir un comunicado o realizar la entrevista por correo electrónico. Uno argumentó que no había mayor problema si al final había que eliminar algunos párrafos del libro. Señalé que no podía dar a los cientos de personas con las que hablé poder de veto sobre el manuscrito. Sería imposible de completar. El libro no estaba siendo escrito por un comité. Nadie en NetBSD se movió. De Raadt, por otro lado, habló con bastante libertad sin condiciones previas ni limitaciones. Todavía mantiene un archivo de registro con una buena cantidad de cartas de correo electrónico intercambiadas durante la separación y facilita su lectura en su sitio web personal. Eso es lo más abierto que puedes conseguir. La gente de NetBSD que se negó a hablar conmigo, por otro lado, parecía decidida a mantener el control de la historia. Su silencio provino de un mundo diferente al del sitio web que ofrece el número de teléfono de la pizzería local como pista. Eran Dragnet; de Raadt era políticamente incorrecto. Cuando la gente de NetBSD decidió hacer algo, le quitaron el acceso a de Raadt al árbol de fuentes. No podía simplemente hurgar en el código haciendo cambios a medida que avanzaba. Bueno, podría hurgar y hacer cambios, pero no en el árbol oficial con la última versión. Después de todo, el proyecto era de código abierto. Podía descargar la última versión y empezar a juguetear, pero no podía tomar decisiones casi oficiales sobre qué fuente formaba parte de la última versión oficial inédita. De Raadt pensó que esto era una verdadera barrera para trabajar. No pudo ver la última versión del código porque se mantuvo fuera de su vista. Estaba atascado con el último lanzamiento, que podría tener varios meses. Eso lo puso en una desventaja extrema porque podría comenzar a trabajar en un problema solo para descubrir que alguien lo había solucionado o cambiado. Chris Demetriou se encontró con la tarea de sacar a De Raadt del equipo. Su carta, que aún se puede encontrar en el sitio de OpenBSD, decía que el comportamiento rudo y los mensajes abusivos de de Raadt habían alejado a las personas que podrían haber contribuido al proyecto. Demetriou también se negó a hablar sobre NetBSD a menos que pudiera revisar las secciones del libro que contenían sus comentarios. También amenazó con tomar todas las medidas posibles contra cualquiera que incluso citara sus cartas en un libro comercial sin su permiso. De Raadt recopiló esta nota de Demetriou y la tormenta de fuego que siguió en un archivo de 300k que guarda en su sitio web. El núcleo de NetBSD trató de ser cortés y firme, pero el asunto pronto degeneró en una guerra de llamas que duró siete meses. Después de un tiempo, la gente comenzó a tener meta-argumentos, debatiendo si el verdadero argumento era más o menos como las disputas de un marido y una mujer que trabajan en la misma empresa. Los esposos y las esposas deben mantener sus peleas personales fuera del lugar de trabajo, argumentaron. Y entonces discutieron sobre si los desagradables gramas de De Raadt eran parte de su "trabajo" o solo parte de su tiempo social. A pesar de todo, de Raadt trató de recuperar su acceso al árbol fuente de NetBSD y el grupo trató de proponer todo tipo de mecanismos para asegurarse de que estaba haciendo una contribución "positiva" y se llevaba bien con todos. En un momento, le ofrecieron una carta para que la firmara. Estas negociaciones no llegaron a ninguna parte, ya que de Raadt se opuso a verse obligado a hacer promesas que otros contribuyentes no tenían que hacer. De Raadt escribió software libre porque quería ser libre para hacer cambios o escribir código de la forma en que quería hacerlo. Si hubiera querido tener la cara feliz de un colaborador positivo, podría haber conseguido un trabajo en una corporación. Renunciar al derecho de participar en guerras de llamas y hablar a voluntad puede no ser una gran compensación para las personas normales con trabajos de tiempo completo. La gente normal se traga su orgullo a diario. La gente normal no bromea sobre convertir a sus gatos en sopa. Pero de Raadt pensó que era como perder un poco de su humanidad y aceptar voluntariamente un par de esposas. Simplemente no era habitable. La discusión duró meses. De Raadt sintió que intentó y trató de reincorporarse al proyecto sin renunciar a su honor. El equipo central de NetBSD argumentó que solo querían asegurarse de que fuera positivo. Querían asegurarse de que no alejaría a los colaboradores perfectamente buenos con payasadas descaradas. Nadie ganó terreno en las negociaciones y, al final, De Raadt se fue. La buena noticia es que la bifurcación no terminó mal. De Raadt decidió que no aceptaría la degradación. Simplemente no podría hacer un buen trabajo si tuviera que ejecutar todos sus cambios por parte del equipo que lo expulsó del proyecto. Me tomó mucho tiempo preguntar "Madre, ¿puedo?" para arreglar cada pequeño error. Si iba a tener que ejecutar su propio árbol, también podría hacer todo lo posible y comenzar su propia versión de BSD. Lo llamó OpenBSD. Iba a estar completamente abierto. Iba a haber relativamente pocos controles sobre los miembros. Si el núcleo de NetBSD manejaba su mundo como los aldeanos puritanos en una historia de Nathaniel Hawthorne, entonces de Raadt manejaría el suyo como Club Med. OpenBSD luchó durante varios meses mientras de Raadt intentaba atraer a más diseñadores y programadores a su proyecto. Fue una batalla por la popularidad en muchos sentidos, no muy diferente de la escuela secundaria. Cuando las camarillas se dividieron, todos tuvieron que escoger y elegir. De Raadt tenía que conseguir algunas personas en su campamento si iba a hacer limonada. La inspiración llegó a de Raadt un día cuando descubrió que al archivo de guerra de llamas en su página web le faltaban algunas letras. Dice que alguien irrumpió en su máquina e hizo algunas eliminaciones sutiles. Alguien que tenía un conocimiento íntimo del sistema NetBSD. Alguien a quien le importaba la imagen que retrataban las emociones crudas en las cartas supuestamente privadas. Aclara sus comentarios para dejar claro que no está seguro de que haya sido alguien del núcleo de NetBSD. "Nunca lo perseguí. Si sucede, es tu culpa. No es culpa de ellos", dijo. Por supuesto, la gente de NetBSD se negó a discutir este asunto oa responder preguntas a menos que pudieran revisar el capítulo. Este robo le dio un enfoque. De Raadt miró a NetBSD y decidió que era demasiado inseguro. Reunió a un grupo de personas de ideas afines y comenzó a peinar el código en busca de posibles inseguridades. "Más o menos al mismo tiempo, me involucré con una empresa que escribía un escáner de seguridad de red. Tres de las personas de allí comenzaron a jugar con el árbol de código fuente y a buscar agujeros de seguridad. Empezamos a encontrar problemas por todas partes, así que comenzamos un auditoría integral de seguridad. Comenzamos desde el principio. Nuestra carga de tareas aumentó enormemente. En un momento, tenía cinco hojas de papel en mi escritorio llenas de cosas que buscar ", dijo. Los agujeros de seguridad en los sistemas operativos son bestias extrañas que suelen aparecer por error cuando el programador hace una suposición infundada. Uno de los agujeros más conocidos es el desbordamiento del búfer, que se hizo famoso en 1988 después de que Robert Morris, entonces estudiante de posgrado en Cornell, lanzara un programa que usaba el agujero para hacer que varias partes importantes de Internet se ralentizaran. En este caso, el programador crea un búfer para contener toda la información que alguien en la red podría enviar. Los navegadores web, por ejemplo, envían solicitudes como "GET http://www.nytimes.com" para solicitar la página de inicio del sitio web del New York Times. El programador debe reservar una parte de la memoria para contener esta solicitud, generalmente un bloque que tiene una longitud de aproximadamente 512 bytes. El programador elige una cantidad que debería ser más que suficiente para todas las solicitudes, incluidas las más extrañas y complicadas. Antes de que el ataque se hiciera conocido, los programadores a menudo ignoraban la longitud de la solicitud y asumían que 512 bytes eran más que suficientes para cualquier cosa. ¿Quién escribiría una URL tan larga? ¿Quién tenía una dirección de correo electrónico tan larga? Los atacantes pronto descubrieron que podían enviar más de 512 bytes y comenzaron a escribir sobre el resto de la memoria de la computadora. El programa tomaría diligentemente 100.000 bytes y seguiría escribiéndolos en la memoria. Un atacante podría descargar cualquier software y comenzar a ejecutarlo. Y los atacantes hicieron esto. De Raadt y muchos otros comenzaron a peinar el código en busca de lagunas. Se aseguraron de que cada programa que usaba un búfer incluyera un fragmento de código que verificaría para garantizar que ningún hacker intentara infiltrarse más de lo que el búfer podía contener. Revisaron miles de otras posibilidades. Se revisó cada línea y se hicieron cambios, incluso si no había una forma práctica de que alguien llegara al agujero potencial. Muchos búferes, por ejemplo, solo aceptan información de la persona que está sentada en la terminal. La gente de OpenBSD también los cambió. Esta auditoría comenzó poco después de la bifurcación en 1995 y continúa hasta el día de hoy. La mayor parte del trabajo principal ya está hecho y al grupo le gusta jactarse de que no han tenido un agujero que pueda explotarse de forma remota para obtener acceso a la raíz en más de dos años. El último logotipo cuenta con el lema "Enviando niños a /dev/null desde 1995". Es decir, cualquier atacante no llegará a ninguna parte con OpenBSD porque toda la información adicional de los ataques se enrutaría a /dev/null, una presunción de UNIX para ser borrada, ignorada y olvidada. La bifurcación de OpenBSD es un buen ejemplo de cómo las malas batallas políticas pueden terminar resolviendo algunos problemas técnicos importantes. Todos se inquietaron y preocuparon cuando de Raadt anunció que estaba bifurcando el mundo BSD una vez más. Esto diluiría aún más los recursos y sembraría confusión entre los usuarios. Sin embargo, la concentración en la seguridad le dio a OpenBSD una identidad de marca, y las otras distribuciones de BSD mantienen al menos un ojo en las correcciones de errores distribuidas por el equipo de OpenBSD. Estos a menudo conducen a arreglos subrepticios en su propia distribución. El enfoque también lo ayudó a atraer nuevos programadores interesados ​​en la seguridad. "Algunos de ellos solían ser crackers y eran personas realmente geniales. Cuando cumplen dieciocho años, se convierte en un delito federal, ya sabes", dice de Raadt. Esta bifurcación puede haber fortalecido a la comunidad BSD porque elevó efectivamente el enfoque en la seguridad y la criptografía al más alto nivel. En el mundo corporativo, es como tomar al líder del equipo de desarrollo responsable de la seguridad y ascenderlo de gerente senior a vicepresidente ejecutivo senior de una división separada. La autonomía también le dio al equipo de OpenBSD la capacidad de tomar decisiones técnicas audaces por sus propios motivos. Si veían un posible problema de seguridad que pudiera perjudicar la usabilidad o la portabilidad, el equipo de OpenBSD podía realizar el cambio sin preocuparse de que otros miembros del equipo se quejaran. OpenBSD se trataba de seguridad. Si quería trabajar en la portabilidad, vaya a NetBSD. Si le preocupaba la facilidad de uso en cajas Intel, vaya a FreeBSD. La creación de un mundo OpenBSD separado hizo posible darle un fuerte enfoque a la seguridad. 18.4 Bifurcaciones Temporales Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Es un error ver estas bifurcaciones como divisiones absolutas que nunca se vuelven a mezclar. Mientras que NetBSD y OpenBSD continúan fulminándose entre sí a través del éter de Internet, los grupos comparten código con frecuencia porque las licencias evitan que un grupo congele a otro. Jason Wright, uno de los desarrolladores de OpenBSD, dice: "Vigilamos los árboles de código fuente de los demás. Una de las cosas que hago para divertirme es sacar controladores de FreeBSD y trasladarlos a OpenBSD. Entonces tenemos soporte para una nueva pieza de hardware. ." Dice que a menudo busca controladores escritos por Bill Paul, porque "Me he acostumbrado a su estilo. Así que sé qué cambiar cuando recibo su código. Puedo hacerlo en unas cinco o seis horas. Es decir, en menos un puerto aproximado para probar si funciona". Aún así, el trabajo no siempre es sencillo. Dice que algunos controladores de dispositivos son mucho más difíciles de manejar porque ambos grupos han abordado el problema de manera diferente. "Los controladores SCSI son más difíciles", dice. "Ha habido cierta divergencia en las capas para SCSI. Están usando algo llamado CAM. Tenemos una implementación más antigua a la que nos hemos adherido". Es decir, FreeBSD ha reelaborado la estructura de la forma en que la información SCSI se envía a las partes del sistema que solicitan información. OpenBSD no ha adoptado sus cambios, quizás por cuestiones de seguridad o quizás por inercia o quizás porque nadie se ha puesto a pensar en ello. La mezcla no es perfecta. Tanto NetBSD como FreeBSD también funcionan en la seguridad. También observan los registros de cambios de OpenBSD y notan cuándo se solucionan los agujeros de seguridad. También descubren sus propios agujeros y OpenBSD puede usarlos como inspiración para tapar su propio código. Los descubrimientos y complementos van en ambos sentidos a medida que los grupos compiten para crear un sistema operativo perfecto. Kirk McKusick dice: "NetBSD y OpenBSD tienen personalidades extremadamente fuertes. Cada uno está absolutamente aterrorizado de que el otro gane una pulgada". Si bien las tres bifurcaciones de BSD pueden cooperar más de lo que compiten, al mundo de Linux todavía le gusta mirar al mundo de BSD con un poco de desprecio. Todas las bifurcaciones se ven un tanto desordenadas, incluso si tener la libertad de bifurcar es lo que aparentemente Stallman y GNU están luchando por lograr. Los entusiastas de Linux parecen pensar: "Tenemos nuestros patos en una sola fila. ¿Cuál es tu problema?" Es algo así como la mentalidad del ejército. Si es verde, uniforme e igual en todas partes, entonces debe ser bueno. El BSD carece de la cohesión monomaníaca de Linux, y esto parece dañar su imagen. La comunidad de BSD siempre ha sentido que Linux está acaparando el protagonismo que debería compartirse al menos por igual entre los grupos. Linux realmente está construido alrededor de un culto a Linus Torvalds, y eso hace que la prensa sea muy buena. Es muy fácil para la prensa tomar fotos de un hombre y ponerlo en la portada de una revista. Es simple, limpio, ordenado y perfectamente compatible con un fragmento de sonido de 30 segundos. Explicar que hay FreeBSD, NetBSD, OpenBSD y quién sabe qué versiones más pequeñas esperando entre bastidores no es tan manejable. Eric Raymond, un verdadero discípulo de Linus Torvalds y Linux, lo ve en términos técnicos. La comunidad de BSD se enorgullece del hecho de que cada distribución se construye a partir de un gran árbol fuente. Obtienen todo el código fuente de todas las partes del núcleo, las utilidades, los editores y demás en un solo lugar. Luego presionan el botón de compilación y dejan que la gente trabaje. Este es un enfoque nítido, efectivo y bien administrado para el proyecto. Los grupos de Linux, sin embargo, no están tan coordinados. Torvalds solo se preocupa realmente por el núcleo, que es su bebé. Alguien más se preocupa por GCC. Todos crean sus propios árboles de origen para las partes. Las empresas de distribución como Red Hat se preocupan por unir el desorden. No es inusual encontrar la versión 2.0 del kernel en una distribución mientras que otra tiene la versión 2.2. "En BSD, puedes hacer una marca unificada. Están bastante orgullosos de eso", dice Raymond. "Pero esto crea rigideces que le dan a la gente incentivos para bifurcarse. Las cosas de BSD que se construyen de esa manera desarrollan nuevos grupos derivados cada semana, mientras que Linux, que tiene un acoplamiento más flexible, no se bifurca". Él elabora: "Alguien señaló que hay un paralelo de la política. Las instituciones políticas y sociales rígidas tienden a cambiar violentamente si cambian, mientras que las que tienen más juego tienden a cambiar pacíficamente". Pero esta distinción puede ser semántica. La bifurcación ocurre en el ámbito de Linux, pero ocurre como pequeñas distracciones que se explican con otras palabras. Red Hat puede elegir usar GNOME, mientras que otra distribución como SuSE puede elegir KDE. Los usuarios verán una gran diferencia porque ambas herramientas crean entornos de escritorio virtual. No te los puedes perder. Pero la gente no etiquetará esto como un tenedor. Ambas distribuciones usan el mismo kernel de Linux y nadie ha dicho: "Al diablo con Linus, voy a construir mi propia versión de Linux". Técnicamente, todos todavía se llaman a sí mismos Linux, incluso si están construyendo algo que se ve bastante diferente en la superficie. Jason Wright, uno de los desarrolladores del equipo de OpenBSD, ve la organización como algo bueno. "Lo único que tienen todos los BSD sobre Linux es un árbol de código fuente unificado. No tenemos el árbol de Joe Blow o el árbol de Bob", dice. En otras palabras, cuando se bifurcan, lo hacen oficialmente, con gran ceremonia, y se aseguran de que el mundo sepa de sus creaciones por separado. Hacen una ruptura clara, y esto facilita las cosas a los desarrolladores. Wright dice que este árbol fuente único les facilitó mucho convertir OpenBSD en un sistema operativo muy seguro. "Tenemos la seguridad sobre Linux. Recientemente han estado realizando una auditoría de seguridad para Linux, pero van a tienen muchos más problemas. No hay un lugar donde ir para el código fuente". Para extender esto a términos políticos, el mundo de Linux es como la década de 1980 cuando Ronald Reagan dirigía el partido republicano con la máxima de que nadie debería criticar a otro republicano. Claro, la gente discutió internamente sobre impuestos, aborto, crimen y las controversias habituales, pero mostró una rara cohesión pública. Nadie critica a Torvalds, y todos tienen cuidado de hablar de la importancia de la cohesión de Linux incluso cuando esencialmente se bifurcan al elegir diferentes paquetes. El mundo BSD, por otro lado, es como el reino bíblico en la película de Monty Python La vida de Brian. En él, un personaje enumera los diversos grupos disidentes que se oponen a la ocupación de los romanos. Está el Frente Popular de Judea, el Frente Popular de Judea, el Frente Popular de Judea y varios otros. Todos buscan lo mismo y todos están manifiestamente separados. El mundo BSD puede compartir una buena cantidad de código; puede compartir los mismos objetivos, pero simplemente lo presenta como proveniente de tres campos diferentes. John Gilmore, uno de los fundadores de la compañía de software libre Cygnus y un firme creyente en las ventajas de la Licencia Pública General GNU, dice: "En Linux, cada paquete tiene un mantenedor, y los parches de todas las distribuciones pasan por ese mantenedor. Hay una sensación de cohesión. Las personas en cada distribución trabajan para reducir sus diferencias con respecto a la versión lanzada por el mantenedor. En el mundo de BSD, cada árbol cree que es el propietario de cada programa; no envían los cambios a un lugar central porque eso viola el modelo del ego". Jordan Hubbard, el líder de FreeBSD, es crítico con la caracterización de Raymond del mundo BSD. "Siempre he tenido un lugar especial en mi corazón para ese periódico porque pintó posiciones que no existían", dijo Hubbard sobre la pieza de Raymond "La catedral y el bazar". "Podría apuntar solo a la comunidad de Linux y decidir qué parte estaba orientada a la catedral y qué parte estaba orientada al bazar. "Cada sistema operativo tiene partes de catedral y partes de bazar. Hay algunos aspectos del desarrollo que usted deja deliberadamente fuera de foco y deja que las personas contribuyan a su propio ritmo. Es una especie de modelo emergente y esa es la parte del bazar. Luego tienes la parte organizativa de cada proyecto. Esa es la parte de la catedral. Son los guardianes y los que establecen los estándares. También son necesarios”, dijo. Cuando se trata de eso, incluso hay muchas bifurcaciones sobre la definición de una bifurcación. Cuando algunos miembros del equipo de Linux apuntan al mundo BSD y comienzan a burlarse de las bifurcaciones, el equipo BSD se pone a la defensiva. Los muchachos de BSD siempre se ponen a la defensiva porque su fundador no está en la portada de todas las revistas. El equipo de Linux insinúa que tal vez, si no estuvieran bifurcando, también tendrían a alguien con un nombre en las luces. Hubbard tiene razón. Linux se bifurca tanto, simplemente lo llaman una distribución o un kernel experimental o un kit de parches. Nadie tiene el descaro de escindir su propia organización política rival. Nadie tiene la influencia política. 18.5 Una bifurcación, una división y una reunión Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Ahora, después de todas las historias desagradables de puñaladas por la espalda y disputas, es importante darse cuenta de que en realidad hay algunas historias felices de bifurcaciones que se fusionan nuevamente. Una de las mejores historias proviene de los pasillos de una empresa de seguridad de Internet, C2Net, que se ocupó de una bifurcación de una manera muy pacífica. C2Net es una empresa con sede en Berkeley dirigida por algunos defensores incondicionales de la privacidad y el anonimato en línea. La compañía comenzó ofreciendo un servicio de reenvío que permitía a las personas enviarse correos electrónicos anónimos entre sí. Su sitio eliminaría la dirección del remitente y se la pasaría al destinatario sin dejar rastro de quién la envió. Su objetivo era satisfacer la necesidad de personas como denunciantes, filtradores y otras personas en posiciones de debilidad que querían usar el anonimato para evitar represalias. La compañía pronto asumió un objetivo mayor cuando decidió modificar el popular servidor web Apache agregando un cifrado fuerte para que las personas pudieran procesar tarjetas de crédito a través de la web. La tecnología, conocida como SSL por "capa de conexión segura", dispuso automáticamente que todo el tráfico entre un servidor web remoto y el usuario se codificara para que nadie pudiera espiar. SSL es una tecnología muy popular en la web hoy en día porque muchas empresas la utilizan para codificar números de tarjetas de crédito para derrotar a los intrusos. C2Net llamó mucho la atención cuando uno de sus fundadores, Sameer Parekh, apareció en la portada de la revista Forbes con un titular que decía que quería "derrocar al gobierno". En realidad, C2Net quería trasladar las operaciones de desarrollo al exterior, donde no había regulaciones sobre la creación de software criptográficamente seguro. C2Net fue donde el talento estaba disponible y tenía el precio justo. En este caso, C2Net eligió una versión gratuita de SSL escrita por Eric Young conocida como SSLeay. El trabajo de Young es otro de los casos de éxito del código abierto. Escribió la versión original como pasatiempo y la lanzó con una licencia similar a BSD. A todos les gustó su código, lo descargaron, experimentaron con él y lo usaron para explorar los límites del protocolo. Young simplemente estaba intercambiando código con la red y pasándoselo bien. Parekh y C2Net vieron una oportunidad. Fusionarían dos productos gratuitos, el servidor web Apache y SSLeay de Young, y crearían una versión segura para que la gente pudiera configurar fácilmente sitios de comercio seguro para Internet. Llamaron a este producto Stronghold y lo pusieron en el mercado comercialmente. La decisión de C2Net de cobrar por el software molestó a algunas personas. Tomaron dos paquetes de software gratuitos y los convirtieron en algo comercial. Esto no fue solo un tenedor, a algunos les pareció un robo. Por supuesto, estas quejas no eran realmente justas. Ambas colecciones de código surgieron con una licencia de estilo BSD que otorgaba a todos el derecho a crear y vender adiciones comerciales al producto. No había ningún requisito similar a la GPL que devolvieran a la comunidad. Si nadie quería una versión comercial, no deberían haber lanzado el código con una licencia muy abierta en primer lugar. Parekh entiende estas objeciones y dice que ha soportado muchas críticas en las listas de correo internas. Aún así, siente que el producto Stronghold contribuyó en gran medida a la fortaleza de Apache al legitimarlo. "No me siento culpable por eso. No creo que hayamos contribuido con mucho código fuente, que es una de las métricas clave que usa la gente del grupo Apache. En mi perspectiva, la mayor contribución que hemos logrado es la aceptación del mercado", dijo. Parekh no quiere decir que tuvo que generar aceptación en el mercado entre los desarrolladores web. El grupo Apache estaba haciendo un buen trabajo al lograr eso a través de sus tácticas de guerrilla, excelente producto y precio gratuito. Pero nadie enviaba un mensaje a los niveles más altos de la industria informática, donde se hacían planes a largo plazo y se cerraban tratos corporativos. Parekh siente que construyó una respetabilidad de primera clase para el nombre de Apache al crear y respaldar un producto de primera clase que las grandes corporaciones podrían usar con éxito. Se aseguró de que todos supieran que Apache estaba en el centro de Stronghold, y la gente se dio cuenta. El primer trabajo de Parekh fue obtener una licencia de patente de RSA Data Security. El software seguro como SSL se basa en el algoritmo RSA, una idea que fue patentada por tres profesores del MIT en la década de 1970. Esta patente está controlada por RSA Data Security. Si bien la empresa publicitó algunos de los términos de su licencia y se esforzó por comercializar la tecnología, negociar una licencia no fue un detalle trivial que pudiera ser manejado por algún equipo de software libre. ¿Quién va a pagar la licencia? ¿Quién va a calcular qué porcentaje de libre es? ¿Quién va a subir con el dinero? Estas preguntas son mucho más fáciles de responder si usted es una corporación que cobra a los clientes por comprar un producto. C2Net estaba haciendo eso. Las personas que compraron Stronghold obtuvieron una licencia de RSA que garantizaba que podían usar el método sin ser demandados. La patente fue sólo el primer obstáculo. SSL es una tecnología que intenta brindar cierta seguridad a las conexiones web mediante el cifrado de las conexiones entre el navegador y el servidor. Netscape agregó una función que permite establecer una conexión solo si el servidor tiene un certificado digital que lo identifica. Estos certificados solo se emiten a una empresa después de pagar una tarifa a un agente de certificados registrado como Verisign. Al principio, los agentes de certificados como Verisign emitían certificados solo para servidores creados por grandes empresas como Netscape o Microsoft. Apache era solo un grupo amorfo en la red. Verisign y las demás autoridades no le estaban prestando atención. Parekh se acercó a ellos y los convenció de que comenzaran a emitir los certificados para poder comenzar a vender Stronghold. "Nos convertimos en el número tres, justo detrás de Microsoft y Netscape. Luego vieron cuánto dinero ganaban con nosotros, así que comenzaron a firmar certificados para todos", dijo. Otros proyectos de Apache que usaban SSL encontraron la vida mucho más fácil una vez que Parekh le mostró a Verisign que se podía ganar mucho dinero con personas que usaban software libre. Parekh no niega que C2Net no haya hecho muchas contribuciones al código base de Apache, pero no cree que esta sea la mejor medida. El trabajo político y de marketing de establecer a Apache como una herramienta valiosa es algo que, en su opinión, puede haber sido más crucial para su salud a largo plazo. Cuando empezó a poner dinero en manos de Verisign, consiguió que esa gente se diera cuenta de que Apache tenía una cuota de mercado real. Ese efectivo habló. El tenedor Stronghold, sin embargo, no hizo felices a todos. SSL es una herramienta importante y alguien iba a empezar a crear otra versión gratuita. C2Net contrató a Eric Young y su colaborador Tim Hudson y les pagó para que hicieran un trabajo para Stronghold. La versión principal del SSLeay original de Young permaneció abierta, y ambos continuaron agregando correcciones de errores y otras mejoras con el tiempo. Parekh se sintió cómodo con esta relación. Aunque Stronghold pagaba los salarios de Young y Hudson, también dedicaban parte de su tiempo libre a mantener actualizado su conjunto de herramientas SSLeay. Aún así, la idea de una versión gratuita de SSL era un proyecto tentador para que alguien lo emprendiera. Mucha gente lo quería. El comercio digital seguro lo exigía. Hubo muchos incentivos económicos que empujaron para que sucediera. Eventualmente, un alemán llamado Ralf S. Engelschall dio un paso al frente y escribió una nueva versión que llamó modSSL. Engelschall es un contribuyente respetado del esfuerzo de Apache, y ha escrito o contribuido a varios módulos diferentes que podrían agregarse a Apache. Él llama a uno el "módulo modrewrite que baila y canta" para manejar URL fácilmente. De repente, la nueva versión de Engelschall significó que había tenedores de duelo. Una versión salió de Australia, donde los creadores trabajaban para una empresa que vendía una versión patentada del código. C2Net distribuyó la versión australiana y se concentró en hacer que su producto fuera fácil de instalar. El otro salió de Europa, distribuido gratis por alguien comprometido con una licencia de código abierto. La interfaz puede haber sido un poco más tosca, pero no costó dinero y venía con el código fuente. El potencial de batalla entre SSLeay y modSSL podría haber sido grandioso. Las dos partes revisaron sus opciones. Parekh debe haberse sentido un poco frustrado y en desventaja. Tenía una empresa que estaba haciendo un buen producto con compradores habituales. Entonces apareció una solución de código abierto. Stronghold de C2Net cuesta dinero y no viene con código fuente, mientras que modSSL de Engelschall no cuesta nada y viene con código. Esos eran aspectos negativos importantes que solo podía combatir aumentando el servicio. Cuando se le preguntó a Engelschall si su versión gratuita promocionaba C2Net, respondió el correo electrónico con el mensaje escrito "[sonrisa]". En esencia, C2Net se enfrentó a la misma situación que muchas empresas importantes como Microsoft y Apple en la actualidad. Los clientes ahora tenían una solución viable de código abierto para sus problemas. Nadie tuvo que pagar a C2Net por el software. Los usuarios de los Estados Unidos necesitaban una licencia de patente, pero expiraría a finales de 2000. Afortunadamente, Parekh es un verdadero devoto del mundo del código abierto, aunque ha estado dirigiendo una empresa de código propietario durante los últimos años. Observó el problema y decidió que la única forma de mantenerse con vida era unir fuerzas y reparar el tenedor. Para empeorar las cosas, Hudson y Young dejaron C2Net para trabajar en RSA Data Security. Parekh perdió a dos miembros importantes de su equipo y enfrentó una competencia intensa. Afortunadamente, su devoción por el código abierto vino al rescate. Hudson y Young no pudieron retractarse del trabajo que hicieron en SSLeay. Era de código abierto y estaba disponible para todos. Parekh, Engelschall, varios empleados de C2Net y varios otros se sentaron (por correo electrónico) y crearon un nuevo proyecto al que llamaron OpenSSL. Este grupo llevaría la antorcha de SSLeay y la mantendría actualizada. Young y Hudson dejaron de contribuir y dedicaron su tiempo a crear una versión comercial de RSA Data Security. Parekh dice de la época: "Aunque fue un serio revés para C2Net que RSA pirateara a nuestra gente, fue bueno para el público. El desarrollo realmente se aceleró cuando comenzamos con OpenSSL. Se involucró más gente y el control se volvió menos centralizado. Se volvió más como el grupo Apache. Es mucho más grande de lo que era antes y es mucho más fácil para cualquiera contribuir". Parekh también trabajó en la reparación de vallas con Engelschall. C2Net comenzó a adoptar parte del código modSSL y lo combinó en su última versión de Stronghold. Para facilitar esta combinación, C2Net comenzó a enviar parte de su código anteriormente propietario a Engelschall para que pudiera mezclarlo con modSSL y lanzarlo como código abierto. En esencia, C2Net estaba evitando una competencia desastrosa al ser amable y compartir con este competidor. Es un movimiento sorprendente que podría no suceder en los negocios habituales. La decisión de Parekh parece abierta y benéfica, pero tiene una cierta cantidad de interés propio detrás. Él explica: "Simplemente decidimos contribuir con todas las características que teníamos en modSSL para poder comenzar a usar modSSL internamente, porque hace que nuestro mantenimiento sea más fácil. No tenemos que mantener nuestra propia versión patentada de modSSL. Concedido, hemos mejorado la versión pública, pero esas características no eran significativas". Esta mezcla no fue particularmente complicada, la mayor parte se centró en la estructura de las partes del código fuente que manejan la interfaz. Los programadores los llaman los "ganchos" o la "API". Si Stronghold y modSSL usan la misma estructura de enlace, entonces conectarlos es pan comido. Si Engelschall hubiera cambiado la estructura de enlace de modSSL, entonces C2Net habría tenido que hacer más trabajo. La decisión de contribuir con el código impidió que Engelschall hiciera el trabajo él mismo de una manera que podría haber causado más dolor a C2Net. "De hecho, estaba planeando implementarlos él mismo, por lo que sería mejor que contribuyéramos con los nuestros para evitar problemas de compatibilidad", dice Parekh. Es decir, a Parekh le preocupaba que Engelschall fuera a implementar todas las funciones que usaba C2Net, y había un peligro muy real de que Engelschall las implementara de una manera que Parekh no pudiera utilizar. Luego habría una bifurcación más seria que dividiría aún más a los dos grupos. C2Net no podría tomar prestado el código de la versión gratuita de OpenSSL muy fácilmente. Así que decidió contribuir con su propio código. Fue más fácil dar su código y garantizar que OpenSSL encajaba perfectamente en Stronghold. En esencia, C2Net optó por ceder un poco para poder seguir obteniendo todas las mejoras futuras. No es muy diferente de la industria del automóvil. No hay nada intrínsecamente mejor o peor en los autos que tienen el volante en el lado derecho. Son mucho más fáciles de usar en Inglaterra. Pero si surgiera algún equipo de desarrollo de ingeniería de automóviles gratuito en Inglaterra, podría tener sentido que una empresa de EE. UU. donara el trabajo temprano para garantizar que el producto final pueda tener el volante a ambos lados del automóvil sin un rediseño extenso. Si Ford simplemente se sentara y esperara obtener el producto final gratuito, podría descubrir que los ingenieros británicos diseñaron felizmente para las únicas carreteras que conocían. Engelschall está feliz con este cambio. Escribió en un mensaje de correo electrónico: "Hacen el único enfoque razonable: basan su servidor en modSSL porque saben que no pueden sobrevivir contra la solución de código abierto con su antiguo código propietario. Y al contribuir con cosas a modSSL implícitamente hacen su mejor su propio producto. De esta manera ambas partes se benefician". Parekh y C2Net ahora tienen un desafío. Deben continuar haciendo que el paquete Stronghold sea mejor que la versión gratuita para justificar el costo que la gente está pagando. No todas las bifurcaciones terminan con una historia tan alegre de cooperación mutua. Tampoco todas las historias en el mundo del software libre terminan con la corporación lucrativa dando la vuelta y devolviendo su código propietario al esfuerzo general. Pero el caso de C2Net/OpenSSL ilustra cómo la naturaleza del desarrollo de software alienta a las empresas y personas a dar y cooperar para satisfacer sus propias necesidades egoístas. El software puede hacer una variedad de cosas maravillosas, pero la estructura a menudo determina qué tan fácil es para algunos de nosotros usarlo. Tiene sentido dedicar más tiempo y hacer donaciones a un proyecto de software libre si quiere asegurarse de que el producto final se ajuste a sus especificaciones. La buena noticia es que la mayoría de la gente no tiene muchos incentivos para romper y bifurcar su propio proyecto. Si permanece en el mismo equipo, puede usar fácilmente todos los resultados producidos por los otros miembros. Cooperar es mucho más fácil que luchar porque las personas tienen un gran incentivo para permanecer juntas. Si no fuera tan egoísta, sería conmovedor. ---------------------------- 19. Núcleo Los proyectos en corporaciones tienen gerentes que reportan a otros gerentes que reportan al CEO que reporta a la junta. Todo es muy simple en teoría, aunque en realidad nunca funciona de esa manera en la práctica. Las líneas de control se cruzan cuando las personas forman alianzas y luchan por mantener contentos a sus jefes. Los proyectos en el mundo del software de código abierto, por otro lado, les dan a todos una copia del código fuente y les permiten ser los maestros del código que se ejecuta en su máquina. Todos pueden ser la Junta Directiva, el CEO y los siervos del cubículo, todo en uno. Si a un usuario de software libre no le gusta algo, entonces tiene el poder de cambiarlo. ¿No te gusta ese icono? Bum, se ha ido. ¿No quieres KDE en tu escritorio? Whoosh, está fuera de allí. Ningún vicepresidente a cargo del marketing de MSN en Redmond lo obligará a tener un ícono para una fácil conexión a Microsoft Network en su escritorio. Ningún diseñador gráfico en Apple lo obligará a mirar ese logotipo de MacOS de dos caras al estilo de Picasso todas las mañanas de su vida solo porque sus estudios de marketing muestran que necesitan construir una identidad de marca sólida. Eres el capitán de tu barco de software libre y decides el menú, el rumbo, la disposición de las tumbonas, la ubicación de los miradores d esde los que observar los icebergs, el tipo de jabón y el número de palillos por pasajero para orden. En teoría, usted es el Lord High Master y el Más Exaltado Gobernante de todo el software, grande y pequeño, salvaje y maravilloso, e interpretado y compilado en su máquina. En la práctica, nadie tiene tiempo para usar todo ese poder. Es francamente aburrido preocuparse por el jabón y los palillos de dientes. Es agotador reconstruir sistemas de ventanas cuando no cumplen con sus gustos de software de grado caviar. Nadie tiene el espacio en disco para mantener una colección de protectores de pantalla, administradores de ventanas, motores de diseño y juegos para su computadora al estilo de Imelda Marcos. Así que empiezas a salir con algunos amigos que quieren cosas similares y lo siguiente que sabes es que tienes un grupo. Un grupo necesita liderazgo, por lo que surge el perro alfa. Muy pronto, todo comienza a parecerse a un equipo de desarrollo corporativo. Bueno, algo así. Muchos neófitos en el mundo del software libre a menudo se sorprenden al descubrir que la mayor parte del mejor código fuente gratuito que existe proviene de equipos que se parecen sorprendentemente a grupos de desarrollo corporativos. Mientras que las licencias y la retórica prometen la libertad de seguir tu propio camino, los grupos se unen por muchas de las mismas razones por las que surgen las caravanas y los convoyes. Hay poder en los números. A veces estos grupos incluso se ponen tan serios que se incorporan. El grupo Apache formó recientemente la Fundación Apache, que tiene el trabajo de guiar y apoyar el desarrollo del servidor web Apache. Todo tiene un aspecto muy oficial. Por lo que sabemos, ahora mismo están poniendo cubículos en las oficinas de la fundación. Este instinto de trabajar juntos es una fuerza tan poderosa en el mundo del software libre como el instinto de tomar tanta libertad como sea posible y usarla todos los días. En todo caso, es sólo una característica esencial de la vida humana. Los fundadores de los Estados Unidos de América crearon una constitución completa sin mencionar los partidos políticos, pero una vez que presionaron el botón de inicio, los partidos aparecieron de la nada. Estas partes también surgieron en el mundo del software libre. Cuando los proyectos crecieron más de lo que una persona podía manejar con seguridad, por lo general se convirtieron en equipos de desarrollo. El camino de cada grupo es algo diferente, y cada uno desarrolla su propio estilo particular. La solidez de esta organización suele ser el determinante más importante de la solidez del software, porque si las personas pueden trabajar bien juntas, los problemas del software se resolverán correctamente. La forma de gobierno más prevalente en estas comunidades es la dictadura benigna. Richard Stallman escribió algunos de los códigos más importantes en el panteón de GNU, y continúa escribiendo código nuevo y ayudando a mantener el software anterior. El mundo del kernel de Linux está dominado por Linus Torvalds. Los fundadores originales siempre parecen tener una fuerte influencia sobre el grupo. La mayor parte del código en el kernel de Linux está escrito por otros y verificado por un estrecho círculo de amigos, pero Torvalds aún tiene la última palabra sobre muchos cambios. Los dos son, por supuesto, dictadores benignos, y los dos realmente no tienen otra opción. Ambos tienen una cantidad aparentemente absoluta de poder, pero este poder se basa en una mezcla de afecto personal y respeto técnico. No hay límites legales que mantengan a todos los desarrolladores en línea. No hay reglas sobre propiedad intelectual o no divulgación. Cualquiera puede obtener todo el kernel de Linux o el código fuente de GNU, ejecutarlo y comenzar a realizar los cambios que desee. Podrían cambiarle el nombre a FU, Bobux, Fredux o Meganux y nadie podría detenerlos. Las viejas amenazas de abogados, armas y dinero no se ven por ninguna parte. 19.1 Equipo central de Debian Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. El grupo Debian tiene un pedigrí maravilloso y muchos lo elogian como la versión más pura de Linux que existe, pero comenzó como un grupo de forajidos que se amotinaron y arrojaron a Richard Stallman por la borda. Bueno, en realidad no fue tan dramático. De hecho, "motín" no es realmente la palabra correcta cuando todos son libres de usar el código fuente como quieran. Bruce Perens recuerda que la división ocurrió menos de un año después de que comenzara el proyecto y dice: "Debian ya había comenzado. La FSF había estado financiando a Ian Murdock durante unos meses. Richard en ese momento quería que hiciéramos todos los ejecutables sin desmontar". Cuando los programadores compilan software y lo convierten de un código fuente legible por humanos a un código binario legible por máquina, a menudo dejan información legible por humanos para ayudar a depurar el programa. Otra forma de decir esto es que los programadores no eliminan las etiquetas de depuración del código. Estas etiquetas son solo los nombres de las variables utilizadas en el software, y un programador puede usarlas para analizar qué contenía cada variable cuando el software comenzó a volverse loco. Perens continuó: "Su idea era que, si había un problema, alguien podía enviar un stacktrace sin tener que volver a compilar un programa y luego hacer que fallara de nuevo. El problema con esto era que la distribución de los ejecutables sin eliminar los hacía cuatro veces más grandes. Era un muchos gastos adicionales y problemas. Y nuestro software no volcó el núcleo de todos modos. Ese fue realmente el resultado final. Ese tipo de error no apareció tan a menudo como para que tuviéramos que distribuir las cosas de esa manera de todos modos". Aun así, Stallman insistió en que era una buena idea. Debian se resistió y dijo que ocupaba demasiado espacio y aumentaba los costos de duplicación. Eventualmente, el debate terminó cuando el grupo Debian siguió su propio camino. Aunque Stallman le pagó a Murdock y escribió gran parte del código GNU en el disco, la GPL le impidió hacer mucho. El proyecto continuó. El código fuente sobrevivió. Y los discos de Debian siguieron enviándose. Stallman ya no era el líder titular de Debian. La brecha entre el grupo se ha curado en gran medida. Perens ahora elogia a Stallman y dice que los dos todavía están muy cerca filosóficamente en los temas más importantes en el mundo del software libre. Stallman, por su parte, usa Debian en sus máquinas porque siente la afinidad más cercana con él. Perens dice: "Richard en realidad ha crecido mucho en los últimos años. Ha aprendido mucho más sobre qué hacer con un voluntario porque, obviamente, somos libres de marcharnos en cualquier momento". El propio Stallman recuerda el argumento con bastante elocuencia: "El hecho es que quería influir en ellos, pero no quería forzarlos. Forzarlos iría en contra de mis creencias morales. Creo que las personas tienen derecho a la libertad en estos asuntos, lo cual significa que no puedo decirles qué hacer", me dijo. "Escribí la GPL para liberar a todos de la dominación de los autores de software, y eso me incluye a mí en ambos lados". Hay mucho debate sobre la mejor manera de ser un dictador benigno. Eric Raymond y muchos otros sienten que el mayor reclamo de éxito de Torvalds fue crear un buen modelo de desarrollo. Torvalds lanzó nuevas versiones de su kernel con frecuencia y trató de compartir las noticias sobre el desarrollo de la manera más abierta posible. La mayor parte de estas noticias viajan a través de una lista de correo abierta a todos y archivada en un sitio web. La lista de correo es una especie de congreso perpetuo donde la gente debate los problemas técnicos detrás de los últimos cambios en el núcleo. A menudo es mucho mejor que el verdadero Congreso de los Estados Unidos porque el foro de debate está abierto a todos y no hay intereses especiales evidentes que intenten dirigir el debate en su dirección. Después de un período de debate, finalmente Torvalds toma una decisión y esta se convierte en definitiva. Por lo general, no necesita hacer nada. La respuesta es bastante obvia para todos los que han seguido l a discusión. Este ejército es un grupo diverso. En una reciente conferencia sobre Linux, Jeff Bates, uno de los editores del influyente sitio web Slashdot (www.slashdot.org), me indicó el stand de Debian, que estaba al lado del suyo. "Si miras en el stand, puedes ver ese mapa. Pusieron una chincheta en el tablero para cada desarrollador y líder de proyecto que tienen en todo el mundo. China, Países Bajos, Somalia, hay gente que viene de todas partes". James Lewis-Moss es uno de los miembros, que casualmente se encontraba en el puesto de Debian de al lado. Vive en Asheville, Carolina del Norte, que está a cuatro horas al oeste del Centro de Convenciones en el centro de Raleigh. El grupo Debian normalmente depende de voluntarios locales para atender el stand, responder preguntas, distribuir CD-ROM y mantener a la gente interesada en el proyecto. Lewis-Moss está oficialmente a cargo del mantenimiento de varios paquetes, incluido X Emacs, un programa que se usa para editar archivos de texto, leer correos electrónicos y noticias, y realizar otras tareas. Un paquete es el nombre oficial de un conjunto de programas, archivos, datos y documentación más pequeños. Estas partes normalmente se instalan juntas porque el software no funcionará sin todos sus componentes. El trabajo del empaquetador es descargar el software más reciente del programador y asegurarse de que funcione bien con la última versión del otro software para la distribución de Debian. Esta tarea crucial es la razón por la que grupos como Debian son tan necesarios. Si Lewis-Moss hace bien su trabajo, alguien que instale Debian en su computadora no tendrá problemas para usar X Emacs. El trabajo de Lewis-Moss no es exactamente programar, pero está cerca. Tiene que descargar el código fuente, compilar el programa, ejecutarlo y asegurarse de que la última versión del código fuente funcione correctamente con la última versión del kernel de Linux y las demás partes del sistema operativo que mantienen el sistema en funcionamiento. El empaquetador también debe asegurarse de que el programa funcione bien con las herramientas específicas de Debian que facilitan la instalación. Si hay errores obvios, él mismo los arreglará. De lo contrario, trabajará con el autor para localizar y solucionar los problemas. Es bastante modesto acerca de este esfuerzo y dice: "La mayoría de los desarrolladores de Debian no escriben mucho código para Debian. Solo probamos las cosas para asegurarnos de que funcionen bien juntas. Sería ofensivo para algunos de los programadores escuchar eso". algunas personas de Debian están escribiendo los programas cuando en realidad no lo hacen". Agregó que muchos de los empaquetadores también son programadores en otros proyectos. En su caso, escribe programas Java durante el día para una empresa que fabrica terminales de punto de venta para tiendas. Lewis-Moss terminó con este trabajo en la tradicional tradición de los comités y organizaciones de voluntarios en todas partes. “Informé un error en X Emacs a Debian. El tipo que tenía el paquete en ese momento dijo: 'Ya no quiero esto. ¿Lo quieres?' Supongo que fue al azar. Fue una especie de accidente. No tenía la intención de involucrarme en eso, pero era algo que me interesaba. Pensé: 'Diablos, también podría'". El esfuerzo de desarrollo de Linux avanza lentamente con miles de historias como la de Lewis-Moss. La gente viene, revisa el código y agrega algunas contribuciones que lo hacen un poco mejor para ellos. La lista de correo debate algunos de los cambios si son controvertidos o si afectarán a muchas personas. Es un sistema muy eficiente en muchos sentidos, si puedes soportar el calor de los debates. La mayoría de los estadounidenses están bastante alejados de las acaloradas discusiones que hierven en los pasillos de Washington. La vista del piso de la Cámara y el Senado es en gran medida solo para mostrar porque la mayoría de los miembros no asisten a los debates. Las verdaderas decisiones se toman en cuartos traseros. Las listas de correo que forman el núcleo de los diferentes proyectos de software libre toman todo este debate y lo transmiten directamente a los miembros. Si bien algunas discusiones ocurren en cartas privadas e incluso en llamadas telefónicas ocasionales, gran parte del problema y la controversia se diseccionan para que todos los lean. Esto es crucial porque la mayoría de las decisiones se toman en gran medida por consenso. “La mayoría de las decisiones son técnicas y la mayoría de ellas tendrán la respuesta correcta o la mejor posible en ese momento”, dice Lewis-Moss. "A menudo, las cosas se reducen a quién está dispuesto a hacer el trabajo. Si estás dispuesto a hacer el trabajo y la persona del otro lado no lo está, entonces la tuya es la correcta por definición". Si bien la lista de correo parece una noción idealizada de un congreso para el desarrollo del kernel de Linux, no es tan perfecta como parece. No todos los comentarios son tomados por igual porque las amistades y alianzas políticas han evolucionado a través del tiempo. El grupo de Debian eligió a un presidente para tomar decisiones cruciales que no pueden tomarse mediante argumentos profundos y consenso. El presidente no tiene muchos otros poderes en otros casos. Mientras que los mundos de Linux y GNU están dominados por su gran Rey Sol, muchos otros proyectos de código abierto han adoptado una estructura de gobierno más moderna que se parece más a Debian. Los grupos siguen siendo bastante ad hoc y no oficiales, pero son más democráticos. Hay menos idolatría y menos dependencia de una sola persona. El grupo Debian es un buen ejemplo de una estructura muy suelta con menos dependencia del líder central. Al principio, Ian Murdock inició la distribución e hizo gran parte de la coordinación. Con el tiempo, la lista de correo creció y atrajo a otros desarrolladores como Bruce Perens. A medida que Murdock se volvió más ocupado, comenzó a entregar trabajo a otros. Eventualmente, entregó el control central a Perens, quien poco a poco delegó más control hasta que no quedó ningún mantenedor clave. Si alguien muere en un accidente de autobús, el grupo seguirá vivo. Ahora un gran grupo de personas actúan como mantenedores de los diferentes paquetes. Cualquiera que quiera trabajar en el proyecto puede asumir la responsabilidad de un paquete en particular. Esta podría ser una herramienta pequeña como un juego o una herramienta más grande como el compilador de C. En la mayoría de los casos, el mantenedor no es el autor del software ni siquiera un programador empedernido. El trabajo del mantenedor es asegurarse de que el paquete en particular continúe funcionando con el resto. En muchos casos, este es un trabajo bastante fácil. La mayoría de los cambios en el sistema no afectan a los programas simples. Pero en algunos casos es un verdadero desafío y el mantenedor debe actuar como enlace entre Debian y el programador original. A veces, los mantenedores corrigen los errores ellos mismos. A veces simplemente los denuncian. Pero en cualquier caso, el mantenedor debe asegurarse de que el código funcione. De vez en cuando, Debian toma el núcleo estable más reciente del equipo de Torvalds y lo mezcla con todos los demás paquetes. Los mantenedores revisan sus paquetes y cuando todo funciona bien, Debian presiona otro CD-ROM y coloca la pila de código en la red. Este es un "congelamiento" estable que hace el grupo Debian para asegurarse de tener una plataforma estable a la que la gente siempre pueda recurrir. "Crear un sistema operativo completo con solo un grupo de voluntarios y sin dinero es un gran logro. Nunca se puede descartar eso. Red Hat lo tiene fácil. Todos reciben un pago. El hecho es que Debian es un buen sistema y aún continúa haciéndolo. No creo que haya habido tantos proyectos colaborativos no remunerados tan complejos antes", dice Perens. Cuando Perens se hizo cargo de Debian, provocó dos cambios importantes. El primero fue crear una corporación sin fines de lucro llamada Software in the Public Interest y hacer arreglos para que el IRS la reconociera como una organización benéfica de buena fe. Las personas y empresas que donen dinero y equipos pueden descontarlos de sus impuestos. Perens dice que el presupuesto del grupo es de unos 10.000 dólares al año. "A veces pagamos por el hardware. Aunque gran parte de nuestro hardware es donado. Llevamos a la gente a conferencias para que puedan promocionar Debian. Tenemos un puesto en la feria comercial. En general, obtenemos el espacio de la feria comercial gratis o con grandes descuentos . También tenemos los apartados postales convencionales, la contabilidad, las llamadas telefónicas. El proyecto no tiene mucho dinero, pero tampoco gasta mucho". El grupo Debian también escribió las primeras pautas para el software de código abierto aceptable durante el tiempo que Perens estuvo a cargo. Estos finalmente mutaron para convertirse en la definición respaldada por la Iniciativa de código abierto. Esto no es demasiado sorprendente, ya que Perens fue uno de los fundadores de la Iniciativa de código abierto. El éxito de Debian ha inspirado a muchos otros. Red Hat, por ejemplo, tomó prestada una cantidad significativa del trabajo realizado por Debian cuando armaron su distribución, y Debian toma prestadas algunas de las herramientas de Red Hat. Cuando Red Hat salió a bolsa, hizo arreglos para que los miembros de Debian tuvieran la oportunidad de comprar algunas de las acciones de la compañía reservadas para amigos y familiares. Reconocieron que el equipo de mantenedores de paquetes de Debian ayudó a realizar su trabajo. La constitución de Debian y su sólida estructura política también han inspirado a Sun, que está tratando de unir a sus clientes de Java y Jini en una comunidad. La compañía enmarca sus esfuerzos para apoyar a los clientes como la creación de una comunidad protegida por una constitución. El antiguo paradigma de atención al cliente está siendo reemplazado por un mundo más activo de participación y representación del cliente. Por supuesto, Sun se mantiene al tanto de todos estos cambios. Protegen su código fuente con una Licencia de fuente comunitaria que impone restricciones cruciales a la capacidad de desviarse de estos miembros de la comunidad. No hay libertad real para bifurcar. Sun no está dispuesto a aceptar el liderazgo de Debian en ese punto, en parte porque dicen que temen que Microsoft use esa libertad para hundir a Java. 19.2 Núcleo corporativo de Apache Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. El grupo Apache es uno de los equipos de desarrollo más profesionales en el mundo del código libre. Surgió a mediados de la década de 1990, cuando la World Wide Web apenas estaba floreciendo. En los primeros años, muchos sitios dependían de servidores web como la versión gratuita que venía de la NCSA, el centro de supercomputación de la Universidad de Illinois que ayudó a desencadenar la revolución web al escribir un servidor y un navegador. Este código fue excelente, pero rara vez cumplió con todos los propósitos de los nuevos webmasters que iniciaban nuevos sitios y creaban nuevas herramientas tan rápido como podían. Brian Behlendorf, uno de los fundadores del grupo Apache, recuerda la época. "No era solo una especie de aficionado. Necesitábamos un software de calidad comercial y esto fue antes de que Netscape lanzara su software. Habíamos desarrollado nuestro propio conjunto de parches que intercambiamos como cromos de béisbol. Finalmente dijimos: 'Nosotros tenía tantos caminos que se superponen. ¿Por qué no creamos nuestra propia versión y continuamos por nuestra cuenta? Estos desarrolladores luego se fusionaron en un grupo central y establecieron una estructura para el código. Eligieron la licencia básica de estilo BSD para su software, que permitía a cualquiera usar el código para cualquier propósito sin distribuir el código fuente a ningún cambio. Muchos miembros del grupo vivían en Berkeley entonces y todavía viven en el área hoy. Por supuesto, la licencia de estilo BSD también tenía sentido para muchos de los desarrolladores que estaban involucrados en los negocios y que a menudo no querían saltar al mundo del código abierto con lo que vieron como el fervor absolutista de Stallman. Las empresas podrían adoptar el código Apache sin temor a que alguna licencia les obligara a revelar su código fuente más adelante. El único inconveniente era que no podían llamar al producto Apache a menos que fuera una copia sin modificar de algo aprobado por el grupo Apache. Varios miembros del grupo se fueron y formaron sus propias empresas y utilizaron el código como base para sus productos. Sameer Parekh basó el producto del servidor Stronghold en Apache después de que su empresa agregara las herramientas de cifrado utilizadas para proteger la información de la tarjeta de crédito. Otros simplemente usaron versiones de Apache para servir sitios web y facturaron a otros por el costo del desarrollo. En 1999, el grupo decidió formalizar su membresía y crear una corporación sin fines de lucro dedicada a promover el código fuente del servidor Apache y el mundo del código abierto en general. Los nuevos miembros pueden solicitar unirse a la corporación y deben ser aprobados por la mayoría de los miembros actuales. Esta membresía se reúne y vota en una junta directiva que toma las decisiones sustantivas sobre el grupo. Este mundo no es muy diferente del mundo anterior a la corporación. Una lista de correo todavía lleva debate y actúa como el pegamento social para el grupo. Pero ahora el proceso de toma de decisiones está formalizado. Antes, los miembros del grupo central asignaban la responsabilidad a diferentes personas, pero las decisiones solo podían tomarse por consenso aproximado. Este mecanismo podría ser doloroso y conflictivo si el consenso no fuera fácil. Esto obligó a la junta a trabajar arduamente para desarrollar compromisos potenciales, pero los empujó a evitar decisiones más difíciles. Ahora la junta puede votar y una mayoría pura puede ganar. Esta seriedad y corporativización son probablemente los únicos pasos posibles que podría tomar el grupo Apache. Siempre se han dedicado a promover los intereses de los miembros. Muchos de los otros proyectos de código abierto como Linux fueron pasatiempos que se volvieron serios. El proyecto Apache siempre estuvo lleno de personas que estaban en el negocio de construir la web. Si bien algunos pueden extrañar la sensación de pueblo pequeño de los primeros años, la estructura corporativa está aportando más certeza y previsibilidad al ámbito. La gente no tiene que usar traje ahora que es una corporación. Simplemente asegura que las decisiones difíciles se tomarán a un ritmo predecible. Aún así, el formalismo agrega mucha rigidez a la estructura. Un recién llegado emocionado puede unirse a las listas de correo, escribir un montón de código y mover montañas para el grupo Apache, pero no será un miembro de pleno derecho antes de ser votado. En el pasado, un forastero enérgico podría convertir fácilmente el trabajo duro en influencia política en la organización. Ahora, la mayoría de los miembros actuales podrían mantener a los intrusos fuera del círculo interno. Esta burocracia no tiene por qué ser un problema, pero tiene el potencial de fragmentar la comunidad al crear una institución donde algunas personas son más iguales que otras. Mantener la organización abierta en la práctica será un verdadero desafío para la nueva corporación. ------------------------------- 20. Camisetas Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Si hay un panteón para los genios del marketing, entonces debe incluir al tipo que se dio cuenta de que la gente pagaría $ 1 por valor de varios centavos de agua azucarada si viniera en una botella bien formada bendecida con la marca CocaCola. También podría incluir al tipo que descubrió por primera vez que agregar nuevos cristales azules al detergente aumentaría las ventas. Es una raza rara que entiende cómo hacer que la gente gaste dinero que no necesita gastar. La próxima ceremonia de inducción para este panteón debería incluir a Robert Young, el CEO de Red Hat Software, quien ayudó enormemente a Linux y al mundo del código abierto al encontrar una manera de cobrar a las personas por algo que podían obtener de forma gratuita. Este descubrimiento hizo rico al hombre, que no es exactamente lo que se supone que debe hacer el mundo del software libre. Pero su empresa también aportó una sensación de estabilidad y certeza al mercado de Linux, y eso era muy necesario. Muchos programadores empedernidos, que saben lo suficiente como para obtener todo el software gratis, están dispuestos a pagar $70 a Red Hat simplemente porque es más fácil. Si bien algunos pueden estar siempre celosos de los millones de dólares en el bolsillo de Young, todos deberían darse cuenta de que llevar Linux a un mundo más grande de analfabetos informáticos requiere un buen empaque y manejo. El software libre no estaría en ninguna parte si alguien no pudiera encontrar una buena man era de cobrar por él. La mejor manera de entender por qué Young se ubica entre las personas que descubrieron cómo vender agua azucarada es asistir a una conferencia como LinuxExpo. En el centro del piso está el stand atendido por Red Hat Software, la empresa que Young fundó en Raleigh, Carolina del Norte, después de terminar de trabajar en el negocio de arrendamiento de computadoras. Young tiene ahora cincuenta y tantos años y se las arregla para sobrevivir a pesar de que la mayoría de los devotos de su compañía están mucho más cerca de los 13. Red Hat agrupa parte del software gratuito creado por la comunidad y distribuido a través de la red y lo pone en una forma relativamente fácil. -para usar CD-ROM. Cualquiera que quiera instalar Linux o algunos de sus paquetes puede simplemente comprar un disco de Red Hat y presionar un montón de teclas. Toda la información está en un CD-ROM, está relativamente probada y prácticamente lista para funcionar. Si las cosas salen mal, Red Hat promete responder preguntas por cor reo electrónico o por teléfono para ayudar a las personas a que el producto funcione. Red Hat vende su disco a precios que oscilan entre $29,95 y $149,95. Eso le da al usuario una bonita caja, tres CD-ROM que incluyen algunas versiones de demostración de otro software, todo el código fuente, un manual y soporte telefónico o por correo electrónico. Eso es más o menos lo mismo que viene en las cajas de software de una empresa normal. El manual no es tan bueno como los manuales producidos por Apple o Microsoft, pero no es tan malo. La gran diferencia es que nadie necesita comprar el CD-ROM de Red Hat. Cualquiera puede descargar todo el software de la red. Un amigo mío, Hal Skinner, lo hizo ayer y me dijo: "Simplemente lo conecté y el software descargó todo de la red. Obtuve todo en la distribución Red Hat 6.0 y no me costó nada". Por supuesto, a Red Hat no le perjudican demasiado las personas que toman copias sin pagar por ellas. De hecho, la compañía mantiene un sitio web que hace que sea relativamente fácil para las personas hacer precisamente eso. Red Hat no escribió la mayor parte del código. También lo tomaron de varios autores a lo largo de la Red que lo publicaron bajo la Licencia Pública General GNU. Lo agarraron sin pagar por él, por lo que no se molestan mucho si alguien se los quita. La capacidad de obtener software con licencia GPL de toda la red mantiene sus costos de desarrollo mucho más bajos que los de Sun, Apple o Microsoft. Nunca pagaron a la mayoría de los autores del código que envían. Simplemente lo empaquetan. Cualquier otra persona puede ir a buscarlo en la red y tomarlo ellos mismos. Esto prácticamente garantiza que Red Hat estará en un negocio de productos básicos. Para empeorar las cosas para Red Hat, los competidores potenciales no tienen que salir a la red y volver a montar la colección de software por sí mismos. La GPL prohíbe específicamente que las personas pongan limitaciones a la redistribución del código fuente. Eso significa que un competidor potencial no tiene que hacer mucho más que comprar una copia del disco de Red Hat y enviarlo a la planta de prensado de CD-ROM. La gente hace esto todo el tiempo. Una empresa en la exposición vendía copias de todas las principales distribuciones de Linux como Red Hat, Slackware y OpenBSD por alrededor de $3 por disco. Si compraste al por mayor, podrías obtener 11 discos por $25. No es un mal negocio si eres un consumidor. Entonces, en un lado del piso, Young tenía un puesto llamativo lleno de trabajadores que hablaban de lo que podría obtener si pagara $50 o más por la versión 6.0 de Red Hat con nuevas mejoras como GNOME. A solo unos cientos de pies de distancia, una compañía vendía copias falsas de los mismos CD por $3. Cualquier empresa que pueda mantenerse en el negocio en un clima como ese debe estar haciendo algo bien. No es muy diferente del supermercado. Alguien puede pagar $ 1 o más por dos litros de Coca-Cola, o puede caminar por algunos pasillos y comprar Kool-Aid y azúcar sin refinar. Puede ser mucho más barato comprar los ingredientes crudos, pero muchas personas no lo hacen. Young también es lo suficientemente inteligente como para aprovechar la competencia de otros proveedores de discos baratos. No puede hacer nada con respecto a las restricciones de la GPL que lo obligan a compartir con competidores de imitación, por lo que aprovecha al máximo. "Cuando la gente se queja de cuánto cobramos por el software gratuito, les digo que vayan a CheapBytes.com", dijo en la Expo. Esta es solo una de las empresas que duplica regularmente los CD de Red Hat y los revende. Red Hat a menudo recibe críticas de personas que dicen que la compañía simplemente se está beneficiando del arduo trabajo de otros que han compartido su software con la GPL. ¿Qué les da derecho a cobrar tanto por el software de otras personas? Pero Young señala que la gente puede obtener el software por $3. Debe haber una razón racional por la que están comprando Red Hat. Por supuesto, los dos paquetes no son exactamente iguales. Tanto el CD-ROM original como el de imitación pueden tener exactamente el mismo contenido, pero los extras son diferentes. El paquete de Red Hat viene con "soporte", un concepto bastante amorfo en el negocio del software. En teoría, Red Hat tiene un equipo de personas sentadas en sus oficinas que esperan diligentemente para responder las preguntas de los clientes que no pueden lograr que el software de Red Hat haga lo correcto. En la práctica, las preguntas suelen ser tan difíciles o confusas que ni siquiera el equipo de soporte puede responderlas. Cuando intenté por primera vez que Red Hat se ejecutara en una PC antigua, el equipo de soporte solo pudo decirme que nunca prometieron que su paquete se ejecutaría en mi original y ligeramente oscuro chip Cyrix MediaGX. Eso no fue de mucha ayuda. Otros probablemente han tenido mejor suerte porque estaban usando una computadora más estándar. Por supuesto, no tuve problemas para instalar Red Hat en mi última máquina y ni siquiera necesité contactar al soporte técnico. Los paquetes de Red Hat también vienen con un libro que trata de responder algunas de las preguntas por adelantado. Este manual describe el procedimiento básico de instalación, pero no entra en detalles sobre el software incluido en la distribución. Si desea saber cómo ejecutar el paquete de la base de datos, debe profundizar en el soporte en línea proporcionado por los desarrolladores de la base de datos. Mucha gente disfruta comprando estos paquetes adicionales como el manual y el soporte, incluso si nunca los usan. Red Hat ha florecido al brindar cierta ayuda. Claro, algunos programadores podrían descargar el software de Internet por su cuenta, pero la mayoría de la gente no quiere perder el tiempo necesario para desarrollar la experiencia. Cuando digo "software de Red Hat", en realidad me refiero al software de fuente libre que Red Hat recogió de la red y entrelazó en un conjunto coherente de paquetes que, en teoría, deberían estar bastante libres de errores, probados y listos para usar. Red Hat está vendiendo algo de control y filtrado para el usuario promedio que no quiere perder el tiempo hurgando en la red, revisando las diferentes versiones del software y asegurándose de que funcionen bien juntas. Los programadores de Red Hat han dedicado algún tiempo a examinar el software del CD-ROM. Lo han probado y ocasionalmente lo han mejorado agregando código nuevo para que funcione mejor. Red Hat también agregó una utilidad de instalación personalizada para facilitar la vida de las personas que desean agregar Red Hat a su computadora.[^12] Podrían haber hecho que esta herramienta de instalación de paquetes fuera propietaria. Después de todo, los programadores de Red Hat escribieron la herramienta en horario de trabajo. Pero Young lo lanzó con la Licencia Pública General GNU, reconociendo que el valor político de devolver algo valía mucho más que el precio que podían cobrar por la herramienta. [12]: Er, quiero decir "agregar Linux" o "agregar GNU/Linux". "Red Hat" es ahora uno de los sinónimos de software libre. Esto es parte de una estrategia política deliberada para generar buena voluntad entre los programadores que distribuyen su software. Muchos usuarios de Linux comparan las diferentes empresas que elaboran CDROM de software libre y prueban su compromiso con los ideales del software libre. Debian, por ejemplo, es muy popular porque es un proyecto en gran parte voluntario que tiene cuidado de incluir solo software de fuente libre certificado en sus CD-ROM. Sin embargo, Debian no se maneja como un negocio y no tiene la misma actitud. Este esfuerzo voluntario y la búsqueda ilustrada de la esencia del software libre hacen que la distribución Debian sea popular entre los puristas. Distribuidores como Caldera, por otro lado, incluyen software privativo con su disco. Usted paga de $29.95 a $149.95 por un CD-ROM y obtiene un software que no es libre, como un procesador de textos, como un bono. Esta es una buena oferta si sólo va a instalar el software una vez, pero los derechos de autor del software no libre le impiden distribuir el CD-ROM a sus amigos. Caldera espera que los extras que incluye lleven a la gente hacia su disco y que elijan la versión de Linux de Caldera. Muchos de los puristas, como Richard Stallman, odian esta práctica y piensan que es una forma no muy sutil de privatizar el software libre. Si el usuario promedio no es libre de redistribuir todo el código, entonces hay algo malo en marcha. Por supuesto, Stallman o cualquiera de los otros autores de software no pueden hacer nada al respecto porque hicieron que su software fuera de libre distribución. Young está tratando de caminar por la línea entre estos dos enfoques. Red Hat está muy en el negocio de vender CD-ROM. La compañía tiene una nómina con más de un puñado de programadores que cobran salarios no voluntarios para mantener las distribuciones frescas y el código limpio. Pero ha evitado la tentación de agregar código no tan libre a sus discos. Esto le da más credibilidad con los programadores que crean el software y lo regalan. En teoría, Young no necesita congraciarse con los diversos autores de paquetes de software protegidos por GPL. Ya han regalado el código. Su poder se ha ido. En la práctica, gana mucha buena voluntad política jugando el juego según sus reglas. Varias empresas ya están fabricando PC con software Linux instalado de fábrica. Si bien podían simplemente descargar el software de la red y crear su propio paquete, varios optaron por incluir la versión de Red Hat en sus máquinas. Sam Ockman, presidente de Penguin Computing, dirige una de esas empresas. Ockman es un recién graduado de Stanford de poco más de veinte años y un gran devoto del mundo de Linux y GPL. Él dice que comenzó su empresa para demostrar que Linux podía ofrecer servidores sólidos y confiables que pudieran competir con lo mejor que Sun y Microsoft tienen para ofrecer. Ockman tiene sentimientos encontrados sobre la vida en Stanford. Si bien recuerda con cariño el "campus parecido a un campo de golf", dice que las clases eran demasiado fáciles. Se graduó con dos carreras a pesar de pasar mucho tiempo jugando con el kernel de Linux. Dice que el currículum entorpecido del departamento de ciencias de la computación lo llevó a Linux. "Toda su comunidad de CS está usando un estúpido compilador para C en Macintosh", dice. "¿Por qué no te inician en Linux? Para cuando llegues al [curso] 248, podrías piratear el kernel de Linux o su propio kernel de reemplazo. Es simplemente una tragedia que esté sentado allí escribiendo kernels virtuales en un sistema Sun que no puede reiniciar". En esencia, el departamento de informática mantenía a sus hijos encerrados en la parte poco profunda de la piscina en lugar de llevarlos al océano. Ockman encontró el océano en su propio tiempo y comenzó a escribir código protegido por GPL y a contribuir al surgimiento político del software libre. Cuando Ockman tuvo que elegir una versión de Linux para sus computadoras Penguin, eligió Red Hat. La compañía de Bob Young hizo la venta porque estaba siguiendo las reglas del juego y devolviendo el software con una GPL. Ockman dice: "De hecho, compramos la caja para cada uno. En parte porque a los clientes les gusta obtener los libros, pero también para apoyar a Red Hat. Esa es también la razón por la que elegimos Red Hat. Son los más gratuitos de todos los distribuciones". Debian, reconoce Ockman, también es muy libre y políticamente interesante, pero dice que su empresa es demasiado pequeña para soportar múltiples distribuciones. "Solo hacemos Red Hat. Esa fue una decisión muy estratégica de nuestra parte. Todas las distribuciones son más o menos iguales, pero hay ligeras diferencias en esto y aquello. Podríamos tener un grupo Debian de doce personas, pero sería sería una pesadilla para nosotros admitir todas estas versiones diferentes de Linux". Por supuesto, Penguin Computing podría haber comprado un CD-ROM de Red Hat e instalado su software en todas las máquinas que salieron. Eso les habría permitido reducir sus costos en alrededor de $50. La GPL permite que cualquier persona instale el software con la frecuencia que desee. Pero esto no sería un ahorro puro porque Ockman también está descargando parte de su propio trabajo cuando incluye un paquete de Red Hat con sus computadoras. Agrega: "Técnicamente, la caja que incluí permite a los clientes llamar a Red Hat, pero nadie lo hace nunca, ni esperamos ni queremos que llamen a nadie más que a nosotros". En esencia, su empresa está agregando algo de soporte adicional con la caja de Red Hat. El soporte es un complemento importante que Young está vendiendo, pero se dio cuenta hace mucho tiempo de que había mucho más a la venta. Red Hat estaba vendiendo una imagen, el sentido de pertenencia y la esencia indeterminada de lo cool. Los fabricantes de refrescos se dieron cuenta de que cualquiera podía poner azúcar y agua en una botella, pero solo los mejores podían superar la naturaleza monótona de la vida empleando a los mejores artistas del país para darle a su agua azucarada la sensación de moda adecuada. Así que Young invirtió en imagen. Sus camisetas y paquetes siempre han sido algunos de los más sofisticados gráficamente del mercado. Mientras que algunas personas pedían a sus novias o vecinos que dibujaran las imágenes que cubrían sus libros y CD, Red Hat utilizó un equipo talentoso para desarrollar su empaque. Los jóvenes bromean sobre esto. Dijo que estaba en una feria comercial hablando con una pequeña empresa de software que estaba tratando de darle una de sus camisetas promocionales gratis. Él dijo: "¿Por qué no intentas regalar el código fuente y vender las camisetas?" En la LinuxExpo, Red Hat también vendía camisetas. Un elegante número que se vende al por menor por $ 19 acaba de decir "La revolución de la elección" en la fuente de máquina de escribir antigua característica de Red Hat. Otros a la venta en el sitio de la compañía suelen costar $15 o más. Me absorbieron. Cuando les pedí mi primer disco de Red Hat, compré una camiseta extra para acompañar la mezcla. La gente de tecnología de Red Hat puede estar trabajando con algún software de última generación que hace que el software sea fácil de instalar, pero el grupo de marketing estaba robando sus jugadas a Nike, Pepsi y Disney. No estaban vendiendo zapatos para correr, agua azucarada o un paseo en una montaña rusa, estaban vendiendo una experiencia. Red Hat no estaba reempaquetando el proyecto científico de algún hacker de la Red, estaba ofreciendo a la gente un boleto para una revolución. Si los viejos radicales de la década de 1960 se hubieran dado cuenta de esto, podrían haber financiado su movimiento sin pedir dinero prestado a sus padres cuadrados. Habría bastado con vender suficientes camisetas geniales y teñidas.[^13] [13]: Apple es un veterano en el juego de las camisetas y los proyectos internos crean camisetas para celebrar hitos en el desarrollo. Estas imágenes se recopilaron en un libro, que puede ser la mejor historia técnica de Apple que pueda existir. Muchos proyectos, incluidos los que fracasaron, forman parte del registro. Muchos de los otros grupos son parte del juego. El proyecto OpenBSD vendió sus camisetas muy de moda con versiones alámbricas de su pequeño logo daemon poco después del comienzo de la LinuxExpo. Continúan vendiendo más camisetas desde su sitio web. Los usuarios también pueden comprar CD-ROM de OpenBSD. Varios asistentes visten camisetas amarillas con copyleft que tienen un logotipo de copyright al revés [ cCopyleft.png ] dispuesto de modo que el lado abierto apunte hacia la izquierda. La camiseta más cara de la feria venía con un logotipo que imitaba una de las primeras imágenes de marketing de la primera película de Star Wars. La camiseta mostraba a Torvalds y Stallman en lugar de Han Solo y Luke Skywalker bajo el titular de la pancarta de "OS Wars". La camiseta costó solo $ 100, pero "vino con entrada gratuita a la próxima convención de Linux en Atlanta". Los trajes corporativos, por supuesto, se han ajustado lo mejor que han podido. La gente de IBM en la feria vestía conjuntos idénticos de color caqui con polos de buen corte y relativamente caros con logotipos de IBM. Un traje regular probablemente sobresaldría menos que el nítido y limpio intento de dividir la diferencia entre un droide de negocios informal y elegante. Por supuesto, las camisetas no se trataban solo de un empaque bonito e imágenes ingeniosas. Las camisetas también transmitían alguna información sobre las afiliaciones políticas de alguien en la comunidad y mostraban algo sobre los gustos técnicos de la persona. Claro, alguien podría usar una camiseta de OpenBSD porque les gustó el lindo logo del pequeño demonio, pero también porque querían demostrar que se preocupan por la seguridad. El proyecto OpenBSD comenzó porque algunos usuarios querían construir una versión de UNIX que fuera mucho más segura. El grupo se enorgullece de corregir errores temprano y bien. Llevar una camiseta de OpenBSD proclama una cierta alianza con el compromiso de seguridad de este equipo. Después de todo, algunas de las ganancias de las camisetas se destinaron a pagar el desarrollo del software. Usar la camiseta adecuada significaba elegir una alianza. Significaba unirse a una tribu. Young es muy consciente de que gran parte de su mercado objetivo son niños de 13 años que están flexionando sus mentes e independencia por primera vez. Las mismas imágenes de rebeldía que llevaron a James Dean al estrellato están pintadas en las camisetas. Algunos visten camisetas que proclaman PRONTO LA DOMINACIÓN TOTAL DEL MUNDO. Enfurecerse contra Microsoft es un cliché que se evita tanto como se sigue utilizando. Las camisetas son una mezcla de parodia, bravuconería, ingenio y confianza. Por supuesto, generalmente son negros. Todo el mundo viste de negro. Ockman observa esta competencia en el mercado de camisetas y ve un genio. Él dice: "Creo que Bob Young es absolutamente brillante. De repente se dio cuenta de que no hay futuro en el lanzamiento de mainframes. Dio un salto después de encontrar a estudiantes universitarios en Carolina [usando Linux]. Para él, dar ese salto es simplemente asombroso. chico Se sentó y lo descubrió. "Cada vez que lo escucho hablar", dice Ockman sobre Young, "cuenta una historia diferente sobre el ketchup. Si tomas a personas que nunca antes han comido ketchup en su vida y las alimentas ciegamente con ketchup, no les gustará el ketchup". . No les gusta". Si les das ketchup con el tiempo, comienzan a exigirlo en sus hamburguesas. "A nadie que nunca haya probado Coca-Cola le gustaría", continúa Ockman. "Estas cosas son puramente un problema de marca. Tiene que ser una marca genial para que la gente se siente y aprenda todo lo que tiene que saber". En esencia, Young miró a su alrededor y vio que un montón de niños desaliñados estaban creando un sistema operativo que era tan bueno, si no mejor, que los principales sistemas operativos que costaban grandes sumas de dinero. Este sistema operativo era, lo mejor de todo, gratuito para todos los interesados. Sin embargo, el sistema operativo tenía un problema. Los niños desaliñados nunca comercializaron su software. Los hackers profundamente inteligentes y de libre pensamiento se dieron cuenta de lo genial que era, pero el resto de la sociedad no pudo dar el salto. Los niños desaliñados no se molestaron en tratar de promocionarlo al resto de la sociedad. Eran artistas. La mayoría de las personas que observaron tal situación habrían concluido que este extraño clan de tecno-forasteros estaba condenado a habitar la periferia de la sociedad para siempre. No hubo marketing del producto porque no había dinero en el presupuesto y nunca habría dinero en el presupuesto porque el software era gratuito. Young reconoció que aún se podía comercializar el software sin poseerlo. Todavía podrías ponerte una capa de genialidad sin escribir el código tú mismo. El agua azucarada tampoco cuesta prácticamente nada. El plan de Young para marcar el sistema operativo con una apariencia de genialidad produjo más éxito de lo que nadie podría imaginar. Red Hat es por mucho el líder del mercado en proporcionar Linux a las masas, a pesar del hecho de que muchos pueden "robar" una versión de bajo costo. Por supuesto, "robar" no es la palabra correcta, porque Red Hat hizo lo mismo. "Tomar prestado" no está bien, "agarrar" es un poco casual, y "unirse a la comunión eterna con el gran continuo del software libre" es demasiado entusiasta para ser genial. En agosto de 1999, Red Hat completó una oferta pública inicial de sus acciones, el punto de referencia común para el éxito en el mundo impulsado por el efectivo de Silicon Valley. Muchos de los directores de Red Hat se hicieron ricos cuando las acciones abrieron a $14 el 11 de agosto y cerraron el día a $52. Bob Young, el CEO de Red Hat, comenzó el día con poco más de 9 millones de acciones o el 15 por ciento de la empresa. Técnicamente, no todo esto era suyo porque había repartido algunas (3.222.746 acciones, para ser exactos) a su esposa, Nancy, y había puesto algunas más (1.418.160) en varios fideicomisos para sus hijos. Aún así, este recorte suma alrededor de $ 468 millones. Marc Ewing, vicepresidente ejecutivo y director de tecnología, también terminó con una cantidad similar de dinero dividida entre fideicomisos y su propio bolsillo. Matthew Sulzik, el presidente, que se incorporó en noviembre de 1998, obtuvo un poco menos (2.736.248 acciones) en su bote, pero era relativamente nuevo. Los grandes inversores, Greylock IX Limited Partnership, Benchmark Capital Partners II e Intel, se reparten la mayor parte del resto de acciones. Ahora, ¿qué pasó con los chicos que escribieron el código? ¿Richard Stallman obtuvo algo de eso? ¿Linus Torvalds? Algunos de los principales desarrolladores, como Alan Cox y David Miller, ya trabajan para Red Hat, por lo que probablemente sacaron acciones del grupo de empleados. Sin embargo, hay miles de nombres que no están en el radar de nadie. Han escrito muchas líneas de código para nada. Red Hat trató de aliviar parte del problema asignando 800 000 acciones a "directores, funcionarios y empleados de Red Hat y a desarrolladores de software de fuente abierta y otras personas que Red Hat cree que han contribuido al éxito de la comunidad de software de fuente abierta y al crecimiento de Red Hat". Este grupo, ocasionalmente conocido como "amigos y familiares", era una forma de recompensar a los amigos. Red Hat elaboró ​​una lista de los principales contribuyentes a la distribución de código abierto y envió invitaciones. "Estimado miembro de la comunidad de código abierto", comenzaba la carta por correo electrónico que Red Hat envió a unas 1000 personas. En reconocimiento a su contribución a la comunidad de código abierto, Red Hat se complace en ofrecerle esta oportunidad personal e intransferible... Red Hat no podría haber crecido tanto sin la ayuda y el apoyo constantes de la comunidad de código abierto. , por lo tanto, hemos reservado una parte de las acciones de nuestra oferta para su distribución en línea a ciertos miembros de la comunidad de código abierto. Te invitamos a participar. Muchos programadores y desarrolladores se sintieron conmovidos por la consideración. La lista probablemente no fue lo suficientemente larga o inclusiva como para atraer a todos al círculo, pero hizo un buen trabajo al distribuir la riqueza. Sin embargo, el plan comenzó a fracasar cuando E*Trade comenzó a repartir las acciones. Todos los que llegaron a la lista completaron un formulario con su patrimonio neto, y E*Trade intentó decidir quién era un inversor sofisticado y quién no. Algunas personas que tenían poco dinero (quizás porque dedicaban demasiado tiempo a escribir software libre) fueron bloqueadas. Un colaborador, C. Scott Ananian, escribió sobre su rechazo en la revista Salon: "Yo mismo completé el cuestionario de elegibilidad. Sabía lo que estaba haciendo. Y era mi dinero, de todos modos, Dios me dio el derecho de arriesgarlo en una aventura tan temeraria como quisiera". El artículo provocó muchas críticas y murmullos de una demanda colectiva de los privados de sus derechos. Estalló una discusión en Slashdot, el sitio hardcore para nerds. Algunos defendieron E*Trade y señalaron que una IPO de Red Hat no era un candado ni una garantía de riqueza. En el pasado, demasiadas abuelas habían sido quemadas por vendedores de acciones que hablaban astutamente. E*Trade tuvo que bloquear a los pequeños para su propia protección. Las acciones pueden subir o bajar. Steve Gilliard, un "operador de medios" en el sitio web NetSlaves, escribió: "Si el grupo de amigos y familiares de Red Hat fuera juzgado según los estándares normales, no existe una agencia de corretaje en los EE. casos, se les negaría una cuenta de corretaje. Por lo general, se alienta a las personas pobres a hacer otras inversiones, como pagar Visa y Master Card". Otros lo vieron como un truco para eliminar el grupo y asegurarse de que E*Trade pudiera asignar las acciones a sus amigos. Cuanto más excluidos estuvieran los pequeños, más obtendrían los grandes por sus fondos. Al final, las quejas llegaron a algunos oídos. Más personas pudieron colarse, pero el círculo nunca fue lo suficientemente grande para todos. --------------------------------------------- 21. Nuevo Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. La mayor parte de este libro enmarca todo el movimiento del código libre como algo nuevo y novedoso. La idea de regalar código fuente gratuito es algo que parece extraño y contradictorio. Pero a pesar de todo el brillo y la emoción de que la gente seria haga un trabajo serio y luego lo regale como grandes filántropos, es bastante fácil argumentar que todo esto ya se ha hecho antes. El mundo del software está redescubriendo secretos que el resto del mundo aprendió hace mucho tiempo. Regalar cosas no es una idea radical. La gente ha sido generosa desde que, bueno, la serpiente le dio a Eva esa manzana. A las empresas les encanta regalar cosas con la esperanza de atraer clientes. Los fabricantes de toallas de papel regalan accesorios para toallas que solo aceptan papel en un tamaño patentado. Las empresas de alimentos entregan refrigeradores y congeladores a las tiendas si las tiendas acuerdan no almacenar marcas rivales en ellos. De hecho, la mayoría de las industrias hacen algo más que regalar obsequios para atraer clientes. La mayoría comparte ideas, estrategias y planes entre competidores porque la cooperación permite que todos florezcan. Las empresas de estéreo fabrican componentes que interoperan porque se adhieren al mismo estándar. Abogados, ingenieros y médicos son solo algunas de las personas que constantemente intercambian ideas y soluciones entre sí a pesar de que trabajan como competidores. Un conjunto de conocimientos amplio, central y sin dueño beneficia a todos de la misma manera que ayuda a la comunidad de software libre. La verdadera pregunta no es "¿Quiénes se creen que son estos rositas pseudocomunistas?" Es "¿Por qué la industria del software tardó tanto en darse cuenta de esto?" ¿Cómo los programadores, que supuestamente son un grupo de libertarios empedernidos e inteligentes, permitieron que un grupo de abogados los guiara por un camino que los colocó en una granja de cubículos y les impidió hablar entre ellos? Las recetas son una de las cosas más cercanas al software en el mundo material, y muchos restaurantes ahora las comparten ampliamente. Si bien los chefs alguna vez los trataron como secretos industriales, ahora con frecuencia entregan copias a revistas y periódicos como forma de publicidad. El anuncio gratuito vale más que la posibilidad de que alguien empiece a clonar la receta. Los restaurantes reconocieron que estaban vendiendo más que comida única. El ambiente, el servicio y el control de calidad suelen tener más demanda que una receta en particular. Cuando la industria del software libre tiene éxito al compartir el código fuente ahora, está aprovechando el hecho de que la mayoría de la gente no quiere usar el código fuente para establecer una rivalidad sin prisioneros. La mayoría de la gente solo quiere hacer su trabajo. El costo de compartir el código fuente es tan bajo que no se necesita mucha ganancia para que valga la pena. Una corrección de errores o una pequeña característica podría pagar por ello. 21.1 Shareware Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. La industria del software ha estado coqueteando con la forma de ganar dinero con el bajo costo de distribución de su producto. El concepto de shareware comenzó mucho antes del movimiento ideológico del software libre cuando las empresas y los desarrolladores individuales comenzaron a compartir el software como una forma barata de publicidad. Los desarrolladores sin el capital para iniciar una gran campaña de marketing han repartido versiones gratuitas de su software. La gente podía probarlo y, si satisfacía sus necesidades, podía pagarlo. Aquellos a quienes no les gustó estaban obligados por su honor a borrar su versión. Shareware sigue siendo popular hasta el día de hoy. Algunos productos han hecho una gran cantidad de dinero con este enfoque, pero la mayoría ha hecho muy poco. Algunas personas, incluidas muchas de las principales empresas, distribuyen su propia versión paralizada de su producto para que la gente pueda probarlo. Las funciones cruciales, como la capacidad de imprimir o guardar un documento en el disco, generalmente se omiten como un fuerte estímulo para comprar la versión real. Por supuesto, los productos de fuente libre no son lo mismo que el shareware porque la mayoría de los productos de shareware no vienen con el código fuente. Los programadores no tienen la capacidad o el derecho de modificarlos para hacer lo que quieran. Este siempre ha sido uno de los puntos de venta más importantes para el mercado de gama alta que sabe cómo programar. De hecho, el software libre tampoco es muy barato. Cualquiera que haya estado en la comunidad del software abierto por un tiempo se da cuenta de que termina pagando algo por el almuerzo. Ocultar algunos costos al consumidor no es nuevo, y aún no ha desaparecido en el mundo del software libre. Los costos pueden no ser muchos y pueden ser mucho mejores que en el mercado propietario, pero el software aún cuesta algo. El costo más simple es el tiempo. El software libre a menudo no está tan pulido como muchos productos comerciales. Si desea utilizar muchas de las herramientas, debe estudiar manuales y aprender a pensar como un programador. Algunos manuales son bastante agradables, pero muchos son superficiales. Esto puede cambiar a medida que el movimiento del software libre busca dominar el escritorio, pero los manuales y la ayuda no están tan pulidos como las soluciones que salen de Microsoft. Por supuesto, un devoto del software libre me dijo a modo de disculpa: "¿Has intentado usar los manuales o la ayuda de Microsoft? También apestan". Incluso cuando está pulido, el software de fuente libre requiere tiempo para usarlo. Cuantas más opciones haya disponibles, más tiempo llevará configurar el software. La fuente gratuita ofrece toneladas de opciones. La falta de pulido no suele ser un problema para los programadores y, a menudo, tampoco supone un coste adicional. Los programadores a menudo necesitan aprender un sistema antes de encontrar una manera de revisarlo y ampliarlo para que haga lo que su jefe quiere que haga. Aprender las entrañas de un paquete de software gratuito no representa un gran costo adicional porque, en su lugar, solo estarían tratando de aprender las entrañas de un producto de Microsoft. Además, el código fuente facilita el proceso. Aún así, la mayoría de los usuarios, incluidos los mejores programadores, terminan pagando a una empresa como Red Hat, Caldera o un grupo como OpenBSD para que realice parte de la investigación básica en la construcción de un sistema Linux. Todas las empresas de distribución cobran por una copia de su software y brindan algún tipo de soporte. Si bien el software es técnicamente gratuito, usted paga para obtener ayuda para que funcione. Si el código fuente gratuito está protegido por la Licencia Pública General de GNU, terminará pagando nuevamente cuando se vea obligado a incluir sus cambios con el software que envía. Empaquetar cosas, configurar un servidor, escribir documentación y responder a las preguntas de los usuarios lleva tiempo. Claro, puede ser justo, bueno y agradable devolver sus adiciones a la comunidad, pero puede ser un problema mayor para algunas empresas. Digamos que tiene que modificar una base de datos para manejar algún proceso patentado, como una forma extraña de hacer un químico o fabricar un widget extraño. Contribuir con su código fuente al dominio público puede revelar algo a un competidor. La mayoría de las empresas no tendrán este problema, pero verse obligado a redistribuir el código siempre tiene costos. Por supuesto, el costo de esto es discutible. Tivo, por ejemplo, es una empresa que fabrica un decodificador para grabar contenido de televisión en un disco duro interno. El usuario promedio solo ve una interfaz elegante y fácil de usar, pero debajo, todo el sistema se ejecuta en el sistema operativo Linux. Tivo lanzó una copia de la versión simplificada de Linux que envía en sus máquinas en su sitio web, cumpliendo con su obligación con la GPL de GNU. El único problema que he descubierto es que la página web (www.tivo.com/linux/) no es particularmente fácil de encontrar desde la página de inicio. Si no hubiera sabido que estaba allí, no lo habría encontrado. Por supuesto, las empresas que adoptan software libre también terminan pagando de una forma u otra porque necesitan contratar programadores para mantener el software en funcionamiento. Esto no es necesariamente un costo adicional porque de todos modos habrían contratado a expertos de Microsoft. Algunos argumentan que el software libre es más fácil de mantener y, por lo tanto, más barato de usar, pero estos son argumentos difíciles de resolver. En cada una de estas formas, la comunidad de software libre está regalando algo para despertar el interés y luego encuentra una manera de compensar el costo más adelante. Algunos en la comunidad de software libre venden soporte y otros consiguen trabajos. Otros devuelven sus extensiones y correcciones de errores. Un negocio en funcionamiento es una ecología de trabajo donde se reinvierte lo suficiente para pagar la próxima generación de desarrollo. El mundo del código libre no es una sola corporación virtual como la compañía telefónica o el negocio del cable, pero puede pensarse de esa manera. Por lo tanto, el software libre no es muy diferente de las tostadoras gratis en los bancos, las piruletas gratis en la barbería o las drogas gratis del vendedor de barrio. Si quiere pensar en grande, puede ser mejor ver el mundo del software libre más cerca de los grandes recursos socializados como el océano, el sistema de autopistas o la infraestructura general de servicios públicos. Estos tratan a todos por igual y proporcionan una base común para los viajes y el comercio. Por supuesto, esa es la forma más cínica en que el software libre no es diferente de muchas de las otras industrias. Hay otras formas en que la visión del código libre es solo un regreso a la forma en que solían ser las cosas antes de que la industria del software las estropeara. El problema es que una combinación de leyes de licencias, derechos de autor y patentes le ha dado a la industria del software más formas de controlar su producto que prácticamente a cualquier otra industria. El movimiento de código libre es más una reacción contra estos controles que un nuevo y valiente experimento. 21.3 Otras profesiones Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Esta comparación no tiene que limitarse a los chicos del coche en el garaje. Muchas otras profesiones comparten ideas libremente y operan sin los convenios muy restrictivos de la industria del software. El negocio legal es un gran ejemplo de un mundo donde las personas son libres de mendigar, pedir prestado y robar ideas de otros. Si alguien encuentra una escapatoria ordenada, no puede patentarla ni evitar que otros la exploten. Una vez que otros abogados se enteren, presentarán sus propias demandas para sus propios clientes. [^14] [14]: 1El sistema legal no es perfecto. Demasiados casos ahora se presentan bajo sello, y los tribunales están demasiado dispuestos a actuar como agencias privadas de disputas para las grandes corporaciones. Cuando la ley está encerrada de esta manera, no es un gran ejemplo para el mundo del software libre. Considere el mundo de la responsabilidad del tabaco. Una vez que un estado presentó la opinión legal de que las compañías tabacaleras eran responsables del costo del tratamiento de cualquier enfermedad que pudiera surgir por fumar cigarrillos, los otros estados y muchos abogados pudieron unirse. Una vez que llegaron a un acuerdo, los abogados volvieron la vista hacia las compañías de armas. Para cuando lea esto, es probable que se hayan pasado a los fabricantes de vehículos de reparto de grasa en la industria de la comida rápida y los grupos de inducción del estrés, también conocidos como su empleador. La industria de la reducción del ejercicio, compuesta por un consorcio megalómano de cine astas, productores de televisión y, sí, escritores de libros, debe estar en la lista de alguien.[^15] [15]: El autor recomienda que lea esto en el Stairmaster o en una bicicleta estacionaria, pero solo después de consultar con un médico registrado y consultar con un especialista en ejercicio con licencia que esté completamente familiarizado con su historial médico. Estos especialistas médicos podrán ajustar su entrenamiento para proporcionarle los beneficios óptimos de acondicionamiento físico para que pueda vivir lo suficiente como para contraer la enfermedad de Alzheimer. La gente de código libre es igual de libre para compartir ideas. Muchas de las distribuciones rivales de Linux y BSD a menudo toman prestado código entre sí. Mientras compiten por los corazones y las mentes de los compradores, las reglas de fuente libre los obligan a compartir el código. Si alguien escribe un controlador de dispositivo para una plataforma, se modifica rápidamente para otra. El mundo del software propietario se mueve lentamente en comparación. Mantienen sus ideas en secreto y la gente pasa miles de años de abogado en proyectos simplemente manteniendo las diversas licencias en orden. El código se comparte, pero solo después de que los abogados examinen los contratos. La industria legal también es un buen ejemplo de cómo el libre intercambio de ideas, técnicas y estrategias no perjudica los ingresos de los profesionales. De hecho, los abogados se las han arreglado para ganarse una buena porción de los ingresos de la nación. La mayoría no son tan ricos como los pocos afortunados que derrotaron a las compañías tabacaleras, pero les va bien. ---------------------------------------- 22. Naciones Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. Microsoft es una empresa estadounidense. Bill Gates vive en el estado de Washington y también lo hacen la mayoría de los programadores bajo su dominio. El software que escriben se usa en todo el mundo en países grandes y pequeños, y el dinero que la gente paga por el software regresa a la zona de Seattle, donde se compran casas enormes, alimentos de diseño y mucho consumo serio y muy competitivo. A lo largo de los años, este tipo de imperialismo económico ha construido las grandes ciudades de Roma, Londres, Tokio, Barcelona y muchas otras ciudades menores. La historia es solo una larga serie de épocas en las que una empresa presenta un mecanismo inteligente para trasladar la riqueza del mundo a sus ciudades. Gran Bretaña dependió del opio por un tiempo. Roma, podría decirse, vendió un sistema legal. España traficaba con oro puro y plata. Microsoft está vendiendo información estructurada en uno de los esquemas más eficientes hasta el momento. Por supuesto, estos períodos de acumulación de riqueza invariablemente llegan a un final abrupto cuando algún ejército, que invariablemente se describe como "desarrapado", aparece para saquear y saquear. Las hordas mongolas, los visigodos y los vikingos son solo algunos de los grupos delgados y livianos que aparecieron en el horizonte y derrotaron al ejército permanente de la sociedad gorda y complaciente. Este fue el ciclo de auge y ruina que construyó y destruyó imperio tras dinastía tras gran sociedad. Tal vez sea solo una coincidencia que Linus Torvalds tenga sangre vikinga en él. Aunque creció en Finlandia, proviene de la minoría de la población para quienes el sueco es la lengua materna. La famosa neutralidad durante la Segunda Guerra Mundial, los estados de bienestar pesados, el Premio Nobel de la Paz y las bahías llenas de submarinos rusos ocultos dan la impresión de que el estilo vikingo es solo una cosa del pasado, pero tal vez algunos de los viejos hack and sack. todavía queda en las líneas de sangre. El movimiento Linux no se trata realmente de naciones y no se trata realmente de guerras en el sentido antiguo. Se trata de nerds que crean software y dejan que otros nerds vean lo genial que es su código. Se trata de potenciar el mundo de los programadores y eliminar los trajes corporativos. Se trata de pasar toda la noche programando en un maravilloso y magnífico software con columnatas enormes, plazas interminables, grandes campanas de bronce y enormes silbatos de vapor sin preguntarle a un jefe: "Madre, ¿puedo?" Es muy individualista y pacífico. Esa conmovedora visión romántica puede estar moviendo a los muchachos en las trincheras, pero los efectos secundarios comienzan a sentirse en el mundo de la política global. Cada vez que se instala Linux, FreeBSD u OpenBSD, muchos dólares no van a parar a Seattle. Hay un poco menos disponible para que la multitud de Microsoft gaste en megamansiones, SUV e impuestos locales. La biblioteca local, la policía local y las escuelas locales tendrán un poco menos de riqueza local para gravar. En esencia, los chicos de Linux están saqueando Seattle sin levantarse de sus sillas ni sudar. No verás esta batalla contada de nuevo en esos canales de cable que trafican con documentales de guerra, pero se está desarrollando mientras hablamos. Las repercusiones son más profundas. Microsoft no es solo una empresa de Seattle. Microsoft es una empresa estadounidense y todo lo que es bueno para Microsoft suele ser bueno, al menos de alguna forma, para Estados Unidos. Puede haber algunas disputas fraternales entre Microsoft y Silicon Valley, pero a Estados Unidos le está yendo bastante bien. El auge de la información está poniendo a trabajar a millones y recaudando billones en impuestos. La revolución del software libre socava este gran esquema de dos formas muy insidiosas. La primera es sutil. Nadie tiene oficialmente mucho control sobre un producto de software libre, y eso significa que ningún país puede reclamarlo como propio. Si Bill Gates dice que la versión japonesa de Windows requerirá un mouse de tres botones, entonces Japón tendrá que adaptarse. Pero Torvalds, Stallman y el resto no pueden hacer nada por nadie. La gente puede simplemente reprogramar su ratón. Si ser jefe significa hacer saltar a la gente, entonces nadie en el mundo del software libre es jefe de nada. El código fuente gratuito no está del lado de nadie. Es más neutral de lo que fue Suiza en la Segunda Guerra Mundial. Estados Unidos solo puede consolarse con el hecho de que muchas de las grandes mentes libres eligen vivir en sus fronteras. El segundo efecto es más incendiario. El software libre no paga impuestos. En los últimos siglos, los gobiernos de todo el mundo han pasado sus días elaborando esquemas para gravar cada transacción que puedan encontrar. Primero, solo había aranceles sobre los bienes que cruzan las fronteras, luego las negritas fueron tras los ingresos, y ahora el impuesto sobre las ventas y el IVA son el logro supremo. En el camino, la computadora con su habilidad desinteresada para contar hizo esto posible. Pero, ¿cómo gravar algo que es gratis? ¿Cómo sacas una tajada de algo que no cuesta nada? Estos son dos efectos insidiosos. El trabajo principal de los gobiernos es gravar a las personas. Ocasionalmente, un gobierno codiciará los ingresos fiscales de otro y estallará una guerra que obligará a la gente a elegir bando. Las licencias GPL y BSD destruyen este mecanismo fiscal, y nadie sabe lo que esto traerá. Uno de los mejores lugares para ver esta desestabilización es en los esfuerzos del gobierno de los Estados Unidos para regular el flujo de software de cifrado en todo el mundo. Las versiones de código abierto de la tecnología de cifrado se filtran por las grietas de un mecanismo cuidadosamente desarrollado para restringir el flujo del software. El gobierno de EE. UU. ha tratado de controlar la tecnología detrás de los códigos y cifrados desde la Segunda Guerra Mundial. Algunos argumentan que Estados Unidos ganó la Segunda Guerra Mundial y muchas de las guerras posteriores mediante un uso juicioso de las escuchas. Los descifradores en Inglaterra y Polonia descifraron el cifrado alemán Enigma, dando a los Aliados una pista valiosa sobre los planes alemanes. Los Aliados también hicieron agujeros en el sistema de código japonés y lo usaron para ganar innumerables batallas. Nadie ha escrito una historia completa de cómo el descifrado de códigos cambió el curso de los conflictos en Vietnam, Corea o e l Medio Oriente, pero las historias seguramente serán convincentes. En los últimos años, el trabajo de escuchar a escondidas las conversaciones en todo el mundo ha recaído en la Agencia de Seguridad Nacional, que se resiste a perder el terreno elevado que le dio a Estados Unidos tantas victorias en el pasado. El software criptográfico de consumo barato amenazaba la capacidad de la agencia para aspirar fragmentos de inteligencia en todo el mundo, y había que hacer algo. Si se incluyera un buen software de codificación en cada copia de Eudora y Microsoft Word, muchos documentos serían prácticamente ilegibles. Estados Unidos luchó contra la amenaza regulando la exportación de todo el código fuente de cifrado. Las leyes permitieron que el país regulara la exportación de municiones, y el software de codificación se incluyó en esa categoría. Estas regulaciones han causado una cantidad interminable de dolor en Silicon Valley. Las empresas de software no quieren que nadie les diga qué escribir. Limpiar una pieza de software con un burócrata en Washington, D.C., es un verdadero dolor de cabeza. Ya es bastante difícil aclararlo con tu jefe. La mayoría de las veces, el burócrata no aprobará un software de encriptación decente, y eso significa que la empresa estadounidense tiene una decisión difícil: puede no exportar su producto o construir uno de calidad inferior. Hay ramas del gobierno de los Estados Unidos a las que les gustaría ir más allá. La Oficina Federal de Investigaciones sigue preocupada de que los delincuentes utilicen el software de codificación para frustrar las investigaciones. El hecho de que la gente promedio también pueda usar el software de encriptación para proteger su dinero y su privacidad ha presentado un desafío difícil para los analistas de políticas del FBI. De vez en cuando, el FBI plantea el espectro de simplemente prohibir el software de encriptación por completo. La industria del software ha presionado durante mucho tiempo para levantar estas regulaciones, pero han tenido un éxito limitado. Han señalado que gran parte del software extranjero es tan bueno, si no mejor, que el software de cifrado estadounidense. Han gritado que estaban perdiendo ventas frente a competidores extranjeros de lugares como Alemania, Australia y Canadá, competidores que podían importar su software a los EE. UU. y competir contra empresas estadounidenses. Ninguno de estos argumentos llegó muy lejos porque los intereses de la comunidad de inteligencia estadounidense siempre ganaban cuando el presidente tenía que tomar una decisión. El mundo del código fuente gratuito se metió en este debate cuando un activista por la paz llamado Phil Zimmerman se sentó un día y escribió un programa que llamó Pretty Good Privacy, o simplemente PGP. El paquete de Zimmerman era sólido, bastante fácil de usar y gratuito. Para empeorar las cosas para el gobierno, Zimmerman regaló todo el código fuente y ni siquiera usó una licencia BSD o GPL. Simplemente estaba ahí afuera para que todo el mundo lo viera. El código fuente gratuito tuvo varios efectos. En primer lugar, facilitó que todos aprendieran a crear sistemas de encriptación y agregar las funciones a su propio software. En algún lugar probablemente haya varios programadores a los que los traficantes de drogas les paguen para que usen el código fuente de PGP para codificar sus datos. Al menos una persona que comerciaba con pornografía infantil fue atrapada usando PGP. Por supuesto, muchas personas legítimas lo aceptaron. Network Solutions, la rama de SAIC, la potencia tecnológica, utiliza firmas digitales generadas por PGP para proteger la integridad del servidor raíz de Internet. Muchas empresas utilizan PGP para proteger su correo electrónico y documentos de propiedad. Los bancos continúan explorando el uso de herramientas como PGP para ejecutar redes de transacciones. Los padres usan PGP para proteger el correo electrónico de sus hijos de los acosadores. El código fuente gratuito también abrió la puerta al escrutinio. Los usuarios, programadores y otros criptógrafos desarmaron el código PGP y buscaron errores y fallas. Después de varios años de indagar, todo el mundo decidió que el software era seguro y protegido. Este tipo de seguridad es importante en criptografía. Paul Kocher, un experto en criptografía que dirige Cryptography Research en San Francisco, explica que el software libre es una parte esencial del desarrollo de la criptografía. -sistemas", dice. "Necesitamos que todos revisen el diseño y el código para buscar debilidades". Hoy en día, los productos de seguridad que vienen con código fuente abierto son los más confiables de la industria. Las empresas privadas como RSA Data Security o Entrust pueden presumir de la calidad de sus científicos internos o de la cantidad de contratistas externos que han auditado el código, pero nada se compara con dejar que todos revisen el código. Sin embargo, cuando Zimmerman lanzó PGP, sabía que era un acto explícitamente político diseñado para crear el tipo de velo de privacidad que preocupaba a los espías. Sin embargo, enmarcó su decisión en términos nítidos que implícitamente le daban a cada persona el derecho de controlar sus pensamientos y palabras. "Es personal. Es privado. Y no es asunto de nadie más que tuyo", escribió en la introducción del manual que acompaña al software. "Puede estar planeando una campaña política, discutiendo sus impuestos o teniendo una aventura ilícita. O puede estar haciendo algo que cree que no debería ser ilegal, pero lo es. Sea lo que sea, no quiere que su correo electrónico privado (correo electrónico) o documentos confidenciales leídos por cualquier otra persona. No hay nada de malo en afirmar su privacidad. La privacidad es tan sencilla como la Constitución". Inicialmente, Zimmerman distribuyó PGP bajo la GPL, pero dio marcha atrás cuando descubrió que la GPL no le daba mucho control sobre las mejoras. De hecho, proliferaron y fue difícil hacer un seguimiento de quién los creó. Hoy, el código fuente viene con una licencia que es muy similar a la licencia BSD y permite que las personas circulen el código fuente tanto como quieran. "No impongo restricciones a la modificación del código fuente para su propio uso", escribe en la documentación adjunta, y luego se sorprende a sí mismo. "Sin embargo, no distribuya una versión modificada de PGP con el nombre 'PGP' sin primero obtener permiso de mí. Respete esta restricción. La reputación de integridad criptográfica de PGP depende de mantener un estricto control de calidad en los algoritmos y protocolos criptográficos de PGP". Sin embargo, la actitud de laissez-faire de Zimmerman no significa que el software esté disponible sin restricciones. Un holding llamado Public Key Partners controlaba varias patentes fundamentales, incluidas las creadas por Ron Rivest, Adi Shamir y Len Adleman. El PGP de Zimmerman usó este algoritmo y, técnicamente, cualquiera que usara el software estaba infringiendo la patente. Si bien "infringir una patente" tiene cierta seriedad legal, sus efectos reales son difíciles de cuantificar. La ley otorga a los titulares de la patente el derecho de impedir que alguien haga lo que se especifica en la patente, pero solo les permite utilizar una demanda para cobrar daños y perjuicios. De hecho, los titulares de patentes pueden cobrar daños triples si pueden probar que los infractores sabían sobre la patente. Estas demandas pueden ser bastante complicadas para una gran empresa como Microsoft, porque Microsoft está vendiendo un producto y obteniendo ganancias. Encontrar un número para multiplicar por tres es fácil de hacer. Pero los efectos de las demandas en activistas por la paz barbudos y relativamente pobres que no ganan dinero son más difíciles de juzgar. ¿Cuánto es tres por cero? Las demandas tienen aún menos sentido contra un tipo que usa PGP en su sótano. Aún así, la amenaza de una demanda fue suficiente garrote para preocupar a Zimmerman. Los costos, sin embargo, ponen un límite a lo que PKP podría exigir. Al final, las dos partes acordaron que PGP podría distribuirse para uso no comercial si se basaba en un conjunto de herramientas conocido como RSAREF creado por la empresa hermana de PKP, RSA Data Security. Aparentemente, esto alentaría a las personas a usar RSAREF en sus productos comerciales y actuaría como publicidad gratuita para el conjunto de herramientas. La demanda de patentes, sin embargo, fue realmente una amenaza menor para Zimmerman. En 1994, el gobierno de EE. UU. comenzó a investigar si Zimmerman había exportado de alguna manera software de encriptación poniéndolo a disposición en Internet para su descarga. Si bien Zimmerman denunció explícitamente la violación de las leyes y se esforzó por mantener el software dentro del país, se filtró una copia. Algunos sugieren que fue a través de una publicación en la red que, sin darse cuenta, se envió a todo el mundo. ¿Fue Zimmerman el responsable? Una rama de la Aduana de EE. UU. inició una investigación criminal en el Distrito Norte de California para averiguarlo. Por supuesto, determinar cómo salió el código fuente del país fue un ejercicio casi imposible. A menos que Zimmerman confesara o de alguna manera guardara alguna evidencia incriminatoria, los fiscales enfrentaron un trabajo difícil al presentarlo como un infractor de la ley. El software estaba disponible de forma gratuita para cualquier persona dentro del país, y eso significaba que todos tenían al menos la oportunidad de infringir la ley. No había registros de compra ni registros de registro. Nadie sabía quién tenía PGP en su disco. Tal vez alguien lo llevó al otro lado de la frontera después de olvidar que el código fuente estaba en un disco duro. Tal vez un extranjero entró deliberadamente a los EE. UU. y lo llevó a cabo. ¿Quién sabe? Zimmerman dice que cruzó la frontera "como semillas de diente de león en el viento". Para empeorar las cosas para las fuerzas del gobierno de los EE. UU. que querían restringir PGP, la patente en poder de RSA no se presentó en el extranjero debido a diferentes regulaciones. Los extranjeros podían usar el software sin cuidado, y muchos lo hicieron. Este fue el tipo de pesadilla que preocupó a las partes de la rama de recopilación de inteligencia de los EE. UU. que dependían del espionaje al por mayor. Finalmente, la investigación criminal quedó en nada. No se anunciaron acusaciones. No comenzaron los juicios. Poco después de que terminara la investigación, Zimmerman ayudó a formar una empresa para crear versiones comerciales de PGP. Si bien las versiones gratuitas continúan estando disponibles en la actualidad y son de uso generalizado entre las personas, las empresas a menudo recurren a PGP para productos comerciales que vienen con una licencia de PKP. Cuando la patente de RSA expire en septiembre de 2000, la gente podrá volver a utilizar PGP.[^16] [16]: El proyecto GNU ya ha solucionado muchos de estos impedimentos. Su paquete Privacy Guard (GNU PG) se publica bajo la licencia GNU. Las experiencias de Zimmerman muestran cómo el código fuente gratuito se convirtió en una verdadera espina en el costado del gobierno de los EE. UU. Las empresas pueden comprarse o al menos apoyarse en ellas. La mercancía debe fluir a través de las tiendas y las tiendas deben obedecer la ley. La burocracia puede arruinarlo todo. Pero el software libre que flota como semillas de diente de león no se puede controlar. Las personas pueden dárselo unos a otros y fluye como un discurso. De repente, no es un producto lo que está siendo regulado, sino el libre intercambio de ideas entre personas, ideas que casualmente se cristalizan como un programa de computadora. Por supuesto, una burocracia nunca ha encontrado algo que no pueda regular, o al menos algo que no pueda tratar de regular. La experiencia de Zimmerman puede haberles demostrado a algunos que los gobiernos son simplemente obstáculos en la infobahn del futuro, pero otros lo vieron como un desafío. Hasta finales de 1999, el gobierno de los EE. UU. trató de endurecer las restricciones sobre las versiones de código abierto de la tecnología de encriptación que flotan en todo el mundo. El problema fue que muchos países alrededor del mundo explícitamente eximen al software de código abierto de las restricciones, y Estados Unidos ha presionado para cerrar estas lagunas. El mejor lugar para comenzar esta historia puede ser en las trincheras donde los administradores de sistemas del gobierno de los EE. UU. intentan mantener alejados a los hackers. A Theo de Raadt, el líder del equipo de OpenBSD, le gusta presumir que el gobierno de EE. UU. usa OpenBSD en su red interna segura. Los diseñadores del sistema probablemente tomaron esa decisión porque OpenBSD ha sido auditado exhaustivamente en busca de fallas y errores de seguridad tanto por parte del equipo de OpenBSD como del mundo en general. Quieren el mejor código, e incluso es gratis. "Están ejecutando Network Flight Recorder", dice de Raadt. "Es un paquete súper rastreador y un sistema de detección de intrusos. Pueden decirle si ocurre tráfico malo en su pequeña red privada que el firewall debería haber detenido. Tienen OpenBSD ejecutando NFR en cada red. Ejecutan un IPSEC vpn de vuelta a una red principal centro de información de red donde buscan y hacen análisis de tráfico". Es decir, los departamentos vigilan a los piratas maliciosos colocando cajas de OpenBSD en puntos sensatos para escanear el tráfico y buscar información incriminatoria. Estas cajas, por supuesto, deben permanecer seguras. Si están comprometidos, no valen nada. Pasar a algo como OpenBSD, que al menos ha sido auditado, tiene sentido. "Atrapan a muchos administradores de sistemas cometiendo errores. Es un resultado muy proactivo. Pueden ver que un administrador de sistemas ha configurado mal un firewall", dice. Normalmente, esto sería solo una simple historia feliz sobre el gobierno obteniendo un gran valor de un sistema operativo de código abierto. No pagaron nada por él y obtuvieron los resultados de una revisión abierta y generalizada en busca de agujeros de seguridad. De Raadt vive en Canadá, no en los Estados Unidos, y desarrolla OpenBSD allí porque las leyes sobre la exportación de software de encriptación son mucho más indulgentes. Durante un tiempo, Canadá no trató de controlar ningún software de mercado masivo. Recientemente, agregó el requisito de que el software retractilado reciba una licencia, pero el país parece estar dispuesto a otorgar licencias con bastante liberalidad. El software que cae en el dominio público no está restringido en absoluto. Si bien OpenBSD no es de dominio público, se ajusta a esa definición según lo establecido por las reglas. El software se distribuye sin restricciones ni cargos. A fines de 1999, los altos funcionarios se dieron cuenta de que la política de detener las criptas estaba generando demasiados momentos irónicos. Este es solo otro ejemplo de cómo el software de fuente libre lanza el sistema regulatorio de los instintos tradicionales por un bucle. Las empresas venden productos y los productos están regulados. La información de dominio público, por otro lado, es expresión y la expresión está protegida, al menos por la Constitución de los Estados Unidos. Confiar en Canadá para la seguridad de la red de Internet fue demasiado. En enero de 2000, el gobierno de Estados Unidos capituló. Después de la incesante presión de la industria informática, el gobierno reconoció que el software de encriptación de alta calidad como OpenBSD era común en todo el mundo. También reconoció que la calidad era tan buena que muchos dentro de los Estados Unidos la importaron. El gobierno aflojó las restricciones y prácticamente las eliminó para el software de código abierto. Si bien muchas personas aún no están satisfechas con las nuevas regulaciones, el software de cifrado de código abierto ahora puede salir de los Estados Unidos. Los distribuidores solo necesitan notificar a los EE. UU. gobierno acerca de dónde está disponible el software. El software comercial de cifrado patentado no tuvo tanta suerte. Las regulaciones ahora son mucho más fáciles para las corporaciones, pero aún requieren una revisión sustancial antes de que se otorgue una licencia de exportación. La diferencia de trato probablemente no fue el resultado de ningún amor secreto por Linux u OpenBSD que acechaba en los corazones de los reguladores de la Oficina de Asuntos de Exportación del Departamento de Comercio. Los reguladores probablemente tengan más miedo de perder una demanda presentada por Daniel Bernstein. En la última decisión emitida en mayo de 1999, dos de tres jueces en un panel de apelaciones concluyeron que las regulaciones de encriptación del gobierno de EE. UU. violaron los derechos de libertad de expresión de Bernstein. El gobierno argumentó que el código fuente es un dispositivo, no un discurso. El caso se encuentra actualmente en apelación. Las nuevas regulaciones parecen estar destinadas a abordar específicamente los problemas que encontró el tribunal con las regulaciones actuales. El software de encriptación es solo el comienzo de las tribulaciones mientras el gobierno trata de decidir qué hacer con el libre intercambio de código fuente en la red. Los impuestos pueden ser los siguientes. Mientras que la gente bromea diciendo que estaría encantada de pagar un impuesto sobre las ventas del 10 por ciento sobre los cero dólares que han gastado en el software GNU, se están perdiendo algunos de los problemas filosóficos más profundos detrás de los impuestos. Muchos estados no gravan oficialmente la venta de un objeto; exigen el dinero para el uso de la misma. Eso significa que si compras un estéreo en Europa, aún se supone que debes pagar un "impuesto de uso" cuando lo enciendes en un estado. Los estados tratan de usar esto como un garrote para exigir ingresos por impuestos sobre las ventas de las tiendas de catálogo y pedidos por correo de otros estados, pero no han llegado muy lejos. Pero esto no les ha impedido intentarlo. ¿Qué impuesto podría adeudarse por una pieza de software libre? Bueno, el estado podría simplemente mirar el software, asignarle un valor y enviarle una factura al usuario. Muchos estados hacen precisamente eso con los automóviles. Es posible que tenga un cacharro oxidado, pero usan el valor del libro azul de un automóvil para determinar el impuesto para el año y cada año envían una nueva factura. Este concepto resultó ser tan molesto para los ciudadanos de Virginia que Jim Gilmore ganó las elecciones para gobernador con el mandato de revocarlo. Pero solo porque lo eliminó no significa que otros dejarán el problema solo. Si los gobiernos alguna vez deciden tratar de gravar el software libre, la comunidad podría rechazar la solicitud argumentando que el impuesto se "paga" cuando el gobierno también usa el software libre. Si 7 de cada 100 servidores Apache están ubicados en oficinas gubernamentales, entonces el gobierno debe recibir el 7 por ciento devuelto como impuesto. Uno de los problemas más difíciles para las personas es diferenciar entre riqueza y dinero. El movimiento del software libre crea riqueza sin mover dinero. El fácil flujo de información digital lo hace posible. Algunas personas pueden convertir esto en dinero vendiendo apoyo o ayudando a otros, pero la mayoría de las veces la riqueza se encuentra felizmente en el dominio público. Hoy, el auge de Internet crea una gran fuente de conocimiento y riqueza intelectual para toda la sociedad. Algunas personas han logrado convertir esto en dinero creando sitios web o herramientas y comercializándolos con éxito, pero la gran cantidad de riqueza intelectual permanece abierta y accesible para todos. ¿A quién pertenece esto? ¿Quién puede gravar esto? ¿Quién lo controla? Los países más progresistas resistirán el impulso de gravarlo, pero ¿cuántos realmente podrán seguir resistiéndose? ----------------------------------------- 23. Riqueza Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. El escritor, P. J. O'Rourke, señaló una vez que la riqueza es un concepto particularmente confuso de entender. No tenía nada que ver con nacer en el lugar correcto. África está llena de diamantes, oro, platino, petróleo y miles de otros recursos valiosos, mientras que Japón apenas tiene nada bajo tierra excepto túneles subterráneos y ántrax de cultos extraños. Sin embargo, Japón sigue siendo mucho más rico incluso después del largo desvanecimiento de su economía posterior a la burbuja. O'Rourke también señaló que la riqueza no tiene nada que ver con el cerebro en bruto. Los rusos juegan al ajedrez como deporte nacional, mientras que Brentwood está lleno de bombillas tenues como las personas que vimos durante el juicio por asesinato de O. J. Simpson. Sin embargo, la pobreza es endémica en Rusia, mientras que Brentwood florece. Claro, la gente espera en la fila para comer en Brentwood como lo hicieron en la Rusia soviética, pero esto es solo para conseguir una mesa en el nuevo restaurante más popular. La riqueza es una mercancía extraña, y comprenderla mantiene ocupados a los economistas. Los gobiernos necesitan justificar su existencia de alguna manera, y últimamente la gente en los Estados Unidos usa su percepción de la "economía" como una medida de qué tan bien lo está haciendo el gobierno. Pero muchos de sus intentos de usar números para medir la riqueza y la prosperidad están condenados al fracaso. Un año, los economistas parecen estar luchando frenéticamente contra la deflación, luego se dan la vuelta y parlotean una y otra vez sobre la inflación. Renunciaron a tratar de medir la oferta monetaria para seguir la inflación y, a veces, parecían estar volando la economía por el asiento de sus pantalones. Por supuesto, en realidad no están a cargo. Un minuto no se puede tener crecimiento sin inflación. Al minuto siguiente puedes. Todo es un poco como los días antiguos de la vida tribal cuando el sumo sacerdote era responsable de imaginar las razones por las que el volcán entró en eru pción o no. Algunos días, la oferta de dinero nos sonríe, y otros días, ella está muy, muy enojada. La riqueza en el mundo del software libre es un concepto aún más resbaladizo. Ni siquiera hay ninguna moneda para usar para llevar la cuenta. Digamos que queríamos saber o al menos adivinar si el mundo del código libre era rico. Eso no es demasiado difícil. La mayoría de los chicos que piratean el código solo quieren beber bebidas con cafeína, jugar juegos geniales y escribir más código. El flujo interminable de cajas de computadoras cada vez más rápidas hace que esto sea lo más parecido a un mundo perfecto que podría haber. Para mejorar las cosas, siguen apareciendo nuevas camisetas con eslóganes ingeniosos. Es una utopía nerd. Es Shangri-La para la gente a la que le gustan las computadoras. Por supuesto, decidir si alguien es rico o no no es realmente una cuestión económica interesante. Se trata más de autoestima y felicidad. Alguien que tiene necesidades simples puede sentirse bastante rico en una choza. Los niños mimados nunca serán felices por grande que sea su palacio. Hay mucha gente contenta en el mundo del software libre, pero también hay algunos que no estarán contentos hasta que tengan el código fuente de un sistema operativo enorme, maravilloso, libre de errores y con la mayor cantidad de funciones del planeta. Quieren la dominación total del mundo. Una pregunta más intrigante es si el mundo de la fuente libre es más rico que el mundo de la fuente propietaria. Esto comienza a complicarse porque compara manzanas con naranjas y trata de hacer comparaciones complicadas. Bill Gates es increíblemente rico en muchos sentidos de la palabra. Tiene miles de millones de dólares, una casa enorme, docenas de autos, sirvientes, juguetes y quién sabe qué más. Incluso sus empleados tienen sus propios jets privados. Todas las trampas de la riqueza están ahí. Linus Torvalds, por otro lado, dice que está bastante contento con unos 100.000 dólares al año, aunque es probable que varias OPI lo dejen bien. Microsoft tiene miles de programadores a los que se les paga bien para escribir millones de líneas de código al año. A la mayoría de los programadores de código abierto no se les paga mucho por crear lo que hacen. Si el dinero fuera una buena medida, entonces el mundo de las fuentes propietarias ganaría sin duda alguna. Pero el dinero es la respuesta solo si quieres montones de papeles con fotos de estadounidenses famosos. Varios países de América Latina generan enormes cantidades de dinero a partir de las drogas, el petróleo y otros recursos naturales, pero los países siguen siendo bastante pobres. A los líderes que terminan con la mayor parte del dinero les puede gustar la enorme disparidad, pero tiene limitaciones muy claras. Cuando llega el momento de la universidad o la atención médica, los muy ricos comienzan a volar a los Estados Unidos. Johns Hopkins, un hospital en Baltimore cerca de donde vivo, brinda un maravilloso servicio médico a los pobres que viven en el vecindario circundante. También tiene un ala especial con lujosas suites para personas ricas que llegan en avión para recibir tratamiento médico. Muchos son potentados y altos funcionarios gubernamentales de países pobres de todo el mundo. Las personas en los Estados Unidos pueden disfrutar de las sinergias de vivir cerca de otros ciudadanos bien educados, creativos, empoderados y comprometidos. Las personas en las sociedades pobres no pueden asumir que alguien más diseñará grandes carreteras, construirá aerolíneas, creará cafeterías geniales, inventará nuevas drogas o hará cualquier cosa excepto sobrevivir con las pocas sobras que se deslizan por las grietas hacia los grandes pobres sin lavar. Los ultraricos en América Latina pueden pensar que están ganando mucho al quedarse con todo el pastel, hasta que se enferman. Luego dan la vuelta y vuelan a hospitales como Johns Hopkins, un lugar donde los pobres de Baltimore también disfrutan de un trato bastante similar. La riqueza es algo muy diferente al dinero en efectivo. La mayoría de las personas en el mundo del código libre pueden no tener grandes cuentas bancarias. De todos modos, esos son solo números en una computadora, y todos los que pueden programar saben lo fácil que es llenar una computadora con números. Pero el mundo de la fuente libre tiene un buen software y el código fuente que lo acompaña. ¿Cuántas veces al día debe mirar Bill Gates la pantalla azul de la muerte que aparece en el monitor de una computadora con Windows cuando falla el software de Windows? ¿Cuántas veces ve Torvalds cómo falla Linux? ¿Quién está mejor? ¿Quién es más rico? Se podría hacer la pregunta: "¿Es su software mejor que hace cuatro años?" Es decir, ¿su software hace un mejor trabajo al buscar el correo, mover los datos, procesar las palabras o distribuir las hojas? ¿Es más intuitivo, más potente, más estable, más rico en funciones, más interesante, más expresivo o simplemente mejor? Las respuestas a estas preguntas no se pueden medir como el dinero. No hay un cociente numérico que pueda resolver ninguna de estas preguntas. Siempre habrá algunas personas que estén contentas con su procesador de texto DOS de primera edición y no vean la necesidad de reinventar la rueda. Hay otros que todavía están descontentos porque su máquina de escritorio no puede leer su mente. Para los devotos discípulos del mantra del software abierto, el software del mundo libre es infinitamente mejor. Richard Stallman siente que el código GNU es mejor que el código de Microsoft simplemente porque tiene el código fuente y la libertad de hacer lo que quiera con él. La libertad es más importante para él que cualquier característica súper tonta que surja de los equipos de Microsoft. Después de todo, puede agregar cualquier función que desee si tiene acceso al código fuente básico. Vivir sin el código fuente significa esperar como un buen peón a que los buenos maestros de la gran corporación nos bendigan con una corrección de errores. No hay duda de que la gente como Stallman ama la vida con el código fuente. Una pregunta más profunda es si el reino de la fuente libre ofrece un estilo de vida más rico para el usuario promedio de computadoras. La mayoría de las personas no son programadores, y la mayoría de los programadores ni siquiera son los hackers empedernidos a los que les encanta jugar con el kernel de UNIX. Rara vez he usado el código fuente de Linux, Emacs o cualquiera de las herramientas ordenadas en la Red, y muchas veces simplemente he vuelto a compilar el código fuente sin mirarlo. ¿Esta comunidad sigue siendo una mejor oferta? Hay muchas maneras de ver la pregunta. La más sencilla es comparar características. Es difícil negar que el mundo del software libre ha hecho grandes avances en la producción de algo que es fácil de usar y bastante adaptable. Las distribuciones más actuales en el momento en que escribo esto vienen con una variedad de paquetes que brindan toda la funcionalidad de Microsoft Windows y más. Los editores son buenos, el navegador es excelente y la disponibilidad del software es maravillosa. La distribución básica de Red Hat o Caldera proporciona una interfaz de usuario muy rica que es mejor en muchos aspectos que Windows o Mac. Algunos de los productos ligeramente especializados, como los editores de software de video y los programas de música, no tienen una apariencia tan rica, pero esto seguramente cambiará con el tiempo. Es realmente un mundo muy usable. Algunos se quejan de que comparar características como esta no es justo para el mundo de Mac o Windows. El conjunto de herramientas de GNOME, señalan, no surgió de años de investigación y desarrollo. El botón de inicio y la barra de herramientas se ven iguales porque los desarrolladores de GNOME simplemente estaban copiando. El mundo GNU/Linux no creó su propio sistema operativo, simplemente clonó toda la investigación comercial dura que produjo UNIX. Siempre es más fácil ponerse al día, pero seguir adelante es difícil. Las personas que quieren mantenerse a la vanguardia deben estar en el mundo comercial. Es fácil crear una lista de productos y herramientas comerciales que no hayan sido clonados por un tipo de código abierto en el momento de escribir este artículo: transmisión de video, animación vectorial, la API completa de Java, reconocimiento de voz, programas CAD tridimensionales, síntesis de voz, etc. La lista sigue y sigue. Las innovaciones más calientes siempre vendrán de empresa s emergentes bien capitalizadas impulsadas por la zanahoria de la riqueza. Otros señalan que el mundo del software libre ha generado más innovación de la que le corresponde. La mayor parte de Internet se construyó sobre estándares no patentados desarrollados por empresas con contratos del Departamento de Defensa. Emacs de Stallman sigue siendo uno de los mejores programas del mundo. Muchos de los proyectos como Apache son el primer lugar donde se demuestran nuevas ideas. A las personas que quieren simular un proyecto les resulta más fácil extender el software libre. Estas ideas a menudo renacen como productos comerciales. Si bien es posible que los usuarios de código libre no tengan acceso a las últimas innovaciones comerciales, tienen muchas propias que emergen del mundo del software abierto. GNOME no es solo un clon de Windows, viene con miles de extensiones y mejoras interesantes que no se pueden encontrar en Redmond. El propio Stallman dice que el proyecto GNU mejoró muchas piezas de software cuando las reescribieron. Él dice: "Nos basamos en su trabajo, en la medida en que legalmente podíamos hacerlo (ya que no podíamos usar nada de su código), pero esa es la forma en que se avanza. Casi todos los programas GNU que reemplazan una pieza de Unix incluye mejoras." Otra forma de abordar la cuestión es observar el comportamiento de las personas. Algunos argumentan que empresas como Red Hat u organizaciones como Debian prueban que la gente necesita y quiere parte del apoyo del mundo comercial. No pueden darse el lujo de simplemente descargar el código y jugar con él. La mayoría de las personas no son estudiantes de secundaria cumpliendo condena por ser jóvenes. Tienen trabajos, familias y pasatiempos. Pagan porque el pago aporta continuidad, forma, estructura y orden al mundo de fuente libre. En última instancia, estos usuarios de Red Hat no son discípulos de Stallman, son ovejas comerciales que dependen tanto de Red Hat como los clientes de Windows de Microsoft. El contraargumento es que esta idea pasa por alto una diferencia filosófica crucial. Los clientes de Red Hat pueden ser esclavos como los clientes de Microsoft, pero aún tienen importantes libertades. Claro, muchos estadounidenses son esclavos asalariados de un empleador que les paga lo menos posible, pero tienen la libertad de ser esclavos asalariados de otro empleador si así lo desean. Los esclavos anticuados enfrentaban el látigo y la muerte si intentaban tomar ese camino. La mayoría de los usuarios de Linux no necesitan reescribir el código fuente, pero aún pueden beneficiarse de la libertad. Si todos tienen la libertad, entonces alguien vendrá con la capacidad de hacerlo y si el problema es lo suficientemente grande, alguien probablemente lo hará. En otras palabras, solo una persona tiene que volar el caza X-wing por la trinchera y hacer estallar la Estrella de la Muerte. Algunos señalan que el mundo del código libre está bien, si tienes el tiempo y la atención para jugar con él. El código fuente solo ayuda a aquellos que quieren dedicar tiempo a participar. Tienes que leerlo, estudiarlo y practicarlo para obtener algún valor de él. La mayoría de nosotros, sin embargo, solo queremos que el software funcione. Es como la distinción entre las personas que se relajan viendo un partido de béisbol en la televisión y las que se unen a una liga para jugar. Los espectadores son en gran parte pasivos, esperando que se les sirva la acción. Los jugadores de la liga, por otro lado, no obtienen nada a menos que practiquen, se estiren, empujen y se apresuren. Necesitan estar completamente comprometidos con el juego. A todos nos gusta una competencia ocasional, pero a menudo necesitamos un sofá suave, un paquete de seis y el control remoto. El software libre es una buena oportunidad para dar un paso al frente, pero no es un verdadero refrigerio para las masas. ¿Cuál es un mundo mejor? ¿Un Disneylandia pulido donde cada acción está escrita, o un montón de bloques de Lego esperando que les demos forma? ¿Queremos que nos entretengan o queremos interactuar? Mucha gente del software libre señalaría que el software libre no le impide instalarse en el seno de alguna corporación para una larga siesta de invierno. Empresas como Caldera y Linuxcare están dispuestas a tomarte de la mano y darte el código fuente. Muchas otras corporaciones están llegando a la misma idea. Netscape abrió el camino, y muchas compañías como Apple y Sun lo seguirán. Microsoft puede incluso hacer lo mismo cuando lea esto. El dinero no es lo mismo que la riqueza, y la naturaleza del software enfatiza algunas de las formas en que esto es cierto. Una vez que alguien dedica horas a crear software, no cuesta casi nada distribuirlo al mundo. El único costo real es el tiempo porque la potencia de la computadora y las bebidas con cafeína son muy económicas. 23.1 Riqueza y Pobreza Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. George Gilder expuso la brecha entre la riqueza y el dinero en su influyente libro Wealth and Poverty. El libro surgió en 1981, justo antes de que Ronald Reagan asumiera el cargo, y se convirtió en una de las piedras de toque filosóficas de los primeros años de la administración. En ese momento, las palabras de Gilder estaban dirigidas a un mundo donde las economías socialistas habían fracasado en gran medida pero los capitalistas nunca habían declarado la victoria. La Unión Soviética se estaba hundiendo cada vez más en la pobreza. Suecia se dirigía a algunas de las tasas de interés más altas imaginables. Sin embargo, los periódicos y las universidades de los Estados Unidos se negaron a reconocer el fracaso. Gilder quería disipar la noción de que el capitalismo y el socialismo estaban encerrados en una eterna batalla de yin/yang. En su opinión, los mercados eficientes y la asignación descentralizada de capital eran un éxito rotundo en comparación con la laboriosa burocracia que estaba es trangulando a la Unión Soviética. Aunque Gilder habló en general sobre la naturaleza de la riqueza, sus ideas son particularmente buenas para explicar por qué las cosas salieron tan bien para el mundo del software abierto. "El capitalismo comienza con dar", dice, y explica que las sociedades florecen cuando las personas son libres de poner su dinero donde esperan que les vaya mejor. Las inversiones se esparcen como semillas y solo algunas encuentran un buen lugar para crecer. Aquellos capitalistas que son una mezcla de inteligente y afortunado ganan más y luego reinvierten sus ganancias en la sociedad, repitiendo el proceso. Nadie sabe qué tendrá éxito, por lo que animar a los valientes que toman riesgos tiene sentido. El capítulo de Gilder sobre la entrega de regalos es especialmente bueno para explicar el éxito del mundo del software libre. El capitalismo, explica, no se trata de codicia. Se trata de dar a las personas con el conocimiento implícito de que devolverán el favor varias veces. Se basa en gran medida en la antropología y los escritos de académicos como Claude L vi-Strauss para explicar cómo las mejores sociedades crean capital a través de regalos que vienen con la deuda implícita de que la gente devuelve algo. La competencia entre las personas por dar cada vez mejores regalos impulsa a la sociedad a desarrollar cosas nuevas que mejoren la vida de todos. Gilder y otros han visto las raíces de la formación de capital y la creación de riqueza en esta entrega de regalos. "Las ofertas interminables de los empresarios, la inversión de capital, la creación de productos, la creación de empresas, la invención de puestos de trabajo, acumular inventarios -todo mucho antes de que se reciba alguna devolución, todo sin seguridad de que la empresa no fracasará- constituye un patrón de dar que empequeñece en extensión y generosidad esencial cualquier rito primitivo de intercambio. Dar es el impulso vital y el centro moral del capitalismo", escribe. Los socialistas que han arremetido contra las injusticias y brutalidades del capitalismo de mercado en el trabajo no estarían de acuerdo con la fuerza de su declaración, pero hay muchos buenos ejemplos. La Guerra Civil Estadounidense fue la batalla entre los estados del norte donde los trabajadores eran ocasionalmente encadenados a telares durante sus turnos y los estados del sur donde los trabajadores siempre eran esclavos. Al final, ganó la sociedad menos cruel, en parte por la fuerza de su industria y su capacidad de innovar. Las empresas que descubrieron este hecho florecieron y las que no lo hicieron finalmente fracasaron. A fines del siglo XX, la demanda de mano de obra en los Estados Unidos era tan alta que las empresas competían activamente para ofrecer un trato lujoso a sus trabajadores. El mundo del software libre, por supuesto, es un ejemplo perfecto de la naturaleza altruista del potlatch. El software se regala sin garantía de devolución. Las personas son libres de usar el software y cambiarlo de cualquier manera. La Licencia Pública GNU no es muy diferente del pegamento social que obliga a los miembros de la tribu a tener una fiesta más grande el próximo año y devolver aún más. Si alguien termina creando algo nuevo o interesante después de usar el código GPL como base, se le exige que devuelva el código a la tribu. Por supuesto, es difícil obtener mucha orientación de Gilder sobre si la licencia GPL es mejor que la licencia BSD. Constantemente enmarca la inversión como un "regalo" para tratar de restar importancia a la codicia del capitalismo. Por supuesto, cualquiera que haya pasado por una ejecución hipotecaria o una refinanciación de deuda sabe que los bancos no actúan como si hubieran regalado. Existen soluciones legales para forzar a las personas que no devuelven lo suficiente. Estaba tratando de hacer que los lectores olvidaran un poco estas tácticas y que se dieran cuenta de que después de que todos los brazos se rompen, el banco aún se queda con lo que haya producido el préstamo. No había garantías finales de que todo el dinero regresaría. Gilder suaviza esto con una analogía bien dibujada. Todo el mundo, dice, ha experimentado la sensación incómoda que surge al recibir un regalo del tamaño incorrecto, del estilo incorrecto o simplemente incorrecto. "De hecho, es el genio mismo del capitalismo que reconoce la dificultad de dar con éxito, comprende el trabajo duro y el sacrificio que implica el mandato de ayudar a los semejantes, y ofrece una forma práctica de vivir una vida de caridad efectiva", dijo. escribe No es suficiente darle un pescado a un hombre, porque enseñarle a pescar es un regalo mucho mejor. Una piscifactoría que contrata a un hombre y le da opciones sobre acciones puede estar ofreciendo la mejor forma de dar. Gilder nota que el ciclo de regalos por sí solo no es suficiente para construir una economía fuerte. Él sugiere que las pilas cada vez más grandes de cocos y grasa de ballena fueron todo lo que emergió de las interminables rondas de potlatching. Eran geniales para festejar, pero las pilas se pudrían y envejecían antes de consumirse. La sociedad exitosa reinterpretó el ciclo de los obsequios como inversión y dividendos, y la introducción del dinero hizo posible que las personas trasladaran fácilmente los rendimientos de una inversión al comienzo de otra. Esta liquidez permite que los ciclos sean cada vez más eficientes y brinda a las personas un lugar para almacenar su riqueza. Por supuesto, Gilder admite que el dinero es solo un dispositivo de almacenamiento temporal. Es solo una herramienta para traducir la riqueza de un sector de la economía en la riqueza de otro. Es solo una carretilla o un carro tirado por bueyes. Si la sociedad no valora los aportes de los capitalistas, la transferencia fracasará. Si los caminos son demasiado pedregosos o están bloqueados por demasiados cobradores de peaje, los carros no harán el viaje. A primera vista, nada de esto importa al mundo del software libre. Los autores regalan sus productos, y mientras alguien pague una cantidad mínima por el almacenamiento, el software no decaerá. La web está llena de repositorios de código fuente y fortalezas que permiten a las personas almacenar su software y permitir que otros lo descarguen a voluntad. Estos cuestan una cantidad mínima para mantenerse al día y el costo está cayendo todos los días. No hay razón para creer que el trabajo original de Stallman se perderá por la enfermedad, la pestilencia, el desgaste y la descomposición que han maldecido objetos físicos como casas, ropa y comida. Pero a pesar de la hermosa permanencia del software, todo el mundo sabe que sale mal. Los programadores no usan el término "bit rot" para divertirse. A medida que los sistemas operativos maduran y otros programas cambian, las interfaces antiguas comienzan a descomponerse lentamente. Un programa puede depender del sistema operativo para imprimir un archivo en respuesta a un comando. Luego, se acelera una nueva versión del código de impresión para agregar fuentes más elegantes y más colores. De repente, la interfaz no funciona exactamente bien. Con el tiempo, estos miles de pequeños cambios pueden arruinar el corazón de un buen programa de la misma manera que los gusanos pueden comerse el casco de un barco de madera. La buena noticia es que el software libre está bien posicionado para solucionar estos problemas. Distribuir el código fuente con el software permite que otros hagan todo lo posible para mantener el software funcionando en un entorno cambiante. John Gilmore, por ejemplo, dice que ahora adopta la GPL porque experimentos anteriores con software totalmente libre crearon versiones sin el código fuente adjunto. La mala noticia es que Gilder tiene razón sobre la formación de capital. Richard Stallman hizo un gran trabajo escribiendo Emacs y GCC, pero los elogios no fueron tan fáciles de gastar como el dinero en efectivo. Stallman era como el tipo con un montón de carne de ballena en su patio delantero. Podría darse un festín por un rato, pero solo puedes comer tanta carne de ballena. Stallman podía editar todo el día y la noche con Emacs. Podía deleitarse con las funciones ordenadas y los geniales trucos de Emacs LISP que amigos y discípulos contribuirían al proyecto. Pero no pudo traducir ese montón de carne de ballena en un sistema operativo gratuito que le permitiera deshacerse de UNIX y Windows. Si bien Stallman no tenía capital monetario, sí tenía mucho capital intelectual. Para 1991, su proyecto GNU había creado muchas herramientas muy respetadas que se encontraban entre las mejores de su clase. Torvalds tuvo un gran ejemplo de lo que podía hacer la GPL antes de elegir proteger su kernel de Linux con la licencia. También tenía un gran conjunto de herramientas que creó el proyecto GNU. El proyecto GNU y la Free Software Foundation pudieron recaudar dinero gracias a la solidez de su software. Emacs y GCC abrieron puertas. La gente dio dinero que fluyó a través de los programadores. Si bien no hubo flujo de efectivo de las ventas de software, el proyecto descubrió que todavía podía funcionar bastante bien. La reputación de Stallman también puede valer más que el dinero cuando abre las puertas correctas. Continúa siendo bendecido por el apoyo implícito del MIT, y muchos jóvenes programadores se enorgullecen de contribuir con su trabajo a sus proyectos. Es una insignia de honor estar asociado con Linux o con la Free Software Foundation. Los programadores a menudo enumeran estos detalles en sus resúmenes y los hechos tienen peso. La reputación también le ayuda a iniciar nuevos proyectos. Podría escribir el esqueleto de un nuevo editor mejorado con palabras de moda de doble rotación, etiquetarlo como "PeteMACS" y publicarlo en la red con la esperanza de que a todos les guste, lo arreglen y lo amplíen. Podría ocurrir. Pero estoy seguro de que a Stallman le resultaría mucho más fácil apoderarse de los corazones, las mentes y los ciclos de repuesto de los programadores porque tiene una gran reputación. Puede que no sea tan líquido como el dinero, pero puede ser mejor. La forma de transferir riqueza de proyecto a proyecto es algo que el mundo del software libre no entiende bien, pero tiene un buen comienzo. Microsoft se hizo rico con DOS y usó ese dinero para construir Windows. Ahora ha estado tratando frenéticamente de usar esta fuente de ingresos para crear otros nuevos negocios. Presionan a MSN, la red de Microsoft, y esperan que pisotee a AOL. Han construido muchos vehículos de entrega de contenido como Slate y MSNBC. Han creado negocios de manipulación de datos como Travelocity. Bill Gates puede simplemente soñar un sueño y poner a trabajar a 10.000 programadores para crearlo. Tiene una gran liquidez intelectual. En este sentido, la batalla entre el desarrollo de software libre y propietario es una entre la entrega pura y la liquidez fuerte. El mundo de la GPL da sin esperar nada a cambio y descubre que a menudo obtiene un retorno mil veces mayor de parte de un agradecido mundo de programadores. El mundo propietario, por otro lado, puede tomar sus ganancias y redirigirlas rápidamente para asumir otro proyecto. Es una batalla entre la velocidad de la cooperación de código abierto fácil y sin restricciones contra la velocidad del rayo del dinero que fluye para hacer que las cosas funcionen. Por supuesto, empresas como Red Hat se encuentran en un término medio. La empresa cobra dinero por el soporte y reinvierte este dinero en mejorar el producto. Vale la pena que varios ingenieros dediquen su tiempo a mejorar todo el producto Linux. Comercializa bien su trabajo y puede cobrar una prima por lo que las personas pueden obtener de forma gratuita. Nadie sabe si el camino elegido por empresas como Red Hat y Caldera y grupos como la Free Software Foundation tendrá éxito a largo plazo. La competencia puede ser una forma muy eficaz de reducir el precio de un producto. Algunos se preocupan de que Red Hat eventualmente sea expulsado del negocio por los CD baratos de $ 2 que copian la última distribución. Sin embargo, por ahora, el éxito de estas empresas muestra que las personas están dispuestas a pagar por un trato que funcione bien. Una pregunta más profunda es si el modelo abierto o propietario hace un mejor trabajo al crear un mundo en el que queremos vivir. Satisfacer nuestros deseos es la última medida de una sociedad rica. Las computadoras, el ciberespacio e Internet están ocupando rápidamente una parte cada vez mayor del tiempo de las personas. La audiencia televisiva está disminuyendo, a menudo de forma espectacular, a medida que la gente recurre a la vida en línea. El tiempo pasado en el ciberespacio va a ser importante. 1 Stallman escribió en la revista BYTE en 1986, estoy tratando de cambiar la forma en que las personas abordan el conocimiento y la información en general. Creo que tratar de apropiarse del conocimiento, tratar de controlar si las personas pueden usarlo o tratar de evitar que otras personas lo compartan, es sabotaje. Es una actividad que beneficia a quien la realiza a costa de empobrecer a toda la sociedad. Una persona gana un dólar destruyendo una riqueza equivalente a dos dólares. Nadie sabe cómo será la vida en línea dentro de 5 o 10 años. Ciertamente incluirá páginas web y correo electrónico, pero nadie sabe quién pagará cuánto. Las estructuras de costos y la disposición a pagar no se han resuelto. Algunas empresas están regalando algunos productos para poder ganar dinero con otros. Muchos están regalando frenéticamente todo con la esperanza de atraer suficientes ojos para eventualmente ganar algo de dinero. El modelo patentado recompensa a los que toman riesgos y brinda a los programadores más inteligentes y rápidos una gran cantidad de capital que pueden usar para volver a jugar. Recompensa a los que satisfacen nuestras necesidades y les da dinero en efectivo que pueden usar para construir modelos más nuevos y más grandes. La distribución del poder es bastante meritocrática, aunque puede fallar cuando se trata de monopolios. Pero la solución de código abierto sin duda proporciona un buen software para todos los que quieran molestarse en intentar usarlo. El precio gratuito contribuye en gran medida a extender su generosidad a una amplia variedad de personas. Nadie está excluido y nadie está excluido de contribuir a la comunidad porque no tiene el pedigrí, la educación, la herencia racial o el color de cabello correctos. La apertura es una herramienta poderosa. Richard Stallman me dijo: "¿Por qué sigue hablando de 'capital'? Nada de esto tiene nada que ver con el capital. Linus no necesitaba capital para desarrollar un núcleo, simplemente lo escribió. Usamos dinero para contratar hackers para trabajar en el núcleo, pero describirlo como capital es engañoso. "La razón por la que el software libre es una idea tan buena es que desarrollar software no requiere realmente mucho dinero. Si no podemos 'recaudar capital' como lo hacen las empresas de software propietario, eso no es realmente un problema. "Desarrollamos mucho software libre. Si una teoría dice que no podemos, hay que buscar las fallas en la teoría". Una de las mejores maneras de ilustrar este enigma es observar las experiencias de los trabajadores de Hotmail después de que Microsoft los adquiriera. Claro, muchos de ellos estaban encantados de recibir tanto por su participación en una organización. Muchos incluso podrían volver a hacer lo mismo si tuvieran la opción. Muchos, sin embargo, están frustrados por su nueva posición como ciudadanos corporativos cuyo trabajo principal es aumentar los resultados de Microsoft. Un fundador de Hotmail le dijo al columnista de PBS Online, Robert Cringely, "Todo lo que obtuvimos fue dinero. No hubo reconocimiento, no hubo diversión. Microsoft obtuvo más del trato que nosotros. No sabían nada sobre Internet. MSN fue un fracaso. Tuvimos 10 millones de usuarios, pero Redmond no nos respetó en absoluto. Bill Gates dijo específicamente: 'No arruines Hotmail', pero eso es lo que hicieron". ---------------------------------------- 24. Futuro David Henkel-Wallace se sentó en silencio en una silla en una cafetería de Palo Alto explicando lo que hacía cuando trabajaba en la firma de software libre Cygnus. Trajo a su nueva hija en un cochecito de bebé y la mantuvo estacionada al lado. Cygnus, por supuesto, es uno de los mayores éxitos en el mundo del software libre. Ayudó a ganar dinero real construyendo y manteniendo el compilador gratuito, GCC, que Richard Stallman construyó y regaló. Cygnus logró ganar dinero real incluso después de regalar todo su trabajo. En medio de una conversación sobre Cygnus y el código abierto, señala a su hija y dice: "Lo que realmente me preocupa es que crezca en un mundo en el que el software sigue teniendo errores como lo es hoy". Otros padres pueden estar preocupados por la economía, las pandillas, las armas en las escuelas o la cantidad de sexo en las películas, pero Henkel-Wallace quiere asegurarse de que los bloqueos de software aleatorios comiencen a desaparecer. Ha hecho su parte. El movimiento de código abierto prospera con el compilador GCC, y Cygnus logró encontrar una manera de ganar dinero con el proceso de mantener el compilador actualizado. Los sistemas operativos libres como Linux o FreeBSD son excelentes alternativas para la gente de hoy. Son pequeños, rápidos y muy estables, a diferencia de las mejores ofertas de Microsoft o Apple. Si el movimiento del software abierto sigue teniendo éxito y creciendo, su hijo podría crecer en un mundo en el que la pantalla azul de la muerte que aterroriza a los usuarios de Microsoft les resulte tan extraña como las máquinas de escribir manuales. Nadie sabe si el mundo del software abierto seguirá creciendo. Algunas personas son muy positivas y señalan que todas las características que hicieron posible que florecieran los sistemas operativos gratuitos no van a desaparecer. En todo caso, las fuerzas del intercambio abierto y la libertad solo se acelerarán a medida que más personas se involucren en la mezcla. Más personas significan más correcciones de errores, lo que significa un mejor software. Otros no están tan seguros, y este grupo incluye a muchas de las personas que están profundamente atrapadas en el mundo del código abierto. Henkel-Wallace, por ejemplo, no está tan seguro de que el código fuente haga mucha diferencia cuando el 99 por ciento de la gente no programa. Claro, Cygnus tuvo un gran éxito al compartir el código fuente con los programadores que usaban GCC, pero todos esos muchachos sabían cómo leer el código. ¿Qué diferencia supondrá el código fuente para el usuario medio que sólo quiere leer su correo electrónico? Alguien que no puede leer el código fuente no va a contribuir mucho al proyecto y ciertamente no va a poner mucho valor en conseguirlo. Una empresa propietaria como Microsoft puede ser capaz de mantener una amplia base de lealtad simplemente ofreciendo un mejor control para las personas que no pueden programar. El software libre se encuentra en una encrucijada interesante mientras se escribe este libro. Se ganó a algunos hackers en los garajes a principios de la década de 1990. A mediados de la década de 1990, los webmasters lo adoptaron como una opción perfectamente buena. Ahora todo el mundo se pregunta si conquistará el escritorio en el próximo siglo. Siempre es tentador para un autor tomar el clásico gambito de noticias de televisión y terminar la historia con la frase franca: "Queda por ver si esto sucederá". Esa puede ser la forma más justa de abordar la información, pero no es tan divertido Voy a predecir audazmente que el software de código abierto ganará la guerra a largo plazo contra las empresas propietarias, pero será una guerra sangrienta y será más costosa de lo que la gente espera. Durante los próximos años, los abogados pasarán horas argumentando casos; la gente pasará tiempo en la cárcel; y se perderán fortunas en la lucha. Aunque parezca difícil de creer, algunas personas ya han pasado tiempo en la cárcel por su participación en la revolución del software libre. Kevin Mitnick fue arrestado en 1995 en medio de acusaciones de que robó millones, si no miles de millones de dólares en código fuente. No hubo juicio, ni siquiera una audiencia de fianza. Finalmente, después de casi cinco años en prisión, Mitnick se declaró culpable de algunos cargos y recibió una sentencia que fue solo unos meses más larga que el tiempo que cumplió mientras esperaba el juicio. Mitnick fue acusado de robar millones de dólares de empresas al irrumpir en las computadoras y robar copias de su código fuente. En la declaración que hizo después de su liberación, dijo: "... mis delitos fueron simples delitos de allanamiento de morada. He reconocido desde mi arresto en febrero de 1995 que las acciones que tomé fueron ilegales y que cometí invasiones a la privacidad. -Incluso me ofrecí a declararme culpable de mis crímenes poco después de mi arresto". Continuó: "El hecho es que nunca privé de nada a las empresas involucradas en este caso. Nunca cometí fraude contra estas empresas. Y no hay una sola prueba que sugiera que lo hice". Esta transgresión, por supuesto, sería romper las reglas. La ironía es que en 1999, Sun anunció que compartiría su código fuente con el mundo. Rogaron a todos que lo miraran y probaran sus debilidades. La marea de opinión cambió y Sun cambió con ella. Por supuesto, entrar en el sistema informático de una empresa siempre será malo, pero es difícil ver los presuntos delitos de Mitnick como algo terrible. Ahora que el código fuente es en gran medida gratuito y a todo el mundo le gusta compartirlo públicamente, empieza a parecerse más a un fabricante de alcohol ilegal durante la Prohibición. La revolución del código libre le ha dado un encanto libertino. Quién sabe si se lo merece, pero el espíritu de la época ha cambiado. Hay más arrestos en camino. En enero de 2000, la policía noruega detuvo a un joven noruego que quería comprender su participación en el desarrollo de software para descifrar los datos de video colocados en discos DVD. Los productores de películas que lanzaron sus películas en este formato estaban preocupados de que una herramienta conocida como DeCSS, que flotaba en Internet, facilitara que los piratas hicieran copias sin licencia de sus películas. El hombre, Jan Johansen, no escribió la herramienta, sino que simplemente ayudó a pulirla y hacerla circular en la red. Los informes de noticias sugieren que un programador alemán anónimo hizo el trabajo pesado real. Aún así, Johansen fue un gran objetivo para la policía, que nunca lo arrestó oficialmente, aunque lo llevaron para interrogarlo. Al momento de escribir este artículo, no está claro si Johansen violó oficialmente alguna ley. Algunos argumentan que violó las restricciones básicas contra el allanamiento de morada. Otros argumentan que hizo circular secretos comerciales que no se obtuvieron legítimamente. Aún otros ven la respuesta de la industria cinematográfica como un esfuerzo por controlar la distribución de películas y las máquinas que las exhiben. Un pirata no necesita usar la herramienta DeCSS para desbloquear los datos en un disco DVD. Simplemente hacen una copia textual del disco sin preocuparse por el cifrado. Eso lleva a otros a sospechar que el verdadero motivo es limitar drásticamente las empresas que producen máquinas que pueden mostrar películas en DVD. Un grupo que está excluido de la refriega es la comunidad de Linux. Si bien existe software para reproducir películas en DVD para Macintosh y PC, no existe ninguno para Linux. DeCSS no debe verse como una herramienta de hackers, sino simplemente como un dispositivo que permite a los usuarios de Linux ver las copias legítimas de los DVD que compraron. Bloquear Linux es como bloquear Apple y Microsoft. La batalla entre la comunidad cinematográfica y el mundo Linux se está calentando mientras escribo esto. Habrá más juicios y quizás más tiempo en la cárcel por delante para los desarrolladores que produjeron DeCSS y las personas que lo compartieron a través de sus sitios web. La mayoría de las batallas no son tan dramáticas. Son en gran parte técnicos, y el mundo del código libre debería ganarlos fácilmente. Las soluciones de código abierto no han tenido la misma interfaz gráfica sofisticada que los productos de Apple o Windows. La mayoría de los programadores que disfrutan de Linux o de las distintas versiones de BSD no necesitan la interfaz gráfica y es posible que no les importe. La buena noticia es que proyectos como KDE y GNOME ya son excelentes herramientas. El mundo del código abierto debe continuar abordando esta área y luchar para producir algo que el hombre promedio pueda usar. La buena noticia es que el software de código abierto suele ganar la mayoría de las batallas técnicas. Las versiones gratuitas de UNIX ya son mucho más estables que los productos de Microsoft y Apple, y parece poco probable que esto cambie. La última versión del sistema operativo de Apple tiene versiones gratuitas de BSD en su núcleo. Esa batalla está ganada. La versión de NT de Microsoft puede vencer a estos sistemas operativos gratuitos en algunos casos extremos, pero cada día son más raros. Solaris de Sun sigue siendo superior en algunos aspectos, pero la empresa comparte el código fuente con sus usuarios de una forma que emula el mundo del código abierto. Más atención significa más programadores y más correcciones de errores. Las luchas técnicas son fáciles de ganar para el código abierto. El mayor activo de Microsoft es la base instalada de Windows, y tratará de usar esto lo mejor que pueda para derrotar a Linux. Al momento de escribir este artículo, Microsoft está implementando una nueva versión del servidor de nombres de dominio (DNS), que actúa como una guía telefónica para Internet. En el pasado, muchas de las máquinas DNS eran cajas UNIX porque UNIX ayudó a definir Internet. Windows 2000 incluye nuevas extensiones de DNS que prácticamente obligan a las oficinas a cambiar a máquinas con Windows para ejecutar DNS. Windows 2000 simplemente no funcionará tan bien con una caja antigua de Linux o UNIX que ejecute DNS. Esta es una estrategia típica de Microsoft y una que es difícil, pero no imposible, de frustrar para los proyectos de código abierto. Si el costo de estos nuevos servidores es lo suficientemente alto, algún grupo de administradores creará su propio clon de código abierto del servidor DNS modificado. Esto ha sucedido una y otra vez, pero no siempre con gran éxito. Las cajas Linux vienen con Samba, un programa que permite que las máquinas Linux actúen como servidores de archivos. Funciona bien y es ampliamente utilizado. Otro proyecto, WINE, comenzó con el gran diseño de clonar todas las API de Windows mucho más complicadas que usan los programadores. Es un proyecto maravilloso, pero está lejos de estar terminado. El tamaño y la complejidad hacen una gran diferencia. A pesar de estas tácticas, Microsoft (y otras empresas propietarias) probablemente perderán su objetivo de dominar los estándares en Internet. Solo pueden dedicar unos pocos programadores a cada toma monopólica. El mundo del software libre tiene muchos programadores dispuestos a emprender proyectos. Los números ahora son lo suficientemente grandes como para que los clonadores puedan manejar cualquier cosa que Microsoft le envíe. Las verdaderas batallas serán políticas y legales. Si bien el mundo de la informática parece moverse a gran velocidad con una gran cantidad de cambios constantes, hay mucha inercia en el mercado. Muchas personas se sorprendieron bastante al descubrir que había mucho COBOL, FORTRAN y otro software antiguo funcionando felizmente sin tener idea de cómo almacenar una fecha con más de dos dígitos. Si bien los incidentes del año 2000 quedaron muy por debajo de la exageración de los medios, la cantidad de sistemas que requirieron reprogramación fue aún mucho mayor de lo que predijo la sabiduría convencional. IBM continúa vendiendo mainframes a clientes que comenzaron a comprar mainframes en la década de 1960. Una vez que las personas eligen una marca, un producto o una arquitectura de computadora, a menudo se quedan con ellos para siempre. Estas son malas noticias para las personas que esperan que los sistemas operativos gratuitos se apoderen del escritorio en los próximos 5 o 10 años. Los gerentes corporativos que mantienen las máquinas en los escritorios de las personas odian el cambio. Cambio significa reeducación. Cambiar significa instalar nuevo software en toda la planta. Cambiar significa enseñar a la gente un nuevo conjunto de comandos para ejecutar sus procesadores de texto. Cambiar significa trabajar. Las personas que administran las redes informáticas en las oficinas reciben una calificación según la cantidad de fallas que detienen el flujo de trabajo. ¿Por qué abandonar Microsoft ahora? Si Microsoft tiene un dominio tan emocional sobre el escritorio y la industria informática tarda una eternidad en cambiar, ¿crecerá alguna vez el software libre más allá de los 10 millones de escritorios que poseen los programadores y sus amigos? Su palanca más fuerte será el precio. La libertad es grandiosa, pero las corporaciones responden mejor a un costo cercano, si no exactamente cero. Las grandes empresas como Microsoft son enormes motores de efectivo. Necesitan una gran afluencia de efectivo para pagar a los trabajadores, y no pueden permitir que el precio de sus acciones baje. Los ingresos de Microsoft aumentaron con una precisión poco común en las empresas estadounidenses. Algunos analistas bursátiles bromean diciendo que el precio de las acciones sugiere que los ingresos de Microsoft crecerán más de un 10 por ciento para siempre. En el pasado, la compañía logró esto absorbiendo más y más del mercado mientras encontraba una manera de cobrar más y más por el software que suministra. Las empresas que vivían bastante bien con Windows 95 ahora ejecutan Windows NT. Las empresas que ejecutaban NT ahora usan paquetes de servicios especiales que manejan la administración de redes y las funciones de datos. El presupuesto para computad oras sigue aumentando, a pesar de que los costos de hardware bajan. Algo tiene que ceder. Es difícil saber cuánto de una palanca será el precio. Si los ingresos de Microsoft dejan de crecer, el precio de las acciones de la empresa podría caer en picado. La empresa se las arregla continuamente para producir ingresos cada vez mayores cada trimestre con una precisión suave. La expectativa del crecimiento está integrada en el precio. Cualquier contratiempo podría hacer que el precio cayera. La pregunta más importante es cuánto está dispuesta a pagar la gente para seguir usando los productos de Microsoft. Reformar una oficina es una propuesta costosa. El costo de comprar computadoras y software nuevos suele ser menor que el costo de la reeducación. Si bien el mundo del software libre es mucho más barato, el cambio no es una propuesta fácil. Solo el tiempo dirá cuánto está dispuesta a pagar la gente por su renuencia a cambiar. Las primeras grietas ya son evidentes. Microsoft perdió el mercado de servidores ante Apache y Linux por precio y rendimiento. Los administradores de servidores web son usuarios de computadoras educados que pueden tomar sus propias decisiones sin tener que preocuparse por la necesidad de capacitar a otros. Las computadoras ocultas como esta son objetivos fáciles, y el mundo del software libre se tragará a muchas de ellas. Más usuarios significan más correcciones de errores y propagaciones de mejor código. La segunda grieta en la armadura de Microsoft serán las computadoras de electrodomésticos. La mayoría de la gente quiere navegar por la web e intercambiar algunos mensajes de correo electrónico. La distribución básica de Red Hat o FreeBSD es lo suficientemente buena. Muchas personas están experimentando con la creación de computadoras que se definen por el trabajo que realizan, no por el sistema operativo o el chip de la computadora. Los paquetes de código fuente gratuitos no deberían tener problemas para ganar muchas batallas en este campo. El precio es correcto y los fabricantes tienen que contratar a los programadores de todos modos. La tercera brecha serán los niños pequeños. No tienen lealtades previas y están ansiosos por aprender nuevas tecnologías informáticas. Microsoft puede preguntar "¿A dónde quieres ir hoy?" pero no quieren hablar con alguien cuya respuesta es "Las entrañas de su sistema operativo". Los mejores y más brillantes niños de 13 años ya son los mayores fanáticos del software libre. Les encanta el poder y el acceso completo. La cuarta grieta serán las grandes instalaciones en empresas que estén interesadas en licitar. Microsoft cobra un paquete por cada asiento en una empresa, y cualquiera que presente una oferta por estos contratos podrá cobrar mucho menos si envía un sistema operativo gratuito. No es raro que una empresa pague más de un millón de dólares a Microsoft por derechos de licencia. Hay mucho espacio para la competencia de precios cuando la factura es tan alta. Las empresas que no quieran cambiar serán difíciles de dejar Windows, pero las que son sensibles a los precios sí lo harán. Por supuesto, el software libre no es realmente libre. Una variedad de empresas que ofrecen soporte para Linux necesitan cobrar algo para pagar sus facturas. Es posible que las distribuciones como Red Hat o FreeBSD no cuesten mucho, pero a menudo necesitan algo de personalización y control. ¿Está una empresa simplemente intercambiando una factura por otra? ¿El soporte de Linux no terminará costando lo mismo que el producto de Microsoft? Muchos no lo creen. Microsoft actualmente desperdicia miles de millones de dólares al año expandiendo su negocio de manera improductiva que no genera nuevas ganancias. Gastó millones en crear un navegador web gratuito para competir con el de Netscape y luego simplemente lo regalaron. Probablemente renunciaron a millones de dólares e incontables monedas de cambio cuando obligaron a sus competidores a rechazar Netscape. Los exitosos productos de la compañía pagan estas excursiones. Como mínimo, una operación de sistema operativo gratuita evitaría estos costos. Los sistemas operativos libres son inherentemente más baratos de ejecutar. Si tiene la fuente, es posible que pueda depurar el problema usted mismo. Probablemente no puedas, pero no está de más intentarlo. Las empresas que ejecutan productos de Microsoft ni siquiera pueden intentarlo. El libre flujo de información ayudará a mantener bajos los costos. Por supuesto, también hay números duros. Un artículo en Wired por Andrew Leonard viene con números desarrollados originalmente por Gartner Group. Una oficina de 25 personas costaría $21,453 para equiparla con productos de Microsoft y $5,544.70 para equiparla con Linux. Esta estimación es un poco conservadora. La mayor parte del costo de Linux es discutible porque incluye casi $3,000 por 10 llamadas de servicio a un consultor de Linux y alrededor de $2,500 por Applixware, una suite ofimática que hace casi el mismo trabajo que Microsoft Office. Una oficina verdaderamente económica y técnicamente moderna podría funcionar con el editor integrado en Netscape y una de las hojas de cálculo gratuitas disponibles para Linux. No es difícil imaginar a alguien haciendo el mismo trabajo por alrededor de $3, que es el costo de una imitación barata de la última distribución de Red Hat. Por supuesto, es importante darse cuenta de que el soporte del software gratuito sigue costando dinero. Pero también lo hace Microsoft. Las empresas de software propietario también cobran por responder preguntas y brindar información confiable. No está claro que el soporte de Linux sea más caro de ofrecer. Además, muchas oficinas, grandes y pequeñas, cuentan con técnicos informáticos. No hay razón para creer que los técnicos de Linux serán más o menos costosos que los técnicos de Microsoft. Ambos responden preguntas. Ambos mantienen los sistemas en funcionamiento. Al menos la tecnología de Linux puede ver el código fuente. El usuario doméstico promedio y el usuario de una pequeña empresa serán los últimos en irse. Estos usuarios serán los más leales a Microsoft porque les resultará más difícil que nadie moverse. No pueden permitirse contratar a sus propios gurús de Linux para remodelar la oficina, y no tienen tiempo para aprender por sí mismos. Estas son las principales debilidades de Microsoft, y la empresa ya se las está tomando en serio. Creo que muchos subestiman lo sangrienta que está a punto de volverse la batalla. Si el software libre es capaz de detener e incluso revertir el crecimiento de los ingresos de Microsoft, habrá algunas personas muy ricas con mucho dinero que se sentirán amenazadas. Microsoft probablemente recurrirá al mismo sistema legal que le dio tanto dolor y encontrará alguna cuña para introducirse en la comunidad de Linux. Su mayor arma serán las patentes y los derechos de autor para detener a los clonadores. Cualquier batalla legal será una pelea interesante. Por un lado, la comunidad de software libre es diversa y está repartida entre muchas entidades diferentes. No hay una oficina central ni una fuente que pueda ser derribada. Esto significa que Microsoft pelearía una guerra en muchos frentes, y esto es algo emocional e intelectualmente agotador para cualquiera, sin importar cuán rico o poderoso sea. Por otro lado, la comunidad del software libre no tiene una reserva central de dinero o fuerza. Cada pequeño grupo podría quedar lisiado, uno por uno, por una desagradable demanda. Grupos como OpenBSD siempre están buscando donaciones. La Free Software Foundation tiene una gran profundidad y afecto, pero su presupuesto es una pequeña fracción del de Sun o Microsoft. Las facturas legales son reales y los abogados saben cómo hacerlas florecer. Puede haber cientos de objetivos diferentes para Microsoft, pero muchos de ellos no requerirán mucha potencia de fuego para noquearlos. La comunidad del software libre no está exenta de grandes bolsillos. Muchas de las compañías de hardware tradicionales como IBM, Compaq, Gateway, Sun, Hewlett-Packard y Apple pueden ganar dinero vendiendo hardware o software. Se han visto perjudicados en los últimos años por el implacable dominio de Microsoft sobre el escritorio. Microsoft negoció contratos duros con cada una de las empresas que controlaban lo que veía el usuario. Los fabricantes de PC recibieron poca capacidad para personalizar su producto. Microsoft los convirtió en fabricantes de productos básicos y les quitó el control. Cada una de estas empresas debería ver un gran potencial en pasar a un sistema operativo gratuito y adoptarlo. No hay costo adicional, ni reuniones extrañas, ni amenazas veladas, ni torceduras de brazo. De repente, marcas como Hewlett-Packard o IBM pueden significar algo cuando se colocan en una PC. Cualquier tonto en un garaje puede poner una placa de circuito en una caja y abofetear a Microsoft Windows. Una gran empresa como HP o IBM podría hacer un trabajo extra para asegurarse de que la distribución de Linux en la caja funcionara bien con los componentes y proporcionara una existencia libre de fallas para el usuario. Las empresas de hardware serán poderosos aliados para el ámbito del software libre porque serán las empresas las que más se beneficien económicamente de las licencias de software libre. Cuando todo el software es gratuito, nadie lo controla y esto elimina muchas de las formas tradicionales de Microsoft de aplicar el apalancamiento. Microsoft, por ejemplo, derribó las piernas debajo de Netscape al regalar Internet Explorer de forma gratuita. Ahora el mundo del software libre está usando la misma estrategia contra Microsoft. Es difícil para ellos socavar gratis para la mayoría de los usuarios. El sistema universitario es un aliado menos estable. Si bien la noción de libre intercambio de información todavía flota en muchos de los campus de la nación, los lugares son terriblemente corporativos y con fines de lucro. Microsoft tiene mucho efectivo a su disposición y no ha tenido reparos en distribuirlo en lugares como el MIT, Harvard y Stanford. Los departamentos de ciencias de la computación en esos campus son los destinatarios de los nuevos edificios cortesía de Bill Gates. Estos regalos son difíciles de ignorar. Microsoft probablemente evitará una confrontación directa con la tradición académica de las instituciones y optará por recortar sus precios lo más bajo que sea necesario para dominar las computadoras de escritorio. Las universidades probablemente recibirán donaciones de software "gratis" y deducibles de impuestos cada vez que se alejen de la solución respaldada por Microsoft. Los directores de laboratorio y las personas que toman decisiones sobre la infraestructura informática de la universidad probablemente obtendrán buenos contratos de "consultoría" de Microsoft o sus colegas. Esto probablemente no signifique una dominación total, pero comprará una cantidad sorprendentemente grande de obediencia. A pesar de estos regalos, el software libre seguirá creciendo en los campus. Los estudiantes a menudo tienen poco dinero en efectivo y Microsoft no obtiene ninguna gran deducción de impuestos al dar obsequios a estudiantes individuales (eso es ingreso). Los niños más inteligentes de los dormitorios seguirán ejecutando Linux. Muchos laboratorios realizan trabajos de vanguardia que requieren software personalizado. Estos grupos naturalmente se sentirán atraídos por el código fuente gratuito porque les hace la vida más fácil. Será difícil para Microsoft contrarrestar la atracción muy real del software libre. Por supuesto, Microsoft no está sin sus propios brazos. Microsoft todavía tiene la ley de patentes de su lado, y esto puede resultar ser un arma muy seria. La ley otorga al titular de la patente el derecho exclusivo de determinar quién usa una idea o invención durante el transcurso de la patente, que ahora es de 20 años a partir de la primera fecha de presentación. Eso significa que el titular de la patente puede demandar a cualquiera que fabrique un producto que utilice la invención. También significa que el titular de la patente puede demandar a alguien que simplemente improvisa la invención en su sótano y utiliza la idea sin pagar nada a nadie. Esto significa que incluso alguien que distribuya el software de forma gratuita o utilice el software puede ser responsable de los daños y perjuicios. En el pasado, muchos desconfiaban de la idea de las patentes de software porque se suponía que el sistema de patentes no permitía reclamar las leyes de la naturaleza. Esta interpretación se quedó en el camino cuando los abogados de patentes argumentaron con éxito que el software combinado con una computadora era una máquina separada y las máquinas eran elegibles para protección. Hoy en día, es bastante fácil obtener protección de patentes para nuevas ideas sobre cómo estructurar una red informática, un sistema operativo o una herramienta de software. El único requisito es que sean nuevos y no obvios. Microsoft tiene muchos de estos. Si las cosas van perfectamente para Microsoft, la empresa podrá sacar una o dos patentes de su enorme cartera y usarlas para demandar a Red Hat, Walnut Creek y algunos de los otros distribuidores importantes. Idealmente, esta patente cubriría una parte crucial del sistema operativo Linux o BSD. Después de que las primeras facturas legales comenzaran a llegar al escritorio del director ejecutivo de Red Hat o Walnut Creek, las empresas tendrían que llegar a un acuerdo abandonando el negocio. Eventualmente, todos los distribuidores de Linux se derrumbarían y regresarían a los pequeños campamentos en las colinas para lamerse las heridas. Al menos, ese es probablemente el sueño de algunos de los mejores soldados legales de Microsoft. Esta maniobra está lejos de ser un bloqueo para Microsoft porque el mundo del software libre tiene varias buenas defensas. La primera es que el mundo Linux y BSD hacen un buen trabajo publicitando sus avances. Cualquier titular de una patente debe presentar la patente antes de que otra persona publique sus ideas. Los grupos de discusión de Linux y las distribuciones de fuentes son un foro público bastante bueno. Las ideas y los parches a menudo circulan públicamente mucho antes de que lleguen a una versión estable del núcleo. Eso significa que los titulares de las patentes deberán estar mucho más adelantados que el mundo del software libre. Linux y el mundo del software libre suelen ser la cuna de nuevas ideas. Los estudiantes universitarios usan software de código abierto todo el tiempo. Es mucho más fácil hacer cosas geniales si tienes acceso a la fuente. Claro, Microsoft tiene algunos investigadores inteligentes con una gran financiación, pero ¿pueden competir con todos los estudiantes? La capacidad de Microsoft para dominar el mundo de las patentes puede verse perjudicada por la naturaleza del juego. Presentar la solicitud primero o publicar una idea primero es todo lo que importa en el mundo de las patentes. Producir un producto real es un trabajo duro que se ve favorecido por el suministro de efectivo de Microsoft. Proponer ideas y hacerlas circular es mucho más fácil que crear herramientas reales que la gente pueda usar. La segunda defensa es la adaptabilidad. Las distribuciones de software gratuito pueden simplemente eliminar el código ofensivo. Los discos Linux y BSD son muy modulares porque provienen de una variedad de fuentes diferentes. Las diferentes capas y herramientas provienen de diferentes autores, por lo que no están muy integradas. Esto hace posible eliminar una parte sin arruinar todo el sistema. El proyecto GNU de Stallman ha estado lidiando con patentes durante mucho tiempo y tiene cierta experiencia en programación alrededor de ellas. El programa GNU Zip, por ejemplo, se escribió para evitar las patentes sobre el algoritmo de compresión Lempel-Ziv reclamadas por UNISYS e IBM. El software está bien escrito y funciona tan bien como el algoritmo al que reemplaza, si no mejor. Ahora es bastante estándar en la web y muy popular porque es de código abierto y libre de patentes. Es el algoritmo de compresión políticamente correcto que se debe usar porque está abierto a todos. Será bastante difícil para una empresa como Microsoft encontrar una patente que le permita dar un golpe fatal a las distribuciones de Linux o BSD. Los grupos simplemente recortarán el código ofensivo y luego trabajarán alrededor de él. La mayor esperanza de Microsoft es asegurar la próxima generación de computación con patentes. Las nuevas tecnologías, como la transmisión multimedia o el audio de Internet, aún están disponibles. Si bien la gente ha estado estudiando estos temas en las universidades durante algún tiempo, la comunidad de Linux está más rezagada. Microsoft intentará dominar estas áreas con patentes cruciales que afectan la forma en que los sistemas operativos manejan este tipo de datos. Su éxito en esto es difícil de predecir. En cualquier caso, si bien pueden paralizar la adopción de algunas tecnologías nuevas, como la transmisión de multimedia, no podrán aplastar al mundo entero. La tercera y mayor defensa de la ideología del código libre es una laguna en la ley de patentes que también puede ayudar a muchas personas en el mundo del software libre. No es ilegal usar una idea patentada si está en el proceso de investigar un poco sobre cómo mejorar el estado del arte en esa área. La escapatoria es muy limitada, pero muchos usuarios de software libre pueden caer en ella. Todas las distribuciones vienen con código fuente y muchos de los usuarios actuales son programadores que experimentan con el código. La mayoría de estos programadores devuelven su trabajo al proyecto y esto hace que la mayor parte de su trabajo no sea comercial. La laguna probablemente no protegería a las corporaciones que usan software libre simplemente porque es barato, pero aún sería lo suficientemente grande como para permitir que la innovación continúe. Una comunidad no comercial construida en torno a la investigación aún podría prosperar incluso si Microsoft logra presentar algunas patentes que so n muy poderosas. El mundo de las patentes todavía puede limitar el mundo del software libre. Muchas empresas trabajan arduamente en el desarrollo de nuevas tecnologías y luego confían en las patentes para garantizarles un retorno de la inversión. Estas empresas tienen problemas para trabajar bien con el movimiento del software libre porque no hay un flujo de ingresos que utilizar. Una empresa como Adobe puede integrar una nueva tecnología de transmisión o un algoritmo de compresión y agregar el costo de una licencia de patente al precio del producto. Una herramienta de software libre no puede. Esto no impide que el mundo del software libre utilice algunas ideas o software. No hay ninguna razón por la que Linux no pueda ejecutar software de aplicación propietario que cueste dinero. Quizás la gente venda licencias para algunas distribuciones y parches. Aún así, los usuarios deben cambiar de marcha mental cuando se encuentran con estos paquetes. No hay soluciones fáciles para los problemas de patentes. La mejor noticia es que la tecnología propietaria y patentada rara vez llega a dominar el mercado. A menudo hay formas de evitar las soluciones, y otros ingenieros son excelentes para encontrarlas. Claro, habrá una bombilla brillante, un transistor, una radio u otra solución ocasional que esté protegida por una patente amplia, pero estos serán relativamente raros. Hay algunas cosas que la comunidad de código abierto puede hacer para protegerse contra las patentes. En este momento, muchos de los esfuerzos para desarrollar soluciones de código abierto surgen después de que surge la tecnología. Por ejemplo, el desarrollo de controladores para discos DVD es uno de los desafíos actuales en el momento en que escribo este capítulo, aunque la tecnología se ha estado comercializando con muchas computadoras de precio medio durante aproximadamente un año. No hay ninguna razón por la cual una investigación de torre de marfil y cielo azul no pueda llevarse a cabo en un mundo de código abierto libre de patentes. Muchas empresas ya permiten que sus investigadores asistan a conferencias y presenten trabajos sobre su trabajo abierto y lo clasifican como investigación "precompetitiva". Estándares como JPEG o MPEG surgen de comités que se comprometen a no patentar su trabajo. No hay ninguna razón por la que estos grupos de investigación sueltos no puedan organizarse en torno a una licencia cuasi-BSD o GNU que obligue a que el desarrollo se mantenga abierto. Estos grupos de investigación probablemente estarán mal financiados pero serán mucho más ágiles que los equipos corporativos o incluso los equipos académicos. Pueden organizarse en torno a un grupo de noticias público o una lista de correo organizada con el propósito de divulgar ideas públicamente. Una vez que se divulgan oficialmente, no se pueden otorgar patentes sobre ellos. Muchas empresas como IBM y Xerox publican revistas en papel con fines defensivos. Aun así, el debate sobre las patentes confundirá a toda la industria del software durante algún tiempo. Muchas empresas propietarias con fines de lucro quedan desconcertadas por algunas de las patentes concedidas a sus competidores. El mundo del código abierto tendrá muchos aliados que querrán rehacer el sistema. Las patentes son probablemente la herramienta legal más potente que las empresas de software propietario pueden utilizar para amenazar el mundo del código abierto. No hay duda de que las empresas lo utilizarán para defenderse de la competencia de rentas bajas. Uno de los mayores desafíos para la comunidad del software libre será desarrollar el liderazgo para emprender estas batallas. Una cosa es perder el tiempo en un garaje con tus amigos y pasar el rato en una casa club virtual de he-man/Microsoft-haters cocinando un código ordenado. Es un desafío muy diferente lograr realmente la dominación mundial sobre la que reflexiona el mundo de Linux. Cuando comencé a escribir el libro, pensé que un himno para el movimiento del software libre podría ser "Flower People" de Spinal Tap. Ahora creo que va a ser "For What It's Worth" de Buffalo Springfield, que advierte: "Aquí está pasando algo / No está exactamente claro qué es". Tim O'Reilly enfatiza este punto. Cuando se le preguntó acerca de algunas de las batallas legales, dijo: "Definitivamente habrá una guerra por este tema. Cuando miro hacia atrás en las revoluciones anteriores, me doy cuenta de lo violentas que se volvieron. Amenazaron con quemar a Galileo en la hoguera. Dijeron 'Retíralo', y él se retractó. Pero al final no hizo ninguna diferencia. Pero solo porque haya una reacción violenta no significa que el código abierto no ganará a largo plazo". Empresas como Microsoft no permiten que los mercados y el territorio se escapen. Tienen un gran presupuesto para comercializar su software. Saben generar prensa positiva y mucho miedo en el corazón de los directivos que deben tomar decisiones. Entienden el valor de la propiedad intelectual y no temen enviar equipos de abogados para garantizar que sus mercados permanezcan protegidos. La comunidad de código abierto, sin embargo, no está exenta de una amplia variedad de fortalezas, aunque puede que no sea consciente de ellas. De hecho, este poder difuso y la falta de autoconciencia y organización es una de sus mayores fortalezas. No hay un liderazgo poderoso que le diga a la comunidad de código abierto "Deberás adoptar estas bibliotecas y escribir en esta API". La gente en las trincheras está probando código, proponiendo soluciones y ensuciándose las manos mientras toma decisiones. El reino no es un gigante, un carro, un acorazado o un tren de carga imparable que ruge por la vía. Es kudzu rastrero, una floración de algas, una moda adolescente y una marea creciente mezcladas. La fuerza del precio libre no debe subestimarse. Si bien el costo no es realmente nada después de sumar el precio de pagar a Red Hat, Slackware, SuSE, Debian u otra persona para brindar soporte, sigue siendo mucho más económico que las soluciones propietarias en el mercado. El precio no es lo único en la mente de las personas, pero siempre será importante. Sin embargo, al final, creo que el mundo del software libre florecerá debido a los ideales que adopta. Los principios de debate abierto, circulación amplia, fácil acceso y divulgación completa son como hierba gatera para los niños que chisporrotean con inteligencia. ¿Por qué alguien querría trabajar en un cubículo corporativo con un jefe de Dilbert cuando puedes pasar toda la noche hackeando las mejores herramientas? ¿Por qué querrías unirte a una jerarquía corporativa interminable cuando puedes sumergirte y ser juzgado por el valor de tu código? Por estas razones, el mundo del software libre siempre puede contar con reclutar a los mejores y más brillantes. Este proceso continuará porque los jefes de grado Dilbert no son tan tontos. Conozco a más de unos pocos ingenieros y primeros empleados de empresas emergentes que recibieron asignaciones de acciones muy pequeñas en el momento de la oferta pública inicial. Uno había escrito tres de los seis sistemas que eran cruciales para el éxito de la empresa en la web. Sin embargo, obtuvo menos del 1 por ciento de las acciones asignadas al nuevo director ejecutivo que acababa de unirse a la empresa. La codicia de los cambistas no programadores que sondean las aguas del capital de riesgo continuará envenenando la experiencia de los programadores y empujando a muchos al mundo del software libre. Si no van a obtener nada, también podrían mantener el acceso al código que escriben. Los ideales de código abierto también son extrañamente empoderadores porque obligan a todos a renunciar a su voluntad de poder y control. Incluso si Richard Stallman, Linus Torvalds, Eric Raymond y todos los demás en el mundo del software libre deciden que eres un cabrón que debería ser exiliado a Siberia, no pueden quitarte el código. Esa libertad es una droga muy poderosa. El movimiento del software libre está redescubriendo las mismas nociones que llevaron a los colonos estadounidenses a rebelarse contra las fuerzas de opresión inglesas. Las mismas palabras que fluyeron a través de las plumas de Thomas Paine, Thomas Jefferson y Benjamin Franklin son igual de importantes hoy. El movimiento del software libre certifica que todos somos creados iguales, con los mismos derechos a la vida, la libertad y la búsqueda de un código libre de errores. Esta gran nación tardó muchos años en evolucionar y tomó muchos desvíos malos en el camino, pero al final, Estados Unidos tiende a hacer lo correcto. El movimiento del software libre tiene muchos defectos, imperfecciones y debilidades, pero creo que también prosperará con el paso de los años. Tomará caminos equivocados y encontrará grandes obstáculos, pero al final la devoción por la libertad, la fraternidad y la igualdad lo llevarán a tomar las decisiones correctas y superará a todos sus competidores propietarios. Al final, el atractivo de la completa libertad para cambiar, revisar, extender y mejorar el código fuente de un proyecto es una droga poderosa que las personas creativas no pueden resistir. La facilidad de uso y la conveniencia preempaquetada del software empaquetado son muy valiosas para muchas personas, pero su mundo es estático y lento. Al final, el poder de escribir código y cambiarlo sin contratar un equipo de abogados para analizar los acuerdos entre empresas asegura que el mundo del software libre gane gradualmente. La organización corporativa proporciona dinero y estabilidad, pero en tecnología la carrera generalmente la gana el más rápido. Al final, el software libre genera riqueza, no dinero, y la riqueza es mucho mejor que el dinero. No puedes comer dinero en efectivo y no puedes construir un auto con oro. El software libre hace cosas y realiza tareas sin chocar con la pantalla azul de la muerte. Empodera a las personas. Las personas que la crean y la comparten están construyendo una infraestructura real que todos pueden usar. Las corporaciones pueden tratar de controlarlo con leyes de propiedad intelectual. Pueden comprar personas, engañar a los jueces y cooptar a los políticos, pero no pueden ofrecer más que dinero. Al final, la información quiere ser libre. Las corporaciones quieren creer que el software es un bien manufacturado como un automóvil o una tostadora. Quieren fingir que es algo que solo se puede consumir una vez. En realidad, está mucho más cerca de una broma, una idea o un chisme. ¿Quién ha logrado controlarlos? Por todas estas razones, esta gran fiesta de todos contra todos, esta gran fiesta de intercambio de software, esta maravillosa fiesta de pijamas sin parar de creación cooperativa de conocimiento, este increíble proyecto científico con esteroides crecerá a pasos agigantados e inesperados hasta que se trague al mundo. Habrá batallas, habrá ejércitos, habrá espías, habrá serpientes, habrá juicios, habrá leyes, habrá mártires, habrá héroes y habrá traidores. Pero al final, la información solo quiere ser libre. Eso es lo que nos encanta. ------------------------------- 25. Glosario Gratuita para todos. Ir a la tabla de contenidos. Visita el Gifcom. *Licencia Apache* Un primo cercano de la Licencia BSD. El software viene con pocas restricciones, y ninguna le impide tomar una copia de Apache, modificarlo y vender versiones binarias. La única restricción es que no puedes llamarlo Apache. Por ejemplo, C2Net comercializa un derivado de Apache conocido como Stronghold. *AppleScript* Un lenguaje de texto que se puede utilizar para controlar la interfaz visual de Macintosh. Esencialmente dice cosas como "Abra esa carpeta y haga doble clic en Adobe Photoshop para iniciarlo. Luego abra el archivo llamado 'Imagen del perro de Pete'". arquitectura Los informáticos usan la palabra "arquitectura" para describir la planificación estratégica de alto nivel de un sistema Un arquitecto de computadoras puede decidir, por ejemplo, que un nuevo sistema debe venir con tres circuitos multiplicadores pero no con cuatro después de analizar la secuencia de operaciones aritméticas que una computadora probablemente tendrá que ejecutar. Si a menudo hay tres multiplicaciones que se pueden hacer al mismo tiempo, la instalación de tres circuitos multiplicadores aumentaría la eficiencia. Sin embargo, agregar un cuarto sería una pérdida de esfuerzo si hubiera pocas ocasiones para usarlo. En la mayoría de los casos, el término "arquitecto informático" se aplica solo a los ingenieros de har dware. Sin embargo, todos los proyectos de software suficientemente complicados tienen un arquitecto que toma las decisiones iniciales de diseño. *Licencia artística* Una licencia creada para proteger el lenguaje PERL original. A algunos usuarios no les gusta la licencia porque es demasiado compleja y está llena de lagunas. Bruce Perens escribe: "La Licencia Artística requiere que hagas modificaciones gratis, pero luego te da una laguna (en la Sección 7) que te permite hacer modificaciones privadas o incluso colocar partes del programa con licencia Artística en el dominio público". *BeOS* Un sistema operativo creado por Be, una empresa dirigida por el exejecutivo de Apple Jean Louis Gass e. *BSD* Abreviatura de Berkeley Software Distribution, un paquete lanzado por primera vez por Bill Joy en la década de 1970. El término ha llegado a significar tanto una clase de UNIX que formaba parte de la distribución como también la licencia que protege este software. Hay varias versiones gratuitas de BSD UNIX que son bien aceptadas y respaldadas por la comunidad de software libre. OpenBSD, NetBSD y FreeBSD son tres de ellos. Muchas versiones comerciales de UNIX, como Sun's Solaris y NeXT's OS, tienen sus raíces en esta distribución. El BSD estaba originalmente protegido por una licencia que permitía que cualquier persona copiara y modificara libremente el código fuente siempre que le diera algún crédito a la Universidad de California en Berkeley. A diferencia de GNU GPL, la licencia no requiere que el usuario libere el código fuente para realizar modificaciones. *Licencia BSD* La licencia original para el software BSD. Puso pocas restricciones sobre lo que hizo con el código. Los términos importantes lo obligaron a mantener intactos los derechos de autor y dar crédito a la Universidad de California en Berkeley cuando anuncia un producto. El requisito de incluir crédito ahora se eliminó porque la gente se dio cuenta de que a menudo necesitaban publicar cientos de reconocimientos para un solo CD-ROM. Berkeley eliminó el término con la esperanza de que fuera un buen ejemplo para el resto de la comunidad. *copyleft* Otro término que a veces se usa como sinónimo de la Licencia Pública General GNU. *Pautas de software libre de Debian* Consulte Código abierto. (www.debian.org) *controlador* La mayoría de las computadoras están diseñadas para funcionar con dispositivos opcionales como módems, unidades de disco, impresoras, cámaras y teclados. Un controlador es una pieza de software que traduce las señales enviadas por el dispositivo en un conjunto de señales que el sistema operativo puede entender. La mayoría de los sistemas operativos están diseñados para ser modulares, por lo que estos controladores se pueden agregar como una idea de último momento cada vez que un usuario conecta un nuevo dispositivo. Por lo general, están diseñados para tener una estructura estándar para que otro software funcione con ellos. El controlador de cada mouse, por ejemplo, traduce las señales del mouse en una descripción estándar que incluye la posición del mouse y su dirección. Los controladores son un punto importante de debate en la comunidad de software libre porque los voluntarios a menudo deben crear los controladores. La mayoría de los fabricantes escriben los controladores para las computadoras con Windows porque estos clientes constituyen la mayor parte de sus ventas. Los fabricantes a menudo evitan crear controladores para sistemas Linux o BSD porque perciben que el mercado es pequeño. Algunos fabricantes también citan la GPL de GNU como un impedimento porque sienten que entregar el código fuente a sus controladores publica información competitiva importante. *FreeBSD* La versión más popular de BSD. El equipo de desarrollo, dirigido por Jordan Hubbard, trabaja arduamente para proporcionar una herramienta fácil de usar para computadoras que ejecutan la arquitectura Intel x86. En los últimos años, han intentado diversificarse en otras líneas. (www.freebsd.org) *Free Software Foundation* Una organización creada por Richard Stallman para recaudar dinero para la creación de nuevo software libre. Stallman dona su tiempo a la organización y no cobra salario. El dinero se gasta en contratar programadores para crear nuevo software libre. *GIMP* El programa de manipulación de imágenes de GNU, que puede manipular archivos de imágenes de la misma manera que Adobe Photoshop. (www.gimp.org) *GNOME* El entorno del modelo de objetos de red GNU, que podría resumirse como "Toda la funcionalidad de Microsoft Windows para Linux". En realidad es más. Hay muchas mejoras que hacen que la herramienta sea más fácil de usar y más flexible que el prototipo de Redmond. Vea también KDE, otro paquete que logra casi lo mismo. (www.gnome.org) *GNU* Acrónimo recursivo que significa "GNU no es UNIX". El proyecto fue iniciado por Richard Stallman en la década de 1980 para luchar contra la marea de software propietario. El proyecto comenzó con varios programas muy buenos como GNU Emacs y GCC, el compilador de C que estaba protegido por la Licencia de Propósito General GNU de Stallman. Desde entonces, ha crecido para emitir paquetes de software que manejan muchas tareas diferentes, desde juegos (GNU Chess) hasta privacidad (GNU Privacy Guard). Ver también GPL y Free Software Foundation (www.gnu.org). Su objetivo principal es producir un sistema operativo gratuito que brinde al usuario la capacidad de hacer todo lo que quiera con el software que viene con el código fuente. *GNU/Linux* El nombre que algunas personas usan para Linux como una forma de dar crédito al proyecto GNU por su liderazgo y contribución de código. *GPL* Abreviatura que significa "Licencia de uso general". Esta licencia fue escrita por primera vez por Richard Stallman para controlar el uso del software creado por el proyecto GNU. Un usuario es libre de leer y modificar el código fuente de un paquete protegido por GPL, pero el usuario debe aceptar distribuir cualquier cambio o mejora si llega a distribuir el software. Stallman ve la licencia como una forma de obligar a las personas a compartir sus propias mejoras y contribuir al proyecto si se benefician del arduo trabajo del proyecto. Véase también BSD. lenguajes de *nivel superior* Los programadores informáticos modernos casi siempre escriben su software en lenguajes como C, Java, Pascal o Lisp, que se conocen como lenguajes de nivel superior. La palabra "superior" es un modificador que mide la cantidad de abstracción disponible para un programador. Un lenguaje de alto nivel podría permitir que un programador dijera: "Agregue ingresos variables a pérdidas variables a ganancias de la computadora". Un lenguaje de alto nivel sería capaz de averiguar dónde encontrar la información sobre las ganancias y las pérdidas. Un lenguaje de programación de bajo nivel requeriría que el autor del software apuntara directamente a una ubicación en la memoria donde se podrían encontrar los datos. *KDE* El entorno de escritorio K es otro conjunto de herramientas que ofrece muchas de las mismas funciones que Windows. Es controvertido porque originalmente usaba algún software propietario y algunos usuarios necesitaban una licencia. Véase también GNOME, un paquete similar que se distribuye bajo la GNU GPL. (www.kde.org) *kernel* El núcleo de un sistema operativo responsable de hacer malabarismos con las diferentes tareas y equilibrar todas las demandas. Imagínese un cocinero de comida rápida que prepara huevos revueltos, tuesta pan, pica la comida y de alguna manera se las arregla para sacar una orden en unos pocos minutos. Un núcleo en un sistema operativo hace malabares con las solicitudes para enviar información a una impresora, mostrar una imagen en la pantalla, obtener datos de un sitio web y mil otras tareas. *Linux* El nombre dado al núcleo del sistema operativo iniciado por Linus Torvalds en 1991. La palabra ahora se usa generalmente para referirse a un paquete completo de paquetes de software libre que funcionan juntos. Red Hat Linux, por ejemplo, es un gran paquete de software que incluye paquetes escritos por muchos otros proyectos no relacionados. *Licencia pública de Mozilla* Un primo de la Licencia pública de Netscape que se creó para proteger las contribuciones públicas al árbol fuente del proyecto Mozilla. Netscape no puede volver a licenciar las modificaciones al código protegido por la MPL, pero puede hacerlo a la NPL. Véase también Licencia pública de Netscape. *NetBSD* Una de las distribuciones gratuitas originales de BSD. El equipo se enfoca en asegurarse de que el software funcione bien en una amplia variedad de plataformas de hardware, incluidas algunas relativamente raras como Amiga. (www.netbsd.org) *Licencia pública de Netscape* Una licencia creada por Netscape cuando la empresa decidió lanzar su navegador como fuente abierta. La licencia es similar a la Licencia BSD, pero proporciona características especiales a Netscape. Se les permite tomar instantáneas del código fuente abierto y convertirlas nuevamente en un proyecto privado y propietario. Bruce Perens, uno de los consultores no remunerados que ayudó a Netscape a redactar la licencia, dice que la disposición se incluyó porque Netscape tenía contratos especiales con empresas para proporcionar una herramienta patentada. Véase también Licencia pública de Mozilla. *OpenBSD* Una de las tres versiones principales de BSD disponibles. El equipo de desarrollo, dirigido por Theo de Raadt, tiene como objetivo proporcionar la mejor seguridad posible examinando el código fuente en detalle y buscando posibles agujeros. (www.openbsd.org) código abierto Término amplio utilizado por la Iniciativa de Código Abierto (www.opensource.org) para abarcar el software desarrollado y publicado bajo la Licencia Pública General GNU, la licencia BSD, la Licencia Artística, el Consorcio X, y la licencia de Netscape. Incluye licencias de software que imponen pocas restricciones a la redistribución del código fuente. La definición de Open Source Initiative fue adaptada de las Directrices de software libre de Debian. La definición de OSI incluye 10 criterios, que van desde insistir en que el software y el código fuente deben redistribuirse libremente hasta insistir en que la licencia no discrimine. *Iniciativa de código abierto* Un grupo creado por Eric Raymond, Sam Ockman, Bruce Perens, Larry Augustin y muchos más. El grupo verifica las licencias para ver si coinciden con su definición de fuente abierta. Si la licencia se ajusta, puede llevar el término "certificado por la OSI". *Procesamiento múltiple simétrico* Gran parte del trabajo reciente en el diseño de sistemas operativos se centra en encontrar formas eficientes de ejecutar múltiples programas simultáneamente en múltiples chips de CPU. Este trabajo es relativamente sencillo si las diferentes piezas de software se ejecutan independientemente unas de otras. La complejidad crece sustancialmente si las CPU deben intercambiar información para coordinar su progreso. El núcleo debe orquestar la mezcla de información para que cada CPU tenga suficiente información para continuar su trabajo con una cantidad mínima de tiempo de espera. Es importante encontrar una buena manera de lograr este SMP porque muchas de las nuevas máquinas que aparecen después de 2000 pueden venir con múltiples procesadores. *UNIX* Un sistema operativo creado en AT&T Bell Labs por Ken Thompson y Dennis Ritchie. El sistema se diseñó originalmente para admitir múltiples usuarios en una variedad de plataformas de hardware diferentes. La mayoría de los programas escritos para el sistema aceptan texto ASCII y escupen texto ASCII, lo que facilita encadenarlos. El nombre original era "unics", que era un juego de palabras con el entonces popular sistema conocido como Multics.