El middleware y la Sección 3.3.1 ☆ ★

Friday, 30 April 2010

Miguel de Icaza ha escrito esta semana un profundo e informativo artículo que explica el funcionamiento de MonoTouch, y de qué modo podría evitar entrar en conflicto con la nueva sección 3.3.1 del acuerdo de licencia de Apple. El artículo apareció hace dos días, por tanto antes de la aparición de la carta abierta de Steve Jobs titulada “Relfexiones sobre Flash”. La teoría de Miguel de Icaza sobre la justificación empresarial para la nueva Sección 3.3.1, mucho más restrictiva, la confirmó Jobs de forma directa — Apple no quiere que se creen aplicaciones multiplataforma sobre Cocoa Touch que apenas alcancen un mínimo de calidad.

La segunda teoría de Miguel de Icaza habla acerca de las consideraciones sobre el interfaz que justifican los cambios en la Sección 3.3.1:

Como mencioné antes, usar soluciones multiplataforma como Flash o Silverlight haría que todas las aplicaciones no parezcan creadas para ese sistema operativo. Pero como mencionó igualmente Steve Jobs, los programadores no tendrían acceso a las nuevas funciones de iPhone OS si hubieran escogido una tecnología que no las incorporara.

Por ejemplo, cuando Apple introdujo en iPhone OS 3.2 las nuevas vistas partidas que el iPad usa habitualmente al rotar la pantalla, esa funcionalidad en concreto habría tardado demasiado tiempo en estar disponible de forma satisfactoria por ejemplo en Silverlight para el iPhone o Flash para el iPhone. O también cuando Apple introdujo la vista de interfaz (UIView) que se puede utilizar para mostrar mapas, también habría sido un problema añadir este tipo de control de interfaz. O cuando Apple introdujo GameKit, una API para conectar iPhones entre sí de modo que pudieran intercambiar mensajes entre ellos.

El compilador cruzado de Flash, y esto es algo que ya sabemos, queda explícitamente descartado por la nueva Sección 3.3.1. En lugar que ocupa MonoTouch, por otra parte, aún no está claro. Como explica Miguel, MonoTouch, a diferencia de Flash, no pretende crear interfaces multiplataforma pensados para programar una sola vez y ejecutarse en cualquier sistema:

MonoTouch trae al iPhone el lenguaje C# y el núcleo de .NET, pero no aspira a aportar un interfaz multiplataforma y tampoco ningún tipo de APIs multiplataforma para dispositivos móviles. […]

Actualizamos la plataforma para incluir soporte para el iPad 24 horas después de que Apple publicara el kit de desarrollo. Añadimos el soporte para iPhone OS 4.0 unos días después de su aparición (tardamos sobre todo porque estábamos todos bastante decepcionados). Nuestras APIs son un mapeo exacto de las APIs de iPhone.

Al igual que C y C++, si los programadores quieren reutilizar código entre MonoTouch, Windows 7 o MonoDroid, tendrán que separar su interfaz y el código exclusivo para cada dispositivo de su lógica de negocio. MonoTouch no proporciona semejante capa de abstracción.

MonoTouch no está en la misma categoría que el compilador para iPhone de Flash, puesto que no es un entorno de desarrollo multiplataforma. Es algo intermedio, por así decirlo. Pero sigue siendo una capa de middleware situada entre los programadores y las APIs de la propia Apple. Sí, actualmente MonoTouch se mantiene al día con las APIs nativas de Apple, pero ¿qué pasará dentro de tres, cuatro o cinco años si MonoTouch deja de estar al día y cientos (o miles) de aplicaciones populares para iPhone OS dependen de él? Esa situación es lo que Apple quiere evitar.

Lo siguiente es un fragmento de la carta de Jobs “Reflexiones sobre Flash”:

Por desgracia, sabemos por experiencia propia que permitir que una capa de software de terceros se interponga entre la plataforma y el programador acaba por producir aplicaciones de baja calidad y dificulta la mejora y el avance de la plataforma. Si los desarrolladores acaban por depender de librerías y herramientas de terceros, sólo pueden aprovechar las mejoras realizadas a la plataforma si dicho tercero decide adoptar las nuevas funcionalidades, y sólo cuando éste las incluya. No podemos estar a merced de que alguien decida si va a poner a disposición de nuestros programadores las mejoras que realicemos, y en caso afirmativo, hacerles esperar hasta que las incluyan.

Un ejemplo de “experiencia” lamentable de este tipo, desde el punto de vista de Apple, sería la plataforma PowerPlant de Metrowerks. PowerPlant era un kit de creación de interfaces y una plataforma de dearrollo para el antiguo sistema operativo Mac OS, que venía incluido con CodeWarrior, un compilador y entorno de desarrollo intergado creado por Metrowerks. Era muy bueno, y muy popular — muchas aplicaciones populares para Mac se habían creado con la plataforma de desarrollo PowerPlant.

El problema llegó varios años más tarde, con el salto a Mac OS X.¹ PowerPlant no se diseñó teniendo presente Mac OS X, y no aprovechaba los últimos avances de Mac OS X. Por ejemplo, no se incorporó soporte para Carbon Events en PowerPlant hasta 2004. No había una forma sencilla de que aplicaciones creadas con PowerPlant pudieran adaptarse para ser aplicaciones nativas para Mac OS X. Dejando a un lado Cocoa, las aplicaciones creadas con PowerPlant no podían aprovechar las nuevas y más potentes APIs Carbon de Mac OS X.

Ahora bien, no es como comparar manzanas con manzanas, porque una de las mayores diferencias entre el antiguo Mac OS y Mac OS X es que en Mac OS no existía una plataforma de desarrollo incorporada como ocurre con Cocoa en Mac OS X. (Y hay que hacer hincapié en que Carbon fue un kit de desarrollo de primer nivel para Mac OS X durante la primera mitad de la década — podría decirse que Cocoa no llegó a ser realmente la plataforma de desarrollo definitiva hasta la WWDC  de 2007, cuando Apple canceló repentinamente la creación de una plataforma Carbon de 64 bits, que se había anunciado para Mac OS X 10.5 tan sólo 9 meses antes [durante la WWDC de 2006]). Los desarrolladores de Metrowerks que crearon PowerPlant no pudieron anticipar Carbon y Mac OS X, y mucho menos Cocoa, y los desarrolladores de Mac que decidieron usar PowerPlant no tuvieron ningún consejo por parte de Apple en plan “No, esto es lo que deberías hacer” que decidieran ignorar.

Pero debido a que PowerPlant era (a) popular y (b) no estaba al día de los nuevos avances en la plataforma de Mac OS X, se convirtió en un lastre y un freno para Apple. Apple invirtió una importante cantidad de tiempo, dinero y esfuerzo intentando dar soporte a los desarolladores de PowerPlant y en traerlos hasta donde Apple quería hacer llegar a la plataforma.

Por tanto, mi comparación en este caso no es decir que PowerPlant fuera malo o que los desarrolladores que dependían de él tomaran una mala decisión. Más bien es que Apple descubrió que había grandes riesgos al permitir que cualquier tipo de tecnología se interponga entre las APIs de Apple y los programadores independientes. Apple no podía arreglar PowerPlant. No podían portarlo a Mac OS X por su cuenta. Estaba fuera de su poder, y Motorola (que compró Metrowerks en 1999) tenía otras prioridades.

Miguel de Icaza plantea que este tipo de decisión debería dejarse en manos de los programadores independientes:

Como programador, creo que debería ser responsable de mis decisiones tecnológicas. Si escojo una herramienta de desarrollo multiplataforma que tiene un aspecto horrible en el iPhone, esto dejará el campo abierto para que un competidor lo haga mejor. O si mi aplicación no aprovecha una nueva API de iPhone OS, también estoy dejando un flanco descubierto del que puede aprovecharse un competidor. Apple no necesita intervenir imponiendo unas directrices, pues la calidad de las aplicaciones, el App Store, las revistas especializadas, los analistas y el boca a boca están creando las condiciones para que se produzca una situación de competencia darwiniana en la que sobrevivirá el mejor.

Creo que el párrafo anterior expresa muy bien la opinión de muchos programadores que se oponen enérgicamente a las restricciones impuestas por la nueva Sección 3.3.1, y en muchos casos se sienten directamente ofendidos por ellas. Más o menos algo como “dejadme que yo sea quien se arriesgue a que se abra un abismo entre el middleware que quiero usar y la plataforma Cocoa”.

Y es algo totalmente razonable. Pero el punto de vista de Apple también es razonable — ya han tenido experiencias negativas cuando herramientas y plataformas de desarrollo populares han quedado fuera de su control. En este momento, Apple tiene la autoridad para prohibir estas “capas de software de terceros que se interponen entre la plataforma y el programador” por decreto. Si esperaran hasta que surjan problemas reales de compatibilidad en el futuro, podría ser ya demasiado tarde — llegados a ese punto, si los sistemas middleware incompatibles son lo suficientemente populares, la autoridad no estará en manos de Apple, sino en las del colectivo de programadores que dependen del middleware. Apple puede prohibirlas ahora por decreto; no podrían hacer lo mismo en un futuro en el que se uso ya esté generalizado.

Con las capas que añade el middleware, la plataforma subyacente puede quedarse estancada. Apple quiere mantener todo el control posible sobre las aplicaciones nativas para el iPhone, y está usando este control para, tal y como dice el propio Jobs, impulsar “la mejora y el avance de la plataforma”.

John Siracusa habló sobre esto mismo hace dos semanas en su artículo titulado “Apple’s Wager” (el envite de Apple):

Al igual que el Mac, el iPhone salió al mercado con una enorme ventaja técnica sobre sus competidores. Pero en esta ocasión, Apple está decidida a no desperdiciar su ventaja. En lugar de eso, está esforzándose al máximo por llevar la delantera. Todo lo que pueda frenar “el avance de la plataforma” debe desaparecer. Y el mejor modo en que Apple puede evitarlo es controlando su propio destino de cualquier forma posible. Esto quiere decir, entre otras cosas, eliminar a los productores de middleware, disuadir del desarrollo multiplataforma (ya sea de forma explícita o implícita), y un control abritrario absoluto sobre la presencia de todas las aplicaciones en la plataforma.

Apple opina que otras plataformas que permiten este tipo de cosas, la mayoría de las cuales son muy apreciadas por los programadores, pagan el precio de frenar su avance respecto a la competencia.

No estoy seguro de que Apple esté haciendo lo correcto. Como ya he dicho, el punto de vista de Miguel de Icaza — que la toma de estas decisiones y riesgos debería depender de cada programador — es totalmente sensata. Siracusa tiene toda la razón al decir que Apple está haciendo una apuesta fuerte con esta decisión. Apple se está jugando todo su futuro en el mercado móvil apostando que su plataforma de desarrollo es mejor que todas las demás.