Microsoft's ownership of both GitHub and the companies it competes with creates uncomfortable conflicts of interest. As Hacker News reported, Mitchell Hashimoto's decision to move Ghostty away from GitHub highlights a deeper issue that engineering teams ignore at their peril: platform concentration risk.
This isn't just about one terminal emulator switching code hosts. It's about the gradual consolidation of developer tooling under a single corporate umbrella and what happens when that umbrella starts casting shadows on projects it doesn't like.
The Microsoft Dilemma Gets Real
Here's the uncomfortable truth: Microsoft owns GitHub, Visual Studio Code, TypeScript, npm (through acquisitions), and has massive influence over .NET, PowerShell, and Windows Terminal. When you're building a competing terminal emulator like Ghostty, hosting on GitHub starts feeling like sleeping in your competitor's house.
We've seen this movie before. Remember when Google deprecated Reader and killed off dozens of RSS clients that depended on its API? Or when Twitter strangled third-party clients by restricting API access? The pattern is always the same: build a platform, attract dependents, then squeeze when it serves business interests.
The difference here is scope. Microsoft's reach across the developer stack is unprecedented. They don't just own one platform. They own the repository, the editor, the language runtime, the package manager, and increasingly, the deployment targets through Azure.
Beyond Code Hosting: The Deeper Dependencies
GitHub isn't just a git host anymore. It's become infrastructure. GitHub Actions powers CI/CD for millions of repositories. GitHub Packages hosts dependencies. GitHub Codespaces provides development environments. GitHub Copilot writes code.
When we built AgileStack's early projects, GitHub felt like a neutral platform. Today, it's impossible to ignore that every commit, every action, every dependency flows through systems owned by a company with its own competing products.
Consider the incentives. Microsoft has Windows Terminal, a direct competitor to Ghostty. They have VS Code, which competes with every other editor. They have Azure DevOps, competing with every CI/CD tool. At what point does "platform neutrality" become a liability on the quarterly earnings call?
The Network Effects Trap
Here's why this matters more than just switching git remotes. GitHub has built network effects that make leaving painful:
Discovery and contributions: Most developers find new projects through GitHub's interface. Moving to GitLab or Codeberg means losing discoverability.
Integration ecosystem: Thousands of tools integrate with GitHub's API. Moving means rebuilding those connections or losing functionality.
Social proof: Stars, forks, and contribution graphs on GitHub carry weight in hiring and project evaluation. Starting over elsewhere means losing that social capital.
Workflow lock-in: GitHub Actions, Issues, Projects, and Discussions create workflow dependencies that extend far beyond source control.
This is vendor lock-in disguised as convenience. And like all good vendor lock-in, you don't notice until you need to leave.
What This Means for Engineering Teams
The Ghostty situation should trigger some uncomfortable conversations in engineering organizations. Here's what we're seeing at companies we work with:
Audit your Microsoft dependencies: Count how many critical paths flow through Microsoft-owned infrastructure. Source control, CI/CD, package management, development environments, deployment platforms. The number is probably higher than you think.
Plan for platform migration: Document what it would take to move your repositories, workflows, and integrations off GitHub. Not because you're planning to leave tomorrow, but because having options creates negotiating power.
Diversify your toolchain: Consider alternatives for each piece of your stack. GitLab for repositories, CircleCI for CI/CD, npm alternatives like Yarn or pnpm, VS Code alternatives like Zed or Vim.
Monitor policy changes: GitHub's terms of service, API limits, and feature restrictions change regularly. Teams that don't track these changes get surprised when workflows break.
The Technical Reality of Platform Migration
Migrating off GitHub isn't trivial. We've helped teams make this transition, and the complexity extends beyond git push commands:
CI/CD reconstruction: GitHub Actions workflows don't translate directly to other platforms. You're looking at weeks of work to rebuild complex pipelines.
Integration rewiring: Every webhook, API integration, and automated workflow needs updates. Third-party tools that depend on GitHub's API need alternatives or custom solutions.
Team retraining: Developers know GitHub's interface, keyboard shortcuts, and workflows. Moving to GitLab or Bitbucket means productivity hits during the transition.
External dependencies: Other projects, clients, or partners who depend on your GitHub presence need coordination and communication.
But here's the thing: teams that go through this exercise, even as a thought experiment, end up with more resilient architectures and better vendor relationships.
The Broader Platform Consolidation Problem
GitHub is just one example of a larger trend. Look at the current state of developer tooling:
Google: Android, Chrome, Firebase, GCP, Kubernetes, Angular, Dart, Go Amazon: AWS, Alexa, countless internal tools that become AWS services Meta: React, GraphQL, Jest, Yarn, and the entire metaverse bet Microsoft: Everything mentioned above plus LinkedIn, which is increasingly tied to GitHub profiles
Each company builds genuine value. But they also create ecosystems designed to keep you inside their walls. The switching costs compound over time until moving becomes prohibitively expensive.
Practical Steps for Risk Mitigation
You don't need to abandon GitHub tomorrow. But smart teams are building optionality:
Mirror your repositories: Keep automated mirrors on GitLab, Codeberg, or your own infrastructure. When GitHub has outages (remember the October 2022 incident?), you have alternatives.
Document your GitHub dependencies: Create a spreadsheet listing every GitHub integration, API usage, and workflow dependency. Update it quarterly.
Build portable CI/CD: Write workflows that can run on multiple platforms. Use Docker containers and standard tooling that isn't tied to GitHub Actions specifics.
Test migration scenarios: Pick a small, non-critical project and actually migrate it to another platform. Learn the pain points while the stakes are low.
Negotiate from strength: When you have real alternatives, vendor conversations go differently. Microsoft knows which customers can actually leave.
What Ghostty Gets Right
Hashimoto's decision isn't just about avoiding conflicts of interest. It's about maintaining independence and optionality. By moving before being forced to move, Ghostty preserves choice.
This is the same principle we apply at VooStack. We build on popular platforms but maintain the ability to move. Our NutriScan AI models can run on different cloud providers. Our DevStack tools work with multiple repository hosts. ESig integrates with various document storage systems.
Diversification isn't paranoia. It's engineering discipline.
The Long Game
Platform consolidation won't reverse. If anything, it's accelerating. AI capabilities, cloud infrastructure, and developer tools are increasingly bundled under single corporate umbrellas.
Teams that recognize this trend and plan accordingly will have competitive advantages. They'll negotiate better terms, avoid service disruptions, and adapt faster when platforms change policies.
Teams that ignore platform risk will find themselves at the mercy of quarterly earnings calls and corporate strategy shifts they have no control over.
Ghostty's move isn't really about GitHub. It's about the future of software independence. And that future requires intentional choices about where we build and how we maintain optionality.
The question isn't whether platform consolidation will affect your team. It's whether you'll be ready when it does.
Building something in this space? AgileStack helps teams ship enterprise-grade software without the consulting-firm overhead. Book a 30-minute call and tell us what you're working on.