After Backlash, GitLab U-Turns on Deleting Dormant Projects

"GitLab has reversed its decision to automatically delete projects that are inactive for more than a year and belong to its free-tier users," reports the Register. Thursday GitLab tweeted:

"We discussed internally what to do with inactive repositories. We reached a decision to move unused repos to object storage. Once implemented, they will still be accessible but take a bit longer to access after a long period of inactivity."

But the Register says they've seen internal documents from "well-placed sources" showing that GitLab had originally "hoped the move would save it up to $1 million a year and help make its SaaS business sustainable." And the company had spent a long time preparing for such a move: Documents we have seen gave staff notice of an internal meeting scheduled for August 9. The agenda for the meeting lays out the plan to delete dormant code repositories... Other internal documents seen by The Register mention the possible use of object storage to archive projects but express concerns that doing so would increase GitLab's costs by creating a need for multiple redundant backups.

We have also seen internal discussions confirming the automation code to delete inactive projects was completed by the end of July, and was ready to roll out after months of debate and development work.

One of our sources told us [Thursday] that it was online pressure, led by The Register's reporting, that forced a dramatic rethink at the GitHub rival. Word of the deletion policy as a money-saving exercise sparked fury on Twitter and Reddit.
On GitLab's Twitter feed Thursday, someone raised an interesting point about GitLab's new promise to move inactive repos into object storage. "Wait, does 'inactive' mean repositories that have no new commits? Or only those without new commits AND without read access by cloning / fetching?"

And GitLab's CEO/co-founder Sid Sijbrandij replied, "We're not sure yet. Probably all write operations would keep a project active, creating an issue, a merge request, pushing changes to a branch, etc. We might also keep it active as long as people are doing read operations such as cloning, forking, etc."

Friday Sijbrandij tweeted this status update:

"Archived projects is a user activated state that signals intent. We're not sure yet but very likely the storage type used is orthogonal to that. Our current plan for object storage would keep the repos visible to everyone."

Depository....

[Puls4r]

And this is the problem when a site goes from non profit to profit. Now they answer to share holders who don't understand what it means to document and hold items for later use. Yeah, that 40 year old copy of to kill a mockingbird may not have been checked out of the library recently. That doesn't mean we burn it. Assholes.

Re:

[gweihir]

Indeed. It also takes not much storage and no CPU or network bandwidth. And if they add a note "dormant project, download may take an hour or more to start", they can, for example, put it on slow-ass very cheap storage. It is not like multi-tier storage is somehow an obscure idea. It make absolutely no sense to delete this stuff. This is a sign of idiots with no clue calling the shorts.

Re:

[bill_mcgonigle]

There are nonprofit hospitals that make net income of hundreds of millions of dollars per year, and there are private small businesses that struggle to break even every year. You might be talking about public corporations which is a completely separate issue. Some private corporations issue private investor shares, but those are more likely to be concerned with long-term return, not shooting themselves in the foot for quarterly profits.

Which category is Gitlab in?

I will buy them three 10TB SATA drives to st

Need a more flexible storage architecture

[test321]

the possible use of object storage to archive projects but express concerns that doing so would increase GitLab's costs by creating a need for multiple redundant backups.

They really need to develop an architecture where the projects are stored in different cloud depending on how active they are, or who accesses them them most. If dormant projects can be placed in a servers far away in e.g. Indonesia and western users have long ping, that's fair enough.

Re:

[splutty]

This has been a solved problem since the 50's/60's when IBM had their multi tier mainframe architectures.

This isn't rocket science, and the fact cloud providers want you to think it is, just goes to show what their primary goal is (hint: It's not providing reliable storage)

Re:

[tlhIngan]

No, they need to rethink how they do storage.

Git makes storage very simple because it does a lot of the work that a de-duplication mechanism would do. You just need to hijack the way it does things to take advantage of it. But if you're a site whose specialty is hosting repositories via Git, this should be your expertise.

Git makes it easy to implement copy-on-write semantics, so a "fork" shouldn't take more than a few bytes to make, yet you can claim the whole repository as part of the free account. So a Li

Such a surprise...

[gweihir]

A bad idea is a bad idea. This is a very bad idea that only an MBA-moron could have come up with. Dormant projects cost almost nothing. Projects that get downloaded are not dormant, but serve as demonstration that the service works and hence (indirectly) generate revenue. You really have to understand absolutely noting to think this "save a penny, lose a million" type of idea makes any sense.

Re:

[Ostracus]

There's a reason tape still exists even though "dormant [code] costs almost nothing" on all other forms of storage.

Re:

[gweihir]

Indeed.

Re:

[derplord]

> Projects that get downloaded are not dormant, but serve as demonstration that the service works and hence (indirectly) generate revenue.
Pray tell me how GitLab offering downloads and storage for free, without ads and allowing hotlinking to files "generates revenue"?

Because I'm gonna make a fuckton of moolah if you can reveal me the sekritz for this business model.

Re:

[gweihir]

If you have to ask, then you do not understand how this type of business works at all. Here is hint: GitLab had to be hit repeatedly with a clue-bat, but they did finally see how bad the mistake they were about to make was,

Re:

[NFN_NLN]

> Because I'm gonna make a fuckton of moolah if you can reveal me the sekritz for this business model.

Duh, the CIA pays them to slip back doors into code without a git comment :)

Re:

[Tablizer]

> Dormant projects cost almost nothing.

Not necessarily. Spy-bots and search engines use up server resources to see if anything changed every month or so.

Re:

[gweihir]

> Dormant projects cost almost nothing.

Not necessarily. Spy-bots and search engines use up server resources to see if anything changed every month or so.

Then add a captcha and a robots.txt. It is not hard to do.

Re:

[Tablizer]

Captcha's also take up CPU, and snoop-bots ignore robots.txt.

Re:

[gweihir]

Yes, so? It is not much CPU and the whole point is to not to save on CPU but to not need to get data from slow background storage if the captcha does not get solved.

Gitlab is still lowering storage quota to 5 GB

[bigbang137]

Even so, Gitlab is going ahead with its plans to lower the total storage quota for a user, across all their repositories, to just 5 GB. It was previously effectively unlimited. 5 GB is nothing. A reasonable limit would have been 1000 GB. Just mirroring the master branch of the Linux kernel repo requires 3.5 GB. That leaves 1.5 GB for everything else. The MBAs have turned Gitlab into something useless.

Re:

[Ostracus]

Consider it an incentive to not bloat one's code.

Re:

[bigbang137]

Go say that to Linux and various other big projects. Also, stop using a computer since your OS is almost certainly bloated.

Re:

[StormReaver]

The MBAs have turned Gitlab into something useless.

This is the predictable future of all cloud services you don't own yourself.

Re:

[jmccue]

No mods, but yes, or they do what Mocrosoft did with github copilot.

I was starting to look elsewhere to move off github. I guess gitlab is off the list now.

Re:

[bigbang137]

I am considering using Bitbucket as a secondary remote. They look to permit 4 GB per repo, with no limit on the number of repos. Moreover, they have never reneged on their offering. The unverified rumor, however, is that they severely cap the upload bandwidth when pushing to a repo.

Re:

[Dutch Gun]

In fairness to GitLab, 5GB is plenty of space for a typical user. That's literally a lifetime's worth of source code for most. The average user does not really need to fork and host the entire Linux kernel or other giant projects on their free account.

Re:

[bigbang137]

Why would a single free user use Gitlab when they can get so much more out of Github. I used to use Gitlab as a secondary remote, but now that I see them collapsing, it's time to move away.

Re:

[93 Escort Wagon]

Why would a single free user use Gitlab when they can get so much more out of Github.

It starts with "M" and ends with "icrosoft".

Re:

[echo123]

Just asking, because I have no idea, but if someone using GitLab/GitHub forks a large repo like the Linux kernel and makes changes using their own account, wouldn't their own account with the fork only reflect unique DIFFs of the Linux kernel without requiring the large diskspace required for everything, (assuming it was forked using the same hosting service)?

Re:

[Dutch Gun]

That's a good point. Apparently, that's how GitHub works behind the scenes: https://github.blog/2015-09-22... [github.blog]

However, I suspect that the size of the cloned repo is still counted against your account. After all, if the original repo goes away, your account becomes the sole repository responsible for the data storage. It's kind of a weird accounting problem when data is shared behind the scenes, I guess.

Re:

[NFN_NLN]

> In fairness to GitLab, 5GB is plenty of space for a typical user.

"But I want to check in the dependent binary blobs of downstream projects that aren't open source."

Inactive?

[countach]

Sounds possibly ok, if inactive means nobody read from it for several years (although far from ideal).... but if inactive means nobody sent an update, that's terrible. It should be everyone's aim to create a project so perfect it doesn't need updates, and if everyone is still accessing it and using it as a read repository, the last thing you want to do is delete it. ... of course, if you make that the definition, someone will probably make a bot to read every project every year... may as well keep everythin

Re:

[Puls4r]

Oh yes, that's a PERFECT idea. Because no one EVER looks up how to solve a problem and finds a 12 year old snippet of code that does it. (Which I just did this morning working with nested arrays).

Glad they did

[buck-yar]

Glad they changed their minds. That's a lot of work from many people.
I can understand their side too though. Storage isn't free, especially multiple up to date backups.
Maybe could be maintained by libraries like archive.org. They could keep a read only copy. Someone could host it on their own git website if they wanted to reactivate and maintain it again.

HSM

[sphealey]

I'm so old I remember the concept of Hierarchical Storage Management. One would think projects that have been dormant for 10+ years could have everything except their most recent release archived off to triple-redundent DLT tape and be brought back on request within a standard time period, say 24 or 48 hours.

Re:

[jmccue]

I think this is a good idea, but...

They may have to hire a real person for this and pay real money. God forbid a commercial company take even 1 penny away from their bonuses.

Re:

[bigbang137]

Yup, this is exactly what happens when the suits take over. Talent is driven out, and short-termism is all that matters. I think their biggest mistake was going public.

pennywise pound foolish

[Virtucon]

Yes, let's push more developers away from your platform, creating negativity and bad PR.

I'm sure they could crowdfund $1m or how about something like, I don't know using compression?

Services cost money

[bradley13]

Honestly, I find the quantity and quality of free services astounding. For professional reasons, I have small repos on all of the major services, and none if them charge.

Consider this: I'm approaching retirement. It us unlikely that I will go delete all those repositories, because - who knows - I might want them or simply for sentimental reasons.

So...how long should those repositories be kept, if I don't use them? One year seems short, but maybe 2-3 years? Five years?

Re:

[bigbang137]

Storage isn't really that expensive. Gitlab makes it appear hyper-expensive since they don't look to have their own hardware or even know how to use public clouds efficiently. Gitlab prefers to pay useless MBAs and product owners more than it pays developers, also micromanaging developers to an extent that they have no sense of ownership. I squarely blame the suits.

So long as git itself is FOSS, you can up sticks..

[bb_matt]

... that's the beauty of a distributed version control system. So long as an organisation using git to manage version control has a coherent strategy, heck, just one person needs to ensure they have the latest history of all branches and it can be moved - to self-hosting if needs be.

The reality is, gitlab and github provide an infrastructure and some very cool tools - but the underlying aspect of git is still sound.
NEVER lose sight of that, that ultimately, what both offer, is entirely up to you as to how m

Re:

[bb_matt]

And heck, I've been a web developer long enough to remember using FTP for years - way before most people even knew what CVS was.
It was largely skipped over, because web development back then was considered somewhat of a "toy" (with good reason)

Version control in those crazy days on the web, was mostly none-existent. Whatever existed on the web server, was the source of "truth" and was vanishingly easy to overwrite with even just two devs working on code and not communicating.

"Oh fuck, I just broke the sites

Charge you to delete your projects!

[gabrieltss]

We pay for Gitlab SaS and if we want to delete a repo or remove all the objects from it Gitlab wants to charge us big $$$$ to do so. They want us to keep paying for the space we are using for it - even though we NO LONGER NEED the repo! So their stance on this whole thing is total BULLSHIT! Both Gitlab and github have become totally anti-developer the way they are doing things. Gitlab can guarantee some show throwing at renewal time, if we don't migrate to something else and tell them to take a F!ing hike!