Il sociologo, la sociologia e il software libero: open source tra società e comunità/Capitolo 5/4
 |
Questo testo è completo. | |
| ◄ | Capitolo 5 - 3 | Conclusioni | ► |
Rispetto alla teoria dell'azione di Talcott Parsons che prevede una struttura le cui parti sono dedite alla mobilitazione di energia ed altre alla mobilitazione dell'informazione, Luhmann attraverso l'auto-poiesi giunge ad una visione meno scontata dell'ordine e soprattutto ad un'idea di ordine, se tale si può definire, come uno dei tanti possibili. In questa concezione funzionalista l'informazione assume una specificità diversa. Non più dai livelli gerarchici più elevati a quelli più bassi ma attraverso dislivelli informativi che si verificano nel sistema senza seguire un piano prestabilito.
Il dislivello informativo è ciò che consente in ultima analisi la dinamica informativa, senza questo presupposto non ci sarebbe informazione, poiché senza differenze non è possibile la distinzione di differenze. L'informazione nasce come distinzione di differenze, quindi un sistema con poche differenza è un sistema entropico non in grado di adeguarsi. Per contro un sistema sufficientemente complesso è in grado di produrre grossi effetti a partire da piccole differenze. Un sistema sufficientemente complesso è in grado quindi, non solo di trasferire informazione, ma di costruire informazione amplificando la devianza (Luhmann, 2007, p. 72).
È interessante notare come Vixie (2000) descriva il processo di produzione software proprietario come fasi rigidamente sequenziate, tali per cui la fase successiva non può avviarsi se prima non è stata completata la precedente (modello top-down), mentre il modello di produzione open source risponde a criteri autonomi, spesso spontanei ed originali bottom-up. Il primo modello corrisponde ad un idea organizzativa di sistema come la prevede Parsons, mentre il secondo modello corrisponde ad un processo dove l'innesco delle diverse fasi di sviluppo è contingente al dispiegarsi dei flussi informativi. A questo diverso approccio corrisponde anche lo scambio di corrispondenza tra Linus Torvalds, ancora studente presso l'università di Helsinki, e Andrew Tanenbaun, docente di sistemi operativi alla libera università di Amsterdan:
Torvalds: se questo fosse l'unico criterio per la “bontà” di un kernel avresti ragione. Quello che non menzioni è che minix non fa le cose del micro-kernel molto bene e ha problemi con il vero multitasking (nel kernel). Se io avessi un sistema operativo che avesse problemi con il vero file di sistema multithreading, non condannerai altri così facilmente: infatti, farei tutto il possibile perché venga dimenticato il fiasco.
Tannenbaun: ...Un file di sistema multithread è solo uno sfizio per le prestazioni. Quando c'è solo un processo attivo, il caso tipico di un piccolo PC, non porta nulla ed aumenta la complessità del codice. Nelle macchine abbastanza potenti da sopportare la multiutenza avresti abbastanza buffer nella cache da assicurare ad ogni porzione di cache una porzione di cicli, nel qual caso ugualmente non ti fa guadagnare nulla. Hai qualche vantaggio solo con multiprocessori che fanno fisicamente I/O. Ma anche in questo caso complicare il sistema e quantomeno discutibile
Nonostante il linguaggio esoterico ciò che emerge è il diverso approccio alla complessità. Nella disciplina informatica è, a distanza di vent'anni, ancora vigente e più che operante il paradigma top-down. Per cui molte risorse vengono investite nella progettazione e quindi le informazioni vengono passate ai sistemisti e ai programmatori per lo sviluppo. Il paradigma opposto è quello per cui degli sviluppatori sperimentano dei successi su cui poi chiedono investimenti. In quest'ultimo caso ciò che si verifica non è una direzione lineare dell'informazione dal basso verso l'alto ma un emergere sistemico dell'informazione. In pratica questi due paradigmi, il top-down e il bottom-up sono i corrispettivi modelli informatici dei due diversi modelli funzionalisti, il primo Parsonsiano e l'altro Luhmanniano.
Se si nota i termini usati non sono esattamente reciproci, l'uno l'opposto dell'altro, non indicano due direzione opposte dell'informazione, ma due diverse dinamiche dell'informazione, l'una unilineare da un punto gerarchico ad un altro punto inferiore e l'altra emergente (multithread) dal basso verso l'alto. Nella prima definizione il basso viene indicato con “down”, mentre nella seconda definizione il basso viene indicato con “bottom” che da più l'idea di base. Lo stesso si può dire per “top” e “up”. La prima definizione top-down esprime una direzione dell'informazione da un punto ad un altro, nel secondo caso un emergere dell'informazione da un livello ad un altro. La cosa interessante e paradossale è che quando viene fondato la OSD (Open Source Defination) si innesca un processo di istituzionalizzazione che invoca il top-down:
[...] Dimenticare la strategia "bottom-up"; puntare sulla strategia "top-down"
Ci appariva ormai chiaro che la strategia storica seguita per Unix, vale a dire la diffusione dei concetti dal basso verso l'alto, partendo cioè dai tecnici per giungere poi a convincere i boss con argomentazioni razionali, si era rivelata un fallimento. Era una procedura ingenua, di gran lunga surclassata da Microsoft. Inoltre, l'innovazione di Netscape non avvenne in quella direzione, ma fu resa possibile proprio perché un importante personaggio di livello strategico, quale Jim Barksdale, aveva avuto l'intuizione e l'aveva imposta ai suoi subordinati. (Eric Steven Raymond, 2000).
Linux nasce assolutamente con un processo bottom-up mentre il processo di istituzionalizzazione si orienta al top-down, legittimando questa scelta con il successo di questo paradigma nel caso Netscape. Netscape nasce in contesto industriale e solo successivamente diventa open source, ed anche la sua “liberazione” non può che essere coerente con una logica top-down. Ciò che emerge è l'idea di organizzazione come ordine, semplificazione e contenimento dell'incertezza.
Già da qui si evince che non esiste mai una scelta totalmente spostata da una o dall'altra parte. E ' però evidente una maggiore tendenza dell'organizzazione open source ad adottare processi bottom-up ed una maggiore tendenza dei sistemi industriali di produzione di software ad adottare una struttura top-down. Proprio per la sua diversa dinamica dell'informazione possiamo ipotizzare non una semplice classificazione tra questi due paradigmi, ma una sostanziale differenza della loro natura. Luhmann distingue tra strutture e processi, dove le strutture hanno una maggiore tendenza a trattenere il tempo diminuendo l'incertezza, mentre i processi segnano il carattere irreversibile del tempo. Entrambe queste strategie rispondono al problema della complessità inevitabili quando i sistemi aumentano di dimensione e assumono dimensioni planetarie. La complessità presuppone l'adozione di criteri selettivi, attraverso strutture o processi, in quanto non è possibile mantenere tutte le connessioni (possibilità) aperte.
Luhmann non ci offre una classificazione di sistemi sociali in base alla quale distinguere quelli che privilegiano più la struttura e quelli che privilegiano più il processo ma solo dei criteri. La differenza tra questi due sta nel fatto che le strutture operano le selezioni in base a criteri di validità, mentre i processi attraverso la temporalizzazione degli elementi e si rifanno al criterio dell'adattamento. L'adattamento consiste nella diversità degli elementi che si susseguono, la stabilità del sistema in generale è raggiunta grazie all'instabilità dei suoi elementi. Ciò che è importante notare è che nel modello bottom-up viene meno il bisogno di criteri di validità preordinati tipici del modello top-down. Il criterio di validità è raggiunto grazie all'accelerazione del processo selettivo.
Si pensi ad esempio alla continua interazione nei diversi progetti open source tra utenti e sviluppatori software. Questo non ha corrispondenza nel software chiuso, se non attraverso canali istituzionalizzati di assistenza definiti contrattualmente. Anche in questo caso si segnala la rapidità e spesso il rapporto diretto sviluppatore utente, tale per cui un problema rilevato da un utente viene spesso risolto seduta stante. Inoltre val la pena riprendere la tesi Gian Antonio Gilli per cui l'attività del portatore di téchne deve necessariamente essere mediata da altre figure professionali. Nel caso dell'open source il programmatore si può liberamente e direttamente relazionare con gli utenti, è di fatto fuori controllo e questo a maggior ragione rafforza l'idea di un sistema caotico a bassa entropia.
Esempi di temporalizzazione sono evidentissimi nel mondo open source. I sistemi operativi proprietari più importanti che si sono susseguiti vantano alcune versioni che si susseguono sequenzialmente. Le cosiddette “distro”, cioè distribuzioni, di Gnu/Linux, pacchetti personalizzati a seconda delle diverse esigenze, sono innumerevoli e contemporanei. A parte le principali distribuzioni da PC, con le diverse interfacce grafiche (Gnome, KDE, XFCE, LXDE) da cui si differenziano diverse interfacce utente Debian, Ubuntu, Fedora, Suse, Mandriva mantenute da altrettanti gruppi e svariati sottogruppi di specifici applicativi, le diverse versioni si susseguono freneticamente. A questo si aggiungano diverse personalizzazioni di personalizzazioni. In 5 anni Ubuntu ha raggiunto 10 versioni, Windows a partire dal 92 al 2010 annovera le versioni: 3.1, 95, 98, NT, XP, Vista, sette.
Naturalmente questo non è indice di qualità, anche se le differenze qualitative sono inevitabili, ma queste si misurano con tecniche di benchmarking e non in base al numero di versioni come spesso semplicisticamente si pensa. Piuttosto questo è indice di un diverso modello sistemico: strutturale per i sistemi operativi proprietari; processuale per i sistemi open. Il paradosso organizzativo di Gnu/Linux è uno degli argomenti più discussi e consiste nel fatto che secondo molte teorie dell'organizzazione non sarebbe possibile tenere sotto controllo una tale complessità. La questione in realtà sta a monte delle teorie dell'organizzazione che si occupano di processi di produzione, è in realtà una questione sistemica, ciò che rende possibile il controllo è proprio, in definitiva, la complessità. La semplificazione dell'ambiente può essere attuata attraverso la complessificazione interna al sistema (Luhmann, 1988). In altre parole, a parte settori molti organizzati di produzione di software open source, spesso si tratta di un emergere della tecnologia da dinamiche sociali non istituzionalizzate che non possono essere facilmente confrontante con i sistemi industriali di produzione del software da un punto di vista meramente organizzativo orientato alla produzione.
Luhmann, nonostante la necessaria chiusura, o in quanto alla chiusura, cioè separazione dall'ambiente dei sistemi, distingue tra sistemi chiusi e sistemi aperti complessi. Nella realtà non esistono sistemi chiusi ma solo sistemi più o meno aperti. Ad una maggiore apertura corrisponde un maggior disordine, una maggiore difficoltà di prevedere il futuro in base a criteri di validazione, e quindi maggiore incertezza. Per contro un sistema maggiormente complesso e temporizzato presenta maggiore velocità, e capacità di adattamento a scapito di una maggiore incertezza espressa come bisogno di ordine e prevedibilità. È per tale motivo che i processi di istituzionalizzazione non possono che proporre il modello top-down.