Linux Containers anunció el mes pasado que LXD, el administrador de máquinas virtuales y contenedores para Linux, pasaba a estar en manos de Canonical. Este movimiento tuvo como consecuencia la renuncia de Stéphane Graber, todo un veterano que estuvo trabajando para Ubuntu durante dieciocho años, de los cuales los últimos ocho los pasó involucrado en LXD, primero como líder técnico del proyecto después de crearlo y luego como gerente de ingeniería de proyectos.
La renuncia de Stéphane Graber y sobre todo algunos de los argumentos que ha expuesto dejaron la puerta abierta al salseo en torno a este asunto, como ha terminado sucediendo si tenemos en cuenta que, según informan en FossForce, el proyecto ha sido bifurcado y no solo eso: ya ha sido aceptado de forma inmediata por Linux Containers. Un caso impreciso de efecto bumerán que deja entrever que el proceso de trasladar LXD a Canonical podría no haberse hecho de manera muy amistosa.
Lejos de ser críptico o lanzar indirectas, Graber fue muy claro en su momento a la hora de exponer las razones que le llevaron a renunciar: “Obviamente desearía que este cambio en particular 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. Tener el ‘experimento de la comunidad LXD’ etiquetado como un fracaso dentro de Canonical parece injusto para mí y para todos los que contribuyeron a lo largo de los años”.
“En cuanto a mi participación particular en el avance de LXD de Canonical, definitivamente seguiré siendo un usuario activo de LXD y probablemente seguiré reportando y solucionando problemas ocasionalmente. Sin embargo, no tengo la intención de firmar nunca el Acuerdo de Licencia de Contribuidor (CLA) de Canonical, por lo que si eso se convierte en una barrera para la contribución al proyecto, tendré que dejar de contribuir”.
No es la primera vez que el CLA de Canonical termina provocando rechazo entre los contribuidores o potenciales contribuidores de un proyecto que se encuentra debajo del paraguas de la responsable de Ubuntu, y viendo las razones de Graber, parecía que había probabilidades de que apareciera una bifurcación que se deshiciera del CLA, cosa que ha terminado ocurriendo.
En un principio aparecieron dos forks de LXD, uno de Stéphane Graber, motivado en sus propios principios y otro materializado por Aleksa Sarai, quien en su perfil de LinkedIn se define como “ingeniero jefe del equipo central de contenedores en SUSE”, responsable del mantenimiento de paquetes relacionados con contenedores para SUSE Linux Enterprise y openSUSE, y que contribuye como mantenedor upstream en varios proyectos de Open Container Initiative y en el kernel Linux en materia de seguridad y los entornos de ejecución de contenedores. Trabaja para la corporación del camaleón desde 2015.
Aunque aparecieron dos, todo apunta a que Graber estuvo ayudando a Sarai, así que al poco tiempo terminó quedando solo una llamada Incus. A partir de ahí los acontecimientos han transcurrido de forma rápida, ya que al día siguiente de establecerse su existencia fue adoptado por Linux Containers. En cierto modo, se puede decir que LXD volvía a casa.
¿Y qué hay del LXD original? Dejando de lado los ásperos temas legales, el propio Mark Shuttleworth decidió aparecer por el portal Hacker News para refutar los rumores sobre la posibilidad de que el administrador quedara atado a Ubuntu, dejando fuera al resto de distribuciones. Sin embargo, con un Incus que tiene la bendición y la contribución Stéphane Graber, el aparente apoyo indirecto de SUSE y la condición de producto oficial de Linux Containers, puede suceder cualquier cosa.
Veremos cómo le van a LXD y a Incus y cuál de los dos se termina imponiendo al otro. El primero cuenta con el sustento de Canonical y la gigantesca masa de usuarios de Ubuntu y el segundo puede presumir de ser un proyecto comunitario auspiciado por un organismo independiente del vendedor, lo que podría atraer a la comunidad de LXD. ¿Mala jugada para Canonical?