GitLab plans to delete dormant projects in free accounts GitLab plans to automatically delete projects if they've been inactive for a year and are owned by users of its free tier. 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 …
There's a reason why those who made GitHub sold it to Microsoft. GitLab can sell itself to Google? After all Google too runs things like GMail "at a loss".
Also you mean Linux is successful because it is delivered "at a loss", and you can't compete with "free"?
"Microsoft basically wrote the book on it."
Oh no, they were already old stuff when Gates used them. There's a reason the Sherman Act was written in the XIX century.,.
Who is working for free? Torvalds? Most of the key people working on the Linux kernel are paid for it - by companies who need to keep the OS price down to avoid to invest much more in developing a whole one themselves or paying licenses to someone else.
Then there are those who are exploited by those same companies and really work for free to ensure those companies can make boatloads of money using a "free" OS to deliver the services they make money from.
This concerns users of the free tier. How would they compete? How would MS not owning Github reduce their hosting costs?
(I suppose the MS induced migration may have some effect).
Pay for your repository hosting and your problem goes away.
Well, that depends on how you look at it. Corporations like Microsoft have armies of creative accountants and offshore structures on tap, which means they have lower tax burden than small and medium business and effectively they can gain competitive advantage by being able to afford hosting free tier accounts.
Almost every day I use a program which hasn't changed since 2009. It is gnuit (GNU Interactive Tools), a console file manager (plus other goodies). I wouldn't be surprised if there are no more changes to it. Perfect? Probably not. Good thing it isn't hosted on GitLab. (Not that I often download it. Just when installing a new system.)
Best wishes,
Bob
I know a company using code written in 1988 for running much of their accounts system.
If it ain't broke, why fix it?
Modern software gets fiddled with way too much. Constantly rearranging a GUI for no reason at all may be fun for a designer but a headache for people getting work done.
I know a company using code written in 1988 for running much of their accounts system.
Presumably the much of their accounts system is flexible and allows its users to reconfigure it to adapt to changing regulatory and tax etc. A lot of companies don't have users with that product knowledge and rely on support backup from the software vendor.
Good for you. I've worked for a company where using an old database became the issue. Nothing wrong (well.... That's debatable) with the rest at the time - it mostly worked. But when it hit a 1GB data limit, things got painful to manage. Even more so when 1GB of transactions occurred within a financial year.
I know a company using code written in 1988 for running much of their accounts system.
This is something I try and explain to young developers. It's fine to want to use the latest and greatest all the time, and you should always be aware of these things.
However, most software development isn't the cool new mobile app, for most of us, it's something business related, either as an internal system or software used by businesses.
The reality is, unless you fuck up badly the systems most of us work on will (and should) last for many many years. This means by definition even the thing built with the latest and greatest will at some point become old hat, and still require maintenance.
You simply can't re-write entire systems continuously.
But, if you design and implement systems considering this, you might write maintainable systems, and that's the key.
If it ain't broke, why fix it?
Or, if it's fit for purpose, why re-write it.
I'm currently working on webifying a piece of software with some code that goes back to the early 90s. It's financial, so requires yearly updates to keep up with the law, it would be unfeasable to re-write it from scratch; however by the time we've finished webifying it and putting it in the cloud there won't be any 90s era code left.
This process has been going on for 3 years, and I reckon there's another 4-5 years until we can stop supporting the existing codebase. (This work is in parallel with existing feature development and work, as it's still a living product).
However, at the end we should have a web version of a product that can trace it's lineage back to a DOS era program, and with customers who will have been using it continuously since then.
Perhaps, but it doesn't break once a year, and their time limit here is 12 months.
Furthermore, if you're working in a relatively high-level language that's abstracted away inside another environment (eg JavaScript, Python) then version compatibility problems are mostly a matter for the maintainers of the environment, not individual projects.
And ?
Maybe that'll finally teach them to have their code on their production servers and not download it on the fly as they continue to do now.
Bandwidth costs are not an excuse to avoid securing your production server.
On the one hand I see where GitLab is coming from. Inactive projects can be a risk to the general software ecosystem, so this could be seen as a good move.
But in my experience working for larger companies, there's no agility there. The idea that anything gets updated to a later version more than every few years is laughable. So a one year timeout is useless.
Even in personal computing, it's only Macs that get yearly software updates. Most Linux distros (rolling ones excepted) ship a new update every two years or so at best. So if I'm using one of these projects and it doesn't work on the latest version of Python, how am I going to know before the project's repo gets pulled? I have literally no chance of finding out and reporting it, which leaves the developer in a very poor position.
And before someone says "Well, they could always just make a change every year" - really? An unnecessary change just to keep the repo open? Time flies past, a year can feel like the blink of an eye. And if the developer regards the project as complete - or has just moved on to another personal project - a year could easily feel like a month for that project.
After a few years and a few projects, this will become quite a hassle.
Frankly, a year feels way too low. Three years feels more reasonable, given the cadence of software development these days.
(As an aside, I was evaluating GitLab and GitHub for deployment at my work. I'd already picked GitHub, but it was very close and this does nothing to make me think I was wrong.)
For that automation you need to use an unencrypted key to login to Gitlab. There are disadvantages to that, especially for a key used only one a year.
Also, you probably should that script at least once a year - which ironically obviates the need for automation.
What is stopping me is "something like GitLab" needs much more than just the archive. I have no desire to go into competition with GitLab.
However, I find it hard to believe that even a large number of dormant projects are costing them much money - I don't believe disk space, particularly for highly compressed dormant projects, is likely a significant cost for them.
I would be happy to reach into my project to contribute to something like archive.org to add git support to allow it to archive all the Internet's freely available git repositories.
I expect them to do so, or to lose users. For modern companies, the network effects of having lots of users are an important part of their business plan, even if many of those users are not paying. If GitLab don't want to be regarded as one of the Internet's main locations for code that is, of course, their choice.
Basically - if they don't want to offer free accounts that is their choice. If they do want to offer free accounts then they shouldn't whinge.
No, they're projects, not accounts.
And they're not dormant. There are several libraries and utilities we use commercially that have not changed for several years - because they don't need to.
Obviously we have our own mirrors, but there will be plenty of open-source (free!) projects that also rely on libraries or utilities that only need changes every two or three years. Or longer.
And they will break if those dependencies vanish.
For example, the "official" Python "artifactory" library on pypi was last updated in 2018, and the last issue or PR was in April 2021.
There are alternatives, perhaps even better ones, but it works and plenty of projects rely on that bit of Python code.
If it was hosted on Gitlab, they'd be about to kill it.
Other than increasing the time, maybe a better metric:
* Project owner (and collaborative minions with admin level) have not committed anything to anything (including issues) during the same time period - so THEY are inactive, too.
* Project has not been cloned nor downloaded in addition to that (maybe for a shorter period of time)
* Project is not listed as a dependency for anything else that is 'still active'
and maybe some provision for archiving it as a dependency within the projects that depend on it., as applicable (so they do not break).
Then, only a project that is TRULY dead would fall off of the cliff and disappear, after a sufficiently long time, without doing any damage. Or, that's the theory. My guess is that this would be way less than 25%, though, and would not have the same financial bottom line effect of giving it "the chop" as the previous announcement might.
(Sort of a compromise when nobody likes the outcome, but it is the only sensible solution)
I completely agree with Philip's core point, but for me a better approach would be to create a new "dormant" state, where the only options are to download the whole thing (possibly not instantaneously; perhaps you get a tarball of the repository within 24 hours or so)_or_ transfer it to a paid account!
Have projects become dormant after 12 months, and then purge them after another year or two.
If you're working with third party libraries in your product then you should have copies of those libraries locally; your build system should not be pulling from systems that aren't under your control.
If you're working with third party open source software it's probably a good idea to grab the source code too.
If you're not doing either of these things let this article be a wake up call. ;)
(Finding you need to issue a hotfix and you can't build your production codebase is not a fun place to be in).
I can see GitLab's point of view, because it's free it's seen as expendable. There's no jeopardy in creating a new repo and leaving it there for 3 years doing nothing to it. But like others have said, some code doesn't get chance to be updated every year.
I suppose the only way around this is to spin your own GitLab on a VPS and have done with it. That's what I intend to do.
I don't know, I would rather use a simpler and different git manager now. I don't trust the company to not go half under and the code to become unmaintained and deleted by the skeleton staff for not being active. /s That or everyone to not care and migrate to something else.
This is why I'm glad I use local git first before hitting any of these services. I'm 100% done with all of them after migrating off GitHub to GitLab. I'll go back to standard gitweb.
Years I did some XSL transforms for processing some XML based climate data.
These (with a few tweaks added by others) became widely used and are essentially "complete".
They will only need changing if the format of the XML data to be processed ever changes
There is plenty of code that will only ever need changing if input data changes in some way (or, if the code is responsible for data output then if the required output format change, or data transfer method changes (as most things are a "file" in OS I mainly use then this data transfer method changes not typically a problem for underlying code but scripts that glue things together)
It's difficult to believe that dormant projects are responsible for 25% of hosting costs. The disk space is already paid for and, if nothing much is happening traffic costs should be negligible so potential savings we be low. The annoucement does suggest that they've got their sums wrong and have either overallocated for free accounts, or more likely, aren't getting enough paid accounts, in which case it's a bit like one of the appeals to use the photocopier less to save money, and the lights get switched off permanently a few months later.
If resource allocation is wrong, the adjust it: reduce the number and size of repos per user.
It's difficult to believe that dormant projects are responsible for 25% of hosting costs.
That. I can understand everything has cost but that much? And even if it did I'd be inclined to say so what, suck it up.
The worst part is "dormant" seems to only be defined in terms of being updated, not in terms of its usefulness to others, how often it is accessed.
Let's hope our local libraries don't decide they can save a fortune by burning all the books which haven't seen updates in years.
-> That. I can understand everything has cost but that much? And even if it did I'd be inclined to say so what, suck it up.
That's really your opinion? Suck it up? I guess you have never run a business where 25% of "customers" don't pay and expect something for nothing. Try going to your local coffee shop and give them your brainwave: let every 1 in 4 customers get their coffee for free.
Sadly hard drives don't last forever. There's been a few good articles on this topic recently on TheReg.
Hosting costs too, plus there's labour costs in reviewing security and applying patches, plus electricity.
Not defending GitLab, they should have realised from the get go that some of the stuff they host will be untouched for year's on end, yet the whole of the internet might be dependent on some of that code through ancestral linkages.
That's really your opinion? Suck it up? I guess you have never run a business where 25% of "customers" don't pay and expect something for nothing.
I do indeed run such a business and it's far more than 25% I host for free. But I wouldn't class my customers as expecting something for nothing; just taking advantage of what I am offering them for free.
Most of what I host for users can be considered 'bit rot', sunk cost, but it serves a purpose, has value, is useful to the community I wish to attract - and, yes, make money from.
To me that's an acceptable balance between philanthropy and sound business sense. "Free" is a part of my model and getting rid of the 'dead wood', as GitLab seems to perceive it to be, would actually harm my business.
I don't see hosting for free as '"throwing money away" but securing the viability of my business while helping the community. I don't have maximising my profit as my goal. It's not all me, me, me.
"Let's hope our local libraries don't decide they can save a fortune by burning all the books which haven't seen updates in years."
There is no cultural critic more ruthless than a librarian, or more populist. The librarian applies a brutally simple criterion: has this book been borrowed in the last year or two? No? Discard. Talis and Heritage both produce reports showing the long tail...
So if you want to keep a repository available, I suppose you will have to open an issue saying simply 'this is useful' once a year. Cron job?
Maybe the GitLab can agree with Web Archive/Wayback Machine to donate a frontend to off-load dormant code over there?
Win/Win..
I also fail to understand why "dormant" source code data would be expensive to maintan for GitLab. How do you attract project when there is a doubt about the longevity.
> That's only GPL and in such situations the source must be provided with the software: the requirement predates publically accessible repositories. Yes, even CVS.
That's incorrect.
GPL only requires that an offer of the source accompany the software
> accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
So you absolutely can ship someone binaries and say "source is available at https//github/foo", or indeed "to request a copy of the source, contact foo"
But, of course, this also means they wouldn't be in breach just because the repo got deleted (so long as they had a copy and could satisfy subsequent requests)
1) Only GPL.
2) If it's their OWN software, they can do what they want, unless it contains dependencies on other GPL stuff.
3) The requirement is to make the source available "on request" - only if someone continues to distribute binaries and refuses to also release the source code would they be in breach.
4) And specific to this case, or even in general: No! A third party is NEVER liable for someone elses responsibilities!
What about software that is usable by others but the author doesn't need to update, doesn't have the inclination any more or is isn't able to (Some authors will be ill or have died). If no changes AND no downloads for say three years then it might be appropriate. If you see no updates or comments for say six months when downloading something may be we should make a comment of Thanks.
I find your faith in commercial development highly amusing.
It's absolutely certain that there are bootstrap scripts with such dependencies, that are only run once in a blue baboon to bring up new systems.
Thus everything works "just fine" until the A/C fails and they desperately need it to work... and it doesn't.
I have an account with a hosting/online dev provider which is free and I have a half written project in there. I'm very proud of the project and I fully believe it will be worth finishing, and I will finish it. But not right now, because another project is in the way.
That provider just requires that I log in and access my project once every three months to avoid their sweeper up process. I think that's fair enough, if people want to keep gitlab projects alive then use them.
Just after the deadline clicks over, new ads for GitLab start to appear:
"Every single GitLab hosted project shows activity! We only attract the most active and alert coders, not like the slackers you get infesting <name of competitor>. Come and join our fast-paced community."
Although unlikely Github would do the same thing I've been using gitea locally to keep a backup of all of my public repositories as it has a handy mirror mode which can keep itself in sync with anything pushed to the remote.
It's also handy for local stuff I don't want public (like personal ansible scripts etc) or stuff not yet ready to be made public.
I remember a similar issue when Sun's code hosting Kenai went offline after Oracle bought them.
But which?
Sure, I can (and have) mirrored everything I use directly.
But that's my direct dependencies. I can't see the dependencies my upstream has for their development, only the code so produced. If they - or something they rely on - loses a tool they rely on for development, then what?
Which explains everything.
Just another dot com scam company.
Why exactly you need $400M plus for a glorified file hosting company when back in the good old days (pre dot com VC scams) you could build out a half billion dollar revenue company with 15% plus net profit margin in 5 years for a total VC investment of less that $30M.. You know, legitimate tech companies that actually made money by producing products that customer bought.
But no surprises here as companies like Gitlabs were never anything more than financial engineering exercises designed to make their annual 2% of the 2/20 business model for the VC's. Because the 20 never ever happens, 98% plus of the time.
A nice little earner for doing nothing productive.
Savings of up to $1 million a year, which most likely will be claimed by some exec bragging that he saved the company a bundle.
The net effect will be a world of hurt, where some crucial open-source project is accidentally deleted and people have to scramble to recreate the source code from bits and pieces lying around.
All this simply isn't worth it!!!
as I see it, devs have uploaded their work onto machines bought and paid for by someone else, and then hosted for free.
And they are now pissed off because they have been given a year to do something with it or it will be deleted?
So they have danced to the music and now have to pay to the piper.
Why not just pay for the service, or download it or move it somewhere else?
Sheesh…
…in which ways GitLab was going to suck when it went public.
I paid a personal subscription for a while even though I never used any of the extra stuff. Then they got rid of the $5 tier and suddenly I thought $20 or whatever it is that they charge was a bit excessive.
They should reconsider the $5 tier.
Given the opportunity to present themselves as the truly open platform that could be THE place to host and share open source software, they somehow come off greasier than the popular closed source Microsoft owned alternative.
Sometimes you look at these situations and find nobody to cheer for.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
