Codice e società/Capitolo 3
 |
Questo testo è completo. | |
TECNOSCIENZA E CODICE
| ◄ | Capitolo 2 - 2 | Capitolo 3 - 1 | ► |
Il percorso che stiamo seguendo ci porta a non soffermarci su tecniche comparative o di valutazione della qualità. Il nostro discorso è estraneo al valore tecnico del codice. Ciononostante dobbiamo tener conto del fatto che per gli attori in gioco la qualità del codice intesa come requisiti, usabilità, aderenza agli standard, manutenibilità, robustezza e sicurezza è di importanza centrale. La tentazione di far derivare una diversa qualità degli artefatti informatici in funzione del paradigma che sottende il modo di produzione del codice, per poi allargare tali concetti ad interi settori della società, come fanno gli approcci post-moderni, è tuttavia forte.
La ricerca empirica spesso ha colto queste differenze qualitative, derivabili dai diversi assunti paradigmatici che sottendono la produzione di codice nell'ambito del Software Libero e Open Source. Il fatto che gli assunti di base si riflettano su, e rimangano ad impregnare, l'artefatto finale è una prospettiva affascinante oltre che plausibile:
[…] Guardando dentro al VAX, West percepì di vedere un diagramma dell'organizzazione della corporazione DEC. Trovò il VAX troppo complicato. Non gli piaceva, ad esempio, il sistema attraverso il quale le singole parti della macchina comunicavano tra loro; c'erano troppi protocolli coinvolti. La macchina esprimeva la cautele della DEC, il suo stile burocratico. West si compiaceva di tutto ciò. (Tracy Kidder, 1981).
È tuttavia molto difficile soffermarsi sulla differenza senza correre il rischio di stilare delle classifiche. Il discorso sulla qualità caratterizza la comunicazione legata alle strategie di diffusione del Software Libero e dell'Open Source e finisce col riversarsi nelle teorie della ricerca empirica, in particolare nelle prime ricerche sul Software Libero Open Source, che Lin (2005) indica come periodo utopistico. La “qualità” assume rilevanza ai nostri scopi come significante e non come significato. In altre parole, essa è importante non in quanto “sociologicamente misurabile”, ma in quanto gli attori in gioco vi danno importanza. Dal nostro punto di vista è importante perché sulla base di ciò vengono costruiti confini che permettono di identificarsi e di individuare un avversario. Il discorso sulla qualità come significante è un elemento fondamentale nelle controversie tra Software libero Open Source e software proprietario.
Il discorso sul metodo va di pari passo con il discorso sulla qualità. Dal primo ne deriva “necessariamente” la seconda. Ad esempio la qualità industriale la si raggiunge solo attraverso l'industrializzazione del software. Il sistema operativo Linux iniziato da Linus Torvalds1, nasce con una controversia sul metodo: quella tra micro-kernel del progetto MINIX di Tannenbaum e quella del kernel monolitico di Torvalds. Una volta che Linux si afferma c'è energia, più che argomenti, per ribaltare le accuse. Al suo inizio la controversia assume questi toni:
Tannenbuam: “se costruisci un sistema operativo con kernel monolitico il tuo sistema nascerà già vecchio”.
Torvalds: “può essere, ma a differenza di MINIX e del progetto GNU il mio è già nato”.
Questa è una sintesi – e una semplificazione - della controversia che si è svolta tra Tannenbaum e Torvalds nel 1992. Torvalds sostiene il primato dell'uso rispetto a quello della correttezza metodologica. Quindi Torvalds concede il fatto che il suo progetto sia carente sul fronte del rigore e quindi della qualità. La teoria informatica in questo periodo storico afferma che il micro-kernel è necessariamente più affidabile in quanto, “detta in soldoni”, il nocciolo del sistema è minimalista e molte delle funzionalità, specialmente quelle legate al funzionamento di schede e dispositivi esterni, viene demandata ad altri programmi. Questa “parcellizzazione informatica” agevolerebbe la manutenzione e l'individuazione di difetti, l'affidabilità, la manutenibilità e l'usabilità.
Sulla base di questi assunti teorici la Carnegie-Mellon University costruisce nel 1994 il sistema Mach anch'esso Open Source. Il progetto però non da i risultati sperati perché le cosiddette “chiamate” o IPC (interprocess communication) da micro-kernel verso moduli esterni appesantiscono il sistema più di un kernel monolitico2. A questo punto si iniziano a teorizzare i micro-kernel di seconda generazione che dovrebbero eliminare questi inconvenienti (Miao, 2010).
Per contro nel 2003 l'IBM Linux Technology Center afferma che:
[…] i test dimostrano che il kernel Linux e gli altri nuclei del sistema operativo sono affidabili e stabili oltre i 30, 60 e 90 giorni, e possono costituire un sistema robusto, di livello industriale per progetti di lunga durata.
Addentrarsi nel problema e cercare di capire quali siano i criteri ultimi, universalmente accettati, per definire la qualità diventa un'impresa senza speranza: quella tra kernel monolitico e micro-kernel è una questione tuttora irrisolta. Anche gli esperti concludono che alla fine si tratta di punti di vista.
La questione della qualità e del metodo può essere poi generalizzata e allargata agli assetti organizzativi, e quindi eventualmente, tra le altre opzioni, anche al “paradigma open”. In effetti, una volta affermati (e istituzionalizzati), il Software Libero e l'Open Source Initiative iniziano a dettare nuove regole per il rigore e nuovi criteri per la validazione, ad esempio:
- con un numero sufficiente di occhi tutti i difetti vengono a galla;
- le liste di variabili (vettori in termini informatici) devono essere enumerati a partire dal numero “zero” e mai da “uno”;
- il codice deve essere commentato e ben indentato;
- i nuovi progetti non devono implementare funzionalità già scritte da altri, ma devono fare chiamate a tali moduli già esistenti.
Quello che emerge è che non esistono dei criteri ultimi che possano aiutarci a giudicare la “bontà” del codice: ciò che sembra appurato oggi, può non essere valido domani, e non solo per una questione di progresso degli strumenti.
All'interno dello stesso Software Libero molti progetti nascono con il massimo della partecipazione e con il minimo di regole (in relazione ai criteri di validazione), ma finiscono con la necessità di darsi delle regole, di stabilire degli organi, dei ruoli, in ultima analisi di stabilire dei confini da difendere, e di conseguenza cercare di calibrare il grado di apertura, il che implica una certa chiusura. Anche nei progetti più aperti e democratici una qualche forma di chiusura è, infatti, inevitabile. Debian è una comunità tra le più importanti e vaste, mantiene circa 40.000 pacchetti e si riconosce nella Free Software Foundation di Richard Stallman. All'inizio il progetto era costituito da poche persone che potevano fare più o meno quello che volevano. Ora vige una struttura molto complessa, con diversi livelli di governo, sistemi di elezione democratica, organi giudiziari e amministrativi e soprattutto:
[…] C'è il cosiddetto DAM, Debian Account Manager, che è un gruppo di persone che decidono chi può diventare sviluppatore Debian e chi no. (intervista Stefano Zacchiroli - Leader di Debian - 17 agosto 2010)
Come abbiamo già spiegato nel primo capitolo, man mano che il progetto acquista complessità e importanza si cerca di restringere l'apertura in entrata (inserimento di nuovi programmatori) e di allargare l'apertura in uscita (distribuzione di pacchetti).