BleepingComputer reported this week that Microsoft suspended developer accounts associated with high-profile open source projects. The details are still emerging, and Microsoft has not provided public justification at the time of writing. What the event does, regardless of how it ultimately resolves, is force into focus something the ecosystem has been comfortable ignoring: the two platforms that host the overwhelming majority of open source software, GitHub and npm, are both owned by the same company.
Microsoft acquired GitHub in June 2018 for $7.5 billion. It acquired npm in March 2020. Those two events together produced a situation with no real historical precedent: a single corporate entity controls the primary source code hosting platform and the primary package registry for the world’s most widely deployed programming language ecosystem. If you write JavaScript or TypeScript, the place where your code lives and the place where your dependencies live are both Microsoft property.
What Platform Risk Actually Means
Platform risk is one of those terms that sounds abstract until it is not. The practical definition is simple: your ability to continue operating depends on decisions made by an entity whose interests are not identical to yours, and whose decision-making you cannot audit or appeal in any meaningful way.
For individual developers and small open source projects, the risk is direct. An account suspension, whether for policy violation, sanctions compliance, automated system error, or reasons never communicated, cuts off access to the canonical location of your code and your ability to publish packages. It does not matter whether the suspension is ultimately reversed. The window during which you cannot push releases, cannot respond to security issues, cannot direct new contributors to your repository, is a real operational failure regardless of duration.
For downstream consumers of open source, the risk is one step removed but not smaller. A project that cannot publish to npm because of an account issue cannot ship security patches through the channel that every package manager in the npm ecosystem resolves against. The security surface of every application depending on that package widens until the issue is resolved.
The Precedents Worth Knowing
This is not the first time platform control over open source infrastructure has caused visible damage.
In October 2020, GitHub took down the youtube-dl repository in response to a DMCA takedown notice filed by the RIAA. youtube-dl is a command-line tool for downloading video from public URLs; it has extensive legitimate uses, and the DMCA claim was legally disputed. GitHub reinstated the repository about a month later after the Electronic Frontier Foundation argued the takedown was improper, but the month-long removal demonstrated precisely what account or repository actions look like in practice: swift, automated or semi-automated, and slow to reverse.
In 2019, GitHub suspended accounts belonging to developers in Cuba, Iran, Syria, and Crimea, citing US sanctions law. GitHub is a US company and is legally required to comply with OFAC regulations, so the suspensions were not arbitrary. But they affected developers who had committed no policy violations and who had been using GitHub to collaborate on open source projects with no commercial dimension. Some developers lost access to years of work. GitHub later worked to restore access and lobbied for export control exemptions for open source software, ultimately obtaining them for some regions. The episode illustrated that the legal obligations of a US platform operator can fall on users who had no reason to anticipate them.
In 2022, npm removed the Tornado Cash packages from the registry after the US Treasury added Tornado Cash to the OFAC sanctions list. This was a package removal, not an account suspension, but the mechanism is the same: platform operators responded to legal or regulatory pressure by taking action against code. Whether you think that particular action was correct or not, the structural point stands. npm holds the ability to remove any package, and it will exercise that ability when regulatory pressure requires it.
The common thread across these episodes is not bad intent. GitHub has, in most cases, eventually done the right thing and worked to limit the harm. The thread is the structural fact that any centralized platform operator will periodically receive legal demands, government pressure, or automated system triggers that produce outcomes harmful to some set of users, and the users affected have limited recourse.
The Concentration Problem
What makes the current situation different from historical platform risk is the degree of consolidation.
GitHub has somewhere around 100 million developers and hosts hundreds of millions of repositories. Its network effects are now so strong that the practical cost of leaving is not just migrating your repository; it is leaving behind the issue tracker history, the PR review threads, the GitHub Actions CI pipelines, the Dependabot configuration, the integration with dozens of other tools that assume GitHub as the source-of-truth. GitHub has become infrastructure in the same way that SMTP is infrastructure, except that SMTP is a protocol implemented by competing servers, and GitHub is a proprietary service.
npm is, if anything, more concentrated in a more dangerous way. The npm registry is the default package source for Node.js, Deno with its compatibility shim, and by extension the broader JavaScript ecosystem. The resolution chain for a modern JavaScript application might involve hundreds of transitive dependencies, all resolving against registry.npmjs.org. There are mirrors and caches at the CDN level, but the authoritative source for package metadata and tarballs is a single registry operated by npm Inc., which is owned by GitHub, which is owned by Microsoft.
The git protocol is open. Anyone can run a git server. But the coordination layer that most open source JavaScript operates through, the place where packages are published, where version ranges are resolved, where provenance is established, is controlled by a single entity.
What Technical Mitigations Exist
The mitigations exist. They are not widely adopted, and adoption varies by ecosystem.
For source code hosting, Codeberg is a nonprofit Gitea instance operated by Codeberg e.V., a German registered association. Forgejo is a community-driven fork of Gitea maintained under the Codeberg umbrella. Both support the core git protocol, issue tracking, and PR workflows. Self-hosted Gitea or GitLab instances give teams complete control over their repository hosting. The friction cost is real, especially the loss of GitHub’s discovery and social graph, but the technical barrier to migration is not high.
For package distribution, Deno’s JSR is the most interesting new entrant. JSR is a TypeScript-first package registry that is open-source and whose governance is separate from npm. It does not replace npm for existing packages, but it represents a plausible alternative publishing channel. Organizations running internal package infrastructure often run Verdaccio as a private npm proxy, which also caches upstream packages and can serve as a partial mirror.
The npm registry itself has a replication protocol and there are mirrors, including those maintained by large CDN providers. But the mirrors replicate data; they do not replicate the authority to publish or remove packages. A mirror of npm can serve existing package versions; it cannot unilaterally reinstate a removed package or authorize new publishes from a suspended account.
Whether the Community Has Actually Addressed This
The honest answer is no, not in any systematic way.
The youtube-dl takedown prompted a round of discussion about GitHub dependence. The Iranian developer suspensions prompted a round of discussion about geographic risk. The Tornado Cash npm removal prompted a round of discussion about smart contract infrastructure on public registries. Each episode produced genuine concern and then, once the immediate situation resolved, gradual return to the status quo.
The structural incentive to stay on GitHub is not laziness or naivety. It is a rational response to network effects. The value of GitHub for an open source project is not just repository hosting; it is the probability that a potential contributor already has an account, already knows the workflow, and will not encounter friction when submitting a PR. Moving to Codeberg solves the platform risk problem and creates a contributor acquisition problem. For most projects, the second problem feels more pressing than the first.
This is the same dynamic that makes any dominant platform hard to displace even when users recognize its risks. The switching cost is not just operational; it is social. GitHub’s issue tracker is where your community’s institutional memory lives. Your GitHub Actions workflows encode your build and release process. Your GitHub Sponsors profile funds your development. Leaving is not a technical migration; it is abandoning an accumulated social infrastructure.
The ecosystem has made partial progress. The Software Freedom Conservancy runs advocacy and its Give Up GitHub campaign has moved some prominent projects. The European Commission has invested in self-hosted open source infrastructure as part of its open source strategy. These are meaningful efforts, but they have not shifted the aggregate distribution of open source hosting in any measurable way.
The Real Question
The question is not whether the current concentration is bad. It clearly creates fragility. The question is what the ecosystem’s risk tolerance is, and whether any event will shift that tolerance enough to change behavior at scale.
High-profile project suspensions, even temporary ones, are probably the most effective event type for changing minds. A suspension affecting a project with a large user base and active maintainer community makes the risk concrete in a way that a policy change or an abstract warning does not. If that is what this week’s news turns out to be, it may have more lasting effect on hosting diversity than the previous episodes did.
But the pattern so far is concern, partial resolution, return to normal. Platform concentration in open source infrastructure has been documented and discussed for years. The documentation and discussion have not produced structural change. What would produce it is unclear, and the answer may be that the ecosystem does not change this voluntarily, and instead waits to see what happens when something goes wrong that does not get fixed quickly.
That is a reasonable bet for any individual project to make. It is not a sound collective strategy for infrastructure that the global software industry depends on.