Codice e società/Capitolo 1/2
 |
Questo testo è completo. | |
| ◄ | Capitolo 1 - 1 | Capitolo 2 | ► |
Molto spesso l'Open Source è presentato dalla letteratura come la sfida al software proprietario. Questa prospettiva non riesce a mettere sufficientemente in evidenza le controversie che sono già in essere nel momento in cui il software proprietario riesce a imporsi nel campo informatico. Il fatto di prospettare l'Open Source come avvento o reazione al software proprietario implica una prospettiva diacronica di tipo post-industriale. Il prefisso post indica proprio l'idea di un superamento a seguito di una contraddizione interna al sistema. Quelli che noi chiamiamo “approcci post-industriali”, in questo specifico contesto Open Source, tendono quindi a porre la nascita dell'Open Source nelle sue forme istituzionali come reazione al software proprietario ed usano registri come rivoluzione (DiBona, 2000); successo (S. Weber, 2004); ribellione ([en.wikipedia.org/wiki/Glyn_Moody Glyn], 2002); opportunità, sfida e innovazione (Benkler, 2006). Ciò che si ritiene contraddittorio è il software industriale, che fa riferimento ai criteri di industrializzazione del software, diversi ed alternativi rispetto ai criteri di ingegnerizzazione del software Open Source.
L'utilizzo del termine “pos-tindustriale” parlando di Open Source e Software Libero permette di connettere due livelli: uno particolare ed uno generale. Il livello particolare si riferisce allo specifico contesto informatico ed è usato per contrapporre il Software Libero e l'Open Source a quella branca dell'ingegneria informatica che va sotto il nome di “industrializzazione del software”.
In senso più generale con il termine post-industriale ci si riferisce ad approcci “beyond software”, cioè che non tengono conto di questo specifico settore, ma della società globale. Si tratta di approcci che forniscono la grammatica alla dialettica del Software Libero e dell'Open Source, pur non entrando nel merito specifico dell'informatica. È il caso, ad esempio, di Wallerstein (1985) che sostiene che il sistema mondo, basato sull'economia e sulla divisione mondiale del lavoro, smetterà di funzionare quando le sue contraddizioni diventeranno insostenibili. In questo senso l'Open Source, per molti autori, rappresenterebbe un anticipo, o quantomeno un sintomo, rispetto a quanto accadrà anche in altri settori della società (Benkler, 2006). A tal proposito Benkler parla di networked information economy che dall'informatica si diffonderà anche in altri ambiti produttivi, e dove il modello di produzione sarà radicalmente decentrato, collaborativo, paritario e non-proprietario.
Questi autori spesso non si riferiscono esplicitamente a teorie post-industriali o della globalizzazione, purtuttavia il tema delle contraddizioni del modo di produzione del software proprietario, e l'idea del potenziale espansivo dell'esperienza del Software Libero e dell'Open Source in altri settori della società, nel limite dei nostri scopi argomentativi, ci fa ritenere legittima questa sistematizzazione, se non altro, ad esempio, in relazione alla contrapposizione con i principi dell'industrializzazione del software proprietario.
Una delle contraddizioni più interessanti che solleva Wallerstein nella sua prospettiva post-industriale mondiale, per noi “beyond software”, è quella relativa alla mondializzazione dell'economia in contrapposizione al radicamento locale della politica. Quelle che descrive Wallerstein sono contraddizioni che hanno come esito la contrapposizione tra stati ed attori dell'economia mondiale. Da un nostro punto di vista queste contrapposizioni emergono anche nello specifico informatico come, ad esempio, in occasione delle controversie legali tra Microsoft e le agenzia governative: con l'antitrust USA nel 1995, e con l'Unione Europea nel 2004.
Per Beck (2001) l'esito sarà quello dell'acquisizione di funzioni politiche da parte di attori transnazionali in competizione con gli stati, i quali saranno sempre più delegittimati dal minor consenso pubblico, a seguito della loro incapacità di gestire il rischio e l'incertezza legati alla globalizzazione. Un sintomo dell'acquisizione di funzioni governative da parte di soggetti non statali può essere invece rappresentato dalla controversia in atto nello scorcio del 2012 tra produttori di computer, produttori di sistemi operativi di tipo Open Source.
Il motivo della controversia è l'immissione nel mercato di calcolatori equipaggiati con “secure boot loader”1, in questo modo i computer accetteranno di eseguire solo sistemi operativi approvati da un'unica software house. Si tratta di fatto di funzioni di certificazione da parte di soggetti non governativi e che riguardano dimensioni sociali, come la sicurezza e la fiducia, e che vengono poste su livelli extra-governativi e nell'ambito di quella che Wallerstein chiama economia mondiale. Altra funzione governativa svolta da soggetti non statali è riconoscibile nell'opinione di molti utenti Linux che ritengono il costo del sistema operativo a corredo del computer acquistato una tassa sull'hardware pagata a un privato, in quanto non c'è possibilità di farsi rifondere il costo di un sistema operativo che si decide di disinstallare e non utilizzare.
Questa tensione tra soggetti transnazionali e stati emerge concretamente nei fatti come viene rilevato dal discorso del Vicepresidente dell'UE Neelie Kroes in occasione del Guadec open source software conference a L'Aia nel luglio del 2010:
[…] Many authorities have found themselves unintentionally locked into proprietary technology for decades and after a certain point that original choice becomes so ingrained that alternatives risk being systematically ignored. That's a waste of public money that most public bodies can no longer afford.
Non sempre gli approcci che noi chiamiamo post-industriali hanno riferimenti espliciti ad autori come Wallerstein o Bell, ma ciò non toglie che siano coerenti con questi se proiettati ad un livello teorico più generale “beyond software”. In termini generali Bell (1973) offre una cornice teorica che vede l'informatica e l'elettronica come terreni di conquista sempre più importanti in un mondo sempre più terziarizzato, in cui i rapporti di potere saranno sempre più determinati da queste tecnologie.
Bell (1973) fornisce la definizione della situazione in termini di “posta in gioco”. Come emerge dalla letteratura Open Source che noi chiamiamo post-industriale (Himmanen 2001; Weber, 2004; Blenker, 2006; De Laat, 2007), il Software libero e l'Open Source sono attori consapevoli di questa posta in gioco, cioè queste nuove forme di potere che Bell chiama processi decisori attraverso la tecnologia intellettuale.
In sintesi il termine post-industriale, per i nostri scopi, ha un significato specifico legato al paradigma di industrializzazione del software, ma allo stesso tempo coerente con la prospettiva post-industriale più generale. Quello che diviene importante è che lo stesso termine “industrializzazione del software” evoca un'idea di passaggio inverso rispetto a un'idea “post” di superamento. Ci troviamo quindi di fronte a due paradigmi opposti: uno che deriva dalle scienze sociali e che riguarda il paradigma open source, secondo cui il “software” è destinato a deindustrializzarsi e a deindustrializzare altri settori della società, grazie alla diffusione del suo stesso paradigma; l’altro di derivazione ingegneristica secondo cui il software deve essere industrializzato.
Secondo la nostra prospettiva è proprio l'idea di industrializzazione del software a confermare il fatto che il software, o meglio il codice, esiste come tale, autonomamente rispetto alla progettazione. In qualche modo esso esiste socialmente1, la sua “industrializzazione” avverrebbe dopo, coinciderebbe con un processo di appropriazione, di chiusura e di confezionamento di una tecnologia da rendere pronta all'uso (Latour, 1987). Dal nostro punto di vista è più attendibile l'idea di industrializzazione del software perché, indipendentemente dagli esiti futuri, pone gli eventi nel giusto ordine.
Paradossalmente è proprio il fatto che il software “debba” essere industrializzato che ci dice che il codice non è industriale bensì sociale. Fermandoci a questo punto della storia ci troviamo di fronte ad un quadro non lineare e complesso: entrambi questi processi sono in atto. Si tratta cioè di un sistema complesso e dialogico.
Diversamente da Wallerstein, Beck2 (2001) non parla di contraddizione, ma di passaggio da una società scarsista, cioè basata sull'allocazione di risorse scarse, ad una società del rischio basata sulla distribuzione del rischio. L'informatica in questo senso rappresenterebbe (secondo gli approcci della specifica ricerca empirica sull'Open Source e del Software Libero) una forma di democratizzazione della scienza e della tecnologia che a livello più generale descrive Beck. In questa prospettiva potremmo invece parlare di radicalizzazione della modernità (Giddens, 1994), una sorta di modernità 2.0, piuttosto che una post-modernità, che rende conto della complessità dialogica.
Il fatto di assumere invece l'avvento del Software L'ibero e dell'Open Source sul software proprietario, piuttosto che il contrario, contraddirebbe queste prospettive dialogiche, sulla complessità, sul rischio e la riflessione. Ne consegue che il punto di partenza non è indifferente rispetto alla prospettiva che poi si assume. In questa tesi la prospettiva è invece quella di assumere il codice libero come forma tecnologica che anticipa il software proprietario (in senso storico e non del processo produttivo), e che poi continua a essere compartecipe con lo stesso, condividendone la struttura sociale e nella produzione di tecnologia informatica. Si tratta quindi di una prospettiva dialogica rispetto a quella diacronica di tipo post-industriale.Inoltre, una tale prospettiva ci permette di spiegare come avviene la chiusura del codice libero, piuttosto che l'apertura del software. In qualche modo lo stesso Open Source tende a industrializzarsi in una certa misura: nascono ruoli, funzioni e specializzazioni. Secondo questo approccio, sia che si tratti di semplice codice, sia che si tratti di Open Source o Software Libero, la chiusura sarà un destino inevitabile, anche se nelle forme inedite che consentano di mantenerne la distinzione dal software proprietario e di conservarne l'identità.
Weber fa una ricostruzione storica dettagliata dell'Open Source, tanto da costituirne un punto di partenza e un riferimento teorico importante per le ricerche che seguono. Pur seguendo un approccio diverso, ma non necessariamente alternativo, riteniamo la ricerca di Weber una fonte di informazioni fondamentale. Weber (2004, pp. 159-164) descrive gli assetti organizzativi dell'Open Source come una combinazione di leadership e norme culturali che determinano chi abbia l'autorità di distribuire versioni modificate del software, e chi possa essere incluso come contributore nella distribuzione pubblica.
Certamente tale assetto è vagamente gerarchico, ma non totalmente aperto. Prevalgono criteri legati al carisma e alle competenze dimostrate nel campo, ma ciò che non viene meno è una certa forma di controllo. Si può discutere sullo stile del comando o del controllo, ma non sulla sua assenza o presenza. Per l'Open Source si tratta di selezionare (“filtrare”, direbbero gli informatici) ex-post, piuttosto che indirizzare ex-ante. Si tratta sostanzialmente di un assetto bottom-up dove non vengono assegnati dei progetti da realizzare, c'è massima autonomia, saranno poi i leader a decretare la validità o meno di quanto svolto. Questo filtro ex-post rappresenta, per quanto democratico e condiviso, una forma di chiusura. A questo proposito De Laat (2007) parla di carattere evolutivo dei progetti Open Source: quando i progetti sono piccoli e appena nati il coordinamento è più informale e riflessivo. Quando il progetto si espande vengono elaborati sistemi di coordinamento più formali. Per Shah (2006) i modelli organizzativi molto autoritari tendono a restringere la partecipazione. Dunque, si verifica una perfetta capacità di uscita da parte di chi partecipa. Ci si riferisce in questo caso a ciò che Hirschman (1970) chiama “exit” (agire economico) piuttosto che “voice” (agire politico). La minaccia di uscita è un deterrente notevole per il management, ed è tanto più efficace quanto più il proprio contributo è ritenuto importante. La chiusura ha quindi una doppia valenza: in entrata e in uscita. L'entrata riguarda la partecipazione al progetto, l'uscita riguarda ciò che viene pubblicato e comunicato3.
Ciò che deve fare il management nei progetti Open Source e del Software Libero è coordinare nel miglior modo possibile la chiusura di queste due aperture. Un progetto piccolo e giovane avrà necessità di attirare programmatori e quindi dovrà aprire il più possibile l'entrata e chiudere l'uscita, fintanto che non si raggiunga un prodotto accettabile dagli utenti e che non comprometta la reputazione del progetto, che a sua volta si rifletterebbe sulla possibilità di attirare ulteriori collaboratori. Per contro, un progetto stabile, ampio e maturo, dovrà chiudere maggiormente l'entrata e aprire il più possibile l'uscita in termini di pubblicazione e diffusione della tecnologia.
Si tratta di una dinamica del tutto simile a quella descritta da Bucchi (2010, p. 168) a proposito dell'iniziativa di alcuni scienziati, associati tra loro, di pubblicare liberamente i propri risultati sulla rete. Si tratta anche per queste forme di divulgazione di:
[…] mantenere il più possibile saldo il collo di bottiglia in entrata – la selezione degli articoli – e aprire il più possibile quello in uscita – numero di lettori e condizioni di accesso. Tenersi stretto l'elemento qualificante delle pubblicazioni – il sistema di peer-review con cui la comunità scientifica si fa garante di qualità di quello che viene pubblicato (Bucchi, 2010, p. 168).
Ma come avviene la chiusura in entrata di un progetto “open”? Il fatto che l'Open Source rimanga una prerogativa irrinunciabile non significa che non esistano altre forme di chiusura. Quando un progetto è complesso e avanzato diviene molto difficile inserirsi: è molto più facile inserirsi in un progetto giovane, e questo corrisponde esattamente alle esigenze organizzative. In questo senso la chiusura è giocata sulla complessità. Progetti molto complessi, come Linux, possono essere di fatto avvicinati solo come utenti, mentre nel nucleo centrale (core) degli sviluppatori vi sono pochi programmatori che vantano decenni di anzianità di servizio. La storia annovera non pochi progetti che da Open Source sono diventati proprietari o hanno assunto forme miste grazie alla tolleranza dei requisiti OSD4. Quando un progetto Open Source si chiude troppo, o addirittura diventa proprietario, si libera subito spazio occupato da un nuovo progetto Open Source o Libero. È quanto è accaduto con OpenOffice acquisito da Oracle. Il semplice sospetto che Oracle potesse far diventare OpenOffice un pacchetto proprietario, visto che la stessa software house agisce nel mercato delle licenze, è stato sufficiente a iniziare un nuovo progetto, sulla base dello stesso codice, che ha preso il nome LibreOffice.
In gergo informatico questo processo va sotto il nome di “fork” ed è strettamente legato alla decisione di uscita (exit) di alcuni partecipanti di cui si diceva sopra. Chi esce si porta via anche il codice sorgente, oltre che le competenze, e spesso inizia un nuovo progetto (fork) sulla base dello stesso codice. Questo evento è ritenuto uno dei peggiori pericoli per il management dei progetti Open Source, ma è anche una garanzia per la persistenza di questo vasto settore dell'informatica. I fork fanno male agli specifici progetti, ma fanno bene al sottosistema del Software Libero o Open Source in generale.
Quindi l'Open Source e il Software Libero non si contrarranno a beneficio del software proprietario, in quanto vi saranno forme di chiusura diverse da quelle del software proprietario, presumibilmente più attenuate, giocate sulle competenze e la complessità, ma mai totali. Nel frattempo continuerà a nascere nuovo Open Source e nuovo Software Libero attraverso la dinamica autopoietica del codice libero.
In sintesi, se la prospettiva post-industriale spiega perché il software proprietario è contraddittorio, e perché l'apertura risolva le sue contraddizioni, la nostra prospettiva tende invece a spiegare come, e in quali forme, il codice libero necessariamente si chiuda. Anzi, le forme istituzionali del codice libero, come l'Open Source e il Software Libero, rappresentano già di per sé una prima fase di chiusura, seppur attenuata rispetto al codice libero pre-istituzionale.
Le garanzie, a nostro avviso, stanno più nella cultura organizzativa e nella rete sociale, piuttosto che nel codice in sé, ossia nei meccanismi sociali che garantiscono la continua alimentazione di questo sistema con codice libero. In altri termini: le garanzie stanno nelle relazioni, non nei nodi rappresentati dai soggetti, quindi sono sociali e non tecniche.
Già negli anni '70 del '900 ci sono dei network che hanno stili molto simili a quelli più popolari e diffusi del Software Libero Open Source contemporanei. In questi termini la questione potrebbe essere rovesciata: non è tanto l'Open Source che emerge, ma è il software proprietario che si organizza e rivoluziona i modelli di produzione e di distribuzione del software, i quali vengono industrializzati. Da un nostro punto di vista potremmo parlare di forme estreme di chiusura. In altri termini, cambiando prospettiva temporale, ad imporsi è il software proprietario a partire da fine anni '70 del '900, non il Software Libero con l'emergere dei sistemi Linux a partire dai primi anni '90 del '900. Ciò che emerge in questa epoca non è la modalità di produzione di codice libero che si registra già negli anni '60 e '70 del '900, quanto le sue forme istituzionali a seguito di nuove consapevolezze, che erano invisibili (“trasparenti” direbbero gli informatici) prima dell'affermarsi del software proprietario chiuso.
Nessuna delle due prospettive alla fine si auto-sostiene: sono compresenti e si implicano a vicenda. Il modello più esaustivo è, in sintesi, quello di una controversia in essere da molti più decenni, e che probabilmente durerà per i decenni a venire, e che noi tenteremo di spiegare come funzionale a un unico sistema complessivo. Questa controversia diviene storica quando nel mercato informatico fanno la loro comparsa i brevetti e le licenze d'uso e, per contro, i network dove circola codice aperto si istituzionalizzano. Si tratta di salvaguardare il contesto operativo, il capitale sociale e l'esperienza comunicata che diventa “performance”5.
La posta in gioco è alta. Per quei soggetti che oggi chiameremmo “utenti avanzati”, adeguarsi alla logica di chiusura del codice significa rinunciare a tutto questo. Val ben la pena organizzarsi in una fondazione, tanto più che il mercato delle licenze chiuse colonizza i templi del sapere e della ricerca scientifica. Il software proprietario inverte la logica per cui non sono più le istituzioni accademiche a detenere il codice di base che fa funzionare le macchine, ma il mercato.
Nel 1984 Richard Stallman è un ricercatore al MIT AI Lab, dove inizia il progetto GNU con lo scopo di superare le limitazioni dei brevetti che ormai imperversavano nelle università attorno ai sistemi Unix, di cui la AT&T era detentrice. GNU doveva essere un sistema in grado di sostituire i sistemi Unix ormai sotto il controllo privato. Per sostenere tale progetto era quindi necessario dar vita a una Fondazione, cioè la Free Software Foundation. I principi etici riguardano il primato del sapere pubblico, il pericolo del monopolio, la possibilità di poter migliorare la tecnologia che viene meno quando il codice sorgente è tenuto segreto da privati. Si badi che difendere il “bene pubblico” non è nella nostra prospettiva un concetto di gratuità eroica, in quanto si tratta di difendere assieme allo spazio pubblico anche il proprio ruolo e la propria esperienza.
È un passaggio storico importante, che caratterizzerà l'asse principale della controversia con il software proprietario negli anni successivi: la centralità del sistema operativo, cioè quella parte di software che si trova, come recitano i manuali di informatica, tra l'hardware e i programmi applicativi. Il sistema operativo diviene così la posizione strategica da conquistare per i contendenti in gioco. Questi principi sono estesi fino a coinvolgere concetti quali democrazia e libertà. Si tratta quindi di uscire dall'ambito prettamente scientifico per mobilitare risorse valoriali che ancora una volta si trovano nella società.
L'Open Source nasce a sua volta dal Software Libero con lo scopo di porre maggiore attenzione alla dimensione tecnologica, in quanto le implicazioni valoriali vengono ritenute ingombrati e limitanti. Questa “scissione” avviene nella primavera del 1997: i protagonisti sono Eric Steven Raymond, Tim O'Reylly, il presidente di Va Reserch Larry Augostin ed altri. La preoccupazione è quella di promuovere il codice aperto in quanto tale e di renderlo compatibile con le logiche dell'economia formale. Da questa scissione nasce l'Open Source Definition che rispetto al Software Libero ha lo scopo di conquistare il mercato più che gli utenti. Ancora oggi l'Open Source è maggiormente conciliante con il software proprietario con cui scende a compromessi, è più permissivo, e questa permissività è dettata proprio dalla necessità che ha l'Open Source di diffondersi senza auto-imporsi troppi limiti morali. Ancora oggi rimane questa distinzione di fondo tra Software Libero ed Open Source: il Software Libero mobilita valori etici, l'Open Source pone l'accento sulle peculiarità tecniche e commerciali del software a codice aperto. In linea di massima possiamo affermare che il Software Libero implica l'Open Source, mentre non è vero il contrario. Cioè Il Software Libero è necessariamente anche Open Source, mentre non sempre l'Open Source è anche formalmente Software Libero.
Note
- ↑ Nasce nell'ambito di relazioni umane quand'anche specialistiche e selettive.
- ↑ Società del rischio, verso una seconda modernità.
- ↑ Come fa notare Weber (2004) il potere si esercita filtrando ciò che viene pubblicato in termini di tecnologia ma anche di credits (contributori menzionati).
- ↑ Open Source Defination.
- ↑ Victor Turner, 1986.