“The Github Threat” is a great write-up by Carl Chenet, reviewing the problems created by this centralised system.
Github is very convenient, but that’s not really the point…
The greatest irony in the setup is that key advantages of using distributed revision control are undermined by using a centralised repository for bugs and other key aspects of the development process.
It’s most unfortunate, but indeed ubiquity comes with lots of side-effects. People join without considering, and many people joining will not have the background or information to even be able to consider.
For an example of a distributed version control system that has its bug tracking (and other aspects) built-in: Fossil, by the author of SQLite, Richard Hipp.
The approach has specific merits that we should consider, and they can “easily” be applied with Git also.
Many of the GitHub alternatives are in themselves centralised – yes you can run your own instance, but they still split the code from the bugs and other info. Why?
There are documented cases of Github projects (ref. Gadgetbridge) being blocked due to DMCA take-down notices. Imagine your company relying on a centralised service and that service being (even temporarily) being unavailable to your employees. How well will your company cope? Yes, with Git you can share changes in a different way, but your business processes will need to adjust and that can be quite hard. How will the equivalent of pull-requests be managed, and where is your bug tracking?
Finally, it should not be necessary to have a centralised user-base at all. It would be good to have/use a distributed notification system (Mastodon might qualify) for distributed repos, using signed messages. That way even “politically endangered” projects would be able to exist effectively without an intrinsic risk of being taken out. Secondary hosts can automatically clone and broadcast availability.
As part-fixes, also see options like this idea for Gitlab (and others): Implement cross-server (federated) merge requests.