Justin Poehnelt, a Google Workspace DevRel engineer of nearly seven years, says he was fired for building gws, the unofficial Google Workspace CLI that topped Hacker News on launch and now sits near 29,000 stars. For every team that wired a community-built vendor tool into their automation, the episode is the same lesson: a CLI with no SLA is a side-project binary, even when it lives in the vendor’s own GitHub org.
What is gws, and why did teams adopt it so fast?
gws is a single command-line tool covering Drive, Gmail, Calendar, Sheets, Docs, Chat, and Admin, plus the rest of the Workspace surface, according to its README. It reads Google’s Discovery Service at runtime to generate its command surface dynamically, so new APIs surface as commands without a release. It ships agent skill files and emits structured JSON output built for AI agents as the primary consumer rather than humans parsing --help text.
That combination hit a nerve. On launch in early March 2026, gws topped Hacker News and gathered thousands of stars within days; the repository listing now shows roughly 29,000 stars and 1,600 forks, last updated 2026-06-24. For teams that had been stitching together per-API SDK calls or fighting OAuth boilerplate, one binary that spoke fluent Workspace was an easy dependency to reach for.
There is the appeal and the trap in the same sentence. It lived under the googleworkspace GitHub org, was announced by a Google Cloud AI director, and was built by a Google engineer on a DevRel team whose remit explicitly covers open-source abstractions over Google APIs. The CLI was a sanctioned work product, not a rogue 20%-project hack, which is exactly what makes the dependency story uncomfortable. None of that added up to support.
What happened to the tool’s maintainer?
Poehnelt says he was fired roughly two months before his 2026-06-23 post, and attributes the termination to the CLI he built and maintained, according to his own account. The timing is what lands for dependents. Two days before he was let go, Google announced at Google Cloud Next 2026 that an official Workspace CLI was in development, with Cloud CEO Thomas Kurian declaring at the same event, “the era of the pilot is over. The era of the agent is here.”
Addy Osmani, the Google Cloud AI director who publicly announced gws on 2026-03-05 with a post titled “Introducing the Google Workspace CLI: built for humans and agents,” has also since left Google. Poehnelt called Osmani’s launch announcement “the tweet that got me fired.”
Poehnelt is now building at helensfoundry.com; whether there is more context than his post discloses remains an open question.
Did the CLI ever promise stability?
No, and the README said so in plain text on the front page. It carries an explicit banner, “This is not an officially supported Google product,” and warns, “This project is under active development. Expect breaking changes as we march toward v1.0,” per the repository. That is a pre-v1.0, no-SLA, no-stability-commitment stance stated in the most visible place a maintainer can put one.
The banner matters less than who reads it. Developers who reached for gws in a weekend spike absorbed the disclaimer. Developers who wired it into CI, scheduled jobs, or an agent toolchain often did not price in what “not officially supported” means the day the sole maintainer’s employment ends. A breaking change under that banner is not a regression you can file a ticket on; it is the documented behavior of the project.
The distinction the disclaimer draws is the whole story for dependents. “There’s a CLI for that” is not “the vendor supports a CLI for that.” The first is a convenience. The second is a commitment, backed by an SLA, a support path, and someone whose job description includes keeping it working. gws was the first, dressed in the visual signaling of the second.
How much of gws ran through one person?
Almost all of the release pipeline. The repository’s release history shows the latest release is v0.22.5, dated 2026-03-31, and that release-workflow commits, including checksum verification, cargo-audit and cargo-deny runs, and installer changes, are authored by @jpoehnelt. The now-departed maintainer held the keys to the build, the security scanning, and the distribution in a single GitHub identity.
That is bus-factor-one in textbook form. A 29,000-star tool, in the vendor’s own org, with a release pipeline one author pushed through. The star count and the org branding signaled durability. The commit log said otherwise, and the commit log was public the whole time.
What are the migration options for teams that depend on gws?
Three paths, none of them free. The repository remains live and has not been taken down, so the immediate breakage is zero. The real question is what happens next, and Google has not said whether the official CLI will incorporate the open-source work, whether gws keeps receiving updates, or whether the two diverge.
| Path | What it gives you | What you carry |
|---|---|---|
| Wait for the official CLI | Vendor backing, presumably an SLA | Migration cost whenever it ships; gws frozen at v0.22.5 in the meantime |
| Adopt a community fork | Continued patches, community-driven | Fragmentation; you pick a fork and bet on its maintainer |
| Self-maintain a private fork | Full control, no external dependency | You own the release pipeline, security scanning, and breaking-change triage |
A third-party fork already exists. niclasmartinsson-sys/google-workspace-cli is an early signal of the fragmentation teams inherit when an unofficial wrapper’s maintainer exits. One fork today, a half-dozen in a quarter, each drifting on which breaking changes it accepts and which skill files it regenerates.
The agent-native angle sharpens the cost. gws was built for agents as the primary consumer, which means the teams most exposed are the ones who wired it into agent toolchains rather than human-run scripts. Those stacks are the hardest to migrate because the failure mode is silent: an agent keeps calling a command that quietly changed or stopped getting Discovery updates.
The honest framing is that every team which shipped gws into production now owns a migration it did not budget for. The cost was hidden in the dependency, and the firing is what surfaced it.
How should you evaluate an unofficial vendor CLI before depending on it?
Run the same checks you would run on any dependency whose failure breaks a workflow. The gws case is a useful template because every red flag it raised was sitting in public.
- Read the support banner. “Not an officially supported Google product” is a legal and operational statement, not modesty. If the vendor’s own disclaimer says unsupported, treat it as unsupported.
- Check the version. Pre-v1.0 with “expect breaking changes” in the README is a statement of intent. Pin the version in CI and plan for churn on the maintainer’s schedule, not yours.
- Count the maintainers. Open the release history and the commit graph. If one author pushes the release pipeline, the security scans, and the installer, you have a bus-factor-one dependency regardless of star count.
- Separate “lives in the vendor org” from “backed by the vendor.” A repo under
googleworkspace/is not a support contract. Org branding signals permission, not continuity. - Assume the exit. Before you wire the tool into CI, ask what breaks the hour its maintainer leaves. If the answer is “a lot,” that is the cost of the dependency, paid now or later.
- Watch the signaling gap. A director-level announcement, a top-of-HN launch, and DevRel authorship all read as implicit backing. None of them are an SLA.
The lesson is older than gws and will outlast it. Unofficial wrappers are valuable precisely because they move faster than the vendor. The cost of that speed is that they vanish, fork, or freeze on someone else’s schedule. Poehnelt built a useful tool, labeled it unsupported on the front page, and says he was fired for building it. The teams that depended on it are the ones who now own the consequence.
Frequently Asked Questions
How does gws differ from gcloud or Google’s official Workspace SDKs?
gcloud is Google’s supported CLI for Cloud and predates gws, but it never covered the Workspace APIs; until the 2026 official-CLI announcement, Workspace had no first-party CLI, only per-API client libraries. gws filled that gap, which is why a DevRel-built tool accrued roughly 29,000 stars instead of being crowded out by an official alternative.
What failure mode does runtime Discovery generation create for dependents?
Because gws reads Google’s Discovery Service at runtime to build its command surface, pinning the binary version pins only half the interface. A Discovery schema change can alter a command’s arguments or JSON output without a new gws release, so an agent calling that command can fail or misparse with no version bump to alert on.
Who owns gws’s release and security pipeline now that the sole maintainer has left?
No successor is visible in the release log. The history shows checksum verification, cargo-audit, and cargo-deny runs all authored by @jpoehnelt, so the supply-chain checks that produced installable binaries have no named owner after his exit. A team pulling a future build is trusting a release pipeline no one is currently paid to run.
What earlier dependency incidents does the gws pattern resemble?
It rhymes with left-pad and event-stream from the npm ecosystem, where single-maintainer packages with large downstream usage broke or were compromised when the author stepped away. gws is less acute because the repo is intact and forkable, but the structural mismatch is the same: high adoption and a vendor-org prefix were read as institutional backing that was never contracted.
Is the unofficial-CLI continuity risk unique to Google Workspace?
No. The same shape appears wherever a vendor ships APIs but no first-party CLI and a community or DevRel maintainer fills the void: Microsoft Graph has long relied on community PowerShell and CLI modules, and Stripe and Slack each have popular unofficial wrappers. When that maintainer exits, the maintenance burden lands on teams that treated the wrapper as the vendor’s own product.
