# Codice e società/Capitolo 1

../Introduzione: Codice e società ../Capitolo 1/1 IncludiIntestazione 07 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_1&oldid=- 20130607231456 //it.wikisource.org/w/index.php?title=Codice_e_societ%C3%A0/Capitolo_1&oldid=- 20130607231456
La ricerca su questo particolare settore, a sua volta parte della storia dell'IT (Information Technology o informatica) e quindi espressione della tecno-scienza, tende ad assumere come date le definizioni che gli stessi attori in gioco danno. La tendenza è inoltre quella di contrapporre il software non chiuso, nelle sue diverse accezioni consolidate - come Open Source o Software Libero – al software chiuso cosiddetto proprietario.
In questa tesi cercheremo invece un approccio diverso, per certi versi rischioso, che tiene conto delle peculiarità sociali del codice che emergono attraverso la sua apertura in quanto tale anche quando non appartiene formalmente alle denominazioni ufficiali. Il rischio consiste nel venir meno di riferimenti certi e di uso comune, come l'espressione “open source”, a cui ancorare un discorso su questo fenomeno e ciò impone delle premesse. Il rischio è quello di non far comprendere l'argomento che stiamo trattando perché il concetto legato alla definizione di open source è molto consolidato e diffuso anche se percepito in modo vario.
Non si tratta quindi di osservare l'open source, ma il codice informatico non chiuso che “essuda” dalla rete e che la caratterizza socialmente. Questo codice alimenta al tempo stesso gli apparati che si trovano nella rete (qui per rete si intende il Web) ma anche alcune relazioni sociali specifiche. Questo “essudato” non è solo un prodotto secondario, o incidentale del metabolismo, cioè del funzionamento della rete, che si disperde, che non si riesce a controllare totalmente e che necessariamente emerge. Esso è anche questo, ma è anche un combustibile che viene riusato, condiviso e modificato in continuazione, e perché ciò avvenga è necessario che emerga.
La rete funziona attraverso apparati istruiti attraverso il codice ed è quasi “naturale” che parte di questo emerga e divenga visibile, visto che la rete ne è “impregnata”. Ad esempio, per quanto possano essere efficienti gli apparati che distribuiscono carburante agli autoveicoli è quasi impossibile non percepire l'odore degli idrocarburi quando siamo in una stazione di servizio: non tutto il carburante passa dalla pompa al serbatoio del veicolo, una certa percentuale evapora e si disperde.
Questo codice può venire esposto nella rete in modo incidentale: ad esempio i browser (i programmi che usiamo per navigare) interpretano codice aperto e non sono predisposti, in linea di massima, per interpretare il codice chiuso, quindi molti programmi che devono essere eseguiti dai browser non sono chiusi e compilati.
A volte il codice può trovarsi esposto nella rete in modo intenzionale, cioè viene reso visibile nella rete da chi lo produce; altre volte potrebbe trovarvisi erroneamente.
I motivi per cui tale codice viene intenzionalmente esposto sono di particolare importanza e sono essenzialmente due:
- per essere utilizzato (scaricato e installato) in un altro apparato;
- per essere modificato da altri programmatori.
Questo ultimo motivo è quello su cui ci soffermeremo maggiormente. Da un punto di vista produttivo ciò significa che questo codice viene messo in lavorazione (attraverso la pubblicazione o l'esposizione in termini informatici) da qualcuno a favore di qualcun altro che lo manipolerà ulteriormente. A noi interessano la relazioni che vi sono tra chi mette a disposizione del codice, chi lo modifica ulteriormente e chi semplicemente lo utilizza. Si tenga presente che questi ruoli non sono sempre ben distinti: Chi mette a disposizione il codice, o lo conserva, può anche modificarlo e utilizzarlo, anzi il più delle volte è proprio così.
Siccome noi ci occupiamo di relazioni sociali, ci può tornare utile distinguere questi ruoli e pensarli come distinti in modo da poterne vedere le relazioni. Solitamente chi lo mette a disposizione è chi ha iniziato il progetto ed invita altri a continuare il lavoro o a collaborare.
Usando un'altra semplificazione possiamo dire che il codice libero, per noi artefatto sociale, viene esposto nella rete per essere modificato. Questa modificazione può riguardare tanto il miglioramento, l'aggiunta di funzionalità (implementazione in gergo informatico), l'eliminazione di difetti (il debug in gergo informatico ) ma anche la costruzione (sviluppo) dell'artefatto tecno-scientifico. La costruzione e manutenzione dell'artefatto in condizioni di codice libero avvengono attraverso la loro esposizione nella rete. L'esposizione del codice è una prassi necessaria al suo mantenimento – conservazione - , manutenzione, potenziamento e ulteriore sviluppo. Spesso è più una necessità che un'opzione.
Altro aspetto importante è che i destinatari di questa esposizione non sono persone note, ma soggetti a-priori astratte, le cui competenze vengono verificate contestualmente sul campo, se mai qualcuno coglierà l'invito. Spesso le relazioni che vengono così a formarsi sono forti e durature, consolidate dal forte valore di utilizzo dell'artefatto ma anche dalla sua dimensione simbolica. In qualche modo l'esposizione corrisponde ad un'inseminazione nel sostrato sociale e virtuale di codice. Anche le operazioni di semina di un agricoltore possono rimanere incomprese se non viste nella prospettiva temporale: che senso può avere gettare via della granaglia? E che senso può avere svelare del codice che è costato fatica e tempo produrre? La spiegazione sta nel fatto che la società in questo caso assume il vero significato di sostrato produttivo.
Ciò che ne nascerà, come si svilupperà, dipende dal sostrato sociale su cui si troverà, ma anche dal codice di partenza. Da ciò ne derivano anche delle relazioni nuove e non solo l'artefatto in sé, anzi l'artefatto è ciò che implica le relazioni. Si vedrà più avanti come il sistema operativo open source più diffuso, Linux, nasce con peculiarità che sono alla base di una controversia giocata apparentemente sul piano tecno-scientifico, ma con forti implicazioni relazionali e organizzative: il kernel monolitico. In quel preciso momento storico le relazioni sono state più importanti del rigore scientifico. La rinuncia al rigore scientifico è ciò che ha consentito la liberazione di energia sociale utile a ciò che informaticamente si chiama start-up. Questo ha poi portato a tutta una serie di riflessioni su cosa significhi “rigore scientifico”, visto che comunque nulla vieta di rifare le cose già fatte con maggiore accuratezza in un secondo momento, quando si avranno a disposizione maggiori risorse, con però alcune differenze possibili, e quindi in mutate condizioni sociali:
- sarà cambiata la definizione di cosa sia il “rigore” informatico;
- lo stesso “rigore” potrà aver assunto un peso diverso, perché prevale il rispetto dei tempi di consegna;
- la complessità sarà tale che sarà impossibile sindacare sul rigore;
- l'impegno per il “rigore” viene demandato a chi aderisce successivamente e non più a chi ha iniziato il progetto;
- sindacare sul rigore equivarrà a minacciare nuovi interessi che nel frattempo si saranno consolidati;
- ci saranno nuovi soggetti autorizzati a definire la situazione, i quali avranno, o difenderanno, interessi diversi.
Oltre a questo aspetto, spesso destinato a consolidarsi ed istituzionalizzarsi, e quindi destinato ad assumere delle denominazioni, vi sono almeno altre due modalità di esposizione del codice:
- quella fatta per motivi didattici o pedagogici;
- quella fatta nei vari forum tematici di auto-aiuto per programmatori.
Molti manuali di sviluppo software (manuali che spiegano come si scrivono programmi) vengono prodotti e posti liberamente nella rete. Questi manuali, oltre a costituire di per sé degli artefatti socialmente rilevanti, contengono al loro interno pezzi di codice sotto forma di esempi che possono essere ripresi per iniziare un progetto di costruzione di un software, o magari, di un sistema operativo.
La stessa cosa accade con le relazioni di aiuto tra programmatori. Un problema posto in un forum tematico può ricevere come risposta direttamente il codice per risolvere quel particolare problema. Essendo quel codice visibile anche ad altri questo può essere ripreso e quindi incluso in programmi di diversi progetti. Formalmente non si tratta di Open Source o Software Libero, ma certamente si tratta di codice libero, ed occupa una parte non certo marginale, anche se difficilmente quantificabile.
Già a questo punto ci siamo accorti che abbiamo usato l'espressione “Open Source” parlando del sistema Linux ed è quindi fondamentale chiarire le diverse denominazioni e le forme istituzionalizzate che assume il codice libero, anche se, non tutto il codice libero è necessariamente e fattivamente istituzionalizzato. Questo excursus sulle forme istituzionalizzate del codice libero è tuttavia necessario. Non possiamo rendere bene l'idea di codice libero, autopoietico, esposto e primario come concetto più generale e più vasto di ciò che comunemente chiamiamo Open Source o Software Libero se non spieghiamo, se pur brevemente, cos'è l'Open Source e cos'è il Software Libero. Nel frattempo abbiamo introdotto un nuovo concetto che allarga e generalizza ancor più il nostro assunto di partenza rappresentato dal codice libero: il codice primario. In questa accezione noi consideriamo, ad esempio, codice primario il codice che Linus Torvalds trova a disposizione nel manuale di “Sistemi Operativi” di Andrew S. Tannenbuam. Si tratta di un manuale per studenti di informatica con relativi diritti d'autore sui contenuti, divieto di copia, in qualche modo “chiuso”, al cui interno si trova però il codice di esempio (o codice primario) da cui iniziare a scrivere un nuovo sistema operativo.
È talmente importante questa porzione di codice libero non istituzionale, che, come riporta lo stesso Tannenbuam, in un'intervista rilasciata a Kennet Brown nel 2004, il progetto Minix ha scopi puramente didattici ed è stato sviluppato per ovviare al divieto della AT&T di studiare sul manuale Lions, in quanto conteneva codice rivelatore della tecnologia Unix di cui la stessa AT&T deteneva i diritti. Quindi Tannenbuam affronta un problema “pedagogico”: poiché non si possono far studiare gli studenti su un manuale che spiega come si costruisce Unix di proprietà della AT&T, allora è necessario costruire un sistema operativo per poi, su quest'altro, scrivere un manuale a quel punto non più censurabile.
Questo spiega tutta la portata del codice didattico che non è solo quella pedagogica. Per noi si tratta di una grossa fetta di codice libero che non è né Software Libero, né Open Source, e di cui non si può non tener conto, così come, per motivi diversi dai nostri, la stessa AT&T ne tiene conto. Se indaghiamo il Software Libero Open Source in quanto tale, ci perdiamo una grossa porzione del “paradigma open”, se non addirittura le sue origini. Sarebbe come studiare le piante ignorando le radici. Nella stessa intervista Tannenbuam non si preoccupa del fatto che Torvalds abbia usato quel manuale per costruire il sistema Linux, se ciò è accaduto significa semplicemente che tale manuale è stato utile e che ha svolto il suo compito didattico (egregiamente).
C'è molto più codice libero operante e in grado di produrre effetti, che circola “inosservato” nella rete e nei manuali, di quanto ad oggi rendano conto le ricerche empiriche sul Software Libero e sull'Open Source. Si tratta di una rizosfera vasta almeno quanto la chioma. Nel prosieguo ci riferiremo alle espressioni Software Libero e Open Source con le iniziali maiuscole proprio per sottolinearne la dimensione storica e istituzionale, che è la parte emersa e pubblica di un mondo molto più vasto.

#### Note

* ↑ Questo punto è particolarmente importante perché spiega uno casi storici più importanti che vede contrapposti alcuni grossi produttori di software e di sistemi operativi: si tratta della lunga controversia tra Netscape e Microsoft. Inglobando Explorer nel proprio sistema operativo Windows, Microsoft minacciava di rendere eseguibili sul Web i programmi compilati per Windows attraverso la tecnologia cosidetta .Net e ActiveX che permette ai browser di interpretare codice compilato. In questo modo Microsoft avrebbe potuto espandere il suo monopolio anche ad internet. Questo avrebbe significato la chiusura del codice interpretato dai browser. Attualmente Explorer utilizza ancora questa tecnologia, ma chi sviluppa con questa tecnologia esclude la possibilità di fornire servizi a chi usa browser e sistemi operativi diversi e questo è un deterrente sufficiente a scongiurare il monopolio, grazie anche al fatto che Netscape, proprio per questo fine, decise di rendere pubblico il proprio codice per poterlo diffondere e potenziare sfruttando il sostrato sociale. In sostanza si trattava per Microsoft di spostare la tecnologia verso i client, quindi i browser, quindi explorer e quindi Windows per sottrarla a quello che si chiamo “lato server” dominato da sistemi tipo Unix e Linux.
* ↑ Inserire una nota molto lunga per spiegare tutto.
* ↑ Principalemnte Open Source e Software Libero
* ↑ Il termine esposizione richiama un'espressione gergale informatica ed equivale a pubblicare qualcosa nella rete con maggiore enfasi sul rischio. Anche in questa tesi si ritiene di utilizzare lo stesso gergo informatico per sottolineare una situazione di indeterminatezza e incertezza. Una volta esposto il codice nessuno sa come questo si modificherà, se troverà consenso, disapprovazione, interesse o meno.
* ↑ Anche qui si inserisce una nuova controversia relativa al fatto che Linux debba essere classificato come open source piuttosto che come software libero. Le denominazioni, così come le definizioni delle situazioni non sono neutre.
* ↑ 23 March 2004, Kennet Brown, presidente dell'”Alexis de Tocqueville Institution”.
* ↑ Dalla ricerca empirica.