Microsoft Bought GitHub for $7.5 Billion and Has Been Slowly Wrecking It Ever Since

Let me take you back to April 3rd, 2005.

The Linux kernel project just lost access to BitKeeper. Three years of depending on a proprietary version control system had just ended because a kernel developer reverse-engineered its protocols and BitMover — the company behind it — yanked the free license in response. The most important open source project in history suddenly had no version control tool.

Linus Torvalds sat down and wrote one.

On April 8, 2005, Linus Torvalds made the very first commit to a new version control system called Git — in fact, he'd written enough of Git to use Git to make the commit. In just ten days, Torvalds developed a functional enough version to be used immediately for Linux kernel development. However, this speed was the result of months of prior thinking, which had begun around November or December 2004.

Git uses SHA-1 hashes internally. Linus Torvalds has responded that the hash was mostly to guard against accidental corruption, and the security a cryptographically secure hash gives was just an accidental side effect. The design choices reflect exactly how he thought about the problem: fast, distributed, corruption-resistant, and built by one person who was furious about the alternative.

Git was originally created by Linus Torvalds for version control in the development of the Linux kernel. Today, Git is the version control system most commonly used by software developers — nearly 95% of developers reporting it as their primary version control system as of 2022.

Torvalds handed off maintenance to Junio Hamano in July 2005. He'd maintained it for roughly three months and moved on. The thing he built in anger and frustration became the backbone of the entire software industry within three years. He didn't plan that. He just needed something that worked.

How GitHub Was Built and Why It Mattered

Git was the plumbing. GitHub was the house.

Tom Preston-Werner, Chris Wanstrath, PJ Hyett, and Scott Chacon launched GitHub in April 2008. They took everything Linus had built — the distributed model, the cryptographic integrity, the branching mechanics — and wrapped it in a social layer that made collaboration effortless. Pull requests. Issue tracking. Forks. The contribution graph. Stars. Wikis. GitHub Pages. Gists. All of it free for open source projects.

It worked because it understood what developers actually needed. Not an enterprise product with procurement cycles. Not a hosted SVN server. A place where you could fork a project in one click, make a change, send a pull request, and have your fix merged before lunch. The friction of contributing to open source dropped from "get commit access" to "send a PR."

By 2018, GitHub had 28 million developers and 85 million repositories. Essentially the entire open source world lived there. Linux kernel development. CPython. Node.js. React. PostgreSQL. Kubernetes. Every significant piece of software infrastructure ran through GitHub. It was not a product. It was infrastructure for the entire industry.

That's when Microsoft decided it needed to own it.

June 4, 2018: Microsoft Pays $7.5 Billion

The announcement landed on a Monday morning. Microsoft was acquiring GitHub for $7.5 billion in Microsoft stock. Satya Nadella stood on stage next to GitHub CEO Chris Wanstrath and said GitHub would "remain an open platform."

The developer community's reaction split cleanly. Half were cautiously optimistic — Satya Nadella's Microsoft had shifted toward open source in meaningful ways, open-sourcing .NET, acquiring Xamarin, contributing to Linux on Azure. The other half remembered a different Microsoft.

They remembered the Halloween Documents — internal Microsoft memos from 1998 that were leaked to Eric Raymond and published online, where Microsoft executives discussed strategies for combating the open source threat. They remembered Steve Ballmer calling Linux "a cancer." They remembered Internet Explorer. They remembered what Microsoft had done to every technology it had ever embraced.

The U.S. Department of Justice found that Microsoft used internally the phrase "embrace, extend, and extinguish" to describe its strategy for entering product categories involving widely used open standards, extending those standards with proprietary capabilities, and using the differences to strongly disadvantage its competitors.

The three phases: Embrace — development of software substantially compatible with an open standard. Extend — addition of features not supported by the open standard, creating interoperability problems. Extinguish — when extensions become a de facto standard because of their dominant market share, they marginalize competitors who are unable to support the new extensions.

The cynical half of the developer community in June 2018 was not wrong to look at a $7.5 billion acquisition of the world's most important open source platform and see a pattern they recognized.

The First Casualty: Atom

GitHub didn't just host code. It built tools. Atom was the most important of them.

Launched in 2011, Atom was GitHub's open source text editor — built by GitHub, for developers, with extensibility at its core. The Atom shell, a separate component integrating Chromium, Node.js, and native APIs, was renamed Electron in 2015 and became the cross-platform application framework the entire industry would adopt. VS Code, Slack, Discord, WhatsApp Desktop — all built on the framework that came from Atom.

Microsoft, developing VS Code since 2015, built it on the same Electron foundation. After the acquisition, GitHub suddenly owned two editors: Atom and VS Code.

In June 2022, GitHub officially announced the discontinuation of Atom, stating that after extensive consideration, they had made the difficult decision to retire Atom as a project. Sunset date: December 15, 2022. Repository archived March 3, 2023.

The Register called it precisely: that relationship has followed a paradigm Microsoft made famous — embrace, extend, extinguish — though the sunsetting of Atom looks more like pushing dead weight out of a cloud-bound balloon rather than a strategically advantageous hit. GitHub's own spokesperson confirmed the direction: "We want to invest in our core bets over the coming years, and that means focusing on enhancing the developer experience in the cloud."

Translation: VS Code won, GitHub Codespaces won, Atom was competition, Atom is dead.

The technology that Atom created — Electron — became the bloated foundation for a generation of applications consuming gigabytes of RAM to do tasks that should take megabytes. We covered this in depth in the Zed 1.0 article. The short version: VS Code, Atom's replacement, spawns 23 processes consuming 3,549MB of RAM just to open a project folder. The man who built Electron is now building something in Rust specifically to fix the damage.

Atom was the first thing GitHub built that Microsoft killed. It wouldn't be the last.

Copilot: Training on Your Code Without Asking

June 2021. GitHub launches Copilot.

The pitch: AI pair programmer, trained on billions of lines of publicly available code, suggests completions as you type. Powered by OpenAI's Codex. Available first to subscribers at $10/month, later $19/month, eventually bundled into GitHub's enterprise plans at considerably higher prices.

What "trained on billions of lines of publicly available code" meant in practice: trained on everything in GitHub's repositories, including projects licensed under GPL, MIT, Apache, and every other open source license requiring attribution. The training happened without asking permission. Copilot suggests code from those repositories. When it does, attribution is absent. When the suggested code is GPL-licensed, no indication of that appears.

Microsoft has long been antagonistic to open-source software, waging a war against open-source pioneer Linux for decades as one notable example. This is why developers feared how Microsoft might leverage GitHub's central role in the open-source community when it first acquired GitHub for $7.5 billion in 2018.

The lawsuit arrived in November 2022. Microsoft, its subsidiary GitHub, and business partner OpenAI experienced a significant win after most of the claims of a lawsuit brought against them were dismissed by a California court. The legal battle, which started in November 2022 when programmer and lawyer Matthew Butterick filed suit, will proceed on only two out of the 22 initial claims.

The surviving claims are not minor. Two of the plaintiffs' core claims — that GitHub violated its terms of service by monetizing user code and that all of the defendants violated the open source licenses attached to the code emitted by Copilot and Codex — were not addressed in the judge's order. So the plaintiff developers are moving ahead with those claims. They also now have the opportunity to seek monetary damages.

While the lawsuit grinds through the courts, Copilot keeps running. During Microsoft's July 30, 2025 earnings call, CEO Satya Nadella said GitHub Copilot had reached 20 million users and GitHub Copilot Enterprise customers increased 75 percent quarter over quarter. Copilot revenue hit $400 million in 2025.

The community response has been pointed. One developer wrote: "I deeply resent that on top of Copilot seemingly training itself on my GitHub-posted code in violation of my licenses, GitHub wants me to look at (effectively) ads for this project I will never touch."

Calls to shun Microsoft and GitHub go back a long way in the open source community, but moved beyond simmering dissatisfaction in 2022 when the Software Freedom Conservancy urged free software supporters to give up GitHub.

GitHub took the most important concentration of open source code in human history, trained a commercial product on it without consent or attribution, and is charging $19/month for access. The licenses that governed that code — the community norms that made open source collaboration possible — were treated as a cost to be litigated around.

The Reliability Problem Nobody Wants to Say Out Loud

Here's something nobody leading a GitHub-dependent organization wants to admit: GitHub keeps going down, it keeps getting worse, and the status page is consistently behind reality.

Independent tracking and community commentary have painted a more granular picture of the platform's reliability challenges. Projects such as the "missing status page" mirror highlight discrepancies between perceived uptime and real-world incidents, documenting ongoing disruptions and degraded services that may not always be fully visible through standard status reporting.

GitHub stopped updating its status page with aggregate uptime numbers some time ago — if you use it regularly, you might have a feeling why. This is the missing version. We rebuild platform-wide and per-service uptime from archived status updates, derive minute-level downtime windows, and map incidents to services whenever the source data allows.

The current month's status page makes the point without needing much analysis. In the last week of April 2026 alone:

On April 27, customers across GitHub experienced failures with searches. Workflow run failures, projects failing to load, timed out search requests — due to an ongoing infrastructure issue. The cause: overloaded ElasticSearch clusters. The failure cascaded through Actions, Issues, Packages, and Pull Requests simultaneously. GitHub disabled the source of additional load and monitored for recovery. Total time: approximately 4 hours 15 minutes of degraded service.

On April 24-25, GitHub Actions experienced delays and timeouts for Larger Hosted Runner jobs using VNet injection in the East US region, lasting from approximately 11:39 UTC April 24 to 00:15 UTC April 25 — over 12 hours.

On April 22, the Copilot Cloud Agent service began failing during session execution for users running the Agent HQ Codex agent, lasting from 18:49 to 19:32 UTC.

That's three separate significant incidents in eight days. In April alone.

One of the most impactful incidents, on February 9, was triggered by an overloaded database cluster responsible for authentication and user management. The failure stemmed from earlier configuration changes that led to excessive background processing and resource contention, ultimately causing widespread service degradation. The event highlighted how seemingly isolated changes can propagate across tightly coupled systems, leading to platform-wide instability. More broadly, GitHub identified systemic issues such as insufficient isolation between components and inadequate backpressure mechanisms — the system struggled to protect itself under stress. Without the ability to effectively limit or redirect traffic, failures in one area could ripple through critical services, including repositories, APIs, and automation pipelines.

Insufficient isolation between components. Inadequate backpressure mechanisms. This is not the language of a platform being carefully scaled. This is the language of technical debt accumulating in an infrastructure that is not receiving the engineering investment it needs.

StatusGator reports that GitHub acknowledges incidents with an average delay of 15-30 minutes, and rates their status communication accordingly. Fifteen to thirty minutes before they even acknowledge something is wrong. If your CI/CD pipelines depend on GitHub Actions — and the majority of the industry's do — you're flying blind for at least that window on every incident.

April 23, 2026: The Merge Queue Bug

This one deserves its own section because it represents a category of failure different from everything above.

Outages are annoying. Slow performance is frustrating. But those are reversible — when service restores, you continue. What happened on April 23rd, 2026 was something else entirely: GitHub's merge queue started silently reverting code on customers' main branches. Not a handful of lines — in some cases, thousands.

Let me explain the mechanism because it's important.

A merge queue's job is to serialize PR merges so that every PR gets CI-tested against the exact state of main it will land on top of. To do that, GitHub constructs a temporary branch for each PR in the queue. Normally, that temp branch is the tip of main plus the PR's diff. That's what CI runs against, and if it passes, that's what lands.

For a few hours on Thursday, the queue was building temp branches off the wrong starting point. Instead of branching from the tip of main, it was branching from wherever the feature branch had originally diverged from main. Then it pushed the contents of that temp branch to main wholesale.

Follow the implications. If your feature branch was 50 commits behind main when it hit the queue, those 50 commits of other people's work were silently removed from main as a side effect of landing yours.

A PR with a tidy +29/-34 diff got reviewed, approved, and queued. What actually landed on main was a single commit with +245/-1,137. Thousands of lines of unrelated, already-shipped code were quietly removed. Every merge that followed went in on top of that broken history.

Three properties of this bug made it unusually nasty. The PR UI lied — you reviewed +29/-34 and the commit that landed was +245/-1,137. The thing engineers approved was not the thing that merged. That breaks the most fundamental contract of a code review system. It was silent — no merge conflicts surfaced, no check failed, no banner went up on the PR. Teams only caught it when they noticed code missing from main. It scaled with activity — the faster a repo was merging, the further its feature branches had drifted from main, and the more damage each bad merge did. The teams who most need a merge queue got hit the hardest.

CI passed because the temp branch was internally consistent. But it had nothing to do with actual main. The core guarantee of code review — that what you approved is what merged — broke silently at scale.

Teams spent hours combing through the commit graph, reconstructing commits by hand, figuring out what code had been silently dropped. In one organization, every team on GitHub's merge queue got hit — dozens of bad commits each, hundreds of existing ones clobbered before anyone noticed.

The Hacker News thread on the incident ran to hundreds of comments. Engineers describing hours of incident response. Engineering managers explaining to executives why the release they thought had shipped contained code that had been deleted after it was reviewed. Teams wondering which other bugs had slipped through undetected in a similar way.

GitHub identified the regression and rolled it back within a few hours. A few hours of a merge queue actively corrupting the main branch of every repository using it. On a platform where 70 million CI/CD jobs run daily.

The Structural Decay Under the AI Veneer

In August 2025, GitHub CEO Thomas Dohmke stepped down. No successor was named.

GitHub was folded into Microsoft's CoreAI division, with three senior executives now reporting to Microsoft leadership. The independent platform that developers trusted is now a subsidiary of a company that views it primarily as AI training data and distribution.

Read that again. GitHub — the platform where open source software lives, where the Linux kernel is developed, where the Python interpreter is maintained, where PostgreSQL takes pull requests — is now organizationally a component of Microsoft's AI division. Its purpose, from Microsoft's corporate perspective, is AI training data and Copilot distribution. GitHub Copilot revenue hit $400M in 2025.

A GitHub community discussion post from March 2026 put it directly: "The decline has recently escalated with Microsoft moving GitHub underneath its CoreAI division which clearly communicates how Microsoft thinks of GitHub. It is no longer a developer service and is instead a vehicle for selling Copilot licenses and is caught in all the hype cycles that currently go with LLM-based AI tools. GitHub no longer gets any quality of life improvements. I follow several issues that should be very easy to implement and exist in competing products, and they never get any attention from GitHub whatsoever. They are completely ignored for years on end."

The deeper issue is structural. GitHub makes money from seats and compute — Actions, Copilot, enterprise licenses — not from solving maintainer burnout. Building better discovery, quality gates, and contributor tooling would require rethinking the entire social model, breaking compatibility with a decade of workflow integrations that 100 million users depend on. For a platform processing 70 million CI/CD jobs daily, that's not a refactor, it's a whole new system. And Microsoft doesn't view GitHub as independent infrastructure anymore.

The core product — the pull request, the issue tracker, the code review workflow, the notification system — has received no meaningful improvement in years. Issues that have been open for five years with hundreds of upvotes remain unacknowledged. Basic workflow requests that GitLab, Codeberg, and Gitea ship routinely get GitHub staff responses that amount to "we'll consider it."

Meanwhile: GitHub wants developers to use Copilot to generate code for their repositories, use GitHub Actions for CI/CD, use GitHub Codespaces for development environments, use GitHub Packages for artifact storage, and use GitHub Advanced Security for vulnerability scanning. Every product layer locks you deeper into an ecosystem that reports to Microsoft's CoreAI division.

The Developers Who Left

In November 2025, Zig made its GitHub repository read-only and migrated to Codeberg, citing "bloated and buggy JavaScript frameworks, sluggish performance, and buggy GitHub Actions." The move cost them access to over $170,000/year in GitHub Sponsors donations. They left anyway.

That's not a small decision. The Zig project sacrificed $170,000 a year in donations rather than remain on GitHub. They looked at GitHub's trajectory, at the Copilot training controversy, at the performance problems, at the direction the platform was heading — and decided the cost of leaving was lower than the cost of staying.

The Software Freedom Conservancy has been making the same case since 2022. Their position has not changed and the reasons for it have only grown stronger. The GitHub Copilot lawsuit has validated the concerns about open source license compliance. The folding into CoreAI has validated the concerns about platform direction. The reliability incidents have validated the concerns about infrastructure investment.

The migration alternatives are real. GitLab is mature. Codeberg is clean and community-run. Gitea and Forgejo are self-hostable. The self-hosted stack guide covers how to run your own infrastructure for everything else — email, file sync, photos, passwords. Running your own Gitea alongside that stack is not a fantasy. It's an afternoon of configuration.

The lock-in that keeps most developers on GitHub is network effects, not product quality. The contribution graph that serves as a developer portfolio. The pull requests that serve as professional history. The integrations that every tool assumes. None of that is technical. All of it is social. And social lock-in, unlike technical lock-in, can migrate.

What Linus Actually Built

The thing that makes this story frustrating is how clean the origin is.

Linus Torvalds built Git in ten days in 2005 because a proprietary company revoked access to the tool the Linux kernel depended on. He refused to be dependent on a company's goodwill for infrastructure the open source community needed. He'd say later: "All the projects that I've had to make, I had to make because I couldn't find anything better that somebody else did."

The lesson he drew from the BitKeeper situation was not "be grateful when corporations offer free access to proprietary tools." It was "own your infrastructure." Don't let a business decision made in someone else's board room take away the tool your community depends on.

GitHub took that tool — the distributed, open, censorship-resistant version control system built specifically to avoid corporate dependence — wrapped it in a social platform, and handed the keys to Microsoft for $7.5 billion.

Microsoft, operating exactly as Microsoft has always operated, is now using that platform as distribution for a commercial AI product trained on the open source community's code without their consent, while the core product stagnates, the infrastructure degrades, and the platform gets reorganized under a division whose purpose is AI revenue.

In a memo to the Office product group in 1998, Bill Gates stated: "One thing we have got to change in our strategy — allowing Office documents to be rendered very well by other people's browsers is one of the most destructive things we could do to the company. We have to stop putting any effort into this and make sure that Office documents very well depend on proprietary IE capabilities. Anything else is suicide for our platform."

Gates wrote that in 1998. The strategy hasn't changed. What changed is the platform they're capturing. Not browsers this time. Not office documents. The entire open source software development workflow of a $12 trillion industry.

The merge queue bug corrupted your main branch silently on April 23rd. The CEO left in August 2025 with no replacement. The platform is now under CoreAI. And somewhere, Linus Torvalds is still using Git exactly as he designed it, on his own machines, for the Linux kernel, as he always has.

He doesn't need GitHub. He never did. He built the thing GitHub depends on.

The question is whether the rest of us will eventually get there too.

The Git overview covers the version control system at the foundation of all of this. The supply chain security article covers what happens when the platforms developers depend on get compromised — the Axios supply chain attack is exactly the threat model that platform concentration enables. The DevOps overview covers CI/CD pipelines and why GitHub Actions reliability failures have platform-wide consequences for engineering organizations.