GitHub dominates code hosting with 180 million developers, the largest source code repository in the world. Developers choose it by default. But a closer look at recent events reveals something uncomfortable: those 180 million developers may not actually prefer GitHub. They may simply be trapped.
On August 18, 2026, Cursor launched Origin, a new code hosting platform built directly into its AI editor. The same day, GitHub suffered a six-hour global outage with 20% error rates. The timing is instructive. It exposes a fundamental truth about platform dominance: GitHub's dominance rests on switching costs and inertia, not on continuous innovation or excellence.
The Timeline: When GitHub Knew vs When It Acted
GitHub's reliability crisis is not new. An analysis by LeadDev counted 257 incidents between May 2025 and April 2026, 48 of them major — roughly one significant disruption per week. GitHub's chief technology officer has said the platform "wasn't built for the scale it's now being asked to handle".
But GitHub has known about scale challenges for years. Developers adopted ChatGPT rapidly. GitHub logged 257 outages over the past year, yet the company did not prioritize reliability until after lawsuits and public pressure. Instead, GitHub focused on enterprise features and integrations with Microsoft's cloud ecosystem.
The pattern is revealing: GitHub didn't optimize for developer experience proactively. It reacted after damage became visible.
GitHub Switching Costs: Why Developers Stay Despite Problems
Understanding GitHub switching costs explains why 180 million developers tolerate unreliability. Switching costs are not prices — they're the friction of leaving.
Network effects. Your code lives on GitHub. Your collaborators work there. Your open-source reputation is attached to your GitHub profile. Moving means recreating this social graph elsewhere. The time cost is prohibitive.
Integrations. Your CI/CD pipeline connects to GitHub Actions. Your deployments rely on GitHub webhooks. Your security tools scan GitHub repositories. Each integration represents a switching friction point. Removing GitHub from your workflow means reconfiguring dozens of connected services.
Historical accumulation. Years of commits, pull request history, and issue discussions sit on GitHub. These aren't just data — they're part of your project's institutional memory. Moving them is possible, but costly.
Organizational inertia. Your entire team already uses GitHub. Your hiring process assumes GitHub familiarity. Your documentation mentions GitHub. Changing platforms means retraining, restructuring, and documentation updates.
These switching costs are not insurmountable individually. But combined, they create a powerful lock-in effect. GitHub doesn't need to be the best; it needs to be "good enough" to justify staying. For years, it was. But outages have tested that assumption.
Why This Vulnerability Matters: The Cursor Factor
Cursor's Origin is not a complete GitHub replacement. Origin is built to interoperate with GitHub rather than replace it outright, letting teams sync existing GitHub repositories into Cursor's platform. This design choice is strategic. It lowers switching costs dramatically.
Instead of migrating entirely, developers can try Origin alongside GitHub. Instead of choosing between tools, they can work with both. This parallel approach reduces migration friction to near-zero.
Additionally, Cursor's bundling strategy matters. By combining an AI code editor with integrated code hosting and agent-native review, Cursor solves pain points GitHub ignores. GitHub treats code hosting and editor integration as separate concerns. Cursor treats them as one unified workflow.
When switching costs drop and bundled value rises, GitHub's dominance becomes fragile.
This Pattern Repeats Across Tech
GitHub's situation is not unique. Similar dynamics have fractured dominant platforms before.
Slack versus Email. Slack didn't beat email on features. It changed what communication means — making synchronous, searchable, contextual conversations the default instead of asynchronous messages. Email adoption remained high, but Slack's bundled value lowered switching costs.
Chrome versus Firefox. Chrome didn't win because browsers were needed more. It won by bundling a browser, ecosystem integration, and automatic sync — lowering friction to entry and creating network effects through shared bookmarks and settings across devices.
TikTok versus Snapchat. TikTok's recommendation algorithm created value Snapchat's chronological feed couldn't match. When one platform delivers superior value, switching costs become surmountable.
The pattern: Dominant platforms become vulnerable when they stop solving core problems. Challengers win by addressing the pain the incumbent neglects.
What This Reveals
GitHub's 180 million developers represent a massive moat — but perhaps not the moat GitHub believes it is. Hashicorp's co-founder Mitchell Hashimoto decided to pull out his Ghostty project from GitHub in April 2026 due to GitHub's reliability issues after 18 years of use. When high-profile developers leave after years of loyalty, it signals that switching costs have become bearable.
For founders and platform builders, this offers a strategic insight: dominance through lock-in is durable only as long as lock-in costs remain higher than the pain of staying. Once that equation flips — when a focused alternative lowers switching costs while addressing unmet needs — dominance fractures quickly.
GitHub switching costs are high. But they are not infinite. Cursor's Origin, alongside GitHub's outages, appears to be testing exactly where that threshold lies.
This dynamic reflects the pattern we've explored before: how controlling the editor, host and model creates vertical integration risks, and how as platforms' incentives shift toward ownership rather than service, the properties making them safe to adopt may erode. GitHub's choice to optimize for Microsoft's ecosystem over developer reliability is not malicious — it's structural. But structural incentive misalignment creates vulnerability.
The question facing dominant platforms is not "Can we maintain dominance?" but "Do our users feel locked in or genuinely served?" The answer determines whether dominance is durable or fragile.
For more on platform economics and incentive misalignment, visit Bitroot.