Una vicenda che mescola codice open source, viralità improvvisa e licenziamento ha al centro Google Workspace CLI, lo strumento creato da Justin Poehnelt per gestire i servizi di Google direttamente dal terminale. Qualche mese fa questo sviluppatore, all’epoca ancora dentro l’azienda di Mountain View, aveva messo a punto un programma capace di interagire con Workspace senza dover scrivere ogni volta chiamate REST, gestire OAuth, paginazione, payload JSON e controlli sugli errori. Una sola interfaccia per Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin SDK e le altre API esposte da Google. Pensata per due tipi di utenti che ormai si assomigliano sempre di più: gli sviluppatori che vogliono automatizzare le operazioni noiose e gli agenti AI, che hanno bisogno di comandi prevedibili e di output ordinato.
In un intervento pubblico, Poehnelt, che a Google aveva lavorato per quasi 7 anni, racconta la sua versione senza troppi giri di parole: due mesi fa è stato licenziato proprio per aver creato Google Workspace CLI. Lo strumento era diventato virale, aveva raccolto migliaia di stelle su GitHub e decine di migliaia di utenti reali nel giro di un paio di giorni. Eppure l’azienda guidata da Sundar Pichai ha scelto di mettere alla porta il programmatore.
Come funziona e perché ha conquistato così tanti utenti
Il successo è meritato perché l’applicazione funziona davvero bene e permette di gestire tutti i servizi da terminale senza grandi sforzi. La maggior parte delle CLI cloud ragiona con comandi scritti direttamente nel codice sorgente: il maintainer aggiunge un servizio, scrive il parser, documenta opzioni e argomenti, sistema i casi limite e pubblica una nuova versione. Qui la strada è diversa. Il programma legge il primo argomento per capire di quale servizio si tratta, scarica il relativo Discovery Document, lo tiene in cache per 24 ore, costruisce un albero di comandi e poi rifà il parsing degli argomenti rimasti.
Il vantaggio è chiaro: il ritardo tra l’evoluzione delle API e la loro disponibilità da terminale si riduce parecchio. Se un metodo compare nel documento Discovery, la CLI può esporlo subito come comando utilizzabile. Detto questo, lo strumento non cancella la complessità delle API Google, la sposta soltanto su un livello più gestibile. Un comando come gws drive files list semplifica buona parte del lavoro, ma chi lo usa deve comunque conoscere i parametri di base.
Il nodo del licenziamento e una tempistica che fa discutere
Il punto più spinoso è proprio il licenziamento, arrivato secondo il racconto dello sviluppatore circa 2 mesi dopo la nascita e la diffusione virale dello strumento. Va presa con le pinze, questa storia, perché dall’esterno è impossibile conoscere tutti gli elementi che hanno portato alla decisione: policy interne, autorizzazioni, valutazioni legali e dinamiche organizzative non sono ricostruibili per intero.
Proprio questa opacità rende il caso interessante. Poehnelt sostiene che la sua creazione abbia generato interesse, entusiasmo ma anche preoccupazione dentro Google, fino alle domande dei team legali sull’uso del logo, dei colori e dell’identità visiva legata a Workspace. A suo dire il problema non era tanto la CLI in sé, quanto ciò che rappresentava: la possibilità che agenti AI e strumenti esterni potessero ridisegnare il modo in cui gli utenti interagiscono con il prodotto, spostando parte del controllo dall’interfaccia ufficiale verso un livello più aperto e automatizzabile.
l’idea di una CLI per Workspace non era affatto considerata sbagliata o inutile
C’è poi un dettaglio che aumenta l’ambiguità. Lo strumento è rimasto pubblicato 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 ufficialmente supportato. E sempre stando a Poehnelt, a Google Cloud Next l’azienda avrebbe annunciato l’arrivo di una propria CLI per Workspace appena 2 giorni prima del suo licenziamento.
Se la cronologia fosse esatta, il quadro si fa ancora più curioso: l’idea di una CLI per Workspace non era affatto considerata sbagliata o inutile, anzi, poteva entrare nella strategia ufficiale. Il conflitto, allora, forse non riguardava il valore tecnico, ma chi controllava lo strumento e quanto fosse compatibile con i processi interni di approvazione. Lo stesso Poehnelt fa notare che un membro del team Developer Relations non è un puro tecnico né un semplice marketer: sta a metà tra prodotto, ingegneria e comunità. Il suo lavoro è capire dove gli utenti incontrano ostacoli reali e creare demo, prototipi, librerie o strumenti open source per ridurli. Da questo punto di vista una CLI può essere letta in due modi opposti, come attività perfettamente in linea col ruolo oppure come iniziativa scomoda, troppo vicina a un prodotto ufficiale.