Le comunità del movimento free software/open source
Prima di applicare il termine comunità al fenomeno open source dobbiamo fare una premessa che ci metta al riparo da interpretazioni errate.
Esso, infatti, come indicato da Bagnasco , può nascondere delle trappole se si corre il rischio di considerarlo come un termine analitico piuttosto che come una metafora. Il suo uso nelle diverse scienze umane l’ha poi reso estremamente duttile e inclusivo, tanto da rappresentare contesti sociali molto differenti tra loro.
Nella sua accezione originaria, elaborata da Tönnies , il termine si riferisce a realtà sociali basate sul territorio, caratterizzate da legami forti (primo fra tutti quello di sangue), non scelti ma al contrario già dati. Le comunità così definite si caratterizzano come insiemi relativamente chiusi, dove è molto difficile entrare e altrettanto difficile uscire e il divario tra chi vi appartiene e chi non vi appartiene è molto sentito.
Le comunità virtuali, categoria in cui si inserirebbero le comunità legate al software libero/open source, rappresentano un concetto per alcuni versi opposto a questo.
La comunità virtuale, sostenuta dal computer e da e-mail, è una comunità che si crea artificialmente nella quale si può entrare e dalla quale uscire molto facilmente, dandosi regole a piacere, per fini scelti e contrattati, esattamente il contrario di quello che diceva Tönnies parlando della comunità .
D’altro canto, l’utilizzo del termine in svariate discipline ha contribuito a renderlo meno specifico, più duttile e flessibile. Proprio questa flessibilità lo rende adatto a descrivere un fenomeno nuovo, variegato e complesso come l’open source.
In un contesto sociale in cui i legami con il territorio tendono ad affievolirsi e le comunità tradizionali si sfaldano in molti soggetti autonomi e indipendenti, muta anche l’accezione del termine stesso.
Taurino propone la combinazione del concetto di comunità con quello di rete: le comunità non devono essere intese come gruppi sociali, compatti e omogenei, ma come
…espressione di una specifica forma di rapporto sociale che, svincolato dall’ancoraggio al territorio, si realizza attraverso una struttura relazionale di tipo reticolare, fondata sull’azione del soggetto e sulla sua libertà di scelta e movimento .
La comunità post-moderna non si struttura rispetto al territorio e a rapporti ereditati e tradizionali ma rispetto a legami che vengono creati sulla base di affinità di pensiero e pratiche comuni.
Quello che rimane della precedente concezione è il senso di comunità, basato sulla percezione di un’identità comune, sulla reciprocità e sulla fiducia tra gli appartenenti.
Un ruolo chiave è occupato in questo contesto dalla condivisione di simboli, storie, linguaggi. Gli artefatti collettivi costituiscono il polo intorno al quale strutturare le comunità, in mancanza di rapporti faccia a faccia prolungati e in presenza di legami relativamente deboli, mutabili e non coercitivi. Nel caso delle comunità del free software/open source le norme che regolano le comunità sono in genere norme riguardanti gli artefatti e l’approccio da adottare nei loro confronti.
L’apertura delle comunità virtuali, diversamente dalle comunità tradizionali, da vita a comunità multiple, dai confini incerti, che si strutturano su più livelli: la struttura reticolare sottostante permette un dialogo costante tra singole comunità (nel caso del software libero/open source quelle che si formano attorno ad un unico progetto), comunità immaginate, presenti più come idea che come reale interazione (nel nostro caso, la comunità del free software e la comunità open source) e comunità a base territoriale che si intersecano con le precedenti (si pensi ai gruppi di supporto agli utenti Linux, i Linux Users Groups, detti LUGs).
Proporremo un’analisi degli usi e delle norme che regolano le comunità del software libero/open source, descrivendone le consuetudini e i modi in cui i progetti nascono e si sviluppano e cercando di capire come avviene il processo di socializzazione tra i partecipanti, per poi situare concettualmente queste specifiche comunità all’interno del contesto più generico delle comunità virtuali.
Ogni progetto nasce dall’iniziativa di un singolo o di un gruppo di sviluppatori, che contribuiscono rilasciando una prima porzione di codice. Essi vengono considerati a tutti gli effetti proprietari del programma e denominati manutentori.
Come nota Raymond,
…la cultura open source possiede una serie di usi e costumi sulla proprietà, elaborati ma essenzialmente non dichiarati. Essi stabiliscono a chi e in quali circostanze sia consentito modificare il software, e (soprattutto) chi abbia il diritto di ridistribuire nuovamente le versioni modificate alla comunità.
Nonostante le licenze indichino che chiunque può ridistribuire versioni modificate di un programma, nella pratica questo è un privilegio riservato ai manutentori del progetto.
Sono accettate versioni modificate di un programma sviluppate per soddisfare esigenze individuali da persone non appartenenti al gruppo dei manutentori, ma sono scoraggiate le distribuzioni dirette all’intera comunità.
Leggi informali regolano le procedure di acquisizione della “proprietà” di un progetto abbandonato: l’interessato deve rendere pubblica la sua intenzione di prendersi in carico un progetto attraverso forum e mailing lists, far passare del tempo in modo che il manutentore precedente abbia la possibilità di manifestare le sue volontà, (tra le quali la possibilità di delegare un successore), infine dimostrare attraverso donazioni di codice la sua competenza tecnica.
Un grande sforzo viene fatto da tutti i programmatori per annotare i nomi di tutti i contribuenti e per gestire la cronologia delle modifiche.
L’omissione o la cancellazione del nome di uno sviluppatore nei crediti del programma è ritenuta un’azione molto grave, denunciata dai partecipanti con molta forza e avviene raramente.
Il forking è considerato negativamente da tutta la comunità perché provoca una duplicazione del lavoro collettivo. Esso viene accettato solo quando la scissione dà corpo a due progetti estremamente differenti tra loro, che coprono diversi campi applicativi.
Nelle discussioni attraverso mailing list e forum emerge anche la tendenza diffusa nei programmatori “anziani”, cioè quelli che hanno maggiore visibilità e considerazione all’interno della comunità open source, a esprimersi con umiltà ed evitare atteggiamenti auto-celebrativi. I leader ottengono la fiducia dei partecipanti soltanto assicurando che le scelte riguardanti le porzioni di codice da inserire all’interno della versione ufficiale di un programma vengono presi in base a criteri condivisi riguardanti la qualità.
La selezione basata sul merito è fondamentale per garantire il carattere di apertura della comunità.
Queste regole informali, alle quali gran parte degli hackers open source si attengono, sembrano svolgere, a detta di Raymond, la funzione di
…stimolare maggiore responsabilità pubblica, maggiore attenzione collettiva e maggiore cura nel preservare i nomi dei partecipanti e le cronologie delle modifiche in ogni progetto, così da stabilire, tra l’altro, la legittimità dei proprietari correnti .
Nell’ottica dell’autore, le norme precedentemente descritte servirebbero a incentivare la collaborazione attraverso il gioco della reputazione tra pari.
Questo punto mette il luce il forte aspetto relazionale delle comunità free software/open source. Non si contribuisce solamente per motivazioni utilitaristiche, benché queste siano sempre presenti, ma anche per mettersi in relazione con un gruppo di persone che condivide interessi, etiche e pratiche comuni.
Il fatto di basarsi su donazioni di codice conferisce alle comunità virtuali free software/open source caratteristiche peculiari. Infatti,
L’ingresso in una relazione di scambi di doni implica un’ indebitamento perenne, un coinvolgimento in relazioni personali che limitano la libertà di interrompere a proprio piacimento la relazione .
L’instaurazione di un rapporto di reciprocità basato sul dono conferisce nuove caratteristiche alle comunità virtuali di tipo free software/open source.
I legami che contraddistinguono le comunità virtuali sono spesso indicati come deboli, specialmente in relazione ai legami di tipo primario: la grande libertà lasciata ai singoli individui può spingerli a uscire ed entrare molto facilmente.
Tuttavia, in linea con Mannarini crediamo che la presenza di norme ed etiche condivise e l’attribuzione di grande importanza alla dimensione relazionale e dello stare insieme possa contribuire a rendere più stabili i legami virtuali.
Nel caso delle comunità free software/open source i legami sono ulteriormente rafforzati dalla presenza del dono, che costituisce la base intorno alla quale si costruisce la comunità. E’ infatti attraverso di esso che le comunità riescono a limitare il fenomeno del free riding.
Se poi consideriamo le peculiarità del digitale, comprendiamo come il software, e soprattutto il codice sorgente del software, costituisca un tipo di dono del tutto particolare. I bassi costi di riproduzione del software, la non deperibilità del bene in questione e la possibilità di lavorare servendosi di un’infrastruttura decentrata e aperta rendono economico e conveniente lo scambio di doni. Esso appare ancora più conveniente in un campo come l’informatica in cui il livello dell’innovazione e della complessità è molto alto. Il pieno accesso alle conoscenze reciproche che si ottiene attraverso la collaborazione è centrale. Le licenze free software/open source offrono poi l’ulteriore garanzia che i doni rimarranno disponibili a tutti, andando a costituire una sorta di bene pubblico.
Le comunità free software/open source riescono a conciliare l’apertura, la propensione volontaristica e la libertà individuale tipica delle comunità virtuali con un senso di identità di gruppo e un richiamo all’obbligatorietà della partecipazione più vicino (anche se molto differente) a quello delle comunità tradizionali di tipo amicale .
Grandi sono i legami che congiungono le comunità free software/open source con il mondo accademico: la collaborazione e lo scambio frequente di conoscenze sono fondamentali per gestire la complessità dei sistemi e i frequenti cambiamenti cui sono sottoposti.
Edwards propone il paragone tra le comunità free software/open source e le comunità epistemiche descritte da Haas , elencando le seguenti caratteristiche comuni:
- A shared set of normative and principled beliefs, providing a value based rationale for the social action of community members;
- Shared causal beliefs, which are derived from their analysis of practice leading or contributing to a central set of problems in their domain and serving as the basis for elucidating the multiple linkages between possible policy actions and desired outcomes;
- Shared notions of validity – that is, intersubjective, internally defined criteria for weighing and validating knowledge in the domain of their expertise;
- A common policy enterprise – that is, a set of common practices associated with a set of problems to which their competence is directed, presumably out of the conviction that human welfare will be enhanced as a consequence ;
Nel nostro caso, i programmatori free software/open source hanno una serie di principi comuni, quali la convinzione che il software proprietario restringa la libertà degli utenti e la loro possibilità di scelta e l’opposizione ai brevetti sul software, considerate un grande ostacolo per i programmatori e particolarmente nocive per l’innovazione.
Condividono criteri di scelta derivati dagli studi (generalmente nell’area tecnico-informatica) e dalla conoscenza del progetto a cui partecipano. Da questi criteri dipenderà poi il futuro sviluppo del progetto stesso.
La presenza di comuni criteri di validità rende più facile la scelta delle patch da includere nelle nuove release e contribuisce ad attenuare i conflitti tra gli sviluppatori, desiderosi di vedere i propri contributi inseriti nelle distribuzioni ufficiali.
I criteri di validità riguardano anche il linguaggio utilizzato e il modo di proporsi alla comunità, che dipendono anche dallo status reputazionale dello sviluppatore stesso.
La presenza di obiettivi comuni, come lo sforzo di creare programmi liberi che costituiscano un’alternativa al software proprietario crea un quadro di riferimento che rende più dirette e semplici le conversazioni tra sviluppatori che non si conoscono e suggerisce temi di discussione.
Le istanze comuni qui descritte sono decisive nel contesto di interazione in remoto, creando un quadro di riferimento che può essere dato per scontato, riducendo in tal modo le possibili ambiguità che possono nascere nella comunicazione tra i partecipanti.
Nella visione di Haas le comunità epistemiche emergono in presenza di alti fattori di incertezza. Il paragone tra queste e le comunità del free software/open source sembra calzante visto il contesto informatico, caratterizzato da enorme complessità e necessità di aggiornamenti continui.
Ci interessa qui capire come i partecipanti sviluppino le competenze, i valori, i metodi di valutazione e i linguaggi sopra evidenziati in un contesto particolare, basato su di una infrastruttura decentrata.
Possiamo suddividere i partecipanti al processo di sviluppo di un progetto in almeno tre categorie principali:
- Manutentori: sono gli sviluppatori autorizzati a rilasciare le versioni ufficiali del programma. Sono le persone che hanno maggiore voce in capitolo sulle scelte riguardanti le direzioni che il progetto prenderà. Si occupano, oltre a contribuire con il proprio codice alla scrittura del programma, di rivedere, correggere e inserire nelle release il codice proveniente dai collaboratori. Generalmente questa categoria è costituita da persone con grandi abilità di programmazione ed esperienza consolidata nel mondo dell’open source.
- Collaboratori: si tratta di persone coinvolte in svariati modi in un progetto open source. Contribuiscono attraverso donazioni di codice, fissaggio o semplice segnalazione dei bug, ma anche attraverso meno impegnative discussioni all’interno dei forum o attraverso mailing lists. Possono in qualche modo essere considerati collaboratori anche le persone che cercano informazioni e chiedono agli utenti più esperti informazioni sull’uso del programma, in quanto danno il loro contributo mettendo in luce possibili problemi di usabilità del software.
- Utilizzatori: sono quelle persone che utilizzano il software ma non partecipano in alcun modo al processo di sviluppo, nemmeno lasciando commenti o domande nei forum.
Quest’ultima categoria di utenti è di vitale importanza per i progetti open source, perché spesso costituisce il bacino dal quale nascono nuovi sviluppatori.
Alcuni utilizzatori, inizialmente percepiti come esterni dalla comunità, intraprendono un processo di socializzazione e di apprendimento che li porterà a diventare parte di essa, interiorizzandone le istanze comuni sopra descritte.
Alcuni di essi, infatti, spinti spesso dal desiderio di risolvere un problema riscontrato nell’uso del programma, iniziano a postare delle domande nei forum, cominciando ad interagire con gli utenti più esperti e maturano il desiderio di inserirsi all’interno della comunità.
I concetti sviluppati da Lave e Wenger , poi applicati al contesto open source da diversi autori , di communities of practice e di apprendimento contestuale, ci offrono un’ulteriore spunto per comprendere come avvenga il processo che porta i normali utenti a diventare parte della comunità di sviluppatori.
Le communities of practice sono gruppi di persone che si costituiscono sulla base di interessi e pratiche comuni. L’apprendimento all’interno di questi gruppi si attualizza attraverso l’interazione tra i partecipanti. Il sapere è strettamente connesso con il contesto in cui viene usato ed è un tutt’uno con le relazioni sociali che si creano nell’interazione tra i partecipanti e l’ambiente in cui si sviluppa.
I principianti non vengono a contatto con conoscenze astratte ma con indicazioni estremamente mirate al compito che stanno svolgendo.
Nonostante le osservazioni di Tzouris , che notano come la teoria di Lave e Wenger non si riferisca ad un contesto di lavoro remoto e distribuito, ci sembra plausibile considerarla adatta ad analizzare le comunità free software/open source.
Se ogni sviluppatore lavora in solitudine davanti al proprio computer, è vero anche che ha a propria disposizione una serie di strumenti di interazione in tempo reale e non, quali IRC , forum, mailing list e programmi telefonici peer-to-peer , che rendono il contesto lavorativo più ricco e simulano la situazione del lavorare insieme.
Gli utenti divengono collaboratori a tutti gli effetti attraverso un’apprendimento che ha come punto di partenza l’inserimento immediato nella comunità in qualità di principianti. Gli appartenenti alla comunità accettano la presenza della legitimate peripheral participation descritta da Lave e Wenger , in cui i principianti vengono accettati come membri periferici all’interno di una comunità con il ruolo di apprendisti.
Attraverso questo apprendimento situato nel contesto comunitario gli apprendisti acquisiscono non solo abilità di programmazione, ma anche un linguaggio specifico, uno stile comunicativo e un particolare approccio al lavoro di gruppo.
Nel processo open source gli utenti rappresentano la risorsa potenziale attraverso la quale reclutare nuovi partecipanti.
La trasparenza e l’apertura degli artefatti e dei processi nel modello free software/open source danno vita ad un nuovo tipo di rapporto tra progettista e utente finale, che si attualizza mediante il livellamento delle barriere comunicative tra le due figure.
Bollier guarda al movimento free software/open source come ad un movimento dei consumatori, in cui gli utenti di computer riacquistano gradualmente il controllo dei mezzi che usano. Non sono più semplici fruitori costretti a scelgliere tra una relativamente ampia varietà di prodotti messi a punto dalle aziende, ma parte integrante e attiva del processo di indirizzamento e creazione degli strumenti adatti a soddisfare i propri bisogni.
Il software si trasforma quindi da semplice prodotto che viene creato, venduto e comprato, in “a new kind of knowledge and community-building infrastructure ”.
Segnala questa pagina a qualcuno
Stampa questa pagina