Gitlab U-turns on deleting dormant projects after backlash
theregister.com
theregister.com
There may have been reasons to do this in the past (e.g. lack of integrated CI) but I'm not convinced those arguments really hold anymore in 2022. If you're a maintainer and prioritising interoperability and the lowest barrier to entry for potential contributors and you don't care about it being proprietary/owned by MSFT you pick GitHub. If you're prioritising a FOSS stack, good tooling offering and low-weight pages with excellent performance, you pick something like SourceHut.
For everyone reliant on software published by maintainers who have already made this decision historically, it's reassuring the right decision has been made here, but a bit worrying they were needing to consider a step this far in the first place. Combined with their poor pay for engineers (discussed to death here on HN already), it does make you think a bit about their finances.
[0]: https://drewdevault.com/2022/03/29/free-software-free-infras...
Note that GitLab is not really the answer to this problem. It's open core, subservient to its investors, and pulls a lot of stupid shit like this. If you want the GitHub-style workflow and UI, go with Codeberg or another Gitea instance.
This isn't to mention also the issues regarding code ownership, where GitHub now trains their Co-Pilot AI on code under any license.
> Note that GitLab is not really the answer to this problem. It's open core, subservient to its investors, and pulls a lot of stupid shit like this.
Even if GitLab pulled out on their payed-tiers now, it's too late. This has been coming for years with the paid version of GitLab features vs the free version, which always ran behind on functionality.
We are currently considering our options to move away from GitLab. Ideally we look for tickets, merge/pull requests, CI and the ability to allow the public to contribute.
@ddevault We have been looking at SourceHut at an alternative. Specifically some questions for you:
1. Will you have a non-email merge/patch system for SourceHut in the near future [1]? The problem isn't so much for our team, but to encourage external people to help with our project who are used to the likes of GitHub and GitLab.
2. With regards to pricing for SourceHut, how will the pricing look in the future [2]? We have a small project that could pay per person/group, but would struggle to pay what GitLab are asking [3]. GitHib pricing is better, but obviously your code then becomes the product.
Great work in any case, I really enjoy seeing your blog updates.
[1] https://drewdevault.com/2022/07/25/Code-review-with-aerc.htm...
I remember their argument is that their training is considered fair use, legal/moral questions aside, doesn't it means that they can also justify using projects hosted on alternative platforms for training?
https://spacepub.space/w/no6jnhHeUrt2E5ST168tRL
2: TBD, but we will consult with the community before making any final calls. There will be at least 90 days notice before any pricing changes once the long-term pricing is finalized. It definitely won't be anything near GitLab's extortionate pricing.
Github is and always has been a closed platform. It's also responsible for the largest explosion of open source activity from any single source in the last twenty years. Your argument relies on the assumption that the cost of migrating away from Github is a cost a FOSS project can pay and survive, which is a pretty heavy assumption as far as those things go. Even if the alternatives were comparable in UX, and they're not, there are entire ecosystems (Node, Golang, RubyGems, brew, etc.) that explicitly depend on Github. If you measure your software's success by any metric other than how well it aligns to your ethics, it's hard to justify anything but Github for a FOSS project.
Most people, IME, write FOSS software so people can find and use it. I remember the era when SourceForge was more-or-less the best thing you could hope for as far as central repositories were concerned, but they weren't much more than free static web hosting. I remember how difficult it was to contribute to Apache projects because figuring out their esoteric source control and patch process was so daunting. I remember googling for software packages to use and not having an easy route to quickly gauge whether its quality was worth investing further research. I wouldn't like to go back to a world where everything was hosted on free software if it means losing all the knowledge that exists in that one place.
There definitely seem like more important windmills to tilt at than pointing at the engine that drives the entire FOSS ecosystem and saying it's not good enough by the most stringent of ethical standards.
Many people write FOSS for many different reasons. Chasing popularity is among the worst, and using GitHub is a poor way of achieving it regardless.
GitHub is not good enough. Placing all of our FOSS eggs in a proprietary basket which is incompatible with FOSS values is an absolutely foolish thing to do. The alternatives exist and are equal to the task, if not exceptional.
This is why pure FOSS hasn't, doesn't, and won't win. This overly moralistic posturing at every turn drives people away.
(Not that I think GitLab - at least in its cloud form - is much better, but alas.)
And GitHub can afford to offer all of these things for free because they are owned by Microsoft and they are playing the long game. CoPilot is probably one of monetization steps coming.
I have been planing to switch to GitLab because of it, even though I don't have any important public projects currently.
This Blog post is very helpful.
https://sfconservancy.org/blog/2022/jun/30/give-up-github-la...
I choose gitlab because IMO its the only full GitHub alternative, Gitea lacks advanced CI, while Gitlab has everything GH has and more.
Also if dont really agree that if you care about the platform being open source, that you should use SourceHut.
New user experience is horrible IMO, its lacks a lot of stuff GitHub has, and the UI isn't great.
IMO the best alternative is GitLab for a complete GH alternative, and Gitea for core stuff.
I hope that Gitlab and other hosts of the open source community think hard about this before implementing any policy like this. There are projects that are useful, and stable, but for whatever reason do not have a lot of users. There is no reason to let those projects die, or force the maintainers to have to do a song and dance to keep them around.
Yes, there's a cost, but there's a benefit too, and I hope these hosts of the open source community remember that.
I also have some amount of open science stuff. I count on github / gitlab being archival for things like archiving how I process data in some piece of research.
Literally all I really need of a git host is to support the git protocol, and to keep stuff around for me forever. I appreciate having pull requests, conversations, and what-not, but the #1 requirement is having my stuff there, reliably stored, and available to the world.
I'll mention: I don't blame gitlab for a decision they didn't make. If you've ever worked in a corporation, you'll know a lot of stupid decisions ALMOST get made all the time. gitlab tends to be more open than other organizations, so we see the inner workings. I've always seen them pull back when a decision is particularly numbskull.
Seems like their new policy wont prohibit that though.
Not everybody considers constant feature creep desirable.
In fact, even if they weren't a commercial enterprise they would still need to balance the books in order to survive.
[1]: https://about.gitlab.com/support/gitlab-com-policies/#name-s...
That knowledge about GitLab left a weird and confused taste in me. It gives me an impression, that is if a free tier user becomes inactive, they're no longer valuable for GitLab and can be treated as second-tier.
For that reason, I cannot seriously being myself to use GitLab. If you knew that all of your investments will rot to nothing as soon as you stopped paying, you'll probably consider to stop investing it.
Sadly, this idea of removing "dormant" projects followed the same train of logic: If you're not constantly contributing (paying/publising content) to our platform, you're second-tier, and we can just kick you out.
From the previous article where they announced the plan:
> 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...
GitLab don't seemed to understand their users well. "Angry opposition" is what might happen if GitHub decides to remove dormant repositories, not GitLab. GitLab users will just feel disappointed and leave (to self-hosting, or maybe host it (back) on GitHub).
GitLab should seriously re-learn what's more important for their service: user engagement or the code hosted on it. Tip: GitLab is not running a social network business.
Other than that, you can fork whatever you want today...
Later github changed its policy to something saner, but I never switched back to using github for private repos. This decision by gitlab even if it's rescinded, however, might give me the impetus to do so.
The five slots were precious and I didn't want to waste them.
But the pricing is just too steep for me to justify setting up, e.g. an extra user for some automated tasks.
GitLab has an explicit program for approved Open Source projects:
https://about.gitlab.com/handbook/marketing/community-relati...
This is their philanthropic effort. They need to remain financially solvent to provide anything long term, so of course they need to be careful how much they're giving away and for how long.
If you're not in the approved open source program, you should consider your usage of the "Free Tier" as part of their freemium business model whereby they hope to convert you at some point into a paying customer.
> GitLab should seriously re-learn what's more important for their service: user engagement or the code hosted on it.
They're a business that needs to pay the builds (including the long-term costs of storage). If they haven't approved your projects into their open source program, you should consider paying them to host the code.
I have my own issues with GitLab, but I won't judge them for the need to pay the bills.
When GitHub took off, they were not offering private repository at all. Instead, they added it in slowly when they can afford to do so. This is one of the reason why GitHub has now become the #1 platform for open source projects around the world.
GitLab is trying a different approach by focusing on offering repository hosting as service, but as time progresses and GitHub grows, this business model became less and less attractive. As a result of it, now days GitLab mainly attracts people who thinks GitHub isn't the right option for them, and that's not a big market. No matter how many cost they cut, if this remain unchanged, GitLab is already on it's dead bed (by that, I mean stop growing, not close for business).
GitHub is smart because at very beginning (before allowing private repositories), they knew that if they want to attract good programmers and projects, they must also accept and respect garbage, because that's what it takes to build their trust.
Deleting user data however, always destroy trust. If storing those repositories creates unbearable cost for GitLab, then maybe introduce a reasonable cap and then rejects new commits once the cap is exceeded (while asking user to buy more spaces). Making the entire repository just disappear is too much.
I'm glad that they did not end up choosing that route, but at the same time, not choosing that route should be the default, not something you just realized after it went to the media.
You can't, without paying, sit on a namespace for years and do nothing with it, if there is interest from a user willing to pay. And even if that is what you're doing, gitlab will contact you before taking back the account to make sure you don't suffer data loss. I don't know, this seems pretty reasonable to me, especially considering gitlab is a business and provides you with a free service.
You just have to log in more than once every two years!
I don't blame Gitlab for not understanding the levels of self-entitlement of some of its free users. And maybe, just maybe, Gitlab is better off without those users. In my experience, the cheap customers were always the worst and most demanding.
I don't know if the people running Gitlab are dev/ops guys who found themselves running the ship or some high pedigree managers but this reveals an enormous blind spot on this group of people.
One of the major driving forces for humans is loss aversion. Doesn't matter the project is abandoned or some garbage you don't value, these guys are on the business of banking for code + services and they just announced to the world they can't be trusted as bankers.
I'm sure that wasn't what they were looking for and their monthly bill is big ( perhaps too big ), but setting fire to the whole thing isn't the right move.
It's owned by Microsoft, a for-profit company with a long history of hostility toward open source anything.
Literally setting fire to the building and servers IS the right move if it's what brings the most money in the door and keeps as little as possible from going out.
They don't and never will care about customer goodwill for something like their paid service, they'd stop offering it tomorrow if it made money for them.
[source](https://about.gitlab.com/press/releases/2022-03-14-gitlab-re...)
They're spending more money than they're making.
They burned $129MM and forecast a loss of $142MM next fiscal year.
Given that they recently went public I’d imagine they would be trying to become profitable. The IPO appears to have netted them around $600M in cash, or about four years of runway.
[1]: https://about.gitlab.com/blog/2022/03/24/efficient-free-tier...
A lot of things get discussed and evaluated that never eventuate.
That said, they were talking about deleting dead projects from unpaid accounts, and it does seem kind of shitty that as a community we seem to have decided that once a company has hosted some content that they should be required to host it forever at their own expense.
So that’s somewhere between 0.6% and 1.5% of their annual loss according to the claim it would save 1M a year
This is a really great insight that I hadn't thought of. Sure, if they, from the start, had promised to do so, that would be one thing. But users of free plans are essentially freeloading (sure, there are useful network effects of having free users on the platform), and it's a bit entitled to expect that free services are free in perpetuity (especially from a company that isn't profitable), even for projects that might be abandoned.
If they really wanted to save only on costs, surely they could have gone for the biggest repos first? E.g., politely email owners of large-but-inactive repos to consider spinning them down, and then if that fails to move the needle, then put in a policy (starting with big repos first).
There's no reason for someone's 1k LOC project to get swept up in something like this. The costs for that must be trivial.
GitLab dined on that, and really any time negative press has come from GitHub.
I don’t think people would have been pushed the move it to GitLab narrative If they had foreseen this.
We need something like public (book) libraries for code. Or a Library of Congress. FOSS has become critical infrastructure and we need to act like it. Done well, this could also help foster people learning to code. Sure there will be some political issues with it around funding and what code we should or shouldn't host, but the benefits would outweigh the drawbacks I think. I've seen tax money go to worse things, at least.
When it comes to open source and free software projects both of these platforms are not your friends. The "free" services are just an enabler for their revenue models, part of the business plan. Especially Microsoft is well-known for their long game and EEE strategies. If it is up to them we'll move to GOSS, Github Open Source Software, that is so dependent on nice GH services that it can never move away.
I have my hopes in more open technologies, be they low-level like DVCS, or taking care of social aspects of software development, like ActivityPub. On this last bit cool developments are taking place. Extensions to ActivityPub that will allow code forge features to federate with any vendor that supports them. We'll get decentralized software development if that is done well.
Some FOSS projects and communities are taking first strides here. A report of their activities is in this blog post of the Forgefriends project:
https://forgefriends.org/blog/2022/06/30/2022-06-state-forge...
Some FOSS has become critical infrastructure. But how much of that has been inactive for a year on gitlab free tier?
I dont see how this threatens critical open source projects.
Notably, it includes Gitlab.com and discontinued forges like Google Code and Bitbucket's mercurial repositories.
I have one project which I use all the time which is basically finished, once in a great while I have to fix some minor thing when python changes their C-API or I get bored and add some minor feature because I wanted to figure out how to do something in python. From the outside the project is “dead” as I barely ever touch it, just recompile when I do an OS upgrade and forget about it until the next python version bump.
I honestly don’t think anyone else has used it, its a python wrapper around boost:: property_tree which I use to transform rss xml to json, but it does contains a lot of magic to do things using the python C-API which are pretty hard to figure out because there’s no documentation so I think the real value is having examples to look at. I spent many wasted hours figuring out how these things worked by reading other peoples code and adding them in the easiest way possible. Might someday save someone a bit of time…maybe.
https://blog.printf.net/articles/2015/05/29/announcing-gitto... https://news.ycombinator.com/item?id=31534936
There are also multiple git-remote-ipfs projects on GitHub.
There is no reason for me to go to a paid account. There is no way that I could justify the cost to my boss. We have 5 slots for the team and only need 3. There is nothing that we'd gain from paying.
If they said tomorrow that we had to pay $60 a month to get what we're getting now, then I'd say to my manager we need to pay for this or we won't be able to keep developing our software without deploying infrastructure we have to maintain. At that point we'd start paying.
0 to 60 overnight sounds like a very disastrous thing for a company to do, like a big ol bait and switch. I would immediately stop using that company and find alternatives, and I am guessing it will be the same for a lot of people too.
At 60usd a month for 5 people, a developer should be able to buy a few servers(~4) for less than $30-$40, selfhost something like gitea with drone.
And then set up the users
Then set up the permissions
And the hooks
And move repos to it
Then set up deployments, figuring out how to replace any missing Gitlab features
Then update the docs that describe how the repo structure works for onboarding
Etc etc
Moving infrastructure is a couple of days work at least for a small team. If you factor than cost into it then it's rarely worthwhile. And that's before any time lost to investigating and fixing outages, updating the software, and so on.
The amount of downtime, sudden server crash, problem with SSL with NAT, setting up gitlab runner, upgrading, etc. You'll need someone experienced enough and maybe even a dedicated infra role to handle those things
Depends on where you are are doing it. AWS makes it ridiculously easy to hand off basically all aspects of hosting. Set up once, use forever.
Same story for the primary free software project we rely on (who we have a support contract with). Neither us nor them spend anywhere close to 10 hours a year on maintaining selfhosted Gitlab related infrastructure.
People underestimate consistently how complicated is to build reliable things, hardware or software. There is a world between "it works for me" and "it works for all"
Reasoning was if the file server was down, it would come back up quickly because it affects everyone. I didn't understand this reasoning until I got emails from the database team saying the database servers stopped working and every development team now needs to change their connection string from machinename-abc.corp to machinename-bcd.corp
How in the world someone could write an email like that is beyond me. Ok machines crash all the time but why can't they reuse the same name for the new machine?
(And that's literally only because I choose to update it manually since it's usually offline for about 15-30 minutes during updates...)
I actually recently did just that, moving over everything from my self-hosted GitLab instance into Gitea, Drone CI and Nexus: https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-... (the same would apply when moving from a cloud GitLab instance to the other self-hosted solutions)
Edit: fixed the link now.
Honestly, it wasn't so bad, given that I didn't couple what I had too tightly to the functionality of GitLab in particular - having an external issue tracker, though moving CI and build artifact storage systems can indeed necessitate porting them over (which was easy, given that I mostly use Dockerfiles and shell scripts for builds anyways) and cause additional work.
> And then set up the users; Then set up the permissions; And move repos to it
Thankfully, nowadays neither is too hard to do, given that there are pretty good migration scripts which will work, unless you're doing something very non-standard and peculiar. I migrated close to a 100 repositories with not a single failure, though perhaps that's also because I don't mess around with Git LFS after being burnt whilst trying to sync GitLab and GitHub repos with LFS data going into a black hole.
> And the hooks; Then set up deployments, figuring out how to replace any missing Gitlab features
The good thing here in particular was the fact that I use Docker for builds as mentioned before, so getting "docker build -t ... -f ... ." working across different build systems is generally pretty easy (except for Jenkins which is needlessly hard sometimes), especially when the software for the CI runner nodes themselves runs in Docker containers (with trusted code you can also just share the Docker socket, otherwise you probably want a DinD setup).
Deployments are also just telling another system (Portainer/Docker Swarm in my case; sometimes Helm for Kubernetes) that it should retrieve the latest build artifacts from some OCI compatible repo and run the new version of the application with any given configuration.
> Then update the docs that describe how the repo structure works for onboarding
I don't think that I've ever actually needed to change this, since while the UI itself does change (e.g. organizations vs groups), the actual contents of a particular repository itself remain the same. Might need to update an URL or two, but for the most part I saw no blockers here.
> Moving infrastructure is a couple of days work at least for a small team. If you factor than cost into it then it's rarely worthwhile.
It took me less than a day, total. But maybe that's because I've built a bit of a pipeline around running containers in my infrastructure and have the ingress/reverse proxy setup around them all established. Not to sound cocky, there are also caveats and things that I do agree with you in regards to pain points (below).
> And that's before any time lost to investigating and fixing outages, updating the software, and so on.
This is probably the bigger issue here, though. All of the sudden, the stability of it all is your responsibility. Now, in my case that wasn't such a change in circumstances because I started out with GitLab and with my limited hardware setup moving over to Gitea and friends was actually a win from a resiliency standpoint vs an integrated GitLab Omnibus install (that loves to eat RAM). For for anyone moving from the cloud to an on-prem infrastructure, this is definitely one of the main concerns.
That said, for many out there storing their code and other stuff in the cloud is a non-starter (e.g. certain government orgs or enterprises), which is where self-hosting can indeed be very helpful, though in most cases I've seen GitLab instances be used instead of Gitea. That said, Gitea is also an excellent option for anyone who just wants to embrace self-hosting out of principle or other reasons.
Being in control of your data is pretty cool (at least until you misconfigure something and everyone is in control of your data). That said, if you don't buy into the balkanization of software platforms nowadays too much and focus on the common standards of the systems instead, overall it's not as painful as one might think.
Of course, you can also pick a platform that's too hard to actually use and administer (which is why I switched away from GitLab) by yourself, but then the question becomes of why you're even using it in the first place. Honestly, GitLab is an excellent platform with amazing features, but handling updates and its hardware requirements wasn't fun: https://blog.kronis.dev/everything%20is%20broken/gitlab-upda...
Oh, also sometimes migrating data can be downright hellish, like when I tried migrating SVN to Git, with migration scripts not working due to non-standard repo layouts, which meant that I had to rewrite the layouts and history on the SVN end so things would actually work properly and those scripts wouldn't hang. Though it was ages ago and I haven't used SVN that much recently, Tortoise SVN was a nice piece of software though, RIP.
More like 4 hours of my salary (~2100 euros per month after taxes), given that I live in Eastern Europe and work for a local company.
I think that there is definitely an interesting shift in opinions towards expenditure towards software, platforms and tools. The poorer a particular nation (and its developers) are on average, the more inclined everyone is towards a mindset of "doing instead of buying", given how their own time is comparatively less valuable than paying someone else to do it.
Then again, the same applies to the software that they use, personally I pay for the Ultimate package of all the JetBrains products (their IDEs are really good), but a lot of my acquaintances only use free software, or other means of acquiring it. Kind of why a lot of Russia and other countries over there (if you look eastwards) is running on pirated Windows machines.
Curiously, that's also why something like AWS is out of reach for me and instead I use local platforms like Time4VPS, or something like Hetzner/Scaleway/Contabo.
Sure, you could setup with 4 machines and think this is costing you only $40 per month, if you take out all the maintenance and setup time
I’m often accused of being somewhat too frugal, but in this case frugality points me strongly towards paying the $60/mo.
I know a company that moved to Github because why add a cost when more popular competitor is giving same for free.
Unfortunately, they know this, and as a result they've actually been making more and more user-hostile changes (like bumping features up to higher plans, introducing virtually all of their new features as premium, and just generally ignoring their supposed pricing and monetization strategy in favor of $$$).
I have a bunch of repos on there I haven't touched for years I was thinking of archiving them on my home server instead and maybe setup cgit or something for a web interface if it mattered. I don't really need 80% of GitLab features (or GitHub for that matter). It might be nice if someone sees it because of the navigability of these platforms and the visibility it affords. However, that hasn't happened. If they are saying that it has a cost, I can might as well self-host it for myself ... or not.
https://gitlab.com/gitlab-org/gitlab/-/issues/366467
“Today we have the SaaS Free User Efficiency - Data Retention Policy in the internal handbook for our team members. legal has requested that we add a full definition for the 'last_activity_at' attribute.”
We buy compute time periodically and that is a small amount I guess.
We happily pay Bitbucket for our backup storage. I'm sure we'd pay for our code storage if that was required.
Maybe $5/person/month is not a lot for active projects a business relies upon, but the 90% of hobby and (semi-) dormant projects would be deleted or moved to GitHub if Gitlab tried to ask money for them. Which would reduce the attractivity of the platform.
GitLab has nothing to compete against that.
Instead of arguing "we need to cut costs", why don't they work on an entry-level paid tier? Seriously, it is like they're not even trying to compete with GH at this level.
Throw in a feature like epics or roadmaps and some CI time for $5/mo and I would have been on it, but $20/mo is too much for how few of the premium features I'd use. I'd just always assumed this tier didn't exist because the opportunity lost with long tail consumers was weighed up against the possible of business users downgrading to a lower tier. But then they could just go with the jetbrains model, and have the exact same tier have two different prices depending on whether the buyer is an individual or a business, if they're worried about that. Call it Gitlab Premium Personal or something.
That said, the youtube-dl github drama did push me into self hosting my private projects and mirrors of at-risk projects on Gitea, so that window has closed now. Also Gitea is a lot nicer than Gogs was the previous time I compared gitlab against other options. But gitlab is still for now my host for public projects.
I found out about it on a previous HN thread.
It can do automation, one of the missing points from Gitea.
The most successful of my projects has a potential audience of a few hundred users-- custom firmware for specific obscure hardware. The others, the likely user base is likely one.
I suspect that's what a lot of hobbyist projects are going to be-- an itch scratched for a single user and/or a very small community, perhaps cast into the void with the thought "someone else might find some value in it" or "this helps as a portfolio for future job interviews-- lets me showcase technologies I don't work on 40 hours a week"
The thing is, this means that there's a fair chance you're going to reach endgame. You don't need any more features because your itch is scratched. There will be no new commits, but it's nice to have the archive for when someone actually needs the code. So activity is an awful proxy for value here.
there are plenty of things that don't require dependencies and don't encounter breaking changes. the javascript community's problems, attention deficit and hyperactivity disorders don't represent software development.
Check out progress at the latest Forge Friends monthly report:
The main problem with services like GitLab is that they are not only hosts to repositories. They're issue trackers, they're CI/CD platforms, they're release artifact hosts, they're discussion platforms, they're review platforms, they're their own bespoke pull/merge request workflow; all eggs in one basket "as a service". If they shut down your repo, the code is the last thing to worry about unless they have the only copy of the current canonical history.
I once thought DOAP might be a thing, but a search engine bringing up code results (needs not be constrained to it) would be really nice.
Problem: funding. Maybe like this https://nlnet.nl/project/Gitea/
Once again, i don't agree with deleting dormant projects, I'm just curious what an alternative solution is?
That's what they ended up deciding to do
> 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.