Il sociologo, la sociologia e il software libero: open source tra società e comunità/Capitolo 4/3

Da Wikisource.
Jump to navigation Jump to search
4.3 Il carisma e l'istituzionalizzazione nel software libero

../../Capitolo 4/2 ../../Capitolo 5 IncludiIntestazione 20 agosto 2011 75% Da definire

Capitolo 4 - 2 Capitolo 5

I valori che Himanen (2001) riporta come appartenenti all'open source sono: passione, libertà, coscienza sociale, verità, antifascismo, anti-corruzione, lotta contro l'alienazione dell'uomo, eguaglianza sociale, accesso libero all'informazione (cultura libera), valore sociale (riconoscenza tra simili), accessibilità alla rete, attivismo, responsabilità, creatività. L'imputazione di alcuni di questi valori al fenomeno Open Source può però essere dialettico, in effetti si può notare come molti di questi siano assolutamente coerenti. La libertà e la sensibilità nei confronti dei diritti degli utenti è un punto qualificante del movimento del Software Libero e del suo leader Richard Stallman. La passione è assolutamente coerente con lo stato di flusso visto precedentemente. La verità può essere ricondotta ad un concetto di verità scientifica falsificabile in senso popperiano che si esprime attraverso l'apertura del codice. La lotta contro l'alienazione può essere ricondotta ad un principio di integrazione intellettiva collettiva contraria di conseguenza ad una visione parcellizzata ed industriale del software. Il valore sociale, come emerge più volte in questo studio, fornisce molta della motivazione. La creatività è legata alle competenze emotive, cognitive e progettuali. L'attivismo è evidente. La responsabilità rientra in una dimensione professionale. L'accesso libero all'informazione costituisce un fattore importante per limitare l'entropia, come si vedrà più avanti.

Tutto questo non entra esplicitamente nelle attività delle diverse communities impegnate nell'open source e nel software libero. Anche nei documenti costituivi della Free Software Foundation, dell'Open Source Defination, nella costituzione sociale Debian i cenni ai valori morali ed etici che riporta Himanen (2001) non sono così esaustivi. Si tratta di documenti molto brevi, lunghi una o due pagine, concisi così com'è lo stile hacker. Una apparente contraddizione sta nel fatto che nei forum di discussione questi elementi non emergono, non vengono esplicitati perché eccetto la peculiarità del valore liberale nel software libero, ribadito più volte e scritto nei documenti costitutivi, un valore implicito che costituisce una norma altrettanto implicita è quella di non mescolare questione tecniche con questioni politiche o morali. I valori che richiama Himanen non sono richiesti come condizioni per partecipare, emergono in modo puntiforme, con diverse accentuazione nelle diverse epoche e nei diversi progetti. Ciò che resta costante è invece la dimensione professionale e le competenze, anche nel caso del progetto Debian dove la sua costituzione, più di ogni altro progetto si rifà a valori democratici1, resta centrale il possesso di competenze. Il programma elettorale di Stefano Zacchiroli eletto Project Leader Debian nel 2010 annovera, oltre alle intenzioni strategiche, anche una serie di competenza in termini di partecipazione a diversi progetti.

La partecipazione riguarda per lo più attività di diffusione del software libero, soluzioni tecniche e organizzazione. La discussione su tematiche valoriali che riguardano argomenti con possibili connotazioni politiche rischiano di disaggregare la community, rischiano di connotare politicamente il software libero, di creare conflitti interni e di distogliere dagli obbiettivi principali. C'è quindi una norma implicita che impone di attenersi a temi circoscritti alla creazione e diffusione del software libero. Si tratta di un agire professionale e discreto, chi vuole rendersi utile lo deve fare con umiltà. Questo è ciò che consente una certa adattabilità del software libero, di mantenersi aperto alle diverse culture, confessioni e appartenenze perché il suo obbiettivo principale è la diffusione. Oltre a questa norma implicita è operante anche una regola costitutiva che riguarda il funzionamento dello strumento software attorno al quale si delinea il progetto con dinamiche bottom-up. Questa è il criterio della funzionalità, quindi una soluzione è giusta o sbagliata in base al fatto che funzioni o meno.

Se si dovesse individuare un leader di un tale movimento esteso, diffuso e policentrico, che comprenda l'open source e il software libero, questo è senz'altro Linus Torvalds. La sua capacità di leadership non nasce tanto dalle sue abilità oratorie, morali o politiche ma da ciò che è stato in grado di fare in termini di competenze tecniche, sviluppando un kernel funzionante, e organizzative aggregando attorno a questo progetto programmatori da tutto il mondo. Ha quindi dimostrato competenze tecniche e organizzative non comuni, o per meglio dire, Weberianamente, presenta quelle qualità eccezionali necessarie ad un leader perché sia tale. Il sistema operativo Gnu/Linux che nasce con questa dinamica è assolutamente centrale così come è centrale la leadership di Linus Torvalds che ne richiama il nome. Gnu/Linux è anche un pseudo-acronimo che si riferisce LINus UniX. L'identificazione di Linus Torvalds con il sistema operativo Gnu/Linux è resa ancora più evidente dal fatto che venga spesso indicato con il sopranome di Linux Torvalds. Questa centralità è inevitabile dal momento in cui non esistono, per il momento, sistemi operativi open source alternativi. Anche se val pena menzionare il progetto MINIX iniziato da Andrew S. Tanenbaum famoso per la controversia con lo stesso Linus Torvalds e che viene rilasciato con una licenza di tipo open source.

Il processo di istituzionalizzazione di un progetto che ha successo è in genere molto rapido. Nel caso del kernel Gnu/Linux dopo la diffusione nella rete delle prime versioni nei primi anni '90 del secolo scorso, in cui chiunque riesca ad implementare delle soluzioni e a risolvere problemi può partecipare, il progetto si chiude. Rimangano i programmatori della prima ora e vengono definite delle regole operative. Ciò che si diffonde non è solo il sistema operativo, ma l'idea che ci sta dietro che viene imitata. Altri progetti nascono con la stessa dinamiche e, anche se l'implementazione del kernel resta riservata, si iniziano progetti ad un livello più alto. Si tratta delle interfacce grafiche di cui le più famose sono KDE, di derivazione commerciale poi “liberata”2, e GNOME di derivazione liberale. Su queste interfacce grafiche, che hanno l'importanza, finalmente, di costituire una reale alternativa al sistema Windows, si inseriscono poi altri progetti di implementazione che completano il sistema operativo e lo rendono usabile e completo anche per gli utenti comuni. Si tratta ad esempio di Debian, Fedora, Ubunto, Mint e molte altre. Intervengono finanziamenti di società come IBM, Sun Microsystems, Hewlett-Packard, Red Hat e Novell.

Questa frammentazione del software libero è una conseguenza del processo di istituzionalizzazione. Nel momento in cui viene mobilitata una notevole quantità di energia questa non può essere assorbita da un solo progetto e quindi è necessario che la partecipazione venga limitata e la produzione regolamentata. L'energia lasciata libera si riorganizza in altri progetti satellitari i quali a loro volta si istituzionalizzano. La differenza di questi altri progetti sta nel fatto che per quanto attiene il kernel Gnu/Linux, cioè il progetto principale, il leader resta lo stesso, mentre negli altri progetti i leader se ne vanno, occupano posizione di rilievo in altre società e cedono il posto a dei leader di funzione. Questo è quanto accade con Rasmus Lerdorf iniziatore del linguaggio PHP, Ian Murdock fondatore di Debian e autore della prima costituzione Debian e così molti altri. Il processo di istituzionalizzazione comporta quindi per il progetto principale del kernel il rafforzamento della leadership carismatica e per gli altri progetti satelliti il passaggio a leadership di funzione.

L'istituzionalizzazione dei progetti, specie se molto estesi e di successo, comportano anche la differenziazione di organi e funzioni interne riconducibili al modello AGIL di Parsons, Così Stefano Zacchiroli nell'intervista del 17 agosto 2010 descrive la struttura organizzativa Debian:

Quindi ci sono tutti gli strumenti per far funzionare la costituzione Debian:

  • 1. Il project leader, ci sono i suoi delegati. Il segretario e tutti i macchinari che servono per fare andare avanti i meccanismi di voto.
  • 2. Il comitato tecnico, nel caso ci siano conflitti di natura tecnica tra persone all'interno del progetto. È una specie di, come dire, tribunale a cui ci si può appellare per risolvere conflitti di natura tecnica.
  • 3. Quelli che chiamiamo core teams, che hanno dei ruoli specifici e che sono in quanto su carta delegati del proprio project leader, ma che hanno dei ruoli politici abbastanza importanti anche se vuoi di divisione dei poteri.
  • 4. Il cosiddetto DAM, Debian Account Manager, che sono un gruppo di persone che decide chi può diventare sviluppatore Debian e chi no.
  • 5. C'è il gruppo di DSA, Debbian System Administrator, che sono quelli che mantengono tutte le macchine, tutti i server del progetto Debian in giro per il mondo, ed in generale tutta la infrastruttura tecnica.
  • 6. Un gruppo chiamato FTP masters, che sono quelli responsabili su cosa entra nell'archivio software Debian e cosa no, e che hanno un potere molto significativo, nel senso che sono quelli che decidono al momento quali sono le licenza che sono accettabili nell'archivio Debian, decidono quando un pacchetto non raggiunge i criteri minimi di qualità per entrare nell'archivio.
  • 7. C'è un gruppo di Keyring Manager che sono quelli che gestiscono il gruppo di chiavi e di firme digitali che servono a firmare i pacchetti che possono entrare nell'archivio.
  • 8. Il release team che è un gruppo di persone responsabili di valutare il programma verso una release Debiano che è l'outcome principale di un progetto come Debian, fare una nuova release.

Gli FTP masters e i Debbian System Administrator, ad esempio svolgono una funzione economica (adaptetion), approvvigionano beni e servizi. La funziona politica (goal attainment) di garanzia della sicurezza interna ed esterna è svolta da Comitato tecnico, dai core teams e i Debian Account Manager. La funziona normativa (integration) è svolta dai Keyring Manager e Core teams. La funzione riproduttiva (latency) è svolta dal Release Team.

Il processo di istituzionalizzazione rappresenta anche per il software libero, come per tutte le organizzazioni, una fase critica, in cui l'accento si sposta da una fase emozionale collettiva ad una fase normativa. Ciò che diviene a rischio è l'identità, la positività del modello auto-rganizzato. Nell'intervista a Stefano Zacchiroli emerge tutta questa preoccupazione di dover tenere le fila di un progetto che assume dimensioni globali ma che non vuole perdere la sua peculiarità di modello di libertà. Si è sostenuto che il sostegno morale, inteso come possibilità di senso che nasce dalla consapevolezza che si sta facendo qualcosa di “importante”, ed il sostegno etico, inteso come stile e atteggiamento professionale sono ciò che consentono al software libero di competere con il software proprietario sulla capacità di rispondere a bisogni.

[...] Anche le tattiche specifiche necessarie per spingere la strategia apparivano ormai chiare sin dall'inizio e furono infatti discusse nel primo incontro. Ecco le tematiche principali: 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. La conclusione inevitabile era che bisognava abbandonare la prima impostazione e passare a imporre le decisioni dall'alto, cercando quindi di coinvolgere in primo luogo i dirigenti delle alte sfere. (Eric Steven Raymond, 2000)

Forse quello a cui assistiamo è un processo che porterà ad un compromesso, oppure come accade spesso nel software, saranno nuovi “forks” - progetti collaterali più piccoli che si staccano da quello principale per dare vita a nuovi progetti – a farsi carico di istanze di libertà, mentre l'industria che vi investe sempre più capitali, e i processi di istituzionalizzazione colonizzano progressivamente l'open source. Ed anche in questo caso, non è detto che le organizzazioni industriali non si lascino sedurre dai modelli comunitari del software libero.

Note

  1. Per liberazione si intende la trasposizione di un software proprietario a software GPL