Este término, de acuñación bastante reciente, describe software que está disponible en forma de fuentes para quien desee usarlo. La actividad de compartir los resultados de trabajo en el computador siempre ha estado presente en la subcultura que rodea estas máquinas, particularmente en el ámbito académico. Es sólo recientemente que esta actividad ha adquirido notoriedad pública.
Muchas veces se confunde el software de fuente pública con software de dominio público. Sin embargo, hay profundas diferencias entre las diferentes opciones que se han usado para distribuirlo. Todas ellas se basan en las leyes y convenciones internacionales de derecho de autor. Estas especifican ciertos derechos del autor (o del dueño de los derechos) de una obra literaria o artística (lo que definitivamente es una curiosa categoría bajo la cual clasificar software). En síntesis, esta legislación reserva para el autor (o dueño de los derechos de autor) el uso exclusivo de la obra del caso. El dueño de los derechos puede, sin embargo, licenciar el uso (en escencia, comprometerse a no llevar a los tribunales al usuario) bajo ciertas condiciones. El caso típico es el que el usuario deba pagar por el derecho de uso del software, posiblemente con ciertas restricciones adicionales (usarlo en una sola máquina, no sacar copias, uso educacional únicamente son restricciones comunes). De esto vive la industria tradicional de software.
Sin embargo, desde los albores de la computación han existido grupos que intercambiaban software, aprendiendo los unos de los otros y dejando un legado creciente creado en forma conjunta. Con la enorme expansión de la computación estos grupos crecieron, alcanzando algunos de ellos dimensiones de leyenda en el folklore. Inicialmente se crearon partiendo de grupos de usuarios de las distintas plataformas (como fue el caso de Decus, grupo de usuarios de minicomputadores de DEC). Con la aparición de las redes, y luego de Internet estos grupos aislados comenzaron a establecer contactos mas fluidos. Ayudó en ésto la aparición de Unix, y luego los estándares POSIX asociados, que permitieron la portabilidad práctica de programas fuentes de una máquina a otra. Al comienzo dificultoso, con la adopción de los estándares (el movimiento de sistemas abiertos) esta tarea se hizo cada vez más fácil. Nacieron varias iniciativas de parte de programadores entusiastas que perseguían compartir software con sus pares alrededor del mundo. Aparecieron así variadas opciones para distribuir software. Como estamos considerando software que se distribuye gratuitamente, todas las opciones de distribución incluyen cláusulas en el sentido que el software se distribuye sin garantías de ninguna especie, así que este aspecto no se mencionará explícitamente. Entre las condiciones más importantes se cuentan:
En realidad, hay una gran variedad de licencias de fuente realmente pública, pero en general se pueden asimilar a una de estas tres grandes categorías. Lo que tienen en común es no impedir (y ojalá fomentar) la distribución de los fuentes del software. Otras licencias reservan los derechos de todo software desarrollado a partir de las fuentes entregadas al dueño de los derechos, situación que en general es mirada con malos ojos por la comunidad de desarrolladores.
La idea de que un ``grupo de chascones en Internet'' (como los describió un escéptico) sin mayor coordinación pueda crear y mantener software complejo, y de alta calidad, parece un contrasentido. Nace también inmediatamente la pregunta de a quién recurrir en caso de problemas.
Para entender cómo este proceso en apariencia caótico da los resultados que se aprecian hace falta profundizar un poco en el proceso de desarrollo y las fuerzas que lo mueven. Esta es un área que ha tratado con gran detalle Eric S. Raymond en su serie de artículos clásicos The Cathedral and the Bazaar (la catedral y el bazar, donde contrasta el esquema de desarrollo de software en ambiente cerrado con una catedral y el desarrollo abierto, en el cual cualquiera puede participar, con un bazar), en el cual describe cómo (y porqué) funciona el sistema de desarrollo que instituyó Linus Torvalds con Linux en 1991-1992, que consiste en distribuir tempranamente y frecuentemente, delegar todo lo que se pueda, y desarrollo abierto hasta el punto de promiscuidad. En parte para probar sus teorías, usó como caso de prueba el proyecto fetchmail, cuyo éxito demostró que las premisas básicas eran correctas. Está claro que este éxito hubiese sido imposible antes que Internet se masificara, y el genio de Linus Torvalds consiste precisamente en saber aprovechar la oportunidad que ofreció la entonces emergente tecnología. En la secuela del anterior, Homesteading the Noosphere describe cómo se gestan y se mantienen, incluso por largo tiempo, proyectos de desarrollo complejos frente a cambios permanentes de los participantes, y cuáles son las fuerzas que impiden que los proyectos se fragmenten al aparecer disensos en el grupo de desarrollo. Finalmente, en The Magic Cauldron hace un análisis más detallado de la economía del desarrollo de software de fuente pública, y llega a la conclusión de que incluso puede ser económicamente beneficioso (tanto para la empresa como para el desarrollador individual) abrir los fuentes.
Sus conclusiones en general apuntan a que el participar en un proyecto abierto, en el cual se puede ganar el reconocimiento público de sus pares en todo el mundo es un fuerte incentivo. Los desarrolladores de estos proyectos son auto-seleccionados, y probablemente pertenezcan al 5% más competente. Como se sabe que la diferencia de productividad entre los mejores y los peores programadores es en factores de 100 ó más, cabe esperar buenos resultados. El que hayan varias personas trabajando simultáneamente sobre un mismo tema sirve para explorar diversas alternativas, eligiendo la que da mejores resultados en la práctica una vez que estén relativamente completas, no está la necesidad de definirse por una alternativa sin información adecuada sobre su rendimiento real.
Estas conclusiones fueron en parte las que llevaron a que Netscape anunciara públicamente a comienzos de 1998 que abriría el código de Netscape Navigator. Ese mismo año, IBM anunció que soportaría Apache como servidor web como parte de WebSphere. Desde hacía tiempo, empresas como Digital (hoy parte de Compaq) y Sun han estado apoyando al desarrollo de Linux en forma más o menos abierta. Más recientemente Apple, IBM, SGI, y Hewlett-Packard han comenzado a portar Linux a sus máquinas. El caso de SGI es importante, existen indicios de que estudian seriamente migrar sus ofertas en el ámbito Unix a Linux, y en particular apoyar fuertemente el desarrollo de Linux para sus supercomputadores. Para estas empresas eso significa contar con un rango mucho mayor de desarrolladores talentosos, y les descarga parte del costo de desarrollo de software, que en sí no les produce beneficios (su producto es, finalmente, el hardware). Hoy en día, tanto IBM como SGI y Compaq tienen proyectos importantes sobre Linux, con apoyo oficial de la empresa. Por otro lado, Sun adquirió la empresa Star Division, quienes desarrollaron StarOffice, el producto de oficina más popular en Linux en este momento. Inicialemente distribuian StarOffice gratuitamente, para liberar el código fuente bajo GPL el 13 de octubre del 2000.
Otro ejemplo es el caso del desarrollo de la colección de compiladores del proyecto GNU, conocidos colectivamente como GCC. Originalmente, este proyecto estaba férreamente controlado, con versiones liberadas muy a lo lejos. En 1997 la empresa Cygnus, cuyo principal negocio consiste en portar este compilador a nuevas CPUs y que es uno de los principales proveedores de herramientas para desarrollo de aplicaciones empotradas, lanzó el proyecto Egcs para continuar el desarrollo (que a la sazón estaba claramente estancado) en el espíritu del proyecto Linux. Desde entonces, con versiones casi semanales de prueba, el desarrollo se ha acelerado enormemente. Más recientemente a los interesados se les sugiere sincronizar su copia de los fuentes usando CVS (un sistema de control de versiones distribuido) directamente a través de la red desde el repositorio central. Muchos otros proyectos están haciendo ésto, entre los más importantes se cuenta el paquete SAMBA, que permite a una máquina Unix actuar como servidor y cliente en una red Windows. Incluso han aparecido sitios que mantienen los repositorios de fuentes de varios paquetes, el más importante de éstos es probablemente SourceForge.
Es crítico para la supervivencia de un proyecto de éstos que el líder ejerza con prudencia su poder de veto frente a modificaciones, de manera de impedir que el producto se hunda bajo una masa de ``características indispensables.'' Debe imponer una arquitectura general en el marco de la cual se aceptan sugerencias y modificaciones. Uno de los problemas es que la persona a la cabeza no escala bien; sin embargo, el mismo proyecto Linux (con seguramente algunos miles de desarrolladores en diversos grados de actividad) demuestra que este efecto no es tan grave como pareciera, dado un círculo de responsables por diversos subsistemas que sirvan de filtro previo, además de la discusión pública y las pruebas a las que las distintas versiones se ven sometidas de parte de los interesados.
Como son muchos los que están leyendo el código, la probabilidad de que se pasen errores por alto es baja (y el quedar en ridículo públicamente es un buen incentivo para no cometerlos en primer lugar). La calidad del código que se logra a través de este sistema de desarrollo no tradicional se ve avalada por los experimentos con entradas al azar a los que se sometieron diversos programas ( fuzz). Este proyecto nació de la observación que entradas aleatorias (en este caso, basura inducida por una tormenta eléctrica cercana en una comunicación vía telefónica) hacían que algunos programas fallaran. En 1990 encontró que en 5 Unix comerciales esto hacía fallar entre 24 y 33% de los 49 a 85 utilitarios sometidos a prueba, dependiendo del proveedor. En 1995 se repitió el experimento con 9 sistemas, incluyendo paquetes GNU y una distribución de Linux. El resultado fue que de entre 47 a 80 programas fallaban entre 15 y 43% en los Unix comerciales. Comparando nuevas versiones con los sistemas originales, las tasas de fallas ahora eran entre 18 y 24%. Las tasas de falla de aplicaciones GNU y de Linux fueron 6 y 9%, respectivamente. En febrero del 2000 se repitieron las experiencias (aunque en forma mucho más limitada) con aplicaciones sobre Windows NT y Windows 2000. El 100% de las aplicaciones probadas falló.
Durante 1999 se produjo una verdadera locura en las bolsas por la alta demanda de las acciones de empresas relacionadas con Linux. Un análisis calmado muestra que este efecto fue en parte resultado de una estampida de parte de los inversionistas por no quedarse atrás en la siguiente ola de innovaciones tecnológicas, y que los precios siderales que alcanzaron algunas acciones simplemente no tenían justificación racional. Recientemente muchas de las acciones de empresas en el rubro Internet sufrieron fuertes caídas, pero las empresas alrededor de Linux en general se han mantenido.
Linux (y en términos más generales, software de libre distribución) es un negocio, incluso un buen negocio. Las distribuciones de Linux más populares (entre las que se cuentan Red Hat, SuSE, Mandrake, y más recientemente Conectiva, con su área en Chile) son mantenidas por compañías que han experimentado una expansión fenomenal. Y estas compañías prosperan a pesar que es perfectamente posible obtener copias de su productos bajándolas a través de la red, sin pagarles un centavo (incluso les significa un costo el ponerlos a la disposición del público). Esto se compensa con que es mucho más conveniente para el usuario comprar el paquete, que incluye manuales impresos y posiblemente otras ventajas, e instalar de allí. Algunos simplemente adquieren el paquete con la intención de retribuir en parte el esfuerzo que ha hecho la empresa. Estas empresas por lo demás ofrecen otros servicios, como soporte técnico y capacitación; y últimamente se ha puesto de moda ofrecer cursos y pruebas de certificación. A cambio de abrir sus productos (incluso a la competencia), ganan dado que los usuarios, reportan problemas, y, como tienen acceso al código fuente, hasta pueden ofrecer correcciones.
Una de las aprehensiones frecuentes sobre software cuyas fuentes están disponibles públicamente es la seguridad. El razonamiento es que los crackers, al tener acceso a los fuentes, pueden encontrar debilidades con mayor facilidad. Sin embargo, ese mismo acceso permite que uno tenga la posibilidad de verificar que no hay debilidades ocultas. Es poca la gente suficientemente paranoica como para hacer estas verificaciones por sí mismas (o contratar a alguien para que las haga por ellos), pero al existir la posibilidad de hacerlo hay personas que lo harán. Claro que no hay garantías de que este proceso lleve a descubrir los problemas, el que ande buscando modificar un programa para ajustarlo a su conveniencia revisrá sólo lo necesario para sus fines, y no necesariamente se fijará en los problema de seguridad. También es posible que los que descubran los problemas sean malintencionados... Todo esto se discute en detalle en The Myth of Open Source Security.
Hay herramientas que permiten detectar posibles problemas de seguridad en forma automática, como por ejemplo ITS4. Estas herramientas analizan el código fuente de una aplicación para detectar errores comunes. Hay bastantes interesados en mejorar la seguridad del sistema, entre ellos en primera línea los proveedores del mismo.
Es una de las verdades comúnmente aceptadas en la comunidad de seguridad que lo que llaman seguridad a través de la obscuridad (o sea, tratar de hacer seguro un sistema ocultando su funcionamiento) es inútil: Tarde o temprano el secreto se revelará, y la seguridad desaparece con él. Es así como recomiendan confiar sólo en sistemas que han sido sometidos a escrutinio y análisis públicos. De la misma forma, si un sistema tiene debilidades, tarde o temprano se sabrán (y las ratas las aprovecharán de ellas; posiblemente antes que los responsables se enteren, muchas veces antes que el problema se resuelva, y aún mucho antes que las soluciones se hayan distribuido ampliamente). Una indicación de la robustez de un sistema frente a ataques lo dan los resultados de pruebas con datos al azar, las vulnerabilidades más comunes usadas por los crackers hoy día se reflejarán en caídas del programa. Ninguno de los servicios de red tradicionales (expuestos, por su naturaleza, a toda clase de ataques externos) de los Unix considerados en las ya mencionadas pruebas con datos aleatorios del año 1995 sucumbió.
Es mi experiencia personal que puede ser más fácil corregir problemas de seguridad que encontrar una manera de explotarlos. A comienzos de 1996 me interesé en el código del programa dip, que maneja conexiones TCP/IP vía telefónica en Unix. Encontré varios puntos dudosos en el código (no vi cómo podrían explotarse, aunque a decir verdad tampoco invertí mucho tiempo en este análisis), los corregí y envié un parche al mantenedor del paquete. Poco después supe de ataques bastante rebuscados a este programa, que con mi parche dejaron de ser efectivos.