How-To Geek's Sydney Butler recently described the trend as a set of "canaries in the coal mine," not a stampede. That's a fair way to put it, and he says plainly that GitHub is still the most popular repository platform and that most free and open-source projects still live there. His point is that the reasons are more complicated than "Microsoft's AI is scary." The primary sources back him up on that, and they also correct one claim that often comes up in these discussions.
Zig: a ten-year GitHub tenant moves to Codeberg
On November 26, 2025, the Zig project said its GitHub repository was now read-only. The canonical master branch moved to Codeberg. Zig lead Andrew Kelley's post is blunt, and its complaints go well past AI:
- Engineering decline. Kelley argues that the engineering quality that made GitHub successful no longer drives it. He describes a slow, buggy JavaScript front end where pages that used to be quick are now sluggish or broken.
- GitHub Actions. This is the most practical complaint. Zig says Actions has serious bugs, gets little attention, and has started picking jobs to run seemingly at random. Combined with being unable to step in manually, that left the CI queue so backed up that even commits to
masterweren't reliably tested. Zig decided to switch hosts instead of spending donation money on more CI hardware. - AI policy enforcement. Zig has a strict no-LLM, no-AI contribution policy. Kelley expects fewer violations off GitHub and blames some of them on GitHub promoting its "file an issue with Copilot" feature.
- GitHub Sponsors. Sponsors helped Zig's early fundraising and is still a big share of its revenue. Kelley says the product has been neglected and is declining, so the Zig Software Foundation now treats it as a liability. It's asking recurring donors to move to Every.org, a nonprofit, and is retiring the Sponsors-linked perks.
The migration itself is worth studying if you're thinking about doing the same. Zig did not try to bring over its entire issue and pull-request history. Existing GitHub issues stay open where they are. Codeberg issue numbers start at 30,000 so no number can refer to two different issues. Contributors were told to leave old issues and PRs alone unless they need to edit, comment or rebase. Kelley thanked Forgejo contributors and Codeberg staff for help with the move.
Section takeaway: For Zig, CI reliability and how the platform is run mattered at least as much as AI. The project left a read-only GitHub repo in place and moved issues only when needed. It didn't attempt a big-bang migration.
Ghostty: an 18-year GitHub user logs outages on a calendar
Mitchell Hashimoto published "Ghostty Is Leaving GitHub" on April 28, 2026. The main complaint was reliability. He said that for a month he marked an X on every day a GitHub outage hurt his ability to work, and almost every day got one. On the day he wrote the post, a GitHub Actions outage had blocked his PR reviews for about two hours.
He made two clarifications that often get lost in coverage:
- Timing. The post came out the day after a large GitHub outage on April 27, but Hashimoto said that was a coincidence. The plan had been in the works for months, and the post was written more than a week earlier.
- Git isn't the issue. Replying to the "but Git is distributed!" crowd, he said the problem is the infrastructure around Git: issues, pull requests, Actions and so on.
Coverage at the time agreed that the destination hadn't been chosen. Further details about the new hosting platform were promised in the coming months, as discussions continued with both commercial and open-source providers. The Register reported that he would come back if GitHub delivered "real results and improvements, not words and promises." His personal projects stayed on GitHub, and Ghostty kept a read-only mirror there.
What happened next isn't well documented. A Ghostty setup guide from Bitdoze, updated this month, says the GitHub URL still works as a read-only mirror synced daily, but it is no longer where development happens, and that development happens on the project's own infrastructure. That's a third-party source, not an official Ghostty announcement, so read it with caution. It does suggest Ghostty didn't simply join a big public forge.
Section takeaway: Ghostty left over uptime, not principle. It's a different reason from Zig's, and it carries more weight with enterprises, because outages affect every customer whatever they think about AI.
The Copilot training claim needs a correction
How-To Geek says GitHub's Copilot "will use you for training data" and that this is "sneakily an opt-out feature." The opt-out part is true. The broader suggestion that GitHub now trains on everything it hosts isn't what GitHub announced.
GitHub's March 25, 2026 announcement says that from April 24, 2026, it will use interaction data from Copilot Free, Pro and Pro+ users to train and improve its AI models unless they opt out. That data includes inputs, outputs, code snippets and surrounding context. Copilot Business and Copilot Enterprise users aren't affected. GitHub lists what can be collected:
- Suggestions you accept or modify
- Prompts and code snippets sent to Copilot
- Code around your cursor
- Comments and documentation you write
- File names, repository structure and navigation patterns
- Feedback such as thumbs-up and thumbs-down ratings
GitHub also says the program does not use content from issues, discussions, or private repositories "at rest." That last phrase is deliberate. GitHub admits Copilot does process private-repo code while you're actively using it, and that interaction data can go into training unless you opt out. It may also be shared with GitHub affiliates, including Microsoft, but not with third-party model providers. GitHub's current documentation adds Copilot Max to the plans covered.
So the accurate version is this: if you use Copilot on a personal plan, what you do with Copilot can become training data. If you only host code on GitHub and never use Copilot, this policy doesn't change anything for you.
How to opt out (individual Copilot plans)
According to GitHub's documentation:
- Click your profile picture in the top-right corner of any GitHub page.
- Choose Copilot settings.
- Open the "Allow GitHub to use my data for AI model training" dropdown and pick Disabled.
If you opted out of GitHub's earlier product-improvement data collection, GitHub says that choice still applies. If the setting isn't there, you're probably signed in with an account that has a Copilot Business or Enterprise license. GitHub hides the toggle for those accounts because their data is covered by its Data Protection Agreement, which prohibits training without customer authorization. Admins should note that developers who also have personal Copilot accounts should check those settings separately.
Where projects are going
Codeberg: run by a nonprofit, built on Forgejo
Codeberg describes itself as a democratic, community-run nonprofit platform operated by Codeberg e.V., a registered association in Berlin, built around the Forgejo-based Codeberg.org. Members elect its board, so its claim to be community-owned is more than branding. It also offers Codeberg Pages, hosted CI and Weblate for translations. (How-To Geek cites a figure of more than 730,000 hosted projects, but we couldn't confirm it from a primary source, so treat it as unverified.)
There's a recent wrinkle: SourceHut's August 2026 policy post notes that Codeberg announced in late July that it would limit LLM use on its platform. If you're moving partly to keep using AI tools freely, read Codeberg's current rules before you go.
Self-hosted Forgejo: full control, and full responsibility
Forgejo is free, self-hostable forge software that runs Codeberg. It's a hard fork of Gitea, and Codeberg has backed its development since 2022. Codeberg points out that running a Forgejo instance makes it easy to leave later, which addresses the lock-in concern directly.
The catch is that you now run the infrastructure. How-To Geek jokes that, given GitHub's outage record, it's hard to imagine doing worse. That depends a lot on who's doing the work. Backups, patching, CI runners, spam control and authentication all become your team's job. For Windows-heavy shops, this is a real staffing decision, not a weekend project.