Software e etica

Il software non solo quale artefatto tecnologico, oggetto di profitto per generare profitto, ma quale libero mezzo di espressione e comunicazione. Si tratta di una "presentazione" alla quale ho aggiunto un po' di commenti, per farne una sorta di testo illustrato.

Iniziamo con una suggestione. Il 16 luglio del 1969 con la missione Apollo 11 l'uomo mise piede sulla luna. Fu un'impresa clamorosa, se si considera quali fossero le tecnologie disponibili a quei tempi. Avevo 14 anni. Posso quindi testimoniare che la tecnologia di comunicazione più moderna di cui si poteva disporre era un grosso telefono nero in casa. Fuori si potevano usare i "telefoni a gettoni". Mi pare che fosse proprio in quell'anno che nel laboratorio di fisica del liceo scientifico, un rappresentante venne a mostrarci una calcolatrice elettronica tascabile. Era la prima di quella che sarebbe stata una fortunata serie prodotta dalla Hewlett Packard, tutt'ora esistente. Eravamo esterreffatti, mai vista una cosa del genere: faceva addirittura la radice quadrata! Insomma, così per dare l'idea del contesto.

Missione Apollo 11 - 16 luglio 1969

Queste immagini fecero una grande impressione, come è ovvio. Al di là del fatto di avere messo piede su qualcosa che per millenni aveva ispirato poeti e artisti di ogni genere, c'era l'effetto di una tecnologia sì umana, evidentemente,ma distante quanto la luna, rispetto alla vita quotidiana dell'uomo comune. Roba da scienziati, anche loro lontani quanto la luna, nell'immaginario comune.

Il primo allunaggio

Missione Apollo 20 - luglio 1969

Questa bella immagine sintetizza il viaggio fatto dagli astronauti. Dalla figura si capisce bene come tutta la questione stesse nel darsi la spinta giusta al momento giusto per mollare l'orbita terrestre in modo da farsi agganciare dall'orbita lunare, e viceversa al ritorno. Una sorta di vertiginoso tirassegno. Ma come appariva il bersaglio?

Il viaggio

Missioni Apollo - il viaggio

Per azzeccare l'ingresso in quel corridoio occorre la conoscenza delle leggi gravitazionali di Newton, e fin qui ci siamo, anzi, ci eravamo. Ma la conoscenza teorica nono sarebbe certo bastata perché questa si doveva poi tradurre in precisi valori numerici da utilizzare per governare i razzi che consentivano di uscire dalle orbite e di aggiustare le traiettorie. Calcoli numeri quindi, non banali e soprattutto da eseguire in modo pressocché istantaneo, non certo a mano quindi. Oggi pare banale ma allora non lo era affatto. I computer digitali esistevano ma erano "mostri" costosissimi che potevano permettersi solo grandi istituzioni, banche, università etc. Ed erano enormi, mentre le capsule spaziali erano piccolissime, poco più che cabine. Occorsero gli sforzi congiunti di vari scienziati dei laboratori più avanzati del mondo, fra cui quelli del Massachusetts Institute of Technology (MIT) per costruire l'Apollo Guidance Computer. Ebbene, confrontate le sue specifiche con quelledel mio telefono, già abbastanza vecchio, mentre scrivo questi appunti...

AGC: il computer che ha portato l'uomo sulla luna

Apollo Guidance Computer - 64 KB memoria, 43 KHz clock processore, 32 kg

Cellulare Galaxy III - 16 GB (x 25000) memoria, 1.4 GHz (x 32000) clock processore, 133 g (/ 240)

Insomma, lo smartphone che ho in tasca pesa 240 volte meno dell'AGC, è 32000 volte più veloce e la sua memoria è 25000 volte più grande! E lo possono comprare (quasi) tutti...

Cosa voglio dire con questo panegirico? Voglio mettere in evidenza come con poco si possa fare tanto e con molto si possa fare poco, considerato come la maggioranza dei nostri potenti device sono usati...

Riflettiamo un attimo su questa suggestione. In cinquant'anni la tecnologia ha conosciuto uno sviluppo esplosivo. Maneggiamo quotidianamente strumenti enormemente più potenti di quelli che ci hanno portato sulla luna, solo mezzo secolo fa. Il progresso raggiunto nella metà secolo precedente è minimo a confronto. Questa si chiama crescita esponenziale ma è una crescita difficile (impossibile?) da metabolizzare nello spazio di una generazione: una situazione inedita nell'evoluzione umana. E in effetti le possibilità sono straordinarie, ma allo stesso tempo, siamo come schiacciati da tale improvvisa abbondanza. Si può fare tutto ma al prezzo, forse, di non capire nulla. E in buona parte, impossibilitati ad andare a fondo in alcunché, non di rado intenti a perseguire le tante futili necessità generate dal potere spropositato delle tecnologie che abbiamo in mano. E intenti a rincorrere il prossimo meraviglioso strumento, software, metodo o moda. Non si tratta solo di mettersi in grado di "sostenere" una simile pressione tecnologica - ci si abitua a tutto - ma di fare in tempo a forgiare gli strumenti culturali per rimanere padroni del gioco, cioè di essere in grado di mettere efficacemente al nostro servizio i mezzi tecnologici per obiettivi significativi, capaci di valutare obiettivamente gli esiti e anche le implicazioni etiche delle nostre "azioni aumentate".

Simili considerazioni valgono a maggior ragione nel mondo del software e anche del software destinato a fini didattici. Gli strumenti e i metodi si avvicendano troppo veloci e il rischio è che non si faccia in tempo a comprenderne le possibilità, alla rincorsa delle magnificenze del prossimo arrivato. Un effetto questo che appare particolarmente evidente se ci si aggira nei vari gruppi tematici dei social network. Contesti questi dove fa impressione la virulenza delle diatribe fra questo o quello strumento, oppure fra apocalittici e integrati, virulenza non di rado acconmagnata dalla sostanziale ignoranza in materia, degli uni e degli altri.

Il proposito della suggestione che abbiamo esposto è come di frenare un attimo, per approfondire un po' meglio le basi, anzi per imparare a approfondire le basi, prima di procedere oltre. Un costume che si è perso molto. In poche parole, recuperare il senso e l'utilità di fare molto con poco prima di acquisire altro.

Dire no

Si può dire di no. Non nel senso banale della protesta scontata, del bastian contrario a parole, di cui oggi c'è gran dovizia nei social, per esempio. Intendo invece dire di no per davvero, con i fatti, con precise azioni concrete, di quelle che cambiano il proprio destino, e che, sempre, costano. Per un verso o per l'altro. C'è un filo conduttore nelle storie accennate qui di seguito, che è rappresentato dalla rinuncia a qualcosa, di solito a qualcosa di più sicuro in favore di qualcosa di molto meno sicuro ma più interessante. Se si chiede a una persona a caso quali siano i maggiori innovatori nell'ambito della tecnologia è molto probabile che emergano nomi come quelli di Bill Gates o Steve Jobs, o altri leader delle maggiori aziende di Information technology, che oggi vantano capitalizzazioni paragonabili al Prodotto Interno Lordo di Paesi di dimensione media. Insomma, a conti fatti domina il messaggio che il successo, ogni tipo di successo, si misuri sostanzialmente dal successo economico. Ecco, no. Certo, il successo economico ci può essere ed è anche molto facilmente visibile, così facilmente visibile da oscurare altri tipi di successo, meno appariscenti. Perché se poi si va a vedere bene, figure come Bill Gates o Steve Jobs, in termini tecnici o scientifici non è che abbiano fatto granché. In realtà hanno fatto gli imprenditori, e in questo sono stati magari anche geniali, ma anche molto spregiudicati. Hanno influenzato sicuramente l'innovazione, favorendo la diffusione di una tecnologia piuttosto che un'altra. Ma non sono gli artefici, i protagonisti, coloro che "hanno fatto i pezzi" delle innumerevoli tecnologie che noi usiamo, software o hardware che siano. Gli artefici primi sono altri, sono persone che hanno fatto altre scelte e che, in modi diversi, hanno pronunciato un no a facili guadagni o facili soddisfazioni, per il fascino di un ideale, per una questione di giustizia o anche solo per puro divertimento.

Software libero

Quello che segue è il primo capitolo, "Per volontà di una stampante", di Codice Libero di Sam Williams (Apogeo, 2003). Narra dell'episodio che cambiò la vita di Richard M. Stallman, e anche quella del software. Leggerlo serve a capire l'essenza del software libero e le motivazioni etiche che lo sostengono.

Richard Matthew Stallman

Timeo Danaos et dona ferentes
Virgilio, L’Eneide

La nuova la stampante si era bloccata un'altra volta.

Stallmann programmatore dello staff del laboratorio di intelligenza artificiale (AI Lab) presso il Massachusetts Institute of Technology, aveva fatto le spese di quel malfunzionamento. Un'ora dopo aver inviato un file di 50 pagine alla stampante laser, Stallman, 27 anni, decise di interrompere una produttiva sessione di lavoro per andare a recuperare il documento. Arrivato in loco, trovò appena 4 pagine stampate. Al colmo della frustrazione, si accorse che quelle pagine erano di un altro utente, confermando così che il suo documento per intero e parte delle stampe di qualcun altro erano ancora intrappolati nel circuito elettrico della rete interna.

Per un programmatore il fatto di dover aspettare i comodi di una macchina è un rischio del mestiere, perciò Stallman decise di affrontare la cosa con un po' di buon senso.

Tuttavia, la differenza tra l'attesa del funzionamento di una macchina è quella su una macchina è alquanto considerevole. Non era la prima volta che era costretto a chinarsi sopra la stampante per seguire l'uscita delle pagine una alla volta. Abituato a trascorrere gran parte del giorno e della notte a migliorare l'efficienza degli apparecchi e dei relativi programmi di controllo, Stallman senti il bisogno naturale di aprire quella macchina, dare un attenta occhiata all'interno e isolare le radici del problema.

Purtroppo le sue capacità di programmatore informatico non si estendevano all'ambito dell'ingegneria meccanica. Mentre la stampante continuava a produrre documenti freschi d'inchiostro, Stallman ebbe l'opportunità di riflettere su altre modalità per eludere il problema dell'intasamento dei fogli. Quanto tempo era passato da quando i membri del laboratorio avevano accolto a braccia aperte la nuova stampante? Stallman se lo andava chiedendo. La macchina era stata donata dalla Xerox Corporation. Si trattava di un prototipo d'avanguardia, versione modificata della diffusa fotocopiatrice Xerox. Soltanto che, anziché effettuare copie, seguiva le istruzioni di un apposito software diffuse tramite la rete locale interna per trasformare le informazioni in documenti di qualità professionale. Creata dagli ingegneri dello Xerox Palo Alto Research Center, un centro di fama mondiale, rappresentava, per dirla semplicemente, un assaggio della rivoluzione della stampa desktop che avrebbe poi raggiunto il resto dell'industria informatica entro la fine del decennio.

Guidati da una passione innata a giocare con le migliori apparecchiature esistenti, i programmatori del laboratorio di intelligenza artificiale si erano dati immediatamente da fare per integrare la nuova macchina all'interno anno della sofisticata infrastruttura informatica. I risultati apparvero subito positivi. Al contrario della vecchia stampante laser, la nuova Xerox era assai veloce. Le pagine volavano fuori al ritmo di una al secondo, trasformando un lavoro di 20 minuti in uno da 2 minuti. Il lavoro risultava anche più preciso. I cerchi venivano stampati correttamente, non come ovali. Le linee rette rimanevano tali e non diventavano sinusoidali. Sotto tutti gli aspetti e le intenzioni, si trattava di un regalo troppo bello da rifiutare.

Soltanto qualche settimana dopo il suo arrivo iniziarono a evidenziarsi i primi difetti. Tra i problemi maggiori vi era l'insita predisposizione all’inceppamento della carta. Le menti ingegneristiche di quei programmatori compresero al volo la questione: in quanto fotocopiatrice, generalmente la macchina funzionava con la supervisione diretta di un operatore. Ci sarebbe sempre stato qualcuno, insomma, pronto a risolvere problemi di carta inceppata - così dovevano aver ragionato gli ingegnere della Xerox, dedicandosi perciò la risoluzione di altre noie. In termini tecnici, il sistema di funzionamento faceva affidamento sulla diligenza dell'utente.

Nell’apportare le modifiche necessarie per l'utilizzo come stampante, gli ingegneri della Xerox avevano modificato anche il rapporto utente-macchina in maniera sottile ma profonda. Invece di prevedere l'intervento di un singolo operatore, la macchina sottostava a un'intera popolazione di operatori collegati in rete. Anziché starvi letteralmente sopra, un utente di tale rete inviava il comando di stampa attraverso una lunga catena di macchine, contando sul fatto che il contenuto desiderato giungesse a destinazione in maniera corretta ed appropriata. Solamente alla fine, quando si recava ritirare l’output finale, poteva rendersi conto di quanto poco del contenuto fosse stato effettivamente stampato.

Stallman era stato tra i primi a identificare il problema e il primo a suggerirne la soluzione. Qualche anno addietro, quando il laboratorio utilizzava ancora la vecchia stampante, Stallman aveva risolto un problema analogo aprendo il “software” di controllo della stampante collegata alla macchina PDP-11 del laboratorio. Pur non riuscendo a impedire l'inceppamento della carta, egli inserì nel programma un comando che ordinava al PDP-11 di verificare periodicamente i vari meccanismi e inviarne relazione al PDP 10, il computer centrale del laboratorio. Per esser certo che la negligenza di qualcuno non danneggiasse tutta una serie di stampe in corso, Stallman aggiunse inoltre un comando che istruiva il PDP 10 a notificare l'eventuale blocco della stampante a ogni utente con una stampa in attesa. Si trattava di una semplice nota, qualcosa del tipo “La stampante è bloccata, si prega di sistemarla”; e poiché tale nota raggiungeva proprio coloro che avevano maggior necessità di risolvere il problema, esistevano buone probabilità che ciò avvenisse in tempi brevi.

Come per ogni soluzione, quella di Stalmann era indiretta ma elegante. Non risolveva la parte meccanica del problema, però ci andava vicino chiudendo il cerchio informativo tra utente e macchina. Grazie all'aggiunta di poche righe di codice, lo staff del laboratorio di intelligenza artificiale poteva così eliminare una perdita di tempo pari a 10-15 minuti ogni settimana per correre avanti e indietro a controllare la stampante. In termini di programmazione, la soluzione di Stallman traeva vantaggio dall'intelligenza amplificata che sosteneva la rete locale nel suo complesso.

”Se ricevevi quel messaggio, non potevi dare per scontato che qualcun altro avrebbe risolto il problema”, spiega Stallman, sottolineando la logica applicata in quell'occasione. “Dovevi controllare di persona. Un minuto o due dopo il mancato funzionamento, i due o tre utenti che avevano ricevuto l'avviso erano andati a risolvere il problema. Di questi, generalmente almeno uno sapeva come fare per risistemare i fogli”.

Questo tipo di soluzioni indirette rappresentavano una sorta di marchio del laboratorio di intelligenza artificiale e dei programmatori originari che lo popolavano. Anzi, i migliori tra costoro disdegnavano lo stesso termine programmatore, preferendo invece l'appellativo gergale di hacker. Una qualifica professionale che indicava uno spettro di attività alquanto ampio - qualsiasi cosa compresa tra il caos creativo e il miglioramento di software e sistemi esistenti. Nel termine era tuttavia implicita la vecchia idea di una certa ingenuità yankee. Per essere un hacker, bisognava accettare la filosofia secondo cui la scrittura di un programma era soltanto l'inizio. Stava poi nella capacità di migliorarlo la vera prova di abilità per un hacker.

Questa filosofia costituiva il motivo principale che spingeva aziende come la Xerox a seguire la politica di donare macchine e programmi a quelle entità che costituivano il terreno abituale degli hacker. Se questi ultimi riuscivano a migliorarne il software, tali migliorie sarebbero state riutilizzate dalle stesse aziende, incorporandole nelle nuove versioni dei programmi destinati al mercato commerciale. Nella terminologia imprenditoriale, gli hacker rappresentavano una sorta di capitale e comunitario, un'unità aggiuntiva per la ricerca e lo sviluppo disponibile a costi minimi.

Fu grazie a questa filosofia del dare è del ricevere che quando Stallman isolò il difetto di carta inceppata nella stampante laser Xerox, non si fece certo prendere dal panico. Semplicemente, si mise alla ricerca di un modo per aggiornare le vecchie procedure e adattarle al nuovo sistema. Tuttavia, mentre si apprestava a dare un'occhiata al software della stampante Stallmann scopri qualcosa di preoccupante. La macchina non sembrava essere dotata di alcun software, almeno nulla che lui stesso con gli altri programmatori fossero in grado di leggere. Fino ad allora, la maggioranza delle aziende riteneva una forma di cortesia la pubblicazione in formato testuale dei codici sorgenti che documentavano i singoli comandi su cui era basato il comportamento della macchina. In questo caso, la Xerox aveva fornito i file in formato precompilato, ovvero binario. I programmatori erano liberi di aprirli, ma a meno che non fossero degli esperti nel decifrare sequenze infinite di zero e di uno, il testo finale sarebbe rimasto una sfilza di caratteri incomprensibili.

Pur sapendone parecchio di informatica, Stallman non poteva considerarsi certo un esperto nella decifrazione dei file binari. L'esperienza acquisita come hacker gli consentiva, però, di fare affidamento su altre risorse. Il concetto della condivisione dell'informazione occupava un ruolo talmente centrale nella cultura hacker che sarebbe stata solo questione di tempo prima che un collega di qualche laboratorio universitario o di altra struttura aziendale riuscisse a fornirgli la versione e testuale dei sorgenti relativi a quel software.

Dopo i primi blocchi della stampante, Stallman si consolo ripensando a una situazione analoga sperimentata qualche anno addietro. Il laboratorio aveva avuto bisogno di un programma sulla rete per aiutare il PDP-11 ad operare in maniera più efficiente con il PDP-10. Gli hacker del laboratorio potevano facilmente cavarsela da soli, ma Stallman, avendo studiato ad Harvard, si ricordò di un programma analogo scritto dai programmatori del Dipartimento di Informatica di quell'università. Tale dipartimento usava un computer del medesimo modello, il PDP-10, pur se dotato di un diverso sistema operativo. Le procedure in vigore nel laboratorio richiedevano altresì che tutti i programmi installati sul PDP 10 fossero accompagnati dalla pubblicazione dei relativi codici sorgenti.

Potendo contare sul pieno accesso al laboratorio di informatica di Harvard, Stallman vi si recò, fece una copia di quei codici e li portò con sé al laboratorio di intelligenza artificiale. Qui prese a riscrivere alcune parti onde renderle compatibili con il sistema operativo locale. Senza troppo clamore, il laboratorio di intelligenza artificiale richiuse una falla importante all'interno della propria infrastruttura informatica. Stallman aggiunse persino alcune funzioni assenti nel programma originale di Harvard, rendendolo così ancora più utile. “Ne facemmo uso per parecchi anni senza problemi”, sostiene Stallman.

Nella concezione di un programmatore degli anni ‘70, questa operazione era l'equivalente software di un vicino di casa che veniva a chiederci in prestito un utensile o una tazza di zucchero. Nel caso del prestito di una copia del software per il laboratorio di intelligenza artificiale, l'unica differenza stava nel fatto che Stallman non aveva privato gli hacker di Harvard dell'utilizzo del programma originale anzi. Anzi, erano stati proprio costoro a trarne vantaggio, considerate le nuove funzionalità aggiuntevi dallo stesso Stallman, funzionalità che rimanevano a loro completa disposizione. Anche se nessuno a Harvard richiese mai quel programma, Stallman ricorda che lo fece invece uno sviluppatore della società privata Bolt, Beranek & Newman, il quale vi apportò ulteriori aggiunte poi reintegrate da Stallman nell'archivio dei codici sorgenti organizzato presso lo stesso laboratorio di intelligenza artificiale.

”Normalmente ogni programma seguiva uno sviluppo analogo a quello della pianificazione cittadina”, dice Stallman in riferimento all' infrastruttura informatica in vigore in quel laboratorio. “Alcune aree venivano interamente sostituite e ricostruite. Vi si aggiungevano nuovi elementi. Ma era sempre possibile isolarne qualche sezione e dire, ‘a giudicare dallo stile, queste stringhe sono state scritte all'inizio degli anni 60, mentre queste altre risalgono a metà anni 70’.”

Grazie a questo semplice sistema di crescita intellettuale, gli hacker operanti nel laboratorio di intelligenza artificiale e in altri ambiti riuscirono a mettere in piedi prodotti particolarmente affidabili. Fu ricorrendo a tale strategia che, sulla costa occidentale degli Stati Uniti, i ricercatori della University of California di Berkeley, in collaborazione con alcuni ingegneri di primo livello presso la AT&T, realizzarono un intero sistema operativo. Chiamato Unix, con un gioco di parole riferito ad un sistema operativo più vecchio e più rispettabile in ambito accademico noto come Multics, il software venne messo a disposizione di qualunque programmatore disposto ad accollarsi le spese per copiarlo su un nuovo nastro magnetico e per la successiva spedizione.

Non tutti gli sviluppatori coinvolti in questa cultura amavano autodefinirsi hacker, ma la vasta maggioranza condivideva i sentimenti di Stallman. Se un programma o una correzione software si dimostravano sufficientemente validi da risolvere i problemi dell'autore, potevano risolvere anche quelli di qualcun altro. Perché allora non condividerle anche soltanto per guadagnarsi un buon karma?

Inizialmente il fatto che la Xerox avesse deciso di non condividere i propri sorgenti non provocò alcun fastidio. Mentre andava alla ricerca di quei file, Stallman sostiene di non essersi minimamente preoccupato di contattare la Xerox: “Ci avevano già regalato la stampante, perché mai importunarla ancora?”

Quando però si accorse che i file non comparivano da nessuna parte, Stallman inizio a farsi sospettoso. L'anno precedente aveva già subito un brutto colpo da parte di un laureando presso la Carnegie Mellon University. Lo studente, Brian Reid, aveva realizzato un utile programma di formattazione testi chiamato Scribe. Si trattava di uno dei primi software grazie al quale l'utente poteva scegliere font e stili di un documento da inviare attraverso una rete, antesignano del linguaggio HTML, la lingua franca del World Wide Web. Nel 1979, Reid decise di vendere Scribe ad un'azienda produttrice di software nell'area di Pittsburgh, la Unilogic. Ormai vicino alla laurea, Reid stava semplicemente cercando una soluzione per mollare il programma a qualche sviluppatore disposto ad accollarsi l'onere di impedirne la caduta nel pubblico dominio. Per addolcire la trattativa, Reid si dichiarò inoltre d'accordo all'inserimento di una serie di funzioni con limiti temporali - bombe a tempo, nel gergo dei programmatori - grazie alle quali le versioni gratuite del programma smettevano di funzionare dopo 90 giorni. Onde evitare la disattivazione, gli utenti dovevano così pagare una tariffa al produttore, il quale a sua volta avrebbe fornito loro il codice necessario a disattivare il blocco.

Secondo Reid, era un buon affare per entrambe le parti. Scribe non si sarebbe eclissato tra i programmi di pubblico dominio mentre la Unilogic avrebbe recuperato il denaro investito. Per Stallman si trattava invece del puro e semplice tradimento dell'etica del programmatore. Anziché onorare il concetto della condivisione, Reid collaborava con l'industria costringendo gli sviluppatori a pagare per avere accesso all'informazione.

Con il trascorrere delle settimane, mentre i tentativi di rintracciare il codice sorgente della stampante apparivano senza via d'uscita, Stallman senti incombere un analogo scenario di scambio denaro codice. Tuttavia, prima di poter dire o fare qualunque cosa al riguardo, ecco la rete dei programmatori produrre una buona notizia. Girava voce che un ricercatore presso il Dipartimento di Informatica della Carnegie Mellon University si era appena dimesso dallo Xerox Palo Alto Research Center. E non soltanto aveva lavorato sulla stampante in questione, ma, stando alle stesse voci, se ne stava tuttora occupando come parte dei progetti assegnatigli alla Carnegie Mellon.

Mettendo da parte ogni sospetto iniziale, Stallman decise di andarlo a trovare durante la sua visita successiva al campus di quell'università. Non dovete attendere a lungo. Anche la Carnegie Mellon aveva un laboratorio specializzato in ricerche sull'intelligenza artificiale, e nel giro di qualche mese egli dovette recarvisi per questioni di lavoro. Durante la visita, fece in modo di fermarsi al Dipartimento di Informatica. Qualcuno dei Ricercatori gli indico l'ufficio del docente incaricato del progetto Xerox. Entrando in quell'ufficio, lo trovo al lavoro.

Nel tipico confronto tra ingegneri, la conversazione e che ne segui fu cordiale ma schietta. Dopo essersi rapidamente presentato come un collega del MIT, Stallman gli chiese una copia dei sorgenti della stampante laser in modo da poterli adattare al PDP-11. Con sua sorpresa, il professore gli oppose un netto rifiuto.

”Mi disse di aver promesso che non me ne avrebbe fornito una copia, sostiene Stallman”.

A volte la memoria gioca brutti scherzi. Vent'anni dopo quel fatto, il ricordo mentale di Stallman è notoriamente pieno di lacune. Non soltanto non rammenta la motivazione alla base del viaggio di lavoro nell'anno in cui questo avvenne, ma neppure riesce a descrivere in qualche modo la controparte con cui tenne quello scambio di battute. A sentire Reid, probabilmente la persona che avrebbe potuto soddisfare la richiesta di Stallman era Robert Sproull, ex ricercatore presso lo Xerox PARC e attuale direttore dei laboratori, divisione del conglomerato informatico Sun Microsystems. Negli anni 70, mentre lavorava allo Xerox PARC, Sproull aveva diretto il gruppo di sviluppo del software per la stampante laser in questione. Verso il 1980, assunse il ruolo di ricercatore informatico presso la Carnegie Mellon, dove tra i vari progetti continua ad occuparsi ancora di quella stampante.

”Il codice oggetto della richiesta di Stallman rappresentava la parte migliore del software che Sproull aveva scritto nell'anno precedente al suo arrivo alla Carnegie Mellon”, ricorda Reid. “Credo che Sproull si trovasse alla Carnegie Mellon da meno di un mese quando arrivò quella richiesta.”

Interrogato direttamente sulla questione, tuttavia, Sproull cade dalle nuvole. “Non posso offrire alcun commento”, mi scrive via e-mail. “Non ho assolutamente il minimo ricordo dell'incidente”.

Vista l’amnesia di entrambe le persone coinvolte in quella breve conversazione, inclusa persino la veridicità sull'effettivo svolgimento, è difficile valutare la rudezza del rifiuto opposto da Sproull, almeno nella ricostruzione di Stallman. Nei suoi interventi pubblici, quest'ultimo ha più volte fatto esplicitamente riferimento all'incidente, sottolineando come il rifiuto di Sproull fosse dovuto al cosiddetto accordo di non divulgazione (non-disclosure agreement), norma contrattuale stipulata tra la Xerox Corporation e il proprio dipendente, sulla base della quale a quest'ultimo veniva garantito accesso ai codici sorgenti del software in cambio della promessa di mantenere la loro segretezza. Oggi clausola standard nei contratti dell'industria informatica, a quel tempo l'accordo di non divulgazione costituiva una novità, un segnale del valore commerciale acquisito per la Xerox sia dalla stampante sia dalle informazioni necessarie al relativo funzionamento. “In quel periodo la Xerox stava cercando di lanciare la stampante laser come prodotto commerciale”, spiega Reid. “Per loro sarebbe stato folle regalarne in giro i codici sorgenti”.

Invece Stallman considerava la faccenda in maniera diametralmente opposta si trattava del rifiuto da parte della Xerox Sproull, o chiunque fosse la persona che quel giorno si trovò di fronte, di far parte di un sistema che fino ad allora aveva spinto gli sviluppatori a considerare i programmi al pari di risorse comuni. Come un contadino i cui canali d'irrigazione vecchi di secoli si fossero improvvisamente prosciugati, Stallman aveva seguito quei canali fino alla sorgente soltanto per scoprire una nuova diga idroelettrica in cui spiccava il logo della Xerox.

Non fu semplice per Stallman mandar giù il fatto che la Xerox avesse coinvolto alcuni programmatori in questo nuovo e stravagante sistema di segretezza forzata. All'inizio riuscì a comprendere soltanto la natura personale di quel rifiuto. Dato che in generale gli incontri faccia a faccia lo mettevano a disagio e in imbarazzo, la visita non annunciata di Stallman ad un collega poteva essere intesa come una dimostrazione di socialità tra buoni vicini. Ma ora il rifiuto bruciava come un grave atto di scortesia. “Ero talmente arrabbiato che non riuscivo neppure ad esprimerlo. Così mi sono girato e sono uscito, senza aggiungere neanche una parola”, rammenta Stallman. “Può anche darsi che abbia sbattuto la porta, chissà? Tutto quel che ricordo è che volevo andarmene subito via”.

Vent'anni dopo quel fatto, la rabbia brucia ancora tanto da spingere Stallman a ritenere l'evento un punto di svolta sostanziale. Nei pochi mesi successivi, Stallman e gli hacker del laboratorio di intelligenza artificiale sarebbero stati colpiti da un ulteriore serie di eventi talmente negativi da fare impallidire la tensione di quei 30 secondi in un remoto ufficio della Carnegie Mellon. E tuttavia, quando si tratta di individuare quei singoli episodi che avrebbero trasformato Stallman da hacker solitario, istintivamente sospettoso verso ogni autorità centralizzata, ad attivista animatore di una crociata che applica le nozioni tradizionali di libertà, uguaglianza e fraternità al mondo dello sviluppo software, lo stesso Stallman non esita a isolare l'incontro alla Carnegie Mellon, dedicandogli un’attenzione tutta particolare. “L'evento mi spinse a riflettere più a fondo su quel che andavo già pensando”, spiega Stallman. “Avevo già l'opinione che il software avrebbe dovuto essere condiviso, ma non sapevo bene come procedere. Non avevo le idee chiare e organizzate al punto da poterle esprimere in maniera concisa al resto del mondo”.

Sebbene alcuni episodi precedenti avessero già suscitato le ire di Stallman, egli sostiene come fino all'incontro della Carnegie Mellon non si fosse reso conto del fatto che quella serie di eventi andasse infiltrandosi in una cultura considerata sacrosanta da molto tempo. Facendo parte di un élite di programmatori in una delle maggiori istituzioni al mondo, Stallman aveva coscientemente deciso di ignorare ogni patto o compromesso sottoscritto dai suoi colleghi fintanto che ciò non interferiva con il il proprio lavoro. Fino all'arrivo della stampante laser della Xerox, egli si era accontentato di dedicarsi a macchine e programmi a malapena tollerati da altri utenti. Nelle rare occasioni in cui tali programmi uscirono dalle stanze del laboratorio di intelligenza artificiale - quando, per esempio, il laboratorio sostituì il venerabile sistema operativo Incompatible Time Sharing con una variante commerciale chiamata TOPS 20 - Stallman e gli altri hacker erano stati liberi di riscrivere, ricocostruire e rinominare il software sulla base del gusto personale.

Ora che la stampante laser si era insinuata nella rete del laboratorio, tuttavia, qualcosa era cambiato. La macchina funzionava bene, al di là di occasionali problemi di carta inceppata, ma era scomparsa la possibilità di modificarlo secondo il gusto personale. Dal punto di vista dell'industria del software nel suo complesso, la stampante rappresentava un campanello d'allarme. Il software era divenuto un bene talmente prezioso che le aziende non sentivano la necessità di diffondere i sorgenti, soprattutto quando la loro pubblicazione significava offrire ai potenziali concorrenti la possibilità di duplicare qualche programma a costi irrisori.

Dal punto di vista di Stallman la stampante era una sorta di cavallo di Troia. Dopo un decennio di tentativi falliti, il software sotto proprietà privata - in seguito gli hacker introdurranno il termine proprietario - aveva messo piede nel laboratorio di intelligenza artificiale grazie al più subdolo dei metodi. Vi era entrato sotto le mentite spoglie di un regalo.

Il fatto che Xerox offrisse ad alcuni programmatori l'accesso doni ulteriori in cambio del loro riserbo era un'amara scoperta, tuttavia Stallman non può fare a meno di notare come egli stesso, nel caso gli fosse stato proposto un simile scambio nei suoi anni giovanili, probabilmente avrebbe accettato l'offerta della Xerox Corporation. Però l'imbarazzante incontro alla Carnegie Mellon provocò un salutare effetto sulla sua apatia morale. Non soltanto l'evento gli fornì la rabbia necessaria per considerare ogni futuro regalo con una buona dose di sospetto, ma lo costrinse a porsi una domanda inquietante: cosa accadrebbe se un giorno un collega hacker entrasse nell'ufficio di Stallman e improvvisamente egli dovesse trovarsi a rifiutare un'analoga richiesta del codice sorgente?

Era la prima volta che mi imbattevo in una clausola di non divulgazione, e mi resi immediatamente conto come questi accordi producano delle vittime, sostiene con convinzione Stallman. In questo caso la vittima ero io. Io e il mio laboratorio.

Fu questa una lezione avrebbe accompagnato Stallman lungo i tumultuosi anni 80, un decennio nel corso del quale parecchi colleghi al MIT avrebbero abbandonato il laboratorio di intelligenza artificiale per firmare analoghi accordi di non divulgazione a livello personale. Poiché gran parte di questi accordi prevedono un limite di durata, gli hacker che decisero di sottoscriverlo non ci pensarono su due volte. Prima o poi, questo è il loro ragionamento, il software diverrà di pubblico dominio. D'altra parte, la promessa di mantenere segreto il programma nel primo periodo di sviluppo faceva parte di quel compromesso che permetteva agli hacker di lavorare sui progetti migliori. Anche se per Stallman ciò non rappresenta altro che il primo passo verso un terreno molto sdrucciolevole.

Quando ricevevo un invito a tradire in tal modo tutti i miei colleghi, sentivo riaffiorare la rabbia provata quando qualcun altro aveva fatto lo stesso con me e l'intero laboratorio, insiste Stallman. Allora rispondevo, ‘Grazie mille per l'offerta di questo bel pacchetto software, ma non posso accettarlo alle condizioni che mi avete richiesto, per cui ne farò a meno’.”

Come avrebbe imparato presto, il rifiuto implicava molto di più di qualche sacrificio personale. Significava piuttosto l'isolamento dagli altri hacker che, pur condividendo un'analoga avversione per i segreti, tendevano esprimerle in maniera più elastica a livello etico. Non trascorse molto tempo prima che Stallman, sempre più isolato all'interno del suo stesso laboratorio, prese ad autodefinirsi “l'ultimo vero hacker”, allontanandosi sempre più da un mercato caduto sotto il dominio del software proprietario. Il rifiuto opposto a una qualsiasi richiesta per il codice sorgente, decise Stallman, rappresentava non soltanto il tradimento della missione scientifica che aveva alimentato lo sviluppo del software a partire dalla fine della Seconda Guerra Mondiale, ma anche una violazione della regola aurea, il fondamento morale che imponeva di non fare ad altri quello che non vorresti fosse fatto a te.

Da qui l'importanza della stampante laser e del successivo incontro alla Carnegie Mellon. In mancanza di questa circostanza, afferma Stallman, la sua vita avrebbe potuto seguire un percorso più ordinario, alla ricerca di un equilibrio tra la ricchezza di un programmatore commerciale e la frustrazione finale di un'esistenza spesa scrivere codice invisibile. Non si sarebbe evidenziato alcun senso di chiarezza, nessuna urgenza di affrontare un problema di cui nessun altro pareva curarsi. Fatto ancor più importante, non avrebbe preso corpo quella giusta ira, un sentimento che, lo vedremo più avanti rimarrà il motore propulsore della carriera di Stallman tanto quanto l'ideologia politica o le considerazioni etiche.

”Da quel giorno in poi decisi che non avrei mai potuto partecipare a quel sistema”, dice Stallman riferendosi alla pratica di barattare la libertà personale per pura convenienza - così descrive gli accordi di non divulgazione - ma anche e soprattutto alla cultura globale che incoraggiava simili accordi moralmente dubbi. “Presi la decisione di non causare mai altre vittime, come era invece successo a me.”

Richard Stallman abbandonò la sua prestigiosa posizione di ricercatore presso il laboratorio artificiale del MIT (Massachusetts Institute of Technology) per potersi dedicare a quella che la stragrande maggioranza dei suoi contemporanei considerava un'idea visionaria e scarsamente credibile. Per capire la portata di questa decisione occorre sapere che per un giovanotto appassionato di quel genere di cose, il laboratorio del MIT era senza dubbio il miglior posto al mondo per fare ricerca. Il suo è stato senza dubbio un no clamoroso.

Le 4 libertà del software libero

Secondo la definizione di Stallman, il software è libero se garantisce le seguenti quattro libertà:

1. Libertà di eseguire il programma per qualsiasi scopo
2. Libertà di studiare il programma e modificarlo
3. Libertà di ridistribuire copie del programma in modo da aiutare il prossimo
4. libertà di migliorare il programma e di distribuirne pubblicamente i miglioramenti, in modo tale che tutta la comunità ne tragga beneficio

Naturalmente, queste affermazioni si possono comprendere solo se si ha una minima idea di cosa sia il software. Facciamo un semplice esempio.

CLEARSCREEN
REPEAT [
    FORWARD 100
    RIGHT 90
]
	

Oppure...

clear()
repeat (4) {
    forward(100)
    right()
}
	

Questi due frammenti di codice servono a disegnare un quadrato in LOGO. Studieremo per bene come. La differenza fra i due esempi sta nel fatto che si riferiscono a due diverse versioni di LOGO, la prima è LibreLogo, che studieremo estesamente, la seconda è una versione più sofisticata e potente che si chiama Kojo, che chi lo vorrà potrà a suo tempo sperimentare. La cosa importante da osservare è che questo è il software: nient'altro che un testo scritto secondo delle ben precise regole. Anzi, possiamo dire con una precisa grammatica, perché ogni linguaggio ha un suo lessico, un'ortografia e una sintassi. Questa è perlomeno la parte che vediamo noi. Poi c'è la parte che vede il computer, che è in grado di interpretare e eseguire istruzioni rappresentate da sequenze di zero e uno. Infatti, quando noi chiediamo di "eseguire" un software, in realtà si attiva un qualche altro software che provvede a tradurre le istruzioni che abbiamo scritto in quelle corrispondenti ma codificate in sequenze di zero e uno. Questa forma dello stesso software è (quasi) inintelligibile per noi ma è quella che serve al computer per eseguirla. Questo giusto per sapere. A noi interessa la versione scritta che abbiamo appena vista, perchè è quello che ci serve per capire le quattro libertà, in particolare quando ci si riferisce a studiare, modificare, migliorare il programma (con il termine "programma" si intende un pezzo di software che fa certa precisa cosa): apro il file che contiene il programma, lo studio, provo a cambiarlo, lo salvo, lo faccio eseguire, se funziona e può interessare qualcuno lo ridistribuisco. Lasciamo per ora perdere come si possa eseguire, questo dipende dal contesto, dal linguaggio ecc. Non è la parte importante del nostro discorso. Quello che importa è avere chiaro di come si possa fare a capire e cambiare un software.

L'aspetto etico e licenze Copyleft: GPL ecc.

Ma il fatto importante viene ora. Riscriviamo le quattro libertà nel modo seguente:

1. Libertà di eseguire il programma per qualsiasi scopo
2. Libertà di studiare il programma e modificarlo
3. Libertà di ridistribuire copie del programma in modo da aiutare il prossimo
4. libertà di migliorare il programma e di distribuirne pubblicamente i miglioramenti, in modo tale che tutta la comunità ne tragga beneficio

Stavamo parlando di tecnologia e ci ritroviamo le espressioni "aiutate il prossimo" e "che tutta la comunità ne tragga beneficio". Questo nuovo concetto di software fu introdotto da Stallman verso la metà degli anni '80 ma non si tratta di un episodio isolato. Per quanto potesse sembrare una posizione eccentrica e visionaria il fenomeno è dilagato nel mondo, dando luogo ad una creatività enorme e gravida di conseguenze concrete. Il merito di Stallman non è solo quello di avere avuto l'idea ma anche quello di avere concepito lo strumento per proteggere l'idea. È un aspetto cruciale perché un'idea del genere è intrinsecamente "debole". La protezione consiste in un nuovo tipo di licenza. Come è più o meno noto a tutti, le opere dell'ingegno sono protette dalle leggi del Diritto d'Autore. Questo significa che qualsiasi opera, creata da chicchessia in qualsiasi campo, è automaticamente protetta e, se l'autore ritiene che i suoi diritti siano stati infranti, può rivalersi secondo i termini della legge. Chi vuole approfondire può trovare qui un approfondimento. Lo strumento ideato da Stallman interviene su questa materia, non nel senso di alterare il concetto di diritto d'autore (in America si chiama copyright che è un po' diverso anche se il concetto base rimane) ma di fornire all'autore uno strumento per cedere parte dei propri diritti, qualora lo voglia. Questa è stata chiamata Copyleft e le corrispondenti licenze General Public License. Distribuire "software libero" vuol dire quindi distribuire il codice in chiaro, come abbiamo visto sopra, e corredare il testo del software con appropriate diciture, come descritto in questa pagina.

Oggi c'è confusione fra queste due espressione e prevale decisamente la seconda. Ma sono due cose diverse. La differenza è spiegata con qualche dettaglio nella lezione precedente: Introduzione al software libero. Brevemente, il software libero è software sviluppato da comunità di programmatori che credono in un’etica della condivisione, il software open source è distribuito liberamente insieme al codice sorgente da programmatori oppure anche da aziende. In generale, chi distribuisce software open source non è necessariamente interessato agli aspetti etici dell questione, contrariamente a chi distribuisce il software libero.

Così come l'idea di software libero in se, anche il dispositivo concettuale delle licenze Copyleft ha avuto un successo straordinario. Infatti, negli anni successivi, sono emerse una varietà di licenze adatte ad altri tipi di opere, non solo al software. Le più note sono le licenze Creative Commons, con le quali l'utente può modulare finemente i diritti che decide di cedere. Oltre al sito che ho appena linkato, altri dettagli possono essere trovati nel già citato articolo sul Diritto d'Autore.

Da menzionare anche la Free Software Foundation, una società fondata da Stallman per la pubblicazione e il mantenimento della General Public License, la promozione del software libero e in particolare del sistema operativo GNU. In realtà GNU fornisce un gran numero di componenti fondamentali che stanno nel cuore di un sistema operativo, completo. I sistemi Linux, di cui diremo fra poco, contengono tutti questi componenti. In questo senso sarebbe corretto parlare del sistema GNU/Linux, anche se ormai tutti chiamano quest'ultimo brevemente Linux.

Sistema operativo Linux

Linus Benedict Torvalds

Il 25 agosto 1991, Linus Torvalds, all'età di 22 anni - era uno studente di informatica a Helsinki - scrisse la seguente email ad un gruppo di specialisti che lavoravano intorno ad un nuovo sistema operativo Minix (ripresa da Rivouzionario per caso: Linux, Garzanti, 2001, con qualche semplificazione):

Da: torvalds@klaava.helsinki.fi (Linus Benedict Torvalds)
A: Newsgroup: comp.os.minix
Oggetto: piccolo sondaggio per il mio nuovo sistema operativo

Ciao a tutti quelli che usano Minix. Sto realizzando 
un sistema operativo free (è solo per hobby, non sarà 
una cosa grossa e professionale come gnu) per cloni 386 
(486) AT [NdR: in sostanza i personal computer dell'epoca]. 
Ci lavoro da aprile e sta cominciando a prendere forma. 
Mi piacerebbe avere la vostra opinione su cosa vi piace/non 
vi piace in minix, perché il mio sistema operativo gli 
assomiglia per alcuni aspetti.

Al momento ho fatto girare bash (1.08) e gcc (1.40) 
[NdR: si tratta di componenti del sistema GNU, di Stallman, 
di cui dicevamo] e la cosa sembra funzionare. Il che vuol 
dire che entro qualche mese avrò qualcosa di utilizzabile 
e mi piacerebbe sapere quali sono le caratteristiche che 
interessano di più alla gente. Tutti i suggerimenti sono 
ben accetti, ma non vi prometto di implementarli :-)

Linus

Anche se Linus Torvalds ha sempre preso le distanze dagli eccessi di Stallman, a suo dire troppo ideologici, non vi è dubbio che già a quei tempi avesse assorbito uno spirito di collaborazione che in epoca pre-stallmaniana sarebbe stato impensabile: "guardate cosa ho fatto, fatemi sapere se vi interessa, cosa fareste voi..."

Di lì a pochissimo, il 17 settembre 1991, Linus pose in rete tutto il sistema che aveva scritto, in modo che fosse scaricabile da chiunque in Internet. Una quantità di materiale che corrispondeva a circa 10000 righe di codice. Ebbene, la gente si interessò moltissimo e prese a contribuire, in un travolgente processo a valanga: nel 1995 il sistema era composto da 250000 righe di codice e nel 2001 aveva raggiunto 10 milioni di righe! Altri particolari della storia sono reperibili nel capitolo Software libero.

Oggi Linux è il sistema operativo di riferimento per i web server, le macchine che offrono le pagine web nella rete. Ma la sua caratteristica fondamentale è la grande modularità che lo rende estremamente flessibile e adattabile alle necessità più diverse. Per esempio una grande quantità di macchine, come router, sistemi di backup, schede di controllo per elettrodomestici - solo per fare qualche esempio - funzionano con versioni specializzate di Linux, cosiddette embedded. Il sistema Android, che equipaggia la maggioranza degli smartphone presenti oggi sul mercato, deriva da Linux. In questa pagina (attenzione sono 2.6 MB: 2220x10114 pixel) si può esplorare quella che ha le sembianza di una vera e propria esplosione evolutiva dei sistemi Linux. Per gioco, il lettore può provare a vedere se trova Ubuntu, la "distribuzione" più diffusa fra i sistemi di uso comune.

Il no di Linus Torvald è meno eclatante di quello di Stallman, non legato ad una precisa rivelazione o presa di posizione, intrisa di motivazioni sociali o altro. Il no di Torvalds attiene piuttosto allo stile di vita, totalmente orientato a soddisfare le proprie curiosità e a esercitare le proprie passioni, e non al conseguimento di successi economici o di carriera. Il fenomeno di Linux è stato travolgente, ha investito la vita delle più grandi aziende di information technology, inducendole a reinventarsi nuovi modeli di business, e ha mosso enormi quantità di denaro. Ma Torvalds non è diventato ricco. Pur prendendosi cura del coordinamento delle innovazioni prodotte da comunità software di tutto il mondo, si è limitato a scegliere il posto di lavoro che più lo attraeva, in base ai propri interessi scientifici, e, come narra nella sua autobiografia, a comprarsi una macchina, e nemmeno stratosferica, diciamo una macchina di fascia medio alta che gli piaceva. Tutto qui. Il suo è un messaggio interessante: si possono fare cose straordinarie rimanendo uomini normali. Questa è una categoria molto ampia. Vi appartengono ad esempio i vari scienziati che hanno costruito veramente i mattoni fondamentali di tutto ciò che chiamiamo oggi tecnologia, buona o cattiva che la si voglia considerare (vere ambedue le valutazioni, fatto importante da discutere altrove).

Indubbiamente il software è un territorio ottimale per l'innovazione. Il ciclo di ideazione-sperimentazione è brevissimo: scrivere, provare, correggere, riprovare. Un processo quasi immediato. Questo non significa che sia facile, tutt'altro. Appena i progetti si complicano un po', si amplificano le fasi di progettazione e soprattutto di perfezionamento, fase questa che prende il nome di debugging, che è spesso lunghissima: è raro che un software complesso possa essere dichiarato privo di difetti. Di solito, quando arriva a questo punto, se mai ci arriva, è anche passato così tanto tempo che il software è obsoleto nel suo complesso, e occorre rifarsi daccapo con la progettazione ex novo di una versione adatta alle mutate esigenze. Ma sono certamente più dinamici i processi di innovazione nel software piuttosto che in qualsiasi altro campo dove si debba costruire qualcosa di materiale. Non è un caso che questo paradigma di costruzione collettiva di un artefatto sia esplosa nel campo del software. Però, ora che il fenomeno è maturato ampiamente, il modello si è esteso a altri ambiti della produzione e non solo, anche a contesti molto più generali, come per esempio quello della cosiddetta sharing economy, tanto per fare un esempio. Tant'è che già da tempo si parla di hardware open source. Ma cosa vuol dire? È facile capire cosa voglia dire distribuire liberamente un software, in fin dei conti è un codice scritto in formato testo. Lo possiamo mettere anche in un'email! Ma una scheda elettronica? È qui che viene l'innovazione di Massimo Banzi e del suo gruppo. Massimo Banzi è un insegnante di un istituto tecnico, ingegnere, che ebbe l'idea di fabbricare una scheda elettronica che rendesse possibile la realizzazione di progetti artistici "computerizzati", ovvero mobili e eventualmente interattivi con l'ambiente. L'idea comportava una sfida: realizzare una scheda elettronica in grado di soddisfare sì l'obiettivo, ma che al tempo stesso potesse essere gestita senza prendere una laurea in ingegneria elettronica. Così è nato Arduino. Un schedina elettronica delle dimensioni di una carta di credito, in grado di ricevere informazioni da una varietà di sensori (temperatura, umidità, movimento ecc.), elaborare i dati mediante un apposito software scritto dall'utente e inviare comandi a altri dispositivi: accensione e spegnimento di luci o altro, attuatori di movimento in robot e così via. E dove sta il lato "open", considerato che la scheda si compra (circa 20€, o 100€ in un kit didattico)? Ebbene, Massimo Banzi e i suoi hanno avuto l'idea di rendere "open source" gli schemi della scheda, anziché metterli sotto chiave nella cassaforte della proprietà intellettuale dell'azienda, limitandosi a porre il copyright solo sul nome, "Arduino". Ecco, questa sembrava un'altra "decisione folle", invece cosa è successo? È successo che, come era prevedibile, la scheda è stata immediatamente copiata in tutto il mondo ma questo non si è risolto in un danno bensì in una formidabile fonte di pubblicità. La quantità e varietà di cloni che si sono diffusi rapidamente in tutto il mondo ha reso semplicemente famoso il progetto Arduino, in una maniera altrimenti impossibile. Non solo, allo staffo di Massimo Banzi sono anche ritornati indietro una quantità di suggerimenti per migliorare e ampliare le prestazioni della scheda, dando luogo anche alla proliferazione di una varietà di scede originali diverse e anche a tutta un'accessoristica che ha ulteriormente esteso la presenza di Arduino del mondo. Oggi, le schede Arduino sono utilizzate in innumerevoli contesti didattici ma anche in applicazioni tecniche, tipo domotica e dintorni, ma sono utilizzate anche negli acceleratori di particelle al CERN e negli equipaggiamenti di alcuni satelliti. Non si contano i progetti; ne esiste anche uno dove si può inviare il proprio software per Arduino per fare determinati esperimenti con misure fatte in un apposito satellite (progetto ArduSat).

Hardware libero

Qui sotto si vede Arduino all'opera. Il cavo nero a sinistra entra nella scheda con un connettore USB. Questo serve sia a dare l'alimentazione elettrica alla scheda che a scaricare il software in Arduino. Per usarlo occorre fare due cose:

1. Scrivere un software che gli faccia fare quello che desideriamo. Il software va scritto nel computer e poi da questo deve essere scaricato in Arduino mediante un'applicazione liberamente disponibile nella sezione "Download" del sito web di Arduino.
2. Collegare Arduino a uno o più circuiti elettronici, a loro volta collegati a sensori e altri dispositivi elettronici.

Massimo Banzi

Nella figura successiva Arduino è collegato a un display a cristalli liquidi. L'oggetto bianco bucherellato si chiama breadboard e serve a realizzare rapidamente circuiti elettronici senza dover saldare nulla. In altre parole serve a fare prototitpi per sperimentare nella realtà se un'idea funziona. Una volta che un progetto è stato perfezionato, si può provvedere a realizzare un circuito opportunamente saldato. Le breadboard sono molto utili nei contesti didattici dove l'obiettivo è sperimentare piuttosto che produrre oggetti finiti pronti per la produzione. Altri esempi e considerazioni a riguardo possono essere trovati nell'articolo La rivoluzione digitale e il sogno di Adriano Olivetti

Il no pronunciato da Massimo Banzi è riferito al modello convenzionale di produzione industriale, rinunciando alla proprietà individuale assoluta. A posteriori sembra sempre tutto facile. Invece ci vuole molto coraggio per prendere decisioni del genere, oltre ad avere una visione proiettata nel futuro.

Arduino

Ushahidi (crowdmaps...)

Prima perdiamoci un attimo in questo sorriso...

Ory Okolloh

Ory Okolloh si è laureata in legge a Harward ma era cresciuta in una povera famiglia di un villaggio in Kenia. È arrivata a quel risultato grazie alla bravura e alla tenacia. Ma al momento di essere assunta in un grande studio legale americano ha rinunciato per tornare nel suo Paese e lavorare lì: un no clamoroso. Laureata in legge, quindi, ma questo non le ha impedito di contribuire a dar vita a un progetto prettamente tecnologico, anche se destinato a impieghi sociali. Quando nel 2007, in seguito alle elezioni presidenziali, in Kenya divampò una stagione di violenza, Ory Okolloh ispirò la creazione di Ushahidi (che nella lingua Swahili significa "testimonianza"): un sistema web che consente di raccogliere testimonianze di episodi di violenza inviando SMS che si traducono in segnalazioni collocate in Google Maps. È così che sono nate le ben note crowdmaps. Il sistema Ushahidi ha avuto un successo strepitoso perché negli anni successivi è stato utilizzato in un gran numero di eventi calamitosi. Per esempio, in occasione del terribile terremoto di Haiti del 2010 (magnitudo Mercalli 7), Ushahidi fu l'unica cosa che funzionava. In sostanza, un gruppo di studenti dell'università di Boston riceveva via Skype informazioni sulla localizzazione di siti critici da un gruppo di volontari che, da un gazebo nei pressi dell'aeroporto di Port-au-Prince, capitale di Haiti, raccoglievano testimonianze verbali sulla localizzazione di siti critici, probabile presenza di persone sepolte ecc. Tramite tutti i mezzi possibili, Twitter e altri canali, le informazioni venivano diffuse nel Web e quando qualcuno dava informazioni utili a definire esattamente le coordinate geografiche dei siti queste venivano segnalate sulla crowdmap e trasmesse alle unità di soccorso. Ebbene, Ushahidi è stato realizzato con software libero. Chiunque lo può scaricare dal repositorio Github di software libero per installarlo su un proprio server. Alternativamente si può usare il servizio Web il servizio web gestito dal team Ushahidi con una varietà di piani di pagamento. Questo è un grande esempio di condivisione basato sul modello del software libero in un contesto di grande utilità sociale.

Sono innumerevoli i progetti basati su software libero. Accenno qui solo a due esempi che ho potuto sperimentare in vari contesti didattici: la PirateBox e il computer Kano.

PirateBox

La PirateBox è un piccolo dispositivo che consente di distribuire contenuti nell'arco di una rete wireless che si estende per alcune decine di metri. È costituita da dispositivi hardware economici nei quali viene montato una particolare versione del sistema operativo Linux. Si tratta di dispositivi in grado di produrre una rete wireless locale. I contenuti vengono messi in una semplice chiavetta USB. I vantaggi stanno nella possibilità di distribuire contenuti in assenza di Internet oppure laddove si preferisce essere sconnessi per motivi di sicurezza. In questa pagina si possono trovare altre informazioni su un'iniziativa tesa alla sperimentazione delle PirateBox a scuola. La cosa che vogliamo mettere in evidenza qui è il fatto che la funzionalità della PirateBox è resa possibile dall'adattamento del sistema operativo Linux realizzato da un team di sviluppatori di software libero. Sono persone che svolgono questo tipo di attività nel tempo libero. In particolare, l'artefice principale, Mattias Strubel, lavora presso una software house ma lavora al progetto PirateBox a titolo personale, semplicemente perché crede che sia una cosa giusta, e perchè si diverte...

Il team PirateBox - Matthias Strubel

Kano, un microcomputer per la didattica basato su Raspberry PI

Kanō Jigorō (嘉納 治五郎) è il padre del Judo, l'arte marziale "arte delle cedevolezza": batti l'avversario usando la sua medesima forza e il tuo minimo sforzo. Kanō Jigorō aveva anche creato un'accademia, in ... , con il seguente motto: "Maximum Efficiency with Minimum Effort, Mutual Welfare and Benefit": massima efficenza con il minimo sforzo, aiuto e beneficio reciproco. Una notazione tecnica e una etica, che allude ad un'ideqa di comunità. Qualcosa che ricorda da vicino le libertà di Stallman. È proprio questa suggestione che un team di giovani e intraprendenti sviluppatori software ha scelto per dare il nome alla loro idea: Kano, un computer economico che possa essere montato da un bambino, per imparare "come è fatto dentro" e soprattutto per imparare a comandarlo, mediante il codice. Kano è basato su un compenente base anch'esso pensato per essere usato i contesti didattici. Si tratta della scheda Raspberry PI. Una scheda di dimensioni appena più grandi di quelle di Arduino, dotato di tutti gli apparati interni e le connessioni che caratterizzano i computer più grandi. Come memoria fissa (tipo disco rigido) usa una scheda di memoria SD sulla quale possono essere installate alcune varianti del sistema operativo Linux. Al minimo, la scheda Raspberry può essere utilizzata collegando una tastiera, un mouse (questi via USB), un video (HDMI). Poi ci si può collegare a Internet collegando un classico cavo Ethernet, oppure mediante una chiavetta USB wireless. Inoltre la scheda è dotata di una connessione alla quale si possono collegare svariati attuatori e sensori elettronici, come si fa con Arduino. Il costo è basso, intorno ad alcune decine di Euro ed è incredibile la varietà di cose che ci si possono fare. Ho un amico che ci ha realizzato il server di una biblioteca. Kano è costruito intorno alla scheda Raspberry ma viene proposto in un kit fatto di componenti colorati che facilitano il montaggio da parte di bambini più piccoli e anche l'opera di assistenza da parte di insegnanti non particolarmente ferrati in questioni tecnologiche, come è ovviamente la norma. In termini molto generali, si può dire che Kano si presta a essere introdotto in un contesto di scuola primaria mentre le attività basate direttamente sulla scheda Raspberry sono più adatte al contesto di una scuola secondaria.

L'emergenza di Kano è stata fulminante: in una campagna di kickstarting) iniziata in novembre 2013, il team Kano raccolse più di 1.5 milioni di dollari, una cifra che rese possibile la realizzazione industriale dell'idea. Perché le kicksarter campaign consistono proprio in questo: tu hai un'idea, la piazzi in http://www.kickstrater.com e aspetti che la gente se ne innamori e ti faccia un'offerta. Il modello di business escogitato dal team Kano è molto interessante. Il loro kit si compra, e costa 200 €, mentre la scheda su cui si basa è la Raspberry PI, che costa circa 60 €. Il package completo comprende la scheda Raspberry, una tastiera apposita, una scheda di memoria SD con il sistema operativo installato, una chiavetta usb per il collegamento Internet wireless, il case (involucro) per contenere il tutto, un altoparlante per l'audio, i cavi per collegare monitor, audio, internet, alimentazione elettrica, l'alimentatore. Ma il kit comprende anche il software che fornisce tutte le funzionalità peculiari del sistema Kano. Ebbene, questo viene rilasciato con licenza di software libero. In particolare, questo sistema operativo, che si chiama Kanux, è una variazione del sistema Raspbian (specializzato per le schede Raspberry) che è a sua volta una variazione della distribuzione Debian di Linux. Se da un lato si può acquistare il kit sul sito principale: kano.me, dall'altro è possibile scaricare il software dal sito riservato agli sviluppatori, copiarlo su una scheda di memoria SD e utilizzare una qualsiasi scheda Raspberry. Come si vede è un approccio misto, dove la produzione industriale classica viene contaminata da un modello di condivisione di certe parti del prodotto, in particolare quelle caratterizzate da un più elevato valore di proprietà intellettuale. Dal punto di vista dell'utente interessato alle applicazioni in contesti didattici, si rende disponibile una interessante varietà di opzioni che vanno dall'acquisto del kit completo che può essere usato più facilmente e in particolare con i bambini più piccoli, a soluzioni ancora più del tipo do-it-yourself, dove con una scheda Raspberry, materiale di recupero e il software scaricato si realizza un sistema equivalente, adatto per ragazzi di età maggiore.

Il team Kano - Yonatan Raz-Fridman and Alex Klein