Codice e società/Capitolo 3/2
 |
Questo testo è completo. | |
| ◄ | Capitolo 3 - 1 | Capitolo 3 - 3 | ► |
Il fatto di considerare come artefatto il codice piuttosto che il software, che eventualmente ne deriva, è giustificato dalla sua rilevanza per gli effetti che produce prima ancora di diventare software. Questa prospettiva ci permette di generalizzare il “paradigma open” senza dover cercare delle spiegazioni universali al di fuori dell'informatica, in altri settori della società, in quanto il codice, aperto e accessibile, come tale si trova già di per sé a un livello astratto, come abbiamo avuto modo di spiegare nelle note introduttive.
Tuttavia ciò non significa rinunciare alla vasta conoscenza che paradigmi come la “scienza 2.0” (Bucchi, 2010, p.160) e ricerche empiriche sulla diffusione sociale della scienza hanno prodotto. Certamente il nostro punto di vista può essere sostenuto anche con generalizzazioni esterne all'informatica.
Ad esempio il fenomeno dell'invenzione collettiva viene descritto da Allen (1983) e si riferisce all'industria siderurgica tra il 1850 ed il 1875 nel distretto di Cleveland in Inghilterra, dove non era consuetudine secretare l'architettura e il processo produttivo dell'acciaio. Come già descritto da altri, lo scopo primario era farsi una buona reputazione e acquisire prestigio. In secondo luogo il costo e quindi l'investimento per il mantenimento del segreto era minacciato, se non altro, dal fatto che i progettisti degli impianti si spostavano da una fonderia all'altra realizzando impianti uguali. Queste rivelazioni aumentavano la possibilità di guadagni per due motivi. Il primo riguarda la centralità, il passaggio obbligato (Latour 1987), verso chi per primo aveva realizzato quella determinata architettura e possedeva le conoscenze indispensabili. In secondo luogo la diffusione di conoscenza aveva come conseguenza lo sviluppo del settore in una determinata area e quindi l'aumento del mercato in generale.
Oltre a quanto già spiegato, il codice libero è astratto per più motivi: - È accessibile e visibile1.
- Non è comprensibile ricorrendo all'esperienza quotidiana comune.
- Non ha un'utilità immediata, non è utilizzabile se non installato, configurato, compilato o interpretato dalle macchine.
- Può essere potenzialmente usato su apparati anche molto diversi tra loro.
- Può essere scritto per motivi didattici o fissare dei concetti in modo più sintetico che non con il linguaggio umano. Può accadere che si ricorra al linguaggio informatico per trasmettere significati ad altri uomini e non a delle macchine2.
- Un buon esempio storico della dimensione del codice come artefatto è offerto dal libro “Lions' Commentary on Unix 6th Edition, with Source Code” (Lions, 1976). Il codice contenuto in tale libro fu vietato con la versione 7 di Unix della AT&T: la stessa AT&T, quindi, non sottovaluta l'importanza del codice in quanto tale, anche quando questo “viaggia” su “supporto cartaceo”3 e non “gira” necessariamente su qualche “macchina”4. Questo episodio sarà poi all'origine del progetto didattico MINIX di Tannenbeum, da cui Torvalds prenderà spunto per iniziare a costruire quello che diventerà uno dei sistemi operativi più diffusi al mondo: Linux.
Si potrebbe obiettare che, tutto sommato, anche quel codice comunicato per scopi didattici, conviviali, sociali o esplicativi finisce bene o male per esser fatto “girare” in qualche macchina. Tuttavia, la differenza sostanziale sta nel fatto che non sempre chi lo divulga ha queste intenzioni. Non sempre esiste un piano perché ciò avvenga, e quando esiste è generico, non industriale, per cui la diffusione avviene in modi e tempi non previsti o imprevedibili. Addirittura, seppur semplificando, la “chiusura” delle note didattiche (che per noi costituiscono codice libero) sul sistema Unix, da parte della AT&T, scatena una serie di effetti non previsti e contrari agli interessi della stessa AT&T, che portano alla nascita di Linux.
Il codice informatico, che nella sua accezione libera noi consideriamo sociale, produce effetti inattesi e non previsti a livello informatico, e quindi nuovamente sociali per l'impatto che l'informatica pronta all'uso (Latour, 1987) ha sulla società. Tuttavia ciò non avviene informaticamente bensì socialmente, perché accade autonomamente rispetto alla progettazione industriale, tanto più che, come accade per il codice libero istituzionale del Software Libero ed Open Source, i processi non prevedono una fase progettuale. La progettazione arriva a coincidere con la scrittura del codice5.
La rinuncia della fase progettuale, comunemente chiamata top-down, da parte del “paradigma open” è, a sua volta, una conseguenza di quella che è considerata un'auto-evidenza di fatti emergenti sfuggiti al controllo dei “progettisti”. Di fatto viene a mancare un elemento ritenuto importante per scrivere codice e cioè la progettazione. Il paradigma precedente sostiene che senza progettazione non può esserci informatica, mentre nei fatti l'informatica, per mezzo del codice libero, si diffonde anche senza progettazione. È qualcosa di simile a quanto accade ai raggi “N” di Blondlot che continuano a lasciare le loro tracce su di un monitor anche rimuovendo il prisma di alluminio che si suppone li generi. In quel caso si trattava di qualcosa d'altro e non di raggi “N”6, il cui dilemma sulla loro esistenza si perde sullo sfondo dell'arena tecno-scientifica. La posta in gioco sta qui: la natura di questo codice è solo informatica e progettuale, o anche sociale e incidentale? L'informatica è qualcosa che la tecno-scienza conosce bene perché costruita dall'uomo, o ci sfugge qualcosa? Siamo sicuri che il codice non sia semplicemente un prodotto intermedio dello sviluppo software, e che non costituisca già un artefatto pronto a un uso che non abbiamo ancora ben compreso, e che ha a che fare anche col simbolico? E questo qualcosa lo stiamo cercando nel posto giusto? È plausibile che un progetto in via di fallimento non abbia nel frattempo agito nel sistema provocando effetti emergenti difficilmente riconducibili ad esso? Se diamo una qualche credibilità alla teoria dei sistemi di Luhmann, allora è anche plausibile pensare che gli elementi del sistema non debbano necessariamente essere permanenti perché il sistema nel suo complessi funzioni.
Queste sono le domande che pone l'emergere di un nuovo sistema operativo dal tessuto sociale, o pezzi di società “non autorizzati” a “giocare” con la tecnologia, come studenti senza strumenti sofisticati che procedono senza piani precisi7 (Vixie, 2000). Per tutte queste ragioni l'emergere del “paradigma open” imponeva a suo tempo – fine millennio – un ripensamento sui modelli organizzativi che sottendono la produzione di codice.
A questo punto intervengono le teorie sui modelli organizzativi del Software Libero e Open Source. Il punto di partenza sono le contraddizioni a cui sono gli stessi teorici dell'iniziativa Open Source a tentare di dare delle risposte. Una di queste contraddizioni riguarda la legge di Brooks, per cui aggiungere programmatori a progetti in ritardo peggiora la situazione. Secondo Eric Steven Raymond (1997) ciò non accade nel contesto Open Source – i cui progetti vedono la partecipazione di migliaia di programmatori – poiché, a differenza delle strutture gerarchiche del software proprietario, quelle destrutturate e partecipate su base volontaria sono maggiormente in grado di gestire la complessità e di auto-coordinarsi.
Seguono poi una serie studi più empirici che cercano di spiegare tali paradossi a partire dalle strutture organizzative in termini di ruoli, livelli di partecipazione e di motivazioni. Ye et al. (2002) individuano otto ruoli nel contesto della produzione Open Source8. Questa classificazione per noi è significativa perché ci permette di stabilire quali sono i livelli di partecipazione, cioè i primi cinque, dove è predominante la significatività del codice piuttosto che l'utilità del software finito, cioè gli ultimi tre. Per Benkler (2006) la differenza sostanziale sta nel fatto che nei progetti proprietari i programmatori sono ingaggiati in funzione dei progetti, mentre nel contesto Open Source sono i programmatori ad ingaggiare i progetti. Il paradosso dell'Open Source rispetto alla legge informatica di Brooks ha ispirato molto a livello di semplice divulgazione ma anche di ricerca empirica.
Secondo la nostra prospettiva9 il problema è invece capire qual è l'oggetto che stiamo osservando: il codice o il software? Posto in questi termini il problema potrebbe anche venir meno. Se la questione è produrre software, allora si può constatare come gli assetti organizzativi che prevedono progettazione e top-down continuano a funzionare, non sono spariti: in definitiva non c’è stata una rivoluzione che ha spazzato via tutto il software proprietario con i suoi progetti gerarchici e il suo top-down. Eppure, allo stesso tempo il Software Libero e l'Open Source hanno avuto un’enorme diffusione.
Si tratta, secondo la nostra prospettiva, di due cose diverse: nel primo caso si tratta di software, nel secondo di codice libero. Tanto è vero che il codice libero istituzionale, come il Software Libero e l'Open Source, dettano precise regole su come deve essere confezionato il codice (annotazioni, commenti, lista dei difetti, indentazione, enumerazione) e non il software. Ciò non significa che queste due tipologie informatiche non confliggano, o non entrino in competizioni tra loro, o non siano connesse o, in termini generali, non si condizionino. Sono i rispettivi assetti organizzativi a non contraddirsi, perché attengono alla produzione di artefatti di “natura” diversa. Da questa prospettiva può risultare irrilevante applicare le leggi che sottendono la produzione di software (legge di Brooks) quando ciò che viene prodotto non è software.
Si è consapevoli del fatto che separare l'idea di software dall'idea di codice è una semplificazione che non rende merito alle situazione sfumate e complesse che fanno parte dell'esperienza degli addetti ai lavori. Si tratta nello specifico di costruire un ideal-tipo astratto del codice libero in grado di poter essere descritto e su cui poter fare delle generalizzazioni.
Note
- ↑ se non lo fosse sarebbe semplicemente oscuro e segreto e non astratto.
- ↑ In questo caso il linguaggio e quindi il codice è usato in modo improprio rispetto allo scopo per cui è stato inventato, e cioè quello di fornire istruzioni alle macchine e non informazioni agli uomini. Per contro, le annotazioni all'interno del codice informatico sono fatte in linguaggio umano comune.
- ↑ Definizione usata in campo informatico per indicare l'informazione fissata sulla carta anziché sulla memoria delle macchine.
- ↑ Il termine macchina nel gergo informatico si riferisce a un calcolatore generico che può di essere di volta in volta un client, come il nostro PC quando navighiamo in rete e usiamo i servizi del Web; un server, che ospita, ad esempio, servizi disponibili nel Web; oppure calcolatori specializzati che hanno nomi come firewall, proxy, reverse proxy e via dicendo.
- ↑ … scrivo codice con metodo simile a quello a quello di Richard Stallman, per lui la carta non serve. Se sto lavorando su qualcosa di complicato o devo riflettere su precisi dettagli, raramente prendo appunti. Ma in genere quello che succede è che lavoro direttamente sulla macchina. Se il progetto è complicato, prima di cominciare a elaborare il codice, per qualche settimana mi limito semplicemente a pensare a tutti i possibili aspetti e cerco di trovare la soluzione. E tutto senza scartoffie … Linus Torvalds in codice ribelle - Glyn Moody – 2002.
- ↑ In La scienza in azione - Bruno Latour – 1987.
- ↑ ...Diversamente un caso anche troppo comune di progetto Open Source è quello in cui i soggetti coinvolti si stanno divertendo e vogliono che il loro lavoro sia usato dal maggior numero possibile di persone: per questo lo danno via gratis e spesso senza porre alcuna restrizione alla ridistribuzione. Si tratta magari di gente che non ha accesso agli strumenti software cosiddetti "di livello commerciale" (analizzatori della copertura del codice, interpreti bounds-checking, verificatori dell'integrità della memoria). E le cose che più sembrano divertirli sono: programmare, confezionare ed evangelizzare: niente QA, niente MRD, di norma niente date di rilascio troppo vincolanti . (Vixie, 2000).
- ↑ 1. Il project leader: iniziatore del progetto, responsabile per l'andamento del progetto in genere; 2. Il core members (gruppo ristretto): responsabile per la guida ed il coordinamento dello sviluppo di un progetto OSS; 3. Active developers (sviluppatori attivi): coloro che contribuiscono regolarmente con la produzione di codice allo sviluppo di nuove funzionalità e l'aggiustamento di bugs1; 4. Peripheral developers (sviluppatori periferici): coloro che implementano nuove funzionalità in modo occasionale; 5. Bug fixers: rimediano a bachi che loro stessi trovano o che vengono segnalati; 6. Bug reporters: scoprono e segnalano bachi, assumendo un ruolo simile a quello dei testers nello sviluppo software tradizionale; 7. Readers (lettori): Utenti finali che nel contempo cercano di leggere il codice e comprendere come funziona il sistema; 8. passive users (utenti finali): utenti che usano il sistema senza mostrare alcun interesse su come il sistema è costruito.
- ↑ In questo caso non si tratta di prendere le distanze dalla ricerca che ci ha preceduto, ma semplicemente proporre un'altra prospettiva.