will delete repositories on free accounts that haven't recorded any activities for a year.

I still sporadically receive emails and support requests for SnortAI_Preproc, a machine learning pre-processor for Snort that I built more than 12 years ago for my M.Sc thesis. Even though the repo itself hasn't seen any activities for >10 years, it keeps getting stars and followers. Under Gitlab's new policy, I would have had to push a stupid commit every year for the past 10 years just to keep it alive.

And my project isn't even an outlier. These patterns are especially common in academic software, where a researcher or a graduate student may bump into your projects months or years after its latest commit.

And this is not to mention preservation: some software may have been actively developed and used in the past, lost momentum at some point for any variety of reasons, and deleting would prevent any later developer from resurrecting it, or from preserving it for historical purposes.

Being a large host of open-source software and planning to delete software that hasn't been updated in a while is like being in charge of a museum and destroying the items that visitors haven't shown interest in the past few months.

If Gitlab has decided to prioritize profit margins over their responsibility to reliably host our free contributions to the world, then they no longer deserve to host anything.

I'm very happy I successfully completed my migration to a self-hosted instance just a few weeks ago, and I don't have to cope anymore with shitty companies that still think that other people's open-source software must be something to exploit for their own profit.


is apparently considering a U-turn (or maybe not?) after the expected community backlash: theregister.com/2022/08/05/git

1. If something as stupid as a data retention plan for open-source projects linked to free accounts comes to your mind, and you don't think in advance that the community is going to be extremely angry at you, then you should change your job, period.

2. I personally don't give a damn about their U-turn. Their announcement already outlined their vision, and they only reverted their plan after a lot of people started taking their projects off. This kind of companies don't deserve trust.

@blacklight You’re using the wrong tool for the job. The best place to archive dormant projects is Software Heritage (#SWH). Also, #Gitlab.com deleting repos of any kind is a good thing b/c that’s the absolute worst forge in existence from a freedom, privacy, human rights PoV. See git.sdf.org/humanacollaborator

@koherecoWatchdog I used to self-host my Gitlab instance and I stopped a while ago. Luckily I never created anything on gitlab.com. I'm on a self-hosted Gitea instance now and I couldn't be happier.

The problem isn't much about me and my projects - all of my repos are mirrored across at least three different locations so I don't have a fear of being "removed". But there's plenty of FLOSS software that still lives on Gitlab, and I'm very concerned about its ability to survive.

@blacklight @koherecoWatchdog Can I butt in and ask why you switched from GitLab to Gitea? Was it because Gitea is a more minimalist approach to things? GitLab has more automation and deployment features.


@biguenique @cambridgeport90 @koherecoWatchdog the main reason was performance and requirements. Gitlab took 3-4 GB of RAM on my server, and it was a mix of several fat Ruby services. Gitea only takes 150-200 MB,way less disk space, and only one service running.

Then there was the fact that Gitlab recently broke git and gitaly now provides its own executable. This is another no go for me: a git server should be able to deal with the vanilla git, not push its own implementation.

Lastly, Gitlab's recent desperate moves towards profitability and its main focus on paying business customers and cloud hosting reminded me that it's bad to use a product made by a company that doesn't prioritize your use-case.

@blacklight @cambridgeport90 @biguenique That’s a lot of good reasons there. I didn’t know #Gitlab had incompatibilities with standard git. That should get a big spotlight because #git is designed to be inherently portable and decentralized. Sounds like Gitlab is using tactics from Microsoft’s playbook.

@koherecoWatchdog @cambridgeport90 @biguenique the change to the "recommended" version of git has actually happened quite recently docs.gitlab.com/ee/install/ins.

Note the "The Git version provided by Gitaly may contain custom patches required for proper operation" out of Microsoft's textbook.

Sign in to participate in the conversation

A platform about automation, open-source, software development, data science, science and tech.