Hace unas semanas, Canonical anunció el soporte de distribución cruzada para el mecanismo de entrega de aplicaciones Snap, uno que podría soportar aplicaciones móviles, de escritorio y de servidor. El anuncio irritó a algunos miembros de la comunidad Linux, que vieron escasa evidencia de que alguna otra distribución Linux soportara Snaps.
Snap es el intento de Canonical de perfeccionar el mecanismo de empaquetado y entrega de aplicaciones en la plataforma Linux. El origen de Snap se encuentra en Click, una solución que Canonical creó para su plataforma móvil en 2014, para manejar la complejidad de la entrega de aplicaciones a los usuarios de teléfonos y tabletas de Ubuntu, un ecosistema muy diferente de los escritorios y servidores. Además, los móviles también necesitaban confinar las aplicaciones y ponerlas en un cajón de arena, para que no comprometieran toda la plataforma.
Click permitía a los desarrolladores agrupar todas las dependencias en un único paquete de aplicaciones, para que los usuarios y los desarrolladores no tuvieran que preocuparse por sistemas y bibliotecas de aplicaciones conflictivas. Permitió a los desarrolladores utilizar las últimas librerías en sus apps, para ofrecer nuevas funcionalidades al estar desvinculadas de las librerías instaladas en el sistema.
Más allá de los móviles a los servidores y al IoT
Click evolucionó hasta convertirse en Snap y Canonical amplió su uso potencial a los espacios de los servidores, la nube, el Internet de las Cosas (IoT) y el escritorio. Con el lanzamiento de Ubuntu 16.04 en abril, Canonical llevó oficialmente Snap al escritorio de Ubuntu.
Canonical también está desarrollando Snappy Ubuntu Core, un diminuto sistema operativo basado en Linux para despliegues de contenedores en la nube a gran escala, dispositivos IoT y mucho más, y cualquier cosa que necesite actualizaciones transitorias y una huella diminuta. Snappy Ubuntu Core funciona más o menos como Chrome OS y CoreOS de Google, donde ofrece actualizaciones transitorias basadas en imágenes para el sistema y las aplicaciones que se pueden revertir. Simultáneamente, ofrece el confinamiento que se conoce en el mundo de los contenedores.
Snap es el alma de esa tecnología.
El desorden de Linux en la entrega de aplicaciones
El modelo de entrega de aplicaciones existente en Linux tiene muchos defectos. El mundo de Linux se divide principalmente en dos campos de empaquetado de aplicaciones: rpm y deb. Además, hay diferentes versiones de las mismas distribuciones que utilizan diferentes bibliotecas, por lo que resulta bastante complicado para los desarrolladores de aplicaciones empaquetarlas para Linux.
Como resultado, los desarrolladores de aplicaciones no pueden aprovechar las últimas bibliotecas y ofrecer más funciones a sus usuarios si la distribución sigue utilizando bibliotecas antiguas.
En la mayoría de los casos, los desarrolladores de aplicaciones de código abierto no empaquetan sus aplicaciones para las distribuciones. Las aplicaciones populares o establecidas desde hace tiempo suelen ser empaquetadas por los desarrolladores de las distribuciones. Las más nuevas o menos populares son empaquetadas por el upstream para cada distro que quieren apoyar, o no se ofrecen como un paquete de distro en absoluto. Cuando se publica una nueva versión de una aplicación, estos desarrolladores la prueban y la ponen a disposición de la distro. Como puede ver, en lugar de que el desarrollador de la aplicación sólo escriba una aplicación para toda la plataforma, que en este caso es Linux, hay muchas personas que llevan esa aplicación a los usuarios.
Añade más complejidad.
Hay casos en los que Windows y MacOS obtienen las últimas versiones inmediatamente, ya que las aplicaciones son empaquetadas por los desarrolladores primarios, mientras que las distros de Linux pueden tardar un tiempo. Eso no es todo; algunas distros las obtienen rápidamente, y otras tienen que esperar semanas o meses.
En el caso de las apps comerciales como Skype, Dropbox, Chrome, la responsabilidad recae en el desarrollador primario de empaquetar las apps y ofrecer binarios para diferentes distribuciones. Muchas aplicaciones no funcionan en las versiones más antiguas, aunque soportadas, de muchas distribuciones.
En una palabra, es un lío.
Incluso el creador de Linux, Linus Torvalds, no está contento con el modelo de entrega de aplicaciones existente en Linux. No ofrece binarios de sus aplicaciones para la plataforma Linux citando este desorden. Dirk Hohndel, el encargado de mantener Subsurface (un proyecto iniciado por Linus), explicó: «La situación actual, con docenas de distribuciones, cada una con diferentes reglas, cada una con diferentes versiones de diferentes bibliotecas, algunas con ciertas bibliotecas ausentes, cada una con diferentes herramientas de empaquetado y formatos de empaquetado… eso básicamente les dice a los desarrolladores de aplicaciones ‘váyanse, concéntrense en plataformas que se preocupen por las aplicaciones.'»
«El empaquetado de aplicaciones es enormemente importante, pero también lo es la procedencia y el mantenimiento de todas las piezas implicadas», coincidió Gunnar Hellekson, director de gestión de productos de Red Hat Enterprise Linux.
Snap fue diseñado para poner un poco de orden en este estado de cosas. Pero si se adoptará es otra cuestión totalmente distinta.
Hellekson argumentó que herramientas como Snap no «resuelven mágicamente los problemas de interoperabilidad entre las distribuciones de Linux y, en realidad, trasladan más responsabilidad de mantenimiento y seguridad a los proveedores de aplicaciones. De este modo, podrían dificultar aún más el desarrollo en Linux, a pesar de las muchas ventajas que aportan a los usuarios».
«Las ventajas de Snap están directamente relacionadas con sus desventajas… en esencia, Snap es el equivalente a la vinculación estática: por un lado es conveniente, pero por otro crea duplicidades y desafíos con respecto a la seguridad (y la aplicación de parches de seguridad)», dijo Gerald Pfeifer, vicepresidente de productos y programas tecnológicos de SUSE.
Sin embargo, no todo el mundo es de la misma opinión. Brandon Philips, cofundador y director de tecnología de CoreOS, nos dijo que los contenedores son el futuro de las aplicaciones en Linux. Pero los contenedores Docker no pueden utilizarse en todas partes. Tienen sus limitaciones. Lo que necesitamos es una solución parecida a los contenedores, algo como Snap.
Durante otra entrevista, el principal desarrollador del kernel de Linux, Greg Kroah-Hartman, nos dijo que Android ha estado haciendo contenedores «para sus aplicaciones desde hace ocho o nueve años. Cada aplicación se ejecuta en su propio espacio de nombres. No puede ver fuera de él. Así es como hay que hacerlo. Ese es el futuro de Linux y el modo en que funcionan los sistemas». Dijo que Snap es el mismo concepto, la misma idea.
Snap Goes Cross Platform
El éxito de Snap depende en gran medida de su adopción por parte de la comunidad de código abierto más amplia. ¿De qué sirve un formato de aplicación si nadie lo utiliza? Al ser una tecnología exclusiva de Ubuntu, que puede que ni siquiera reciba apoyo oficial de sus derivados como Linux Mint, KDE neon o elementary OS, Snap podría enfrentarse a una carrera no muy exitosa.
Cuando Canonical anunció Snap, afirmó en una conferencia de prensa que ha estado trabajando con varias distribuciones para añadir soporte para Snap.
Canonical dijo que Snaps está disponible de forma nativa para Arch, Debian, Fedora, Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Unity y Xubuntu. Canonical también está trabajando en la validación de Snaps en CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt y Red Hat Enterprise Linux.
Canonical y SUSE no están actualmente comprometidos en el desarrollo en torno a la colaboración en Snaps, y de hecho, parece que esto no fue el resultado del diseño y desarrollo de la comunidad abierta», Gerald Pfeifer, SUSE.
El anuncio de Canonical de que trabajaban con otras distribuciones atrajo algunas críticas de algunos miembros de la comunidad de código abierto. Los desarrolladores de Fedora no se tomaron bien este anuncio y criticaron a Canonical afirmando que no había ningún tipo de colaboración entre ambos proyectos.
Cuando hicimos un seguimiento con el fundador de Canonical, Mark Shuttleworth, para preguntarle sobre estas acusaciones, respondió: «Hicimos un informe con el equipo de escritorio de Red Hat y siempre estamos abiertos a trabajar con todas las distribuciones de Linux para habilitar Snaps.»
Sin embargo, esto resultó ser una noticia para Red Hat, que pastorea la distribución Fedora.
«Aunque trabajamos con Canonical en varias comunidades, nos sorprendió tanto como a todos cuando anunciaron nuestra participación en esta iniciativa en particular. Estamos abiertos a más discusiones sobre esto, y a ver cómo la comunidad Linux en general quiere trabajar juntos», dijo Hellekson.
Los responsables de SUSE también restaron importancia a cualquier colaboración. «Canonical y SUSE no están actualmente comprometidos en el desarrollo en torno a la colaboración en Snaps, y de hecho, parece que esto no fue el resultado del diseño y desarrollo de la comunidad abierta», dijo Pfeifer.
Lo que parece haber sucedido es que Canonical trabajó con algunos desarrolladores, tal vez sólo un puñado, de otros proyectos y ayudaron en el embalaje de Snaps para otras distribuciones.
Canonical no es perfecto
Parte del rechazo que Canonical puede haber recibido puede ser un subproducto de la forma en que hace negocios.
Por un lado, otras empresas de Linux, como Red Hat y SUSE, mantienen una separación de poderes muy clara cuando se trata de Fedora y openSUSE. Fedora y openSUSE son proyectos bastante independientes, impulsados por la comunidad, donde las decisiones son tomadas por los miembros de la comunidad y no por las empresas patrocinadoras.
En cambio, Ubuntu es un producto de Canonical que también resulta ser un proyecto comunitario. Debido a que al contrario que openSUSE y Fedora, Canonical tiene control directo sobre Ubuntu. Ya aprendimos en el caso de ownCloud; es realmente difícil mantener un equilibrio entre las necesidades de la comunidad y la empresa; a menudo termina en un desastre como ownCloud.
Surge la pregunta de cómo se «trabaja» con un proyecto…
Además, muchos sienten que hay una falta de transparencia con Ubuntu. En ocasiones, muchos de los principales colaboradores de Ubuntu han expresado su frustración porque Canonical ha mantenido en secreto los principales anuncios sobre Ubuntu, ocultos incluso a los miembros del núcleo. Los miembros de Ubuntu no tenían ni idea de la existencia de Ubuntu para Windows o del malogrado proyecto Edge.
«No retenemos las cosas», respondió el director general de Red Hat, Jim Whitehurst, a una pregunta sobre el enfoque de esa empresa respecto al código abierto. «Cuando construimos cosas, no lo ocultamos a la gente para hacer una gran revelación y decir ‘aquí está el código’. No lo hacemos. Trabajamos en comunidades desde el primer día, todo el tiempo. Creo que tratamos de ser muy buenos participantes, y creo que eso se nota».
Además de estas diferencias, Canonical también es conocido por cometer algunos errores cuando se trata de liberar información. Este parece ser ciertamente el caso de anunciar el soporte de distribuciones cruzadas para Snap; la redacción que irritó a los desarrolladores de Fedora fue «Desarrolladores de múltiples distribuciones de Linux.» Para ser claros, Canonical nunca declaró explícitamente en su comunicado de prensa que trabajaba con Fedora. Y según la información que recogimos, no hubo ningún compromiso «oficial» con distros de Linux como Fedora, Red Hat, SUSE u otras.
Dicho esto, surge la pregunta de ¿cómo se «trabaja» con un proyecto? Si un desarrollador que trabaja en una aplicación colabora con un desarrollador de Ubuntu, un desarrollador de Fedora y un desarrollador de openSUSE para llevar esa aplicación a esas plataformas, ¿sería incorrecto decir que el desarrollador trabajó con múltiples distribuciones para llevar la aplicación a ellas? ¿O el desarrollador necesita un compromiso oficial con los líderes de los proyectos de estas distribuciones para poder hacer tal declaración? Después de todo, se trata de una comunidad distribuida de código abierto.
¿Dónde está Snap?
La pregunta más importante es, ¿será Snap adoptado oficialmente por otras distribuciones? Ahí es donde las cosas se complican un poco. Se convierte en una cuestión tecnológica y política.
En primer lugar, Snap no es la única solución que existe. Hay muchos proyectos que intentan ofrecer ecosistemas de empaquetado agnósticos para las distros de Linux. Pero puede ser difícil encontrar un consenso dentro del mundo de las distro de Linux. Existen AppImage y Flatpak, que ofrecen alternativas adecuadas a Snap; estos proyectos han existido durante mucho más tiempo que Snap.
Entonces, ¿por qué Canonical no adoptó estas soluciones en lugar de iniciar Click o Snap?
«Lo analizamos y descubrimos que AppImage funciona perfectamente para las aplicaciones de escritorio ‘leaf-node'», dijo Shuttleworth. Una aplicación leaf-node es aquella que no necesita integrarse con ninguna otra aplicación. Snap se diseñó más bien para empaquetar aplicaciones con dependencias y aplicaciones relacionadas. «Snaps tiene una serie de capacidades para describir esas conexiones: interfaces, enchufes y ranuras, así como archivos compartidos, etc.»
Además de eso, Shuttleworth nos dijo que Snap fue diseñado para niveles más altos de seguridad en comparación con AppImage, en parte porque el equipo que trabajaba en el móvil estaba centrado en la seguridad y la eficiencia, y en parte porque Snap utiliza capacidades más nuevas del kernel.
Flatpak supuestamente fue víctima de la rivalidad entre Canonical y Red Hat cuando estaba siendo desarrollado por la gente de Fedora. Cuando pregunté, Shuttleworth lo descartó como un proyecto desarrollado por un solo desarrollador.
Eso explica por qué Canonical siguió adelante con Snap.
Ahora, ¿lo adoptarán otras distros? Los desarrolladores de Fedora ya han declarado que no utilizarán Snap. Un desarrollador de Fedora escribió en la lista de correo: «Nosotros, por supuesto, no tenemos ningún plan para adoptar Snappy en Fedora y, de hecho, varios desarrolladores de Fedora están trabajando en una solución de la competencia, Flatpak».
Red Hat adoptó previamente un proyecto de Canonical para la inicialización del sistema llamado Upstart. Hellekson dijo: «Estos son días muy tempranos para todos estos esfuerzos de empaquetado, y esperamos trabajar con todas las comunidades relacionadas para hacer la vida tan fácil como sea posible para los usuarios de Linux».
Más allá de la rivalidad entre Red Hat y Canonical, hay algunas cuestiones técnicas que pueden disuadir a otros proyectos de colaborar en Snap. Uno de ellos es que los desarrolladores tienen que firmar un CLA (Contributor License Agreement) si contribuyen al proyecto Snap. Michael Hall, desarrollador de Canonical, dijo que «el CLA es necesario cuando un desarrollador quiere contribuir al propio proyecto Snap. No se necesita un CLA para crear o distribuir Snaps de aplicaciones»
Los CLA permiten a Canonical cambiar la licencia del proyecto. Eso es beneficioso para Canonical, ya que puede volver a licenciar un proyecto, permitiendo su uso con licencias no libres o incompatibles. A los desarrolladores no les suelen gustar los CLA.
Frank Karlitschek, de Nextcloud, nos dijo que está poniendo fin a los CLA de Nextcloud, ya que consideraba que los CLA no tienen muy buena reputación dentro de la comunidad de código abierto.
Cuando le preguntamos a Red Hat si los CLA iban a dificultar la colaboración en torno a Snap, Hellekson dijo: «Los Acuerdos de Licencia de Colaboración nos dificultan la participación. Creemos que las licencias directas de código abierto son un enfoque mejor y más inclusivo».
La respuesta de SUSE fue muy parecida. Pfeifer dijo: «Los ingenieros y el personal de SUSE siguen contribuyendo a una plétora de proyectos de código abierto, tanto en el tiempo de la empresa como en el nuestro propio, y cuando es necesario hemos firmado CLAs. Sin embargo, siempre que iniciamos proyectos o influimos en ellos, tratamos de mantenernos alejados de los acuerdos de licencia. Por lo general, no nos gustan los CLA que asignan un derecho de autor que permite a las organizaciones volver a licenciar el código abierto utilizando una licencia que no es de código abierto».
Cuando le preguntamos a Shuttleworth si consideraría la posibilidad de eliminar los CLA de Snap para obtener un mayor apoyo de otras distros, empezó explicando por qué los CLA son buenos, pero luego también dijo que «si eso supusiera una diferencia, entonces sí, encontraríamos la manera de eliminarlos.»
¿Y luego hubo uno?
Con el tiempo, la madurez, la popularidad y la superioridad técnica de uno sobre otro pueden dejarnos con una solución. Ya lo hemos visto antes con Upstart y systemd, donde systemd emergió como una tecnología superior y se convirtió en la predeterminada en las tres principales distros de Linux: Ubuntu, RHEL y SUSE.
En cualquier caso, ambas tecnologías están en fases muy tempranas de desarrollo, y es difícil decir qué proyecto tendrá éxito. Sin embargo, está bastante claro que en el mundo centrado en los contenedores, Linux necesita un nuevo mecanismo de entrega de aplicaciones.
Muchas empresas y comunidades han expresado su apoyo a soluciones como Snap. Samsung y Dell se unieron a Canonical en la convocatoria de prensa y declararon la necesidad de una solución de este tipo. En el extremo del escritorio, proyectos como LibreOffice y Firefox ya han expresado su apoyo a Snap.
El tiempo dirá si Snap será adoptado fuera de Ubuntu o no. Cualquiera que sea el futuro de Snap, debemos dar a Canonical el debido crédito por empujar el sobre, forzando al resto de la comunidad Linux a centrarse finalmente en la solución de un problema con el que nos habíamos acomodado o, tal vez, nunca tuvimos la motivación para resolver.
CoreOS y Red Hat son patrocinadores de The New Stack.