GitLab se retracta de la eliminación de proyectos inactivos

agosto 05, 2022 , 0 Comments

El día de ayer compartimos aquí en el blog la noticia sobre que GitLab planeaba modificar sus términos de servicio para el próximo mes (en septiembre), según los cuales los proyectos alojados en cuentas gratuitas de GitLab.com se eliminarán automáticamente si sus repositorios permanecen inactivos durante 12 meses.

Y ahora GitLab ha revertido su decisión de eliminar automáticamente los proyectos que han estado inactivos durante más de un año y pertenecen a sus usuarios de nivel gratuito y que planeaba introducir la política a finales de septiembre. La empresa esperaba que la medida le permitiera ahorrar hasta un millón de dólares al año y ayudar a que su negocio de SaaS fuera sostenible.

Geoff Huntley, un defensor del código abierto, describió la política como «absolutamente descabellada». «El código fuente no ocupa mucho espacio en disco», dijo. “Que alguien elimine todo este código es la destrucción de la comunidad. Destruirán su marca y su 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», agregó. «Por supuesto, no hay garantía de que siempre estará alojado allí, pero las reglas no escritas del código abierto son que el código está disponible y no lo eliminas».

«Tuvimos mantenedores que extrajeron el código y hubo una gran indignación de la comunidad por eso», dijo, señalando que otros proyectos que dependen de un producto eliminado sufrirán.

“No todas las dependencias pueden compilar”, lamentó.

Sobre el caso GitLab se ha negado repetidamente a comentar sobre su plan de eliminación, y hace unas horas, la empresa, que no desmintió la información de The Register, pero no menciono nada al respecto, solo tuiteó que archivaría los proyectos inactivos en el almacenamiento de objetos:

«Hemos discutido internamente qué hacer con los repositorios inactivos. Tomamos la decisión de trasladar los depósitos no utilizados al almacenamiento de elementos. Una vez implementados, seguirán siendo accesibles, pero tardará un poco más en acceder después de un largo período de inactividad”.

El almacenamiento de objetos es una estrategia para administrar y manipular el almacenamiento de datos como unidades separadas denominadas «objetos». Estos objetos se guardan en un almacén, sin adjuntarse a archivos ubicados en otras carpetas. El almacenamiento de objetos combina los datos que componen los archivos, luego procesa todos los metadatos relevantes antes de asignarles un identificador personalizado.

“Los documentos que hemos visto informaron al personal de una reunión interna programada para el 9 de agosto. La agenda de la reunión describe el plan para eliminar repositorios de códigos inactivos, describiéndolo de la siguiente manera*:

Mencionan que después del 22 de septiembre de 2022, se implementara la política de retención de datos para usuarios gratuitos. Esta rutina limitará la cantidad de meses que un proyecto gratuito puede permanecer inactivo antes de que se elimine automáticamente junto con los datos que contiene.

Se menciona que el tweet de GitLab puede, a los ojos de algunos internautas, contradecir su propia notificación del personal:

“Otros documentos internos que hemos visto mencionan el posible uso de almacenamiento de objetos para archivar proyectos, pero les preocupa que esto aumente los costos de GitLab al crear la necesidad de múltiples copias de seguridad redundantes.

“También vimos discusiones internas que confirmaron que el código de automatización para eliminar proyectos inactivos estaba completo a fines de julio y estaba listo para implementarse después de meses de discusión y trabajo de desarrollo.

“Una de nuestras fuentes nos dijo esta tarde que fue la presión en línea, liderada por nuestros informes, lo que obligó al rival de GitHub a repensar drásticamente su forma de pensar. La noticia de la política de eliminación como un ejercicio para ahorrar dinero provocó furor en Twitter y Reddit”.

De todos modos, el tweet de GitLab fue bien recibido pero también planteó algunas otras preguntas*:

“Si solo el propietario puede recuperarlo, ¿ha pensado en el caso profundamente desafortunado en el que muere un gerente de proyecto y su código se vuelve inaccesible un año después de que cesa su actividad en el sitio*? »

El CEO de GitLab, Sid Sijbrandij, ofreció más información sobre sus planes en el siguiente tweet:

Sin embargo, la empresa se negó a responder a las solicitudes de información de los medios estadounidenses que publicaron esta información.


Some say he’s half man half fish, others say he’s more of a seventy/thirty split. Either way he’s a fishy bastard.