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.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (44)
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.
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.
Docker did something like this a few years ago -- and I lost some images that just worked. Ohh well.
Or IPFS which is free. They just need to redirect it to cloudflare-ipfs.com/ipfs/:cid/:repo_path
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.
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.)
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".
Yes, I acknowledged that in my earlier comment so I'm not sure why you're pointing it out to me again.
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.
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.
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.
It's right there in the linked article:
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.
A tiny shell script called by a simple cron job should suffice
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...
"Federated Git Hosting"
I like the idea!
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?
Hey Ben wanted to make sure you saw this tweet from GitLab.
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.
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!
They updated the article--they've scrapped the plan and are considering moving inactives to slower storage instead.
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)
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.