Seven and a Half Billion Dollars

June Fourth, Two Thousand Eighteen

On a Monday morning in June two thousand eighteen, Satya Nadella stood in front of a camera and said three words that would have been unthinkable a decade earlier. Microsoft is acquiring GitHub. The price: seven and a half billion dollars. In Microsoft stock, not cash. Seven and a half billion for a company that had never turned a profit.

The developer community lost its collective mind. Not because the number was absurd, though it was. Not because GitHub was struggling, though it had been. But because of the buyer. Microsoft. The company whose former CEO had called Linux a cancer. The company that had spent a decade threatening open source projects with patent lawsuits. The company with a playbook so infamous it had its own Wikipedia page: embrace, extend, extinguish.

That Microsoft now wanted to own the platform where most of the world's open source code lived. Where twenty-eight million developers collaborated. Where the JavaScript package registry hosted every npm module. The place that had become, for better or worse, the central nervous system of modern software.

The immediate reaction was predictable. Developers started migrating repositories to GitLab. Memes flooded Twitter. Think pieces declared the death of open source. A petition circulated demanding GitHub resist the acquisition. And on GitLab's servers, the import tool buckled under the load. Thirteen thousand projects arrived in a single hour. Fifty thousand in the first week.

But here's the thing about panic. It burns hot and it burns fast. And the story of Microsoft acquiring GitHub is not really the story of that panic. It's the story of how a corporation spent four years quietly becoming something different, and whether the rest of the world would believe it.

The Company That Called Linux a Cancer

To understand why developers panicked, you need to understand the Microsoft they remembered.

June first, two thousand one. Steve Ballmer, Microsoft's CEO, sat down with the Chicago Sun-Times for an interview. The topic was Linux, the open source operating system that was starting to eat into Microsoft's server market. Ballmer did not mince words.

Linux is not in the public domain. Linux is a cancer that attaches itself in an intellectual property sense to everything it touches.

Cancer. Not a competitor. Not a challenge. A disease. And Ballmer wasn't speaking off the cuff. This was Microsoft's position, articulated by its CEO to a major newspaper.

The logic, if you could call it that, went like this. The GNU General Public License, the license that governs Linux, requires that any software built on top of GPL code must also be open source. Ballmer framed this as a kind of infection. Touch Linux, and your proprietary code becomes open source. A cancer that attaches itself to everything it touches.

It was wrong, of course. The GPL doesn't work that way in practice for most commercial software. But the metaphor stuck. For years afterward, "Microsoft thinks Linux is a cancer" was shorthand for the company's relationship with open source.

And it wasn't just words. Microsoft backed them up with action. In two thousand seven, the company told Fortune magazine that Linux and other open source software violated two hundred and thirty-five Microsoft patents. They never identified which patents. They just let the number hang in the air, a legal threat vague enough to be terrifying and impossible to refute.

Then came the deals. Microsoft approached Linux vendors, one by one, offering "patent protection" agreements. Novell signed one in two thousand six, paying Microsoft for a promise not to sue Novell's Linux customers. The message was clear: use Linux, and you might get sued. Unless you pay us.

The open source community had a phrase for this strategy, borrowed from the Department of Justice's antitrust case against Microsoft in the nineties. Embrace, extend, extinguish. First, adopt a standard. Then, add proprietary extensions that only work with your product. Finally, when enough people depend on your version, kill the original. The Internet Explorer wars with Netscape. The Java disputes with Sun Microsystems. The Office file format lock-in. The pattern repeated for a decade.

So when developers heard "Microsoft is buying GitHub" in two thousand eighteen, they weren't reacting to a single announcement. They were reacting to twenty years of history. Twenty years of watching Microsoft treat open source as a threat to be neutralized, not a movement to join.

Satya Nadella's Microsoft

But the developers who panicked in June two thousand eighteen had missed something. Or rather, they'd noticed it but didn't trust it. Because by two thousand eighteen, Microsoft had been quietly transforming for four years. And the transformation started at the top.

On February fourth, two thousand fourteen, Satya Nadella became Microsoft's third CEO. He replaced Ballmer, the same man who called Linux a cancer. Nadella was an insider, twenty-two years at the company, most recently running the cloud division. He was not an obvious choice for a revolution. But within months, the signals started coming.

October two thousand fourteen. Microsoft open-sourced dot-NET. Not a side project. Not a small library. The core framework that millions of Windows developers had been building on for over a decade, released under the MIT license, the most permissive open source license there is. Anyone could use it, modify it, build on it, even compete with Microsoft using their own technology. For a company that had spent years treating open source as an existential threat, this was like the Pentagon open-sourcing its missile guidance software.

Then Visual Studio Code. A free, open source code editor from Microsoft. It launched in two thousand fifteen and within two years became the most popular editor in the world. Not the most popular Microsoft editor. The most popular editor, period. Developers who would never touch a Microsoft product were suddenly using a Microsoft product every day.

Then, in August two thousand sixteen, something that would have been inconceivable under Ballmer. Microsoft shipped the Windows Subsystem for Linux. A real Linux kernel, running inside Windows. Not a virtual machine. Not an emulator. Actual Linux, blessed and distributed by Microsoft. Nadella stood on stage and showed a slide with three words that became a meme.

Microsoft loves Linux.

The audience laughed. Some nervously. Some in genuine disbelief. The CEO of Microsoft, on stage, declaring love for the operating system his predecessor called a cancer. Either this was the most elaborate embrace-extend-extinguish in history, or something had genuinely changed.

What had changed was the business model. Under Ballmer, Microsoft made money selling software licenses. Windows, Office, SQL Server. In that world, Linux was a direct threat. Every server running Linux was a server not running Windows Server. Every developer on Linux was a developer not buying Visual Studio.

Under Nadella, Microsoft made money from cloud services. Azure. Office three sixty-five. The subscription model. In that world, it didn't matter what operating system you ran. It mattered where you ran it. And by two thousand eighteen, more than half the virtual machines on Azure were running Linux. Microsoft was making billions from the operating system its former CEO had called a disease.

We are a developer-first company, and by joining forces with GitHub we strengthen our commitment to developer freedom, openness, and innovation.

Nadella wrote those words in a blog post on the day of the acquisition announcement. By the time the GitHub acquisition was announced, Microsoft had quietly become the single largest contributor to open source projects on GitHub. Not by lines of code committed, but by number of employees with public GitHub activity. More than any other company on the planet. The transformation wasn't a press release. It was thousands of individual engineers, contributing to thousands of projects, day after day, for years.

The Promises

The deal came with promises. Specific ones.

Nat Friedman would be the new CEO of GitHub. Not a Microsoft lifer. Friedman was the former CEO of Xamarin, a company Microsoft had acquired in two thousand sixteen that made tools for cross-platform mobile development. He was an open source veteran who had been writing open source software since the nineties, contributing to the GNOME desktop environment, building Ximian with Miguel de Icaza. He was, deliberately, someone the open source community might trust.

On the day of the announcement, Friedman posted a letter to the developer community. It was direct, plainly written, and noticeably free of corporate language.

I'm not asking for your trust, but I'm committed to earning it. GitHub will operate independently as a community, platform, and business. We will always support developers in their choice of any language, license, tool, platform, or cloud.

Three promises stood out. First, GitHub would remain independent. It would keep its own culture, its own leadership, its own product direction. Microsoft would be the owner, not the operator. Second, GitHub would remain a platform for everyone. Not just Microsoft developers. Not just Azure users. Everyone. Including developers building software for Amazon Web Services, Google Cloud, and every competitor Microsoft had. Third, public repositories would stay free. The community had built GitHub into what it was. Microsoft would not charge them for it.

Chris Wanstrath, the co-founder who had negotiated the sale, moved to Microsoft as a technical fellow. He had been running GitHub as CEO after Tom Preston-Werner's departure in two thousand fourteen, and the company had struggled. GitHub had raised over three hundred and fifty million dollars in venture capital but was still losing money. The engineering culture had issues. The product had stalled. Multiple CEO searches had failed. By two thousand seventeen, GitHub was in a difficult position: beloved by developers, essential to the industry, and unable to turn a profit.

I'm confident that GitHub and Microsoft share a common vision, and together we will be able to achieve more for developers than either company could alone.

The acquisition closed on October twenty-sixth, two thousand eighteen. Four months of regulatory review, no objections. And then the real test began: whether the promises meant anything.

The Exodus That Wasn't

Let's talk about the migration. Because it happened, and it didn't.

In the days after the announcement, GitLab's import tool nearly melted. Their servers saw ten times the normal daily load. Thirteen thousand projects imported in a single hour. By the end of the first week, over fifty thousand projects had moved.

The numbers sounded dramatic. They were dramatic, from GitLab's perspective. The company, which had been growing steadily as an open source alternative to GitHub, saw a sudden burst of attention and users it had been working years to earn.

But from GitHub's perspective, fifty thousand projects was noise. GitHub hosted over fifty-seven million repositories at the time. The migration represented less than a tenth of one percent of the platform. Most developers, even angry ones, stayed put.

There were practical reasons for this. Moving a repository is easy. You run git push to a new remote and you're done. This is one of the beautiful things about Git's distributed design, the thing we talked about back in episode six. Every clone is complete. There is no lock-in at the version control level.

But moving a project is hard. The issues, the pull requests, the CI pipelines, the integrations, the contributor community, the links that thousands of blog posts and Stack Overflow answers point to. None of that comes with a git push. The code is portable. Everything built around the code is not.

And that's the paradox at the heart of GitHub's position. Git itself is radically decentralized. Linus built it that way on purpose. Any clone can be the source of truth. There's no privileged copy. What git fetch does is simply ask another repository, "What do you have that I don't?" and git pull goes one step further, automatically merging the answer into your current work. The distinction between fetch and pull matters here. Fetch downloads new data but lets you decide what to do with it. Pull downloads and merges in one step. With the rebase flag, git pull dash-dash-rebase, it replays your local changes on top of the remote ones, keeping a cleaner history.

The point is: switching where your code lives is trivially easy. Git was designed so that no single server matters. But switching where your project lives, with all its social infrastructure, is brutally hard. GitHub's moat was never the code. It was everything around the code.

So the exodus that the memes predicted never materialized. Some high-profile projects moved. Most didn't. The developers who left were the ones most ideologically committed to avoiding Microsoft. The developers who stayed were the ones whose projects were too deeply integrated to move, or who decided to wait and see.

The Follow-Through

And then something unexpected happened. Microsoft actually kept its promises.

January two thousand nineteen, three months after the acquisition closed. GitHub announced that private repositories were now free for all users. Unlimited private repositories, up to three collaborators. The feature that had been GitHub's primary revenue source for individuals, the reason anyone paid for a personal account, was now free. Microsoft's deep pockets meant GitHub no longer needed to charge individuals for privacy.

This was not an obvious move. It was the opposite of what "embrace, extend, extinguish" would predict. An acquirer strip-mining value would have raised prices, not eliminated them. Microsoft was spending money to grow the platform, not extracting money from the platform.

Then came GitHub Actions, a continuous integration and deployment system built directly into GitHub. Before Actions, developers needed external tools like Travis CI or CircleCI to automatically test their code. Actions made it native. Push code, tests run. Open a pull request, checks appear. Build and deploy, all from inside GitHub. For public repositories, it was free. This single feature effectively killed several independent CI companies overnight.

Then the npm acquisition in March two thousand twenty. GitHub absorbed the JavaScript package registry, home to over one million packages, and committed to keeping it free and open. npm had been struggling financially for years. Under GitHub, it stabilized.

Then GitHub Copilot in June two thousand twenty-one. The most visible and most controversial product of the Microsoft era. An AI pair programmer, trained on public code repositories, that could suggest entire functions as you typed. Built on OpenAI's Codex model, which itself was built with Microsoft's billion-dollar investment in OpenAI. Suddenly the reason Microsoft wanted GitHub became clearer. It wasn't just about hosting code. It was about the data.

Copilot raised questions that are still being debated. Was it legal to train an AI on public repositories? Did the open source licenses that governed that code permit it? The Free Software Foundation argued no. Microsoft argued that training on public code was fair use, no different from a human developer reading public code and learning patterns from it. Lawsuits followed. As of this recording, they're still winding through the courts.

But set aside the legal questions for a moment and look at the business logic. Microsoft spent seven and a half billion dollars on GitHub. Then it invested thirteen billion dollars in OpenAI. Then it combined them to create Copilot, which by two thousand twenty-four had over a million paying subscribers at roughly ten dollars a month. That's more than a hundred million dollars a year in recurring revenue from a product that only exists because Microsoft owns both the platform where the training data lives and the AI company that knows how to use it.

Nat Friedman stepped down as CEO in November two thousand twenty-one, replaced by Thomas Dohmke. Friedman had done exactly what he promised. GitHub remained independent. The platform stayed neutral. Public repositories stayed free. Under his leadership, GitHub's user base grew from twenty-eight million to seventy-three million developers. Whatever you thought of the acquisition, the numbers were hard to argue with.

One Company, All the Code

So Microsoft kept its promises. Private repos became free. The platform grew. GitHub Actions made CI accessible. Copilot launched an entirely new product category. By every conventional metric, the acquisition was a success.

But the story isn't that simple. Because while Microsoft was being a good steward of GitHub, the concentration of power was deepening in ways that should make anyone uncomfortable.

Think about what one company now controls. GitHub hosts over three hundred million repositories and more than a hundred million developers. That's the collaboration platform. npm, the JavaScript package registry, serves billions of downloads per week. That's the distribution system for the world's most widely used programming language. GitHub Actions runs millions of CI pipelines. That's the build and test infrastructure. Copilot, trained on all that public code, writes an increasing percentage of new code. That's the creation tool.

Platform. Registry. Pipeline. And now the AI that writes the code itself. All owned by one company.

Each of these acquisitions and launches was individually defensible. GitHub needed a buyer with resources. npm needed stability. Actions made developers' lives easier. Copilot genuinely increases productivity. No single step was villainous.

But the cumulative effect is something new. No single entity has ever controlled this much of the software supply chain. When the same company owns the platform where code is stored, the registry where packages are distributed, the CI system where code is tested, and the AI that generates new code, the layers of potential leverage are staggering. Not leverage that Microsoft is exercising today. But leverage that exists, waiting for the moment when commercial interests and community interests diverge.

The open source community has a long memory. They remember that Microsoft's transformation coincided perfectly with a business model shift that made Linux profitable instead of threatening. They note that "Microsoft loves Linux" translates directly to "Microsoft loves the sixty percent of Azure virtual machines that run Linux and generate billions in cloud revenue." The cynical reading isn't that Microsoft changed its values. It's that Microsoft changed its business model, and the values followed.

The charitable reading is simpler. Companies are made of people. The people at Microsoft in two thousand eighteen were not the people at Microsoft in two thousand one. Satya Nadella genuinely believed in open source. Nat Friedman genuinely loved the developer community. The engineers contributing to open source projects did it because they wanted to, not because a memo told them to. Institutions can change when their leaders change, especially when the new direction also happens to be profitable.

Both readings can be true at the same time.

Can Corporations Change?

The question that hangs over this episode isn't whether Microsoft was good for GitHub. By most measures, it was. The question is whether a corporation can be a trustworthy steward of public infrastructure, and whether the answer matters if the alternatives are worse.

GitHub before Microsoft was beloved but struggling. It was burning through venture capital, couldn't find a permanent CEO, and hadn't figured out how to be profitable. The open source community loved it, but love doesn't pay server bills. If Microsoft hadn't bought GitHub, someone else would have. The other rumored bidders included Google and Amazon. Would the open source community have trusted them more? Less? The same?

The uncomfortable truth is that public infrastructure run by private companies is the default state of the internet. AWS hosts a terrifying percentage of the web. Google runs the most popular email service, search engine, and mobile operating system. Cloudflare sits between a significant chunk of all internet traffic and its destination. We've accepted this bargain for two decades: private companies build and maintain public infrastructure because nobody else will, and we hope that competition and regulation keep them honest.

GitHub fits this pattern perfectly. Git itself remains free and open source, maintained by Junio Hamano and a community of contributors, exactly as it has been since two thousand five. Anyone can run their own Git server. Anyone can use GitLab, Gitea, Forgejo, SourceHut, or any other hosting platform. The lock-in isn't technical. It's social. And social lock-in is the hardest kind to break.

Back in episode six, we talked about how every clone is a kingdom. How Git was designed so that no server is special. How "origin" is a convention, not a requirement. Linus built Git to be resilient against exactly this kind of centralization. The technology works exactly as designed.

But the people using the technology chose convenience over resilience. They chose the platform with the most users, the smoothest interface, the best network effects. They chose GitHub. And now GitHub is Microsoft.

The git fetch command asks a remote repository one simple question: what do you have that I don't? It doesn't care who owns the remote. It doesn't check the corporate structure of the server operator. It just wants the commits. That's the beauty of Git's design. The code is free no matter who hosts it.

The question for the next decade isn't whether the code is free. It's whether the platform is fair. Whether the collaboration tools, the package registries, the CI systems, the AI pair programmers, whether all of that remains open and accessible. Not because it has to. There's no license that requires it. But because the company that owns it decides to keep it that way.

Microsoft spent seven and a half billion dollars on a bet that developers would trust them. Four years of open-sourcing dot-NET, shipping Linux inside Windows, contributing to thousands of open source projects, all of that was the down payment. The acquisition was the ask. And the follow-through, the free private repos, the growing platform, the kept promises, that was the answer.

The developers who migrated to GitLab in a panic were right to be cautious. The developers who stayed and watched were right to wait. And the developers who now depend on GitHub for their livelihood, their identity, their contribution history, their CI pipelines, their package distribution, and increasingly their AI coding assistant, they are right to keep asking the question.

Because the question never goes away. It just moves. From one acquisition to the next. From one platform to the next. From one moment when commercial interests and community interests align, to the next moment when they don't.

Git was built for a world without gatekeepers. The challenge is that we keep building gatekeepers on top of it. And now the biggest gatekeeper of all sits in Redmond, Washington, politely holding the door open, patiently earning trust, and controlling more of the software supply chain than any company in history.

Can corporations change? Microsoft did. But the next question is harder. Does it matter, if the power stays the same?

git fetch and git pull. Two commands that sound alike and do very different things. Fetch asks the remote one question: what do you have that I do not? It downloads the answer and then does nothing. Your branch stays where it is. Your files do not change. You just know more than you did a minute ago. Pull asks the same question and then immediately acts on the answer, merging the remote changes into your work. The difference is the difference between checking the weather and walking outside. One informs. The other commits you.