- Google open source contributors — 6,000 of them — helped build Gemini CLI, only to be locked out when it went enterprise-only.
- The Google open source playbook follows a familiar pattern: build in public, harvest free labor, then restrict access to paying customers.
- Free and paid consumer users are being migrated to a replacement tool called Antigravity CLI, while enterprise accounts keep Gemini CLI.
- Developers need to rethink how they engage with corporate-owned repos before contributing free work to projects with no independent governance.
Google Open Source and the Gemini CLI Betrayal
The Google open source community just got a masterclass in why you should read the fine print before donating your evenings and weekends to a trillion-dollar company. Google has announced it’s deprecating Gemini CLI for free users and paid consumer subscribers, redirecting them to a new replacement called Antigravity CLI. Enterprise customers? They keep the original. Everyone else — including the roughly 6,000 developers who voluntarily contributed pull requests, bug fixes, documentation improvements, and feature work — gets a polite thank-you and a locked door.
Six thousand contributions. That’s not a rounding error. That’s a genuine, large-scale community effort by developers who believed in the project enough to invest real time and skill into it. And now the product they helped build is effectively off-limits to them unless they’re paying enterprise rates.
The Playbook Everyone Knows But Nobody Stops
This isn’t a new story. It’s one of the most well-worn moves in big tech’s relationship with the Google open source world, and it follows a depressingly predictable arc. A company launches a promising tool with an open development model. The community shows up — because that’s what developer communities do — files issues, submits patches, writes docs, tests edge cases. The project matures. It becomes reliable, well-documented, battle-tested. Then, once the hard work of early-stage development is done and the product is actually good, the company decides that goodness belongs exclusively to its paying enterprise clients.
The community wasn’t the customer. The community was the unpaid QA team, the free R&D department, and — perhaps most cynically — the marketing engine that makes enterprises feel safe buying in. When developers are visibly excited about a Google open source tool and contributing to it publicly, that’s a powerful trust signal to procurement teams at large companies. The open source energy does the selling. The enterprise license does the monetizing.
Google has done this before, of course. The company has a long history of launching products, building audiences, then discontinuing or pivoting them in ways that leave users stranded — Google Reader, Stadia, Google+, Inbox by Gmail, the list is genuinely long enough to have its own memorial website. Gemini CLI’s situation is a variation on that theme, except this time the people left behind weren’t just passive users. They were active builders.
What Google Actually Got From Those 6,000 Contributors
Let’s be concrete about what this looks like in practice. Six thousand merged contributions across a Google open source project represent an enormous amount of value. Even if you assume a modest average of two to three hours per contribution — and many PRs take significantly longer — that’s somewhere between 12,000 and 18,000 hours of skilled developer time. At typical software engineering rates, you’re looking at hundreds of thousands, potentially millions of dollars’ worth of labor. Freely given.
The contributors weren’t compensated financially. They didn’t receive equity or any stake in the project. They had no vote on its future direction. And crucially, they had no say whatsoever in the decision to restrict access. They weren’t even given a formal heads-up before the announcement. They found out the same way everyone else did.
There’s something worth sitting with there. These weren’t naive newcomers who didn’t understand how corporate software works. Many will have been experienced developers who made a calculated decision to contribute, believing — reasonably — that a tool they helped build would at least remain available to them. That calculation turned out to be wrong.
The License Loophole That Protects Nobody
Some will point out that permissive licenses like MIT and Apache 2.0 allow anyone to fork the code and carry on. That’s technically true, and it’s not nothing. But it misses the point of what actually gets taken away in situations like this. The brand, the infrastructure, the distribution channels, the official support, the community momentum — none of that transfers with a fork. You can clone the code but you can’t clone the ecosystem Google built around it. When a company pulls back from a Google open source project, the fork that emerges is almost always a pale shadow of the original.
This is why license type alone isn’t sufficient protection for contributors. What matters is governance. Projects backed by independent foundations — the Apache Software Foundation, the Linux Foundation, the CNCF — have structural protections that prevent any single corporate sponsor from unilaterally redirecting a project away from its community. A foundation-backed project can still be abandoned by a corporate contributor, but it can’t be locked behind an enterprise paywall. The community retains genuine ownership.
Gemini CLI had none of that. It was Google’s project, on Google’s terms, and Google made a business decision. The Google open source trappings were real in the sense that contributions were accepted and code was public — but the governance was always entirely corporate.
Should Developers Demand Contribution Agreements?
The question that naturally follows all of this: should developers start demanding formal contribution agreements with guaranteed access clauses before submitting work to corporate repos? It’s not as far-fetched as it sounds. Some open source projects already include contributor license agreements (CLAs) that govern how the company can use contributed code. Flipping that dynamic — requiring the company to make reciprocal commitments to contributors — would be a meaningful structural change.
Practically speaking, most large companies won’t accept that kind of arrangement. Their legal teams would kill it immediately. Which brings you to the harder question: if you can’t negotiate protections, and you can’t trust that the company’s incentives will remain aligned with yours, is contributing to corporate open source worth doing at all?
The most honest answer is probably: it depends on why you’re doing it. If you’re contributing to build skills, generate portfolio material, or get closer to a technology you use professionally, Google open source projects can still deliver on those goals regardless of what happens to the project later. But if you’re contributing because you believe you’re building something for a community that will have lasting access to it, corporate repos are a risky place to put that energy.
The Broader Cost of Shrugging This Off
Every time an episode like this plays out and the developer community absorbs it with a collective sigh of “well, it’s Google open source — what did you expect,” the implicit message sent back to large corporations is that this behavior is acceptable. It normalizes the extraction of community labor without genuine accountability, and it quietly discourages the kind of deep, trusting engagement that makes open source ecosystems so valuable in the first place. The cost isn’t just to the individuals who contributed. It’s to the health of the broader open source world.
Source: https://dev.to/adioof/google-used-6000-open-source-contributors-then-locked-the-door-classic-if7
