Codice e società/Capitolo 2/1
 |
Questo testo è completo. | |
| ◄ | Capitolo 2 | Capitolo 2 - 2 | ► |
La caratteristica principale del codice libero, che giustifica la nostra attenzione nei suoi confronti, risiede nel fatto che si tratta di un'entità, organizzata per algoritmi – parti di codice che eseguono funzioni o producono effetti coerenti con il contesto applicativo in cui sono inseriti – e che costituisce degli artefatti che connotano socialmente la rete. Anche le immagini, i programmi chiusi, i video clip, i testi e quant'altro sono artefatti collocati nella rete: ma il codice libero è un artefatto costruito nella rete, che sottende relazioni che vivono e si sviluppano nella rete anche senza momenti di compresenza.
Questa è una peculiarità, in mancanza di altri riscontri, esclusiva del codice libero. Un romanzo parimenti potrebbe essere scritto a più mani sulla rete, ma non a così tante mani. Wikipedia raccoglie gli sforzi di milioni di volontari che implementano notizie e informazioni, ma si tratta alla fine di una grossa base dati, di un “repositorio” in termini informatici, che viene scritto e riscritto in continuazione ma non costruito. Ciò che viene scritto e modificato sulla pagina dedicata alla rivoluzione francese non condiziona ciò che sta scritto nella pagina dedicata al DNA. Nel codice informatico le cose stanno diversamente: quando si modifica una parte del codice la coerenza globale di tutto il progetto deve essere ri-verificata. Ciononostante, Wikipedia è ciò che più si avvicina al codice libero senza essere codice libero.
Questa dimensione della costruzione è ciò che spiega come le relazioni caratterizzate dal codice libero riescono ad auto-sostenersi fuori dalla compresenza. Abbiamo già visto quanto sia pressante avere macchine che funzionino e come l'esperienza, anche della nostra quotidianità, dimostri che non ci sono garanzie.
Negli anni '70 del '900 era abbastanza normale acquistare macchine costose e poco affidabili e ciò lo si comprende se si tiene conto di alcuni aspetti:
- Chi acquista queste macchine si trova alla frontiera della tecnologia, come le università o il ministero della difesa americano.
- Per le università si tratta, oltre che di un rischio, di un'opportunità. I vari dipartimenti hanno possibilità di fare ricerca in questo specifico campo e ciò che vi è in palio è la possibilità di definire degli standard e costituire successivamente dei passaggi obbligati (Lotour, 1987).
- Questi soggetti intravedono potenzialità che altri non vedono, perché diversamente da altri trattano dati massivi e sono alla continua ricerca di due cose: capacità di calcolo e capacità di trasmissione dei dati.
- Il rischio viene assorbito allargando la rete. Diviene quasi una necessità collaborare apertamente.
- La necessità di apertura è proporzionale al rischio.
La questione del codice aperto con il suo peso socio-economico, che si manifesta nelle forme istituzionalizzate come l'Open Source e il Software Libero, emerge in questo preciso momento storico. La chiusura dovrebbe in questo momento decretare dei vincitori accademici, come l'Università di Berkeley che diviene un punto di riferimento per i sistemi operativi basati su Unix; governativi, come il il ministero della Difesa USA che mette in produzione il suo progetto ARPANET precursore di Internet; attori economici, come l'AT&T che vende versioni proprietarie del sistema Unix dopo anni di investimenti.
La rete di collaborazione a questo punto dovrebbe esaurire la sue funzioni, si tratta semmai di migliorare quanto è consolidato ed ognuno può farlo per proprio conto. Cioè i ridotti margini di azione ulteriore e il venir meno del rischio spostano l'attenzione dalle relazioni ai nodi e quindi al mercato. La partita si sposta dallo spazio pubblico allo spazio privato.
Questa dinamica protesa alla chiusura si verifica oltre che a livello generale, anche a livello di specifici progetti di sviluppo. Chi sviluppa codice si trova spesso a fornire un semilavorato su cui il committente farà delle considerazioni e chiederà ulteriori modifiche. Il prodotto rimbalza continuamente tra prove e ulteriori implementazioni finché non si giunge a un sistema soddisfacente: si tratta di un modo di procedere definito dalla manualistica “metodo evoluzionistico” (Sommerville, 2005), che costituisce la regola più che l'eccezione. Quando infine si arriva a un prodotto stabilizzato ed esaustivo, viene meno la necessità delle relazioni che l'hanno reso possibile.
Chi ha esperienza di questo modo di procedere sa che il raggiungimento dell'obiettivo coinciderà con la fine del progetto e la fine delle relazioni implicate in questo processo. A quel punto il committente avrà il sistema funzionante, mentre il soggetto che ha sviluppato il sistema si troverà a possedere un sistema che tenterà di vendere nel mercato. Qual è la differenza sostanziale tra il primo committente che partecipa attivamente alla costruzione del sistema ed il secondo soggetto che acquista lo stesso sistema nel mercato? In primo luogo il tipo di relazioni: nel primo caso si tratta per il committente di contribuire con le proprie idee e le proprie specifiche conoscenze alla costruzione di un sistema; nel secondo caso si tratta di un agente economico che negozia sul mercato il prezzo e le condizioni di utilizzo di quel sistema informatico. In altre parole: nel primo caso si tratta di collaborare, nel secondo caso si tratta di negoziare e comprare.
Si aggiunga a ciò il fatto che in un processo di questo tipo l'informatica, sotto forma di codice, assorbe conoscenze specialistiche da altri settori che vengono non solo automatizzate ma anche chiuse e protette da copyright. Chi ha comunicato quelle conoscenze, assorbite poi dal software, si accontenterà della loro automazione ma non potrà rivendicare alcun diritto futuro. Eppure quelle conoscenze sono ciò che da senso allo strumento informatico: Il software celebra se stesso a spese di altri.
Proiettando queste dinamiche a livello macroscopico, e complicando lo scenario, avremo nel primo caso una serie di soggetti, come università, agenzie governative, istituti di ricerca che collaborano tra loro con il supporto di programmatori (studenti, dipendenti delle stesse istituzioni, oppure free-lance) per costruire sistemi informativi statistici, sistemi informativi territoriali, fogli di calcolo, editor vettoriali per la biologia, la geofisica o l'architettura; nel secondo caso avremo soggetti non in relazione tra loro che acquistano, indipendentemente gli uni dagli altri e nel mercato, quegli stessi prodotti a un determinato prezzo. In questo secondo caso vengono meno le relazioni tra i diversi soggetti e restano solo le relazioni commerciali tra chi vende e chi compra. Chi vende avrà molte relazioni con i vari acquirenti, ma gli acquirenti avranno una sola relazione con chi vende. Mentre in una prima fase i diversi utilizzatori di informatica sono in relazione tra loro, in una seconda fase questi sono isolati. La struttura del network diventa da reticolare a satellitare, con un unico passaggio obbligato (Latour, 1987) o nodo di accesso a quello specifico sapere esperto (Giddens, 1994) assorbito dal software.
Il passaggio obbligato viene costruito su due livelli: aggregare gli attori umani da un lato e aggregare gli attori non umani dall'altro. Aggregare gli attori significa comprendere il rapporto che lega le loro competenze ai loro problemi. Questo rapporto racchiude le strategie che gli attori umani usano per risolvere i loro problemi e svolgere le loro attività. L'idea è quella di raggruppare questi attori per categorie di problemi e attività, e quindi frapporre idealmente tra queste categorie di problemi e gli attori che ne sono portatori un black box che si occuperà di automatizzare le soluzioni.
Nessuno settore della società usa il termine “soluzione” in modo così esteso e pregnante come lo usa il mercato informatico. Il black box è a sua volta un aggregato di prototipi che nasconde i meccanismi e mostra solo gli effetti. In questo modo gli attori convocati si abitueranno a pensare alla loro attività in termini di strumento. Le competenze non saranno più quelle che legano l'agire alla categoria di problemi tipiche del proprio ruolo, ma saranno quelle che legheranno l'agire alla soluzione informatica. Il progettista non sarà più colui che fa progetti, ma colui che usa un CAD1, lo statistico colui che usa SPSS2, il tornitore colui che usa un CAM3, l'urbanista colui che usa un GIS4. I meccanismi con cui questi strumenti gestiranno la grafica vettoriale, le basi dati relazionali, l'accesso in scrittura e lettura al file system e via dicendo, sarà oscurato e reso ancor più opaco dal linguaggio esoterico che anche noi poc'anzi abbiamo usato. L'urbanista non penserà più solo e semplicemente alla mappa del territorio, ma penserà alla quantità di memoria e al tipo di processore necessario a far funzionare al meglio la sua soluzione informatica. In questo modo viene riconfigurato il focus attentivo e i nostri attori umani non riusciranno più a pensare al lavoro disgiunto da quelle “soluzioni”: il passaggio obbligato ha avuto successo.
Ma ci si può spingere anche oltre, come suggerisce Latour (1987, p. 175): si può fare in modo che per svolgere la propria attività sia obbligatorio usare determinate “soluzioni”, ad esempio con l'immissione nel mercato di macchine equipaggiate con “secure boot loader”, cioè in grado di distinguere sistemi operativi approvati da Microsoft. In questo modo non sarà più possibile separare l'hardware dal software, il computer sarà un pezzo unico, non sarà possibile comprare un computer in un posto e il sistema operativo in un altro, tutti i componenti saranno solidali tra loro e fungeranno da
[…] ispettori, supervisori, controllori, analisti e informatori, al fine di tenere in riga le forze assemblate: significherebbe un’ulteriore confusione dei limiti; vorrebbe dire attribuire alla natura le tattiche sociali (Latour, 1987, p. 175).
In sostanza, la tecnologia e i saperi esperti prima “contenuti” nelle relazioni vengono “assorbiti” dai nodi che deterranno i diritti di distribuirli sotto forma di tecnologia confezionata e pronta all'uso. Non solo, questi nodi, almeno potenzialmente, proprio per la struttura morfologica della rete, diventeranno intermediari per i diversi soggetti in campo, i quali, perdendo il controllo della tecnologia e non potendola più modificare, saranno costretti a darsi assetti organizzativi uniformi e compatibili con la tecnologia “unica” che viene distribuita. Non saranno più le esigenze organizzative a determinare il modo di funzionamento degli strumenti, ma sarà la tecnologia ad esigere specifici assetti organizzativi: si tratta di un processo di omologazione. In sintesi pochi nodi assorbono tutto il controllo sulla tecnologia, le relazioni diminuiscono in senso quantitativo e da reticolari diventano radiali come i raggi di una ruota di bicicletta.
Tutto questo non è estraneo a quelle forme di assunzione di funzioni governative da parte delle software house (Cfr. Cap. I paragrafo 2). Come rileva Neelie Kroes5 nel luglio del 2010, le autorità governative non hanno possibilità di uscita (exit) e nemmeno voci in capitolo (voice) per modificare il funzionamento della soluzione (Hirschman, 1970), rispetto a scelte tecnologiche effettuate anche decenni prima. Si tratta del cosiddetto lock-in, per cui nel medio e breve periodo il costo di uscita da una tecnologia, eventualmente inadeguata ai continui cambiamenti e trasformazioni della pubblica amministrazione, diviene molto elevato. Il costo non si concentra sull'acquisizione di nuova tecnologia ma sull'abbandono di quella vecchia: questi passaggi obbligati hanno raggiunto un altissimo grado di consolidamento e specializzazione. La specializzazione non ha a che fare con la qualità della tecnologia, ma con il fatto che questi passaggi obbligati hanno conformato l'ambiente in cui si trovano e sono divenuti solidali con gli stessi.
Nello specifico informatico, man mano che la tecnologia si consolida e diviene pronta all'uso (Latour, 1987), si passa dal network di produzione alla catena di distribuzione. Questo passaggio implica, oltre alla forma diversa, anche una differenza quantitativa sostanziale. Gli utenti saranno, o si sentiranno, costretti a rivolgersi a quell'unico nodo, ma saranno tra loro isolati. Se sarà un unico soggetto a potersi relazionare con tutti gli altri verranno meno le relazioni tra i diversi utenti. Dal punto di vista qualitativo ciò che cambia è la partecipazione alla costruzione. Quando la tecnologia si sposta nello spazio privato, chi acquista la tecnologia diventa un cliente, dal punto di vista commerciale, ed un utente, dal punto di vista informatico, e, in entrambi i casi, ha ridotte possibilità di apportare anche minime personalizzazioni.
Nel frattempo i programmatori saranno stati assunti dalla software house che detiene i diritti e i brevetti, oppure avranno assunto ruoli diversi all'interno della propria istituzione: in ogni caso quei soggetti che prima partecipavano attivamente alla costruzione della tecnologia avranno perso la capacità di controllarla o modificarla. Si tratta di un processo lungo il quale le competenze vengono spostate nei nodi, e se non vengono spostate nei nodi, vengono riconfigurate. È ciò che spesso viene chiamato outsourcing, e invocato come forma di razionalizzazione.
L'idea è sempre la stessa, quella della costruzione della scatola nera che rappresenta la scienza pronta all'uso. Per riuscire in questo intento è necessario aggregare attori umani e non umani attorno a dei specifici nodi. L'outsourcing ha esattamente questo significato: togliere competenze e mezzi dalle relazioni per concentrarle nei nodi. Nel contempo si tratta anche di una deviazione strategica (Latour, 1987). L'outsourcing viene presentato come necessario alla razionalizzazione e all'efficienza, contro i rischi legati alla complessità. La storia di Unix mostra come il rischio legato alla complessità venga affrontato dagli attori degli anni '70 del '900 allargando la rete. La strategia della deviazione inverte questa logica facendo intravedere un rischio tanto maggiore quanto più ci si affida alla rete piuttosto che al mercato.
Le scatole nere e i passaggi obbligati sono gli esiti dell'informatica pronta all'uso. L'informatica fatta “soluzione” diventa un package deal da prendere o lasciare. Non se ne possono prendere alcune parti e lasciarne altre; prendere alcune parti e costruirne altre; oppure modificare ciò che si acquista.
Le cose però non stanno sempre così. Non tutti nel contesto informatico sono così interessati al fatto che si prema un tasto e che al resto ci pensino le scatole nere e chi le costruisce. L'informatica è diversa dalla fotografia, perché si tratta di macchine multi-tasking, complesse, che comunicano tra loro. La strategia industriale della Kodak viene messa a dura prova in questo settore, anche se non si può negare che in vasti settori dell'IT tale strategia sia continuamente perseguita ed abbia ottenuto indubbi successi.
Spesso l'informatica viene presentata come necessariamente complessa e indefinita, come lo è linguaggio informatico PERL, poiché anche l'universo è complesso, ma lo è a ragion veduta (Larry Wall, 2000). Vi è sempre nella scienza un rumore, un qualcosa di caotico da cui estrarre qualcosa di ordinato attraverso il linguaggio della natura6. Tutto ciò non è molto diverso da quanto afferma Larry Wall7 e cioè:
[…] Evidence abounds that people continue to oversimplify today. Some people prefer to oversimplify their cosmology. Others prefer to oversimplify their theology. Many computer language designers oversimplify their languages, and end up sweeping the universe's complexity under the carpet of the programmer. (Larry Wall, 2000)
Esiste una consapevolezza informatica di tipo critico che problematizza un'idea di tecnologia ordinata. Lo stesso titolo del libro di Eric Steven Raymond (1997)8, The Cathedral and the Baazar evidenzia questa dimensione.
Per queste ragioni la rete mostra una sua resistenza e persistenza nel passaggio dallo spazio pubblico allo spazio privato. Nello spazio pubblico restano dei residui impossibili da appropriare (aggregare e disciplinare direbbe Latour), perché la complessità e la stratificazione impediscono di individuare in modo univoco degli autori. Il Software Libero Open Source come bene pubblico si consolida come precipitato di relazioni complesse. Di per sé, esso si afferma in modo residuale rispetto a ciò che non può essere appropriato perché, a seguito della sua complessità e della numerosità dei suoi contributi, non è riconducibile a un autore individuale.
Da un punto di vista sociologico emerge come effetto perverso. Nonostante, una volta terminata la collaborazione tra Berkeley, la AT&T e il ministero della difesa USA, inizino le controversie per i diritti sul codice, non tutto il codice viene appropriato dal mercato (Weber, 2004). Una parte della tecnologia Unix resta in mano alle università, in particolare Berkeley che lo distribuisce liberamente come BSD9. I protocolli di ARPANET restano pubblici e mantenuti dalla Internet Society che è una società senza scopi di lucro.
Ma ciò che rimane sono le relazioni in quanto tali, cioè il capitale sociale già attivato sulla base di progetti, aspettative e visioni del mondo condivise. In quanto già attivato (Coleman, 2005) e disponibile, questo capitale sociale è in grado di continuare a essere operativo e a cooptare nuove leve (Weber, 2004). Si tratta di una rete che continua a fare ciò che ha sempre fatto con ciò che gli resta: una rete internet, tutto sommato pubblica, e pezzi di sistemi operativi funzionanti. La rete continua a funzionare e a fare ciò che ha sempre fatto, ricostruendosi i pezzi che il mercato si è portato via. Questa ricostruzione avviene di continuo, soprattutto perché c'è già una rete, ma anche perché questa rete è impregnata di codice e di competenze.
La rete è in definitiva uno spazio pubblico costruito allo scopo di produrre tecnologia in condizioni di incertezza. Riesce a mobilitare fiducia perché riesce a comunicare l'esperienza attraverso il codice, e lo può fare anche in condizioni di non compresenza: è talmente vero il codice che si trova nella rete che, oltre a funzionare, lo si può anche manipolare e modificare per fargli fare cose diverse, percepite come necessarie. Inoltre, così come la chiusura (v. introduzione), anche la fiducia è giocata sulla velocità: in questo specifico ambito tecnologico dove la velocità è percepita come fondamentale, la compresenza è troppo lenta per riuscire a veicolare fiducia.
In rete vi sono molti siti di auto-aiuto per programmatori: il fatto di riuscire a risolvere problemi complessi grazie all'aiuto di migliaia di altri programmatori in tempi brevissimi è un'esperienza che compensa la non compresenza. La concretezza sta nel fatto che i problemi vengono realmente risolti in tempi rapidissimi.
Note
- ↑ Computer Aided Design
- ↑ Statistical Packege for Social Science
- ↑ Computer Aided Manifactured
- ↑ Geographical Information System
- ↑ Commissario europeo per l'agenda digitale.
- ↑ Laboratory Life: The Social Construction of Scientific Facts
- ↑ Programmatore statunitense Iniziatore del linguaggio PERL e sostenitore del Software Libero.
- ↑ Fondatore nel 1997 dell'Open Source Defination che diverge dalla Free Software Foundation fondata da Stallman nel 1985.
- ↑ Berkeley Software Distribution.