GitLab Plans To Delete Dormant Projects in Free Accounts (theregister.com) 91
UPDATE (8/5): "GitLab has reversed its decision to automatically delete projects that are inactive for more than a year and belong to its free-tier users," the Register reported Friday.
Thursday the same site had reported that GitLab planned to automatically delete projects if they've been inactive for a year and are owned by users of its free tier. From that report: The Register has learned that such projects account for up to a quarter of GitLab's hosting costs, and that the auto-deletion of projects could save the cloudy coding collaboration service up to $1 million a year. The policy has therefore been suggested to help GitLab's finances remain sustainable. People with knowledge of the situation, who requested anonymity as they are not authorized to discuss it with the media, told The Register the policy is scheduled to come into force in September 2022. GitLab is aware of the potential for angry opposition to the plan, and will therefore give users weeks or months of warning before deleting their work. A single comment, commit, or new issue posted to a project during a 12-month period will be sufficient to keep the project alive. The Register understands some in the wider GitLab community worry that the policy could see projects disappear before users have the chance to archive code on which they rely. As many open-source projects are widely used, it is feared that the decision could have considerable negative impact.
Thursday the same site had reported that GitLab planned to automatically delete projects if they've been inactive for a year and are owned by users of its free tier. From that report: The Register has learned that such projects account for up to a quarter of GitLab's hosting costs, and that the auto-deletion of projects could save the cloudy coding collaboration service up to $1 million a year. The policy has therefore been suggested to help GitLab's finances remain sustainable. People with knowledge of the situation, who requested anonymity as they are not authorized to discuss it with the media, told The Register the policy is scheduled to come into force in September 2022. GitLab is aware of the potential for angry opposition to the plan, and will therefore give users weeks or months of warning before deleting their work. A single comment, commit, or new issue posted to a project during a 12-month period will be sufficient to keep the project alive. The Register understands some in the wider GitLab community worry that the policy could see projects disappear before users have the chance to archive code on which they rely. As many open-source projects are widely used, it is feared that the decision could have considerable negative impact.
Bad cost estimate (Score:5, Insightful)
such projects account for up to a quarter of GitLab's hosting costs
You'd have to really screw up your software architecture for that to be true. Inactive storage just doesn't cost that much.
Re: (Score:2)
Inactive storage just doesn't cost that much.
Who knows... They've probably stuffed all the repositories on an enormous Elastic Block Store provisioned for IOPS.
In that case, they could save a lot by moving Repository storage to a File-Based PaaS storage service.
Re:Bad cost estimate (Score:4, Insightful)
They've probably stuffed all the repositories on an enormous Elastic Block Store provisioned for IOPS.
I'd say that qualifies as screwing up the software architecture, wouldn't you?
Re: (Score:1)
> Inactive storage just doesn't cost that much.
Maybe the real cost is network and CPU for when snoop crawlers visit, scanning dormant projects.
Or are they really dormant? If they are coded well maybe they don't need maintenance visits. Granted, such is probably rare as to make false positives a non-problem.
Re:Bad cost estimate (Score:4, Insightful)
Re: (Score:2)
We're talking about gitlab. Heavily biased towards TEXT objects.
Re: (Score:3)
That's not accurate. Active storage costs money. A lot of it. Go check pricing on 5 or 6 hundred terabytes of active cloud storage. It is bleeping expensive. Not to mention backups. Which add a whole new level of ridiculous when it comes to cost.
And this is why "the cloud" isn't always the right answer. Sometimes the right answer for a low-volume project or site is a Raspberry Pi attached to a suitably sized SSD, stuck in a broom closet somewhere, with a spare copy of the data stored on a second SSD offsite in a second closet, just in case the first one dies.
Re: (Score:2)
I think you described my home Git server to a "T", with Borg Backup slinging snapshots of the drive both to a NAS, as well as Borgbase for offsite backups.
Re:Bad cost estimate (Score:5, Insightful)
But even if their current storage worked differently: I'd be very sympathetic to them saying "if the project is inactive for 12 months, it will be available in read-only mode (git repo exported to static files, for example), it has longer longer latencies to access it (due to not being on fast storage), and if the project is to be reactivated due to new activity, it will take a couple of minutes (or even hours)". Because then at least the data would still be accessible. But outright deleting it?
There have been projects on Github (their competitor) that have been inactive for 12 years or so that I stumble upon every once in a while that are still very useful. It would be a real shame if those all get deleted automatically.
And if Gitlab truly wants to be a real competitor to Github, this is clearly the wrong direction to go in.
Cheaper storage (Score:3)
But even if their current storage worked differently: I'd be very sympathetic to them saying "if the project is inactive for 12 months, it will be available in read-only mode (git repo exported to static files, for example), it has longer longer latencies to access it (due to not being on fast storage), and if the project is to be reactivated due to new activity, it will take a couple of minutes (or even hours)". Because then at least the data would still be accessible.
Totally agreeing with that:
Moving inactive project to much cheaper (even if much crappier performance) storage is better than those project being lost forever.
There are countless scientific research project, written by a PhD (or Master) student, uploaded to public git repositories and then left untouched. Two year down the line, somebody else is interested in that research and need to check out the code, perhaps fix and patch some bugs and/or integrate it into a more modern project.
By then the previous stud
Re:Cheaper storage (Score:5, Informative)
Moving inactive project to much cheaper (even if much crappier performance) storage is better than those project being lost forever.
That [twitter.com] is what they are doing:
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.
Yay! (Score:2)
Once implemented, they will still be accessible but take a bit longer to access after a long period of inactivity.
And there was much rejoicing!
Re: (Score:2)
Re: (Score:2)
This and disabling the more expensive features. For example, the issues section could go read-only until there's a commit, allowing dynamic files in an expensive SQL database to be replaced with some static web pages and a backup of the sql database.
I'd also be sympathetic to deleting inactive repos with large binary checkins. A multi-gigabyte repo for a project no one is updating is probably doing something gitlab wasn't meant for anyway.
Re: (Score:3)
There have been projects on Github (their competitor) that have been inactive for 12 years or so that I stumble upon every once in a while that are still very useful. It would be a real shame if those all get deleted automatically.
And if Gitlab truly wants to be a real competitor to Github, this is clearly the wrong direction to go in.
They aren't trying to compete in the "free" space or being a free archival service. Github and Gitlab make money from their enterprise offerings, that's where they actually compete with eachother.
Re: (Score:2)
Well, Bitbucket, which started out as (only?) supporting Mercurial, which is why I used them, after being sold to Alsation, decided to drop Mercurial support and deleted all the Mercurial repositories, active or not though with lots of warning. Still it was the shits to see others work vanish and some of mine (mostly tickets and such) also vanish. Now I keep 2 providers besides my local one and don't deal with Bitbucket
Re: (Score:2)
Quoted for hilarity. I'm picturing a team of German Shepherds with their tongues out, using white box PCs, deleting your repositories.
Re: (Score:2)
The problem is, these projects are only dormant from a particular perspective - no updates from an owner perspective, but the project could be accessed on a regular basis.
So inactive storage wouldnt work for those projects - that would be for projects which are archived and there would be an accepted delay for retrieval for those.
Re: (Score:3)
The problem is, these projects are only dormant from a particular perspective - no updates from an owner perspective, but the project could be accessed on a regular basis.
So inactive storage wouldnt work for those projects - that would be for projects which are archived and there would be an accepted delay for retrieval for those.
Yeah, that's pretty much what I was thinking (and would have posted as the first post, but got busy doing other things and never clicked "post").
If nobody is using it or pulling from it or viewing from it at all, maybe deleting might make sense, but using "no commits" as a metric means that mature projects that people depend on will suddenly disappear, and people will be forced to do useless "maintenance" commits to prevent things from being deleted. And if the original maintainer is dead... this potential
FSF's Savannah (Score:2)
What we really need is a 501(c)(3) foundation that exists to provide basic git servers for use by open source projects
Replace "open source" with "free software" and you've more or less described Savannah, a free software repository host operated by Free Software Foundation.
Re: (Score:2)
What we really need is a 501(c)(3) foundation that exists to provide basic git servers for use by open source projects
Replace "open source" with "free software" and you've more or less described Savannah, a free software repository host operated by Free Software Foundation.
The reason almost nobody uses it is because the FSF has bought too thoroughly into their free software ideology to provide a service that's generally useful for the public. For Free Software zealots, the idea of building something that touches closed-source software is too gross to imagine. For the other 99.999% of people who write and use software, they use a non-free operating system every day, they interact with non-free software continuously, and while they would prefer that free software, or at least
Re: (Score:2)
The reason almost nobody uses it is because the FSF has bought too thoroughly into their free software ideology to provide a service that's generally useful for the public. For Free Software zealots, the idea of building something that touches closed-source software is too gross to imagine.
Though funnily enough they weren't too keen on ensuring their GCC was only used to produce binaries licensed under a free license, guess they thought the project would be dead in the water if they did that.
It's unfortunate that the more "free" solution that is accepting of anybody is the one from Microsoft (and of course GitLab too) and the one that you have to apply to be accepted for is by the FSF.
Re: (Score:2)
I think this is probably the issue. Gitlab is a software company, they make their money from selling enterprise licenses to self-host the Gitlab software. Sure, they make some money selling cloud subscriptions, but I doubt that's the main income. I also suspect their enterprise sales aren't as plentiful or lucrative as they'd like - a lot of shops use a cloud hosted service (most likely Github, I guess).
As such, my guess is that the online presence is a hacked about version of the enterprise self-host softw
Re: (Score:3)
There's this other thing where I have a lot of code that I haven't touched in 10 years because it works, it's complete, and the specs never changed. A good example is the 1D barcode software that I wrote long ago. There's nothing to change and nobody is creating new 1D barcode symbologies.
Re: (Score:2)
Microsoft owns Github, which will be the only half-decent git service that you can use for "write and forget" code - of which, lets face it, there is a lot. Not everyone writes code that's so useful it gets a following of contributors and helpers - yet some of that code is still useful, even if just as a reference or as fodder for codegreper and the like.
Of course but who is going to pay for it all? Providing this free service costs a lot of money and really its only value is to try and get people comfortable with their ecosystem such that if they have a need for the commercial it will be the first port of call. Kind of like the way Microsoft and Apple give away software (or offer big discounts) to education providers, it's an investment that costs them a huge amount of money that they hope to get a return on.
Re: Bad cost estimate (Score:1)
How about you go out buy at GitLab some SSDâ(TM)s.
Somebody can just move those âfreeâ(TM) accounts to some arrays of SSD units.
Re: Bad cost estimate (Score:2)
TANSTAAFL applies.
Re: (Score:2)
I think excluding inactive projects from local search would be a lot more reasonable than deleting them altogether. Ditto issue tracking and similar features that don't directly interact with the git archive.
What's the point of code control if disappears? (Score:2)
Seriously?
Certainly a SC has a roll as an active tool during heavy development, and GitHub is great for that.
But it also has a roll as a repository of *non*-active code so that other people can find it online.
It's the reason most of us end up on GitHub, at least at one point or another.
Re:What's the point of code control if disappears? (Score:4, Informative)
The article was about GitLab not GitHub.
Re: (Score:2)
Re: (Score:3)
Yeah. I guess GitLab does not really want to be a GitHub competitor for open source work. An open source project can go YEARS without a commit: That does not mean they are dead forever. The last thing we want is risk to loss is development history or code that can represent thousands of hours of development, over some shitty "cost-saving policy"
Re: (Score:2)
If you don't want to lose your work over some 'shitty cost saving policy', PAY for access. Or do cost saving policies count as 'shitty' only when OTHER people use them?
Re: (Score:2)
This.
Right now theres a big push in open source to guilt companies into paying for time and effort spent on building and maintaining open source projects that are widely used - this is just another aspect of that whole thing. If you are using something for free, you cant rely on it as much as you can if you pay for it - you are taking advantage of someone elses good will and that always has downsides.
Re: (Score:2)
If you don't want to lose your work over some 'shitty cost saving policy', PAY for access. Or do cost saving policies count as 'shitty' only when OTHER people use them?
I think what you're missing is that the original creator almost certainly doesn't lose the work. The people who lose the work are the people who might have found it years later, discovered that it was the perfect tool for some esoteric task that ten people do every year, and used it.
The people creating it are giving their hard work to the community as a whole. Why should they be expected to pay for a donation? That's not the way donations work in any civilized society. You can't really expect me to pay
Re: (Score:2)
If you ask me to do that, then all those other people who freeload off of the software I create will have to pay me to obtain a copy of the software I've written so that I can use that money to offset the cost of making the content available.
What's wrong with that? Perhaps you weren't aware that this is exactly how software distribution was done before the internet - or at least before it was feasible to transfer significant amounts of data over it. Yes we had to pay for media and shipping and that was a lot more than it costs for equivalent server hosting these days.
RMS has explicitly called this out in Free Software discussions that "free" does not mean "gratis" because software distribution itself has costs.
Re: (Score:2)
If you ask me to do that, then all those other people who freeload off of the software I create will have to pay me to obtain a copy of the software I've written so that I can use that money to offset the cost of making the content available.
What's wrong with that? Perhaps you weren't aware that this is exactly how software distribution was done before the internet - or at least before it was feasible to transfer significant amounts of data over it. Yes we had to pay for media and shipping and that was a lot more than it costs for equivalent server hosting these days.
Yeah, and we call those the dark ages of computing for a reason. One of the greatest achievements of the Internet was bringing distribution costs down to so close to zero that they almost aren't even worth talking about. But now, to make more profit so that shareholders will be happy, folks are pushing back and trying to drive us back into those dark ages, where people pay orders of magnitude more than it should reasonably cost.
The real problem with the push towards paid plans that cost a minimum of $228
Re: (Score:2)
Yeah, and we call those the dark ages of computing for a reason. One of the greatest achievements of the Internet was bringing distribution costs down to so close to zero that they almost aren't even worth talking about.
Why should gitlab have to pay that cost?
So if the free tier goes away or becomes too much of a burden, you'll see everybody switch to running their own git servers. But those won't be on the web, so they won't be indexed, so unless you know that what you're looking for exists, you won't be able to find it.
Running a webserver is a trivial task. If you actually believe this then it's kind of funny that the entire modern open source movement could be extinguished by taking out GitLab...since Microsoft already owns GitHub.
We will not go gentle into that good night. Freedom should burn and rave at close of day. Rage, rage against the dying of the light.
Rage against the corporations for not giving us free stuff! How dare they! Me Me Me! I WANT I WANT I WANT!
Re: (Score:2)
Why should gitlab have to pay that cost?
Because Gitlab poses their services as something people should move to in order to get away from Github, And Github pays the "costs" for their users.
It turns out the presence of all this free software on their platform can be quite helpful not just for the OSS community in general, But also their users who are paying them money tend to depend on a lot of the free projects in their software development.
The cost of hosting these is negligible compared to a c
Re: (Score:2)
Why should gitlab have to pay that cost?
Because Gitlab poses their services as something people should move to in order to get away from Github, And Github pays the "costs" for their users.
And also because GitLab charges high fees for everyone else to cover the cost of that free tier so that they can use it as a way of hooking people and getting them to move up to the paid tier. Presumably the people paying for that are aware that their fees are funding that, and pay those fees at least in part because they know it supports the community.
Re: (Score:2)
Because Gitlab poses their services as something people should move to in order to get away from Github, And Github pays the "costs" for their users.
But if they decide they don't want to pay the costs for the free users anymore it's up to them. If that's going to disrupt the Open Source community/movement then it's a very poor decision to hand that level of responsibility and control to a for-profit company that is providing this service for free at their own expense. Not just because of their profit-motive but that if they end up bankrupt then their free service goes away too so you're not only relying on their free service but the profitability of the
Re: What's the point of code control if disappears (Score:2)
Re: (Score:2)
Yeah. I guess GitLab does not really want to be a GitHub competitor for open source work. An open source project can go YEARS without a commit: That does not mean they are dead forever. The last thing we want is risk to loss is development history or code that can represent thousands of hours of development, over some shitty "cost-saving policy"
I'm sure someone can come up with a script to pull a list of all the projects that meet these criteria and commit a change to an unused file at a frequency just within the threshold.
Re: (Score:2)
The last thing we want is risk to loss is development history or code that can represent thousands of hours of development, over some shitty "cost-saving policy"
So pay them for it and stop exercising your own "cost-saving policy" by using their free tier.
Re: (Score:2)
So pay them for it and stop exercising your own "cost-saving policy"
This isn't possible. The people their policy causes problems from are Not the original developer, so much as it hurts everyone else directly.
The original developer probably has their own code stashed on a hard drive somewhere, and maybe in their own private cloud storage.
Re: (Score:2)
If you need it then you pay for it, don't expect somebody else to pay for it for you. This is a pattern that is more common nowadays, RedHat has a business model where its corporate customers foot the bill so if they have needs for something in particular (like the requirements of cloud-based elastic compute) that are served by a development like systemd then all those downstream can complain but ultimately the overwhelming majority of the Linux community have now moved to systemd because of the flow-on eff
Re: (Score:2)
GitLab, not GitHub. Oddly enough, it's the alternative darling GitLab that's making this arguable open-source hostile move, not Microsoft-owned GitHub.
Re: (Score:2)
GitLab, not GitHub. Oddly enough, it's the alternative darling GitLab that's making this arguable open-source hostile move, not Microsoft-owned GitHub.
Ironically, Microsoft is under so much antitrust scrutiny on an ongoing basis that they wouldn't dare, which probably makes them the single best possible company to own GitHub. :-)
Re: What's the point of code control if disappears (Score:1)
Re: (Score:2)
GitLab, not GitHub. Oddly enough, it's the alternative darling GitLab that's making this arguable open-source hostile move, not Microsoft-owned GitHub.
Of course because the question is who is going to pay for it? You think the Linux Foundation or the FSF is going to front up the costs for running a Git lab/hub like service?
Microsoft will pay for it up until they or their shareholders deem it not to be a financially prudent move.
Re: (Score:2)
That might be a roll they assumed but that doesn't mean they are required to do that for free forever.
Their solution seems reasonable but another option would be a $1/year charge for inactive projects.
Heck, they could even offer it to the community and let anyone pay the $1/year charge even if they are not the owner of the project.
If no one is willing to pay $1 for a project then it obviously has very little value to anyone.
Another solution might be to put ads on dormant accounts to try to cover the cost bu
Inadvertent colors.js? (Score:5, Funny)
Re: (Score:2)
How long until this causes a tiny-but-useful bit of code that a million projects depend on to disappear?
Or the deletion of those dormant projects causes websites to stop working as designed?
In this case I would hope that KARMA bites Github right where it hurts the most.
Re: (Score:2)
If there is a website that somehow stops working because of this, then the Karma-In-The-Butt is on them. For the life of me, I can't understand the foolishness of people who blindly allow such a dependency to happen. Look, if it is that important then keep a damn local copy for deployment and not just assume that something will magically stay available forever....sheesh.
Re: (Score:2)
Re: (Score:2)
If you "maintain" code on their
If you "maintain" code on there, as I know it'll irk someone. I know which is which, I just have a problem of typing the wrong one and not always catching it.
One million per year (Score:2)
How much are they going to lose by frightening away potential paying customers, afraid of their projects disappearing in a given future?
They pretend to go back to the 90's and 2000's, when software became unavailable when their website disappeared, and you had to revert to (unreliable, full of adware and bloatware) third-party software storage sites. Maybe Tucows wants to restart their Downloads site after this move.
Re: (Score:2)
Re: One million per year (Score:1)
Ok, maybe the developers die?
But the code is still there for others when open source. How does that situation get cleared up?
What are they thinking? (Score:5, Insightful)
Re: (Score:3)
Why do you feel it is someone else's responsibility to shoulder the costs of your 'partially abandoned' projects?
Re: (Score:2)
Because you have no idea who else might be using your semi-abandoned projects even in their unfinished state? Keeping it on your local network share isn't going to do them any good, it has to be public.
Re: (Score:2)
Who in their right mind would use a semi-abandoned project without cloning and keeping a local copy....SERIOUSLY. If you have to make changes to it then you can send a merge request, and if they don't pick it up, guess what, who really cares because your repo will stay active.
Re: (Score:2)
That didn't answer the question in the slightest. The question was not whether or not it should be public, but who should PAY for it. So again, why is it GitLab's responsibility to PAY for the cost of your projects?
Re: (Score:3)
Re: (Score:2)
I could not possibly agree more. If unpaid accounts are a real burden they should certainly remove them, but I cannot fathom how my barely-touched account is affecting them in any way. If they're worried that I might have a bad password, they can always deactivate my account and make me recover it when I want to log in again. The amount of data I'm using is trivial.
Hmm, just logged in, and nothing's even there. Guess they won't have to delete anything. I was pretty sure I migrated my crap there from github
Re: (Score:2)
Re: (Score:2)
Please point me to the portion of the terms of service where they promised to host your repos for the life of the company. Until then, you are just some person who mistakenly believes that everything related to the internet is somehow free for which none of it is free because everything does have a cost. If you think it is important, pay to host it then.
Re: (Score:2)
Why do you feel it is someone else's responsibility to shoulder the costs of your 'partially abandoned' projects?
Because all of these projects (abandoned or not), shared free of charge by their developers, are the bait that drives traffic to the site. That traffic consists of people who become familiar with the features of the site, and some of them might recommend it to their employers as a solution for a paid source hosting solution.
In an environment where the "network effect" is everything and only the top two or three players usually dominate, it's important to attract new users. Generating ill will by pissing off
Re: (Score:2)
They were hoping that people would use Gitlab for personal projects, and that would lead to use by companies who are willing to pay. I guess the return was too low, probably because their core product is shit and the only good bits are open source anyway.
Re: (Score:2)
I think they want to convert some of the non paying users into paying users.
Like what Redhat did to centos
Re: (Score:2)
Re: (Score:2)
So is it a mature project that doesn't need much updating or is it an abandoned project that can be deleted?
Maybe it's just a bad idea to create a dependency on the free service offering of a for-profit company for which you provide them no financial incentive to continue providing that service? Feels like you shouldn't hand over control of something so important to a company like that.
The Register is a joke site, not a news site (Score:1)
The Register writes shit that is blatantly incorrect and never corrects or removes it.
Do not use them as a source of news.
If only (Score:3)
Somebody could come up with a distributed version control system
Seriously? (Score:2)
Destroy history and possibly something useful to save a mere one million?
A simple solution (Score:2)
If a dormant project is important to someone, all it takes is once a year comment. If someone can’t be troubled to ensure code they use stays available if they need it to then that’s their fault.
you want me to use gitlab in my workflow? (Score:3)
Then encourage me to keep using it. If I can only use it for my professional projects then it's not a big deal for me to go somewhere else. At $19/month for the next tier I could just host on my own VPS or VM for a fraction of that. If I want lots of duplication then I can do backups myself in a few commands (locally or to S3 with restic). Of course there is always Github, Bitbucket, SourceForge, etc.. And if I want to pay for stuff Assembla, Kiln, CodeCommit, etc.
The 1% (Score:3)
In all likelihood, 1% of the "inactive" repositories are consuming 90% of the storage. Someone might have been using GitLab as a backup for memes they liked at one point or were dumping large binary packages up there. Seems reasonable to target the largest repos that contain no code and no recent activity first. If only 1% of the users are impacted, that would basically solve the problem without upsetting a bunch of people.
Automatically rebasing old repos, while kind of rude, would allow them to purge really old commits. After all, who REALLY needs commits from 5+ years ago? Plus, large binaries that were being updated over time just make retrieval of that repo take longer to calculate all of the deltas.
They could have an archive mode where they automatically move inactive repos to large, cheap(er), slow archival storage systems. With the click of an Unarchive button and some waiting to retrieve the repo from storage, the inactive repo could be made active and available again.
They already reversed the decision (Score:2)
Hurt Open Source (Score:1)
Linux Users (Score:2)
The one thing I was most surprised about when switching to Linux is that we just use the gits as personal backup systems. Everyone stores their small files on gihub/lab (their home directories are just git repos). I have read their TOS multiple times, and from what I can tell anyone can store absolutely anything they want on there, with or without public interest and subject matter irrelevant. You can use it to distribute your artwork, by the TOS.
But their mechanism for deletion seems strange. If 1000 peopl