A nearly seven-year Google veteran says he was terminated for building an open-source command-line tool for Google Workspace — a project that was hosted under Google's own GitHub organization and publicly promoted by his manager before the company's legal team turned against it.
A DevRel Project That Outran Its Own Disclaimer
Justin Poehnelt worked in Developer Relations for Google Workspace, a team whose job, by his own description, was to regularly create open-source layers and abstractions over Google's APIs. His Workspace CLI followed that pattern: a command-line tool meant to simplify how developers work with Workspace APIs, released under the official googleworkspace GitHub organization and carrying the standard DevRel disclaimer that it was not an officially supported Google product.
It did not stay a side project for long. The tool was championed publicly by Poehnelt's then-manager, web engineer Addy Osmani, and quickly climbed Hacker News. What changed the calculus inside Google, according to Poehnelt, was not the disclaimer — it was the branding. The repository carried Google's logo and brand colors, the kind of visual association that normally requires sign-off long before a project goes live.
Legal's Question Came Down to a Logo, Not a Feature
Poehnelt has said the experience swung from directors and leaders asking what they could learn from the tool to getting grilled by legal about why the Google logo and brand colors appeared on the repository. That detail is central to understanding why a project hosted on Google's own infrastructure still became a firing offense: using the Discovery Service to build a Workspace CLI is a technical decision a DevRel engineer can make alone, but using Google's trademarked logo and brand palette on a public repository is not — it is the kind of asset use that formal brand and legal review exists specifically to control.
Poehnelt has not disputed that the formal process wasn't followed. What remains contested is whether that was the actual reason for the termination or the justification used for a decision driven by something else: a separate, competing official Workspace product reportedly already in development inside Google, using the same underlying APIs.
Cloud Next's Timing Turned the Firing Into a Contradiction
The detail that has driven most of the public reaction is the sequencing. Poehnelt has said the irony of his termination was that Google announced at Cloud Next, two days before he was fired, that an official Workspace CLI was coming. In other words, the company terminated the engineer who had already built a working version of the product it was about to announce as new.
That timing is why the story reads, to much of the developer audience following it, as an organizational failure rather than a simple policy violation. A brand-compliance issue is normally resolved with a takedown request, a rebrand, or a formal review — not a termination, particularly when the repository sat under Google's own organizational account and had been actively promoted by a manager. Google has not issued a public statement explaining the decision, and the company's internal reasoning beyond the branding question remains unconfirmed.
Why Chrome and Workspace Don't Play by the Same Open-Source Rules
Discussion on Hacker News surfaced a structural explanation that the branding dispute alone doesn't capture: commenters familiar with Google's internal practices have noted that whether Poehnelt's release without prior approval was appropriate depends on whether he had Google's brand asset clearance, which by some accounts he did not. Former Google engineers participating in the discussion described a real divergence in how different product areas handle open-source releases — some groups have historically allowed engineers to publish projects without a formal review cycle, while others, particularly in Cloud and Workspace, require sign-off from legal, privacy, and brand teams before anything goes out under an official account.
That divergence matters because it means the same action — building and releasing a CLI under an official org account — can be unremarkable in one part of the company and a terminable offense in another. Critics have argued that a seven-year veteran should have known which rules applied to his own team, even if the company's internal expectations weren't applied consistently company-wide.
What's Still Unresolved
Two questions remain open, and neither has been answered by Google directly. The first is why the individual engineer faced immediate termination when the project lived on an official corporate repository and had been actively promoted by his own manager — a chain of approval that, on its face, extended well beyond one person's judgment. The second is whether the existence of a competing internal team building a similar product played any role in the decision, as Poehnelt has suggested, or whether the brand and trademark issue was the entire explanation.
The repository itself has not been taken down. The Workspace CLI remains live under Google's official GitHub organization, Poehnelt's contributions still visible alongside the company's other developer relations projects — an outcome that, on its own, undercuts the idea that the tool's existence was the core problem.
Comments (0)
Please sign in to join the discussion.
No comments yet.
Be the first to share your perspective on this topic.