Android se creó como un sistema operativo móvil de código abierto

y precisamente por esto cualquiera puede obtenerlo, clonarlo y crear su propio fork o versión alternativa. En el momento en que una empresa abraza el open source pierde el control total sobre este y la comunidad de desarrolladores adquiere una importancia vital. Pero el caso de Google con Android es digno de estudio. Como un perfecto caballo de troya, la expansión de Android ha propiciado un uso masivo de los servicios propietarios de Google.

Basándonos en este genial artículo de Ars Technica donde se planteó el debate, vamos a repasar un poco los puntos clave de como Google ha ido mejorando el código de Android pero del cual, ya que no todo es abierto, las mejores partes son precisamente aquellas que no han sido compartidas para trastear. Para El Androide Libre es un tema vital, que forma parte de nuestro origen y que cuando todo esto empezó no sabíamos como iba a evolucionar.

Licencia de corazón libre y evolución comercial

Si consultamos el FAQ sobre la licencia libre utilizada por Android encontraremos una justificación de por qué se encuentra bajo Apache2 en vez de GPL. Principalmente las licencias copyleft obligan a aquellos desarrolladores a distribuir su trabajo con el mismo tipo de licencia, limitando entonces la evolución del ecosistema para aquellos que quisieran exprimir la parte comercial de esta. Al contrario que el kernel de linux cuyo éxito es en parte gracias a la comunidad generada gracias a GPL, los de Google decidieron que Android ofrecería una experiencia más parecida a la de su archienemigo privado. La venta de apps a través de un market ha sido un mercado enorme y exitoso, por contra la lista de aplicaciones open source es bastante limitada en comparación.

El código de Android se puede encontrar fácilmente en la web, pero por contra encontramos problemas con los drivers privativos fundamentales que se necesitan para que todo funcione optimizadamente. Quéru denunció en su día que como era posible que uno de los productos estrella de Android no liberara los drivers de su GPU. Qualcomm terminó rectificando y ofreciendo a la comunidad los drivers de sus Snapdragon, pero aun a día de hoy seguimos sin poder aprovechar el Project Butter en algunos Exynos.

Para Google mientras que en sus dispositivos Nexus todo sea compatible no parece que se esfuercen por apretar las tuercas a los demás fabricantes para que liberen también sus códigos, y ahí volvemos otra vez a la diferencia entre la licencia GPL y la Apache.

No lo olvidemos, Google sigue y seguirá trabajando en mejorar Android (movimientos como la compra de Flexycore así lo certifican) y la idea para KitKat es crear una «experiencia extraordinaria para todo el mundo». Una manera de interpretar esta afirmación es asumir que se introducirán mejoras para los dispositivos con pocos recursos, tablets, TVs… pero otra vía es interpretarlo como que Google lo que en realidad quiere es que la experiencia para todo el mundo sea únicamente la que sus servicios ofrezcan.

Entendamos que Android pertenece a la Open Handset Alliance en la que Google es una de sus principales partes, pero no la única. Esta alianza no es sino los múltiples fabricantes que entre todos participan en el Android Open Source Project, el verdadero Android libre y al cual todos tienen acceso. Nos vamos a dar cuenta sin embargo que no es oro todo lo que reluce y que la diferencia entre el Android ideal para Google y el Android ideal para la comunidad es abismal.

Google Play Services; principal problema para AOSP

Hay que diferenciar las aplicaciones instaladas de fábrica del sistema operativo. Si alguna vez te has preguntado por qué en las ROMs había que instalar de manera separada las GApps de las aplicaciones base es porque las primeras pertenecen a Google y no son aplicaciones open source en mano de los desarrolladores. Google no quiere que nadie modifique sus servicios desde el principio, por lo que se optó ya hace tiempo de ofrecerlas en un pack separado de AOSP.

AOSP ofrece su propio material open source y ha desarrollado las aplicaciones propias como la del Calendario, música, buscador… pero aquí está el quid de la cuestión. El verdadero poder de Google en el sector móvil se basa en el control de las Google Apps, ofreciendo un servicio mucho mejor que su alternativa libre basada en la nube de información del buscador. 

Las GApps incluyen desde la aplicación de Gmail hasta la propia Play Store, y cuentan con una línea de diseño aparte de la de Android y con una clausula vital; si aceptas una, aceptas todo el pack. Si quieres tener acceso a GMaps entonces aceptas G+, si quieres acceso a la Play Store aceptas los pagos por Google Wallet.

La diferencia entre las aplicaciones de código libre que podemos encontrar en repositorios como f-droid o ROMS como AOKP de las nativas de Google es abismal. Hay una gran cantidad de trabajo detrás de las aplicaciones de AOSP, incluso la propia Google ha colaborado activamente en su desarrollo pero llegado un punto los de Mountain View convierten una apk básica y libre en un servicio que utiliza APIs propietarias mucho más completas.

Hay múltiples ejemplos de como Google maneja las aplicaciones:

  • En el Google I/O 2013, Google renovó su API de Localización para que formara parte de sus Google Play Services.
  • Las aplicación nativa de galería pasará a formar parte de G+ Photos como se ha visto en los rumores sobre KitKat.
  • Google Cloud Messasing (GCM) es la manera más fácil de sincronizar notificaciones entre Android, pero es un servicio que no veremos en las alternativas libres basadas en AOSP.
  • Android Payments se substituye por Google App payment.
  • Google Music era simplemente un reproductor hasta que se empezó a ofrecer la venta de música en la Play Store.

Google ha transformado cada una de las aplicaciones nativas; no es de extrañar que en el futuro veamos una aplicación del Reloj distinta, quién sabe si integrada con Google Now. El resultado de todo esto además es evidente; la alternativa libre no puede competir contra la app privada de Google. Como dice Ron Amadeo, Android es libre, excepto en las mejores partes.

No solo se trata de APIs abiertas contra APIs cerradas. Los desarrolladores tienen dos opciones diametralmente opuestas. La primera es aceptar las condiciones de Google y utilizar sus servicios con la idea de mirar pero no tocar. Podrás aprovechar la Play Store y algunos servicios como el de localización, que ofrecen una solución buena, barata y compatible, mucho mejor que casi cualquier otra opción. Por otro lado es posible que los desarrolladores quieran utilizar una solución independiente a costa de un gasto de recursos mucho mayor.

En muchos casos tendremos la espalda contra la pared, pues quién querría invertir horas de trabajo en algo que luego puede que Google no acepte en su sistema o incluso que al final por querer introducir una funcionalidad se tenga que aceptar el pack. El ecosistema de aplicaciones Android se está convirtiendo más bien en un ecosistema de Google, donde se rigen sus reglas y se utilizan sus servicios, que aunque mejores que la mayoría, siguen siendo suyos. Además Google es un padre exigente; aunque las nuevas versiones de Android estén optimizadas para bajos recursos las Gapps no lo están. De ahí que veamos esas tablets chinas corriendo Android pero sin acceso a GPlay.

Aquellos desarrolladores que abracen los Google Play Services tendrán la bendición de Google, pero ojo con aquellos que quieran tocar algo que se escapé de su ojo avizor, pues verán como el mundo bajo sus pies se desmorona a base de incompatibilidades. Solo unas cuantas empresas son capaces de gastar los suficientes recursos como para escapar de esta situación.

No lo llames Blootware, llámalo ecosistema propio

En el momento en que el fabricante de un smartphone quiere utilizar una app que no es open source debe pedir permiso a Google. Sería todo un sueño y un regalo monumental si Google licenciara sus aplicaciones, pero eso jamás lo veremos ya que hay millones de euros detrás de este ecosistema.

Esta es la razón de existencia de Touchwiz y equivalentes, no solo es una manera de reforzar la imagen de marca, en este caso de Samsung, sino de buscar una alternativa a los estrictos servicios de Google y por qué no, quitarle parte del beneficio económico.

A pesar de que Google ya sacó cosas para verificar las apps del sistema es muy común encontrarse con móviles con hasta tres aplicaciones prácticamente iguales. ¿Cuantas aplicaciones de correo has llegado a tener instaladas? ¿Qué diferencia las distintas aplicaciones de calendario? ¿Qué beneficios tiene S translator vs GTranslate?

El bloatware llega hasta niveles insospechados, casi ninguna aplicación libre acaba siendo la instalada de fábrica por el vendedor. Samsung, al igual que Sony y demás, nos ha vendido a través de su gama estrella toda una serie de servicios que nos hace olvidar a Google por un momento y que si nos pasamos a otra marca echaremos de menos. Esta pelea acaba de empezar, y a la vuelta de la esquina tenemos un Google Experience Launcher que estará para convencernos que aunque tengamos un Samsung no tenemos por qué utilizar sus apps propias. Una manera de hacer prevalecer otra vez la marca google pura incluso en las marcas de los otros. Y como no, este launcher vendrá de base en cada smartphone, teniendo que aceptarlo como parte del paquete de los Google Play Services.

¿Hacer un fork de Android es un buen plan B?

Algunas marcas están empezando a adoptar posiciones cada vez más fuertes. Otras no tienen problemas por ahora. Dudamos que Google haga la vista gorda en sus condiciones, y hasta el momento los miembros de la Open Handset Alliance tienen contractualmente prohibido crear una versión de Android no aprobada por Google. 

Un fork no es otra cosa que una versión alternativa, y no son pocos los interesados en crear un fork de Android. Actualmente existen varios ejemplos exitosos y lo interesante es que han surgido de formas e intenciones muy distintas.

  • Barnes & Nook creó una versión sin pretensiones de substituir las apps de Google, un fork concreto en la que Android era un sistema perfecto, estable y que ahorró gran cantidad de recursos a la empresa de lectores electrónicos.
  • Aliyun OS en China es un fork de Android creado por Alibaba (¿Yahoo?) que levantó la atención de Acer, sin embargo hubo un momento en que Google hizo público un post comunicando y excusandose de que ese proyecto debía cancelarse.
  • El siguiente es un poco más conocido por todos. Kondik, uno de los contribuidores de Cyanogen, se está tomando muy en serio la posibilidad de realizar su propio sistema operativo. Cyanogen no tiene permiso para distribuir el firmware propietario de Google, pero no es algo que les preocupe. Ellos están comprometidos con no pervertir el núcleo del sistema (aunque algunas partes sí serán privativas) y pretender añadir funcionalidades a Android que Google no se ha molestado en hacer, como una mejora en la seguridad gracias a una criptografía más fuerte. ¿Quién es al final el más interesado en que se potencie el núcleo de Android?
  • Y a continuación, el quizás único caso de éxito comercial de un fork de Android. Kindle OS es la respuesta de Amazon. Y se trata de la única compañía lo suficientemente potente y con un ecosistema en la nube propio como para poder sobrevivir sin las killer apps de Google. Amazon ha tenido que pelear duramente en numerosos aspectos para conseguir que avance su idea. Para crear su Kindle tuvieron que acudir a Quanta Computer, una empresa que al contrario que los demás fabricantes no estaba comprometido con Google y Android. Los rumores sobre la alianza de HTC y el smartphone de Amazon supondrían un revés para Google importante, aunque no estamos muy seguros de que lo mejor para HTC sea crearse más enemigos.

No solo es cuestión de hardware, para poder tener un servicio de localización alejado de Google, Amazon tuvo que pagar una tasa para conseguir los datos de los mapas de Nokia. Un perfecto ejemplo de como funciona todo. Google ofrece sus servicios gratis, pero las compañías prefieren pagar importantes tasas para mantenerse independientes. 

No todos tienen la suerte de tener un ecosistema como el que tiene Jeff Bezos. Mientras que Amazon es una máquina de copiar las apps de Google, Samsung por ejemplo es una empresa de electrónica. A pesar de eso muchos son los que pretender crear su propio fork de Android.

Un fork debe suponer un cambio radical, una alternativa suficientemente interesante como para justiticar no acogerse a Google Play. Millones de aplicaciones son instantáneamente compatibles con tu sistema, aunque no accesibles ya que se encuentran alojadas en los repositorios de Google. La base de usuarios se utiliza como reclamo para no querer irse por separado, pero son precisamente los usuarios los que al final decidimos con quién nos quedamos. Y este es un miedo innato para Google, el mayor temor es que se cree una alternativa lo suficientemente poderosa como para amenazar su dominio sobre Android. Parece fácil, solo hay que convencer a los desarrolladores de que corran sus apps en tu ecosistema, simple pero ardua.

El poder de la comunidad seguirá siendo el futuro de Google

Da igual cuantas veces una gran empresa intente controlarlo todo, al final serán los usuarios los que decidiremos que vamos a hacer. La existencia de Linux con tantos forks e ideas compartidas sería un gran modelo a seguir para Android. En los dos campos hay uno que destaca, Ubuntu y la versión googlificada, pero la diferencia es que mientras que Ubuntu sigue siendo la punta de lanza del software libre, Google ha aprovechado su liderazgo para cerrar filas entorno a sus servicios en vez de regalarlos al mundo. No hay nada que objetar, las empresas nunca han pretendido ser hermanitas de la caridad, y el «Don’t be evil» que siempre nombramos hace referencia una vez más que Google siempre va a aceptarte amablemente para que utilices lo que ellos con tanto cariño (e intenciones comerciales) han creado.

Si la fragmentación era uno de los problemas de Android era por culpa de que su compatibilidad era muy amplia. Llegar a todos los hardwares y GPUs distintas era una verdadero quebradero de cabeza para Google, de ahí que se pusieran manos a la obra. Los Google Play Services no son sino la versión «Nexus» en el campo del software. 

Los servicios de Google cuestan menos que nada. ¿Es posible que estemos justificando que una versión no libre es mejor? Nos gustaría pensar que no, pero la comunidad open source debe ponerse las manos a la obra para darle una vuelta de tuerca a la estrategia que Google presenta. El control de Google no se basa en un iTunes, sino en las diversas apps que ya manejan todo. Un programa de escritorio para manejar Android no tiene sentido, en el momento en que lo que Google controla de tu móvil son sus aplicaciones. ¿Qué fabricante vería con buenos ojos un programa así? De momento tenemos ya separados los propios «Ajustes» y los «Ajustes de Google» y lo que sí tendría sentido es un «Nexus Manager».

La llegada de los dispositivos «wearables» como las Google Glass puede ser el momento en que Motorola entre en acción. ¿Serán todos estos dispositivos creados bajo la supervisión de Google o también lo licenciarán a otros fabricantes? ¿Se convertirá Android en un sistema «invisible» que esté presente en todos los dispositivos? Las marcas se han adelantado y por ejemplo vemos como el Galaxy Gear solo es compatible con dispositivos Samsung. ¿Dónde queda Google en todo esto? El major peligro para Google es Samsung y su gama Galaxy. Y no solo por la marca coreana, sino por el precedente que pueda crear.

Otro sector del que parece que la estrategia se repite es en los Chromebooks. Fabricantes que utilizan un sistema operativo liviano y de moda y que a la larga se dan cuenta que han invertido demasiado en este y deben empezar a diferenciarse de la competencia. En Google son artistas en conseguir que los demás sean abanderados de su marca.

En definitiva, Android no fue creado para conseguir convencer a todo el mundo de las bondades del software libre, sino para poder ser utilizado por todos. Una filosofía, la de llegar a cuantos más mejor, que sí que es mucho más afín a la Google que conocemos hoy en día. Desde aquí esperamos que el núcleo de Android siga prosperando y los distintos fabricantes apuesten por quien les ha permitido ser parte de las líneas de código que definen uno de los sistemas operativos más importantes de todos los tiempos.

Photo: Aurich Lawson

 Source: Ars Technica

ACTUALIZACIÓN: A través de Twitter me ha llegado un contrapost donde se rebaten ciertos argumentos presentados aquí. El artículo en cuestión es de parte de @jcdev90. Se menciona principalmente dos puntos; el primero es básicamente que el papel de Google en el desarrollo de AOSP es mucho más importante del explicado. El segundo punto es sobre los requisitos que pide Google para utilizar sus servicios; yo argumenté que era una razón técnica, cuando en realidad aquellos fabricantes que no adoptan los GPlayServices lo hacen por una razón más bien económica. En los dos puntos estoy de acuerdo y me ha parecido importante señalarlo en este post con una pequeña actualización. Agradezco profundamente este tipo de aportaciones y me encanta que se genere un debate entorno al post.