Codice e società/Capitolo 5

Da Wikisource.
Jump to navigation Jump to search
CAPITOLO 5
DIFFERENZIAZIONE, DIALOGO E CONTROVERSIE

../Capitolo 4/3 ../Capitolo 5/1 IncludiIntestazione 10 giugno 2013 75% Tesi universitarie

CAPITOLO 5
DIFFERENZIAZIONE, DIALOGO E CONTROVERSIE
Capitolo 4 - 3 Capitolo 5 - 1

In questo percorso abbiamo visto l'informatica nel suo farsi, cioè abbiamo visto il codice, poiché l'informatica si fa attraverso il codice. Nel suo processo di trasformazione da codice libero (e disordinato) ad informatica pronta all'uso abbiamo registrato una doppia modalità di chiusura: l’una che comporta la conservazione dell'esperienza attraverso un processo di istituzionalizzazione, e l'altra che comporta l'oscuramento del codice e la sua appropriazione privata. Queste due modalità restano legate a specifiche entità che abbiamo mappato, e che non sono tra loro autonome ma si perturbano. Potremmo dire che si implicano, oppure che si compenetrano, che l'una costituisce l'ambiente dell'altra (Luhmann, 2007). Entrambe queste modalità di chiusura corrispondono a un bisogno d'ordine, alla necessità di presentare l'informatica agli “utenti” e ai “clienti” come stabile, affidabile e consolidata.

C'è sempre nei vari progetti informatici un momento topico che fa scatenare questo bisogno d'ordine. È quello che gli informatici chiamano “dilemma del successo” o “pericolo del successo”. Quando un progetto inizia a diffondersi in modo troppo rapido, il rischio è quello di non riuscire più a controllare gli effetti che produce. L'esito di questa emergenza può essere il fatto che le risposte che vengono date, anziché limitare il problema, lo accentuano. Tanto più il problema è grave, tanti più saranno i soggetti che si sentiranno “autorizzati” a intervenire. Quello che accade con il progetto Unix è esattamente questo. Molte software house e organizzazioni cercano di imporre i propri standard proprietari o aperti, così, anziché mettere ordine, il proliferare degli standard crea ancor più confusione e senso di smarrimento.

Lo stesso Bill Joy, che aveva contribuito al potenziamento di Unix e alla sua stabilizzazione, si troverà in un primo momento a definire gli standard open presso il Computer System Research Group di Berkeley, e successivamente ad essere assunto dalla AT&T per industrializzare Unix. IBM sarà prima associata al progetto Unix della AT&T, successivamente si unirà alla Open Software Foundation legata a Berkeley. Ciò che era stata la forza del modello Unix diventa la sua debolezza. Questo network fortemente basato su legami comunitari si espande, ma è proprio la tipologia dei suoi legami a rendere impossibile la necessaria differenziazione tra un sistema chiuso e proprietario ed un sistema istituzionale, al punto che i passaggi dall'uno all'altro sistema sono molto agevoli e frequenti.

Se da un lato è abbastanza chiara la necessità di arrivare a una chiusura, e quindi a una tecnologia pronta all'uso stabile e consolidata, resta da chiarire il perché questo debba avvenire in due modalità diverse, che noi abbiamo chiamato istituzionalizzazione e privatizzazione. La risposta potrebbe essere cercata nell'emergere di questo conflitto tutto interno al modello Unix. Nessuna delle due forme di chiusura riesce alla fine a prevalere, e ciò potrebbe significare che nessuna delle due forme è in grado di sostenersi senza l'altra. Se così è, il dialogo tra queste due dimensioni sembra in qualche misura essere necessario a questo specifico ambito tecnologico: perché vi sia un dialogo bisogna necessariamente essere in due. Questo dialogo spiega come le due dimensioni si implicano attraverso le controversie scientifiche, le controversie legali, il conflitto, le persone che le attraversano e le mettono in comunicazione, accordi commerciali tra chi opera nell'ambito dell'Open Source e chi opera nell'ambito del software proprietario e, non da ultima, la tecnologia stessa che si trasforma da Open Source a proprietaria, e viceversa.

Prima di affrontare le modalità con cui questi due “mondi” dialogano è importante ribadire che l'istituzionalizzazione del codice libero, verso le forme del Software Libero o dell'Open Source, dal nostro punto di vista è anch'essa, al pari del software proprietario, una forma di chiusura giocata su più modalità: cognitiva, selettiva, tecnica e normativa.

Note