El reciente anuncio de Google Chrome OS pone de manifiesto como pocos la problemática. Google confirma que Chrome OS será open source. Pero... ¿acaso importa mucho, cuando GChOS no es más que un cascarón, un canvas donde renderizar las verdaderas aplicaciones, que residirán en los servicios de la "nube" de Google? El problema ya no es tanto el código, como el control de los datos. Google lo sabe. ¿La comunidad del software libre es consciente?
Tal vez algunos piensen que no hay problema. Que el software libre tiene ya multitud de webmails para hacer frente a Gmail, y que Google Docs puede ser sustituida por cualquier suite ofimática en local. Que, de hecho, las aplicaciones web pueden ser sustituidas por aplicaciones standalone. La realidad que yo veo es bien distinta. Cada vez más gente usa los servicios y aplicaciones web por comodidad. Cada vez más gente prefiere tener el correo en Gmail. Y cada vez surgen y se construyen más aplicaciones --y más potentes-- aprovechándose de los servicios ya existentes y los servicios de "nube".
La "nube" no puede ser replicada localmente, ni por potencia de cálculo, ni por capacidad de almacenamiento, ni por la complejidad que pueden alcanzar los algoritmos basados en la realimentación de grandes cantidades de datos generados en tiempo real por los propios usuarios que emplean dichos servicios/aplicaciones.
En el software, una vez abandonado el concepto de "software como producto", y reconvertido en "software como servicio" (SaaS), lo importante es la disponibilidad del mismo. Lo importante es el mantenimiento más simplificado, reducido a su mínima expresión. Lo importante es la actualización constante y transparente. Con esos parámetros en mente, es lógico que caminemos de vuelta hacia la computación centralizada, donde los ordenadores de los clientes son meras terminales (en este caso, un sistema operativo + un navegador y poca cosa más, que es el concepto que hay tras Google Chrome OS), y donde todo el trabajo duro se realiza por unos pocos técnicos superespecializados en los datacenters de la nube, y por aplicaciones cada vez más complejas, basadas en esos servicios.
El hecho además, converge con el abaratamiento y la popularización de las terminales: para acceder a la nube ya no es necesario un hardware caro: con un notebook, incluso un smartphone es suficiente. Dejamos de hablar de hardware en el entorno de los 1.000 dólares para pasar a hardware en el entorno de los 100 dólares (a grosso modo). Imagináos el impacto en los países emergentes, muchos de los cuales con gran población. Simplificación del hardware unido a precios más baratos implica una mayor disponibilidad, por lo que es fácil trazar el tremendo potencial de crecimiento del concepto de "nube" (y potenciales los beneficios de quienes la controlen).
El reto del software libre en la nube
En este estado de las cosas... ¿cual es el reto que la comunidad del software libre debe plantearse? ¿Cual debería ser su objetivo? Hay que decir que la comunidad no tiene los ojos cerrados, todo lo contrario. Prueba de ello es que va a ser uno de los temas estrellas de la próxima OSCON (a celebrarse dentro de 15 días):
El reto está centrado específicamente en dos asuntos complejos: (a) las licencias tradicionalmente usadas para proteger la libertad del usuario (las copyleft) fallan al tratar de proteger la libertad de los usuarios de SaaS, y (b) incluso si los usuarios tienen el código fuente de la aplicación que están usando, no pueden ejecutarla ellos mismos y generar el mismo efecto-red disponible en la instancia canónica.
Para la parte (a) han surgido licencias como la Affero GPL y la GPL versión 3. Pero estas licencias no son suficientes, porque como mucho garantizan la libertad del código fuente, pero no de los datos. Y hay quien ya considera que los datos libres son más importantes incluso que el código libre.
En este sentido, Tim O'Reilly lleva ya tiempo avisando de que el auténtico foco de interés se ha desplazado del software en sí mismo, a los atributos que lo caracterizan: abierto y basado en la colaboración de una comunidad. En su entrada sobre 'Open Source and Cloud Computing' dice:
Pero centrar la atención en exclusiva en la computación en la nube no es el asunto. El asunto es redescubrir que hace funcionar al open source, pero en el nuevo contexto. Es importante reconocer que el open source tiene varias dimensiones claves que contribuyen a su éxito:
- licencias que permiten y fomentan la redistribución, modificación e incluso la división (forking);
- una arquitectura que permite usar programas como componentes dondequiera que sea posible hacerlo, y extendidos en vez de reemplazados con el fin de proporcionar nueva funcionalidad;
- una baja barrera de entrada a los nuevos usuarios que quieren probar un software;
- una baja barrera de entrada a los desarrolladores para construir nuevas aplicaciones y compartirlas con el mundo.
[...] no creo que sepamos que tipo de licencias nos permitirían hacer un fork de una aplicación Web 2.0 o de nube, especialmente cuando el bloqueo de muchas de estas aplicaciones se basa en sus datos más que en su código. [...] open source sin open data es sólo la mitad de la aplicación.
Pero incluso la importancia de los datos abiertos se relativiza ante la idea de la utilidad de la computación en la nube. Si es cierto que [...] "la Web 2.0 es aparcería digital" [...] será aun más cierto en la cloud computing como infraestructura. Soy cada vez más consciente de lo que dictó Debra Chrapaty (VP de Microsoft Windows Live): "En el futuro, ser un desarrollador en la plataforma de alguien significará estar alojado en su infraestructura".
Podemos hablar todo lo que queramos acerca de datos abiertos y servicios abiertos, pero francamente, es importante darse cuenta de cuanto de lo que es posible hacer está dictado por la arquitectura de los sistemas que usamos.
[...] Así que aquí va mi primer consejo: si estás preocupado acerca del open source para la nube, construye sobre servicios que estén diseñados para estar federados más que centralizados.
Pero las arquitecturas peer-to-peer no son tan importantes como los estándares y protocolos abiertos. Si se obliga a que los servicios interoperen, se preserva la competencia.
Así que lo importante no es discutir si la cloud computing es la conclusión natural del open source software o el desafío que amenaza con convertirlo en irrelevante, sino cómo encaja el modelo open source en el modelo de cloud computing.
Una de las propuestas consiste en homogeneizar las distintas nubes privadas en una sola Nube abierta e interoperable. Esta es la idea que hay detrás del Open Cloud Consortium. Entonces la comunidad del software libre "aceptaría la Nube como la nueva plataforma Hardware/Software, y en vez de construir aplicaciones sobre la plataforma x86 (Wintel, Mac...),lo haría sobre las APIs de Amazon Web Services o Google AppEngine. Y estas aplicaciones manejarían la portabilidad de datos de forma que los datos no quedaran atrapados en la Nube." [*].
Otro enfoque diferente puede ser crear una nube "open source". O si preferís: servicios libres. Tim O'Reilly hablaba en su artículo de arquitecturas peer-to-peer y sistemas federados, y ponía como ejemplo a identi.ca como alternativa a la omnipresencia de Twitter en el campo del microblogging. La FSF lleva años con el proyecto Savannah, iniciado como una alternativa a SourceForge (ahora también a Google Code y Launchpad). Ya he hablado recientemente de Kune, un proyecto con clara vocación de servicio libre. Pero todos estos proyectos, aunque ambiciosos, no dejan de ser tímidos y desacoplados, un "ejército de Pancho Villa" haciendo cada uno la guerra por su cuenta, cada cual en su pequeña parcela, y lejos de formar el equivalente (ni remotamente) a una nube comercial.
¿Qué haremos cuando, como decía antes el VP de Microsoft, desarrollar para una plataforma sea estar alojado en alguna infraestructura? ¿Existirá una infraestructura libre sobre la que construir servicios libres? ¿O se tendrá que construir sobre la infraestructura que nos ofrezcan los grandes jugadores, con las condiciones que ellos impongan?
Tal vez no esté de más recordar que el proyecto ecolNet* surge precisamente como un intento de proporcionar una infraestructura libre, independiente de la "caridad" de las empresas, a proyectos de software libre, basado en el hardware y mantenimiento de voluntarios. Se podría decir que era una "proto-nube", en la web 1.0, cuando las nubes no existían. Tal vez sea un espíritu a recuperar.
El DNS es un ejemplo de servicio libre, basado en una arquitectura distribuida y federada, unida mediante un protocolo estándar abierto (o tal vez lo fuera si no existiera el chanchullo montado en la cúspide --los root servers-- y el negocio derivado de ello de la venta de dominios).
Otra alternativa de infraestructura libre puede venir desde el sector público. Recientemente Javier de la Cueva comparaba la actuación del ayuntamiento de Nueva York respecto a creación de estándares de datos abiertos para la presentación de los datos frente al comportamiento que tiene Red.es con los mismos, y si bien está claro que la administración norteamericana está a años-luz, no sólo en transparencia sino en comprender lo que significa el concepto de "función pública", respecto a la(s) nuestra(s), tampoco hay que perder la esperanza de que, aunque sólo sea por copiar a Obama, puedan llegar hasta aquí ideas como el impresionante proyecto Data.gov, que despierta en mí la más pura de las envidias. Sobre esas infraestructuras públicas de datos abiertos pueden (y de hecho se están haciendo) construir servicios al ciudadano, por lo que ofrecer una infraestructura libre para que no haya que pasar obligatoriamente por un "vendedor" es un paso bastante natural, que no puede ser descartado.**
En cualquier caso, la cada vez más importante presencia --omnipresencia-- de la cloud computing, el impacto que puede tener a la hora de concebir el software libre, y los servicios libres son asuntos que tenemos ya encima de la mesa, y que vamos a seguir teniéndolos encima durante los próximos años, nos guste o no. Y algo habrá que hacer al respecto.
--
* Por cierto, es un poco WTF que el documento no esté accesible dentro del propio dominio escomposlinux.org, o al menos yo no lo he encontrado
** Soy consciente que, en este caso concreto y por estos lares, es posible que esté pecando en exceso de optimista e inocente...