On Wednesday 29 June 2022, we began calling on all FOSS developers to give up on GitHub.
We realize this is not an easy task; GitHub is ubiquitous. Through their effective marketing, GitHub has convinced Free and Open Source Software (FOSS) developers that GitHub is the best (and even the only) place for FOSS development. However, as a proprietary, trade-secret tool, GitHub itself is the very opposite of FOSS. By contrast, Git was designed specifically to replace a proprietary tool (BitKeeper), and to make FOSS development distributed — using FOSS tools and without a centralized site. GitHub has warped Git — creating add-on features that turn a distributed, egalitarian, and FOSS system into a centralized, proprietary site. And, all those add-on features are controlled by a single, for-profit company. By staying on GitHub, established FOSS communities bring newcomers to this proprietary platform — expanding GitHub's reach. and limiting the imaginations of the next generation of FOSS developers.
We know that many rely on GitHub every day. Giving up a ubiquitous, gratis service that has useful (albeit proprietary) features is perennially difficult. For software developers, giving up GitHub will be even harder than giving up Facebook! We don't blame anyone who struggles, but hope you will read the reasons and methods below to give up GitHub and join us in seeking better alternatives! Also, please check back to this page regularly, as we'll continue to update it throughout 2022 and beyond!
There are so many reasons to give up on GitHub, but we list here a few of the most important ones:
Copilot is a for-profit product — developed and marketed by Microsoft and their GitHub subsidiary — that uses Artificial Intelligence (AI) techniques to automatically generate code interactively for developers. The AI model was trained (according to GitHub's own statements) exclusively with projects that were hosted on GitHub, including many licensed under copyleft licenses. Most of those projects are not in the “public domain”, they are licensed under FOSS licenses. These licenses have requirements including proper author attribution and, in the case of copyleft licenses, they sometimes require that works based on and/or that incorporate the software be licensed under the same copyleft license as the prior work. Microsoft and GitHub have been ignoring these license requirements for more than a year. Their only defense of these actions was a tweet by their former CEO, in which he falsely claims that unsettled law on this topic is actually settled. In addition to the legal issues, the ethical implications of GitHub's choice to use copylefted code in the service of creating proprietary software are grave.
In 2020, the community discovered that GitHub has a for-profit software services contract with the USA Immigration and Customs Enforcement (ICE). Activists, including some GitHub employees, have been calling on GitHub for two years to cancel that contract. GitHub's primary reply has been that their parent company, Microsoft, has sold Microsoft Word for years to ICE without any public complaints. They claim that this somehow justifies even more business with an agency whose policies are problematic. Regardless of your views on ICE and its behavior, GitHub's ongoing dismissive and disingenuous responses to the activists who raised this important issue show that GitHub puts its profits above concerns from the community.
While GitHub pretends to be pro-FOSS (like SourceForge before them), their entire hosting site is, itself, proprietary and/or trade-secret software. We appreciate that GitHub allows some of its employees to sometimes contribute FOSS to upstream projects, but our community has been burned so many times before by companies that claim to support FOSS, while actively convincing the community to rely on their proprietary software. We won't let GitHub burn us in this same way!
GitHub differs from most of its peers in the FOSS project hosting industry, as GitHub does not even offer any self-hosting FOSS option. Their entire codebase is secret. For example, while we have our complaints about GitLab's business model of parallel “Community” and “Enterprise” editions, at least GitLab's Community Edition provides basic functionality for self-hosting and is 100% FOSS. Meanwhile, there are non-profit FOSS hosting sites such as CodeBerg, who develop their platform publicly as FOSS.
GitHub has long sought to discredit copyleft generally. Their various CEOs have often spoken loudly and negatively about copyleft, including their founder (and former CEO) devoting his OSCON keynote on attacking copyleft and the GPL. This trickled down from the top. We've personally observed various GitHub employees over the years arguing in many venues to convince projects to avoid copyleft; we've even seen a GitHub employee do this in a GitHub bug ticket directly.
GitHub is wholly owned by Microsoft, a company whose executives have historically repeatedly attacked copyleft licensing.
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. GitHub may even be how you find and showcase your work to prospective employers. We also know that some Computer Science programs even require students to use GitHub.
Accordingly, we call first on the most comfortably-situated developers among you — leaders of key FOSS projects, hiring and engineering managers, and developers who are secure in their employment — to take the first step to reject GitHub's proprietary services. We recognize that for new developers in the field, you'll receive pressure from potential employers (even those that will otherwise employ you to develop FOSS) to participate on GitHub. Collective action requires the privileged developers among us to lead by example; that's why we're not merely asking you leave GitHub, but we're spearheading an effort to help everyone give up GitHub over the long term. You can help protect newcomers from the intrinsic power imbalance created by GitHub by setting the agenda for your FOSS project and hosting your project elsewhere.
As such, we're speaking first to the hiring managers, community leaders, and those in other positions of power that encourage the use of GitHub to new contributors and existing communities. Once someone in power makes the choice to host a project on GitHub, the individual contributors have little choice but to use these proprietary and damaging products. If you are making decisions or have political power within your community and/or employer, we urge you to use your power to center community efforts through FOSS platforms rather than GitHub. If you're an individual contributor who feels powerless to leave GitHub, read our (growing) list of recommendations below on how to take the first steps.
Long term, we'll develop this stable URL (that can always be reached by GiveUpGitHub.org) to include links to resources to help everyone — from the most privileged developer to newcomers and members of underrepresented groups in FOSS — to give up on GitHub. If you don't feel that you or your project can yet leave GitHub, we ask that you raise awareness by adding this section to your README.md to share your concerns about GitHub with your users. If you're ready to leave GitHub, you can use this README.md template to replace your current one.
千里之行始於足下
The journey of a thousand miles begins with a single step.
— 老子 (Lao Tsu) in Chapter 64 of 道德经 (Tao Te Ching)
Here are some resources to help you quit GitHub. We'll be expanding this list regularly as we find more resources. If you'd like to suggest a resource not yet listed, you can discuss it on the Give-Up-GitHub mailing list.
Here are some ideas of how you can help raise the importance of this issue even while you're still a GitHub user. (We'll publish longer tutorials in future about these and other ways to help.)
Add this section to your README.md to share your concerns about GitHub with your users.
Respectfully and kindly ask, before you contribute to a project on GitHub, if they could provide alternative means to contribute other than using GitHub.
Explain to your employer the dangers of relying on GitHub's proprietary vendor lock-in products.
Join the give-up-github mailing list and start threads about your difficulties leaving GitHub. This will help us explore solutions with you and add material to this page.