Wegen einer Google-Workspace-CLI gefeuert: Der Tod eines 20-%-Projekts

Wegen einer Google-Workspace-CLI gefeuert: Der Tod eines 20-%-Projekts

GoogleCLIOpen-SourceUnternehmenskulturEntwickler-Tools

Quellen:Twitter/X + HN-Diskussion · HN

Vor zwei Monaten wurde Justin Poehnelt von Google entlassen. Der Grund: Er hatte die Google Workspace CLI (gws) entwickelt – ein Kommandozeilenwerkzeug, das Drive, Gmail, Calendar und sämtliche Workspace-APIs unter einer einheitlichen Schnittstelle vereinte, konzipiert gleichermaßen für Menschen wie für KI-Agenten.

Das Projekt schoss auf Platz 1 der Hacker News und sammelte tausende GitHub-Stars. Dann schaltete sich die Google-Rechtsabteilung ein.

Markenzeichen, Logo und »verwechselbare Amtlichkeit«

Aus der HN-Diskussion geht hervor: Der unmittelbare Auslöser war die Markennutzung. Poehnelts Projekt war unter github.com/googleworkspace/cli gehostet und verwendete Googles Logo und Markenfarben. Mehrere Kommentatoren wiesen darauf hin, dass die Projektseite allein vom Aussehen her leicht mit einem offiziellen Google-Produkt verwechselt werden konnte.

Die Position der Google-Rechtsabteilung ist eindeutig: Die nicht genehmigte Nutzung von Unternehmensmarken und Markenauftritt kann selbst bei internen Mitarbeitern einen Verstoß darstellen. In den Kommentaren standen sich zwei Lager gegenüber.

Das eine sah eine offensichtliche rote Linie: »Etwas zu veröffentlichen, das mit einer offiziellen Veröffentlichung verwechselt werden kann, zeugt von enormen Urteilsvermögensproblemen«, schrieb ein Kommentator. »Wer den vorgeschriebenen Prozess umgeht, muss mindestens mit schweren disziplinarischen Konsequenzen rechnen; wurde er zuvor ausdrücklich gewarnt, ist die Kündigung gerechtfertigt.«

Das andere Lager argumentierte, das Markenproblem hätte sich technisch einfach lösen lassen – Logo entfernen, umbenennen – wie im Fall Clawdbot → Moltbot → OpenClaw. »Google ist dafür bekannt, selbst bei Leistungsproblemen nur selten zu kündigen«, merkte ein Kommentator an. »Entweder hat sich die Unternehmenshaltung geändert, oder es steckt mehr dahinter.«

20-%-Zeit ist tot?

Die tiefere Kontroverse liegt auf der kulturellen Ebene.

Google war einst berühmt für die »20-%-Zeit«-Regelung – Ingenieure durften ein Fünftel ihrer Arbeitszeit für selbstgewählte Projekte einsetzen. Gmail, Google News und AdSense entstanden aus 20-%-Projekten. Der Tenor in den Kommentaren: Wäre Poehnelts CLI im Google von 2010 entstanden, wäre das Ergebnis möglicherweise ein völlig anderes gewesen.

»Google hat sich von einem Unternehmen, das geniale 20-%-Projekte förderte, zu einem gewandelt, das Leute genau dafür feuert«, lautete einer der am höchsten bewerteten Kommentare. Ein anderer verwies auf ein paralleles Ereignis: Googles Open-Source-CLI Gemini wurde durch die proprietäre Antigravity-CLI ersetzt – dies wurde als eine zweite Facette desselben Trends interpretiert: Interne Innovation wird nicht mehr gefördert, es sei denn, sie dient einer bestimmten Produkt-Roadmap.

Pournelles Ehernes Gesetz wurde als Erklärungsrahmen zitiert: »In einer Bürokratie werden stets diejenigen die Macht übernehmen, die für die Werte der Bürokratie selbst kämpfen, während der Einfluss derjenigen, die für die Werte kämpfen, denen die Bürokratie eigentlich dienen sollte, stetig schwindet.« Poehnelt gehört zur zweiten Kategorie – jemand, der aus eigenem Antrieb Interessantes und Nützliches entwickelt. Seine Gegenspieler gehören zur ersten – sie kümmern sich mehr um das interne bürokratische System und ihre eigene Rolle darin.

Die KI-Angst

Ein weiterer nicht zu ignorierender Kontext: Poehnelts CLI war explizit darauf ausgelegt, sowohl menschlichen Benutzern als auch KI-Agenten zu dienen. Ihr Slogan lautete »built for humans and AI agents«. Diese Positionierung geriet in direkte Spannung zu Googles intern vorangetriebener Strategie für proprietäre KI-Tools.

Wenn das persönliche Projekt eines einfachen Ingenieurs mit der kommerziellen KI-Produkt-Roadmap kollidiert, die das Unternehmen gerade plant, dann ist »Markenverstoß« möglicherweise nur der einfachste Grund, den man vorschieben kann. Ein Kommentar brachte es auf den Punkt: »Ich glaube, der wahre Grund ist, dass bestimmte Führungskräfte und Projekte innerhalb von Workspace Angst hatten, disruptiert zu werden.«

Poehnelts eigene, zurückhaltende Reaktion: »Ich werde nicht viele zusätzliche Informationen teilen, aber ich denke, dieser Fall verkörpert die Erfahrung, in einem großen Tech-Unternehmen zu arbeiten, und die Disruption, die KI auf Team-, Roadmap-, Anreiz- und Nutzerverhaltensebene verursacht.«

Die ewige Spannung zwischen Open Source und Arbeitgeber

Dieser Fall hat auch eine Diskussion über die Open-Source-Rechte von Ingenieuren ausgelöst.

Selbst innerhalb von Google ist die Frage, in welchem Umfang Mitarbeiter persönliche Open-Source-Projekte betreiben, Unternehmensmarken nutzen und interne Tools öffentlich veröffentlichen dürfen, stets eine Grauzone gewesen. Die Durchsetzung variiert enorm zwischen Teams und Vorgesetzten. Ein Kommentator: »Ich bin mir nicht sicher, ob Googler routinemäßig Nebenprojekte unter offiziellen GitHub-Organisationen veröffentlichen – Googles Policies waren in dieser Hinsicht immer schwammig.«

Der Fall Poehnelt könnte zum Präzedenzfall werden: Die Toleranzgrenzen von Großkonzernen gegenüber persönlichen Open-Source-Projekten ihrer Mitarbeiter verengen sich. Wenn ein Nebenprojekt so viel Aufmerksamkeit und Traktion erreicht, dass es die offizielle Produkt-Roadmap des Unternehmens zu stören droht, wird die Frage der Marken-Compliance zur Existenzfrage hochskaliert.

Das Material dieses Artikels stammt aus öffentlichen Informationen und Community-Diskussionen. Wenn Sie tiefere praktische Erfahrung zu diesem Thema haben, sind Hinweise auf Unzulänglichkeiten willkommen.