When Microsoft suspended developer accounts associated with high-profile open source projects, the reaction on Hacker News followed a familiar script. Outrage from maintainers, confusion about what rule was violated, a handful of apologetic comments from people defending the policy, and a thread that spiraled into the same conversation we have every few years about corporate control of open source infrastructure.
The outrage is reasonable. The pattern it fits into is worth more attention than the incident itself.
How We Got Here
In 2018, Microsoft acquired GitHub for $7.5 billion. The open source community’s reaction was mixed at the time, but the transition was smooth enough that most concerns faded. GitHub kept operating the way it always had. Microsoft stayed largely in the background. Over the following years, they added Codespaces, Copilot, and tighter Azure integrations, but the core experience of hosting a repo, filing issues, and reviewing pull requests remained largely unchanged.
What also remained unchanged, and largely undiscussed, was the fundamental relationship: open source projects were now hosted on infrastructure owned by a publicly traded company with its own compliance obligations, commercial interests, and terms of service. The license governing your code might be MIT or Apache 2.0, but the platform serving it operates under entirely different rules.
This is not a new problem. It is a problem that the ecosystem chose to accept, implicitly, by concentrating the majority of active open source development on a single platform. The 2022 Octoverse report noted that GitHub hosts over 90 million developers and hundreds of millions of repositories. That concentration is convenient for discovery, tooling integration, and contributor onboarding. It is structurally fragile for anyone who depends on uninterrupted access.
Precedents Worth Remembering
Microsoft’s previous notable action in this space came in 2019, when GitHub began restricting accounts for users in Iran, Syria, Crimea, and other regions subject to US trade sanctions. The restrictions were not unique to GitHub, and they reflected real legal obligations under US export control law, specifically OFAC regulations. But the effect on affected developers, including contributors to major open source projects, was immediate and disorienting. Code they had written, repositories they maintained, and collaboration they depended on became inaccessible.
GitHub later walked back some of those restrictions and published a detailed account of why they had to comply. The explanation was honest. The underlying problem remained: a platform that hosts the world’s open source collaboration operates under legal frameworks that do not distinguish between a sanctioned commercial entity and a volunteer contributor in Tehran working on a math library.
The current incident involving high-profile project accounts fits this same structural pattern, even if the specific trigger differs. When an organization like Microsoft makes a platform-level decision, it does not go project by project to assess impact. It executes policy. Collateral effects on critical open source infrastructure are not a bug in the process; they are an inherent property of centralized platform governance.
What “High-Profile” Actually Means Here
The involvement of high-profile projects is significant not because those projects deserve more protection than others, but because it makes visible something that is always true: the software supply chain is more fragile than it appears.
When a widely-used library loses access to its primary development platform, even temporarily, the downstream effects are real. CI pipelines that pull from GitHub may fail. Forks that depend on specific branch structures break. Documentation that links to now-inaccessible resources becomes unhelpful. Automated release workflows that push to registries like npm, PyPI, or crates.io may be interrupted.
None of this requires a malicious actor. Automated account suspension systems operating on pattern-matching do not know whether an account belongs to a lone developer or the primary maintainer of a library used by tens of thousands of production services.
The xz utils backdoor incident in 2024 made the software supply chain’s concentration risk viscerally clear from an adversarial angle. A single maintainer of a library embedded deep in Linux distributions nearly succeeded in introducing a backdoor. The Microsoft account suspension story makes the same concentration risk visible from a governance angle. In both cases, the underlying issue is that critical infrastructure is maintained by small teams on shared platforms with centralized control.
The Alternatives Exist and Are Underused
This is not a situation without options. Codeberg, operated by a German non-profit, hosts over 100,000 repositories and runs on Forgejo, a community fork of Gitea. SourceHut takes a more spartan approach, with a mailing-list-based workflow and explicit rejection of many of GitHub’s social features, but offers genuine independence. GitLab provides self-hosted options for organizations that want to own their infrastructure entirely.
For critical infrastructure projects, a multi-homed approach is technically straightforward. Maintaining mirrors on multiple platforms requires minimal tooling:
# Add multiple remotes for push mirroring
git remote add codeberg git@codeberg.org:yourorg/yourproject.git
git remote add sourcehut git@git.sr.ht:~yourorg/yourproject
# Push to all remotes
git remote | xargs -I{} git push {} --all --follow-tagsSome projects use CI to automate this. Others use git hooks. The actual engineering effort is low. The organizational effort, getting contributors comfortable with alternative platforms, maintaining CI integrations across multiple remotes, and establishing a clear policy for which platform is authoritative, is higher but not prohibitive.
The Software Freedom Conservancy has long advocated for projects to reduce their GitHub dependency, and their Give Up GitHub campaign gained renewed attention in 2022 following concerns about Copilot’s training data. The campaign made a reasonable argument: the concentration of open source on a single commercial platform creates dependencies that are incompatible with the values of software freedom, independent of whether any specific policy is currently harmful.
The Structural Argument
There is a version of this conversation that focuses on whether Microsoft’s specific decision was fair, whether the affected accounts had violated policy, or whether the suspension system has adequate appeals processes. Those are reasonable questions and they deserve answers.
The more durable version of the conversation is about whether the open source ecosystem has made a reasonable bet by concentrating its infrastructure on a platform it does not control.
The answer, historically, is that convenience won. GitHub’s network effects, its integration with every major CI system, its pull request model that became the industry standard for code review, and its issue tracker that serves as a de facto bug database for most major projects, all of this made the concentration a rational individual choice even if it produces a fragile collective outcome.
This is not a problem Microsoft created. It is a problem the ecosystem walked into with open eyes, and events like this one are the periodic reminder that the terms of that arrangement are set by someone else.
For projects that treat their infrastructure as seriously as they treat their code, the path forward is not complicated: mirror your repositories, automate your releases to be platform-agnostic, document your contributor workflows so they can survive a primary platform outage, and treat GitHub as one node in your infrastructure rather than the whole of it. The tools to do this have existed for years. The motivation to use them tends to arrive right after incidents like this one.