The open source community absorbed another jolt this week when Microsoft suspended developer accounts associated with several high-profile open source projects, as reported by BleepingComputer. Details about the specific cause are still emerging, but the pattern is familiar enough that the cause almost doesn’t matter. What matters is that it keeps happening, and the community keeps acting surprised.
This is not a new failure mode. It is a structural one.
The 2019 Precedent Nobody Learned From
In 2019, GitHub quietly began restricting accounts belonging to developers in Iran, Syria, and Crimea. Maintainers discovered mid-session that their repositories were inaccessible. Private repos vanished behind a wall. GitHub cited US export control law (EAR) as the justification, specifically the sanctions administered by the Treasury Department’s OFAC. The legal reasoning was sound from a compliance standpoint. The execution was not: no warning, no appeal pathway, no grace period to export data.
The backlash was significant. GitHub CEO Nat Friedman posted an explanation and committed to restoring free private repo access for affected developers where legally possible. Some access was restored. But the fundamental dynamic remained unchanged: GitHub is a US company, Microsoft is its parent, and US sanctions law applies regardless of the ideological commitments of the open source projects involved.
The lesson was that the law can reach into your project at any time, through the platform. Most maintainers filed that under “edge case” and moved on.
Corporate Stewardship Has Real Limits
Microsoft acquired GitHub in 2018 for $7.5 billion. The acquisition was greeted with a mixture of optimism and dread, and the reality since has been roughly as mixed. GitHub’s feature development accelerated. Actions, Codespaces, Copilot, and package registry work all improved the platform substantially. Uptime and reliability improved. Microsoft funded open source projects it depends on more consistently than before.
But “better than before” is not the same as “safe to depend on unconditionally.”
The problem is not bad intent. It is that Microsoft is a publicly traded US company with regulatory obligations, fraud prevention systems, export compliance requirements, and terms of service enforcement pipelines. Those systems make decisions at scale using signals that do not map cleanly onto the nuances of open source project governance. An account that looks suspicious to a fraud classifier may belong to a core maintainer of a project with ten million downloads per month. The system does not know that. The system does not care.
When Microsoft suspended accounts this week, the downstream effect was not just personal inconvenience for the affected developers. It was disruption to projects that other developers, companies, and infrastructure depend on. That asymmetry is the real issue: the cost of a false positive is not borne by Microsoft. It is borne by the community.
The Governance Problem Nobody Wants to Talk About
Open source projects that host on GitHub have made a governance decision, whether they realize it or not. They have delegated authority over project access, continuity, and availability to a third party whose interests are aligned with their own most of the time, but not all of the time.
For small personal projects, that tradeoff is fine. For foundational infrastructure that the broader ecosystem depends on, it deserves more scrutiny.
Consider what it means for a project like cURL, FFmpeg, or any of the other high-profile projects that have consolidated their development on GitHub over the past decade. A suspension event does not just affect the individuals whose accounts are targeted. It can affect CI pipelines, release processes, issue triage, and the ability to push security patches. The blast radius of an account suspension scales with the size and connectivity of the project.
Alternatives exist. Codeberg is a non-profit hosted Gitea instance that has grown steadily as a GitHub alternative for projects that want infrastructure without corporate entanglement. SourceHut takes an even more minimal approach, with a strong philosophical commitment to email-based workflows and plain-text patches. GitLab can be self-hosted, which moves the dependency question from “trust this company” to “trust your own ops team.” None of these is without tradeoffs, and none has GitHub’s network effect.
But the tradeoffs are worth naming explicitly rather than defaulting to GitHub because that is where everyone else is.
What Distributed Should Actually Mean
There is an irony in the fact that software explicitly designed to be distributed, version control, is almost entirely centralized at the social and discovery layer. Git itself is decentralized by design. Every clone is a full copy. You can push to any remote. The protocol is open. Linus Torvalds built it specifically to avoid depending on any single hosting provider.
And yet the community rebuilt centralization on top of it, because GitHub added issues, pull requests, code review, stars, forks, and a social graph that made collaboration genuinely easier. Those features are sticky. They create gravity that keeps projects anchored to a platform even when the platform does something that would otherwise motivate a move.
The answer is probably not to abandon GitHub wholesale. The network effects are real and the tooling is good. The answer is to stop treating platform access as a solved problem and start treating it as a risk to manage. That means:
- Mirroring repositories to at least one other remote automatically, on every push.
- Keeping export archives of issues and pull requests, which GitHub’s API supports.
- Documenting how the project would continue to operate if GitHub access were lost for the primary maintainer.
- For large projects, distributing commit access and admin rights across maintainers in multiple jurisdictions.
None of this is glamorous work. It does not ship features. But for a project with real users, it is maintenance in the truest sense.
The Accountability Gap
What makes incidents like this corrosive is not the suspension itself. It is the opacity. When an account gets suspended, the affected developer typically receives a form email, no specific reason, and an appeal process that is slow and frustrating to navigate. For a solo maintainer with a day job, a week of inaccessibility can mean a week of a project going unpatched.
Microsoft has the resources to do better. A dedicated escalation path for maintainers of widely-used open source projects would cost relatively little to operate and would significantly reduce the blast radius of false positives. GitHub’s maintainer security advisories program shows they can build infrastructure specifically for project maintainers when they choose to. The same logic applies here.
The open source community has spent years arguing about licensing, governance models, and contributor agreements. The question of platform dependency deserves similar rigor. The code may be free, but the infrastructure it lives on is not.
Dependency is not inherently bad. Unexamined dependency is.