Copied from the original page: https://sanctum.geek.nz/why-not-github.html

Tom Ryder, 27 Oct 2017
Last updated 12 October 2019

I host all my own code on my cgit instance. I do have an account on GitHub, but only because it's a requirement to contribute to certain projects and even to log into some websites. I avoid using the account where possible, and I don't host code on it anymore since June 2016. The primary reason I host code on my own domain is a practical one: I can retain control over its location via URI redirects if it needs to move, including redirects to another site if necessary. However, I also dislike the tacit acceptance of GitHub as the dominant free software hosting platform for a decentralised version control protocol, when it is itself centralised, proprietary, for-profit, closed-source, and politically active. These things make it vulnerable to the same issues and abuse that affected SourceForge. I feel that the free software and open source communities turn a blind eye to this massive liability. Regardless of your position on individual cases, the fact that so much controversy results from any censorship activity from GitHub should be considered a warning sign that too much depends on their service. Some examples:

• https://github.com/opal/opal/issues/941 [archive]
• https://www.theregister.co.uk/2013/12/19/feminist_software_foundation_c_plus_equality/
• https://www.techdirt.com/articles/20150802/20330431831/github-nukes-repository-over-use-word-retard.shtml The issue here is not political correctness, it's centralisation. If GitHub were not in this monopolistic position, nobody would care so much about any of the above. The overwhelming monopoly that GitHub has as a code host is a problem that the free software community chooses to ignore. Rules of acquisition

If you are managing a free software project, please do not host it on GitHub, or at least allow a method of contributing that does not depend on using it or any other proprietary code hosting platform: Formatting and sending patches: : Use git-send-email(1). The manual page even has instructions for using it with Gmail. Using this method, you don't need to host the code at all. Pull requests: : Host your own repositories—it's really easy—and point maintainers to them with git-request-pull(1). Web frontend: : Use the superb cgit, or gitweb(1), which is included in the Git source. Both are straightforward to configure for any CGI-capable webserver. Other options include a self-hosted GitLab, Gogs, Gerrit, or Gitea instance. More ambitious or puritan sysadmins might choose to self-host Drew DeVault's stellar sr.ht system, which implements a much wider range of GitHub's features, for an "integrated development hosting" environment. There are some more good reasons not to use GitHub or its ilk discussed here:

• https://miroslaw-zalewski.eu/blog/2015/why-i-dont-use-github-exclusively/
• https://www.adamhyde.net/another-good-reason-not-to-use-github/
• https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm
• https://www.gnu.org/software/repo-criteria-evaluation.html#GitHub
• torvalds/linux#17 (comment)
• https://www.wired.com/2015/06/problem-putting-worlds-code-github/
• https://valdyas.org/fading/kde/why-arent-you-using-github/ Update—June 2018

It's become more widely known that GitHub had a contract with United States Immigrations and Customs Enforcement (ICE), an ethical hot-topic at present after similar disputes with config management software Chef. Again, the issue here is not whether this is good or bad, it's that you're handing GitHub power over your work, while they may be using their proprietary software to political ends that you find repugnant, and refusing you the right to fork and apply their code in the way that suits you, the user. Avoiding these sorts of problems is the entire basis of Freedom 0.