The Register revelaba la exclusiva de que GitLab, el principal rival de GitHub en el campo de las plataformas de repositorios, planeaba poner en marcha una nueva política a partir de finales de septiembre: la eliminación automática de todo proyecto que permanezca inactivo durante un año y que sea propiedad de un usuario con cuenta gratuita. GitLab pretendía que el consiguiente ahorro de hasta 1 millón de dólares al año ayudara a la sostenibilidad de su negocio.

GitLab quería eliminar proyectos alojados con más de un año de inactividad

La noticia no cayó nada bien entre la comunidad de usuarios. De hecho, The Internet Archive y la organización de preservación de código Software Heritage llegaron, incluso, a comenzar a planificar un modo de preservar los tesoros —por inactivos que sean— que guarda GitLab.

GitLab da marcha atrás, no eliminará proyectos inactivos durante un año

Hasta el punto de que hoy, finalmente, y pese a no haberse pronunciado sobre la exclusiva de The Register, la compañía admitía en Twitter que habían estado "discutiendo internamente qué hacer con los repositorios inactivos"… y que finalmente habían tomado la decisión de mover los repositorios no utilizados a una plataforma de almacenamiento basado en objetos:

"Una vez implementada la medida, seguirán siendo accesibles, pero tomará algo más de tiempo poder acceder después de un largo período de inactividad".

El tuit de GitLab da a entender —aunque no lo afirma— que la decisión revelada por The Register nunca llegó a tomarse, pero el medio estadounidense habla explícitamente de 'marcha atrás' de la compañía basándose en documentos internos a los que tuvieron acceso, que incluían el orden del día de una reunión interna programada para el próximo martes.

De hecho, según la publicación, GitLab había contemplado, ciertamente, la apuesta por el almacenamiento basado en objetos… pero la había descartado, preocupado por el hecho de que hacerlo aumentarían los costes al generar la necesidad de múltiples copias de seguridad redundantes.

Los recursos externos pueden hacer referencia al código de los proyectos inactivos y, al eliminarlo, se perderá una copia maestra verificada a la que se puede hacer referencia (no se garantiza que las copias no oficiales estén libres de actividad maliciosa), por lo que en lugar de eliminar, probablemente sería más óptimo archivar el estado manteniendo la capacidad de acceder al código en modo de solo lectura.

Para ahorrar espacio en disco al almacenar bifurcaciones basura, puede usar métodos más eficientes para manejar duplicados, por ejemplo, GitHub almacena todos los objetos del repositorio principal y sus bifurcaciones asociadas juntas para evitar la duplicación de datos, separando lógicamente la propiedad de las confirmaciones.

Geoff Huntley, un defensor del código abierto y participante de la comunidad abierta .Net, describió la política como «absolutamente salvaje».

“El código fuente no ocupa mucho espacio en disco, que alguien elimine todo ese código es destrucción de la comunidad. Van a destruir su marca y buena voluntad. La gente aloja su código allí porque existe la idea de que estará disponible para el público en general para reutilizarlo y mezclarlo.

Por supuesto, no hay garantías de que siempre estará alojado allí, pero las reglas no escritas en código abierto son que haces que el código esté disponible y no lo eliminas. Tuvimos mantenedores que extrajeron el código y hubo una gran indignación en la comunidad al respecto», dijo, señalando que otros proyectos que dependen de un producto eliminado sufrirán.

«Todas las dependencias no se pueden compilar», lamentó.

Fuentes:
https://www.linuxadictos.com/gitlab-eliminara-proyectos-alojados-con-mas-de-un-ano-de-inactividad.html

https://www.genbeta.com/desarrollo/que-pasara-finalmente-repositorios-inactivos-gitlab-te-explicamos-cambio-postura-compania

https://www.theregister.com/2022/08/05/gitlab_reverses_deletion_policy/