GitHub Is Now Microsoft's

Two days ago, Microsoft officially closed its acquisition of GitHub for $7.5 billion. The deal was announced back in June, and after months of regulatory review across multiple jurisdictions, it is now final. Nat Friedman, a long-time Microsoft executive and open source advocate, is the new CEO of GitHub.

The open source community has had months to process this, and the reactions span the full spectrum from cautious optimism to outright alarm. I have spent a lot of time thinking about what this means, both for the open source ecosystem broadly and for my own work.

The Case for Concern

Let me start with the concerns, because they are legitimate and deserve honest engagement.

Microsoft spent the better part of two decades actively hostile toward open source software. Steve Ballmer called Linux a "cancer" in 2001. The company engaged in aggressive patent licensing campaigns against Android vendors, effectively taxing open source adoption. The Halloween Documents, leaked Microsoft memos from the late 1990s, described a deliberate strategy to undermine open source by "de-commoditizing" protocols and standards.

GitHub is the central hub of open source development. Over 28 million developers use it. Most major open source projects, including Linux, Kubernetes, TensorFlow, and React, are hosted there. Giving a company with Microsoft's history control over that hub is, at minimum, a concentration of power that warrants scrutiny.

There is also the platform dependency question. GitHub is not just a Git hosting service. It is a social network for developers, a CI/CD platform (with third-party integrations), a package registry, a project management tool, and increasingly, an identity provider. Many developers' professional identities are built on their GitHub profiles. Handing all of that to a single corporation, even a reformed one, is a structural risk.

The Case for Optimism

The counterargument is equally compelling, and I find myself leaning toward it.

Microsoft in 2018 is not Microsoft in 2001. Under Satya Nadella's leadership since 2014, the company has made a genuine strategic pivot toward open source and cloud services. The evidence is substantial:

• Microsoft is one of the largest contributors to open source on GitHub, measured by employee contributions.
• Azure runs more Linux workloads than Windows workloads.
• Microsoft open-sourced .NET Core, Visual Studio Code, TypeScript, and PowerShell.
• They joined the Linux Foundation as a platinum member.
• SQL Server runs on Linux.
• They acquired Xamarin and open-sourced it.

These are not token gestures. They represent billions of dollars in engineering investment and fundamental shifts in product strategy. You do not port SQL Server to Linux as a PR stunt.

The financial incentive also aligns with good stewardship. Microsoft is spending $7.5 billion because developers are the on-ramp to Azure adoption. If Microsoft degrades GitHub, developers leave, and the strategic value of the acquisition evaporates. The rational play is to invest heavily in GitHub, keep it platform-neutral, and use it as a developer relations channel rather than a lock-in mechanism.

What I Am Actually Watching

Rather than debating whether Microsoft is "good" or "bad" for GitHub, I am watching specific indicators that will reveal the real trajectory.

Pricing changes. GitHub currently charges for private repositories but offers free public repositories. If Microsoft changes the pricing model in ways that disadvantage open source projects or individual developers, that is a red flag.

Platform neutrality. GitHub currently integrates with AWS, Google Cloud, Azure, and dozens of third-party services equally. If Azure integrations start getting preferential treatment (better performance, more features, tighter coupling), that signals a lock-in strategy.

Data practices. GitHub has an enormous dataset: every public commit, every issue, every pull request, every code review comment. How Microsoft handles this data, whether they mine it for competitive intelligence, use it to train AI models without consent, or maintain GitHub's existing data practices, will be telling.

Community governance. Open source project governance depends on trust. If project maintainers feel that GitHub is no longer a neutral platform, they will migrate elsewhere. GitLab saw a significant spike in repository imports immediately after the acquisition was announced. Whether that trend continues or reverses will indicate community sentiment.

Employee retention. GitHub's value is largely its engineering team and their understanding of the developer community. If senior GitHub engineers start leaving in significant numbers, it suggests internal concerns about the direction.

The GitLab Migration Question

I have seen several colleagues and open source projects migrate to GitLab, both the hosted service and self-hosted instances. GitLab is a capable platform, and competition is healthy. But I think the migration impulse is premature for most users.

Moving a large project with years of issues, pull requests, CI configurations, and contributor history is not trivial. The Git repository itself is portable (that is the beauty of distributed version control), but the surrounding metadata, the issues, the wikis, the CI/CD pipelines, the code review history, is platform-specific and difficult to migrate completely.

More importantly, migrating preemptively, before Microsoft has actually done anything harmful, sends a signal that open source communities will flee at the first sign of corporate involvement. That signal discourages corporate investment in open source infrastructure, which is ultimately counterproductive. We want companies to invest in open source tooling. We should judge them on their actions, not their history.

The Bigger Picture: Corporate Stewardship of Open Source Infrastructure

The GitHub acquisition is part of a larger trend: critical open source infrastructure is increasingly owned by large corporations. Google created and controls Kubernetes (now under CNCF, but Google retains significant influence). Facebook created React. Red Hat (soon to be IBM) controls much of the Linux enterprise ecosystem. HashiCorp controls Terraform and Vault.

This is not inherently bad. Corporate resources fund development, provide stability, and enable full-time engineers to work on projects that volunteer maintainers cannot sustain. The Linux kernel development is largely funded by corporations, and it has not suffered for it.

But it does create dependencies. When a corporation controls infrastructure that millions of developers rely on, the corporation's business interests and the community's interests must remain aligned. When they diverge, the community has limited leverage.

The structural defense against this is open standards and portable formats. Git repositories are portable. Container images conform to OCI standards. Kubernetes manifests are declarative YAML that any conformant implementation can execute. The more our tools rely on open standards rather than proprietary platforms, the more leverage communities retain.

My Position

I am keeping my projects on GitHub. Not out of complacency, but because I believe the current evidence supports cautious optimism, and because premature migration imposes costs without corresponding benefits.

I am also diversifying my dependencies. I maintain mirrors of critical repositories on GitLab. I ensure my CI/CD pipelines are defined in portable formats that could move to another platform. I keep my SSH keys and GPG keys under my own control rather than relying on GitHub's credential management.

This is not paranoia; it is engineering prudence. The same principle that says you should not run your production database on a single instance without a replica applies to your development infrastructure. Single points of failure are risks, regardless of who operates them.

Microsoft's acquisition of GitHub is a bet that developer goodwill is worth $7.5 billion. If they are right, and I think they probably are, GitHub will get better. If they are wrong, the beauty of open source is that the code, the real asset, belongs to the community and can move anywhere.

I will be watching the indicators. For now, git push origin main goes to GitHub, and I see no reason to change that.