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.

theregister.com/2022/08/04/git

Follow

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.

· · Web · 3 · 3 · 13

@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

@blacklight BTW, theregister is a Cloudflare site, so CF;NB. I suggest following mg@101010.pl. It’s a beneficial bot that will follow you back and DM you free-world alternatives when you share a Cloudflare link.

@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 I know Software Heritage is mirroring #Gitlab.com projects, but I think it’s on a per request basis. What we need is #SWH to automatically grab all dormant projects that are threatened, instead of just archiving the specific projects people request. Hmm.. or perhaps we just need a bot that detects dormant projects and mechanizes mirror requests to SWH.

@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.

@blacklight

#Showerthought. I wouldn't even be surprised if the information leak was part of the strategy. VC investor pressure in tough economic times, combined with persistent losses.. more enterprise focus, positioning for a buyout / takeover?

A simple leak as emergency measure, showing who you care about most. Gets rid of the most principled, mostly copy-lefted (hence less 'valuable') projects, leaving the exploitable OSS behind. May not care about reputation damage in FLOSS circles..

@blacklight

I may be totally wrong about this, but I always had the feeling that #Gitlab's adoption path was mostly by enterprise-first exposure, in contrast to #Github.

I.e. where people first learn to know to navigate the quirky (imho, bad) UX and explore features + workflows in their own company's professional work environment and only then decide to use it for #FOSS projects.

@humanetech my impression is that tried for a while to walk a thin line - getting the FLOSS community onboard (they'd just be a fancy empty container without us) while being profitable.

The problem is that they've struggled to achieve even a single quarter of profitability since their birth.

And when recession hits, or the VCs just decide to tighten their pursue, either you show that you're profitable, or you go out of business. This is the norm in every industry.

But there are several ways to increase profitability. The good one is to offer premium paid features, or to onboard and retain more business customers (something that Gitlab has been doing quite poorly: we used Gitlab for enterprise in my previous company, and it often took days to get in touch with somebody from their customer support while our repos were down or inaccessible, resulting in days of lost productivity). The bad one is to hurt their own bottom line and make the basic service worse unless you pay.

If you want to be profitable, then you'd better create something new that people would pay for (or even just retain more business customers with a better service), not restrict or remove things that people expect from your service just to push them to a paid account.

My feeling is that Gitlab won't last long. Their VCs are getting impatient for profits, the company is getting desperate for profits, but on one side they can't compete in the business space with products like Github that can allocate far more resources for paid customers, and on the other side they've done enough to alienate the FLOSS community that constitutes the bedrock of gitlab.com.

@blacklight

> My feeling is that Gitlab won't last long.

I fully expect for a long time some kind of exit coming. "Gitlab has been acquired by [SomeBigTech]" for a nice smallish price.

Like Amazon would be a candidate, and they can lead customers to AWS with deeper integrations.

@blacklight
Between this and their abortive attempt to begin performing user tracking, I've lost interest in them.

Honestly, all they would've had to do was add an opt-out button per account. The community wouldn't have been as angry, and they would've still saved a lot of storage.

They could've started sending notifications for each old repo and given users an option to stop the process without having to make useless commits.

It all smacks of desperation, and is sad

Sign in to participate in the conversation
Mastodon

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