La cattedrale e il bazaar/Il contesto sociale del software open source
 |
Questo testo è completo. | |
Traduzione dall'inglese di Bernardo Parrella (1999)
| ◄ | Le pre-condizioni necessarie per lo stile bazaar | Ringraziamenti | ► |
È proprio vero: le migliori operazioni di hacking nascono come soluzioni personali ai problemi quotidiani dell’autore, e si diffondono perchè si scopre che tali problemi sono comuni a molte altre persone. Questo ci riporta indietro alla questione della regola numero uno, riformulata forse in maniera più consona:
18. Per risolvere un problema interessante, comincia a trovare un problema che risvegli il tuo interesse.
Così è successo con Carl Harris e l’iniziale popclient, lo stesso con me e fetchmail. Ma ciò era chiaro da molto tempo. Il punto interessante che richiede attenzione, sulla base dell’evolversi di Linux e di fetchmail, è il palcoscenico successivo – l’evoluzione del software in presenza di una vasta e attiva comunità di utenti e co-sviluppatori.
In “The Mythical Man-Month”, Fred Brooks osserva come il tempo del programmatore non sia calcolabile; aggiungendo altri sviluppatori ad un progetto in ritardo, lo si fa tardare ancora di più. Secondo lui, i costi della complessità e delle comunicazioni di un progetto crescono esponenzialmente con il numero degli sviluppatori coinvolti, mentre il lavoro cresce soltanto in senso lineare. Quest’affermazione è nota come la “Legge di Brooks”, ed è considerata una verità pressoché universale. Ma se la Legge di Brooks fosse stata l’unica verità, Linux non sarebbe mai esistito.
Il classico di Gerald Weinberg “The Psychology Of Computer Programming” spiega in che modo, a posteriori, sia possibile individuare una vitale correzione alla tesi di Brooks. Parlando di “programmazione senza ego”, Weinberg fa notare come laddove gli sviluppatori non si dimostrano territoriali rispetto al proprio codice, incoraggiando altre persone a cercare bug e offrire miglioramenti, questi ultimi prendono corpo molto più in fretta che altrove.
Forse le scelte terminologiche operate da Weinberg hanno impedito alla sua analisi di ottenere il riconoscimento che merita – viene da ridere al solo pensiero di riuscire a descrivere un hacker “senza ego”. Ma ritengo la sua posizione stringente più che mai.
La storia di Unix avrebbe dovuto prepararci per quel che stiamo imparando da Linux (e per quello che io stesso ho verificato sperimentalmente su scala ridotta, copiando deliberatamente i metodi di Linus). Ovvero, pur rimandando la scrittura del codice un’attività prettamente solitaria, la questione davvero importante rimane la capacità di sfruttare l’attenzione e la potenza dell’intera comunità. Lo sviluppatore che impiega soltanto il proprio cervello su un progetto chiuso risulterà sempre dietro allo sviluppatore che sa come creare un contesto aperto, evolutivo dove sono centinaia le persone che si occupano dei miglioramenti e del debugging.
Ma una serie di elementi hanno impedito al mondo tradizionale Unix di applicare tale approccio. Tra questi, gli impedimenti legali connessi alle varie licenze, ai segreti e agli interessi commerciali. Altro impedimento (in retrospettiva), il fatto che allora Internet non fosse ancora abbastanza sviluppata.
Prima dell’attuale Internet super-diffusa, esistevano poche comunità geograficamente compatte in cui veniva incoraggiata la cultura della programmazione “senza ego” di Weinberg, dove uno sviluppatore poteva facilmente attirare molti altri co-sviluppatori in gamba. Il Bell Lab, il MIT, UC Berkeley – queste le dimore dell’innovazione che rimangono leggendarie e potenti ancor’oggi.
Linux è stato il primo progetto a proporre lo sforzo cosciente e coronato da successo verso l’utilizzo del mondo intero come fucina di talenti. Non ritengo una combinazione il fatto che la gestazione di Linux sia coincisa con la nascita del World Wide Web, e che Linux si sia lasciato alle spalle l’infanzia negli stessi anni 1993-1994 che hanno visto il decollo dei provider locali e l’esplosione dell’interesse di massa per Internet. Linus è stata la prima persona ad aver imparato come giocare secondo le nuove regole rese possibili dalla diffusione di Internet.
Se è vero che tale diffusione si è rivelata necessaria per l’evoluzione del modello Linux, non credo però possa ritenersi da sola una condizione sufficiente. Altro fattore vitale è stata l’implementazione di un certo stile di leadership e di un insieme di usanze cooperative che hanno consentito agli sviluppatori di coinvolgere altri co-sviluppatori e ottenere il massimo possibile dal medium stesso.
Ma cosa s’intende esattamente con un certo stile di leadership e quali sarebbero queste usanze cooperative? Intanto, non ci si basa su relazioni di potere – e anche se tali dovessero essere, una leadership fondata sulla costrizione non produrrebbe i risultati che abbiamo visto. Weinberg cita al riguardo l’autobiografia dell’anarchico russo del XIX secolo Pyotr Alexeyvich Kropotkin, “Memorie di un rivoluzionario”:
“Essendo cresciuto in una famiglia che aveva dei servitori, sono entrato nella vita attiva, al pari di tutti i giovani della mia epoca, con un notevole carico di confidenza nella necessità di comandare, impartire ordini, rimproverare, punire. Ma quando, ancora giovane, dovetti gestire degli affari seri e avere a che fare con uomini [liberi], quando ogni errore avrebbe portato da solo a pesanti conseguenze, iniziai ad apprezzare la differenza tra l’agire basato sul principio del comando e della disciplina e l’agire basato sul principio della comprensione condivisa. Il primo funziona mirabilmente in una parata militare, ma non ha valore alcuno allorché si tratta della vita reale, dove ogni obiettivo può essere raggiunto soltanto tramite i duri sforzi di molte volontà convergenti.”
È precisamente i “duri sforzi di molte volontà convergenti” sono quel che un progetto come Linux richiede – e il “principio del comando” è veramente impossibile da praticare tra i volontari di quel paradiso anarchico chiamato Internet. Per operare e competere con efficacia, ogni hacker che voglia guidare progetti collettivi deve imparare come creare e dare energia a reali comunità d’interesse secondo le modalità vagamente suggerite dal “principio della comprensione” citato da Kropotkin. Deve imparare ad usare la Legge di Linus.
Più sopra mi sono riferito all’effetto Delfi come possibile spiegazione della Legge di Linus. Ma si potrebbero anche fare analogie forse più calzanti con i sistemi d’adattamento delle scienze biologiche ed economiche. Sotto molti aspetti il mondo Linux si comporta come un “free market” oppure come un sistema ecologico, una serie di agenti indipendenti che cercando di massimizzare quell’utilitarismo che nel processo va producendo un ordine spontaneo e in grado di auto-correggersi, più elaborato ed efficiente di quanto avrebbe potuto raggiungere qualsiasi pianificazione centralizzata. È dunque questo il luogo dove cercare il “principio della comprensione”.
La “funzione utilitaristica” che gli hacker di Linux vanno massimizzando non è economica in senso classico, quanto piuttosto espressione dell’intangibile, egoistica reputazione e soddisfazione che si guadagna tra gli altri hackers. (La loro motivazione potrebbe essere definita “altruista”, ma ciò significherebbe ignorare il fatto che a ben vedere l’altruismo stesso altro non è che una forma di soddisfazione egoistica). In realtà le culture del lavoro volontario che funzionano in tal modo non sono così rare; un’altra cui ho preso parte a lungo è quella dei fan della fantascienza, che al contrario del giro hacker riconosce esplicitamente come motore propulsore dietro tale attività volontaria proprio il cosiddetto “egoboo” (l’esaltazione della reputazione individuale tra gli altri fan).
Linus, posizionandosi con successo come filtro di un progetto nel quale il lavoro è in gran parte svolto da altri, e alimentando interesse nel progetto stesso finché non arriva ad auto-alimentarsi, ha dimostrato di aver acutamente fatto proprio il “principio della comprensione condivisa” di Kropotkin. Questa visione quasi-economica del mondo Linux ci consente di vedere come applicare tale comprensione.
È possibile ritenere il metodo di Linus come un modo per creare un mercato efficiente all’interno dell’“egoboo” – per collegare nel modo più sicuro possibile l’egoismo dei singoli hacker con quegli obiettivi difficili che possono essere raggiunti soltanto grazie alla concreta cooperazione collettiva. Con il progetto fetchmail ho dimostrato (pur se su scala più ridotta) che è possibile duplicarne il metodo ottenendo buoni risultati. Forse l’ho perfino messo in atto un po’ più coscientemente e sistematicamente di quanto non abbia fatto Linus.
Molte persone (soprattutto quanti politicamente diffidano del “free market”) immaginavano che una cultura di egoisti auto-referenziale si rivelasse frammentaria, territoriale, sprecona, segreta, ostile. Ma tale aspettativa viene chiaramente confutata (per fornire un solo esempio) dalla notevole varietà, qualità e profondità della documentazione relativa a Linux. Se è un dato di fatto che i programmatori odiano lavorare sulla documentazione, com’è allora che gli hacker di Linux ne producono di così copiosa? Evidentemente il “free market dell’egoboo” di Linux funziona meglio nella produzione di comportamenti virtuosi, diretti verso gli altri, rispetto a quei negozi dei produttori di software commerciale che si occupano della documentazione, avendo alle spalle massicci finanziamenti.
Sia il progetto di fetchmail che del kernel di Linux dimostrano come, dando la giusta ricompensa all’ego di molti altri hacker, un bravo sviluppatore/coordinatore possa utilizzare Internet per catturare i vantaggi dell’avere a disposizione molti co-sviluppatori senza che il progetto si frantumi in una confusione caotica. Ecco quindi la mia controproposta alla Legge di Brooks:
19: Stabilito che il coordinatore dello sviluppo abbia a disposizione un medium almeno altrettanto affidabile di Internet, e che sappia come svolgere il ruolo di leader senza costrizione, molte teste funzionano inevitabilmente meglio di una sola.
Penso che il futuro del software open source apparterrà sempre più alle persone che sanno come giocare al gioco di Linus, persone che si lasceranno alle spalle la cattedrale per entrare nel bazaar. Ciò non significa che non saranno più importanti le visioni e l’intelligenza individuali; credo piuttosto che la punta avanzata del software open source apparterrà a quanti sapranno muovere da visioni e intelligenza individuali per poi amplificarle tramite l’effettiva costruzione di comunità volontarie d’interesse.
E forse ciò vale non soltanto per il futuro del software open source. Nessuno sviluppatore in “closed-source” potrà mai pareggiare la fucina di talenti che la comunità Linux è in grado di riunire per affrontare un problema. Sono davvero in pochi a potersi permettere di assumere le oltre duecento persone che hanno contribuito a fetchmail!
Forse alla fine la cultura dell’open source trionferà non perchè la cooperazione sia moralmente giusta o perché il software “costretto” sia moralmente sbagliato (dando per scontato che si creda a quest’ultima affermazione, cosa che né io né Linus facciamo), ma semplicemente perché il mondo “closed-source” non è in grado di vincere la corsa agli armamenti dell’evoluzione contro quelle comunità open source capaci di affrontare un problema con tempi e capacità superiori di diversi ordini di grandezza.