Jobs ed i garage
In questi giorni si è molto parlato della carriera di Steve Jobs, come modello di imprenditore ed innovatore. Senza nulla togliere al carisma della persona ed alla capacità di marketing della sua azienda, molte riflessioni hanno analizzato gli inizi della sua attività, basata su quel modello dei “garage boys” che tanti frutti ha dato nella Silicon Valley degli anni ’70-’80.
A questo proposito ho trovato molto interessante l’allegoria di Stefano Lavori, che descrive cosa sarebbe successo a Jobs se fosse nato a Napoli (ma il tutto è generalizzabile all’Italia intera). Molto divertente e stimolante il pezzo, ma ancora più interessanti sono i commenti, scritti evidentemente da una parte giovane della popolazione, che grossomodo si dividono tra il “bisogna emigrare” ed il “bisogna resistere ad ogni costo”. Triste la pressoché mancanza di commenti del tipo “bisogna cambiare le regole, ed innovare a casa nostra”, indice di scarsissima fiducia nel sistema imprenditoriale ed in quello politico-amministrativo.
Ritchie ed i Bell Labs
Esiste (o esisteva?) anche un altro modello di innovazione, esemplificato da un altro personaggio cardine della storia dell’informatica, anch’egli deceduto in questi giorni (il 12/10/2011), seppur con molto meno clamore: Dennis Ritchie, di una generazione precedente a Jobs. Ritchie, insieme a Brian Kernighan e Ken Thompson faceva parte di un piccolo gruppo di persone, presso i laboratori di ricerca “Bell Labs” del colosso americano AT&T (l’equivalente della nostra Telecom, su scala americana). A differenza degli Steve Jobs e dei Bill Gates, questi personaggi erano ricercatori che avevano un lavoro alle dipendenze di una multinazionale. Ma una multinazionale che sapeva ancora cosa vuol dire fare ricerca.
Il modello di ricerca dei Bell Labs era molto semplice: le persone più brave a fare ricerca venivano lasciate libere di farla. Potevano scegliersi gli argomenti su cui lavorare. Avevano a disposizione le risorse (umane e tecnologiche) per farlo. L’ipotesi di partenza era lapalissiana: se prendo delle persone in gamba e le lascio esprimere, senza troppi vincoli, lacciuoli e laccetti, certamente qualcosa di buono salterà fuori. Ed in ogni caso il costo di un centinaio di persone è praticamente impercettibile in una grande impresa.
E così nel 1969 i nostri Thomspson, Kernighan e Ritchie, stufi di utilizzare un sistema operativo troppo complesso e farraginoso, decisero di provare a scriverne uno più semplice, che soddisfacesse i loro personali requisiti operativi ed estetici. Ottennero facilmente il permesso di utilizzare un vecchio PDP-7 inutilizzato, ed iniziarono a “giocarci”.
Fu così che partorirono la prima versione di Unix. Per gioco. E poiché erano stufi di programmare in assembler, anche perché avrebbe reso impossibile migrare Unix su hardware diversi, decisero (eresia, a quei tempi!) che avrebbero scritto il sistema operativo in un linguaggio di alto livello. Visto che i linguaggi disponibili all’epoca non erano adatti allo scopo, inventarono il linguaggio C. Sempre per gioco.
Un gioco che ebbe influenza su tutta l’informatica moderna.
Oggi, a circa 40 anni di distanza, ogni volta che accendiamo uno smartphone (sia esso un iPhone o un Android), al suo interno parte un sistema operativo derivato da Unix (da una sua versione commerciale od open source, poco importa). Ogni volta che in un indirizzo web scriviamo il carattere slash ‘/’ per indicare una directory, questo discende dalle scelte fatte nella creazione di Unix.
Ogni volta che un programmatore digita ‘{‘, o per andare a capo usa ‘\n’, o pensa al tipo di dato int, riprende il lavoro fatto ai Bell Labs 4 decenni fa. Anche se, oggi, non si programma solo in C ma prevalentemente in C++, C#, Java, JavaScript, php, ActionScript (Flash), … e decine di altri linguaggi minori, che affondano tutti le radici nel C.
Ogni volta che usiamo Internet, lo facciamo grazie al lavoro di altri ricercatori che nel decennio successivo poterono “giocare” con Unix, ed aggiungerne in modo sperimentale le funzionalità di rete, inventando il protocollo TCP/IP. Ciò fu possibile solo su Unix, visto che il sistema operativo era piccolo, leggero, portatile e soprattutto disponibile gratuitamente (no, non open source, il concetto non esisteva ancora) per le università e gli enti di ricerca.
La lezione non appresa
I modelli sopra descritti, che fanno parte della storia, sembrano non avere lasciato traccia nelle organizzazioni oggi deputate a stimolare la ricerca e l’innovazione, siano essi gli enti di ricerca, gli incubatori di impresa, i finanziatori pubblici.
Sia lavorando nel piccolo (non si chiama più garage, ma start'-up), che nel grande (non ci sono i Bell Labs, ma centri e dipartimenti), si riscontra una deriva dell’attenzione dalla bontà dell’idea alla strutturazione del processo.
Mi spiego: oggi, se hai una buona idea nel campo ICT, puoi far leva su Internet, su tool e librerie open source, su ambienti di sviluppo rapido, su emulatori, su app-store, su mashup e servizi web 2.0, … In pochi mesi puoi realizzare un primo prototipo e metterlo alla prova sul mercato: se funziona, potrà decollare, altrimenti non avrai perso troppo tempo né denaro.
Ma non chiedere aiuto a nessuno. Altrimenti dovrai cominciare a fare un budget, un business plan, un’analisi di mercato, una proposta di progetto, un piano di marketing, una ricerca brevettuale ed analisi dei competitor, una previsione di cash flow, un strutturazione in work package, gant, pertt, ecc. ecc.
Mi è successo più volte di incontrare dei giovani i quali, anziché lavorare per 3 mesi e realizzare la loro idea, lavorano invece per 6 mesi sul business plan (in assenza di una reale competenza per realizzarlo bene, e di dati affidabili da utilizzare).
Dopo 6 mesi, se l’idea era buona, qualcun altro l’avrà realizzata. Se non era buona, non lo saprai ancora, perché non avrai avuto modo di provarla, ed allora perderai ulteriore tempo ad implementare una schifezza, magari essendoti indebitato.
Mi sto convincendo che un modello più efficace di sostegno all’innovazione debba essere “lean and light”, snello e leggero. Mi racconti la tua idea in 2-3 ore. Se mi piace e mi convinci, ti finanzio 2-3 mesi di lavoro, 5.000 euro a fondo perduto. Se non mi convinci, amici come prima. Overhead amministrativo: zero. Rischio nell’investimento: basso. Ovviamente occorre investire in tecnici in grado di valutare bene le idee, impegnarsi ad evitare ogni buonismo (dicendo a tutti che l’idea sembra buona), evitare ogni sovrastruttura organizzativa che rallenti lo sviluppo di una prima “beta” lanciata sul mercato.
Insomma, lassez-faire !
Solo dopo, se vi sarà una prima risposta dal mercato, sarà ovviamente necessario re-impostare gli sviluppi futuri in una logica industriale-imprenditoriale. Solo dopo che se ne è appurata la potenzialità.
Mi sembra quasi troppo banale… in che cosa mi sbaglio?
Ieri hanno pubblicato un articolo dal titolo “With the Arduino, Now Even Your Mom Can Program”. In realtà questo era il titolo della news alert, mentre l’effettivo titolo dell’articolo era un più insipido “
Evidentemente questa immagine evoca un cliché di Mom più simile a Nonna Papera (che passa le giornate in casa a sfornare torte ed a gestire le marachelle dei nipotini), che non all’effettivo ruolo delle donne e madri contemporanee, che sono altrettanto capaci e tecnologicamente avanzate quanto i loro mariti o figli/e.
I'm an IEEE member, and a mom, and the headline was inexcusable, a lazy, sexist cliché that should have never seen the light of day. Today we are instituting an additional headline review process that will apply to all future Tech Alerts so that such insipid and offensive headlines never find their way into your in-box. 
È con questo spirito di amarcord informatico che dalla cantina ho rispolverato questo cimelio (edito nel 1982, quindi vicino ai 30 anni anch’esso): il libro che mi ha accompagnato nell’apprendimento del mio secondo linguaggio Assembler, quello del