Hashimoto announced he is moving Ghostty off GitHub entirely, calling it 'no longer a place for serious work.' As co-founder of HashiCorp and creator of tools like Terraform and Vagrant that are installed on millions of machines, his critique carries significant weight — this is a deliberate infrastructure decision, not a reactionary move.
The Hacker News submission garnered 331 points and 175 comments, reflecting strong community resonance. The framing emphasizes that when someone whose tools underpin Fortune 500 infrastructure says GitHub doesn't meet the bar, it's qualitatively different from smaller maintainers making the same move.
The editorial argues that Hashimoto's exit carries weight most GitHub-exit stories don't — when the co-founder of a company whose tools run on millions of machines rejects the platform, it's a signal rather than just a data point. His track record of shipping production-grade infrastructure tools gives the critique credibility that a typical project migration lacks.
The editorial identifies GitHub Copilot's training on public repositories as a central friction point, noting that the platform's relationship with users' code remains uncomfortable for many maintainers. Microsoft's steady integration of AI features into every surface — from code suggestions to PR summaries — has transformed GitHub away from what developers originally came for: git hosting and code review.
Mitchell Hashimoto — co-founder of HashiCorp and the mind behind Terraform, Vagrant, Consul, and Vault — announced on April 29 that he is moving Ghostty, his GPU-accelerated terminal emulator, off of GitHub entirely. His statement was blunt: GitHub is "no longer a place for serious work."
Ghostty, which has attracted significant attention as a fast, cross-platform terminal built in Zig, had been hosted on GitHub since its inception. Hashimoto's decision to migrate it represents a concrete action behind what many open-source maintainers have been grumbling about for years. This isn't a rage-quit tweet; it's a deliberate infrastructure decision from someone who has built and shipped developer tools at massive scale.
The announcement landed on Hacker News and quickly climbed to over 330 points, resonating with a developer community that has been increasingly vocal about GitHub's trajectory under Microsoft ownership.
Hashimoto's departure carries weight that most GitHub-exit stories don't. When a maintainer of a 200-star project moves to Codeberg, it's a data point. When the co-founder of a company whose tools are installed on millions of developer machines says the platform isn't for serious work anymore, it's a signal. HashiCorp's products — Terraform alone — underpin infrastructure at most Fortune 500 companies. Hashimoto knows what production-grade tooling looks like, and he's saying GitHub doesn't meet that bar anymore.
The complaints coalesce around several themes that have been building for years. First, there's the AI training question: GitHub Copilot was trained on public repositories, and the platform's relationship with its users' code remains uncomfortable for many maintainers. Microsoft has been steadily integrating AI features into every surface of GitHub — from Copilot code suggestions to AI-powered pull request summaries — and for developers who came to GitHub for git hosting and code review, the platform increasingly feels like it's optimizing for a different customer.
Second, the core experience has arguably degraded. Search remains mediocre. The Issues system hasn't seen meaningful improvement in years while GitHub chases AI features. Actions, while powerful, has created vendor lock-in that makes migration genuinely painful. The new UI refreshes have been polarizing, with many power users reporting that common workflows take more clicks than they used to.
Third, there's the broader philosophical concern: a single company controlling the canonical location of most of the world's open-source code was always a fragile arrangement, and the cracks are becoming harder to ignore. When Microsoft acquired GitHub in 2018, the community was reassured that GitHub would remain independent. Eight years later, it's deeply integrated into Microsoft's AI strategy, and the priorities of a $3 trillion company don't always align with those of an open-source maintainer trying to ship a terminal emulator.
Hashimoto isn't operating in isolation. Over the past two years, a steady stream of projects has moved off GitHub. Some have gone to Codeberg, the nonprofit Forgejo-based forge that has positioned itself as the ethical alternative. Others have moved to self-hosted Gitea or GitLab instances. The Software Freedom Conservancy has been campaigning for a GitHub exit since 2022. What's changed is the caliber of projects making the move — this is no longer limited to ideologically-motivated activists.
The pattern is clear: projects with strong maintainer opinions and engaged communities can survive a platform migration. Projects that depend on GitHub's network effects for discovery and contribution — which is most projects — face a genuine cold-start problem. The practical reality is that moving off GitHub still means accepting fewer drive-by contributions, less discoverability, and a steeper onboarding curve for new contributors. Hashimoto can afford that trade-off because Ghostty has a dedicated community and his personal reputation drives attention. Most projects don't have that luxury.
GitHub's position remains formidable. With over 100 million developers and deep integration into CI/CD pipelines, package registries (npm, RubyGems, NuGet via GitHub Packages), and security tooling (Dependabot, code scanning), the switching costs are substantial. GitHub Actions workflows, in particular, create a form of lock-in that goes beyond just moving git remotes — you're rebuilding your entire CI pipeline.
If you're a team lead or platform engineer, the immediate action item isn't to panic-migrate off GitHub. It's to audit your GitHub dependencies and understand your actual switching costs. How many GitHub Actions workflows would need rewriting? Are you using GitHub Packages as a registry? Is your entire security scanning pipeline built on GitHub's native tools?
The prudent move is to ensure your workflows are portable. Use standard Dockerfiles instead of GitHub-specific action syntax where possible. Keep your CI configuration in a format that can be adapted to GitLab CI or Woodpecker. Store your project documentation in formats that aren't tied to GitHub's wiki or Discussions features. Think of it as infrastructure-as-code for your development platform — you wouldn't hard-code a single cloud provider into your application, so why hard-code a single forge into your development workflow?
For open-source maintainers specifically, it's worth experimenting with mirror setups. Host your canonical repo on your preferred forge, mirror to GitHub for discoverability, and accept contributions from both. Tools like `git-remote-mirror` and Forgejo's federation features are making this increasingly practical, though not yet seamless.
The forge monoculture era may be ending, but what replaces it is still taking shape. Forgejo's federation work could eventually enable a fediverse-style model where forges interoperate — you contribute from your Codeberg account to a project on a self-hosted Forgejo instance without creating a new account. That future is technically plausible but socially unproven. In the meantime, Hashimoto's move is the strongest signal yet that GitHub's hold on the developer elite is loosening. The question isn't whether alternatives will gain traction — they already are. The question is whether GitHub will respond by refocusing on what made it indispensable in the first place: being the best place to collaborate on code. Not AI code. Not AI summaries. Just code.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.