Quando Olivetti dominava il mondo UNIX: la mia incredibile avventura nello Steering Committee

Nel 1980, quasi tutti i sistemi informatici del mondo erano proprietari. Anche l’Olivetti in quel periodo si stava concentrando sullo sviluppo del proprio sistema operativo MOS, rilasciato ufficialmente nel 1984.

Nel 1983, però, successe una cosa molto importante nel mondo dell’informatica, con conseguenze che nessuno allora avrebbe immaginato.

Fino a quel momento, per via del loro statuto, i Bell Labs di AT&T, proprietari del sistema operativo UNIX, non potevano commercializzarlo e quindi lo avevano offerto liberamente alle università e per uso in ambiente scientifico.

Alcune università, in particolare Berkeley a San Francisco, apportarono notevoli miglioramenti allo UNIX originale, e le versioni di UNIX con le “estensioni di Berkeley” divennero ampiamente accettate. Col tempo ne erano derivate moltissime varianti, e AT&T decise di fonderne molte in una unica versione: “UNIX System V”. Non tutte le aziende però adottarono questa versione.

Nel 1983, i Bell Labs ebbero il permesso di farne un prodotto commerciale e AT&T creò una società apposita per gestire l’evoluzione di System V, fondando gli “UNIX System Laboratories” (USL).

Nel frattempo, in Europa, per indirizzare il problema della compatibilità applicativa tra le diverse varianti UNIX, nel 1984 fu formato il gruppo X/Open. Olivetti era uno dei membri fondatori, e io ero il Technical Manager X/Open per Olivetti. Nel 1985 la Portability Guide di X/Open segnò un passo importante, perché stabilì delle regole per consentire l’interscambio di applicazioni tra sistemi di fornitori concorrenti.

Tutti questi fattori segnarono di fatto l’inizio del movimento degli “Open Systems”, i cosidetti “sistemi aperti”, e la successiva adozione globale di UNIX come sistema aperto sarebbe diventata un fattore determinante nella scomparsa dei sistemi proprietari come il MOS e, a mio parere, rappresentò probabilmente l’elemento più significativo nel declino di Olivetti come grande fornitore di computer.

Oggi, 40 anni dopo, quasi tutti i server Internet nel mondo si basano su derivazioni di UNIX System V, ma il percorso per arrivarci è stato accidentato e costellato di problemi.

Le Guerre dello UNIX

Nel 1988, nel mondo UNIX scoppiò il caos, portando alle cosidette “Guerre dello UNIX”, nelle quali Olivetti ebbe un ruolo fondamentale. Per me fu l’inizio di tre anni incredibili e indimenticabili.

Tutto iniziò tranquillamente, ma nel 1988 USL stipulò un accordo sfortunato con Sun Microsystems. Questo trattamento preferenziale per Sun provocò una profonda frattura nella comunità UNIX, con AT&T che non venne più vista come il creatore e proprietario benevolo di UNIX.

Grandi aziende, che avevano sviluppato le proprie versioni di UNIX, decisero allora di unirsi per contrapporsi ad AT&T. Tra queste c’erano rivali come IBM, DEC e HP. Insieme nel 1988 diedero origine alla “Open Software Foundation” (OSF), promettendo di realizzare un proprio UNIX, secondo standard pubblicati da loro stessi.

L’iniziativa, nonostante la grande risonanza mediatica, non ebbe successo, soprattutto perché anche i sostenitori di UNIX System V decisero di formare un proprio consorzio, la “UNIX International” (UI), con la missione di riportare ordine e chiarezza nelle specifiche di UNIX System V. Si trattava di un consorzio mondiale, con membri principali (AT&T, Sun, NCR, Unisys, Prime, Motorola, Amdahl, Control Data, Fujitsu, Fuji, Oki, NEC, Toshiba, ICL e Olivetti) e membri generali (più di 100, tra cui Alcatel, Stratus, Ericsson, Wang, Locus e Unisoft).

Il quadro era quindi definito: due fazioni contrapposte nel mondo UNIX. Come mi ritrovai coinvolto?

La mia esperienza di Technical Manager in X/Open, in cui ero stato uno dei firmatari della prima X/Open Portability Guide del 1985, mi rese candidato ideale per assistere Franco Agostinucci, in quel momento alle prese proprio con la creazione di UNIX International.

Ero affiancato a Massimo Rusconi, che lavorava per Franco, per scrivere lo statuto del Consorzio, definire i ruoli del Comitato Esecutivo e del Comitato Direttivo (Steering Committee). In sostanza, dovevamo inventare da zero tutte le prassi operative di UI.

Presto ci rendemmo conto che le riunioni mancavano di organizzazione e logica e non approdavano a nessun risultato concreto. Qualcuno doveva prendere il controllo, così lo facemmo noi due.

Diventammo così i presidenti de facto di due gruppi spontanei: uno dedicato al Comitato Esecutivo, in pratica il Consiglio di Amministrazione, guidato da Massimo; l’altro era il Comitato Direttivo, lo Steering Committee, incaricato di discutere con AT&T e di fornire input dettagliati a USL per il futuro di System V. Scrissi la maggior parte dello statuto dello Steering Committee, e non fu una sorpresa per nessuno degli addetti alla creazione di UI che io venissi poi eletto all’unanimità come primo Chairman dello Steering Committee a livello mondiale.

La sorpresa fu a Ivrea, dove nessuno aveva immaginato che Olivetti potesse conquistare una tale leadership e, in effetti, la decisione era stata presa autonomamente, da Massimo e da me, senza alcun mandato della sede centrale. Una volta che fui nominato Presidente, però, per Olivetti fu un enorme successo di immagine. 

L’arte del Consenso, ma era davvero così?

Mi dedicai quindi al mio lavoro part-time come worldwide Chairman of the Steering Committee di UI. Dico “part-time” perché rimasi ufficialmente ancora dipendente Marketing per un anno, e solo dopo Franco Agostinucci riuscì a farmi trasferire nel suo gruppo di Pianificazione Strategica, alle dipendenze di Massimo Rusconi.

Ad ogni modo, quanti rappresentanti di altrettante aziende c’erano e che aspettative avevano dallo Steering Committee di UI? I 15 membri principali, che contribuivano con $500.000 l’anno al Consorzio, si aspettavano di essere determinanti nelle decisioni riguardanti UNIX System V. I 100 membri generali, in ritorno dai loro $10.000 l’anno di contributi al consorzio, si aspettavano di essere “almeno” informati su cosa stava succedendo e magari anche di contribuire in qualche modo. Tipicamente, ciascun incontro dello Steering Committee riuniva almeno 50-60 persone: 15 Membri Principali e 35-45 Membri Generali.

Come gestire 50 persone per arrivare a delle conclusioni concordate? Solo con trucchi subdoli e azioni poco ortodosse, ovviamente! Il consenso era cruciale, non potevo permettere votazioni a meno che non sapessi già in anticipo quale sarebbe stato il risultato! Voti con esiti del tipo 60%-40% non erano assolutamente accettabili. Un simile esito avrebbe significato che qualcuno di quel 40% avrebbe riproposto la questione già alla riunione successiva. No, l’unico modo per andare avanti era ottenere decisioni con un consenso tra il 90% e il 100%, o almeno creare la percezione che fosse così, in modo da archiviare definitivamente ogni questione.

Per la cronaca, ci fu uno studente dell’Università di Chicago, che scrisse la sua tesi proprio sul meccanismo di consenso che avevo inventato per lo Steering Committee di UI!

Il Paradosso di Abilene

Alla prima riunione raccontai al Comitato una storia, ispirata vagamente a un articolo recente (1988) che avevo trovato dell’Università di Washington intitolato “Il Paradosso di Abilene: la gestione dell’accordo”. La storia è sostanzialmente questa (raccontata dal punto di vista dell’autore dell’articolo):

Era un pomeriggio molto caldo a Coleman, Texas (popolazione 5607), 40 gradi centigradi, circa 104 Fahrenheit. Mia moglie ed io stavamo visitando i miei suoceri, seduti fuori sul portico. C’era un ventilatore e della limonata fresca, quindi, purché non ci si muovesse troppo, il pomeriggio era sopportabile.

A un certo punto mio suocero disse: “perché non prendiamo la macchina e andiamo ad Abilene a prenderci un gelato?”. Io pensai (ma non lo dissi): “Cosa? Andare ad Abilene? Ottanta chilometri? Con questa tempesta di polvere e questo caldo? E in una vecchia Buick senza aria condizionata?”. Ma mia moglie intervenne dicendo: “Sembra un’ottima idea. Mi piacerebbe andarci. E tu?”. Così, per non contraddire gli altri, dissi anch’io: “Per me va bene. Spero solo che tua madre voglia venire”. “Certo che voglio venire”, disse mia suocera. “Non vado ad Abilene da tanto tempo”.

Così tutti salimmo in macchina e fu peggio di quanto avessi immaginato. Il caldo era insopportabile, eravamo coperti di polvere quando arrivammo, sudati e irritabili. La gelateria era chiusa…

Circa quattro ore e più di 160 chilometri dopo, eravamo di nuovo a casa, accaldati ed esausti. Seduti di nuovo sul portico, in silenzio. Allora dissi, per rompere il ghiaccio: “Beh, è stato bello uscire un po’, no?”. Nessuno rispose. Finalmente parlò mia suocera: “A dire la verità, non volevo affatto andare, sarei rimasta volentieri qui. Sono venuta solo perché sembravate tutti così entusiasti. Non ci sarei mai andata se non mi aveste spinta voi”.

Non riuscivo a crederci. “Cosa intendi con ‘voi’? Non mettermi nel gruppo dei ‘voi’. Io ero felice di restare qui. Non volevo affatto andare. Ci sono andato solo per non deludere gli altri”. Mia moglie sembrava scioccata. “Non dare la colpa a me. Tu, papà e mamma eravate quelli che volevano andare. Io ci sono andata solo per fare compagnia e farvi contenti. È stata una pazzia uscire con questo caldo”.

Mio suocero intervenne: “Senti, io non volevo davvero andare ad Abilene. Ho solo pensato che magari vi stavate annoiando, per questo l’ho proposto”.

Dopo questo sfogo di recriminazioni, rimanemmo tutti in silenzio. Eccoci lì, quattro persone ragionevolmente sensate che, di propria volontà, avevano appena fatto un viaggio di 160 chilometri attraverso un deserto desolato a una temperatura infernale sotto una tempesta di sabbia per mangiare un gelato inesistente ad Abilene, quando in realtà nessuno di noi voleva davvero andarci. Anzi, a ben vedere, avevamo fatto esattamente l’opposto di ciò che volevamo fare. La situazione non aveva alcun senso.

Questo è ciò che l’autore dell’articolo chiamò “Il Paradosso di Abilene”.

Espresso semplicemente, dice questo: “Le organizzazioni spesso compiono azioni in contraddizione con ciò che realmente desiderano fare e quindi vanificano gli scopi stessi che cercano di raggiungere”.

Una conseguenza importante di questo paradosso è che “l’incapacità di gestire l’accordo è una delle principali fonti di disfunzione organizzativa”.

Così iniziai la mia esperienza come Chairman dello Steering Committee, promettendo in sostanza che non saremmo mai finiti sulla strada per Abilene. Ogni volta che sentivo un’idea che consideravo insostenibile, chiedevo che qualcuno la contestasse, e non permettevo che si prendessero decisioni per inerzia o per paura di offendere qualcuno. Commentavo spesso le proposte dicendo: “Mi sembra la strada per Abilene. Siete proprio sicuri di volerci andare?”.

Chi ha diritto di voto?

Lo statuto che avevo scritto io stesso stabiliva chiaramente che solo i Membri Principali potevano votare sulle raccomandazioni dello Steering Committee. Quello che poi feci, di fatto, fu ignorare questa direttiva. Tutto ruotava attorno alla costruzione del consenso, quindi di tanto in tanto, durante le discussioni, chiedevo a tutti i presenti di alzare la mano per avere un’idea dell’umore generale del comitato. Se il risultato era unanime, allora facevo votare rapidamente i Membri Principali per ufficializzare la decisione. Se non lo era, avevo a disposizione diversi trucchi per avvicinarmi al consenso.

Il Comitato del Ristorante

Quando identificavo fazioni in conflitto all’interno del Comitato, selezionavo alcuni membri chiave e li invitavo a partecipare a una discussione privata serale, a cena, per confrontarsi sulle loro divergenze. A loro veniva poi chiesto di riferire al comitato plenaria il giorno seguente. Non mi sono mai invitato a nessuno di questi “Comitati del Ristorante” (Restaurant Committee), come vennero presto soprannominati. Lasciavo che si scontrassero fra loro. Il risultato incredibilmente sorprendente fu che, nei tre anni in cui ho presieduto il gruppo, nessun Comitato del Ristorante ha mai fallito nel risolvere le proprie divergenze. Così, dopo la loro presentazione alla plenaria, un’altra veloce alzata di mano indicava quasi sempre un consenso vicino al 100%, un rapido voto da parte dei Membri Principali e voilà, consenso raggiunto.

I Sotto-gruppi

Un altro modo per ottenere (o perlomeno per sembrare di ottenere) il consenso era suddividere il comitato completo in gruppi più piccoli, ciascuno di 7-9 membri. Anche in questo caso decidevo io attentamente chi inserire in ciascun sotto-gruppo, cercando di bilanciare le fazioni pro e contro, in modo da favorire un risultato utile. Assegnavo poi a ciascun sotto-gruppo lo stesso compito da risolvere, in stanze separate così da non poter sentire cosa stava succedendo negli altri gruppi. Alla fine, ogni sotto-gruppo doveva consegnarmi un riassunto scritto delle proprie decisioni prima di riferire verbalmente alla plenaria.

Il risultato era di solito che tutti i sotto-gruppi prendevano la stessa decisione, magari alcuni con un margine di 60%-40%, altri con 70%-30%, e così via. Tuttavia, potevo affermare con correttezza che tutti i 6 o 7 gruppi avevano preso la stessa decisione, quindi avevamo un consenso al 100%. Non importava che fosse un’illusione e che magari il 30% dei presenti non fosse d’accordo. Tutte le aziende coinvolte potevano tornare ai loro dirigenti dicendo: guardate, ci ho provato, ma tutti gli altri erano contrari, c’era un consenso del 100% o del 90%. Questo era fondamentale per evitare che qualcuno volesse riaprire le discussioni.

Riflessioni sul processo decisionale

L’unico modo per raggiungere il consenso è gestire attentamente il processo. Nell’organizzare l’agenda delle riunioni, passavo letteralmente settimane a parlare al telefono con i partecipanti tra un incontro e l’altro, per capire cosa volessero e per includere solo i punti all’ordine del giorno su cui sapevo che si poteva trovare un accordo. Lavoravo molto a stretto contatto con AT&T in questo, dopotutto loro erano i proprietari di UNIX System V e sapevano cosa potevano o non potevano implementare. In molti casi scrivevo le conclusioni degli incontri prima ancora che avessero luogo (!) Mai fare una domanda di cui non si conosce già la risposta!

Questo non significa che manipolassi tutto a nostro favore, questi incontri dello Steering Committee erano davvero utili per capire di quali miglioramenti al System V le persone avessero bisogno. In realtà, il gruppo dei Membri Generali era, se possibile, ancora più importante dei Membri Principali. Le aziende più piccole erano di solito più innovative rispetto a quelle grandi, ed erano disposte a pagare molto per essere membri, oltre ai costi di viaggio per partecipare agli incontri. Per loro era importante sentirsi coinvolti. Ecco perché lasciavo che tutti votassero su tutto, fino al momento in cui bisognava registrare una decisione formale.

Le riunioni dello Steering Committee erano molto popolari, continuavano ad arrivare nuove persone, e anche con 60-70 partecipanti, il Comitato del Ristorante, i Sotto-gruppi e l’evitare la strada per Abilene garantivano che fosse uno dei comitati più efficaci mai costituiti.

Ero anche particolarmente apprezzato dalle aziende giapponesi. In un comitato internazionale ci sono sostanzialmente tre tipi di partecipanti, che posso approssimativamente classificare come “gli Americani”, “gli Europei” e “i Giapponesi”. A causa delle diverse culture e lingue, se non si tenevano sotto controllo, “gli Americani” tendevano a dominare qualsiasi discussione, interrompendo immediatamente se non erano d’accordo su qualcosa. “Gli Europei” di solito dicevano qualcosa come “scusatemi, posso aggiungere un pensiero?”, ma non interrompevano e parlavano solo quando l’interlocutore aveva finito. “I Giapponesi” prendevano in considerazione di parlare solo in presenza di un lungo e silenzioso momento di pausa.

Dovevo quindi gestire con fermezza gli Americani, incoraggiare gli Europei e invitare ufficialmente i Giapponesi a esprimere il loro parere, impedendo a qualsiasi Americano di interrompere. Ci voleva una mano ferma, ma alla fine funzionava tutto molto bene, e i Giapponesi mi sostenevano con entusiasmo.

Era interessante notare che nel mio Steering Committee c’erano alcune figure molto famose nel mondo UNIX. C’era Jerry Popek di Locus, originariamente professore alla UCLA di Los Angeles, con cui avevo lavorato dieci anni prima alla definizione di MOS. Poi c’era il leggendario Bill Joy, co-fondatore di Sun Microsystems, definito da Fortune magazine come “l’Edison di Internet”. Ebbe un ruolo fondamentale nello sviluppo iniziale di BSD UNIX quando era ancora uno studente a Berkeley, ed è l’autore originale del text editor “vi”, che personalmente uso ancora oggi, quasi 50 anni dopo. Era un programmatore formidabile, capace di produrre rapidamente codice di qualità che funzionava al primo colpo. Quando parlava Bill, nella stanza calava sempre un silenzio reverenziale: “Sta parlando Dio!” La vera difficoltà era convincere Bill che a volte UI non poteva proprio supportare alcune delle sue proposte più stravaganti.

Nel giugno del 1991, dopo tre anni alla Presidenza, decisi di lasciare il ruolo, anche se continuai a partecipare agli incontri dello Steering Committee come rappresentante Olivetti.

Per finire

Si dice che con un comitato non si riesca mai a prendere decisioni. In effetti, nelle piccole organizzazioni si dice che il Consiglio di Amministrazione dovrebbe sempre avere un numero dispari di membri, e che 3 siano già troppi. Il mio Steering Committee di UNIX International fu decisamente un’eccezione a questa regola.

Davamo raccomandazioni coerenti e dettagliate che USL doveva implementare nelle future versioni di UNIX System V. Ogni riunione di UI iniziava con Jean Baccash, il rappresentante di USL nel mio comitato, che presentava un grafico aggiornato su quando e dove le funzionalità sarebbero state incluse. Jean e io avevamo un eccellente rapporto e diventammo buoni amici. UI costituiva sotto-gruppi per approfondire argomenti specifici. Fu un periodo affascinante!

Durante la mia presidenza, 1989-1992, Olivetti era dunque percepita come un vero protagonista nel panorama UNIX mondiale. Dopo tutto, presiedevamo il gruppo più importante riguardante il futuro dello UNIX, e quindi avevamo un vantaggio intrinseco rispetto ad altre aziende. Sapevamo in anticipo cosa sarebbe successo, e potevamo persino influenzare le decisioni. Almeno, questa era la teoria.

Dopo ogni riunione, inviavo una lettera dettagliata a tutte le persone di Olivetti coinvolte nei nostri sviluppi UNIX. Se questo veniva apprezzato o meno, è un altro discorso. Non ricordo di aver ricevuto un vero feedback positivo o indicazioni sulla direzione da prendere alla riunione successiva. A volte potevano persino arrivare proteste sulla direzione che stava prendendo UNIX System V.

Forse quindi Olivetti contribuì al proprio declino. Eravamo leader mondiali con i nostri sistemi proprietari, ma quando il mondo si orientò verso gli Open Systems, forse non fu dedicata abbastanza attenzione a gestire efficacemente questo passaggio. UNIX International era visto da alcuni in Olivetti come “l’ennesimo ente di standardizzazione”, qualcosa da tollerare ma non davvero utile. In realtà non era affatto un ente di standardizzazione, poiché di fatto specificava le funzionalità di un prodotto vero. Non credo che questo fosse stato sufficientemente compreso all’epoca.

Il problema con gli Open Systems fu che, offrendo tutti le stesse funzionalità, la competizione si spostò sul prezzo e sui servizi complessivi. Sapere in anticipo quali funzionalità sarebbero state incluse in UNIX System V probabilmente non sarebbe bastato e ottenere la conformità a X/Open era necessario ma non sufficiente.

Nessuna società di successo oggi ha un diritto intrinseco a esserlo anche domani: nemmeno la Olivetti lo ebbe.

Forse, quando MOS fu rilasciato nel 1984, proprio mentre uscivano sul mercato i primi sistemi UNIX commerciali, Olivetti avrebbe potuto continuare a offrire il MOS alle banche per ancora molti anni, lavorando in parallelo ad applicazioni UNIX, invece di spostarsi verso un’offerta UNIX “nuda”.

Forse, quando la Olivetti guidava gli sviluppi di UNIX System V nel mondo, avrebbe potuto sfruttare questo vantaggio competitivo.

Forse, ma non andò cosi’.

Qui, altre storie da "Olivetti delle meraviglie". Clicca