Código Abierto: más allá del software libre

Aún existe otra iniciativa todavía más libre desde el punto de vista del usuario: el código abierto (open source). En él, el código fuente es puesto a disposición de la comunidad para que pueda evolucionar sin ninguna limitación, ni siquiera la obligatoriedad de que el resultado de las modificaciones sea también código abierto.

El gran peligro de éste tipo de licencia, en opinión de la gente de GNU, es que una empresa tome el código de un programa construido por la comunidad y desarrolle a partir de él un programa propietario. Esto no es ni más ni menos que lo que ha hecho Apple con el Unix BDS, una versión de Unix de código abierto sobre la que Apple ha montado sus últimas versiones de MacOS. Desde el punto de vista de GNU, esto es una atrocidad, mas desde el punto de vista de la gente de Open Source es un avance más para el mundo del software. Para el usuario, evidentemente, la disponibilidad de un sistema operativo robusto, fiable y fácil de utilizar es una ventaja, y para Apple, sin duda, una decisión acertadísima, como todas sus decisiones recientes. Aquí Apple, el gran defensor de las soluciones cerradas incluso en hardware, se alía con el mundo del software abierto. Bueno, se aprovecha, dirán algunos. Aunque está claro que los usuarios ganan un sistema más robusto y potente que el anterior.

¿Modelo entre el Software Libre y el Código Abierto?

El inconveniente del software libre es que en la práctica está vetado para las empresas tradicionales y que la obtención de recursos económicos para sostener su modelo es complicada. Me pregunto: ¿no habría algún modo de poder anular en ciertos casos la cláusula de obligatoria redistribución de las modificaciones a condición de hacer partícipes a los desarrolladores previos de los beneficios obtenidos con la comercialización ulterior? Soy consciente de que sería muy complejo determinar quiénes fueron los participantes y en qué grado durante el desarrollo de un proyecto de software libre, pero este proceso se simplifica en el caso de software libre auspiciado por alguna fundación.

En este sentido, la licencia LGPL o la cláusula que Sun ha añadido a la reciente liberación de Java bajo licencia GPL permiten al menos el uso de librerías por parte de productos comerciales. Cada vez más especialistas opinan que el futuro del desarrollo informático son el modelo libre o el abierto, y seguramente tienen razón. No me sorprendería ver a Microsoft dentro de unos años exponiendo las bondades del software libre como modelo de negocio; no hay que olvidar que Microsoft terminó siendo una abanderada de Internet cuando inicialmente se propuso construir una red alternativa llamada “Microsoft Network”, que finalmente acabó siendo un portal más.

Herramientas de desarrollo propietarias

Hasta ahora hemos hablado de programas de usuario, pero las herramientas de desarrollo merecen un comentario aparte. A mi juicio, el peor error en el que puede caer un departamento de desarrollo informático es el de depender de un fabricante propietario de sus herramientas. A lo largo de mi experiencia profesional he visto caer torres muy altas, he visto desaparecer excelentes herramientas de programación o ser modificadas de una versión a otra de modo que el código fuente (el capital de la empresa) dejaba de ser útil para la siguiente versión, es decir, o uno continuaba con la herramienta antigua o sencillamente tiraba casi todo el código y empezaba de cero. Esto ha sido especialmente cierto para todo lo relacionado con los interfaces de usuario.

Y, sin embargo, este grave error se comete por doquier. En España, muchísimas empresas utilizan software de desarrollo de Microsoft, lo que, entre otras cosas, les limita la plataforma sobre la que ejecutar sus aplicaciones (Windows, Internet Information Server, etc). Todavía más sorprendente: ¡en muchos casos es el cliente de dichas empresas el que obliga a que se utilicen estas herramientas! Creo que en gran parte esto se debe al hecho de que la Informática es en España (único país de la UE en el que sucede esto) una profesión no regulada (¡señores políticos, cuándo introducirán atribuciones en el sector!) y por tanto las decisiones acerca de plataformas de desarrollo no recaen sobre informáticos. Es como si el cliente de un arquitecto le obligara para contratar sus servicios a que utilizara determinado programa de diseño o de cálculo de estructuras. Está claro que el arquitecto está más cualificado que el cliente para saber qué programa de cálculo de estructuras debe utilizar.

Y conste que siempre he defendido a Microsoft como la empresa que ha sabido llevar el uso del ordenador a los hogares, al usuario no técnico. Y aunque, como siempre se dice, sus tecnologías son “importadas” de otros, como Xerox, el mérito de la difusión corresponde a Microsoft. Pero llevar, a través de herramientas “facilonas”, el asunto del desarrollo informático al usuario no técnico me parece, sencillamente, una salvajada.

El desarrollo de software debería siempre apoyarse en herramientas sometidas a algún tipo de procedimiento de estandarización, sea una organización (ISO, ANSI...) o un proceso bien establecido (Java Community Process). Esto hace que los esfuerzos de desarrollo tengan una mayor extensión temporal. Tengo código desarrollado en Lisp, en C++ o en Java que sigue siendo útil después de diez, quince o veinte años. ¿Qué proyección temporal podemos esperar del código desarrollado en ASP o en las Microsoft Foundation Classes? ¿Que pasará si Microsoft se hunde en tres o cuatro años ante el fracaso con Windows Vista y el DRM? Bueno, no creo que esto suceda, pero como decía antes, torres más altas han caído.