Sviluppa Google Workspace CLI per gestire i servizi da terminale: licenziato

Qualche mese fa un ormai ex sviluppatore dell’azienda di Mountain View, Justin Poehnelt, ha sviluppato Google Workspace CLI, uno strumento innovativo per interagire con Google Workspace dal terminale, senza scrivere ogni volta chiamate REST, occuparsi della gestione OAuth, della paginazione, dei payload JSON e dei controlli sugli errori. Il progetto propone una singola CLI per Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin SDK e le altre API esposte da Google, con un’attenzione evidente a due pubblici diversi ma sempre più vicini: sviluppatori che vogliono automatizzare operazioni ripetitive e agenti AI che hanno bisogno di comandi prevedibili, output strutturato e superfici operative che possano essere descritte in maniera semplice.

In un intervento pubblico, Poehnelt – sviluppatore con quasi 7 anni di esperienza in Google – scrive: “due mesi fa sono stato licenziato da Google per aver creato Google Workspace CLI. È diventato virale, ha guadagnato migliaia di stelle su GitHub e decine di migliaia di utenti reali in appena un paio di giorni“. Eppure la società guidata da Sundar Pichai ha preferito mettere alla porta il programmatore.

Google Workspace CLI: uno strumento che funziona!

Il successo di Google Workspace CLI è meritato: l’applicazione funziona infatti davvero molto bene e consente di gestire tutti i servizi da terminale senza alcuno sforzo.

Molte CLI cloud funzionano con comandi definiti nel codice sorgente: il maintainer aggiunge un servizio, scrive il parser, documenta opzioni e argomenti, gestisce i casi limite e pubblica una nuova versione. Google Workspace CLI sceglie una strada diversa: la documentazione descrive una strategia in due fasi. il programma legge il primo argomento per identificare il servizio, scarica il relativo Discovery Document, lo conserva in cache per 24 ore, costruisce un albero di comandi e poi riesegue il parsing degli argomenti rimanenti.

Dal punto di vista architetturale, la scelta ha un pregio evidente: riduce il ritardo tra evoluzione delle API e disponibilità da terminale. Se un metodo compare nel documento Discovery, la CLI può esporlo come comando immediatamente utilizzabile.

Google Workspace CLI non elimina la complessità delle API Google: la sposta in un livello più gestibile. Un comando come gws drive files list semplifica buona parte del lavoro ma l’utente deve comunque conoscere i parametri di base.

Il caso del licenziamento

Il punto più delicato della vicenda resta il licenziamento di Poehnelt, avvenuto, secondo il suo racconto pubblico, circa 2 mesi dopo la creazione e la diffusione virale della Google Workspace CLI.

È un passaggio che va trattato con prudenza, perché dall’esterno non è possibile conoscere tutti gli elementi che hanno portato alla decisione aziendale: policy, comunicazioni, autorizzazioni, valutazioni legali e dinamiche organizzative non sono pubblicamente ricostruibili in modo completo.

Tuttavia, proprio questa opacità rende il caso significativo. Poehnelt sostiene che lo strumento abbia generato interesse, entusiasmo e preoccupazione dentro Google, fino ad arrivare a domande da parte dei team legali sull’uso del logo, dei colori e dell’identità visiva associata a Google Workspace.

Secondo lo sviluppatore, il problema non sarebbe stato soltanto la CLI in sé, ma ciò che rappresenta: la possibilità che agenti AI e strumenti esterni potessero ridisegnare il modo in cui gli utenti interagiscono con Workspace, spostando parte del controllo dall’interfaccia ufficiale a un livello operativo più aperto, automatizzabile e vicino agli sviluppatori.

Il fatto che la CLI sia rimasta pubblicata nell’organizzazione GitHub googleworkspace, sotto il controllo di Steve Bazyl, responsabile di Google Workspace Developer Relations, pur con la precisazione di non essere un prodotto Google ufficialmente supportato, accentua ulteriormente l’ambiguità del caso.

Cosa potrebbe essere successo

La ricostruzione più plausibile è che la Google Workspace CLI abbia superato molto rapidamente la soglia dell’esperimento tecnico, diventando un oggetto difficile da classificare in quel di Mountain View. Finché uno strumento resta un prototipo interno, un progetto personale o un esempio per sviluppatori, può essere tollerato come iniziativa di ricerca, supporto o community. Quando però diventa virale, accumula migliaia di stelle su GitHub e viene adottato da utenti reali in pochi giorni, cambia natura agli occhi dell’azienda.

Non è più soltanto codice: diventa comunicazione pubblica, aspettativa degli utenti, possibile estensione del prodotto e, soprattutto, rappresentazione del brand.

Il passaggio più paradossale è che, sempre secondo Poehnelt, Google avrebbe annunciato a Google Cloud Next l’arrivo di una propria CLI per Workspace appena 2 giorni prima del suo licenziamento.

Se la cronologia dei fatti fosse corretta, il caso assume un significato ancora più ambiguo: l’idea di una CLI per Workspace non era necessariamente considerata sbagliata, marginale o inutile; al contrario, poteva essere abbastanza importante da entrare nella strategia ufficiale. Il conflitto, quindi, potrebbe non aver riguardato il valore tecnico dello strumento, ma chi lo controllava, com’era presentato, quale rapporto aveva con il brand e quanto fosse compatibile con le dinamiche interne di approvazione.

Il ruolo di un membro del team Developer Relations

L’ex dipendente Google osserva che un membro del team Developer Relations (DevRel) non è solo una figura di marketing tecnico e non è nemmeno un semplice sviluppatore interno. Sta a metà tra prodotto, ingegneria e comunità degli sviluppatori. Il suo compito è capire dove gli utenti incontrano difficoltà reali e creare esempi, prototipi, demo, librerie o strumenti open source per ridurre questi attriti.

Se un DevRel crea una CLI per Workspace, l’azione può essere letta in due modi opposti: da una parte come attività coerente con il suo lavoro, perché aiuta gli sviluppatori e risolve un problema concreto; dall’altra come iniziativa problematica, perché può sembrare troppo vicina a un prodotto ufficiale.