# Codice e società/Capitolo 3/3

../../Capitolo 3/2 ../../Capitolo 4 IncludiIntestazione 10 giugno 2013 75% Tesi universitarie
Codice e società Stefano De Boni 2013 CC BY-SA 3.0 GFDL //it.wikisource.org/w/index.php?title=Codice_e_societ%C3%A0/Capitolo_3/3&oldid=- 20231224193207 //it.wikisource.org/w/index.php?title=Codice_e_societ%C3%A0/Capitolo_3/3&oldid=- 20231224193207
Se il nostro oggetto di osservazione è il codice, in particolare quello libero, da un punto di vista economico questo deve assumere il significato di risorsa. Dobbiamo quindi cercare i meccanismi che allocano tale risorsa, e quali sono gli agenti economici che, quotidianamente col loro agire “razionale”, allocano tali risorse. Anche da questa prospettiva il punto di partenza di molte ricerche empiriche sono i paradossi, il più utilizzato dei quali è il sistema di incentivi. Il paradigma messo sotto osservazione, e in discussione, è in questo caso la “teoria della scelta pubblica di Olson”, per la quale chi agisce nello spazio pubblico è orientato a massimizzare il profitto personale come qualsiasi altro attore economico che si muove nel mercato. In pratica stabilisce che i criteri che guidano l'azione pubblica sono gli stessi che guidano gli interessi privati.
Ci troviamo invece di fronte a programmatori che, dopo aver speso molto tempo e risorse per produrre codice, lo distribuiscono gratuitamente. Sono quindi attori che contraddicono doppiamente la "teoria della scelta pubblica”: non si tratta di soggetti che agiscono nello spazio pubblico per produrre beni privati, ma di attori che agiscono nello spazio privato per produrre beni pubblici. La teoria della scelta pubblica implica poi che più grande è il gruppo, minori sono i vantaggi complessivi. Questo aspetto risulta coerente anche con la legge di Brooks, per cui team troppo grandi di sviluppo sarebbero poco efficaci per il raggiungimento degli obiettivi. In definitiva, nel caso del Software Libero e Open Source ci troviamo di fronte a situazioni estreme di gruppi molto ampi, spesso dell'ordine di qualche migliaio, come per la comunità Debian, che utilizzano mezzi privati per fornire dei beni pubblici.
La ricerca sul Software Libero e Open Source ricorre ad altre ricerche sull'economia industriale (Rosemberg 1976, von Hipel 1988), basate sul ruolo giocato da utenti avanzati nel progresso tecnologico. Altre spiegazioni riguardano la prospettiva di carriera (Lerner e Tirole 2002), la desiderabilità sociale e la dimensione reputazionale in genere. Questi aspetti, spesso coesistenti tra loro, vanno sotto il nome signaling incentive (Holmström 1999), che costituiscono delle motivazioni maggiori che non la semplice ricompensa per la prestazione. La visibilità, e quindi il pubblico, hanno un ruolo determinante e sono componenti essenziali in quella che viene chiamata “complementarità strategica”. Così, mentre il programmatore che sviluppa software proprietario investe sul breve termine, il programmatore Open Source investe sul lungo termine.
Queste spiegazioni riescono a mantenere una buona coerenza con le implicazioni a livello macro di come vengono allocate le risorse. In pratica nel mercato non si scambia tanto il software, quanto piuttosto le competenze. Un programmatore può non essere interessato a tenere nascosto il codice perché si guadagna da vivere attraverso prestazioni. È una questione, ancora una volta, di punti di vista. Vi sono programmatori che ritengono di poter curare meglio i propri interessi distribuendo codice, e programmatori che ritengono di doverlo tenere nascosto:
[…] Sto scrivendo un'applicazione che si basa fortemente su javascript. Il javascript usa un programma ospite della pagina per funzionare come [socket bridge]. Tuttavia. Se qualcuno volesse rubare il codice javascript che ho scritto, violerebbe le norme sul diritto d'autore? Servirebbe se mettessi una clausola all'inizio del file Js? (user188189, 12 ottobre 2009, http://stackoverflow.com)
[…] Io non mi preoccupo che qualcuno possa rubare il mio codice. Io campo fornendo servizi ai miei clienti, il software è giusto un mezzo a questo scopo. E, se devo essere molto sincero, non dubito che qualcuno potrebbe fare versioni migliori di quelle che sviluppo. Buona fortuna. Piuttosto spenderei il mio tempo per soddisfare i miei clienti. (paxdiablo, 12 ottobre 2009, http://stackoverflow.com)
Vi sono infine programmatori che pensano che oltre a non dover tenere segreto il codice, sia vantaggioso distribuirlo perchè così si aumenta il capitale sociale, e qundi la possibilità di ottenere delle commesse. Per Krishnamurthy (2005) le competenze nei contesti Open Source offrono migliori possibilità di carriera e di opportunità.
Altre ragioni possono essere ricercate nel tipo di economia che vogliamo assumere come esplicativa. Si può trattare di allocare risorse scarse, come nel caso del software proprietario, oppure di risorse abbondanti come nel caso del codice Open Source (Berra 2001). In questo caso la spiegazione starebbe nella solidarietà (meccanica - ndr) che sottende gli scambi in condizioni di abbondanza (Berra 2001). Vi sono quindi diversi livelli esplicativi: economia formale del software proprietario ed economia informale del codice libero; risorse scarse del software proprietario allocate con la legge della domanda e dell'offerta e risorse abbondanti del codice libero allocate attraverso il “dono” (Hagstrom, 1965); mercato delle licenze nel software proprietario e mercato delle competenze nel codice libero; chi agisce nel mercato del software proprietario fa investimenti a breve termine, chi agisce nel mercato del codice libero investe a lungo termine (complementarità strategica); interesse privato del software proprietario e bene pubblico del codice libero; produzione industriale del software proprietario e riproduzione sociale del codice libero, ad esempio attraverso quello che Lerner e Tirole (2002) chiamano Alumni effect:
[…] Il movimento open source è vasto e diversificato. Tuttavia pur essendo difficile fare generalizzazioni, ci sono molte pratiche comuni che possono essere individuate in molti progetti open source. Queste pratiche lasciano il loro segno nel software prodotto. In particolare, gli strumenti software più usati nell'ingegneria di tipo open source sono il risultato di queste pratiche, e come tali incorporano il proprio supporto rinforzando ulteriormente le loro pratiche tipiche. (Jason E. Robbins 2003)
In sintesi:
Il fatto di tenere assieme queste apparenti contraddizioni in un unico modello tematico, che intreccia software proprietario e codice libero come le due facce della stessa medaglia, permette di rendere conto della complessità dialogica in cui queste dimensioni coesistono. Si pensi come, ad esempio, lo stesso Polany (1977) sostenga che l'economia formale non sia autonoma e non possa sussistere senza una qualche economia sostanziale. E’ esattamente quello che si verifica nel campo informatico. Anche per il mercato informatico il dilemma non è mai se chiudere o non chiudere, ma quanto chiudere e quanto lasciare aperto al virtuosismo informale e sostanziale.
La AT&T, in una prima fase, lascia circolare le annotazioni “pedagogiche” del suo sistema Unix, che si diffondono nelle università, sfruttando il cosiddetto “alumni effect” (Lerner e Tirole, 2002). Una volta che tale sistema si è diffuso e consolidato, grazie anche alla ricerca universitaria, e lo scopo viene raggiunto, diviene conveniente chiudere la “scatola”.
La pratica di rivelare apertamente, anche se selettivamente, la tecnologia dei semiconduttori da parte di IBM ha lo scopo di fissare uno standard che consenta l'espansione di un mercato dove la stessa IBM mantiene la sua centralità (Lim 2000 – Harhoff 1996). Si tratta di pianificare quelli che Latour (1987) chiama passaggi obbligati. La rivelazione assume il significato di stabilire uno standard che devii l'attenzione da altri possibili esiti. Il meccanico che costruisce il mulino a vento deve far dimenticare il mortaio al contadino e deve fare in modo che questi si abitui all'idea del mulino (Latour, 1987). Per IBM si tratta di rivelare ad altri la tecnologia per produrre innovativi semiconduttori di rame, in alternativa a quelli tradizionali di alluminio, in modo che questi diventino uno standard. Poiché questa nuova tecnologia sarà utilizzabile solo da IBM, la stessa IBM ha tutto l'interesse affinché i fornitori di semiconduttori costruiscano componenti che sono impiegati solo da IBM. Allo stesso tempo IBM non ha le infrastrutture per costruire semiconduttori su larga scala: la rivelazione della tecnologia ha consentito quindi, nel contempo, di consolidare alleanza selettive con apparati industriali, che diversamente avrebbero potuto diventare suoi diretti concorrenti.
Allo stesso modo l'AT&T sfrutta l'alumni effect (Lerner e Tirole, 2003) rivelando parti di codice, ottenendo un doppio effetto: da un lato costituisce un presupposto per ricevere i contributi della ricerca per il suo miglioramento, e dall'altro abitua gli studenti universitari a “pensare in Unix”. Quando il “pensiero Unix” si sarà consolidato e la tecnologia pure, il passaggio obbligato sarà una realtà e diventerà più conveniente oscurare la tecnologia. Storicamente il pensiero Unix è diventato talmente reale che tutti i principali sistemi operativi Open Source che nasceranno più avanti saranno (in gergo informatico) “Unix-like”. Ciò significa che le istruzioni (da linea di comando, in gergo informatico) sono identiche per FreeBSD, Linux e MINIX. Gli standard, da questo punto di vista, possono considerarsi tracce di passaggi obbligati, passati o attuali, realizzati con successo.
Guardando questi fatti nella prospettiva di Latour (1987), la rivelazione ha lo scopo di abituare a uno standard e creare delle alleanze. Forme iniziali di apertura hanno lo scopo di creare modi di pensare e alleanze, e dipendono dal contesto e dal momento storico in cui si verificano. Unix nasce in un momento storico in cui la tecnologia è molto “incerta” e necessita di condividere il rischio con la società. La stessa cosa non avviene con Microsoft, che si diffonde grazie a macchine di nuova concezione, meno costose e più affidabili, destinate al largo consumo. In un secondo momento si deve fare in modo che venga vietato macinare il grano in casa (Latour, 1987, p. 175): è quanto si verifica nel 2010, quando i produttori di computer annunciano l'immissione nel mercato di macchine equipaggiate con “secure boot loader”, cioè in grado di distinguere sistemi operativi certificati da Microsoft. Il boot loader può essere disattivato facilmente, com’è assicurato ai fornitori di sistemi operativi diversi da quelli Microsoft, e potrebbe essere fatto con tutta tranquillità, se non fosse per quel prefisso “secure” che prospetta la rinuncia alla sicurezza. In secondo luogo, anche altri produttori di sistemi operativi possono ottenere il certificato e quindi la chiave da Microsoft, ma proprio di questo si tratta: costruttori di computer e produttori di sistemi operativi devono “passare” tutti per Redmond. Si è sempre meno autorizzati a macinare in casa, sia che si tratti grano, sia che si tratti di codice.
Sul piano individuale, all'interno della stessa opzione di divulgare pubblicamente il proprio codice, vi è la soddisfazione di un bisogno di desiderabilità sociale, di appartenenza e di identità, di costruzione di opportunità future, di riscontro delle proprie competenze e quindi di gratificazione intellettuale, che non sono alternative a norme morali derivanti da valori sociali di cui ci si sente portatori. Sul piano economico il mercato può riguardare le licenze, cioè la proprietà intellettuale e i brevetti, piuttosto che le competenze. In particolare nel campo dell'informatica competenze e conoscenze sembrano non viaggiare assieme, sono scambiati in piazze diverse, anche se talora queste piazze sono connesse da “vie di comunicazione”, peraltro molto trafficate, cioè relazioni che si vedranno meglio quando si tratterà di mappare le controversie. Si può, ad esempio, anticipare il fatto che molto software proprietario e chiuso viene sviluppato a partire da codice Open Source.
Le contraddizioni riguardano inoltre il discorso sulla “paternità individuale” (Bucchi, 2010, p. 164) di una scoperta in cui i ruoli tra software proprietario e Software Libero Open Source sembrano invertirsi. L'informatica nasce in epoca relativamente recente quando ”l'ideologia eroica”, che inizia ad affermarsi nella seconda metà del 1800, (Bucchi, 2010, p. 164) è un fatto (sociale) consolidato, ma non è sempre stato così e non è detto che sarà sempre così. La narrazione eroica serve per sostenere l'idea di “proprietà intellettuale privata” in contrapposizione al determinismo scientifico. Nello specifico informatico si assiste però a una curiosa inversione: chi ha interesse a mantenere la proprietà individuale ha anche tutto l'interesse a mantenere integra la legge di Brooks con il suo top-down che nega di fatto il momento creativo a livello tecnico per posizionarlo a livello organizzativo e progettuale astratto; di converso i propalatori del Software Libero e dell'Open Source sono impegnati a raccontare le gesta e a mantenere viva la memoria degli hacker fondatori. Una possibile spiegazione di questa contraddizione potrebbe risiedere nel fatto che mentre nel caso del software proprietario l'idea di proprietà intellettuale è un fatto sociale acquisito, nel caso del Software Libero Open Source è ancora in corso di costruzione l'idea di proprietà pubblica intellettuale. La narrazione eroica degli hacker fondatori viene usata per costruire un'idea di proprietà pubblica dell'open source, mentre la figura eroica dell'inventore, che si afferma nel XIX secolo, viene usata per costruire un'idea privata di proprietà intellettuale. Ciò significa che lo stesso modello simbolico può essere usato con finalità diametralmente opposte. Pur essendo le finalità opposte gli esiti sembrano però non essere così diversi: in entrambi i casi si tratta di stabilire degli standard e di giungere a forme di chiusura dettate dal bisogno d'ordine.
In sintesi software proprietario e Software Libero Open Source rappresentano l'uno la negazione dell'altro solo se non li consideriamo come due cose diverse, che hanno attraversato un processo di differenziazione (Luhmann, 1990) in stretto rapporto tra loro e funzionali allo stesso (sotto) sistema tecno-scientifico teso alla chiusura per mezzo della "narrazione eroica".

#### Note

* ↑ The Logic of Collective Action: Public Goods and the Theory of Groups, Harvard University Press, 1st ed. 1965, 2nd ed. 1971
* ↑ Un programmatore può avere una sua attività principale e dedicarsi a tempo perso a sperimentare in prospettive future.
* ↑ Si tratta di un vero certificato elettronico.
* ↑ Dove si trova la sede di Microsoft.