Vaya por delante: si me dan a elegir entre código libre y código abierto, me suena mucho más atractivo lo de abierto que lo de libre. Pero confieso que, incluso después de haber estudiado un poco el tema, sigo sin tener muy clara cuál es la diferencia y cada vez que consulto listados de licencias de la Free Software Foundation y de la OSI me hago un lío más grande. Cortito que es uno, oiga.
Vaya por delante, también, que, por filosofía, tanto ‘open’ como ‘free’ me suenan mejor que ‘closed’ o ‘proprietary’, pero que tengo por casa copias legales de Windows XP, de Vista, de Microsoft Office y un buen montón de software de Adobe. De la misma manera que tengo corriendo algún Linux y copias de OpenOffice.org, The Gimp o Inkscape. A igualdad del resto de factores, me quedaré con la solución abierta/libre sobre la cerrada/propietaria. Y a falta de una cuenta corriente infinita, lo gratis suena más atractivo que lo comercial, también (aunque no, no confundo ‘free as in free speech’ con ‘free as in free beer’).
Viene la cosa porque releo las anotaciones de Isma (Richard Stallman: Free Software and Beyond) y Julià Minguillon (Be free, my friend) sobre la charla de Richard Stallman en el FKFT (que me perdí, cosas que pasan, a pesar de currar un par de días de voluntario en la conferencia) y me vienen a la cabeza diversas cosas.
La más importante, sobre todo, por una anotación que recoge Isma de lo dicho por Stallman: que la analogía con las recetas de cocina es la mejor para comprender las cuatro libertades del software libre. Ciertamente, ¿no deberían garantizarse universalmente las cuatro libertades de las recetas de cocina?
- La libertad de elaborar una receta, para cualquiera (libertad 0).
- La libertad de estudiar una receta y adaptarla a tus necesidades (libertad 1). El acceso al ‘código’ de la receta es una precondición para esta libertad.
- La libertad de redistribuir copias de la receta para ayudar al prójimo (libertad 2).
- La libertad de mejorar la receta y publicar tus mejoras, para que toda la comunidad se beneficie (libertad 3). De nuevo, el acceso al ‘código’ es una precondición.
Hablamos de comida y no creo que nadie me discuta que la cocina es tan esencial como el software para la humanidad (habría, incluso, quien llegaría a decir que la cocina es más importante…). Tampoco discutirá nadie que es vital (nunca mejor dicho) la existencia de un corpus de recetas libres y abiertas, amplio y bien documentado.
Y sin embargo, todos (o al menos todos los que vivimos en el primer mundo y disponemos de una renta digna) hemos ido alguna vez a algún establecimiento de comidas que vulnera impunemente las cuatro libertades y, de regalo, no revelaría los secretos de sus recetas ni a punta de pistola. Corre por ahí una cierta compañía de refrescos con burbujas que, de hecho, considera su principal patrimonio el ‘código fuente’ de una de sus bebidas. Y puede que sean malvados, pero a casi nadie se le ocurriría decir que lo son por no divulgar sus recetas…
Además, la existencia de este tipo de empresas y establecimientos no atenta contra ese vital recetario libre y universal. Si hasta hay una OpenCola… Y, curiosamente, que exista un modelo de negocio basado en las recetas de código propietario y cerrado tampoco impide que el negocio alrededor de las recetas abiertas y/o libres sea boyante, incluso en tiempos de crisis. Enciéndase la tele un día de diario hacia el mediodía y podrán presenciar el trabajo de diversos ‘gurús de la receta libre’ que publican con total alegría [parte de] su propiedad intelectual y se ganan muy bien la vida con ello. Me han comentado, además, que hasta en las librerías se pueden comprar cientos de libros que publican el ‘código’ de infinidad de recetas. Muchos restaurantes viven de la explotación del ‘recetario libre’ porque disponer de la receta y convertirla en un plato no son la misma cosa: aún teniendo la receta usada por el restaurante en casa existen múltiples razones para pagar por que te la ‘ejecuten’: ahorro de tiempo y esfuerzo, que la ejecución del cocinero del restaurante es mejor que la nuestra… Existen estimaciones, de hecho, que dicen que el negocio alrededor del recetario abierto/libre es mucho mayor que el que se ha formado alrededor del modelo cerrado/propietario: parece ser que las industrias de las materias primas y los utensilios sacan mucho más del que cocina recetas abiertas y libres en casa que de los restaurantes cerrados. Hasta existen modelos mixtos: instituciones que obtienen beneficios de su ‘recetario cerrado’ y que también lo hacen de la ‘liberación’ de recetas… Finalmente, sin que nadie se rasgue las vestiduras, son multitud los que toman una receta abierta, la modifican para mejorarla… ¡y no publican el resultado!
Impresionante, ¿no?
Existen diversos factores que contribuyen al buen funcionamiento de la cosa:
- Ni el recetario libre/abierto ni el cerrado/propietario están en peligro. Nada indica que vaya a dejar de hacer restaurantes ‘propietarios’ a medio plazo. Mientras tanto, el ‘recetario libre’ goza de indudable salud (comparativamente mejor en tiempos de crisis). Y tampoco tenemos monopolios. La oferta de establecimientos de cualquier tipo de comida es, casi intrínsecamente, no-monopolizable. Incluso si hablamos de comida rápida —que en ubicuidad sería comparable a sistemas operativos y suites de ofimática— el abanico de opciones cerradas/propietarias/abiertas/libres es mareante… Desafortunadamente, que esto sea así en el caso del software es, desde luego, más que discutible: aún sin hablar de programar, prefiero no saber qué porcentaje de la ‘comunidad informatizada’ podría sobrevivir sin el binomio cerrado y propietario de Windows más Microsoft Office. Parece que el ecosistema está ganando en diversidad con la cuota de mercado creciente de otras soluciones, tanto cerradas/propietarias (léase Apple) como abiertas/libres, aún siendo (¿todavía?) brutalmente minoritarias.
- Hay múltiples garantías de calidad. A pesar del ocasional brote de legionela, podemos confiar en las recetas, tanto si tenemos acceso a ellas como si no. Cuando vamos a comer a un restaurante, independientemente del tipo de recetario que use este, existen mecanismos para asegurar la calidad y fiabilidad, tanto formales y «oficiales» (inspecciones de sanidad), como motores de recomendación ‘sociales’ o «tradicionales» (los tradicionales serían, por ejemplo, las críticas de los medios de comunicación, y van con doble comilla porque qué puede ser más tradicional que las recomendaciones sociales, en este caso) y ‘reglas de sentido común’ más o menos universalizadas (si el establecimiento está sucio, no entramos; si un restaurante está lleno y el de al lado vacío, querrá decir algo). De nuevo, cosas que pasan mucho menos en el mundo del software: ¿quién garantiza la calidad del software? La espantosa (aunque comprensible) y casi universal falta de cultura y educación informática impide a la inmensa mayoría elegir con un mínimo criterio entre dos o más alternativas. Es para echarse a llorar que muy probablemente haya más gente capacitada para elegir entre el Porsche y el Ferrari que nunca se podrán permitir que entre Microsoft Office y OpenOffice.org. Lo que nos lleva a recordar que…
- Todo el mundo tiene una cierta idea de cocinar. Si hasta yo sé calentar pasta, oiga :-P. Todos sabemos interpretar el código de una receta, ejecutarlo e, incluso, adaptarlo a nuestras necesidades si falta un ingrediente o somos siete a cenar, y no cuatro. Hasta me atrevo a aventurar que son mayoría los que saben implementar sus mejoras a una receta, aún con las notables variaciones en aptitudes y formación para hacerlo (redistribuyan o no posteriormente esas mejoras). De nuevo, algo que no pasa con el código. Ni siquiera con la informática en general, como comentábamos antes.
Y todo esto me lleva a pensar que además de fomentar el desarrollo y uso de software de código libre y/o abierto, existen otras medidas tan o más importantes, a las que sería conveniente dedicar más esfuerzos que a la satanización del modelo cerrado:
- Luchar contra los monopolios. Aún limitándonos al software cerrado/propietario, no es sano que una solución tenga una cuota de mercado del 90%. Y soy de los que opina que debería hacerse todo lo posible, además, para que en cualquier campo de aplicación lo suficientemente amplio exista una opción libre/abierta. Si para ello deben usarse fondos públicos, adelante.
- Asegurar la calidad. Tantas cosas dependen del software… Una hoja de cálculo decide cuánto pagaré de hipoteca. Un par de líneas erróneas en el código de un alcoholímetro pueden resultar en una multa injusta o dar con los huesos de alguien en la cárcel (o dejar que siga circulando quien no debería). Un cambio de unidades mal hecho estrelló una sonda espacial contra Marte. Un signo cambiado en un programa de cálculo de estructuras puede matar. Un generador de números aleatorios mal ejecutado supone un problema para la seguridad de los que navegamos por la red, por no hablar del sistema financiero mundial. Ni el software abierto ni el cerrado están libres de pecado y tampoco hace falta ser alarmistas (de momento las cosas no nos van tan mal), pero hay que asegurar la calidad del software. Y eso implica procesos certificables en el desarrollo de software y, muy probablemente, en el caso del software cerrado, al menos la disponibilidad, limitada pero universal, del código fuente de prácticamente cualquier aplicación. El uso de estándares bien documentados es también uno de los hitos del camino de la calidad del software.
- Fomentar la cultura informática. ¿Hace falta que todo el mundo sepa programar de manera competente? Probablemente ni tan solo sea una meta alcanzable (cuando ningún sistema educativo garantiza, ni siquiera, que todos seamos capaces de jugar al fútbol de manera competente :P). Pero quizá sí deberíamos saber todos qué es un algoritmo y ser conscientes de la complejidad de desarrollar software. Y me parece de cajón que unas ciertas competencias informáticas/ofimáticas son imprescindibles para casi todos. Añadamos, además, que no podemos hablar de cultura informática si nos limitamos a una única solución. Sea del tipo que sea: claman muchas voces contra un sistema educativo dependiente de las soluciones cerradas de Microsoft, pero haríamos un flaco favor a aquellos a quienes enseñamos si nos limitáramos a las soluciones de Apple o erradicáramos el software propietario del currículo, si este es competitivo y la solución imperante en el mundo laboral. Por poner un ejemplo no canónico: ¿qué escuela de diseño se atrevería a trabajar solo con Inkscape y obviar la existencia de Illustrator? Y como con todo, educar en diversidad es muy difícil e implica sacrificios: el tiempo es finito y si no enseñamos una suite ofimática, sino dos, restamos del tiempo que podríamos/deberíamos dedicar a otros apartados del currículo…
Pues eso. Otro día más ;-).