Il calderone magico/L'inverso dell'area comune
 |
Questo testo è completo. | |
| ◄ | "L'informazione vuole essere libera": un mito. | Perché chiudere il codice sorgente | ► |
Dopo aver analizzato un modello assai diffuso con occhio critico, vediamo di costruirne un altro: una spiegazione economica solida di che cosa possa rendere sostenibile la cooperazione open source.
Si tratta di un quesito che richiede un’indagine a un paio di livelli diversi. Al primo livello, occorre spiegare il comportamento dei singoli individui che collaborano a progetti open source; al secondo, occorre comprendere le forze economiche che sostengono la cooperazione a progetti open source come Linux o Apache.
Ancora una volta, occorre, innanzitutto, confutare un modello divulgativo assai diffuso che ostacola la comprensione. Sopra ogni tentativo di spiegare il comportamento cooperativo aleggia l’ombra della Tragedia dell’area comune di Garret Hardin1.
Hardin, com’è noto, ci chiede di immaginare un prato a uso comune in un villaggio di coltivatori, che vi conducono le proprie mandrie al pascolo. Ma gli effetti del pascolo degradano l’area comune, estirpando l’erba e lasciando macchie brulle in cui l’erba ricresce molto lentamente. Se manca una politica condivisa (e messa in atto!) per la distribuzione dei diritti di pascolo, al fine di prevenire gli eccessi, l’interesse di ciascuna delle parti starà nel far pascolare il maggior numero di capi possibile al più presto possibile, nel tentativo di trarre il massimo valore dal pascolo, prima che degeneri in un mare di fango.
La maggior parte di noi ha un modello intuitivo del comportamento cooperativo che funziona più o meno in questo modo. In realtà, non si tratta di una diagnosi valida per i problemi economici dell’open source, che sono legati al free riding 2 (e quindi alla scarsità di ricavi) piuttosto che alla congestione di un bene pubblico (per sovrautilizzo).
Ciononostante, questa è l’analogia che sento nella maggior parte delle obiezioni improvvisate.
La tragedia dell’area comune non fa che predire tre possibili risultati. Uno è il mare di fango. Un altro è che una figura con poteri coercitivi imponga una politica di ripartizione delle aree a nome del villaggio (una soluzione comunista). Il terzo è che l’area comune venga suddivisa via via che i vari membri del villaggio recingono aree che sono in grado di difendere e di mantenere in modo sostenibile (la soluzione del diritto di proprietà).
Quando, con una riflessione, si applica questo modello alla cooperazione open source, ci si aspetta che avrà vita molto breve. Poiché non c’è alcun modo ovvio per mettere in atto una politica di ripartizione del tempo trascorso dai programmatori su Internet, questo modello conduce direttamente alla previsione che l’area comune si spezzetterà, che i vari software diverranno commerciali, e che ci sarà sempre meno lavoro disponibile nello spazio comune.
In effetti, la realtà empirica prova che la linea di tendenza è quella opposta. L’ampiezza e il volume dello sviluppo open source (misurati, per esempio, attraverso i contributi pervenuti ogni giorno a Metalab o gli annunci pubblicatiogni giorno su freshmeat.net) sono in crescita costante. È chiaro che il modello della tragedia dell’area comune non è in grado, per motivi sostanziali, di descrivere quello che sta succedendo in realtà.
Un aspetto della risposta si trova senz’altro nel fatto che l’utilizzo dei software non ne diminuisce il valore. Anzi, l’uso massiccio di software open source tende a farne aumentare il valore, con la possibilità da parte degli utenti di aggiungere correzioni e funzionalità a loro piacimento ("patches" del codice). In quest’area comune all’inverso, l’erba cresce più alta quando si è in tanti a pascolare.
Un altro aspetto della risposta si trova nel fatto che il presunto valore di mercato di una piccola correzione apportata al codice sorgente è difficile da stimare. Supponiamo che io scriva una correzione per un difetto seccante e supponiamo anche che molti si accorgano che la mia correzione ha un valore in denaro: ma come faccio a ricavarlo da tutte quelle persone? I sistemi di pagamento tradizionali hanno costi aggiuntivi abbastanza alti da costituire un problema per le tipologie di micropagamento che si rivelerebbero adatte in questi casi.
Forse, sarebbe più appropriato affermare che questo valore non è solo difficile da stimare, ma che, in generale, è anche difficile da assegnare. Supponiamo, a titolo di esempio, che Internet sia fornita di un sistema di micropagamento ideale, almeno a livello teorico: sicuro, accessibile a tutti, senza spese aggiuntive. Ora supponiamo che voi abbiate scritto una patch dal titolo "Correzioni varie per il kernel di Linux". Come stabilirete il prezzo da chiedere? E come potrà l’eventuale acquirente, non avendo ancora visto la patch, valutare quanto sia ragionevole sborsare per averla?
Quella che abbiamo di fronte è una specie di immagine a galleria degli specchi di ciò che F. A. Hayek 3chiamò "il problema del calcolo": servirebbe un superuomo, capace di stabilire il valore funzionale delle correzioni e abbastanza fidato da fissare i giusti prezzi, per oliare gli ingranaggi del commercio.
Sfortunatamente, c’è una seria carenza di superuomini, per cui l’autore di patches, signor John Smith Hacker, ha solo due possibilità: o tenersi la patch, oppure metterla gratuitamente nello spazio comune. La prima scelta non presenta alcun guadagno. La seconda potrebbe non presentare un guadagno, ma potrebbe anche incoraggiare la distribuzione a catena ad altri utenti che, in futuro, si rivolgerebbero al signor John Smith per eventuali problemi. La seconda scelta, apparentemente altruistica, è in realtà egoista al punto giusto, nella prospettiva della teoria dei giochi.
In un’analisi di questa tipologia di cooperazione, è importante notare che, se esiste un problema di free riding (il lavoro può essere poco remunerativo in assenza di denaro o di altri compensi equivalenti) esso non si aggrava in proporzione al numero degli utenti. La complessità e il costo delle comunicazioni che ruotano intorno a un progetto open source sono da considerarsi quasi del tutto una funzione del numero di sviluppatori coinvolti: la presenza di più utenti che non esaminano mai il codice sorgente, in realtà, non costa nulla. Può far aumentare il numero di domande banali che compaiono nella mailing list del progetto, ma si può facilmente farvi fronte gestendo una pagina di Frequently Asked Questions e ignorando candidamente i quesiti da cui risulti ovvio che la pagina non è stata letta (e, infatti, entrambi i comportamenti sono consueti).
I veri problemi creati dal free riding, nel campo del software open source, dipendono più che altro dai costi contingenti alla distribuzione stessa delle patches. Un collaboratore che abbia poco da perdere nel gioco culturale della reputazione (vedi [HtN]), in assenza di un compenso in denaro, potrebbe pensare: "Non vale la pena distribuire questa correzione, perché dovrei ripulire la patch, scrivere un ChangeLog e firmare le carte di licenza della Free Software Foundation...". È proprio per questo che il numero dei collaboratori (e, in seconda istanza, il successo dei progetti) è fortemente e inversamente proporzionale alle difficoltà cui l’utente deve far fronte per collaborare a un progetto. Tali costi contingenti possono essere di natura sia politica, sia meccanica, e insieme possono spiegare perché una cultura sconnessa e amorfa come quella di Linux abbia attratto enormemente più energie cooperative rispetto a sforzi organizzati sistematicamente e più centralizzati, come BSD, e perché la FSF abbia iniziato a perdere importanza con la diffusione di Linux.
Tutto questo va benissimo, finché dura. Si tratta, però, di una spiegazione post factum di ciò che fa il signor John Smith Hacker della sua patch, una volta pronta. Ma ci manca ancora una spiegazione economica di come questo signore, tanto per cominciare, sia riuscito a scrivere la patch, invece di lavorare su un programma commerciale che avrebbe potuto apportargli un guadagno sul valore di vendita. Quali sono, quindi, i modelli commerciali che creano nicchie in cui possa fiorire lo sviluppo dell’open source?
Note
- ↑ Garret Hardin: professore emerito di Biologia presso l’Università di Santa Barbara (CA), Hardin è l’autore, fra l’altro, di un saggio dal titolo "w:The Tragedy of Commons", considerato un contributo fondamentale all’ecologia, alla teoria del contenimento demografico e all’economia politica (N.d.T)
- ↑ Free riding: nel linguaggio economico, indica l’accesso a un servizio che consente l’ottenimento di un beneficio senza oneri per sé. L’esistenza di free riders nel campo dell’open source è una diretta conseguenza della disponibilità stessa del codice sorgente. (N.d.T)
- ↑ F. A. Hayek (1899-1992): vincitore del premio Nobel per l’Economia nel 1974, Hayek fu tra i pionieri della teoria monetaria e principale proponente della dottrina del libero arbitrio nel ventesimo secolo. Ha insegnato alle Università di Londra, Chicago e Friburgo. La sua dottrina sostiene che, per effettuare un calcolo economico, occorre un mercato dei mezzi di produzione, in mancanza del quale non c’è alcun modo per stabilire il valore dei suddetti mezzi e, di conseguenza, alcun modo per trovare le giuste modalità di produzione (N.d.T)