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.

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:

1. 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).

2. Ho inserito nella lista dei beta chiunque mi avesse contattato riguardo fetchmail.

3. Ho mandato simpatici messaggi all'intera lista dei beta per annunciare ogni nuova release, incoraggiando la gente a partecipare.

4. 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.