Aquí va uno de esos artículos que mi querida compañera Anna introduce como «voy abriendo el paraguas». Son esos posts susceptibles de que a uno le caigan palos pero pienso que es bastante necesario. Hoy voy a contar por qué lo que se conocen como forks de Android no lo son tal sino que son ROMs. Alguno dirá, llegado a este punto, que si se me ha ido la cabeza pero no. Al menos creo que no, no recuerdo haber oído voces hasta ahora. Lo juro. Podríamos decir, citando ejemplos bastante reconocibles, que Fire OS puede ser un fork pero MIUI es realmente ROMs de Android y no un fork propiamente dichos. La línea es difusa. Lógicamente, ahora toca argumentarlo todo con datos y con parte de opinión. Porque en todos los asuntos polémicos, la opinión tiene un peso específico. Voy a intentar explicarme.
¿Qué es un fork?
Creo que habría que empezar por aquí. Fork significa bifurcación y también tenedor, pero citemos algunas fuentes de prestigio y también la Wikipedia. Disculpadme el chascarrillo pero encuentra uno cada cosa en la Wikipedia que dan ganas de dejar este planeta en la próxima nave disponible.
Según la Wikipedia, un fork o bifurcación de software es lo siguiente:
«Una bifurcación (fork en inglés), en el ámbito del desarrollo de software, es la creación de un proyecto en una dirección distinta de la principal u oficial tomando el código fuente del proyecto ya existente. Comúnmente se utiliza el término inglés. Como resultado de la bifurcación se pueden llegar a generar proyectos diferentes que cubren necesidades distintas aunque similares.»
Si nos fijamos en nuestros compañeros de Android Central, su definición de fork es bastante similar a la anterior aunque con matices ya que se desarrolla el concepto de facciones. Vamos a ver:
«El forking, o la bifurcación de software, se inició hace unos 20 años y se producía cuando un equipo de programadores se dividía en dos facciones debido a que tenían una visión separada de por dónde debía seguir el desarrollo de un código.»
Es decir, se coincide en ambos argumentos en algo bastante claro. Un fork o bifurcación se inicia en un punto común y a partir de ahí surgen dos desarrollos que pueden discurrir de forma más o menos paralela. Luego, por tanto, un fork debería dar como resultado dos sistemas operativos distintos que se fuesen separando más y más en el tiempo.
Un fork debería dar como resultado dos sistemas operativos distintos.
¿Qué ocurre entonces con los forks en Android?
Una vez que sabemos esto podemos poner en seria duda que lo sean realmente. De hecho, se comportan más como ROMs. Android es un proyecto de código abierto, el tan manido término Open Source que ya tenemos hasta en la sopa. Android, de hecho, surgió a partir de Linux. Linux a partir de UNIX y UNIX a partir de la mente de sus creadores. Como proyecto de código abierto, cualquier desarrollador puede tomarlo y crear lo que desee a partir de él pero entonces se corre el riesgo de perder algo bastante fundamental en todo este asunto: la compatibilidad.
La compatibilidad es la clave de todo este embrollo porque nadie quiere perderla. La compatibilidad en aplicaciones, claro está. Con el concepto de fork en la mano podríamos decir que tanto Fire OS como MIUI, y metiendo en el saco a Flyme OS de camino (además de otros no mencionados porque no cabrían en el artículo) son tales pero en realidad sufren lo mismo que le tocó sufrir a Bill Murray: el día de la marmota. La clave de un proyecto divergente es que sea divergente. Si vuelves constantemente a la fuente original para sólo incluir modificaciones estéticas y de funcionamiento pero mantienes el núcleo principal, ¿estás haciendo divergir algo? Papá Google y su masa de programadores tiene mucho tirón.
Nadie quiere perder la compatibilidad con Google Play.
Las ROMs no son forks
Las ROMs que los cocineros elaboran para los distintos sistemas cogen directamente el código Android AOSP, y a veces toman las versiones de los fabricantes para aprovechar su trabajo. Cuando toca avanzar, vuelven a centrar su foco en Android o en el fabricante. Luego esa divergencia no existe como tal. No son, por tanto, forks. En el mismo plano situamos a los fabricantes. A Samsung con Touchwiz, a HTC con Sense, a Sony con Xperia Launcher. De MIUI, con todo lo que se diferencia estéticamente de las versiones de Android de sus compañeros de mercado. Modifican sin intención de crear algo nuevo. Sólo adaptan cada versión a su estética, con sus servicios. Personalizan. Esto dista bastante de lo que se puede considerar un fork de Android. Porque cuando sale una nueva versión de Android, todos vuelven a empezar.
Cuando sale una nueva versión de Android, todos vuelven a empezar.
Aquí llegamos al punto en el que tengo más dudas. Fire OS. ¿Es realmente un fork lo que hace Amazon? Habría que analizar el código del sistema de Amazon para comprobar qué parte del código está realmente modificado y qué parte se toma tal cual de Android AOSP. En mi opinión, y abro paraguas, no es un fork. Tengo con ellos, no obstante, cierta sensación de que aspiran a ser un sistema operativo independiente en el futuro, con un kernel propio, y hacer que los desarrolladores acaben adaptando las aplicaciones para ellos. Pero ahora eso no ha ocurrido así que de ahí mis dudas.
Conclusión
En conclusión, bajo mi punto de vista no existen los forks en Android. Todo son modificaciones sobre el código AOSP que siguen volviendo una y otra vez al código original para no perder la compatibilidad con un sistema que coloca cada año 1000 millones de dispositivos en el mercado. Es principalmente la razón de que nadie decida tomar el código original y convertirlo en otra cosa. ¿Echar a Google? Claro, pero hay que tener en cuenta que el propio Google crea ROMs a partir de AOSP para uso propio. Es un tema complicado, desde luego.
Ya podéis atizarme.
Fork o no fork, ésa es la cuestión. 😛
Mejor explicado imposible.