Las recientes informaciones sobre Canonical y LXD tuvieron menos repercusión de lo debido. Claro que no se trata de un producto que los usuarios comunes, al menos los que producimos o consumimos contenidos sobre Linux tengamos demasiada información.

Confieso que a veces me siento como Dumbledore tratando de convencer al Ministerio de la Magia de que volvió Voldemort. Todavía quedan muchos persuadidos de que los buenos tiempos en donde el control de los destinos del software libre estaba en manos de la comunidad  siguen, pero lo cierto es que cada vez más las grandes tecnológicas, particularmente IBM, Microsoft y Google influyen en las decisiones.

Canonical y LXD. ¿De qué estás hablando, Diego?

Vamos por partes. La nube, mal que le pese a los cloudofóbos no es simplemente usar un ordenador en forma remota. Es usar varios, pero en el mismo hardware. El servidor puede ejecutar al mismo tiempo Photoshop en Windows 11, LibreOffice en formato Flatpak y VLC en formato Snap y un usuario en su Chromebook alternar entre ellos sin necesidad de cambiar de sistema operativo.

Esto es posible gracias a la tecnología de contenedores.  A diferencia de la máquina virtual que es un software intermedio que actúa de intérprete entre el sistema operativo anfitrión y el programa ejecutado, el contenedor es parte del sistema operativo que le asigna recursos exclusivos de hardware para que pueda ejecutar un programa con el sistema operativo que le corresponde.

Para que se entienda la diferencia. Si yo uso Photoshop sobre Windows en una máquina virtual instalada en Linux, el procesamiento gráfico se hace usando el controlador correspondiente de Linux. Si lo hago en un contenedor, usará el controlador de Windows 11. Lo mismo, pero a la inverso si ejecuto LibreOffice y VLC sobre Fedora y Ubuntu en máquina virtual Windows o sobre contenedores.

Cuando uno trabaja con muchos contenedores hacerlo de manera manual puede resultar engorroso por lo que se crearon muchas soluciones de automatización. Una de ellas, la propuesta por Canonical es LXD. Sus competidores principales son Kubernetes (En manos de una fundación conformada por Google y la Linux Foundation) y OpenShift (Red Hat/IBM)

Hasta hace unos días, LXD estaba bajo el control de la comunidad de LinuxContainers (El proyecto de código abierto en el cual se basaba y también estaba apoyado por la empresa). Sin embargo, un anuncio en la página web (Que, al momento de escribir esto está caída, informó que Canonical se hacía cargo del proyecto y tanto los repositorios como la documentación y los foros se trasladaban a su sitio web.

Hay que mencionar que LXD, que es otra más de las tecnologías que Canonical no logró hacer masiva, es parte fundamental de sus planes de avanzar en el uso de la paquetería Snap en sus distribuciones. Sin embargo, desde la empresa aseguraron que el proyecto no estará atado a un sistema operativo o formato de paquetes.

Sin embargo, solo los empleados de Canonical podrán ser mantenedores del proyecto.

Renuncia

Por su parte, Stéphane Graber, líder y la cara visible del proyecto LXD renunció a Canonical. En un post en su blog (Al que al menos yo no puedo entrar) explica las causas de su retiro.

Como les dije a mis colegas y a la alta gerencia, Canonical no es la empresa a la que me uní con entusiasmo en 2011 y no es una empresa a la que me gustaría unirme hoy, por lo tanto, tampoco debería ser una empresa para la que sigo trabajando.

Sobre la decisión de Canonical expresó:

Obviamente desearía que ese [cambio] no hubiera ocurrido, veo mucho valor en que un proyecto como LXD se ejecute en un entorno comunitario más abierto donde se valora la opinión de todos y la contribución de todos, sin importar el tamaño, es bienvenida

Graber, que piensa dedicarse a la consultoría, prometió seguir aportando código a LXD.

Puede que me equivoque, pero este es solo el inicio de un movimiento más en el sentido de menos cooperación y más competencia en el mundo del código abierto.