Prefazione
Perché ho scritto questo libro?
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.
Chi dovrebbe leggere questo libro?
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.
Fonti e riferimenti
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.
Ringraziamenti
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.
Esclusione di responsabilità
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.