MeeGo y su pequeña ventaja en la salida

El proyecto MeeGo ha tenido 6 presentaciones en la conferencia "Linux Foundation Collaboration" -últimamente hay una barbaridad de estas conferencias-, y en una de ellas, Arjan Van De Ven, ex-Red Hatero y trabajador de Intel, describe la organización de la nueva distro:

"Architecture maintainers are responsible for integrating hardware-specific patches into the single MeeGo source base - upstream first" policy for patches!". Es decir, los fabricantes tendrán que ocuparse de conseguir por su propia cuenta la inclusión en el kernel de las modificaciones y drivers que utilicen para que Linux soporte su harware.

Los fabricantes de hardware, ya se ha dicho por aquí varias veces, solo piensan en vender hardware. Se olvidan pronto del software. Se dan, por esta razón, casos de fabricantes de hardware que han adaptado toda una distro para su producto sin preocuparse de contribuir el código. Luego han puesto a la venta el dispositivo, han publicado el código modificado en un FTP, y se han olvidado del asunto. Pueden hacerlo así, claro, y en algunos casos no importa. Para eso está el software libre.

Otros muchos, en cambio, pronto descubren lo contraproducente de este sistema. Tienen que mantener el software, y se encuentran con miles de líneas de código que tienen que cargar a su espalda. Tarde, descubren que mucho mejor hubiera sido preocuparse de adaptar el código y meterlo en upstream en su día. El mejor ejemplo de esto es Android. No quisieron contribuir su código al kernel. DiBona -el jefe de opensource en Google- despreció las críticas que se hicieron al respecto. Creían que podían vivir solos, por su cuenta. Ahora se encuentran con una situación infernal: Las decenas de empresas interesadas en Android están basando su trabajo en un repositorio interno de Google. La cantidad de código no presente en upstream está creciendo rápidamente.

Ahora, Google se encuentra con que cada vez que quieran actualizar el kernel de Android, tienen que hacer un esfuerzo enorme para portar todo ese código a la nueva versión (lo mismo que les pasa con los kernels de sus servidores, que tienen 300.000 LoC de parches sobre un kernel 2.6.26).

Tras todo este nulo esfuerzo por sincronizarse con upstream, Google no solo se encuentra con que les hubiera costado menos contribuir que mantener el código por su cuenta, se encuentran con que más de un teléfono que hoy lleva Android no podrá actualizarse en el futuro. Drivers propietarios no actualizados, bases de código desactualizadas, no mantenidas. Ahora, tarde ya -pero mejor tarde que nunca- han contratado a dos programadores con la única misión de incluir el código de Android en upstream, para arreglar el problema. Bienvenida sea esta magnífica iniciativa, pero MeeGo, con su política de "upstream first" (la misma que usa Red Hat), tiene el problema resuelto de antemano.