My decision tree for selecting source control:
Q: Do I want contributors?
A: Yes, use GitHub.
A: No, use whatever I want. Q: Do I want contributors?
A: Yes, use GitHub.
A: No, use whatever I want.Remember, open source doesn't mean to accept any inane suggestion or PR from anybody. The best software is the opinionated and limited-in-scope. If people want to add an MP3 player to your project, they can always fork it.
And since using GitHub basically means training AI undermining my career, for free, so that Microsoft can turn a profit, the choice is simple, really.
Disclaimer: I am still using Github because I haven't found the time to set up my self-hosted Gitea instance just yet.
The one good thing is that git makes it relatively easy to move, so that if Github suffers excessive enshittification, something else can steal their lunch.
what if the enshittification is making it hard to move?
There are also always a few secondary repositories that share the same tooling, but still have less traction (like GitLab). But the network effects of GitHub are hard to ignore.
But, like was said in a previous comment, it least it is easy to move Git repositories from one host to another. So when there is an inevitable successor to GitHub, we’ll all be able to migrate to the next hotness easier.
(That’s assuming that the next hotness supports Git. Prior shifts followed from changing underlying technologies… CVS -> SVN or Hg -> Git)
Sourcehut has a very good and noble idea but it just adds so much complexity in the name of purity to a hurdle that is already very big for newcomers.
They basically undo all the progress on collaboration since the 90s to get rid of the modern problems that these changes cause, without realizing that the way forward is to solve these problems, not just revert to a time when they didn't exist.
https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
Saying they are "reverting to a time when they didn't exist" is missing the point. It's about improving the problems that caused people to switch away from the collaboration tools in the 90s; e.g. [1]. So it's more of a fork of the 90s than a rollback.
Also, it's not like the people at SH (and their users) haven't tried new collaboration tools. I (at least) have tried them and found them wanting in important ways. The conclusion that it's better to fix the older tools than the newer tools could be debated with[2], but nobody's sticking their heads in the sand here.
1: https://sourcehut.org/blog/2022-07-06-sourcehut-and-irc/ Note also that even without SH, e-mail, IRC, &c. are all greatly improved in both small and large ways in the time between the 90s and now.
2: I mean everybody involved with SH already prefers the older tools for one reason or another, so fixing the older tools is going to be the obvious path forward for them.
It's about a workflow where everything lives in email rather than some company's walled garden.
It also doesn't give a toss about newcomers. It's for users who want something very specific and know what that looks like already.
It's like the same reasons that OpenBSD still uses CVS -- it works perfectly fine for those involved in the project and the switch to Git would not only take time away from what's important to work on but also add a ton of noise from new contributors who may not have the same goals as the project.
If I want visibility and people to contribute, GitHub.
If it's a truly private project (dotfiles dump, esoteric highly personalized tools), self-hosted Gitea.
Everything else I put on Sourcehut.
The biggest problem I see is duplicate issues being raised across forge issue trackers, which using a single forge doesn't fix anyways.
If you funnel potential contributors straight into mentoring, the popularity of the tools is not an issue.
For visibility, there are many possibilities, such as volunteer platforms.
Projects which can follow that practice are substantially fewer than projects who can quickly solicit contributions on e.g. GitHub: requiring mentoring restricts the field to projects whose authors have the time, skills, and inclination to mentor, and restricts potential contributors to people willing to be mentored in new tooling rather than the (much more common) case of people who simply want to provide an improvement to code with minimal friction (and often minimal other involvement with the project, if we’re talking about point fixes for issues faced by the contributing user).
Q: Do I want to actively antagonize contributors while torturing myself?
A: Yes, use SCCS.