A volte, partecipando ad una festa, mi capita di pronunciare la frase "Io scrivo software libero". I primi tempi la gente mi guardava con aria perplessa, adesso rispondono "Ah, si, a codice aperto come Linux?" Annuisco compiaciuto. "Sì, esattamente! Ecco cosa faccio." Provo una piacevole sensazione nel non essere più considerato un alieno. In passato, la domanda successiva era generalmente scontata: "Come fai a guadagnare in questo modo?" Per rispondere, mi toccava riassumere l'economia dello sviluppo a codice aperto (meglio noto come open source): spiegavo che ci sono organizzazioni il cui interesse è di risolvere un problema attraverso un dato software, ma alle quali non serve venderne nemmeno una copia, basta che il programma sia disponibile e aggiornato, più come strumento che come merce. Ultimamente, tuttavia, questa domanda successiva non è sempre stata legata al denaro. Il modello di business dei programmi a codice apertoI termini "codice aperto" e "libero" sono essenzialmente dei sinonimi in questo contesto, saranno discussi con maggior dettaglio in nel . non è più così misterioso, ed un numero sempre maggiore di non addetti ai lavori già comprende — o per lo meno non rimane sconvolto — che alcune persone vi lavorano a tempo pieno. Invece la domanda che iniziano a pormi con maggior frequenza è "Interessante, ma come funziona?" In principio non avevo una risposta soddisfacente a portata di mano, e più mi sforzavo di trovarne una, più mi rendevo conto quanto fosse difficile l'argomento. Dar vita ad un software libero non è esattamente come dirigere un'impresa (immagina di dover costantemente negoziare la natura del tuo prodotto con un gruppo di volontari, la maggior parte dei quali non li hai mai neppure visti in faccia). Tantomeno si può paragonare, per varie ragioni, ad organizzare e gestire un'associazione senza fini di lucro di tipo tradizionale, oppure governativa. Ci sono similitudini con tutte, ma alla fine sono lentamente giunto alla conclusione che il software libero è una cosa sui generis. I settori ai quali paragonarlo sono tanti, ma nessuno di questi è perfettamente uguale. A dirla tutta, persino l'assunzione che il software libero può essere "diretto", è una specie di forzatura. Un software libero può certamente essere avviato, ed il suo sviluppo può subire l'influenza di collaboratori interessati, anche in maniera forte. Ma le sue fondamenta non possono essere proprietà di un singolo, e finché ci sono persone in giro — ovunque — interessate nel suo sviluppo, non esiste modo unilaterale per cessarne la diffusione. Ognuno coinvolto ha un potere infinito, ed allo stesso tempo non ha nessun potere specifico. Dando vita ad una dinamica interessante. Ecco il motivo per cui ho deciso di scrivere questo libro. I progetti che sviluppano software libero hanno fatto nascere una cultura differente, un'etica nella quale la libertà di creare programmi che facciano qualsiasi cosa si abbia in mente è al centro di tutto, e dove il risultato di questa libertà non sono individui sparpagliati che decidono separatamente come far evolvere il codice, ma è una collaborazione piena di entusiasmo. Proprio il "saper collaborare" diventa quindi una delle competenze di maggior valore, nel software libero. Gestire questi progetti vuol dire entrare a far parte di una specie di cooperazione ipertrofica, in cui l'abilità del singolo è di scoprire nuove metodologie per lavorare insieme, al fine di fornire tangibili benefici al software stesso. Questo libro vuol provare a descrivere le tecniche attraverso le quali tale processo può essere portato avanti. Non ha la pretesa di trattare l'argomento in maniera esaustiva, ma è pur sempre un inizio. Fare del buon software libero è un obiettivo valido già di per sé. Spero quindi che il lettore desideroso di scoprire nuovi modi per raggiungere quest'obiettivo, si senta soddisfatto di ciò che troverà in questo libro. Ma soprattutto spero di trasmettere parte del puro piacere che si prova a lavorare con una squadra motivata di sviluppatori open source, e ad interagire con gli utenti nel modo meraviglioso che il software libero incoraggia. Partecipare alla progettazione di un programma aperto di successo è divertente, ed in definitiva è ciò che consente all'intero sistema di continuare ad esistere. Questo libro è pensato per gli sviluppatori di software e per i dirigenti che stanno pensando di far partire un progetto open source, o che ne hanno già avviato uno, chiedendosi come andare avanti. I concetti illustrati potrebbero anche tornare utili per coloro che desiderano partecipare ad un progetto open source, ma non ne hanno mai avuto l'occasione Il livello di difficoltà non richiede che il lettore sia un programmatore, ma dovrebbero essere noti i concetti di basi dell'ingegneria del software come il codice sorgente, il compilatore e le patch. Una precedente esperienza sull'open source, sia come utente che come sviluppatore, non è necessaria. Coloro che hanno invece lavorato in progetti relativi al software libero, troveranno probabilmente alcune parti del libro un tantino noiose e scontate, e potranno decidere di saltarle senza alcun problema per la comprensione dei concetti seguenti. Proprio a tal proposito, ho posto particolare attenzione nell'attribuzione dei titoli alle sezioni in maniera chiara, indicando quando qualcosa può essere saltata da chi ha già dimestichezza con l'argomento trattato. Buona parte del materiale grezzo che ha dato vita a questo libro, proviene da cinque anni di lavoro al progetto Subversion (). Subversion è un sistema open source per il versionamento di un insieme di cartelle e documenti, scritto da zero, al fine di sostituire CVS come standard de facto tra i prodotti della categoria, nella comunità degli sviluppatori open source. Il progetto fu avviato dal mio datore di lavoro, CollabNet (), all'inizio del 2000. Grazie al cielo CollabNet capì sin dall'inizio come portarlo avanti in maniera veramente collaborativa, come l'unione di tanti contributi distribuiti. Si presentarono molti volontari sin da subito; oggi siamo arrivati a circa 50 sviluppatori attivi sul progetto, dei quali solo una minoranza sono impiegati di CollabNet. Subversion è per molti versi un classico esempio di un progetto open source, e ho finito per impegnarmi su di esso più di quanto originariamente avessi previsto. In parte è stata una questione di praticità: ogni volta che avevo bisogno di un esempio di una situazione particolare, potevo richiamarne di solito uno relativo a Subversion dalla memoria. Ma è stata anche una questione di verifica. Benché io sia impegnato in altri progetti di software libero a vari livelli, e parli con amici e conoscenti coinvolti in molti altri, ho scoperto ben presto che scrivendo articoli era necessario accompagnare la teoria con la pratica. Non volevo fare affermazioni su eventi di altri progetti basandomi solo su ciò che mi era capitato di leggere nelle liste di discussione. Con Subversion, ad esempio, un approccio del genere fornirebbe soltanto la metà delle risposte giuste. Così quando raccolgo ispirazioni o esempi su un progetto del quale non ho una particolare esperienza diretta, ho imparato a parlare prima con qualcuno che possa chiarirmi i dubbi, per acquisire confidenza sull'argomento ed essere in grado di spiegare come vanno le cose. Subversion è stato il mio lavoro per gli ultimi 5 anni, ma mi occupo di software libero da 12. Tra gli altri progetti che mi hanno ispirato per la stesura di questo libro, mi piace ricordare: L'editor di testo GNU Emacs, ed il relativo progetto della Free Software Foundation, all'interno del quale ho gestito alcuni piccoli pacchetti. Il Concurrent Versions System (CVS), al quale ho lavorato intensamente nel 1994 – 1995 con Jim Blandy, continuando ad essere sporadicamente coinvolto da allora. La collezione di progetti open source nota come Apache Software Foundation, in particolare l'Ambiente Portabile di Apache (APR) ed il server HTTP Apache. OpenOffice.org, il sistema di basi di dati della Berkeley, il sistema MySQL; non sono stato coinvolto in questi progetti personalmente, ma li ho osservati e, in alcuni casi, ho avuto l'occasione di parlare direttamente con gli sviluppatori. Il debugger GNU (GDB) (in generale). Il progetto Debian (in generale). Quest'elenco non è certo completo. Un po' come la maggior parte dei programmatori open source, mantengo dei legami "deboli" con molti progetti differenti,giusto per avere un senso dello stato generale delle cose. Di sicuro non potrei elencarli qui tutti, ma non trascurerò di citarli ove opportuno, durante la trattazione. Per scrivere questo libro è stato necessario un tempo quattro volte maggiore di quello che avevo preventivato, e per la maggior parte di quel tempo sentivo come un grande pianoforte sospeso sulla mia testa, ovunque andassi. Senza l'aiuto di molte persone, non sarei stato in grado di completarlo evitando di impazzire. Andy Oram, il mio editore alla O'Reilly, si è rivelato ciò che ogni scrittore sogna. Oltre a conoscere il tema in maniera approfondita, (ha suggerito lui molti dei temi), ha il dono prezioso di sapere ciò che si vuol dire, e quello di aiutare a trovare il modo giusto per dire una cosa. Per me è stato un onore lavorare con lui. Un ringraziamento va anche a Chuck Toporek per aver girato subito la proposta di questo lavoro ad Andy. Brian Fitzpatrick ha corretto quasi tutto il materiale mentre lo scrivevo, il che non solo ha reso migliore la qualità del libro, ma mi ha stimolato a continuare la stesura nei momenti in cui avrei desiderato essere da qualsiasi parte tranne che davanti ad un computer. Ben Collins-Sussman e Mike Pilato hanno dato una mano, via via che il documento prendeva forma, e sono sempre stati felici di discutere — a volte a lungo — l'argomento che avrei trattato in un dato momento. Pure loro si accorgevano dei momenti di rallentamento, e con garbo mi stuzzicavano se necessario. Grazie, ragazzi. Biella Coleman stava scrivendo la sua tesi, nello stesso periodo in cui io scrivevo questo libro. Lei sa cosa vuol dire star seduti a scrivere ogni santo giorno, e mi è stata d'esempio, oltre che offrirsi di ascoltare le mie discussioni. Biella inoltre è dotata di un affascinante punto di vista "antropologico" del movimento del software libero, che ha messo a mia disposizione per darmi idee e riferimenti che potessero tornarmi utili in questo libro. Alex Golub — un altro antropologo con un piede nel mondo del software libero, anche lui in procinto di finire la sua tesi in quel periodo — è stato un supporto prezioso sin dall'inizio, dando un grande aiuto. Micah Anderson non si è mai mostrato particolarmente sopraffatto dal suo compagno di viaggio, che l'ha ispirato con una specie di comportamento invidioso, ma è stato sempre pronto con la sua amicizia, con le sue conversazioni, e con il suo supporto tecnico (almeno in un'occasione). Grazie, Micah! Jon Trowbridge e Sander Striker mi hanno entrambi incoraggiato con aiuti concreti — la loro vasta esperienza nel software libero mi ha dato accesso a materiale che non avrei mai potuto ottenere in altro modo. Grazie a Greg Stein non solo per l'amicizia e gli incoraggiamenti al momento giusto, ma anche per aver mostrato agli sviluppatori del progetto Subversion quanto sia importante la revisione periodica del codice nel costruire una comunità di sviluppatori. Grazie anche a Brian Behlendorf, che ha inculcato sapientemente nelle nostre teste l'importanza di discutere pubblicamente un problema; spero che questo principio venga riportato lungo la trattazione di questo libro. Grazie a Benjamin "Mako" Hill e Seth Schoen, per le belle chiacchierate sul software libero e le sue politiche; a Zack Urlocker e Louis Suarez-Potts per avermi concesso un'intervista durante il loro tempo libero; a Shane sulla lista di discussione Slashcode per avermi fatto riportare il suo intervento; e ad Haggen So per il suo enorme contributo di confronto tra vari servizi di hosting pronti all'uso. Grazie a Alla Dekhtyar, Polina, e Sonya per il loro incoraggiamento paziente ed instancabile. Sono ben felice di non dover più finire presto la giornata (a volte senza aver concluso qualcosa) ed andare a casa a lavorare sul "Libro". Grazie a Jack Repenning per l'amicizia, le chiacchierate, e l'ostinato rifiuto di accettare un'analisi semplicistica, quando ne intravedeva una più corretta, ma anche più difficile da spiegare. Spero che una parte della sua esperienza sia nel campo dello sviluppo software che in quello dell'industria del software, abbia dato maggior lustro a questo libro. CollabNet si è mostrata eccezionalmente generosa nel concedermi un orario di lavoro flessibile per scrivere, e non ha avuto da ridire quando il lavoro si è protratto più a lungo del previsto. Non conosco le vie intricate attraverso le quali i dirigenti arrivano a prendere tali decisioni, ma ho il sospetto che Sandhya Klute, e più tardi Mahesh Murthy, ne sappiano qualcosa — il mio ringraziamento va ad entrambi. L'intero gruppo di sviluppatori di Subversion è stato fonte di ispirazione negli ultimi cinque anni, e molto di quello che ho messo in questo libro proviene dalla mia esperienza lavorativa insieme a loro. Non posso ringraziarli uno per uno, perché ci vorrebbe quasi un capitolo solo per i loro nomi, ma prego ogni lettore che incontrasse uno sviluppatore di Subversione di offrirgli immediatamente qualcosa al bar — come farò sicuramente io. Tante volte ho scocciato Rachel Scollon per informarmi sulla situazione del libro; mi ha sempre ascoltato, ed a volte ha reso i problemi più piccoli di quello che sembravano prima di parlarle. Anche questo mi è stato di grande aiuto — grazie. Grazie (ancora) a Noel Taylor, che si sarà sicuramente chiesto perché io volessi scrivere un altro libro, visto quanto mi sono lamentato la volta precedente, ma la cua amicizia e appartenenza a Golosá mi ha aiutato ad avere un po' di buona musica e fratellanza nella mia vita, anche nei giorni più impegnati. Grazie anche a Matthew Dean e Dorothea Samtleben, amici e compagni "sofferti" di musica, che hanno saputo comprendermi man mano che le scuse per le assenze durante la pratica si accumulavano. Megan Jennings è stata un supporto costante, ed interessata in maniera spontanea all'argomento, sebbene le risultasse poco familiare — un vero tonico per uno scrittore insicuro. Grazie, cara. Ho avuto quattro revisori competenti e precisi per questo libro: Yoav Shapira, Andrew Stellman, Davanum Srinivas, e Ben Hyde. Se fossi stato in grado di integrare tutti i loro eccellenti suggerimenti, questo sarebbe un libro migliore. Ma come capita sempre, i vincoli temporali mi hanno costretto a scegliere, sebbene i miglioramenti siano comunque significativi. Qualsiasi refuso rimasto, è imputabile esclusivamente a me. I miei genitori, Frances ed Henry, sono stati un supporto meraviglioso come sempre, a visto che questo libro è meno tecnico del precedente, spero che lo troveranno un tantino più comprensibile. In conclusione, vorrei ringraziare i destinatari della dedica, Karen Underhill e Jim Blandy. L'amicizia di Karen e la sua comprensione sono stati tutto per me, non solo durante la scrittura del libro, bensì negli ultimi sette anni. Semplicemente non sarei stato in grado di finire senza il suo aiuto. Analogamente per Jim, vero amico ed hacker di tutto rispetto, che mi ha introdotto al software libero, un po' come un uccellino che insegna ad un aereo a volare. I pensieri e le opinioni espresse in questo libro sono del tutto personali. Non rappresentano necessariamente la visione di CollabNet o quella del progetto Subversion.