Fired by Google for creating the Google workspace CLI

Original Article ↗ Hacker News Discussion ↗

A Google engineer says they were fired after open-sourcing a command-line tool for Google Workspace under an official-looking GitHub organization, triggering scrutiny over branding, internal approval processes, and who controls product direction. Commenters are split between seeing this as a straightforward policy violation—especially around trademarks and skipped review—and as an example of big-tech bureaucracy stifling initiative and alienating talented builders. The incident feeds broader concerns about Google’s shifting culture, increasing risk aversion, and the chilling signal this sends to employees who want to ship useful tools on their own initiative.

Background and what happened

  • Discussion centers on a Google Workspace CLI, released on GitHub under a Google-owned org with Google branding and a “not an officially supported product” disclaimer.
  • The engineer who built it says they were fired afterward and attributes it partly to internal fear of disruption from “agents” and automation for Workspace.
  • The repo remains public and is linked from official Workspace documentation, which many find contradictory if it was truly a policy violation.

Open‑source / launch process and whether it was followed

  • Several current/ex‑Googlers describe well‑defined processes for:
    • Open‑sourcing code.
    • Using Google trademarks/branding.
    • Launching anything external (via IARC/Launcher tools, director‑level approvals, etc.).
  • Others say these processes are complex, constantly changing, and differ by org; DevRel teams historically had more autonomy and often published directly to GitHub orgs.
  • The engineer claims they followed the process and had “bits flipped” and a manager‑backed launch.
  • A self‑identified current Googler claims the engineer started the process, was confrontational in review, the launch was cancelled, and they proceeded anyway.

Branding, trademarks, and risk

  • Many argue the project name, tweet phrasing, org name, and logo made it look like an official product, which is exactly what policies are designed to prevent.
  • Others counter that dozens of Google repos use similar branding and disclaimers, and that legal concerns could have been fixed with renaming and logo changes rather than termination.

20% time, side projects, and IP

  • Commenters note that across tech, anything work‑related built with company time/resources is company property.
  • 20% projects never meant bypassing legal/launch review or competing with in‑flight internal products.
  • Some argue employees often misunderstand this, especially when coding on personal machines at home on work‑adjacent ideas.

Was firing justified?

  • One camp: violating clear policies, impersonating an official product, and ignoring legal/management decisions are legitimate grounds for firing, especially at a large, litigious company.
  • Another camp: at most this warranted a stern reprimand; firing a productive DevRel engineer who shipped a popular, API‑based tool is an overreaction and poor talent management.

Signals about Google culture and innovation

  • Many see this as emblematic of a shift from the old “20% time / build cool stuff” ethos toward risk‑averse bureaucracy, internal fiefdom protection, and fear of internal disruption.
  • Others argue that with Google’s scale and legal exposure, strong controls and centralized branding are necessary, even if they stifle some individual initiative.

Unclear / contested points

  • Whether the launch was fully approved or explicitly blocked.
  • How much the existence of an in‑progress “official” CLI or AI/agent strategy influenced the decision.
  • Why the repo is still up if it was truly unacceptable.