La cattedrale e il bazaar
di Eric S.
Raymond
(22/11/1998 ore 04:01:20)
Quella che segue è la mia analisi di un progetto
open source di successo, fetchmail,
deliberatamente utilizzato come test specifico per
la verifica di alcune sorprendenti teorie sullo
sviluppo del software suggerite dalla storia di
Linux. Le mie argomentazioni su tali teorie
mettono a confronto due diversi stili di sviluppo,
il modello “cattedrale” in voga in gran parte del
mondo commerciale, opposto al modello “bazaar” del
mondo Linux. Da qui passo poi a dimostrare come
tali modelli derivino da premesse divergenti sulla
natura dell'attività di debugging del software.
Arrivo quindi a stabilire la validità
dell'esperienza di Linux riguardo l'affermazione
“Con molti occhi puntati addosso, ogni bug diventa
una bazzecola”, per suggerire analogie produttive
con altri sistemi di agenti indipendenti in grado
di auto-correggersi, concludendo infine con una
serie di riflessioni sulle implicazioni di queste
analisi per il futuro del software.
Sommario:
- La
cattedrale e il bazaar
- La
posta deve passare
- L'importanza
di avere utenti
- Distribuire
presto e spesso
- Quando
una rosa non è una rosa?
- Popclient
diventa Fetchmail
- Fetchmail
diventa adulto
- Qualche
altra lezione da Fetchmail
- Le
pre-condizioni necessarie per lo stile bazaar
- Il
contesto sociale del software open source
- Ringraziamenti
- Letture
consigliate
- Epilogo:
Netscape si unisce al bazaar!
- Cronologia
delle versioni e delle modifiche
1.
La cattedrale e il bazaar
Linux è sovversivo. Chi avrebbe
potuto pensare appena cinque anni fa che un
sistema operativo di livello mondiale sarebbe
emerso come per magia dal lavoro part-time di
diverse migliaia di hacker e sviluppatori sparsi
sull'intero pianeta, collegati tra loro solo
grazie ai tenui cavi di Internet?
Certamente non il sottoscritto.
Quando Linux fece la sua comparsa nel mio raggio
d'azione all'inizio del 1993, mi ero occupato
dello sviluppo di Unix e di software open source
per dieci anni. Ero stato uno dei primi
collaboratori al progetto GNU a metà anni '80.
Avevo distribuito su Internet un buon numero di
software open source, realizzando da solo o in
collaborazione con altri parecchi programmi
(nethack, Emacs VC e GUD, xlife, etc.)
ancor'oggi ampiamente utilizzati. Pensavo di
sapere come bisognasse fare.
Linux stravolse gran parte di quel
che credevo di sapere. Per anni avevo predicato
il vangelo Unix degli strumenti agili, dei
prototipi immediati e della programmazione
evolutiva. Ma ero anche convinto che esistesse
un punto critico di complessità al di sopra del
quale si rendesse necessario un approccio
centralizzato e a priori. Credevo che il
software più importante (sistemi operativi e
strumenti davvero ingombranti come Emacs)
andasse realizzato come le cattedrali,
attentamente lavorato a mano da singoli geni o
piccole bande di maghi che lavoravano in
splendido isolamento, senza che alcuna versione
beta vedesse la luce prima del momento giusto.
Rimasi non poco sorpreso dallo stile
di sviluppo proprio di Linus Torvalds –
diffondere le release presto e spesso, delegare
ad altri tutto il possibile, essere aperti fino
alla promiscuità. Nessuna cattedrale da
costruire in silenzio e reverenza. Piuttosto, la
comunità Linux assomigliava a un grande e
confusionario bazaar, pullulante di progetti e
approcci tra loro diversi (efficacemente
simbolizzati dai siti contenenti l'archivio di
Linux dove apparivano materiali prodotti da
chiunque). Un bazaar dal quale soltanto una
serie di miracoli avrebbe potuto far emergere un
sistema stabile e coerente.
Il fatto che questo stile bazaar
sembrasse funzionare, e anche piuttosto bene, mi
colpì come uno shock. Mentre imparavo a
prenderne le misure, lavoravo sodo non soltanto
sui singoli progetti, ma anche cercando di
comprendere come mai il mondo Linux non soltanto
non cadesse preda della confusione più totale,
ma al contrario andasse rafforzandosi sempre più
a una velocità a malapena immaginabile per
quanti costruivano cattedrali.
Fu verso la metà del 1996 che mi
parve d'essere sul punto di capirne il perché.
Il destino mi offrì l'occasione propizia per
mettere alla prova la mia teoria, sotto forma di
un progetto open source del quale decisi di
occuparmi usando coscientemente lo stile bazaar.
Ci provai, e il successo ottenuto fu piuttosto
significativo.
Nella parte restante di questo
saggio, racconto la storia di quel progetto,
usandola per proporre alcuni aforismi
sull'efficacia dello sviluppo open source. Non
che li abbia imparati tutti dal mondo Linux, ma
vedremo come le modalità offerte da quest'ultimo
siano del tutto peculiari. Se non ho
interpretato male, questi aforismi ci aiuteranno
a comprendere con esattezza cos'è che rende la
comunità Linux una sorgente così copiosa di buon
software – e aiuteranno tutti noi a divenire più
produttivi.
2. La posta deve passare
Dal 1993 mi occupo del lato tecnico
di un piccolo provider Internet gratuito
chiamato Chester County InterLink (CCIL) in West
Chester, Pennsylvania (sono tra i fondatori di
CCIL e autore del software specifico per il
nostro bulletin-board multiutenti – si può dare
un'occhiata facendo telnet su locke.ccil.org .
Ora dà accesso a quasi tremila utenti su
trenta linee). Grazie a questo lavoro posso
collegarmi a Internet per 24 ore al giorno con
una linea a 56K di CCIL – in realtà, è proprio
quel che mi viene richiesto!
Di conseguenza sono ormai abituato
alle email istantanee. Per vari motivi, era
difficile far funzionare la connessione SLIP tra
la mia macchina a casa (snark.thyrsus.com) e
CCIL. Quando finalmente ci sono riuscito, mi
dava fastidio dover fare ogni tanto telnet su
locke per controllare la posta. Volevo fare in
modo che i messaggi arrivassero direttamente su
snark così da esserne tempestivamente avvisato e
poterli gestire a livello locale.
Il semplice “sendmail forwarding” non
avrebbe funzionato, perché la mia macchina
personale non è sempre online e non ha un
indirizzo IP statico. Mi serviva un programma in
grado di raggiungere la connessione SLIP e tirar
via la posta per farla arrivare localmente.
Sapevo dell'esistenza di simili cose, e del
fatto che in genere facevano uso di un semplice
protocollo noto come POP (Post Office Protocol).
E sicuramente doveva già esserci un server POP3
incluso nel sistema operativo BSD/OS di locke.
Mi serviva un client POP3. Ne ho
localizzato subito uno online. Anzi, ne ho
trovati tre o quattro. Per un po' ho usato un
pop-perl, ma era privo di quella che pareva una
funzione ovvia, la capacità di effettuare un
“hacking degli indirizzi della posta prelevata
in modo che il reply funzionasse correttamente.
Questo il problema: supponiamo di
ricevere un messaggio da qualcuno di nome 'joe'
su locke. Se lo inoltro su snark e poi cerco di
fare reply, il mio programma di posta proverebbe
simpaticamente a inviarlo a un inesistente 'joe'
su snark. Modificare a mano ogni indirizzo per
aggiungere “@ccil.org” diventerebbe in un attimo
un problema serio.
Chiaramente questa era un'operazione
che toccava fare al computer per conto mio. Ma
nessuno dei client POP esistenti sapeva come! E
questo ci porta alla prima lezione:
1. Ogni buon lavoro software
inizia dalla frenesia personale di uno
sviluppatore.
Forse ciò avrebbe dovuto risultare
ovvio (è risaputo da tempo che “la necessità è
la madre di tutte le invenzioni”), ma troppo
spesso gli sviluppatori trascorrono le giornate
impegnati a guadagnarsi da vivere con programmi
di cui non hanno alcun bisogno e che non
apprezzano. Ma non nel mondo Linux – il che
spiega l'alta qualità media del software
originato dalla comunità Linux.
Mi sono forse lanciato in un'attività
frenetica per scrivere il codice di un client
POP3 nuovo di zecca in grado di competere con
quelli esistenti? Nemmeno per sogno! Ho
esaminato attentamente le utility POP che avevo
in mano, chiedendomi: “qual'è la più vicina a
quel che sto cercando?” Perché:
2. I bravi programmatori sanno
cosa scrivere. I migliori sanno cosa
riscrivere (e riusare).
Pur non ritenendomi un programmatore
tra i più bravi, cerco di imitarli. Importante
caratteristica di costoro è una sorta di ozio
costruttivo. Sanno che si ottiene il meglio non
per le energie impiegate ma per il risultato
raggiunto, e che quasi sempre è più facile
iniziare da una buona soluzione parziale
piuttosto che dal nulla assoluto.
Linus Torvalds, per esempio, non ha
mai cercato di riscrivere Linux da zero. È
invece partito riutilizzando codici e idee
riprese da Minix, piccolo sistema operativo per
macchine 386 assai simile a Unix. Alla fine il
codice Minix è scomparso oppure è stato
completamente riscritto – ma per il tempo che è
rimasto lì presente è servito come impalcatura
per l'infante che sarebbe infine divenuto Linux.
Con lo stesso spirito, mi sono messo
a cercare una utility POP basata su codici
ragionevolmente ben fatti, da utilizzare come
base di sviluppo.
La tradizione di condivisione dei
codici tipica del mondo Unix ha sempre favorito
il riutilizzo dei sorgenti (questo il motivo per
cui il progetto GNU ha scelto come sistema
operativo di base proprio Unix, nonostante
alcune serie riserve sullo stesso). Il mondo
Linux ha spinto questa tradizione vicina al suo
al limite tecnologico; sono generalmente
disponibili terabyte di codice open source. È
quindi probabile che, impiegando del tempo a
cercare il lavoro di qualcuno quasi ben fatto,
si ottengano i risultati voluti. E ciò vale
assai più nel mondo Linux che altrove.
Proprio quel che è successo a me.
Conteggiando i programmi trovati prima, con la
seconda ricerca ottenni un totale di nove
candidati – fetchpop, PopTart, get-mail, gwpop,
pimp, pop-perl, popc, popmail e upop. Il primo
su cui mi sono concentrato è stato 'fetchpop' di
Seung-Hong Oh. Ho inserito l'opzione
“header-rewrite” e ho apportato altri
miglioramenti, poi accettati dall'autore nella
release 1.9.
Alcune settimane dopo, però, mi sono
imbattuto nel codice di 'popclient' scritto da
Carl Harris, ed mi sono trovato di fronte a un
problema. Pur offrendo alcune buone idee
originali (come la modalità “daemon”), fetchpop
poteva gestire solo POP3 e il codice rifletteva
un certo approccio da dilettante (Seung-Hong era
un programmatore brillante ma inesperto, ed
entrambe le qualità risultavano evidenti). Il
codice di Carl era migliore, alquanto
professionale e solido, ma il suo programma
difettava di varie opzioni presenti in fetchpop,
opzioni importanti e piuttosto complesse da
implementare (incluse quelle aggiunte dal
sottoscritto).
Restare o cambiare? Nel secondo caso
avrei buttato via il codice che avevo già
scritto in cambio di una migliore base di
sviluppo.
Un motivo pratico per passare
all'altro programma era il supporto per
protocolli multipli. POP3 è il più usato tra i
server per l'ufficio postale, ma non è il solo.
Fetchpop e l'altro rivale non avevano POP2,
RPOP, o APOP, e io stesso stavo meditando,
giusto per divertimento, l'aggiunta di IMAP
(Internet Message Access Protocol, il protocollo
per l'ufficio postale più recente e più
potente).
Avevo però altri motivi teorici per
ritenere una buona idea il fatto di cambiare,
qualcosa che avevo imparato molto tempo prima di
Linux.
3. “Preparati a buttarne via uno;
dovrai farlo comunque.” (Fred Brooks, “The
Mythical Man-Month”, Capitolo 11)
In altri termini, spesso non si
riesce a comprendere davvero un problema fino
alla prima volta in cui si prova a implementarne
la soluzione. La seconda volta forse se ne sa
abbastanza per riuscirci. Per arrivare alla
soluzione, preparati a ricominciare almeno una
volta.
Be', mi son detto, la mia prima volta
erano state le modifiche a fetchpop. Adesso era
ora di cambiare, e così feci.
Dopo aver mandato a Carl Harris il 25
Giugno 1996 una prima serie di aggiustamenti per
popclient, mi resi conto che da qualche tempo
egli aveva perso interesse nel programma. Il
codice era un po' polveroso, con vari bug in
giro. Avrei dovuto fare molte modifiche, e ci
mettemmo rapidamente d'accordo sul fatto che la
cosa più logica fosse che il programma passasse
in mano mia.
Senza che me ne accorgessi più di
tanto, il progetto era cresciuto parecchio. Non
mi stavo più occupando soltanto di sistemare i
piccoli difetti di un client POP già esistente.
Mi ero addossato l'intera gestione di un
programma, e mi venivano in mente delle idee che
avrebbero probabilmente portato a modifiche
radicali.
In una cultura del software che
incoraggia la condivisione del codice, non si
trattava altro che della naturale evoluzione di
un progetto. Questi i punti-chiave:
4. Se hai l'atteggiamento giusto,
saranno i problemi interessanti a trovare te.
Ma l'atteggiamento di Carl Harris
risultò perfino più importante. Fu lui a
comprendere che:
5. Quando hai perso interesse in
un programma, l'ultimo tuo dovere è passarlo a
un successore competente.
Senza neppure parlarne, io e Carl
sapevamo di perseguire il comune obiettivo di
voler raggiungere la soluzione migliore. L'unica
questione per entrambi era stabilire se le mie
fossero mani fidate. Una volta concordato su
questo, egli agì con gentilezza e prontezza.
Spero di comportarmi altrettanto bene quando
verrà il mio turno.
3. L'importanza di avere utenti
E così ho ereditato popclient. Fatto
parimenti importante, ho ereditato gli utenti di
popclient. Importante non soltanto perché la
loro esistenza testimonia che stai rispondendo a
un loro bisogno, che hai fatto qualcosa di
buono. Coltivati in maniera appropriata, gli
utenti possono trasformarsi in co-sviluppatori.
Altro punto di forza della tradizione
Unix, portato felicemente agli estremi da Linux,
è che molti utenti sono essi stessi degli
hacker. Ed essendo i sorgenti disponibili a
tutti, posso diventare degli hacker molto
efficaci. Qualcosa di tremendamente utile per
ridurre il tempo necessario al debugging. Con un
po' d'incoraggiamento, ogni utente è in grado di
diagnosticare problemi, suggerire soluzioni,
aiutare a migliorare il codice in maniera
impensabile per una persona sola.
6. Trattare gli utenti come
co-sviluppatori è la strada migliore per
ottenere rapidi miglioramenti del codice e
debugging efficace.
È facile sottovalutare la potenza di
un simile effetto. In realtà un po' tutti noi
del mondo open source eravamo soliti
sottovalutare drasticamente il fatto che tale
potenza crescesse di pari passo con il numero
degli utenti e con la complessità del sistema.
Finché Linus Torvalds ci ha mostrato le cose in
maniera diversa.
In realtà ritengo che la mossa più
scaltra e consequenziale di Linus non sia stata
la costruzione del kernel di Linux in sé, bensì
la sua invenzione del modello di sviluppo di
Linux. Quando ho espresso questo mio pensiero in
sua presenza, sorridendo ha ripetuto con calma
quel che va spesso affermando: “Praticamente
sono una persona molto pigra cui piace prendersi
il merito di quel che sono gli altri a fare.”
Pigro come una volpe. Oppure, come avrebbe detto
Robert Heinlein, troppo pigro per fallire.
Guardando all'indietro, un precedente
per i metodi e il successo di Linux può esser
trovato nello sviluppo della libreria Lisp GNU e
per gli archivi del codice Lisp di Emacs. In
opposizione allo stile di costruzione a
cattedrale del nucleo centrale in C di Emacs e
di gran parte di altri strumenti della Free
Software Foundation (FSF), l'evoluzione del
codice Lisp risultò assai fluida e guidata dagli
utenti. Idee e prototipi vennero spesso
riscritti tre o quattro volte prima di
raggiungere una forma stabile e definitiva. E le
collaborazioni estemporanee tra due o più
persone consentite da Internet, alla Linux,
erano evento frequente.
Non a caso il mio caso di “hack”
precedente a fetchmail fu probabilmente la
modalità Emacs VC, una collaborazione via email
secondo lo stile Linux con altre tre persone,
soltanto una delle quali (Richard Stallman,
autore di Emacs e fondatore della FSF http://www.fsf.org)
ho poi avuto occasione di incontrare dal vivo. Si
trattava di realizzare il frontale per SCCS, RCS e
più tardi CVS dall'interno di Emacs, dotato di
opzioni a “one-touch” per le operazioni di
controllo. Ciò ha preso avvio da un minuto, crudo
sccs.el scritto da qualcun altro. E lo sviluppo di
VC ha avuto successo perché, al contrario dello
stesso Emacs, il codice di Lisp riuscì a passare
molto rapidamente tra diverse generazioni di
distribuzione/test/miglioramenti.
4. Distribuire presto e
spesso
Elemento centrale del processo di
sviluppo di Linux è la rapida e frequente
distribuzione delle varie release. La maggior
parte degli sviluppatori (incluso il
sottoscritto) aveva sempre considerato negativa
questa usanza per progetti appena più che
minimi, poiché le versioni iniziali sono piene
di bug quasi per definizione e non pareva il
caso di far spazientire inutilmente gli utenti.
Tale opinione era rinforzata
dalla generale aderenza allo stile di sviluppo
della costruzione a cattedrale. Se l'obiettivo
finale era quello di far vedere meno bug
possibili agli utenti, allora conveniva
distribuire una nuova release ogni sei mesi (o
ancora meno frequentemente) e lavorare duramente
sul debugging tra una release e l'altra. Fu
seguendo questo processo che venne sviluppato il
nucleo centrale in C di Emacs. Ma non fu così
per la libreria Lisp –perché erano attivi
archivi Lisp al di fuori del controllo della
FSF, dove era invece possibile trovare versioni
di codice nuovo e in fase di sviluppo
indipendentemente dal ciclo di release di Emacs.
Il più importante di tali
archivi, l'archivio elisp dell'Ohio State,
anticipava lo spirito e molte delle
caratteristiche tipiche dei grandi archivi su
Linux di oggi. Ma pochi di noi si resero davvero
conto di quel che stavamo facendo, o di come
l'esistenza stessa di quell'archivio paresse
rispondere ai problemi insiti nel modello di
sviluppo della costruzione a cattedrale della
FSF. Verso il 1992 ho provato a far confluire
formalmente gran parte del codice dell'Ohio
nella libreria ufficiale Lisp di Emacs. Mi sono
trovato politicamente nei guai e di fronte a un
chiaro insuccesso.
Ma l'anno seguente, mentre Linux
diventava ampiamente visibile, fu chiaro come
stesse accadendo qualcosa di assai diverso e più
salutare. La policy di sviluppo aperto di Linus
rappresentava l'esatto opposto della costruzione
a cattedrale. Gli archivi di sunsite e tsx-11
stavano moltiplicandosi, le distribuzioni
multiple andavano proliferando. E tutto ciò
sotto la spinta della diffusione, con una
frequenza mai vista prima, delle varie release.
Linus trattava gli utenti al pari
di co-sviluppatori nella maniera più efficace
possibile:
7. Distribuisci presto.
Distribuisci spesso. E presta ascolto agli
utenti.
L'innovazione introdotta da Linus
non consisteva tanto nel seguire questa pratica
(qualcosa di simile faceva parte da molto tempo
della tradizione del mondo Unix), quanto
piuttosto nel farla crescere a un tale livello
d'intensità da raggiungere la medesima
complessità del lavoro di programmazione che
stava facendo. A quei tempi (intorno al 1991)
non era raro che egli diffondesse versioni del
nuovo kernel anche più di una volta al giorno!
Qualcosa che poté funzionare grazie
all'attenzione dedicata ai co-sviluppatori e
all'ampio utilizzo di Internet come strumento di
collaborazione.
Ma come funzionava? Era qualcosa
che avrei potuto duplicare, o tutto dipendeva
esclusivamente dal genio di Linus Torvalds?
No, non lo credevo. Certo, Linus
è un gran bell'hacker (quanti di noi saprebbero
realizzare per intero un sistema operativo di
qualità?). Ma a livello concettuale Linux non
rappresentava alcun significativo salto in
avanti. Linus non è (almeno, non ancora) quel
genio innovativo del design allo stesso modo, ad
esempio, di Richard Stallman o James Gosling (di
NeWS e Java). Piuttosto, Linus mi sembrava un
genio dell'engineering, dotato di un sesto senso
per evitare bug e strade senza uscita, oltre che
di un ottimo fiuto per arrivare dal punto A al
punto B con il minimo sforzo possibile. Non a
caso l'intero design di Linux trasuda queste
qualità e rispecchia l'approccio essenzialmente
conservativo e semplificativo tipico di Linus.
Se, quindi, la rapida diffusione
delle release e il pieno sfruttamento del medium
Internet non erano casuali, bensì parti
integranti delle visioni da genio
dell'engineering di Linus lungo il cammino del
minimo sforzo possibile, cos'era che stava
amplificando? Cos'è che riusciva a tirar fuori
da tutto questo gran daffare?
Messa così, la domanda si
risponde da sola. Linus tendeva a stimolare e
ricompensare costantemente i suoi hacker/utenti
– stimolati dalla soddisfazione di sé per aver
preso parte all'azione, ricompensati dalla vista
dei miglioramenti costanti (perfino giornalieri)
ottenuti nel loro lavoro.
Linus puntava direttamente a
massimizzare il numero di ore/uomo coinvolte
nello sviluppo e nel debugging, rischiando
perfino la possibile instabilità del codice e
l'estinguersi del contributo degli utenti
qualora fosse risultato impossibile tener
traccia di qualche serio bug. Linus si
comportava seguendo una concezione più o meno
riassumibile come segue:
8. Stabilita una base di
beta-tester e co-sviluppatori sufficientemente
ampia, ogni problema verrà rapidamente
definito e qualcuno troverà la soluzione
adeguata.
O, in modo meno formale, “Dato un
numero sufficiente di occhi, tutti i bug vengono
a galla”. Io la chiamo la “Legge di Linus”.
La mia formulazione originale era
che ogni problema “diventerà trasparente per
qualcuno”. Linus fece notare come la persona che
si rende conto e risolve il problema non
necessariamente né di norma è la stessa persona
che per prima lo mette a fuoco. “Qualcuno scopre
il problema,” dice Linus, “e qualcun altro lo
comprende. E secondo me il compito più difficile
è proprio trovarlo”. Ma il punto è che entrambe
le cose tendono ad accadere piuttosto
rapidamente.
Questa ritengo che sia la
differenza fondamentale tra lo stile a
cattedrale e quello a bazaar. Nel primo caso la
visualizzazione dei problemi relativi a
programmazione, bug e sviluppo costituiscono
fenomeni dubbi, insidiosi, complessi. Servono
mesi di scrutinio ravvicinato da parte di più
d'uno per poi sentirsi sicuri di aver risolto
tutti i problemi. Da qui i lunghi intervalli tra
le release, e l'inevitabile delusione quando le
versioni così a lungo attese si rivelano
imperfette.
Nella concezione a bazaar,
d'altra parte, si dà per scontato che
generalmente i bug siano fenomeni marginali – o
che almeno divengano rapidamente tali se esposti
all'attenzione di migliaia di volenterosi
co-sviluppatori che soppesano ogni nuova
release. Ne consegue la rapidità di diffusione
per ottenere maggiori correzioni, e come
positivo effetto collaterale, c'è meno da
perdere se viene fuori qualche toppa
raffazzonata.
Tutto qui. E non è certo poco. Se
la “Legge di Linus” è falsa, allora ogni sistema
complesso tanto quanto il kernel Linux, ricavato
grazie al lavoro collettivo delle molte mani che
lo hanno messo insieme, a un certo punto avrebbe
dovuto crollare sotto il peso di interazioni
negative impreviste e di “profondi” bug non
scoperti. Se invece è vera, allora è sufficiente
a spiegare la relativa assenza di bug di Linux.
E forse ciò non dovrebbe
rappresentare affatto una sorpresa. Qualche anno
addietro sono stati i sociologi a scoprire che
l'opinione media di un gruppo di osservatori
equamente esperti (o equamente ignoranti) si
rivela parametro assai più affidabile di quella
di un solo osservatore scelto casualmente in
quel gruppo. Si tratta del cosiddetto “effetto
Delfi”. Ora sembra che Linus abbia dimostrato
come ciò vada applicato anche all'operazione di
debugging di un sistema operativo – ovvero che
l'effetto Delfi è in grado di addomesticare la
complessità della programmazione, persino la
complessità del kernel di un sistema operativo.
Sono in debito con Jeff Dutky dutky@wam.umd.edu
per aver sottolineato come la Legge di Linus possa
essere definita anche: “Il debugging è
parallelizzabile”. Jeff fa notare come nel corso
dell'intero processo, pur richiedendo il
coordinamento di uno sviluppatore che curi le
comunicazioni tra quanti si occupano del
debugging, questi ultimi invece non richiedono
particolare coordinamento. In tal modo non si cade
preda della notevole complessità e dei costi
gestionali imposti dal coinvolgimento di nuovi
sviluppatori.
In
pratica, nel mondo Linux la perdita di efficienza
a livello teorico, dovuta alla duplicazione di
lavoro da parte di quanti seguono il debugging,
non arriva quasi mai a rappresentare un problema.
Uno degli effetti della policy “distribuire presto
e spesso” è proprio quello di minimizzare tale
duplicazione di lavoro propagando rapidamente le
soluzioni giunte col feedback degli utenti.
Anche
Brooks
ha fatto un'osservazione su quanto sostenuto da
Jeff: “Il costo totale per il mantenimento di un
programma ampiamente utilizzato in genere viene
valutato intorno al 40 per cento, o più, del costo
dello sviluppo. Non senza sorpresa, tale costo
viene notevolmente influenzato dal numero di
utenti coinvolti. Maggiori sono questi ultimi, più
bug si trovano.”
Ciò
per via del fatto che con un maggior numero di
utenti ci sono più modi differenti di verificare
il programma. Un effetto amplificato quando
costoro sono anche co-sviluppatori. Ciascuno
affronta il compito della definizione dei bug con
un approccio percettivo e analitico leggermente
differente, una diversa angolazione per affrontare
il problema. L'effetto Delfi pare funzionare
esattamente sulla base di tali differenze. Nel
contesto specifico del debugging, le variazioni
tendono anche a ridurre la duplicazione degli
sforzi impiegati.
Quindi,
dal
punto di vista dello sviluppatore, l'aggiunta di
altri beta-tester può non ridurre la complessità
del bug “più profondo” attualmente sotto studio,
ma aumenta la probabilità che l'approccio di
qualcuno consentirà il corretto inquadramento del
problema, così che per questa persona il bug non
apparirà altro che una bazzecola.
Inoltre,
in
caso di seri bug, le varie versioni del kernel di
Linux sono numerate in modo tale che i potenziali
utenti possano scegliere o di far girare l'ultima
versione definita “stabile” oppure rischiare
d'incappare in possibili bug pur di provare le
nuove funzioni. Una tattica ancora non formalmente
imitata dalla maggior parte di hacker Linux, ma
che forse dovrebbe esserlo. Il fatto che entrambe
le scelte siano disponibili le rende entrambe più
attraenti.
5. Quando una rosa non è una
rosa?
Dopo aver osservato il
comportamento di Linus e aver elaborato una mia
teoria sul perché del suo successo, ho deciso
coscientemente di mettere alla prova tale teoria
sul mio nuovo progetto (palesemente assai meno
complesso e ambizioso).
Per prima cosa però ho
semplificato parecchio popclient. Le
implementazioni di Carl Harris erano precise, ma
mostravano quella complessità inopportuna comune
a molti programmatori in C. Trattava il codice
come elemento centrale, considerando solo come
supporto a latere la struttura dati. Come
conseguenza, il codice era eccezionale ma il
design strutturale improvvisato e bruttino
(almeno secondo gli standard elevati di questo
vecchio hacker di LISP).
Oltre al miglioramento del codice
e del design strutturale, perseguivo comunque un
altro obiettivo nell'operazione di riscrittura.
Volevo si evolvesse in qualcosa che fossi in
grado di comprendere pienamente. Non c'è alcun
divertimento nel sistemare i problemi di un
programma che non si comprende appieno.
Fu così che mi ci volle tutto il
primo mese soltanto per seguire le implicazioni
del progetto di base di Carl. La prima vera
modifica fu l'aggiunta del supporto per IMAP. In
pratica riorganizzai le macchine del protocollo
in un driver generico con tre opzioni (per POP2,
POP3 e IMAP). Insieme ai cambiamenti precedenti,
ciò illustra il principio generale che ogni
programmatore dovrebbe tenere bene a mente,
soprattutto lavorando con linguaggi come il C
che non accettano facilmente gli inserimenti
dinamici:
9. Meglio combinare una
struttura dati intelligente e un codice non
eccezionale che non il contrario.
Brooks, capitolo 9: “Mostrami [il
codice] e nascondimi [la struttura dati], e io
continuerò a essere disorientato. Mostrami [la
struttura dati], e non avrò bisogno del
[codice]; sarà del tutto ovvio.”
Per esser precisi, lui parlava di
“diagrammi” e “tabelle”. Ma considerando il
mutamento lessicale/culturale di questi
trent'anni, il senso rimane invariato.
A questo punto (inizio Settembre
1996, sei settimane dopo esser partito da zero),
ho cominciato a pensare all'opportunità di
cambiare il nome – in fondo non si trattava più
soltanto di un client POP. Ma esitavo perché
mancava ancora qualcosa di genuinamente nuovo
nel design. La mia versione di popclient doveva
ancora acquisire una propria identità.
Il cambio radicale avvenne quando
fetchmail imparò come fare il forward della
posta prelevata verso la porta SMTP. Lo spiego
meglio tra poco. Prima però: più sopra ho
parlato della decisione di usare questo progetto
come test per verificare la mia teoria sui
brillanti risultati raggiunti da Linus Torvalds.
Vi potreste chiedere, in che modo l'ho messa
alla prova? Ecco come:
- Ho diffuso le varie release
presto e spesso (quasi mai a meno di dieci
giorni di distanza; una volta al giorno nei
periodi d'intenso lavoro).
- Ho inserito nella lista dei beta
chiunque mi avesse contattato riguardo
fetchmail.
- Ho mandato simpatici messaggi
all'intera lista dei beta per annunciare ogni
nuova release, incoraggiando la gente a
partecipare.
- E ho dato ascolto ai beta
tester, ponendo loro domande sul design
adottato e plaudendoli ogni volta che mi
mandavano aggiustamenti e feedback.
Questi semplici accorgimenti
produssero una ricompensa immediata. Fin
dall'inizio del progetto, mi arrivavano report
sui bug presenti di una qualità che qualunque
sviluppatore avrebbe invidiato, spesso con buone
soluzioni in attach. Ho ricevuto mail piene di
critiche costruttive, lodi sperticate,
suggerimenti intelligenti. Il che ci porta a:
10. Se tratti i beta tester
come se fossero la risorsa più preziosa,
replicheranno trasformandosi davvero nella
risorsa più preziosa a disposizione.
Un'interessante caratteristica del
successo di fetchmail risiede nell'ampiezza
dell'elenco dei beta, i “fetchmail-friend”. Si è
rapidamente raggiunta quota 249, con nuovi
arrivi due o tre volte la settimana.
L'ultima revisione, fine Maggio
1997, ha rivelato che la lista andava perdendo
membri, dopo aver raggiunto un massimo di 300
nominativi, e ciò per un motivo degno di nota.
In parecchi mi hanno chiesto di essere rimossi
perché fetchmail funzionava così bene che non
c'era più alcun motivo di seguire il traffico
della lista! Forse anche ciò fa parte del
normale ciclo di vita di un progetto maturo in
stile bazaar.
6. Popclient diventa Fetchmail
Il vero punto di svolta del progetto
ebbe luogo quando Harry Hochheiser mi spedì il
codice iniziale per fare il forward alla porta
SMTP della macchina client. Mi sono reso
immediatamente conto che l'implementazione
affidabile di tale funzione avrebbe reso
pressoché obsoleta ogni altra modalità di
consegna della posta.
Per molte settimane mi ero messo a
giocare con l'interfaccia di fetchmail,
passabile ma disordinata – poco elegante e con
troppe opzioni sparse tutt'intorno. Tra queste
mi davano particolarmente fastidio, anche senza
capire perché, quelle utilizzate per trasferire
la posta prelevata in una certa mailbox o
altrove.
Quel che mi veniva in mente pensando
alla funzione del “SMTP forwarding” era che
popclient voleva cercare di far troppe cose. Era
stato ideato per essere sia un “mail transport
agent” (MTA) sia un “mail delivery agent” (MDA)
a livello locale. Con il forward SMTP avrebbe
potuto smettere di essere un MDA per divenire un
puro MTA, trasferendo ad altri programmi la
posta per la consegna locale, proprio come fa
sendmail.
Perché darsi da fare a sistemare le
complesse configurazioni per un MDA o le
impostazioni per le mailbox, quando innanzitutto
è quasi sempre garantito che la porta 25 rimane
disponibile per questo su ogni piattaforma con
supporto TCP/IP? Soprattutto quando ciò
significa che i messaggi prelevati appariranno
come posta SMTP normalmente inviata dal
mittente, che è poi quel che stiamo cercando di
ottenere.
Ci sono diverse lezioni da trarre a
questo punto. Primo, l'idea del “SMTP
forwarding” era la prima grossa ricompensa per
aver tentato coscientemente di emulare i metodi
di Linus. Era stato un utente a suggerirmi
questa fantastica idea – non mi restava che
comprenderne le implicazioni.
11. La cosa migliore, dopo l'avere
buone idee, è riconoscere quelle che arrivano
dagli utenti. Qualche volta sono le migliori.
Fatto interessante, è facile scoprire
che se sei completamente onesto e autocritico su
quanto è dovuto agli altri, il mondo intero ti
tratterà come se ogni bit di quell'invenzione
fosse opera tua, mentre impari a considerare con
sempre maggior modestia il tuo genio innato.
Abbiamo visto come tutto ciò abbia funzionato a
meraviglia con Linus!
(Quando ho presentato questo scritto
alla conferenza su Perl dell'Agosto 1997, in
prima fila c'era Larry Wall. Non appena sono
arrivato al punto di cui sopra, ha intonato in
stile revival-religioso, “Diglielo, diglielo,
fratello!” Tutti i presenti si son messi a
ridere, perché sapevano come ciò avesse
funzionato bene anche per l'inventore di Perl.)
Dopo aver lavorato sul progetto nello
stesso spirito per alcune settimane, mi son
visto arrivare lodi simili non soltanto dagli
iscritti alla lista ma anche da altre persone
che venivano a sapere della cosa. Ho conservato
qualche email; forse me le andrò a rileggere nel
caso iniziassi a chiedermi se la mia vita abbia
mai avuto un qualche valore :-).
Ma ci sono altre due lezioni da
trarre, più fondamentali e non politiche, buone
per ogni tipo di design.
12. Spesso le soluzioni più
interessanti e innovative arrivano dal fatto
di esserti reso conto come la tua concezione
del problema fosse errata.
Avevo cercato di risolvere il
problema sbagliato continuando a lavorare su
popclient in quanto combinazione MTA/MDA con
tutte le possibili modalità di consegna della
posta. Il design di fetchmail aveva bisogno di
essere reimpostato dall'inizio come un puro MTA,
a parte il normale percorso della posta relativo
a SMTP.
Quando sbatti la testa contro il muro
nel lavoro di programmazione – quando cioè non
riesci più a pensare alla prossima “patch” –
spesso è ora di chiedersi non se hai la risposta
giusta, ma se ti stai ponendo la giusta domanda.
Forse bisogna inquadrare nuovamente il problema.
Be', mi toccò inquadrare meglio il
problema. Chiaramente la cosa giusta da fare era
(1) posizionare il supporto per il “SMTP
forwarding” nel driver generico, (2) farla
diventare la funzione default, (3) sbarazzarsi
di tutte le altre modalità di consegna della
posta, specialmente le opzioni “deliver-to-file”
e “deliver-to-standard-output”.
Per qualche tempo ho esitato a
compiere il passo (3), temendo di avvilire
quanti usavano da molto tempo popclient proprio
per i diversi meccanismi di consegna. In teoria,
avrebbero potuto immediatamente passare ai file
“.forward” oppure agli equivalenti
“non-sendmail” per ottenere il medesimo effetto.
In pratica, però, tale transizione sarebbe
risultata impraticabile.
Quando mi decisi comunque a farlo, ne
risultarono enormi benefici. Le parti più
confuse del codice del driver scomparvero. La
configurazione divenne radicalmente più semplice
– niente più girovagare nel sistema MDA e nella
mailbox, niente più preoccupazioni per vedere se
il sistema operativo supportasse o meno il
blocco dei file.
Venne anche eliminata l'unica
possibilità di perdere dei messaggi. Se,
specificando la consegna in un file, il disco è
pieno, la posta va perduta. Impossibile che ciò
accada con il “SMTP forwarding” perché l'altro
SMTP in ascolto non accetterà l'OK a meno che il
messaggio non possa essere correttamente
consegnato o almeno filtrato per il prelievo
successivo.
Inoltre, le prestazioni complessive
risultarono migliorate (anche se così non sembra
quando lo si fa girare una sola volta). Altro
beneficio non insignificante del cambiamento fu
che la chiamata manuale risultò assai più
semplificata.
In seguito fui costretto a
reintrodurre la funzione di consegna tramite un
MDA locale specificato dall'utente, per
consentire la gestione di strane situazioni
relative allo SLIP dinamico. Ma riuscii a farlo
in maniera più semplice.
Morale? Non esitare a buttar via
opzioni inanellate una sull'altra quando puoi
rimpiazzarle senza perdere in efficienza. Diceva
Antoine de Saint-Exupéry (aviatore e designer di
aerei, quando non scriveva libri per bambini):
13. “La perfezione (nel design) si
ottiene non quando non c'è nient'altro da
aggiungere, bensì quando non c'è più niente da
togliere.”
Quando il codice diventa migliore e
più semplice, allora vuol dire che va bene. E
nel processo, il design di fetchmail acquistò
una sua propria identità, diversa dal popclient
originario.
Era giunta l'ora di cambiar nome. Il
nuovo design assomigliava più a sendmail di
quanto lo fosse il vecchio popclient; entrambi
sono MTA, ma mentre sendmail spinge e poi
consegna, il nuovo popclient tira e poi
consegna. Così, a due mesi dai blocchi di
partenza, decisi di dargli il nuovo nome,
fetchmail.
7. Fetchmail diventa adulto
Eccomi qui con un design ben fatto
e innovativo, un codice che ero certo
funzionasse bene perchè lo usavo ogni giorno, e
una spumeggiante lista di beta tester.
Gradualmente mi resi conto che non ero più
indaffarato con uno stupido programmino
personale che forse avrebbe potuto interessare
pochi altri. Stavo lavorando su un programma di
cui ogni hacker dotato di mailbox Unix e
connessione SLIP/PPP non avrebbe potuto fare a
meno.
Grazie all'opzione di “SMTP
forwarding”, superava sicuramente i programmi
rivali fino a diventare potenzialmente una
“categoria killer”, uno di quei programmi
classici che occupano la propria nicchia in
maniera perfetta, facendo scartare e quasi
dimenticare ogni possibile alternativa.
Credo che simili risultati siano
impossibili da perseguire o da pianificare. Devi
esser trascinato dentro la storia da idee così
potenti che, col senno di poi, quei risultati
appaiono del tutto inevitabili, naturali,
perfino prestabiliti. L'unico modo per provarci
è farsi venire un sacco di idee, oppure avere la
capacità di portare le idee degli altri al di là
del punto in cui essi stessi credevano potessero
arrivare.
Andrew Tanenbaum ebbe l'idea
originale di realizzare un linguaggio di base
Unix per il 386, da usare come strumento
didattico. Linus Torvalds ha spinto il concetto
del Minix ben oltre quanto lo stesso Andrew
ritenesse possibile – ed è diventato qualcosa di
meraviglioso. Allo stesso modo (pur se su scala
minore) io ho preso alcune idee da Carl Harris e
Harry Hochheiser, e le ho spinte oltre. Nessuno
di noi è stato “originale” nel senso romantico
in cui si immagina un genio. Ma a ben vedere la
maggior parte della scienza, dell'ingegneria e
dello sviluppo del software non viene realizzata
da alcun genio originale, il contrario della
mitologia dell'hacker.
I risultati ottenuti erano
piuttosto notevoli – meglio, esattamente quel
tipo di successo che ogni hacker sogna! E ciò
significa che avrei potuto mirare anche a
standard più elevati. Per rendere fetchmail così
ben fatto come lo vedevo ora, avrei dovuto
scrivere non soltanto per le mie necessità ma
anche per includere il supporto di opzioni
necessarie ad altri e tuttavia fuori dalla mia
orbita. E fare ciò mantenendo al contempo
semplice e robusto il programma.
La prima funzione di gran lunga più
importante che scrissi dopo essermi reso conto
di ciò, fu il supporto multiutente – la
possibilità di prelevare la posta da più mailbox
in cui erano stati accumulati tutti i messaggi
per un gruppo di utenti, e quindi smistare ogni
singolo messaggio ai rispettivi destinatari.
Decisi di aggiungere il supporto
multiutente in parte perché alcuni lo
richiedevano, ma soprattutto perché pensavo
avrebbe buttato via ogni bug dal codice per un
solo utente, costringendomi a fare attenzione
alla gestione dei vari indirizzi. E così fu. Mi
ci volle parecchio tempo per sistemare tutto
nella RFC
822, non perché sia difficile mettere a
posto ogni singola parte, ma perché coinvolgeva
una montagna di dettagli interdipendenti e
instabili.
In
ogni caso, anche la funzione per gli indirizzi
multiutenti si rivelò un'ottima decisione. Ecco
come me ne sono accorto:
14.
Ogni
strumento dovrebbe rivelarsi utile nella maniera
che ci si attende, ma uno strumento davvero ben
fatto si presta ad utilizzi che non ci si
aspetterebbe mai.
L'uso
inatteso
della funzione multiutenti è per una mailing list
quando questa viene mantenuta sul lato client
della connessione SLIP/PPP, attivando l'espansione
dell'alias. Ne consegue che chi fa girare un PC
tramite un account con un provider Internet è in
grado di gestire una mailing list senza dover
accedere continuamente ai file alias del provider.
Altra
importante
modifica richiesta dai beta tester fu il supporto
per operazioni MIME in 8-bit. Qualcosa piuttosto
semplice a farsi, poiché avevo fatto bene
attenzione a mantenere il codice pulito per
inserire l'8-bit. Non perché avessi anticipato
tale richiesta, quanto piuttosto per rispettare
un'altra regola:
15.
Quando
si scrive del software per qualunque tipo di
gateway, ci si assicuri di disturbare il meno
possibile il flusso dei dati – e *mai* buttar
via alcun dato a meno che il destinatario non ti
ci costringa!
Se
non avessi rispettato questa regola, il supporto
per MIME in 8-bit sarebbe risultato difficile e
problematico. Così invece tutto quel che dovetti
fare fu leggere la RFC
1652 e aggiungere poche stringhe per far
generare l'header.
Alcuni
utenti
europei mi hanno costretto a inserire un'opzione
per limitare il numero dei messaggi prelevati a
ogni sessione (in modo da controllare i costi di
collegamento, per via delle care tariffe imposte
dalle aziende telefoniche nazionali). Ho resistito
per parecchio tempo, e ancor'oggi non ne sono
pienamente soddisfatto. Ma se scrivi programmi per
tutto il mondo, devi dare ascolto ai tuoi clienti
– e ciò rimane valido anche se non ti ricompensano
in denaro.
8. Qualche altra lezione da
Fetchmail
Prima di tornare alle questioni
generali sul “software-engineering”, è il caso
di considerare qualche altro insegnamento
specifico a seguito di quest'esperienza con
fetchmail.
La sintassi del file rc include una
serie di parole-chiave facoltative completamente
ignorate dall'analizzatore. La sintassi in
“quasi-inglese” che si ottiene è notevolmente
più leggibile delle semplici coppie nome/valore
che si rimangono dopo aver eliminato le prime.
Tutto ebbe inizio come un
esperimento a notte fonda dopo essermi accorto
di quante fossero le dichiarazioni del file rc
che cominciavano ad assomigliare a un
minilinguaggio imperativo. (Per lo stesso motivo
ho modificato in “poll” la parola-chiave
“server” del popclient originale).
Mi venne da pensare che sarebbe
stato più facile usare qualcosa di simile
all'inglese comune piuttosto che quel
minilinguaggio imperativo. Ora, pur essendo il
sottoscritto un convinto fautore della scuola di
design del tipo “trasformalo in linguaggio”,
come esemplificato da Emacs, dall'HTML e da
molti motori di database, generalmente non mi
annovero tra i fan delle sintassi in
“quasi-inglese”.
Tradizionalmente i programmatori
hanno sempre avuto la tendenza a favorire
sintassi molto precise e compatte, del tutto
prive di ridondanza. Si tratta di un'eredità
culturale del tempo in cui le risorse
informatiche erano costose, così gli
analizzatori dovevano risultare semplici ed
economici al massimo grado. Allora l'inglese,
con quel 50% di ridondanza, sembrava un modello
poco appropriato.
Non è questa la ragione per cui
generalmente io evito le sintassi in
quasi-inglese; l'ho citata qui soltanto per
demolirla. Con l'attuale economicità dei cicli e
delle strutture, la pulizia non dovrebbe essere
un obiettivo in sé. Al giorno d'oggi è più
importante che un linguaggio sia conveniente per
gli esseri umani anziché economico per il
computer.
Esistono comunque buoni motivi per
procedere con cautela. Uno è rappresentato dai
costi della complessità dell'analizzatore – non
è il caso di aumentare tale complessità fino a
raggiungere il punto in cui produrrà bug
significativi e confusione nell'utente. Un'altra
ragione è che cercare di rendere un linguaggio
in quasi-inglese spesso richiede un tale
aggiustamento linguistico che le somiglianze
superficiali con il linguaggio naturale generino
confusione tanto quanto l'eventuale sintassi
tradizionale. (Come si può notare con evidenza
nei linguaggi di interrogazione dei database di
“quarta generazione” e commerciali).
La sintassi di controllo di
fetchmail riesce a evitare questi problemi
perché il dominio riservato al linguaggio è
estremamente limitato. Non si avvicina neppure
lontanamente a un linguaggio di tipo generale;
le cose che dice non sono affatto complicate,
lasciando quindi poco spazio a potenziali
confusioni, quando ci si sposta mentalmente tra
un ristretto ambito d'inglese e il linguaggio di
controllo vero e proprio. Credo qui si tratti di
una lezione di più ampia portata:
16. Quando il linguaggio usato
non è affatto vicino alla completezza di
Turing, un po' di zucchero sintattico può
esserti d'aiuto.
Un'altra lezione riguarda la
sicurezza “al buio”. Alcuni utenti di fetchmail
mi avevano chiesto di modificare il software in
modo che potesse conservare le password
crittografate nel file rc, evitando così il
rischio che qualche ficcanaso potesse scoprirle
casualmente.
Non l'ho fatto perché in realtà ciò
non aggiunge alcuna protezione. Chiunque sia
stato autorizzato a leggere il file rc, sarebbe
comunque in grado di far girare fetchmail – e se
è la password che cerca, saprebbe come
decodificarla tirandola fuori dallo stesso
codice di fetchmail.
Qualsiasi possibile codifica della
password operata da .fetchmailrc, non avrebbe
fatto altro che fornire un falso senso di
sicurezza a quelli che non vogliono spremersi le
meningi.
La regola generale è:
17. Un sistema di sicurezza è
sicuro soltanto finché è segreto. Meglio
diffidare degli pseudo-segreti.
9. Le pre-condizioni necessarie
per lo stile bazaar
I primi lettori e revisori di questo
scritto hanno ripetutamente sollevato domande
sulle pre-condizioni necessarie per il successo
dello sviluppo in stile bazaar, comprendendo con
ciò sia le qualifiche del leader del progetto
sia lo stato del codice al momento della
diffusione pubblica e della nascita della
possibile comunità di co-sviluppatori.
È alquanto evidente come lo stile
bazaar non consenta la scrittura del codice
partendo da zero. Si possono fare test, trovare
i bug, migliorare il tutto, ma sarebbe molto
difficile dar vita dall'inizio a un progetto in
modalità bazaar. Linus non lo ha fatto. Neppure
io. La nascente comunità di sviluppatori deve
avere qualcosa da far girare e con cui giocare.
Quando s'inizia a costruire la
comunità, bisogna essere in grado di presentare
una promessa plausibile. Non è detto che il
programma debba funzionare particolarmente bene.
Può anche essere crudo, pieno di bug,
incompleto, scarsamente documentato. Non deve
però mancare di convincere i potenziali
co-sviluppatori che possa evolversi in qualcosa
di veramente ben fatto nel prossimo futuro.
Quando Linux e fetchmail vennero
diffusi pubblicamente, erano dotati di un design
di base forte e attraente. Molte persone
ritengono che il modello bazaar da me presentato
riveli correttamente questa fase critica, per
poi da qui saltare alla conclusione che sia
indispensabile un elevato livello di intuizione
e bravura da parte di chi guida il progetto.
Ma Linus prese il suo design da
Unix. All'inizio ho fatto lo stesso con il
popclient originario (anche se poi risultò molto
diverso, assai più di quanto è accaduto con
Linux, fatte le debite proporzioni). È dunque
vero che il leader/coordinatore di un progetto
in stile bazaar debba possedere un eccezionale
talento nel design? Oppure può cavarsela facendo
leva sui talenti altrui?
Non credo sia essenziale che il
coordinatore possa produrre design eccezionali,
ma è assolutamente centrale che sia capace di
riconoscere le buone idee progettuali degli
altri.
Ciò appare evidente da entrambi i
progetti di Linux e fetchmail. Pur non essendo
un designer particolarmente originale (come
discusso in precedenza), Linus ha dimostrato un
ottima intuizione nel saper riconoscere il buon
design per poi integrarlo nel kernel di Linux.
Ed ho già descritto come l'idea più potente di
fetchmail (SMTP forwarding) mi sia arrivata da
qualcun altro.
I primi lettori di questo testo mi
hanno fatto i complimenti mettendo a fuoco la
mia propensione a sottovalutare l'originalità
del design nei progetti in stile bazaar perchè
ne possiedo a volontà io stesso, e quindi la dò
per scontata. In effetti, c'è qualcosa di vero
in quest'affermazione; il design (in alternativa
al codice o al debugging) è la mia capacità
migliore.
Ma il problema con il fatto di
essere bravi e originali nel design del software
è che tende a divenire un'abitudine – prendi a
fare cose carine e complicate quando invece
dovresti tenerle semplici e robuste. Proprio per
questa ragione mi sono crollati addosso vari
progetti, ma con fetchmail sono stato attento a
non farlo.
Credo insomma che il progetto di
fetchmail abbia avuto successo in parte perché
ho limitato la mia tendenza a esser bravo; ciò
va (almeno) contro l'essenzialità
dell'originalità del design per il successo dei
progetti a bazaar. Consideriamo Linux.
Supponiamo che Linus Torvalds avesse cercato di
tirar fuori le innovazioni fondamentali dal
design del sistema operativo nel corso dello
sviluppo; quali probabilità esistono che il
kernel risultante fosse ugualmente stabile ed
efficace come quello che abbiamo ora?
È chiaro che occorrano capacità di
un certo livello per il design e il codice, ma
personalmente mi aspetto, da quasi tutte le
persone che pensano seriamente di lanciare un
progetto bazaar, un livello superiore. Il
mercato interno della reputazione della comunità
open source esercita una sottile pressione sulle
persone in modo che non si lancino dei progetti
se non si è abbastanza competenti per seguirli.
Finora quest'approccio ha funzionato piuttosto
bene.
Esiste un altro tipo di capacità
normalmente non associata allo sviluppo del
software che ritengo importante al pari della
bravura nel design per i progetti bazaar – anzi,
forse ancora più importante. Il coordinatore o
leader deve essere in grado di comunicare
efficacemente con gli altri.
D'altronde è ovvio che per metter su
una comunità di sviluppatori occorra attirare
gente, coinvolgerli in quel che stai facendo,
tenerli contenti per il lavoro che fanno. Lo
sfrigolìo tecnico aiuta molto in questo senso,
ma è ben lungi dall'esser tutto. È anche
importante il tipo di personalità che proietti.
Non è certo una coincidenza che
Linus sia un tipo simpatico, capace di piacere
alla gente e di farsi aiutare. Da parte mia, io
sono un estroverso energetico cui piace lavorare
tra la folla, oltre ad avere qualcosa dei modi e
dell'istinto del comico. Per far funzionare il
modello a bazaar, aiuta parecchio essere in
grado di esercitare almeno un po' di fascino
sulla gente.
10. Il contesto sociale del
software open source
È 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.
11. Ringraziamenti
Questo scritto è stato migliorato
grazie alle conversazioni avute con molte
persone che hanno contribuito a trovarne i bug.
Ringrazio in modo particolare Jeff Dutky , che mi ha suggerito la
formulazione “il debugging è parallelizzabile”
e che mi ha aiutato a svilupparne le analisi
conseguenti. Grazie anche a Nancy Lebovitz per avermi suggerito
di emulare Weinberg citando Kropotkin.
Critiche costruttive sono venute anche da
Joan Eslinger e Marty
Franz della
lista General Technics. Sono grato ai
membri del PLUG, Philadelphia Linux
User's Group, per essersi prestati come
primo test pubblico per la versione
iniziale di questo testo. Infine, i
commenti iniziali di Linus Torvalds sono
stati di grande aiuto e il suo sostegno
molto incoraggiante.
12. Letture consigliate
Ho citato diversi passaggi dal
classico di Frederick P. Brooks “The Mythical
Man-Month” perché, in molti sensi, le sue
introspezioni meritano ulteriori riflessioni.
Raccomando di cuore l'edizione pubblicata in
occasione del 25° Anniversario da Addison-Wesley
(ISBN 0-201-83595-9), che contiene anche il suo
saggio del 1986 “No Silver Bullet”.
Questa nuova edizione contiene
un'importante retrospettiva dei 20 anni
successivi in cui Brooks ammette schiettamente
come alcuni giudizi espressi nel testo originale
non abbiano sostenuto la prova del tempo. Ho
letto la retrospettiva dopo aver sostanzialmente
completato questo scritto, e sono rimasto
sorpreso nello scoprire che Brooks attribuisse
pratiche da quasi-bazaar a Microsoft! (In
realtà, però, si è poi visto come tale
attribuzione fosse erronea. Nel 1998 abbiamo
appreso dagli Halloween Documents come la
comunità interna dei programmatori di Microsoft
risulti pesantemente balcanizzata, senz'alcuna
possibilità per quel tipo di accesso generale ai
sorgenti tipico dello stile bazaar).
“The Psychology Of Computer
Programming” di Gerald M. Weinberg (New York,
Van Nostrand Reinhold 1971) presenta il
concetto, malamente etichettato, di
“programmazione senza ego.” Pur essendo l'autore
nient'affatto tra i primi a rendersi conto della
futilità del “principio del comando”,
probabilmente fu il primo a riconoscere e
sostenere tale punto in particolare connessione
con lo sviluppo del software.
Richard P. Gabriel, occupandosi
della cultura Unix dell'era pre-Linux, sosteneva
con riluttanza la superiorità di un modello
quasi-bazaar nel suo saggio del 1989: “Lisp:
Good News, Bad News, and How To Win Big”. Anche
se per molti versi un po' datato, il testo è
ancora giustamente celebrato dai fan del Lisp
(incluso il sottoscritto). Qualcuno mi ha
ricordato che la sezione intitolata “Worse Is
Better” si propone quasi come un'anticipazione
di Linux. L'articolo è disponibile sul World
Wide Web:
http://www.naggum.no/worse-is-better.html.
“Peopleware:
Productive
Projects and Teams” di De Marco e Lister (New
York; Dorset House, 1987; ISBN 0-932633-05-6) è
una gemma sottovalutata che mi ha fatto piacere
veder citata nella retrospettiva di Fred Brooks.
Anche se poco di quanto scrivono gli autori può
applicarsi direttamente alle comunità Linux o open
source, le loro riflessioni sulle condizioni
necessarie per un lavoro creativo sono acute e
valide per chiunque volesse provare ad applicare
alcune delle virtù del modello bazaar in un
contesto commerciale.
Devo
infine
ammettere d'aver inizialmente intitolato questo
scritto “La cattedrale e l'agorà”, essendo
quest'ultimo il termine greco per indicare un
mercato all'aperto o un luogo d'incontro pubblico.
Ciò per l'influenza dei saggi embrionali di Mark
Miller e Eric Drexler “Agoric systems” in cui
venivano descritte le proprietà emergenti
dell'ecologia computazionale di tipo
quasi-commerciale. Tali scritti mi hanno preparato
a riflettere con chiarezza sugli analoghi fenomeni
nell'ambito della cultura open source quando Linux
mi ci ha fatto sbattere il muso cinque anni dopo.
Questi scritti sono reperibili sul Web: http://www.agorics.com/agorpapers.html.
13. Epilogo: Netscape si
unisce al bazaar!
È proprio strano rendersi conto
di aiutare lo sviluppo della storia...
Il 22 gennaio 1998, circa sette
mesi dopo la prima pubblicazione di questo
scritto, Netscape Communications, Inc. ha
annunciato la diffusione pubblica dei codici
sorgenti di Netscape Communicator. Fino al
momento dell'annuncio, non avevo alcuna idea che
ciò sarebbe mai potuto accadere.
Subito dopo l'annuncio, Eric
Hahn, Executive Vice President e Chief
Technology Officer di Netscape, mi ha inviato
questa breve email: “A nome di tutti noi di
Netscape, voglio ringraziarti per averci aiutato
innanzitutto a compiere questo passo. Il tuo
pensiero e i tuoi scritti sono stati di
fondamentale ispirazione per la nostra
decisione.”
La settimana successiva (4
Febbraio 1998), sono arrivato in aereo nella
Silicon Valley su invito di Netscape per
partecipare a una giornata di incontri sulle
strategie future con alcuni dei loro dirigenti
esecutivi e il personale tecnico. Abbiamo
progettato insieme la strategia e la licenza per
la release del codice di Netscape, oltre ad aver
buttato giù ulteriori piani che speriamo alla
fine possano avere un impatto positivo e
profondo sulla comunità open source. Al momento
in cui scrivo, è troppo presto per entrare nello
specifico; ma entro qualche settimana dovrebbero
essere noti maggiori dettagli.
Netscape sta per fornirci un test
su larga scala e assai concreto del modello
bazaar all'interno del mondo commerciale. La
cultura dell'open source si trova di fronte a un
pericolo; se l'operazione di Netscape non
dovesse funzionare, il concetto stesso di open
source potrebbe risultarne così screditato che
il mondo commerciale non gli si avvicinerà per
un'altra decade.
D'altra parte, però, si tratta di
una spettacolare opportunità. L'iniziale
reazione a tale mossa in quel di Wall Street e
altrove è stata cautamente positiva. Ci è stata
data la possibilità di provare cosa sappiamo
fare. Se grazie a questa mossa Netscape saprà
riguadagnare una sostanziale quota di mercato,
ciò potrebbe davvero innescare la rivoluzione
attesa da lungo tempo nell'industria del
software.
L'anno prossimo sarà un anno
molto istruttivo e interessante.
14. Cronologia delle
versioni e delle modifiche
$Id: cathedral-bazaar.sgml,v
1.42 22/11/1998 04:01:20 esr Exp $
Presentazione della 1.16 al
Linux Kongress, 21 Maggio 1997.
Bibliografia aggiunta il 7
Luglio 1997 nella 1.20.
Aggiunto l'aneddoto sulla
Perl Conference il 18 Novembre 1997 nella 1.27.
Modificato “free software” in
“open source” il 9 Febbraio 1998 nella 1.29.
Aggiunto “Epilogo: Netscape
si unisce al bazaar!” il 10 Febbraio 1998 nella
1.31.
Eliminato il grafico di Paul
Eggert sulla questione GPL-bazaar dopo vivaci
discussioni con RMS il 28 Luglio 1998.
Aggiunta correzione su Brooks
basata sugli Halloween Documents il 20 Novembre
1998 nella 1.40.
Altri livelli di revisione
hanno incorporato minori aggiustamenti
editoriali.
Traduzione
italiana a cura di Bernardo Parrella berny@apogeonline.com,
Giugno 1999
Per
il testo originale inglese: http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar.html
|