Hace la friolera de 18 años escribía Joel Spolsky en su blog un artículo que me llegó al alma, por estar por aquel entonces especializado en desarrollo para Windows. Se titulaba How Microsoft Lost the API War.
Su tesis central era la siguiente: lo más valioso que tenía Microsoft por aquel entonces, no eran el dominio casi absoluto del mercado de sistemas operativos ni la sobreabundancia apabullante de aplicaciones para el mismo, lo que hacía difícil (y a veces inviable) usar otro.
Al contrario de lo que pensaba un Steve Balmer cubierto de sudor y claramente bajo la influencia de algún estimulante (¡poderoso!) cuando nos provocó aquella vergüenza ajena épica a todos los programadores:
Tampoco eran los “developers, developers, developers”. No, eso era circunstancial. Lo que nos tenía a los “developers, developers, developers” atados a la pata de la mesa de Microsoft era otra cosa: la API de MS era Win32.
Win32 era la joya de la corona
Y muchos lo sabían. Ese era el estándar para crear aplicaciones y llegar a millones de clientes: una puerta de la que solo MS tenía la llave.
A nadie normal le importa el sistema operativo. A los usuarios de a pie, que son legión, les importan las aplicaciones que pueden usar para hacer su trabajo. Por aquel entonces, virtualmente todas esas aplicaciones estaban en win32 y, a menudo, de forma exclusiva.
Hasta Steve Jobs tuvo que dar su brazo a torcer y creó para win32 versiones de iTunes o QuickTime.
Los dos lados de la Fuerza… en MS
En MS, por aquel entonces, había dos fuerzas que buscaban servir a los “developers, developers, developers” de la mejor forma que ellos creían posible.
Por un lado, teníamos aquellos que se esforzaban en que tu código, una vez escrito, funcionase siempre en su plataforma. Llegaban a realizar actos heroicos de retrocompatibilidad y consideraban que si una aplicación de éxito tenía problemas para ejecutarse en su plataforma, era un problema de la plataforma y lo arreglaban.
Raymond Chen era el guía espiritual de este grupo y, según él, cuando llegaba un informe de una aplicación que no funcionaba en Windows 95, lo consideraba un fallo personal suyo y se partía los chens para arreglarlo. Si eso introducía complejidad en su código, pues asunto suyo. Lo esencial era mantener la interfaz que los demás usábamos (win32) lo más sencilla posible.
Raymond Chen escribió un libro llamado The Old New Thing, que es de interés para cualquier desarrollador, aunque nunca haya escrito o vaya a escribir una línea de código para las plataformas Windows.
Por otro lado, teníamos aquellos que vivían no de facilitar que nuestro trabajo existente siguiese funcionando, sino de traer cosas nuevas y seguir en la cresta de la ola. El trabajo de este segundo grupo es también muy importante y, desde luego, más sexy que lo que hacía Mr. Chen.
Como líder de este campo, podemos poner a Anders Hejlsberg, creador de Delphi y luego de C#. Se trataba de un extraño traído de Borland a Microsoft con carta blanca para crear todo un nuevo lenguaje de programación (C#) y una plataforma completamente nueva (.NET), que iba a sustituir por completo a la anterior.
Microsoft se hallaba en una situación peligrosa: quería (y algunos dirían que tenía) que sustituir la joya de su corona y tendría que convencer a todos los “developers, developers, developers” que lo mejor que podíamos hacer era aprender su nueva propuesta (.NET) y no ir a buscar su futuro en otro lugar.
Al encargar esa transición a alguien como Hejlsberg, cuyo éxito en la empresa sería medido por la calidad de lo nuevo y no por el éxito de la transición de lo viejo a lo nuevo, se perdió por completo el espíritu de Chen y la retrocompatibilidad.
Y así fue como Microsoft se fue al carajo.
Adiós a Visual Basic 6
El primer error imperdonable fue la muerte de VB6. Se trataba del lenguaje de más éxito de la historia, con más programadores que ningún otro por aquel entonces. A pesar de ello, decidieron que todo el código creado por millones de programadores tendría que irse a la basura y ser reescrito en un lenguaje totalmente distinto, llamado Visual Basic .NET.
El objetivo era obligar a los programadores a pasarse a lo nuevo, tanto si les hacía falta como si no y tanto si querían como si no.
Ese era el plan. El problema es que los humanos tienen una tendencia marcada de no seguir planes que no son suyos y, como le dijo la princesa Leia a Tarkin, “cuanto más aprietas la mano, más sistemas se te escapan entre los dedos”.
¿Resultado? La inmensa mayoría de las aplicaciones escritas en Visual Basic 6 se reescribieron (qué remedio), pero como aplicaciones web con JS, HTML y CSS.
Nos escurrimos entre sus dedos a espuertas y muchos no volvimos nunca jamás.
Hoy, no conozco a nadie que programe en Visual Basic .NET y a muy pocos que usen .NET. Lo que antes era un monopolio, hoy es poco menos que un nicho.
Las startups solo crean software para la web y para móviles
¿Cuántas startups conoces que crean aplicaciones para escritorio? ¿Cuántas aplicaciones de escritorio usas? El browser y poco más, me temo.
La startup que puso en peligro el monopolio de Adobe y que, por ello, fue comprada por una millonada, no hacía aplicaciones de escritorio. Figma hizo temblar a Adobe con una aplicación web.
Hemos pasado de un sistema operativo omnipresente a que sea una commodity. Da igual qué sistema operativo uses. Si tienes un browser, puedes hacer casi todo.
La excepción es la única plataforma nueva que ha surgido: los móviles. Para ella aún se crean aplicaciones nativas, en parte porque el uso de aplicaciones web en móviles es notablemente más molesto que en un ordenador portátil.
En dicha plataforma, Apple dispone de un dominio notable, no tan extremo como fue el de Microsoft, y que Microsoft malgastó.
¿Estará Apple perdiendo la guerra de la API?
Si comparamos la situación de Apple con la de Microsoft de aquellos años, vemos muchos paralelismos.
Apple tiene una API valiosísima llamada Cocoa. Es la base de toda su tecnología, tanto en escritorio como en móvil. Por si fuera poco, se sale un poco de su jardín vallado, con implementaciones abiertas y un grupo (muy reducido, pero muy fanático) de desarrolladores que se dedican a mantenerla. Dichos desarrolladores jamás recibieron ningún tipo de apoyo de Apple, a pesar de que transformar GNUStep en algo relevante solo reforzaría la fuerza de Apple en el mercado a través de la fuerza de su API: Cocoa.
La API de Apple, Cocoa, también se tenía que modernizar, pero dado su valor estratégico, era vital hacerlo con cuidado para no perder usuarios.
Para esa tarea también se trajo a un extraño, cuyo éxito se mediría no por una transición de éxito, sino por cuantas novedades crease, sin ningún cuidado con la retrocompatibilidad.
Al igual que Microsoft, Apple soltó a un elefante dentro de la habitación donde guardaba sus porcelanas y vajillas más valiosas y, cuanto más ruido hacía dentro, más se aplaudía.
La necesidad de una alternativa
Los desarrolladores no estamos tan necesitados de escape en este caso. La ruptura de Apple no es tan absoluta como la de Microsoft y nuestro conocimiento sigue siendo muy valorado.
La necesidad la tienen las empresas, como explicó de forma magistral la startup NuBank. Crear aplicaciones móviles de calidad es caro y complejo. Tienes que crear dos equipos de divas carísimas para que hagan básicamente lo mismo en dos entornos distintos. Además, es vital que vayan de la par y gestionar eso es un castigo bíblico.
La vía de escape no creo que sea la web en este caso, fundamentalmente por cuestiones ergonómicas y la necesidad mayor de interactuar con el hardware del dispositivo.
¿Flutter?
Creo que será Flutter, como hizo Nubank. Flutter proporciona una plataforma común para iOS y Android, además de escritorio y web, con gran calidad del UI y un lenguaje apto para las masas. No es ni mucho menos perfecto y tiene algunas verrugas horrendas, pero de cara a la empresa es una muy buena opción.
Si vemos que más startups empiezan a optar por dicha tecnología (en China ha arrasado) y que algunos horrores en Electron son sustituidos por Flutter, veremos que una vez más la historia demuestra que nadie aprende nada de la historia.
¿Qué hacer si eres programador de aplicaciones móviles?
Pues lo mismo que yo. Mantén tu conocimiento de las tecnologías nativas, las seguirás necesitando para pagar la cena de hoy. Sin embargo, el brunch de mañana, posiblemente, te lo pague Flutter.
Por eso hemos fortalecido la enseñanza de tecnologías nativas en el Bootcamp de Aplicaciones Móviles en KeepCoding, a la vez que hemos incluido Flutter.
