Moving repos between hosts is trivial; e.g. I keep bare clones on my laptop, on an AWS server, and GitHub; with post-receive hooks that keep them all in sync.
GitHub's appeal is all the add-on functionality that's not actually stored in the git repo itself; e.g. Issues, Pull Requests, etc. That can't be migrated away easily.
Anyone who (a) has concerns about GitHub (monoculture, Microsoft, Copilot, whatever), and (b) relies on such add-on functionality, should look into moving that metadata into their repos. To give Microsoft some credit, GitHub Actions already does this (via YAML files in a .github/workflows folder)
Have a look at Gitea. You can run it as a podman rootless container off the box on your local machine.
The functionality is there, the community refuses to switch. There people who still have the idea that gh is still whatvit was 10 years ago.
We tried to migrate to Gitea at my company, ~100 repositories with a bunch of mirrors, lots of CI, renovate-bot using the API, etc. It was a disaster. It was unusably slow (10+ seconds to load the list of pull requests, API calls to open a new pull request timing out after 60s) despite never using more than a tiny fraction of the resources of a 16-core server. We tried to engage with the community to find out the cause of the slowness and were met with open hostility.
A DNS or firewall problem that causes Gitea to intermittently spend 10+ seconds responding to requests, when running in a cluster alongside other containers that have no such problems? Can you describe a plausible mechanism for that?
We did some profiling and spent quite a bit of time looking at Gitea's source code, it was pretty clear in the end that it's just very very inefficient for large setups. It does an excessive amount of I/O on the Git repositories every time you load a page; there is some caching but not enough / not of the right things. We were really open to implementing fixes and submitting PRs but the community was so hostile that we just abandoned it.
It was overall an enormous waste of time and I can't recommend Gitea to anyone with a setup larger than a handful of small repositories.
GitLab UI is full of warts though. Since they are there for 5+ years I doubt they will be fixed soon. I am talking about little things - weird button-with-dropdown to start a comment/discussion on a MR, infuriating emojis (no I don't want to put a sign :man-kissing-a-man: just because I entered a smiley) and similar. It looks like either their devs are not using the product or any change is hampered by red tape.
Still, we use it, but try to use just core functionality (git, CI, issues, wiki) and avoid anything else. Always wanted to try gitea, maybe now it's the time.
It's git-only. FWIW, I chose SourceHut in part because they support git and Mercurial, and I'm a Mercurial user. [1]
FWIW, the main SourceHut developer last year moved to the Netherlands. https://drewdevault.com/2022/03/24/Netherlands-update.html , and commented "I will be re-locating SourceHut, the incorporated entity, to the Netherlands, and gradually moving our infrastructure over the pond."
[1] Also because SourceHut is whole-heartedly pro-free software, and also because I feel better being able to pay for a service than depend on the largess of a large company, and also because I don't like monocultures.
Given the breadth of services Github provide, forge federation using ActivityPub (and ForgeFed extensions) open standards look very promising. A whole host of projects are working on it, and among them is Gitea. They will likely be the first to federate with other instances, so you can work on remote projects from your own environment.
Git is useful for all your textual versioning needs - but your friends don't really need access to all your git repos.
The whole idea of putting your whole life on GitHub is a dev's equivalent of putting all your life on Facebook - an excellent idea, as far as Microsoft and Facebook are concerned. If you can't sell ads to coders, then perhaps you can sell them recycled code.
The problem with that is that at that time GH was surviving with VC money. That money entered with the promise that at some point GH would monetize their users. The "paid account" model wasn't enough for them, And now that Microsoft owns them it's also not enough. They've found another way to monetize all that code.
It surprises me though that Microsoft hasn't added a Stack overflow like panel to github. More. People are jumping between GH for the code AZ md StackOverflow for the support.
As someone else has said, the alternative isn't to move away from GH (at least not for this specific issue). The alternative is to change your license to not allow for this.
If you change your license to exclude this particular use, it's no longer Open Source (no restrictions on how it's used).
If you change your license to forbid removing the license, then there's a good chance that it doesn't hold any legal power. Reason being that machine processing is allowed by copyright laws.
GitHub's appeal is all the add-on functionality that's not actually stored in the git repo itself; e.g. Issues, Pull Requests, etc. That can't be migrated away easily.
Anyone who (a) has concerns about GitHub (monoculture, Microsoft, Copilot, whatever), and (b) relies on such add-on functionality, should look into moving that metadata into their repos. To give Microsoft some credit, GitHub Actions already does this (via YAML files in a .github/workflows folder)
For my personal projects, I use a simple program called Artemis to manage issues, which just stores maildir files in a hidden folder: http://www.chriswarbo.net/blog/2017-06-14-artemis.html