Le sei limitazioni dell'attuale metodologia di sviluppo open source
Felix Stalder
[translated by Paolo M. Pumilia <pol AT linfe.it>, 09.2003]
Riassunto
L'attuale modello di sviluppo open source si basa su un preciso numero dicondizioni, non sempre evidenti, che limitano la sua applicabilità a contesti molto disparati, come la distribuzione di musica o la ricerca in prodotti medicinali.
Le sei limitazioni dell'attuale metodologia di sviluppo open source
From: Felix Stalder <felix AT openflows.org>
Date: Thu, 14 Aug 2003 17:33:50 +0200
L'approccio "Open Source" per lo sviluppo di beni a contenuto informativo ha avuto un successo strepitoso in quell'area per il quale è stato sviluppato, il campo del software.
Ci sono importanti progetti open source anche al di là del software, come l'Enciclopedia Wikipedia gratuita, i progetti di siti collaborativi per scrivere/pubblicare come kuro5hin.org; il progetto di correzione di bozze distribuita, che è parte del progetto Gutenberg. Tuttavia i progetti open source rimangono relativamente a margine, specialmente se estranei al campo del software. Perchè?
In parte ciò può essere spiegato con la novità dell'approccio; ci vuole tempo affinchè le nuove idee facciano presa e riescano a trasferirsi da un contesto ad un altro. Ma tale spiegazione rende conto solo in parte della realtà. Va infatti anche osservato che l'attuale modello di sviluppo si basa su alcune precise condizioni, non sempre evidenti, che ne limitano l'applicabilità in contesti distanti, come la produzione musicale o la ricerca di prodotti medicinali.
I contorni del modello di produzione aperta, come si è affermato nell'ultimo decennio, sono determinati da sei condizioni che caratterizzano praticamente tutti casi di successo di quella che Benkler chiama "commons-based peer production."
L'elenco che segue propone una astrazione concettuale di tali condizioni limitanti, una sorta di classificazione per tipi ideali che forniscono, nel complesso, il campo di validità del modello attuale, anche se realizzazione concreta di tali limitazioni ed il loro relativo peso possono variare da progetto a progetto.
Gli esempi a cui faccio riferimento sono tratti da progetti di open source e free software, ma non sarebbe difficile basare le argomentazioni su casi di 'open content'.
1. Produttore e distributore ben distinti.
La maggior parte dei programmatori professionisti non basa le proprie entrate economiche direttamente dalla vendita dei programmi che scrive. Molti lavorano per una organizzazione che usa il software, ma non lo vende.
E' il caso, ad esempio, degli amministratori di sistema (sysadmins, system administrators [NdT]); è loro preciso interesse trovare la soluzione efficiente a un particolare problema e se, per raggiungere tale risultato, è conveniente collaborare con altri, non ci sono difficoltà a mettere in comune i programmi software.
In altri casi i programmatori lavorano per aziende private, ad esempio IBM, per le quali lo sviluppo di free software è alla base della offerta di servizi commerciali. Il fatto che qualcuno abbia la possibilità di utilizzare tale software senza acquistare i servizi è più che compensato dalla opportunità di basare la propria offerta commerciale sulla creatività di una estesa comunità di programmatori. Per IBM, il costo di partecipazione allo sviluppo di software aperto è un investimento di capitale necessario per poter poi vendere il prodotto finito: i servizi.
In ambito accademico, scrivere programmi software, la cui vendita è spesso esplicitamente vietata, è un passaggio necessario sia per gli studenti, che mirano al raggiungimento di determinati obiettivi formativi, che per i docenti, che accrescono anche in tal modo la propria reputazione. La condivisione del software non è semplicemente parte di un percorso di avanzamento, ma parte integrante della cultura professionle che li sostiene anche dal punto di vista economico, nella forma di stipendi e borse di studio.
Infine ci sono tutti coloro che impiegano le loro capacità al di fuori dell'ambito professionale, ad esempio a casa propria. Assicurata la stabilità finanziaria, questi sono liberi di mettere a frutto le proprie competenze, alla sera o nei week-end, per il perseguimento di interessi personali.
2. Modesti capitali di investimento.
La economicità dei mezzi di produzione e la facilità con essi si possono procurare ha permesso il costituirsi di quest'ultima, molto importante classe di persone che lavorano su particolari progetti personali, al di fuori dell'ambiente istituzionale.
L'attrezzatura materiale di cui c'è bisogno è data da un comune computer di oggi (spesso anche un vecchio computer basterebbe) e una connessione veloce e affidabile per partecipare ai forum della comunità. Ovviamente è anche necessaria la presenza di una infrastruttura per le comunicazioni, cosa che non è garantita in gran parte del mondo, ma è alla portata della maggior parte delle persone nei centri di sviluppo.
Una volta assicurato l'accesso ai mezzi di comunicazione, le competenze necessarie a partecipare allo sviluppo di programmi software possono anch'esse venire acquisite senza costi economici, mediante collaborazione. Il numero di programmatori autodidatti è notevole. Dato che non sono richieste costose certificazioni e lauree per partecipare, lo scoglio finanziario diviene effettivamene molto basso.
3. Elevato numero di contributori potenziali
Le conoscenze di programmazione stanno diventando abbastanza comuni, non più circoscritte ad una elite di ingegneri, ma diffuse a tutti i livelli nella società. Anche se i programmatori veramente grandi sono rari come i grandi artisti, esiste un certo grado di conoscenza professionale, reperibile un po' ovunque, che si caratterizza quantitativamente in un numero crescente di milioni di programmatori. Anche dal punto di vista qualitativo, sono molti i programmatori capaci, anche per il ridotto impatto degli ostacoli materiali e alla possibiltà di apprendimento al di fuori delle vie istituzionali, con esami di ammissione e quote di iscrizione.
La massa critica di contributori è resa possibile da tale grande variegato insieme di talenti, proveniente da una frazione della popolazione.
4. Produzione modularizzata
Poichè un programma software grande consiste di molte parti piú piccole (librerie, plug-ins, etc.), è possibile distribuire la produzione tra un gran numero di contributori, decomponendo il processo in tanti segmenti più brevi. Se le procedure di integrazione sono mantenute semplici, è possibile assegnare la quantità di lavoro ai collaboratori in modo molto flessibile e trarre vantaggio anche da contributi di tipo più minuto (le 'patches' ed i 'bug reports').
Le caratteristiche modulari del processo di produzione permettono inoltre il lavoro in parallelo di un gran numero di persone, senza generare interferenze di rilievo.
5. I produttori sono anche gli utilizzatori
Secondo Eric S. Raymond, un buon progetto open source inizia quando un programmatore si accinge a sistemare qualcosa che non gli va e scopre che ci sono molti altri con lo stesso problema. Il desiderio di rendere usabile un programma dà una forte motivazione per contribuire al suo sviluppo, essendo spesso questa una soluzione molto più efficace che aspettare sperando che qualcuno scriva e poi venda un programma che risponda alle proprie particolari esigenze.
6. Nessuna responsabilità legale.
Infine il software non permette la perseguibilità sul prodotto. Il paragrafo 11 della GPL afferma, analogamente alla maggior parte delle licenze, che "il detentore del copyright e/o le altre parti forniscono il programma 'cosi come è' senza alcuna garanzia, nè espressa nè implicita, senza neppure le garanzie implicite di commerciabilità e di adattabilità a particolari scopi, nè altra garanzia" (GPL, v2).
La non perseguibilità permette di produrre programmi senza dover dichiarare una loro precisa proprietà nè altri segni per la determinazione delle responsabilità.
Lo spazio coperto da queste caratteristiche è ampio e non ancora interamente esplorato. E' probabile che l'attuale modello di produzione aperta troverà altre nicchie nelle quali affermarsi. Solo tre anni fa, pochi avrebbero potuto prevedere la riuscita di Wikipedia, anche se il software open source aveva già avuto molto successo.
Eppure è chiaro che molti beni a contenuto informativo restano al di fuori di questo spazio. Non sempre i mezzi di produzione sono economici e facili da procurare; non sempre il processo di produzione è modulare. A volte il numero di potenziali produttori è piccolo e, in molti casi, la perseguibilità è auspicabile.
Ciò non significa che il 'modello open source' non si possa applicare, ad esempio, alla produzione di opere letterarie, alla musica o ai prodotti medicinali. Ma che, per renderlo praticabile, è necessario un altro ciclo di innovazioni sociali. Questo sta già lentamente avvenendo. Alcuni primi buoni segni sono dati dalla crescita dei "Open Access Journals" ('Giornali ad accesso aperto') e delle discussioni sulla "compulsory licensing" (sulla 'concessione di licenza coercitiva').