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.

Dejándome en evidencia

En la serie de tres entradas que hice farfullando sobre las tiendas de aplicaciones, me jugué la boca diciendo que creía firmemente que Apple acabaría extendiendo la App Store a toda la gama Mac.

Hoy, Steve Jobs confirma explícitamente -últimamente está contestando a mucha gente mediante email, curiosa iniciativa mediática- que de App Store en OS X 10.7, nada de nada. Porca miseria. En realidad no me doy por vencido: La pregunta contiene dos cuestiones diferentes, y la respuesta es demasiado genérica.

En cualquier caso, da igual: Si Steve no quiere una App Store, Ubuntu si, y francamente tiene una magnífica pinta.

El plugin ODF de Oracle para Microsoft Office

Oracle ha empezado a cobrar por el plugin ODF que Sun desarrolló para Microsoft Office. Mucha gente parece haberse escandalizado por ello, y yo también al principio...pero al final ha acabado pareciéndome incluso buena idea.

Y es que a quien más daño hace no disponer de ese plugin es, en realidad, a Office. Dado que se puede decir que ODF ha triunfado, la carencia de buen soporte de ODF es un problema para Office, y una ventaja para Openoffice.