> For software developers, giving up GitHub will be even harder than giving up Facebook and Twitter/X!

This is not so sure; the git format is supported by many services so mirrors can easily be made. It can be difficult if you are using some of their proprietary features for important purposes, but hopefully you might be able to avoid those things (I do avoid them for this purpose).

> Copilot's AI model was trained (according to GitHub's own statements) exclusively with projects that were hosted on GitHub, including many licensed under copyleft licenses.

Whether or not that is true, projects may be mirrored, forked, back up copies, etc on GitHub even if the original one isn't, or if it has been deleted or moved since then it might still be used. Even if they are not on GitHub, someone else might try to use them for training the AI models whether or not Microsoft does.

Nevertheless, the real problem is if someone else other than who originall wrote the software, will add additional restrictions on their modified versions by use of copyright, even though it was originally intended to prevent such a thing. (I think abolishing copyright entirely would be a better solution.)

> Microsoft's Copilot is now generating issues and pull requests and GitHub users cannot opt out

I have not experienced this. (If you have experienced this, then you might try to make a GitHub Actions file to automatically delete any issues generated by Copilot, and see if that will work. If GitHub Actions files are not executed for issues and pull requests from Copilot, then possibly something similar to what I did with auto-assignment using GitHub Actions, might help to allow the ones with Copilot to be ignored.)

> The reason that it's difficult to leave GitHub is a side-effect of one of the reasons to leave them: proprietary vendor lock-in. We are aware that GitHub, as the “Facebook of software development”, has succeeded in creating the most enticing walled garden ever made for FOSS developers. Just like leaving Facebook is painful because you're unsure how you'll find and talk with your friends and family otherwise — leaving GitHub is difficult because it's how you find and collaborate with co-developers.

Not all features require vendor lock-in, e.g. if you only host mirrors of the repositories on GitHub then it does not require the proprietary vendor lock-in.

Problems can occur, if anyone who wishes to discuss it is required to use GitHub, or if you require complicated GitHub Actions files that cannot easily be ported to use on something else, etc.

> We also know that some Computer Science programs even require students to use GitHub.

This seems to be more of an issue with Computer Science programs that require the external services and registration than GitHub itself, although that is still a part of it too.

> Below we include a list of various options for both third-party hosting and self-hosting

I think it would be helpful to make an improved service in many ways. For example, ensure that JavaScripts and CSS are not required, allow X.509 client authentication (this also makes it possible for such things as API keys to be portable to other services if you move your project or make up your own, since the public keys are public and can be trusted by anyone who wishes to do so; and can do so without needing vendor-locking 2FA and stuff like that; and if the other service is malicious, they cannot use this to impersonate you on your first service, so it is also more secure), and better work with non-Unicode text, multiple version control systems possible, the ability to mirror issues and comments, etc.

Are you suggesting people should continue to use github?