Live data from Hacker News

Gitlab U-turns on deleting dormant projects after backlash

theregister.com

81–90 of 131 posts

Re: Gitlab U-turns on deleting dormant projects after backlash

#81
post #73

There's a reason GitHub is the de facto host for OSS projects, I'd posit that open source maintainers who deliberately choose an unconventional host like GitLab already increase the barrier to contributions (not just due to network effects, but an unfamiliar UI, feature parity, poor performance etc) and this change would've already tipped the balance in my view and made it even clearer GitLab is not the right choice…

If you believe that it's important for free software to use free software infrastructure (and you should[0]), then there is no choice but to do so. Infrastructure like GitHub is primarily a function of network effects and the only way to overcome them is to cast your lot appropriately. A maintainer who "doesn't care" if their infrastructure is proprietary is not doing a good job. [0]: https://drewdevault.com/2022/03/…

> A maintainer who "doesn't care" if their infrastructure is proprietary is not doing a good job.

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...

[2] https://sourcehut.org/pricing/

[3] https://about.gitlab.com/pricing/

Re: Gitlab U-turns on deleting dormant projects after backlash

#82
post #81

Earlier quoted context omitted.

If you believe that it's important for free software to use free software infrastructure (and you should[0]), then there is no choice but to do so. Infrastructure like GitHub is primarily a function of network effects and the only way to overcome them is to cast your lot appropriately. A maintainer who "doesn't care" if their infrastructure is proprietary is not doing a good job. [0]: https://drewdevault.com/2022/03/…

> A maintainer who "doesn't care" if their infrastructure is proprietary is not doing a good job. 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…

Regarding copilot training issue, I wonder if they can just train on any open-source projects that they can access, e.g. projects in SourceHut.

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?

Re: Gitlab U-turns on deleting dormant projects after backlash

#83
post #3

I was kind of surprised that the hosting of such stuff was a significant enough cost that removing it was seen as worth it - but I have no idea what their annual revenue is, and a million dollars is a million dollars. 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 th…

> 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. 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 a…

Software Heritage does this. We archive as much publicly available code as we can, and make it available at https://archive.softwareheritage.org/

Notably, it includes Gitlab.com and discontinued forges like Google Code and Bitbucket's mercurial repositories.

Re: Gitlab U-turns on deleting dormant projects after backlash

#84

and here I was wondering when people would build a scheduled pipeline job to commit to a repo every month to keep it active, costing them even more money.

This comment chain has not received any replies in the last 4 hours and is therefore now marked as stale. Reply with "!stale no" to remove the flag, otherwise the comment chain will be deleted in 8 hours.

Re: Gitlab U-turns on deleting dormant projects after backlash

#85
post #81

Earlier quoted context omitted.

If you believe that it's important for free software to use free software infrastructure (and you should[0]), then there is no choice but to do so. Infrastructure like GitHub is primarily a function of network effects and the only way to overcome them is to cast your lot appropriately. A maintainer who "doesn't care" if their infrastructure is proprietary is not doing a good job. [0]: https://drewdevault.com/2022/03/…

> A maintainer who "doesn't care" if their infrastructure is proprietary is not doing a good job. 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…

1: We are working on a web tool which uses emails under the hood but is otherwise quite similar to pull/merge requests. We have already rolled out the contributor side of the process, which you can see demoed here:

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.

Re: Gitlab U-turns on deleting dormant projects after backlash

#86
post #73

There's a reason GitHub is the de facto host for OSS projects, I'd posit that open source maintainers who deliberately choose an unconventional host like GitLab already increase the barrier to contributions (not just due to network effects, but an unfamiliar UI, feature parity, poor performance etc) and this change would've already tipped the balance in my view and made it even clearer GitLab is not the right choice…

I would argue that choosing a closed platform like GitHub where users must sign their data and more over to and which (a) has absolutely no provision for contributing in any way without signing up (and thus giving them a wider "user base"), (b) is an entirely proprietary, for-profit platform built on the backs of open-source, and (c) is owned by a company with such a long history of ill will towards open-source; is worse.

(Not that I think GitLab - at least in its cloud form - is much better, but alas.)

Re: Gitlab U-turns on deleting dormant projects after backlash

#87
post #81

Earlier quoted context omitted.

> A maintainer who "doesn't care" if their infrastructure is proprietary is not doing a good job. 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…

Regarding copilot training issue, I wonder if they can just train on any open-source projects that they can access, e.g. projects in SourceHut. 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?

If your code is open source and matters at all, people put it on GitHub anyway. I refused to self-host any of my stuff on GitHub, but there are a ton of forks and mirrors of old versions there anyway (and then people get confused being unable to find the real copy because there seriously are asshats out there searching for code repositories exclusively on GitHub instead of Google).

Re: Gitlab U-turns on deleting dormant projects after backlash

#88
post #22

I've had open source projects be dormant for 10 years only to get a question pop up out of the blue from someone who found it useful. 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…

Ditto. Sometimes stuff reaches a point where it's mature or stable and doesn't need more development. Sometimes life gets in the way and years down the road someone stops in to pick up the torch. That's open source.

I have a lot of projects from >10 years ago which are mature, stable, used, and the only time they see active development is if there's a breaking change elsewhere (a lot of them interact with other tools).

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.

Re: Gitlab U-turns on deleting dormant projects after backlash

#89
post #79
post #43

Earlier quoted context omitted.

I was a paying GitHub customer, but they had such a crummy private repo policy at the time (I think only 5 private repos were allowed) it forced me to make poor technical decisions: "I'll delete this github repo, keep my local copy, to open up a slot." I switched all my private repos to gitlab and stopped paying for github and was happier for it. Later github changed its policy to something saner, but I never switche…

I had forgotten why I default every little hello world type repo I create on GitHub to public. I knew there was a reason I started doing that but had forgotten. The five slots were precious and I didn't want to waste them.

Which, of course, was entirely their goal: to get more public content to increase the network effect.

Re: Gitlab U-turns on deleting dormant projects after backlash

#90
post #24

Few years ago, I tried to un-squatting an username from both GitLab and GitHub (yes, GitHub were doing this back then), both with success. During the attempt I studied the policies for both service and noticed the difference between the two: For GitHub, they were lean towards not to release the username especially when the account is valid and not "empty"; For GitLab however, they will release the username if the acc…

Gitlab's approach also sounds like an easy way to hijack dormant projects to inject malicious code and let unsuspecting users download "updates"

Except that projects are namespaced under their owner, so you'd need to hijack the owner's account. They don't appear to have been proposing deleting users (or groups), just projects.

Other than that, you can fork whatever you want today...

Post reply on HN