It's true as a user that switching is relatively easy.

As a contributor it's a little harder, more so for stuff with non standard processes like sourcehut or cgit.

As a maintainer there can be much more significant differences around bundled features like CI systems and issue trackers. (Though I am of the opinion that where possible, CI should just be calling makefile steps or your language's tooling equivalent)

However, I agree that this is ultimately not a huge barrier.

Despite that, it's clear that users won't cross that barrier. As a project maintainer on not-github, you'll get less attention, less feedback, less contributions on other platforms. I think there's a bit of a relation to how sticky services like search engines are despite 0 barrier to switching.

So that's something that you will need to weight up when choosing a platform, regardless of whether you as maintainer have difficulty doing the switch or think others do.

Maybe maximising contributions isn't an important goal for you, but I can see why many projects before have made that decision.

> stuff with non standard processes like sourcehut

Of all the forges, Sourcehut arguably has the most standard processes - mailing lists for issues, and git-send-email for contributions. I especially love the latter, because it means I don't have to register and create a repo fork etc. just to contribute a patch.

In 2024 the reality is, without playing silly word games about the meaning of standard, email patches and mailing lists are non-standard (and arguably have been since the early 10s)