Parece mentira que entrados ya en 2014 se esté montando la que se está montando entorno a Android y al concepto que parece estar en la mente de muchos respecto a su apertura. O más bien, a su pseudo-apertura, como explicaremos en las próximas líneas.
Porque por si no lo sabíais, Android no es tan abierto. Lo más gracioso es que esto ni siquiera es noticia. Ya era una realidad cuando Google creó esta plataforma en 2007, aunque lógicamente era mucho más interesante darle todo un aire de apertura total (el nombre de aquel primer organismo, Open Handset Alliance, es un buen ejemplo) para promocionar aquellos inicios.
Un punto de partida
Antes de hablar de la apertura o no apertura de Android y debatir sobre la forma en que Google gestiona este desarrollo, conviene aclarar ciertos términos que utilizaremos a lo largo del artículo.
En primer lugar, y aunque lo comentaré durante el artículo, entiendo que Android es una plataforma móvil, no un sistema operativo. Lo confirma la propia definición de esta solución en el sitio web de los desarrolladores de Android, en el que se la califica --con razón-- como "la plataforma móvil más popular del mundo".
Esa plataforma está compuesta por el sistema operativo como tal, cierto middleware (servicios y soluciones que conectan los componentes de Android), y también una serie de aplicaciones móviles de Google. Así, tendríamos una base que tiene como pilar el Android Open Source Project (AOSP), a la que se sumarían los Google Mobile Services (Google Play, Google Maps, Google Now, por ejemplo) y las Google Apps (Gmail, Google Drive, Google Keep, por ejemplo).
Precisamente la base de la plataforma Android es el citado AOSP, un proyecto en el que colabora la comunidad de usuarios y que ofrece una alternativa a la plataforma como tal, aunque la propia Google es la principal responsable de la gestión y desarrollo del proyecto.
AOSP podría considerarse como una plataforma abierta en sí misma, ya que además del sistema operativo móvil ofrece algunas aplicaciones nativas que permiten por ejemplo reproducir música, realizar y recibir llamadas o sacar fotos con el móvil o tablet que estamos manejando.
La polémica se desata
Empecemos con realidades. Visitad el sitio web oficial de Android y contad las veces que aparecen las palabras Open Source. Cero. Niente. Null. Zero. Solo si nos vamos a la zona que ellos llaman "Partners" se nos redirigirá al sitio web del Android Open Source Project (AOSP), que como comentaremos más adelantes sí es un proyecto abierto y libre. Hasta Google lo deja claro en sus sitios web oficiales, así que ¿qué está pasando?
Los acontecimientos se han precipitado en las últimas semanas y meses. El mercado de la movilidad se ha visto sacudido por la formación de nuevas grandes alianzas y acuerdos. La compra de Nokia por parte de Microsoft fue un primer paso importante de la industria, a los que luego han seguido la adquisición de Motorola por parte de Lenovo y el sospechoso (por su anuncio inmediato tras el de la venta de Motorola) acuerdo entre Google y una Samsung que parecía apuntar a una salida del redil de los de Mountain View.
Todo parecía ir dirigido a consolidar el dominio de los grandes del mercado y a eliminar a los pequeños actores. A priori lo de Google parece una jugada maestra: se deshace de una parte de negocio que no le interesaba (Motorola como fabricante) y refuerza la alianza con el que hoy por hoy es el dominador absoluto del panorama Android (Samsung).
Tizen, que parecía un plan B con ciertas opciones, parece no tener ya tanto sentido en móviles --aunque un reciente anuncio podría reimpulsarlo-- y los consumidores (en líneas generales) parecen haber demostrado que cuando van a las tiendas solo quieren dos opciones: o Android, o iOS.
De hecho esa omnipresencia de Android ha hecho que aparezcan todo tipo de rumores e ideas (alocadas y menos alocadas) sobre lo que deberían o no deberían hacer los grandes del mercado. Woz comentó (aunque luego lo clarificó) que Apple debería apostar por un móvil Android, Nokia tiene ya a punto de caramelo su célebre Nokia Normandy y la puntilla llegó esta semana, cuando se conoció que al parecer Microsoft está "considerando seriamente" la posibilidad de ofrecer aplicaciones Android en Windows Phone.
Las cosas fueron más allá tras el nombramiento de Satya Nadella como nuevo CEO de Microsoft. Entre los análisis tras ese nombramiento destacó una de The Guardian, que le aconsejaba al recién ascendido Nadella que echara Windows Phone a la basura y que crease un fork de Android.
Las respuestas no tardaron en llegar, y la más destacada provenía de un incenciario artículo en Ars Technica en el que su autor, Peter Bright, explicaba por qué según su opinión ni Nokia ni Microsoft deberían plantearse un fork de Android.
Aquel artículo encendió un interesante debate en los comentarios, sobre todo por la participación de Dianne Hackborn, ingeniera de Google en el equipo de Android, y que respondía a todos y cada uno de los argumentos esgrimidos por Bright. El debate se mantendría entre ambos sin que ninguno cediera en sus posturas, y lo más curioso es que ambos tenían razón. Al menos en parte.
Y así estábamos todos, disfrutando de esa guerra dialéctica, cuando de repente apareció la noticia de The Wall Street Journal en la que se indicaba un súbito interés de la Comisión Europea por los términos de uso de Android. Seis años y medio después de la creación de esta plataforma. ¿No llega la UE un poco tarde?
Lo que todo el mundo entiende por Android no es abierto
Según el Journal, "las autoridades antimonopolio europeas están examinando esas condiciones, entre otras, ya que consideran que Google podría haber abusado de la posición de Android como sistema operativo líder en smartphones". Entre otras cosas (o más bien, sobre todo), porque impone su motor de búsqueda --ese que la da buena parte de sus ingresos por publicidad-- en todo smartphone que quiera tener acceso a todas las facilidades que la plataforma Android ofrece.
La Unión Europea podría actuar con Google y Android como ya lo hizo por ejemplo con Microsoft y su Internet Explorer, forzando a que los usuarios europeos dispusieran de una nueva ballot screen, pero esta vez de buscadores en el móvil, suponemos.
El problema es que muchos no parecen comprender que las prácticas de Google no son --como decíamos-- ni mucho menos nuevas, aunque esa dependencia de las aplicaciones y servicios móviles de Google se haya acrecentando en los últimos tiempos.
Lo explicaban muy bien ayer en GigaOm, en un artículo en el que en mi opinión solo cometían un error: seguir repitiendo que Android es abierto. No lo es.
Android es una plataforma móvil compuesta por una base que efectivamente es abierta y libre (AOSP), y una serie de aplicaciones y servicios móviles (Google Mobile Services y Google Apps) totalmente cerradas y propietarias. Y son precisamente esas aplicaciones y servicios las que dan acceso a unas prestaciones muy demandadas por los usuarios y por los fabricantes. La tienda Google Play, los mapas de Google Maps, la sincronización de servicios Google como el correo (Gmail) o el almacenamiento online (Drive), y los cada vez más importantes Google Play Services (APIs y servicios de sistema) que engloban a todas esas opciones son buenos ejemplos.
Cualquier fabricante puede meter AOSP en su teléfono móvil, y en esencia dispondrá de un dispositivo funcional. Ahora, si quiere acceder a los servicios de Google, tendrá que asumir los términos de Google y sus requisitos (ciertas especificaciones hardware, por ejemplo), además de pasar una validación técnica de Google.
No solo eso: aunque Google afirma que las aplicaciones y servicios móviles son gratuitos, esa validación no lo es, y se estima que los fabricantes pagan 0,75 dólares por cada dispositivo licenciado (o validado, que es el término usado en Google).
Google por supuesto no hace pública esa información, y para el común de los mortales todo es de color de rosa para los fabricantes. El mito de la libertad que ofrece Android --"los fabricantes pueden modificarlo a su antojo, es un sistema operativo libre y gratuito, blah, blah, blah"-- se convierte como por arte de magia en realidad para muchos usuarios. El problema al que se enfrenta Google es que en los últimos tiempos esa fantástica imagen de apertura total de Android se está empañando por la salida a la luz de diversos datos sobre las prácticas que Google impone a los fabricantes.
A Google, como a otras, le encanta el control
Muchos nos quejamos de una Apple que se obstina en tener el control absoluto de nuestros dispositivos y sus plataformas software. Sin embargo ese control es algo que en menor o mayor medida esgrimen todas las empresas del mundo, y Google, desde luego, no es una excepción al respecto.
Ese control es patente en la plataforma Android. Como explicaba Peter Bright en su artículo en Ars Technica, hay cuatro formas de integrar Android en un dispositivo móvil:
La primera es la forma en la que Google realmente quiere que las empresas usen Android: dependiendo tanto de AOSP como de GMS (Google Mobile Services). Que pasen la certificación y se incluyan todos los servicios y aplicaciones de Google. Eso es lo que empresas como Samsung, HTC y LG hacen. Seguir ese camino proporciona ciertas opciones de personalización para los OEMs. Estos OEMs pueden proporcionar sus propias aplicaciones para que se preinstalen con las de Google, por ejemplo. Parece que Google no está del todo contenta con esto --hay informes de que la empresa firmó recientemente un acuerdo con Samsung por el que Samsung reduciría la cantidad de personalización de la interfaz de usuario y despriorizaría o eliminaría las aplicaciones que competían directamente con las aplicaciones equivalentes de Google. Seguir ese camino proporciona la mejor compatibilidad con aplicaciones de terceras partes al asegurar que estas tienen disponibles las APIs tanto de AOSP como de GMS. También proporciona la experiencia más consistente: a pesar de las diversas personalizaciones realizadas, esto significa que las aplicaciones de Google estarán disponibles, y que esas aplicaciones funcionarán del mismo modo en cualquier dispositivo AOSP+GMS. También hace que se ceda casi todo el control a Google, y hará que ese nivel de control no haga más que crecer. Cada nueva versión incrementa el nivel de integración con los servicios propios de Google, y Google está migrando más y más funcionalidades a GMS, convirtiendo a AOSP como cada vez más como una simple carcasa.
Obviemos de momento el resto de formas de integrar Android. De hecho, solo nos interesará una más, en la que incidiremos más adelante. La explicación de Bright es clara, y la propia Dianne Hackborn, que respondía a sus afirmanciones, no negaba la evidencia:
Android, como plataforma Open Source, simplemente es incapaz de ofrecer ningún servicio en la nube, porque esos servicios no se ejecutan en el dispositivo donde el código de la plataforma corre. Este es un punto clave que parece ser olvidado completamente. Si quieres entender lo que es Android, y cómo está diseñado, y cómo las piezas encajan, debes entender este punto. Una de las cosas que es interesante sobre las plataformas actuales y el escritorio tradicional es que estos servicios en la nube son cada vez más importantes sobre la experiencia de la plataforma base. Esto presenta un reto muy especial a una plataforma Open Source, que no puede proporcionar estos servicios en la nube como parte de la implementación estándar de la plataforma. En Android nuestra solución es diseñar la plataforma de modo que los servicios en la nube puedan conectarse e integrarse de diversas formas.
Tremendo. Hackborn tiene un argumento poderoso, pero no hace más que justificar el propio argumento de Bright, concediendo que, efectivamente, el que quiera utilizar los servicios de Google --que según esta ingeniera "son más importantes que la plataforma base"-- debe asumir esos términos.
Cómo logra Google controlar cada vez más la experiencia Android
Si esos argumentos no os logran hacer entender la solución, tengo otra propuesta para vosotros: la de que una imagen vale más que mil palabras. Si me apuráis, vamos más allá y elijamos más de una imagen. La propuesta no es en realidad mía, sino que de nuevo es mérito de un análisis que hicieron una vez más en Ars Technica.
El análisis de octubre de 2013 de Ron Amadeo era aún más contundente y reforzaba la reflexión (por llamarlo de algún modo) de su compañero Peter Bright. En un recorrido por la evolución y situación actual del proyecto AOSP y Android quedaba patente la estrategia de Google para hacernos cada vez un poquito más dependientes de Android.
La técnica es magistral. Cuca, yo diría. Google, por supuesto, no habla mucho de ello públicamente, y cuando lo hace lo que parece salir a la luz es que ha hecho grandes progresos en nuevas versiones de Android, pero donde en realidad los hace es en los Google Mobile Services y en las aplicaciones Android. Yep. Esas que son cerradas y propietarias, y sobre las que Google tiene todo el control.
Vamos con los ejemplos que proponía el artículo. El primero, el de las búsquedas tal y como se ofrecen actualmente en AOSP, y cómo se ofrecen en la última versión de Android. Mientras que la búsqueda de AOSP se limita a la búsqueda en el dispositivo local y en Internet, la potencia de Google Now (búsquedas por voz y nueva interfaz incluida) demuestra lo mucho que ha avanzado la empresa de Mountain View... en su aplicación propietaria.
Segundo ejemplo. Reproductor de música. La presentación de Google Play Music en Google I/O 2010 supuso el principio del fin para la aplicación de música de AOSP, que hoy en día se comporta como una aplicación Froyo. Mientras tanto, en Google Play Music tenemos almacenamiento en la nube, tienda online y opción de suscripción, además de soporte Chromecast o ecualizador.
El teclado de Google para Android también ha ganado muchos enteros respecto al de AOSP. Cosas como el soporte para escribir "en modo Swype" se sitúan como otra de las diferencias claras entre ambas vertientes de un desarrollo que en Android también se ha seguido cuidando mucho.
Por último, la mensajería, un apartado que Google desveló más recientemente y que ha hecho que Hangouts se convierta en una aplicación mucho más ambiciosa. Las diferencias con respecto al cliente integrado en AOSP no son tan evidentes aún... pero a buen seguro lo serán en el futuro.
Ese repaso de la realidad de Android y sus técnicas de control no se limita a las aplicaciones, y recorre las tácticas cucas que Google también ha empleado por ejemplo en la API de Google Maps, que es parte de GMS y no está accesible a AOSP de forma directa. De hecho, explican en Ars, Amazon "tiene que o bien pagarle licencias a Nokia para siempre (para usar sus mapas) o bien salir a la calle y cartografiar el mundo entero por su cuenta". Algo similar ocurre con la plataforma de mensajería, la API de geolocalización o otro apartado crucial: la API Play Games, totalmente propietaria pero que facilita la vida enormemente a desarrolladores y usuarios a la hora de disfrutar de los juegos. Olvidaos de ella en AOSP.
Un fork completo de Android es posible, pero muy, muy complejo
Ya hemos visto como Google hace que utilizar Android bajo sus condiciones sea, como diría Yoda, "más rápido, más fácil, más seductor". Eso no significa necesariamente que no pueda haber alternativas que se basen en Android. Crear una plataforma propia basada en Android (o más bien, en AOSP) tiene como resultado uno de los famosos forks.
Amazon es el claro referente en este punto: sus tablets Kindle Fire han ofrecido desde sus inicios un fork de Android que integraba su propia tienda de aplicaciones, además de varias aplicaciones y servicios que ofrecen alternativas a los que Google proporciona en Android. Amazon también ofrece sus propias alternativas a APIs como la de Google Maps, pero que como indica Bright no puede mantener el ritmo de desarrollo y dedicación a su fork que Google mantiene con Android, lógicamente.
¿Podría entrar Microsoft en ese juego? Por supuesto. Como apuntaba Bright:
Técnicamente, sin embargo, una empresa con suficientes recursos de desarrollo podría proporcionar su propio sustituto de los Google Mobile Services. El trabajo extra no sería insignificante, ya que --sobre todo para asegurar una compatibilidad óptima esa alternativa tendría que replicar no solo un correcto funcionamiento, sino también los conflictos y defectos de la implementación GMS.
Sobre este caso particular opinaba también recientemente Ben Thompson en su (cada vez más) conocido blog Stratechery, en el que entre las posibilidades que Microsoft tenía en el segmento móvil estaba, desde luego, la de crear un fork de Android "con servicios de Microsoft, una tienda de aplicaciones y, lo más importante, protección de patentes a los fabricantes chinos".
Este punto es importante ya que como comenta Thompson, uno de los aspectos menos comentados del acuerdo entre Lenovo y Motorola es el hecho de que en ese acuerdo se incluyen licencias cruzadas para utilizar patentes de Motorola. Sin esas licencias, explica este analista, el coste de los royalties haría insostenible la infraestructura de costes de Lenovo.
Esa era la razón de que Lenovo solo hubiera vendido smartphones "en países con una protección legal pobre de la propiedad intelectual. Las patentes de Motorola les permitirán salir fuera (de China) de una forma mucho más competitiva", explicaba Thompson.
En ese fork de Android realizado por Microsoft también tendría especial relevancia esa tienda de aplicaciones de la que también habla este experto, y que simplificaría mucho la vida de los desarrolladores. Solo tendrían que cambiar un par de líneas de código para publicar esas "aplicaciones Android" en la tienda de Microsoft en lugar de (o además de) en Google Play. Y como apunta al final, a los desarrolladores "les encantaría el hecho de que ya no tendrían que dar soporte a una plataforma que ni siquiera se ha acercado a ofrecer un retorno de la inversión".
Hay alguna otra alternativa de interés, y por ejemplo tenemos el análisis que nuestros compañeros de Xataka Android realizaron sobre Replicant, una ROM derivada de Android que tiene precisamente el objetivo de ofrecer una alternativa completamente abierta. El proyecto es valiente, pero se enfrenta a obstáculos serios (drivers, soporte de terminales, no hay acceso a las citadas aplicaciones y servicios de Google) que obviamente pueden echar atrás a muchos usuarios.
Conclusión: Android no es para lloricas
Por mucho que durante todo este texto hayamos explicado las formas en las que Google se asegura (cada vez más) el control de Android y de los fabricantes que quieren utilizarlo, lo cierto es que sus prácticas, como decíamos, ni son nuevas, ni son esencialmente "diabólicas".
Google es un negocio, y como tal busca rentabilidad y beneficios. Es normal que intenten hacer todo lo posible por maximizar esos beneficios, y en ese esfuerzo el desarrollo de unos servicios móviles y de unas aplicaciones cada vez mejores y que "aten" a fabricantes y usuarios está absolutamente justificado, como también lo están los esfuerzos de Apple, Microsoft o Amazon, que defienden sus intereses.
Por supuesto, hay formas de hacer las cosas, y Google ha demostrado una forma discutible de, como mínimo, publicitar esos cambios. Y sin embargo nadie puede negar que ninguna empresa ha hecho lo que Google: AOSP es una plataforma móvil real y funcional. Puede que no la más actualizada en diversos apartados y servicios (como hemos visto), pero sí una de las pocas formas que un fabricante (e incluso un chaval con curiosidad) pueda hacer que su hardware móvil tenga funcionalidades básicas realmente decentes.
Esa es la realidad. El tuit de Russel Holly (editor en Geek.com) que citaban en GigaOm es casi perfecto:
One sentence.
Android is open, but if you want to play in Google's sandbox you have to follow their rules.
How hard is that?
— Russell Holly (@russellholly) febrero 13, 2014Como dice Holly, "Android es abierto, pero si queréis jugar en el patio de Google, tenéis que seguir sus reglas" Un resumen casi perfecto, salvo por el hecho de que Android (como plataforma) no es abierto. Solo su parte AOSP.
Se podría decir de otro modo: Android no es para lloricas. Si vais a disfrutarlo (o estáis disfrutándolo), asumid que Google es una empresa. Si no, sois (somos) totalmente libres de elegir otra alternativa que nos convenza más.
Ver 94 comentarios