Follow

So, uh...

I knew I had to give it up when I started . Went with GitLab instead as the lesser of the major evils.

Now we're fully on @codeberg , since a small number of months ago.

Way ahead of the curve, it seems.

@codeberg To be fair, at the time I wasn't concerned with Copilot. I just didn't like how package managers, etc. seem to treat git and GitHub as equivalent. It's ridiculous. It's like nobody learned from the 90s.

Which, to be fair, some devs today didn't experience.

Microsoft had a strategy then that it has now, which we called Embrace, Extend and Extinguish. The last step is optional. That is, it joined some standards committee, and introduced vendor specific extensions.

@codeberg It then worked tirelessly to make its customers dependent on those extensions, all the while claiming it was the standard itself that mattered. In some cases, when it gained dominance over the standard, it moved its customers to a new, closed thing.

This kind of vendor lock-in is a major part of what the FOSS community was working against in those days. We offered open standards as the alternative, which meant providing sensible alternatives to the proprietary...

... extensions.

As useful as GitHub is, it's a proprietary extension to git. Always has been. So is GitLab. They're not as dominant in the market, and provide some FOSS version, but their business is still to hook folks on their extensions.

Gitea is different, and codeberg provides excellent hosting for it. It's one alternative to vendor lock-in.

I'm regularly stunned by how little people pay attention to this kind of thing these days. It almost seems as if folk are seeking to be locked in.

@jens

Gitea seems to provide everything I actually used GitHub for, and with a very similar interface.

Admittedly, I'm not much of a "power user" of GitHub, but it has been a pretty smooth transition as a user.

As a system administrator, getting the thing to run properly, it was a bit rougher for my self-hosted instance, but I felt my special requirements meant I really needed to host it myself.

@TerryHancock @jens @alcinnz I just wanted a private instance for some of my internal config files & scripts and so installed Gitea on my NAS. I have it running inside docker containers and that’s working really well!

I’ll look into @codeberg. I hadn’t heard of it before.

@jens I think it's more that folks usually don't care to be locked-in, they'd rather go for the path that seems to be the absolutely easiest one without planning for long-term.

I stopped using GitHub for my main things at least in 2018 and saw a bunch of projects moving to GitHub, even ones that were entirely self-hosted like SDL or WebKit.

@jens In my case, I was already unhappy with the move to Git, because Git was good enough to be useful, but just bad enough that most people wouldn’t use its core workflow — patches by email.

@jens Git users instead rely on pull-requests and bug-reports and wikis on proprietary platforms.

I used to use Mercurial with the b-extension¹ for distributed bug-tracking, and automatically parse the description for upload to a static site with references to other clones with the staticsite² extension.

¹: mercurial-scm.org/wiki/bExtens
²: mercurial-scm.org/wiki/SiteExt

Sadly staticsite is currently broken; Python 3 happened and I had no time to maintain it. This is how it looked: draketo.de/proj/hgsite/

@ArneBab I used to use monotone until Linus decided not to contribute to it and instead use his popularity to kill it with git.

@jens Do I remember correctly that i2p was developed in monotone?

I need to finish coonverting infocalypse to Python3, so I can move Freenet development into Freenet again.

@ArneBab possible. It's on git nowadays.

I really enjoyed monotone. I'm quite bitter about it being replaced by git, to be honest. Ah, well.

@jens I think I can feel that bitterness, too.

Even more because after the majority voted to get Freenet to Git instead of Mercurial, I was one of two people who had to fix the Git when it made problems. We two had both voted for Mercurial.

They wanted Git, which destroyed our in-Freenet-hosting option, but were not willing to do the work required.

Upside: my heavy dislike for git led to learning it well enough (to counter lies) that I could actually help people get stuff done.

@jens What is different about Gitea? It is still a non-standard extension that hooks your projects into that specific software. You need an account in a Gitea server to be able to contribute to projects and report bugs in the bug tracker. Granted, it is free software; but so is the community version of GitLab.

There are two better options in that regard:

1. SourceHut uses the traditional e-mail workflow for pretty much everything, and acts solely as Git hosting and a mailing list. Git and e-mail are both industry standards, and federated/distributed.

2. Fossil not only stores source code into a repository, but also bug tracker, forum, chat, wiki, web UI, etc. When you clone a Fossil repository, you clone everything, and then you can push/pull, so it is fully distributed, as well as self-contained.

@avalos Gitea is an extension, but by virtue of being fully FOSS and self-hosted by default, doesn't lock you in. There's nothing wrong with extensions, IMHO, if they leave you choice.

SourceHut, by providing git hosting as a service, arguably locks you in more. And while as an extension it's a lot more bare bones, it still is more than a git repo.

Fossil is great for sure! But that's an entirely different system. I wasn't going for comparisons with alternative SCMs.

@jens The community edition of GitLab is also fully free, and the option of self-hosting is always there. Many popular free software projects migrated their code to their own GitLab instances. Migrating to Gitea instead would have been practically the same.

SourceHut is also fully free and self-hostable, just as GitLab and Gitea are. So you also have the choice. The only caveat I've heard about is that the installation is not that easy. It might not be the case anymore.

My point is that, by virtue of the software itself and the freedom it provides, Gitea is no different than the others. I agree that extensions aren't bad as long as they give you choice; but you'll always have a degree of lock-in by using them, not only in terms of the software, but also the third-party integrations that support it.

I suggested Fossil as an option if you want a SCM that is fully distributed and thus requires no extensions, in case anyone cares about that.

@avalos The difference, as I pointed out a few posts ago, is that gitea is just FOSS. It has some funding, such as from NLNet, but that's it. Codeberg is free (beer+speech) hosting for FOSS projects of gitea and woodpecker. It doesn't cost you money, nor is there any entity attached for whom making money off the fact that you use it of interest (both gitea itself and codeberg accept donations and/or membership).

GitLab community is the free product of a for-profit entity whose...

@avalos ... business model is to convince you to go for their premium hosted version and pay for it.

They're not the same.

@jens I agree with you on that. The danger is not in the software itself; but rather on the business model and their incentive to act on it. It doesn't apply to SourceHut (you should check their awesome business model), but it applies to GitLab.

@jens you’ve got me wondering about shifting my private code a self hosted instance of gitea, tbh
@Madmonkey @jens

No, folks are seeking go be popular and, as others put it best, github is the instagram of coders, where the selfie is your "open source" repositories.

But those people doesn't really care about opensource or free software for that matter.

I would like to signsl fossil: https://fossil-scm.org/home/doc/trunk/www/index.wiki

As a self-hosting possibility. Simple, cheap to install and run and feature complete.

@jens A lot more codebergs would be needed to sustain a mass-migration off of Github. I like framagit's approach, where you stay small on purpose and inspire others to do the same.

@elbosso tönt jetzt etwas übertrieben für meine Projekte, an denen ja tatsächlich nur “one dev” beteiligt ist. @jens

@jens i have (perhaps too high) hopes that federating giteas (and others) will somewhat counteract github's network effect. I've seen many projects adopting github "pragmatically" in order to expose themselves to a maximum number of potential future contributors, whereas self-hosting one's projects on one's own gitea has the additional friction of requiring administering users (and for them to register). But a galaxy of federating forges is another story... one can dream ? :moji5:

@jens is there a Gitea / @codeberg roadmap for better accessibility support (for people who are blind, have RSI etc) and for (better) ActivityPub support? ❤️

It's great to see this #GiveUpGitHub conversation picking up momentum!

@wait_sasha @codeberg I don't know of any, but I know there's some cooperation going on.

@wait_sasha
We have a summary issue on accessibility, but it's not always up to date with upstream. Regarding federation / AP support, please check out the upstream organization.
@jens

@jens Gitlab does not lock people. it offers diverse ways to go export your data.

@dragnucs I think you mistake what lock-in is. Vendors don't literally have to hold your data hostage.

GitLab's best features are paid, and GitLab-specific. That is, once you've invested into adopting them, it gets difficult to move.

Inertia is a bitch, but in business, overcoming it costs money.

@jens maybe we do not agree on the same definition but I have seen systems where it is just impossible to get your data out in any possible way. GitLab do not impose deliberate lock-ins.

@dragnucs Oh they're deliberate, that's how they make money. 🤷‍♂️

I get what you mean, though.

@jens

Can't wait for the solution to the "you now need 90000000 accounts" problems of Gitea but they're reportedly working on it ♥

@Sandra I'd rather make 9000 gitea accounts than leak my GitHub account details to 9000 sites.

Sign in to participate in the conversation
Finkhäuser Social

A private instance for the Finkhäuser family.