Something is fundamentally broken in the American open-source ecosystem, and we need to talk about it.
Over the past two years, we’ve watched a disturbing pattern repeat itself: U.S.-based companies that built their reputations — and their billion-dollar valuations — on the backs of open-source communities have systematically pulled up the ladder behind them. They’ve put up paywalls, gutted community editions, and in some cases simply walked away from the projects that made them what they are.
And as American companies retreat, international developers are stepping in to fill the void. The question nobody wants to ask out loud: are we trading one set of risks for another?
The American Sellout: A Pattern, Not an Anomaly
Let’s look at the scoreboard.
MinIO, the de facto standard for self-hosted S3-compatible object storage for over a decade, quietly put its open-source community edition into maintenance mode in late 2025. No announcement. No migration guidance. Just a README update. Earlier in the year, they’d already stripped the web-based admin console from the community version and locked it behind their $96,000/year enterprise offering. The CLI still works, sure — but the message was loud and clear: the open-source community that built MinIO’s market position was no longer the priority.
HashiCorp abandoned its Mozilla Public License for a Business Source License back in 2023, effectively killing the open-source status of Terraform, Vault, Consul, and five other projects. The CTO’s justification was revealing: competitors were “commercializing their IP.” The community’s response was equally telling — 300 partners immediately committed to forking Terraform into OpenTofu. IBM then acquired HashiCorp for $6.4 billion, and if Red Hat’s track record under IBM is any indication, the walls will only get higher.
Red Hat itself restricted access to RHEL source code, breaking the downstream rebuild ecosystem that distributions like CentOS, Rocky Linux, and AlmaLinux depended on.
And then there’s Broadcom. After its $69 billion acquisition of VMware, Broadcom turned its attention to Bitnami — a free container catalog used by millions of developers and baked into countless CI/CD pipelines. In August 2025, Broadcom moved most Bitnami container images and Helm charts behind a paywall. The pricing? $50,000 to $72,000 annually. Versioned images that teams depended on for production stability were dumped into an unsupported “legacy” repository with zero updates and zero security patches. Pipelines broke overnight. The Dockerfiles and Helm charts technically remain open-source on GitHub, but the pre-built images — the actual value — are now pay-to-play.
This isn’t a few isolated incidents. This is a pattern. American companies are systematically extracting themselves from the open-source commitments that built their user bases, their ecosystems, and their market dominance. Build in the open, grow on community goodwill, go public, then pull the rug.
As one engineer put it after the MinIO debacle: in 2025, “Open Source” isn’t enough. We need Open Governance. Projects under CNCF, Apache, or the Linux Foundation don’t get rug-pulled. Single-vendor projects do.
Enter the Alternatives: France and China Step Up
Nature abhors a vacuum, and so does infrastructure. As American companies bail on open source, two international projects have emerged as the leading alternatives in object storage alone — and they tell a fascinating story about where open-source leadership is heading.
Garage: The French Alternative That Doesn’t Trust GitHub
Garage is built by Deuxfleurs, a French non-profit dedicated to digital autonomy. It’s an S3-compatible distributed object storage system, and it takes a very different philosophical approach than its American predecessors.
First, the obvious: Garage’s primary source code repository isn’t on GitHub. It lives on Deuxfleurs’ own self-hosted Forgejo instance at git.deuxfleurs.fr. The GitHub repository is explicitly labeled as a mirror. For a project built by people who believe in digital sovereignty, relying on a Microsoft-owned platform for your primary code hosting would be a contradiction. They practice what they preach.
Garage is designed to run on modest, heterogeneous hardware — Raspberry Pis, consumer-grade internet connections, nodes scattered across different physical locations. Its design draws from Amazon’s Dynamo paper and Conflict-Free Replicated Data Types (CRDTs), but it applies that distributed systems research to a deliberately lightweight system. No ZooKeeper. No etcd. No dedicated data center backbone required.
It’s funded by European Union grants through NLnet and NGI programs — public money, not venture capital with an exit strategy. That funding model alone makes Garage structurally resistant to the kind of paywall pivots we’ve seen from American companies. There’s no board demanding monetization. There’s no IPO prospectus promising revenue growth.
The trade-off? Garage is honest about what it won’t do. Its maintainers publish an explicit list of non-goals: extreme performance, feature extensiveness, erasure coding, POSIX compatibility. It’s not trying to be everything. It’s trying to be reliable, simple, and resilient in environments that are messy and imperfect — which, frankly, describes most of reality outside hyperscale data centers.
RustFS: The Chinese Contender with a Security Problem
Then there’s RustFS. Built in Rust, licensed under Apache 2.0, and claiming 2.3x performance over MinIO for small objects. It checks all the boxes that MinIO’s community wanted: permissive licensing, high performance, S3 compatibility, and an active development pace. It’s crossed 11,000 GitHub stars, maintains a Chinese-language website at rustfs.com.cn alongside its international presence, and has already formed strategic partnerships with companies like AutoMQ.
But here’s the thing nobody in the “just switch to RustFS” crowd wants to talk about: in December 2025, security researchers discovered that RustFS had shipped with a hardcoded authentication token baked directly into the source code.
The token? The literal string “rustfs rpc.” That’s it. Every single RustFS deployment in the world shared the same master password, hardcoded on both the client and server sides, with no mechanism to change or rotate it without recompiling the software. The CVE (CVE-2025-68926) scored a 9.8 out of 10. Anyone with network access to the gRPC port could authenticate using this publicly known token and execute privileged operations including data destruction, policy manipulation, and cluster configuration changes.
Let that sink in. This wasn’t a sophisticated vulnerability. This wasn’t a subtle race condition or a memory corruption bug that only Rust’s type system could catch. This was a string literal. “rustfs rpc.” Hardcoded into both sides of the authentication handshake. Publicly visible in the source repository. As the CVE report noted: “Rust’s memory safety cannot protect against logical design failures — in this case, a password baked directly into the source code.”
And it wasn’t the only critical vulnerability. A separate path traversal flaw (CVE-2025-68705) allowed arbitrary file reads, including sensitive system files like /etc/passwd. Both were discovered by the Xmirror Security Team and have since been patched, but the fact that fundamental security hygiene like “don’t hardcode your authentication tokens” was missed raises serious questions about the maturity and review processes behind the project.
RustFS describes itself as “a project jointly initiated and composed of talented storage architects and open-source enthusiasts from across the globe.” Its about page speaks of “integrity, focus, and simplicity.” But the hardcoded secrets tell a different story — one of a project that may be moving too fast and cutting corners that can’t be cut in infrastructure software that people trust with their data.
The Real Question: What Are We Trading?
So here we are. American companies are selling out their open-source communities. AI-generated code is flooding the space, promising to democratize development but also lowering the barrier for exactly the kind of careless mistakes we saw in RustFS. And the international community — talented, motivated, and filling a real need — is stepping into the leadership vacuum.
But let’s be honest about the trade-offs.
When we adopt Garage, we’re trusting a small French non-profit with EU public funding. Their values align beautifully with the open-source ethos. But their resources are limited. They’re funded year to year through grants. What happens when that funding dries up?
When we adopt RustFS, we’re adopting a project with strong Chinese ties and a track record that already includes critical security failures. The Apache 2.0 license is great. The performance is promising. But the hardcoded “rustfs rpc” token isn’t just a bug — it’s a signal about the engineering culture and review processes behind the project.
When we stick with MinIO, we’re trusting a company that has explicitly deprioritized the open-source community in favor of $96,000/year enterprise contracts.
And when we look at the broader landscape — Broadcom gutting Bitnami, HashiCorp going BSL, Red Hat locking down RHEL — the message from American tech companies is unmistakable: open source was a go-to-market strategy, not a commitment.
What Needs to Change
The open-source community has been here before. Every time a vendor pulls a rug, the community forks, rebuilds, and moves on. OpenTofu rose from HashiCorp’s ashes. Rocky Linux and AlmaLinux filled the CentOS void. The ecosystem adapts.
But the current moment feels different. The velocity of these betrayals is accelerating. The infrastructure at stake is more critical than ever. And the alternatives filling the gap come with their own trust calculus that the industry hasn’t fully reckoned with.
Here’s what I think needs to happen:
Demand open governance, not just open source. A permissive license means nothing if a single company controls the project. Foundation-governed projects under CNCF, Apache, or similar bodies are the only reliable insurance against rug-pulls.
Take security seriously regardless of origin. The RustFS vulnerability wasn’t a nationality problem — it was an engineering maturity problem. But it’s a reminder that we need to audit what we adopt, especially when infrastructure is at stake.
Stop building critical dependencies on single-vendor projects. If your entire storage layer, your container images, your infrastructure-as-code, and your secret management all depend on the goodwill of companies with shareholder obligations, you’ve built a house of cards.
Fund open-source infrastructure like the public good it is. The EU is doing this with programs like NLnet and NGI. The U.S. government and American companies should be doing the same, instead of strip-mining the commons for quarterly earnings.
The future of open-source infrastructure is being decided right now. American companies have made their choice. The question is whether the rest of us will make ours with our eyes open.
What’s your take? Are you migrating away from MinIO or Bitnami? Have you evaluated Garage or RustFS? I’d love to hear how your team is navigating this shift.
Tags: #OpenSource #DevOps #Kubernetes #CloudNative #InfrastructureAsCode #ObjectStorage #MinIO #RustFS #Garage #Bitnami #Broadcom #TechLeadership
