DEV Community

Cover image for GitLab will be deleting dormant projects
Ben Halpern
Ben Halpern

Posted on • Updated on

GitLab will be deleting dormant projects

Here's the story:

GitLab plans to delete dormant projects in free accounts

They plan on saving a quarter in hosting costs by doing this.

I'm curious what the opinions are on this.

Update: GitLab has modified their approach based on some feedback.

Top comments (44)

Collapse
 
cicirello profile image
Vincent A. Cicirello

I don't currently use GitLab, but if I did I'd help them free up space by moving repositories elsewhere.

Some repositories might be dormant because they just work. Relatively small tools that do 1 thing very well may not see many issues, PRs, etc, but may have many users. Albeit, anything of moderate complexity will likely see bug reports and feature requests along the way. But it is possible for simpler tools to have large user base with little such requests.

In other cases, some repositories may be source code to replicate experiments from a journal article or conference paper. These won't change and shouldn't change once the article has been published. Such repositories are deliberately dormant but serve a purpose.

Collapse
 
anwar_nairi profile image
Anwar

They should freeze dormants project instead, deleting code is too harsh. Imagine someone have a vital piece of code hosted there.

Just freeze them on a kind of S3 Glacier hosting, cheap when few reads occurs. If trying to access it, display a confirm message to revive the repo.

Collapse
 
frankfont profile image
Frank Font

Docker did something like this a few years ago -- and I lost some images that just worked. Ohh well.

Collapse
 
drsensor profile image
૮༼⚆︿⚆༽つ • Edited

Or IPFS which is free. They just need to redirect it to cloudflare-ipfs.com/ipfs/:cid/:repo_path

Collapse
 
gklijs profile image
Gerard Klijs

Not a vital piece, but I think I do have a few there. Mostly GitHub through. Worth logging in some time, and maybe move some to GitHub.

Collapse
 
webbureaucrat profile image
webbureaucrat

Importantly, they've backtracked already

But I'm going to offer a really spicy take: I like the idea both as a way to keep costs down for users and to keep the open source ecosystem healthy.

Given a generous warning (which the original plan did include) I think it's a good idea to encourage devs to offer a proof-of-life every once in a while.

How often do you look at a project that's been inactive for, say, three years and wonder what it's deal is and if it's safe to use? Sure, there are some happy, finished, does-what-it-says-on-the-label projects that just don't need a lot of maintenance, but more often, it's stuff that's just sitting there with unpatched dependencies, and even if it works today it will almost certainly break with the next breaking change to the language or framework and not offer an upgrade path. (I plead guilty.)

So you skip over it because you know you can't take on that kind of risk and you don't want to take on the technical debt of maintaining your own fork.

With this change (or something like it--colder storage might be a good compromise) devs who actually do still care about their happy finished projects get occasional reminders to let their users know they're still alive and doing things.

Putting up the occasional comment costs devs almost no time or effort and is a great service to the open source community. I do agree with the backtrack because deletion probably is too extreme, but I don't think this idea is without merit.

(At any rate, paging @ben to encourage him to update the title following the backtrack.)

Collapse
 
nottrobin profile image
Robin Winslow

Have you tried looking through the dependencies of any of your projects and seeing when they were last updated?

It's ridiculously common for packages that everyone depends on to go years without updates. Often that's just called "maturity".

Collapse
 
webbureaucrat profile image
webbureaucrat

Yes, I acknowledged that in my earlier comment so I'm not sure why you're pointing it out to me again.

Thread Thread
 
nottrobin profile image
Robin Winslow

I don't really think you did - you said they exist but you attitude amounted to "if the maintainer can't be bothered to say hi the package/project doesn't matter". I think this is far off the mark because of the volume of those packages in dependency chains.

Thread Thread
 
webbureaucrat profile image
webbureaucrat

That's not what I said at all.

Yes, some finished projects have lots of projects that depend on them.

And of course lots of abandoned projects also have projects that depend on them. So it's not clear what your point is.

Collapse
 
po0q profile image
pO0q 🦄

hum, what defines "activity"?
because I can set a CRON job to create tags artificially or pushing empty commits and "bon appétit" 😈

More seriously, the costs are probably too high and they did not anticipate that. From the Ux perspective, it's kinda bad to downgrade the service, but I guess they don't have the financial power of GitHub/Microsoft.

Collapse
 
katafrakt profile image
Paweł Świątkowski

It's right there in the linked article:

A single comment, commit, or new issue posted to a project during a 12-month period will be sufficient to keep the project alive.

Collapse
 
crayoncode profile image
crayoncode

Looks like an okay definition of active. Although deleting really seems a little drastic. I guess they might also test the waters and see how the community reacts. Even if they increase the time period for dormant projects they still might end up saving a significant share of their hosting cost.

Collapse
 
pinotattari profile image
Riccardo Bernardini

A tiny shell script called by a simple cron job should suffice

Collapse
 
phlash profile image
Phil Ashby

Interesting move...

I've been thinking about a less centralised code sharing/socialising mechanism for a while and it looks like Gitea are heading the the right direction, providing an open source self-hosted equivalent to Git[lab/hub], Bitbucket, Codeberg, etc. but crucially, now looking to support ActivityPub based federation between instances, even with other software forge providers (like Gitllab!) - you can fork to your own instance, and issue PR's back again, federate social aspects (issues, discussions, wiki), user identities are global...

Collapse
 
drsensor profile image
૮༼⚆︿⚆༽つ

"Federated Git Hosting"
I like the idea!

Collapse
 
moopet profile image
Ben Sinclair

The naive interpretation is that all solid, working projects will disappear over time because nobody's found any bugs in them. That can't be the intention.

You don't need to suddenly abandon GitLab if it's what you like, but the nature of git is that it's distributed. You can add remotes on other hosts without causing conflicts; you can use GitHub as a backup for GitLab if you like.

For people worried that they'll lose their work - you're storing it on someone else's computer, so that's always a possibility. Bitbucket could have an outage that loses your data, GitHub could terminate your project because it's anti-something-microsoft-supports if they feel like it... That's what the cloud is.

The problem with projects depending on small utilities that disappear sounds like it's putting the real problem in the spotlight: why are we using a version control system to distribute software?

Collapse
 
olearycrew profile image
Brendan O'Leary 👨🏻‍💻

Hey Ben wanted to make sure you saw this tweet from GitLab.

Collapse
 
jarvisscript profile image
Chris Jarvis

Glad they updated. I'd hate to lose inactive repos. Even if I'm not using it I might want to refer back to that old code for a current project.

Collapse
 
panditapan profile image
Pandita

hmmmmm guess I need to move my projects elsewhere.

Ever since I read this article stating their weird PEO policy (fart in venezuelan spanish hahaha) dev.to/luismejiadev/renuncie-a-mi-... I've been kinda HMMMM with them as a brand/company, this might be the actual push to finally get a github account and move some of my repos there. I've been reluctant cause I like the fox logo (I'm a simple panda) and being a bit of a hipster.

oh well!

Collapse
 
webbureaucrat profile image
webbureaucrat

They updated the article--they've scrapped the plan and are considering moving inactives to slower storage instead.

Collapse
 
tnir profile image
T "@tnir" N

When 100 years later, I believe we will not able to serve all Git repositories people have created for 100 years in the current architecture of GitLab. More intelligent tiering (like Amazon S3) should be required within a decade.

In the first reaction, their communicator should use the term "archived project" for example.

disclaimer: while I am in Core team, not affiliated with GitLab (company)

Collapse
 
leob profile image
leob • Edited

Smacks of a desperate move by a company which might be (just a wild guess) financially unhealthy, otherwise I wouldn't know why they'd do something like this ...

If you want to advertise to the world "we're not trustworthy and not reliable as a company", then this is the perfect way to do it. No, this is a terrible idea, and the very best way to lose existing customers, and scare away potential new ones.

Well anyway, to be honest the advantage of GitLab over Github has always eluded me.

Collapse
 
dpliakos profile image
Dimitris Pliakos • Edited

I believe it's an inconvenience rather than a problem

I understand both the inconvenience and the overall feeling of "My code will not be safe", but if all it takes for me to have free code and page hosting, a free package registry, a free container registry and free CI/CD run time for a project is to write a comment once a year, is not a problem nor much effort (for both my projects and projects that I want to keep around).

We should also point out that they are open source. They are giving their most valuable asset free for all, from individuals to large organizations to host their own instances instead of forcing everyone to use their cloud services.

Of course, it'd be nice to see a cold-storage option (as @khalyomed noted), but I don't plan to help the community by writing it anytime soon. So I don't expect it to get done. Even if we know that notifications are not really enough as we've seen with SSL and domain name expiration examples.

For people questioning their economic status, they seem to go pretty well actually ir.gitlab.com/news-releases/news-r..., but a million USD is a million USD and it doesn't feel quite right to demand someone else to pay for services so I can use them for free (and without any effort).

Probably I should also note that I don't currently use GitLab, but I was using it quite a lot and I do care to keep code that I don't actively maintain alive. I also believe it's the best alternative

Collapse
 
corentinbettiol profile image
Corentin Bettiol • Edited

They're not planning to do that anymore after the backlash.

GitLab U-turns on deleting dormant projects after backlash

Collapse
 
destynova profile image
Oisín

I think that's a really bad idea. There are a lot of projects that are historically relevant that don't need new issues, comments or commits -- look at the Github repos containing projects like Spacewar with source code dating back to 1962, or old versions of Unix tools, or the early K&R C compiler from over 40 years ago.

The motivation behind Gitlab's plan is understandable, but I don't like it. Code doesn't "expire" if you stop updating it.

Collapse
 
fjones profile image
FJones

It depends a lot on what constitutes a "dormant" project (and in turn, the abuse mechanisms to mark repos as non-dormant even though they would technically be dormant...), but in general I suspect the result is going to be a lot of disgruntled users who switch over to GitHub or self-hosted instead.

Collapse
 
katafrakt profile image
Paweł Świątkowski

I've been a big fan of Gitlab since years - actually the oldest post on my blog is the one from 2013 about installing Gitlab instance. But their recent decisions and marketing is... weird and disheartening for me. I'm not leaving them yet, although I feel a bit less secure about hosting some of my code there.

Besides, it's really hard for me to understand what are the real cost of hosting non-active repositories (unless they are huge). Sounds like a flaw in their architecture.