GitLab a communiqué en interne son intention de supprimer automatiquement les projets inactifs des comptes gratuits à partir de septembre. Après que The Register a divulgué les plans, la plate-forme DevOps a reculé après de nombreuses réactions négatives.
En retirant automatiquement les projets dormants, GitLab voulait réduire d’un quart les coûts d’hébergement. Selon le personnel interne, cela devrait économiser jusqu’à 1 million de dollars par an. GitLab souhaitait supprimer, par automatisation, tous les projets qui n’avaient pas été édités, modifiés ou renouvelés depuis un an ou plus.
Critique virulente aux rumeurs
Selon The Register, GitLab s’attendait à des réactions négatives à ses projets. Par conséquent, l’intention était de donner un avertissement à chaque utilisateur d’un compte gratuit. Cependant, selon GitLab lui-même, son segment gratuit est un élément essentiel du recrutement de nouveaux utilisateurs et clients. L’annonce de la suppression automatique de certains projets était donc en contradiction absolue avec leur propre philosophie.
En mai dernier, GitLab a élargi les capacités des comptes gratuits. Elle a ensuite ajouté le support pour les déploiements Kubernetes « pull-based ».
Cédé à la critique intense
Les réactions aux plans divulgués se sont succédé rapidement. Au point que GitLab a été forcé de réagir. Alors qu’ils n’étaient initialement pas disposés à faire de commentaires, ils le font maintenant par un message sur Twitter. Les projets inactifs à long terme ne seront pas automatiquement retirés de la circulation. GitLab déplace alors ces dépôts vers une autre partie du serveur. Ils y seront toujours disponibles, mais leur chargement prendra un peu plus de temps.
En attendant, la question se pose de savoir si les projets inactifs seront toujours accessibles à tout utilisateur, ou seulement au développeur. En outre, d’autres documents que The Register a pu examiner montrent que GitLab avait effectivement prévu de supprimer définitivement les projets inactifs. L’annulation de ces plans a fait réfléchir d’autres organisations. Software Heritage, par exemple, cherche des moyens de préserver son stock de projets sur GitLab.