@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...
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.
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.
@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.
Sadly staticsite is currently broken; Python 3 happened and I had no time to maintain it. This is how it looked: https://www.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.
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.
@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 ?
@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.
A private instance for the Finkhäuser family.