Il bazaar e la cattedrale

In questo articolo, esaminerò l'anatomia di un progetto open-source di successo (fetchmail), che è stato deliberatamente condotto come un esperimento per mettere alla prova alcune sorprendenti teorie sull'ingegneria del software che sono suggerite dalla storia di Linux. Questo articolo discute tali teorie in termini di due modelli di sviluppo fondamentalmente diversi: il modello 'a cattedrale' tipico della maggior parte del mondo commerciale, e il modello 'a bazaar' del modo Linux. Mostrerò che questi modelli derivano da interpretazioni antitetiche di quella che è la natura del debugging (correzione di errori) . La tesi che cercherò di dimostrare, partendo dall'esperienza Linux, è espressa dalla frase ``Se ci sono abbastanza occhi, tutti i bachi (errori) sono facili''. Questo suggerirà interessanti paragoni con sistemi ad autocorrezione costituiti da agenti "egoisti"; concluderò esplorando le possibili conseguenze di queste circostanze nel mondo dello sviluppo del software.

Contenuti

1 La cattedrale e il bazaar

Linux è sovversivo. Chi avrebbe pensato, anche solo cinque anni fa, che un sistema operativo serio potesse scaturire, come per magia, dagli sforzi a tempo perso di molte migliaia di programmatori dispersi per il pianeta e collegati solo dal tenue collante di Internet?

È certo che io non ci pensavo assolutamente. Nel momento in cui Linux è comparso sui miei radar, nel 1993, avevo lavorato per una decina anni su Unix e nello sviluppo open-source, ed ero stato uno dei primi a dare il mio contributo a GNU alla metà degli anni 80. Avevo già rilasciato una buona quantità di software open-source in rete, come autore o coautore di diversi programmi (nethack, Emacs VC e GUD, xlife, e qualche altro) che sono ancora usati oggi. E, perciò, credevo di sapere come funzionavano le cose.

Linux sovvertì gran parte di quello che credevo di sapere. Per lungo tempo a avevo praticato il Vangelo Unix sugli strumenti piccoli, la prototipazione rapida e programmazione evolutiva. Nello stesso tempo pensavo che esistesse un livello di complessità oltre il quale era obbligatorio passare ad un modello centralizzato: pensavo che il software più importante (sistemi operativi o programmi di una certa mole, come ad esempio Emacs) dovessero essere costruiti come lo furono le cattedrali, con arte sopraffina da maghi isolati o da piccoli gruppi di adepti in splendido isolamento, senza che neppure una beta fosse rilasciata prima che arrivasse il momento.

Il modo di sviluppare di Linus Torvalds - rilasciare presto e spesso, delegare il più possibile, essere aperti fin quasi alla promiscuità - era per me sorprendente. Non c'era nulla dell'atmosfera della cattedrale: piuttosto, la comunità di Linux assomigliava ad un grande, assordante bazaar di piani di lavoro e approcci differenti (ben rappresentati dai siti di archiviazione di Linux, che accettano contributi da chiunque). Mi sembrava che l'unico modo in cui un sistema stabile e coerente poteva emergere da questo agitato bazaar fosse una successione di miracoli.

Fu perciò con grande meraviglia che constatai che questo bazaar, apparentemente, funzionava, e bene: man mano che mi familiarizzavo col luogo, non solo lavoravo a progetti individuali, ma cercavo di capire come mai il mondo di Linux, invece di disintegrarsi nel caos, sembrasse procedere da un successo all'altro a velocità ignote ai costruttori di cattedrali.

Verso la metà del 1996 cominciavo a pensare di essermene fatto un'idea, e il caso mi diede il perfetto strumento per mettere la mia teoria alla prova, sotto forma di un progetto open-source che decisi di condurre secondo lo stile bazaar.

La storia di tale progetto, e del su successo, è l'argomento del resto di questo articolo,e la userò per proporre modelli di sviluppo open-source. Non tutto quello che dirò l'ho imparato nel mondo Linux, ma, come vedremo, nel mondo di Linux esse vengono messe a buon frutto in modo singolarmente efficace.

Spero che questo esempio possa aiutarvi a capire cosa ha reso la comunità di Linux una tale sorgente di ottimo software, e, magari, darvi qualche idea su come migliorare la vostra produttività.

2 La posta deve arrivare

Era dal 1993 che gestivo la parte tecnica di un piccolo Internet Service Provider (Chester County InterLink - CCIL) di West Chester, in Pennsylvania. (Io fui uno dei membri fondatori di CCIL, nonché l'autore del nostro software di messaggeria elettronica, che potete provare collegandovi via telnet a locke.ccil.org , e che oggi supporta circa tremila utenti su trenta linee.) Questo lavoro mi consentiva - anzi, mi imponeva - di essere in rete 24 ore al giorno attraverso la linea dedicata a 56K di CCIL.

Così, mi ero abituato ad avere un servizio di posta Internet praticamente istantaneo. Per motivi che non vale la pena spiegare, era difficile ottenere un buon collegamento SLIP tra la mia macchina di casa (snark.thyrsus.com) e CCIL. Quando alla fine riuscii ad ottenerlo, scoprii che collegarmi in telnet per leggere la posta era piuttosto noioso: avevo bisogno di qualcosa che scaricasse tutta la mia posta su snark in modo da poterla leggere e gestire localmente.

Il semplice forward contemplato da sendmail non avrebbe funzionato, perché la mia macchina è spesso scollegata e non ha un indirizzo IP statico: quello che ci voleva era un programma che utilizzasse il mio collegamento SLIP e trasferisse la mia posta permettendo poi la consegna locale. Sapevo bene che esistevano programmi del genere, i quali normalmente usavano un semplice protocollo applicativo detto POP (Post Office Protocol); e infatti nel sistema operativo (BSD/OS) in uso al CCIL c'era un bellissimo server POP3.

Ora mi serviva un client POP3, e sulla rete ne trovai uno già pronto (tre o quattro, per la verità). per un po', usai pop-perl, al quale però mancava la capacità - apparentemente ovvia - di modificare l'intestazione dei messaggi in modo da rendere possibile rispondere correttamente.

Il problema era il seguente: supponiamo che Joe - su locke - mi invii un messaggio, che io recupero da snark. Se l'intestazione del messaggio non viene modificata, al momento di rispondere il mio programma di posta cercherà di mandarlo a un tale `Joe', utente di snark, che in realtà non esiste. Aggiungere a mano `@ccil.org' a tutti gli indirizzi divenne rapidamente una gran seccatura.

Questo era un compito adatto ad un computer: ma nessuno dei client POP che avevo trovato sapeva come occuparsene. E questa è una prima lezione da imparare:

1. Ogni buon prodotto software parte per soddisfare una qualche necessità del programmatore.

Forse questo è ovvio (almeno quanto il proverbio ``La necessità è la madre dell'invenzione''), tuttavia la gran parte dei programmatori passano la loro giornata lavorando su prodotti di cui non hanno bisogno e che non amano. Nel mondo di Linux, questo non succede -- e questo spiega come mai la qualità media del software prodotto in questo ambiente sia così elevata.

Pensate forse che a questo punto mi sia furiosamente lanciato a scrivere un client POP3 nuovo di zecca? Ma neanche per idea! Mi misi ad esaminare i programmi che già avevo chiedendomi ``qual'è il più vicino ai miei bisogni?'' Questo perché:

2. I buoni programmatori sanno cosa scrivere, i grandi programmatori sanno cosa riscrivere (e riusare)

Anche se non pretendo di essere uno dei grandi programmatori, cerco sempre di imitarli: e una delle caratteristiche dei grandi è la pigrizia costruttiva. Essi sanno che non sono gli sforzi, ma i risultati quelli che vengono ricompensati, e che è quasi sempre meglio partirei da una buona soluzione parziale che dal nulla.

Ad esempio, Linus Torvalds non cercò di scrivere Linux da zero: cominciò a riutilizzare codice ed idee che aveva trovato in Minix, un minuscolo sistema operativo, simile a Unix, che funzionava sui 386. Alla fine tutto il codice Minix sparì o fu totalmente riscritto, ma, finché c'era, costituiva l'impalcatura di ciò che sarebbe poi divenuto Linux.

Era nello stesso spirito che io andavo in cerca ci un programma per POP che fosse scritta abbastanza bene da poter diventare una base di sviluppo.

La tradizione di condivisione dei sorgenti del mondo Unix è sempre stata benefica per il riutilizzo di codice (questo è il motivo per cui, nonostante alcune serie riserve sul sistema operativo, Unix fu scelto come piattaforma per il progetto GNU). Il mondo Linux ha portato questo concetto al suo ultimo limite tecnologico: ci sono terabyte di codice sorgente disponibile per Linux. Per questo motivo, il tempo dedicato a cercare una soluzione quasi-sufficiente scritta da qualcun altro ha spesso più successo nel mondo Linux che altrove.

E fu quello che accadde a me. Alla fine della mia seconda ricerca, mi ritrovai con nove candidati -- fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail e upop. Il primo a soddisfarmi fu `fetchpop', di Seung-Hong Oh. Gli appiccicai il mio codice di aggiustamento dell'intestazione, oltre ad altri miglioramenti che l'autore recepì nella release 1.9.

Poche settimane dopo, però, inciampai nel codice di `popclient', un programma di Carl Harris, e scoprii di avere un problema. Fetchpop aveva alcune buone idee originali (come la modalità daemon), ma gestiva solo POP3 ed aveva alcune aree di dilettantismo (Seung-Ho era un programmatore brillante, ma inesperto, ed entrambi i tratti sono evidenti dal suo codice). Il codice di Carl era migliore, professionale e solido, ma gli mancavano molte caratteristiche importanti e di complessa implementazione (incluse quelle che avevo aggiunto io).

Che fare? Passando a popclient, avrei perso il codice che avevo già scritto in cambio di una miglior base di sviluppo.

Un buon motivo per cambiare era costituito dal supporto di protocolli multipli. POP3 è il protocollo più usato in questo campo, ma non l'unico. Fetchpop e gli altri concorrenti non gestivano POP2, RPOP, o APOP, e io già stavo pensando di aggiungere IMAP http://www.imap.org (Internet Message Access Protocol, il più recente e potente protocollo post-office) per mio divertimento.

Avevo anche un'altra ragione per fare il cambio, una ragione teorica che avevo imparato prima di Linux:

3. Metti nei tuoi piani un vicolo cieco: ce ne sarà comunque uno.
(Fred Brooks, `Il Mitico Mese-Uomo', Capitolo 11)

In altre parole, spesso non si ha una buona comprensione del problema, fino a che non si è provato a risolverlo almeno una volta: la seconda volta forse si avrà una comprensione sufficiente per farlo correttamente.Perciò si dovrebbe essere sempre preparati a ripartire almeno una volta.

Così mi dissi, bene, cambiare fetchpop è stato il mio primo tentativo. E cambiai.

Quando mandai le prime patch di popclient a Carl Harris (25 Giugno 1996) scoprii che in pratica egli aveva già perso il suo interesse in popclient qualche tempo prima. Il codice era polveroso, con qualche baco qua e là. Avevo molti cambiamenti da fare, e non ci volle molto prima che decidessimo che la cosa più logica era che io diventassi il custode del programma.

Senza che me ne accorgessi, il progetto si era ingrandito: non stavo più parlando di fare alcune correzioni ad un client POP, ma ero diventato il responsabile di un client POP, e molte delle idee che avevo lo avrebbero probabilmente cambiato in maniera sostanziale.

In una cultura del software che incoraggia la condivisione, è abbastanza naturale che i progetti evolvano in questo modo. Questo ero il mio modo di praticare la seguente regola:

Ma l'atteggiamento di Carl Harris era ancora più importante, perché aveva perfettamente capito che:

5. Quando un programma non t'interessa più, hai il dovere di lasciarlo ad un erede competente.

Senza neanche bisogno di discutere, io e Carl sapevamo che il nostro obiettivo comune era raggiungere la miglior soluzione possibile. L'unica domanda a cui rispondere era se io fossi la persona adatta per raggiungerla, e, non appena dimostrai che lo ero, Carl mi passò il testimone con grazia e velocità. Spero di saper fare lo stesso quando toccherà a me.

3 L'importanza di avere utenti.

Così ereditai popclient, e - cosa altrettanto importante - i suoi utenti. Avere degli utenti è una cosa meravigliosa, non solo perché essi sono la dimostrazione che si sta soddisfacendo una necessità e che si sta facendo facendo qualcosa di utile, ma anche perché, trattati appropriatamente, possono diventare dei co-sviluppatori.

Una forza tradizionale di Unix, che Linux ha enfatizzato, è che molti utenti sono anche ``hacker'': e,poiché il codice sorgente è disponibile, essi sono effettivamente in condizione di vedere e trovare migliorie, e possono essere incredibilmente utili nell'abbreviare il tempo di ricerca e correzione degli errori (debugging). Con un po' di incoraggiamento, troveranno problemi, daranno suggerimenti e aiuteranno a correggere il codice più velocemente di quanto possa mai fare una persona da sola.

6. Trattare i tuoi utenti come sviluppatori è il modo meno difficile per avere un rapido perfezionamento ed un buon debugging.

È facile sottovalutare la potenzialità di questo fenomeno: e infatti, quasi tutti, nel mondo open source, ne abbiamo sottovaluto l'impatto al crescere del numero degli utenti e nonostante la crescita della complessità, almeno finché non è arrivato Linus Torvalds.

Penso che il trucco (hack) più ispirato e gravido di conseguenze di Linus non sia stata la creazione del kernel di Linux in sé, quanto piuttosto l'invenzione del modello di sviluppo di Linux. Quando ho espresso questa opinione in sua presenza, egli ha sorriso ed ha ripetuto con modestia qualcosa che spesso aveva già detto: -Fondamentalmente sono una persona pigra che preferisce prendersi il merito di cose fatte da altri.-. Pigro come una volpe o, come avrebbe detto Robert Heinlein: -Troppo pigro per fallire.-.

Un precursore del metodo e del successo di Linux fu lo sviluppo della ``GNU Emacs Lisp library'' e degli archivi di codice Emacs Lisp. In contrasto con lo ``stile cattedrale'' seguito nel corso dello sviluppo del nucleo di Emacs in C (e di molti altri programmi della FSF) l'evoluzione del codice Lisp delle librerie fu fluida e guidata in gran parte dagli utenti. Idee e prototipi erano spesso riscritti tre o quattro volte prima di giungere ad una forma stabile e definitiva e molto spesso si stabilivano, tramite Internet, collaborazioni ``a distanza'' come è la norma del mondo Linux.

In effetti, la mia opera più diffusa, prima di fetchmail, era probabilmente la modalità VC di Emacs , una collaborazione in stile Linux via email con altre tre persone, delle quali, fin ad oggi, ne ho conosciuto personalmente solo una (Richard Stallman, l'autore di Emacs e fondatore della FSF) ho poi conosciuto in questi giorni. Il modo VC mode è un'interfaccia per SCCS, RCS e CVS, che, permette di effettuare operazioni di controllo di versione e revisione dall'interno di Emacs. Il suo antenato era una piccola e primitiva modalità SCCS (sccs.el) scritta da qualcun altro, e il lo sviluppo di VC fu possibile perché, diversamente dallo stesso Emacs, il codice Lisp di Emacs poteva attraversare molto velocemente diversi cicli di release / test / correzione.

4 Rilascia presto, rilascia spesso

Il fare release precoci e frequenti è una parte cruciale del modello di sviluppo di Linux. La maggior parte degli sviluppatori, me compreso, di solito pensavano che questa fosse una cattiva idea per tutti i progetti non banali, perché le versioni premature sono sempre versioni bacate e bisogna evitare di esaurire la pazienza degli utenti.

Questa convinzione ha rinforzato il generale prevalere degli stili di sviluppo a Cattedrale. Dato l'obiettivo prevalente di far vedere agli utenti meno bachi possibili e lavorare come pazzi per fare le correzioni tra una release e l'altra, le nuove versioni venivano rilasciate come minimo ogni sei mesi (o anche più raramente). Il nucleo C di Emacs fu sviluppato in questo modo, mentre la libreria Lisp non lo fu, perché c'erano archivi Lisp attivi fuori dal controllo della FSF, dove si potevano trovare delle novità e delle versioni di codice sviluppate indipendentemente dal ciclo di release ufficiale di Emacs.

Il più importante tra questi archivi, l' Ohio State Elisp Archive, anticipava nello spirito e in parecchie caratteristiche i grandi archivi Linux di oggi. Ma pochi di noi si stavano realmente rendendo conto di ciò che stavano facendo o del significato che l'esistenza di un archivio del genere aveva per il modello di sviluppo a Cattedrale adottato dalla FSF. Quando, Attorno al 1992, feci un serio tentativo di integrare formalmente molto del codice dell'Ohio Archive nell'Official Emacs Lisp Library, mi trovai di fronte a problemi "politici" e la conseguenza fu un notevole insuccesso.

Ma un anno dopo, quando Linux cominciò a farsi conoscere, fu chiaro che stavamo assistendo alla crescita di qualcosa di diverso e molto vigoroso: la politica di sviluppo aperto di Torvalds era il vero antagonista del modello a Cattedrale. Gli archivi Sunsite e TSX-11 stavano esplodendo,erano state diffuse diverse distribuzioni e tutto questo era guidato da una frequenza mai vista nel rilascio di nuove versioni del sistema base.

Linus stava trattando i suoi utenti e co-sviluppatori nel modo più efficace possibile:

La scoperta di Torvalds non stava tanto nel concetto, che, in una forma simile, era già da parecchio tempo nella tradizione di Unix, quanto, piuttosto, nell'adeguarne l'intensità al livello di complessità di ciò che si stava sviluppando. Nei primi tempi (attorno al 1991) non era una insolito, per lui, rilasciare una nuova versione del kernel più di una volta al giorno! Supportando la sua base di co-sviluppatori e usando Internet - più di quanto chiunque altro avesse mai fatto - per avere collaborazioni, riusciva a fare sì che questo approccio avesse successo.

Ma come funzionava, in realtà, ed era qualcosa che si poteva ripetere, o si trattava di un ``unicum', dipendente dalla particolare genialità di Linus Torvalds?

Io pensavo di no. Ovviamente Torvalds è un hacker fantastico (dopotutto, quanti di noi sarebbero capaci di concepire l'intera creazione del kernel di un sistema operativo di qualità commerciale?) ma, di per sé e dal punto di vista dei concetti, Linux non rappresentava un imponente balzo in avanti. Linus non è, o almeno non ancora, un genio innovativo della progettazione come lo sono Richard Stallman o James Gosling (di NeWS e Java): piuttosto Linus mi sembra essere un genio dell' ingegneria del software, con un sesto senso nell'evitare bachi e vicoli ciechi nello sviluppo e una vera arte per trovare con il minimo sforzo la strada più semplice. Infatti l'intero progetto Linux trasuda queste qualità e rispecchia l'approccio concettuale essenzialmente conservatore e minimalista del suo creatore.

E allora, se un rapido ciclo di release e l'uso di Internet non sono fattori casuali, ma parti fondamentali del disegno concettuale di Linus, riassunte nella filosofia del minimo sforzo, qual era il ``prodotto'' che questo metodo massimizzava? Cosa usciva dagli ingranaggi?

In questa forma, la domanda si risponde da sola. Linus stimolava - e premiava - continuamente i suoi utenti hacker: li stimolava con la prospettiva di essere protagonisti di una parte dello sviluppo, e li premiava con la quantificazione rapida, addirittura giornaliera, dei miglioramenti indotti al loro lavoro.

Linus stava esplicitamente incitando a massimizzare il numero di ore/uomo impiegate nel debuggare e sviluppare, anche al possibile rischio di introdurre instabilità nel codice e di esasperare la base di utenza nel caso in cui grave baco si fosse rivelato intrattabile. Penso che Linus stava agendo nella consapevolezza di un principio del genere:

8. Se hai una quantità sufficiente di sperimentatori beta e di sviluppatori, quasi tutti i problemi saranno individuati velocemente e la soluzione sarà evidente almeno per qualcuno

O, in parole povere, quella che io chiamo la legge di Linus: ``Molte pupille rendono tutti i bachi facili da trovare''

La versione iniziale diceva che ``la soluzione di ogni problema diverrà ovvia per qualcuno'', ma Linus obbiettò che colui che capisce a e risolve il problema non è quasi mai la stessa persona che lo ha trovato e individuato. "Qualcuno trova il problema", diceva, "e qualcun altro lo capisce. E voglio sottolineare che, secondo me, la cosa più difficile è il trovare." La cosa importante, comunque, è che entrambe le cose tendono ad accadere velocemente.

Io penso che questa sia la differenza fondamentale tra gli stili ``a Cattedrale'' e ``a Bazaar'': per il costruttore di Cattedrali, bachi e problemi di sviluppo sono fenomeni insidiosi, impegnativi e profondi che richiedono mesi di minuziosi esami di gruppo, finché non si sia raggiunta la certezza che essi siano stati tutti eliminati. Da qui i lunghi intervalli tra le release e le inevitabili delusioni che derivano dallo scoprire che le tanto agognate release non sono perfette.

Il punto di vista del Bazaar, invece, è che i bachi sono generalmente fenomeni superficiali o almeno, che divengono superficiali, docili e rapidi da trattare, quando esposti a migliaia di ansiosi co-sviluppatori che si accaniscono su ogni nuova release. Perciò si rilascia spesso per ricevere più correzioni e, come benefico effetto collaterale non si ha molto da perdere quando scappa l'occasionale ``cappella''.

Tutto qui, non c'è altro. Se la legge di Linus è falsa, ogni sistema complesso quanto il kernel di Linux dovrebbe ad un certo punto collassare sotto il peso di fenomeni imprevisti e sconosciuti o di gravi bachi, ma se, invece, la legge di Linus è vera, allora è sufficiente spiegare l'assenza di bachi gravi in Linux.

E forse non ci si dovrebbe sorprendere più di tanto. Già da alcuni anni i sociologi avevano osservato che l'opinione media di un campione di esperti (o di persone di equivalente ignoranza) costituisce una predizione molto più accurata che non l'opinione di un esperto scelto a caso (il cosiddetto ``effetto Delfi''). Si direbbe che Linus abbia dimostrato che questo effetto si applica bene al debuggare un sistema operativo; l'effetto Delfi riesce a domare la complessità dello sviluppo persino al livelli di complessità di un kernel per sistema operativo.

Sono debitore a Jeff Dutky per aver indicato che la legge di Linus può essere riformulata come "il debugging è parallelizzabile". Jeff osserva che, sebbene il debuggare richieda ai debuggatori di comunicare con alcuni sviluppatori coordinati, esso non richiede però significanti costi di coordinamento e manageriali, che in genere costituiscono problematiche aggiuntive per gli sviluppatori.

In pratica, la perdita - teorica - di efficienza dovuta dalla duplicazione del lavoro dei debugger non sembra essere un problema nel mondo Linux: un effetto della politica delle release precoci e frequenti è quello di minimizzare simili duplicazioni propagando rapidamente le informazioni sulle correzioni già effettuate.

Brooks (l'autore di ``The Mythical Man-Month'' ) ha fatto un'osservazione che è apparentata a quella di Jeff: "Il costo totale di manutenzione per un programma ampiamente usato è tipicamente il 40% o più dei costi di sviluppo. Sorprendentemente questo costo è fortemente influenzato dal numero degli utenti. Più utenti trovano più bachi.'' (enfasi aggiunta).

Più utenti trovano più bachi perché aggiungendo utenti si aggiungono modi diversi di sollecitare il programma. Questo effetto è amplificato quando gli utenti sono co-sviluppatori. Ognuno affronta la descrizione di un baco con una propria impostazione e un set di strumenti personale, il che gli permette di avere una differente visuale del problema. L'effetto Delfi dipende da queste piccole variazioni: nello specifico contesto del debugging la variazione tende anche a ridurre la duplicazione dello sforzo.

Così, anche se aggiungendo beta tester potremmo non ridurre la complessità di quello che gli sviluppatori sia il più grave baco del momento, incrementiamo la probabilità che gli strumenti di qualcuno si scontrino con il problema, e che il baco sarà individuato da qualcuno che sappia vederne la banalità.

Anche Linus, comunque, cerca di proteggersi dai capricci del caso, e per evitare le conseguenze avverse di bachi gravi, le versioni del kernel di Linux sono numerate in modo che i potenziali utenti possano scegliere tra il far girare l'ultima versione (definita "stabile") o correre sul filo del rasoio e rischiare di incorrere nei bachi pur di disporre di nuove caratteristiche. Questa tattica non è ancora formalmente imitata dalla maggior parte degli sviluppatori di Linux, ma forse dovrebbe; il fatto di poter scegliere rende tutto il processo molto più attraente.

5 Quando una rosa non è (più) una rosa?

Dopo aver studiato il comportamento di Linus, e dotato di una personale teoria che ne spiegava il successo, decisi di mettere la mia teoria alla prova sul mio nuovo progetto - per quanto più semplice e meno ambizioso.

Il mio primo passo fu quello di riorganizzare semplificare di molto popclient. L'implementazione di Carl Harris era solida, ma esibiva quel sovrappiù di complessità che è comune a molti programmatori C, che trattano il codice come la parte centrale e le strutture dati come un strumento di supporto, e di conseguenza, il codice era bello, ma il progetto ad hoc dell strutture dati era decisamente brutto (almeno agli occhi di questo vecchio Lisp hacker).

Oltre al miglioramento del codice e delle strutture dati, il lavoro di riscrittura aveva l'obiettivo di far evolvere il programma in qualcosa di cui avessi una completa comprensione. Essere responsabili della manutenzione di un programma che non si capisce è una brutta esperienza.

Per il primo mese o giù di lì, mi limitai a seguire le implicazioni del progetto di Carl. Il primo serio cambiamento che feci fu di aggiungere il supporto IMAP, e lo feci riorganizzando i protocolli in un driver generico e tre tabelle di metodi: una per POP2, una per POP3 ed una per IMAP. Questo cambiamento, ed altri che lo precedettero illustrano un principio generale che è bene i programmatori tengano a mente, specialmente nei linguaggi come il C che non fanno uso del dynamic typing:

Brooks, capitolo 9: "Mostrami il tuo codice, nascondi le tue strutture dati e continuerò ad essere confuso. Mostrami le tue strutture dati e normalmente non avrò bisogno del tuo codice: sarà ovvio."

In effetti nella citazione originale si parlava di ``diagrammi di flusso'' e ``tabelle'', ma, considerato che sono passati trent'anni, il concetto è quasi lo stesso.

A questo punto (primi di settembre 1996, circa sei settimane dopo il giorno 0) cominciai a pensare che un cambiamento di nome poteva essere accettabile, dopo tutto il programma non era già più Popclient. Tuttavia esitavo, perché finora non avevo inserito niente di veramente nuovo nel progetto: la mia versione di Popclient doveva ancora sviluppare una sua identità.

Questo cambiò radicalmente quando Fetchmail imparò come rispedire la posta presa alla porta SMTP, e a questo arriverò tra un momento ma prima vorrei chiarire un altro punto. Poco fa, ho detto che cominciai ad utilizzare questo progetto per sperimentare la mia teoria su ciò che Linus Torvalds aveva fatto di giusto, e i miei lettori potrebbero chiedermi in che modo lo feci.

1. Emettevo release presto e spesso (mai meno di una ogni dieci giorni e durante i periodi di sviluppo intenso anche una volta al giorno).

2. Aumentavo la mia beta list aggiungendovi tutti quelli che mi contattavano a proposito di Fetchmail.

3. Inviavo annunci amichevoli alla beta list quando rilasciavo, incoraggiando la gente a partecipare.

4. Ascoltavo i miei beta tester, li consultavo sulle decisioni del progetto e li ringraziavo quando inviavano patch o riscontri vari.

Il vantaggio che trassi da questi semplici accorgimenti fu immediato: fin dal principio del progetto ottenevo dei rapporti sui bachi di una qualità che da fare invidia a molti sviluppatori, spesso con buone correzioni allegate. Ricevevo critiche intelligenti, incoraggiamenti, buoni suggerimenti su migliorie da aggiungere, e tutto questo mi portò a formulare il seguente principio:

10. Se tratti i tuoi beta tester come la tua migliore risorsa, risponderanno diventando la tua migliore risorsa.

Una importante misura del successo di Fetchmail è la dimensione del progetto beta list, gli amici di Fetchmail, che, nel momento in cui scrivo, conta 249 membri e se ne stanno aggiungendo 2 o 3 alla settimana.

In effetti, secondo quanto ho riscontrato alla fine del Maggio 1997, la lista sta cominciando a perdere iscritti, dall'alto del suo apice di 300, e per una ragione interessante: diverse persone mi hanno chiesto di cancellare la loro iscrizione perché Fetchmail sta lavorando nel modo a loro necessario e non hanno più bisogno di vedere il traffico della lista. Forse questa è una fase del normale ciclo di vita di un progetto maturo nello stile Bazaar.

6 Popclient diventa Fetchmail

Il punto di svolta del progetto si verificò quando Harry Hochheiser mi mandò una bozza di codice per inoltrare posta alla porta SMTP della macchina client: immediatamente capii che un'implementazione affidabile di questa funzione avrebbe reso tutti gli altri metodi di consegna.

Per diverse settimane avevo lavorato su fetchmail in maniera incrementale, con la sensazione che il progetto dell'interfaccia fosse efficiente, ma scomodo: inelegante e con troppe opzioni che ``sporgevano'' da tutte le parti. L'opzione che permetteva di scaricare la posta direttamente in una casella o sullo standard output mi infastidiva particolarmente senza che riuscissi a spiegarlo razionalmente.

Quando iniziai a pensare all' inoltro a SMTP mi accorsi che popclient tentava di fare troppe cose: era stato progettato per essere sia un agente di trasporto (MTA) sia un agente di consegna (MDA): inserendo l'inoltro SMTP, si poteva sbarazzare della parte MDA e concentrarsi sulla parte MTA, lasciando la consegna ai programmi di consegna locale come fa sendmail.

Perché preoccuparsi delle complicazioni insite nel configurare un agente di consegna locale, o di effettuare il lock-and-append di una casella quando la porta 25 è standard su quasi tutte le piattaforme TCP/IP? E soprattutto in questo caso, quando la posta che viene inoltrata avrà tutto l'aspetto di un normale messaggio SMTP, essenzialmente quello di cui abbiamo bisogno.

Si possono imparare diverse lezioni da questo episodio: innanzitutto, l'inoltro via SMTP fu il guadagno maggiore che ottenni dal mio tentativo di imitazione del metodo di Linus - un utente mi passò un'ottima idea, e io mi limitai a comprenderne le conseguenze.

11. La cosa migliore, oltre ad avere buone idee, è saper riconoscere le buone idee dei propri utenti. A volte è meglio la seconda della prima.

È abbastanza interessante osservare che, se si è completamente e umilmente sinceri riguardo ai contributi degli altri, tutti vi tratteranno come se, in realtà, tutta l'invenzione sia un parto della vostra mente e che vi stiate comportando con educata modestia. Come sappiamo, per Linus ha funzionato proprio in questo modo.

(Quando lessi questo articolo alla Perl Conference - Agosto 1997 - Larry Wall era seduto in prima fila. Mentre leggevo il paragrafo precedente, egli si mise a declamare, nello stile dei revival religiosi ``Diglielo, diglielo fratello!'', mentre il pubblico, che sapeva quanto la ricetta avesse funzionato anche per l'autore di Perl, scoppiava a ridere)

Dopo alcune settimane che lavoravo sul progetto nello stesso spirito, cominciai a ricevere lodi di questo tipo non solo dai miei utenti, ma anche da persone a cui era arrivata la voce e di cui ho conservato i messaggi. Forse me li andrò a guardare quando comincerò a chiedermi se la mia vita sia valsa a qualcosa :-).

Ci sono altre due lezioni di tipo più tecnico e che si applicano a tutti i tipi di progetto:

12. Spesso le soluzioni più innovative e radicali derivano dalla comprensione che la propria rappresentazione del problema era sbagliata.

Avevo cercato di risolvere il problema sbagliato, e avevo continuato a sviluppare popclient sotto forma di un agente misto MDA/MTA, preoccupandomi dei più bizzarri congegni di consegna locale, quando invece il progetto di fetchmail andava ripensato sotto forma di un MTA puro, come parte del normale processo della consegna SMTP della posta Internet.

Quando ci si trova in un vicolo cieco ed è difficile pensare a cosa succederà dopo la prossima patch, spesso significa che è il momento di pensare se si è fatta la domanda giusta, piuttosto che non se si ha la risposta: forse bisogna riesaminare il problema.

E il mio problema era stato riesaminato: chiaramente le cose da fare erano 1) inserire l'inoltro SMTP nel driver generico e 2) renderlo il modo standard per 3) disfarsi, ad un certo punto, di tutti gli altri meccanismi di consegna locale, specialmente quello su file e quello su standard output.

Esitai per un bel po' prima di intraprendere il terzo passo, per paura di alienarmi gli utenti di popclient che si erano affidati agli altri meccanismi di consegna: in teoria, questi avrebbero potuto utilizzare i file .forward dei loro agenti non-sendmail ed ottenere gli stessi risultati, ma in pratica la transizione sarebbe stata complicata.

Quando però mi decisi, i benefici furono immensi: le parti più disordinate nel codice del driver sparirono, la configurazione si semplificò immensamente - non era più necessario rovistare nel sistema alla ricerca degli agenti di consegna e della posizione delle caselle, o preoccuparsi se il sistema operativo supportasse il file locking.

In più, era sparito l'unico meccanismo tramite il quale era possibile perdere la posta: prima se si cercava di consegnare ad un file quando il disco era pieno, la posta era perduta, cosa che non può succedere con l'inoltro SMTP, perché l'agente SMTP non darà l'OK per la consegna a meno ce la posta non possa essere consegnata o, perlomeno, accodata per essere consegnata più tardi.In più le prestazioni migliorarono (anche se troppo poco per essere immediatamente evidente) e, particolare non trascurabile, il manuale si semplificò di molto.

In seguito, fui costretto a reinserire la consegna tramite un MDA specificato dall'utente per risolvere alcune oscure situazioni in presenza di SLIP dinamico, ma trovai una maniera assai più semplice per farlo.

La morale è che non bisogna mai esitare a sbarazzarsi di capacità obsolete quando ci si può permettere di farlo senza perdita di efficacia. Come disse Antoine de Saint-Exupery (che fu un aviatore e un progettista d'aerei quando non scriveva classici per ragazzi):

13. La perfezione (nella progettazione) si ottiene non quando non c'è più nulla da aggiungere, ma quando non c'è più nulla da togliere.

Quando il codice diventa più bello e più semplice si può essere confidenti che è anche giusto. Nel corso di questo processo, fetchmail acquisto un'identità distinta, diversa da quella del suo antenato popclient.

Era venuto il momento di cambiargli nome. Il nuovo progetto era molto più simile a quello di sendmail di quello del vecchio popclient: entrambi MTA, ma mentre sendmail prima manda (send), poi consegna, questo prima recupera (fetch), poi consegna. E fu così che, a due mesi dall'inizio, lo chiamai fetchmail.

7 Fetchmail cresce

E così mi trovavo con un progetto innovativo, che sapevo funzionare a dovere perché lo usavo tutti i giorni, e una lista beta in continua espansione, e cominciai a capire di non essere più impegnato in un banale trucco personale che era anche utile a qualcun'altro. Stavo in effetti lavorando ad un programma necessario per chiunque avesse un sistema Unix e una connessione SLIP o PPP.

Con l'aggiunta dell' invio SMTP, si era posizionato abbastanza avanti come concorrente per diventare un "category killer", uno di quei classici programmi che soddisfano la loro nicchia così bene che le alternative non vengono quasi considerate.

Non penso che un risultato del genere possa essere progettato in anticipo: ci si viene attirati da idee progettuali così potenti che, a cose fatte, il risultato sembra inevitabile, preordinato. L'unico modi per ottenere idee di questo tipo è partire da un sacco di idee, oppure avere il discernimento ingegneristico di saper prendere idee di altri e portarle al di là di ciò che le aveva pensate immaginasse potessero andare.

Andrew Tanenbaum ebbe l'idea di creare una semplice variante di Unix per il 386, da usare a fini didattici. Linus Torvalds spinse questa idea ben oltre il punto in cui lo stesso Tanenbaum - probabilmente - pensava potesse andare, e questa crebbe fino a diventare qualcosa di meraviglioso. Allo stesso modo, ma in tono minore, io avevo preso le idee di Carl Harris e Harry Hochheiser e avevo aggiunto il mio olio di gomito. Nessuno di noi era `originale' nell'accezione romantica che di solito si associa al genio, ma in fondo gran parte della scienza e dell'ingegneria non sono opera di genialità, checché ne dica la mitologia hacker.

Ciononostante, i risultati furono comunque impressionanti, e qualunque hacker ne sarebbe stato più che soddisfatto. Questo significava che avrei dovuto aderire a standard ancora più stringenti: per dare a fetchmail la qualità che sapevo poteva raggiungere, avrei dovuto scrivere non solo per soddisfare i miei bisogni, ma anche per includere funzionalità necessarie ad altri e, nel farlo, cercare di mantenere il programma semplice ed affidabile.

La prima funzionalità - e di gran lunga la più importante - che aggiunsi dopo che ebbi capito tutto ciò fu il supporto per il multidrop, cioè la possibilità di prelevare posta da caselle che avevano accumulato messaggi per un gruppo di utenti e consegnare ogni messaggio individualmente.

La decisione di aggiungere il multidrop fu provocata, in parte, dal fatto che alcuni utenti ne avevano bisogno, ma soprattutto perché pensavo che mi avrebbe aiutato ad eliminare i bachi dalla parte che gestiva il funzionamento consueto, costringendomi ad affrontare il problema dell' indirizzamento in generale - e così fu. Riuscire ad ottenere una versione corretta di un interprete RFC822 richiese un bel po' di tempo, non perché ogni singola parte sia complessa, ma perché entravano in gioco svariati dettagli delicati e interdipendenti.

Inoltre il multidrop si dimostrò un'eccellente decisione progettuale, secondo i dettami di un altro principio:

14. Ogni strumento dovrebbe svolgere bene il compito per cui è stato creato, ma un ottimo strumento si presta ad essere usato in maniere completamente inaspettate.

In questo caso, l'uso inaspettato era la possibilità di mantenere mailing-list dal lato client, facendo anche l'espansione degli alias dalla parte del client, e questo permetteva a persone collegate a un provider tramite SLIP o PPP di centralizzarne la gestione su di una macchina personale piuttosto che su quella del provider.

Un altro importante cambiamento richiesto dai miei utenti fu il supporto per le operazione MIME a 8 bit, ma questo fu facile da implementare: ero infatti stato attento a rendere tutto il mio codice compatibile con operazione a 8 bit, e questo non perché avessi previsto questa funzionalità, ma in osservanza di un altro principio guida:

15. Nello scrivere un qualsiasi tipo di programma di trasferimento dati bisogna impegnarsi per non perturbare il flusso dei dati, e, soprattutto, non bisogna mai perdere informazione, a meno che non sia il destinatario a rifiutarla.

Se non avessi osservato questa regola, introdurre MIME a 8 bit sarebbe stato difficile, e il risultato pieno di errori. Nella mia situazione, invece, mi bastò leggere RFC 1652 RFC 1652 e aggiungere qualche banale manipolazione dell'intestazione.

Alcuni utenti Europei continuavano a chiedermi di poter limitare il numero dei messaggi recuperati per sessione (e così permettergli di controllare i costi telefonici), cosa a cui mi opposi per lungo tempo, e della quale non sono ancora completamente soddisfatto. Ma chi scrive per il mondo deve ascoltare i propri clienti, anche se non pagano in moneta sonante.

8 Altre lezioni imparate da fetchmail

Prima di tornare a questioni generali di software engineering, voglio considerare un paio di lezioni più specifiche imparate dall'esperienza di Fetchmail. La sintassi del file .rc include parole non necessarie, che l'interprete ignora completamente. La sintassi, simile alla lingua Inglese, che esse permettono di usare è considerevolmente più leggibile delle classiche e scarne coppie di opzione/valore che rimangono quando esse vengono eliminate.

Tutto cominciò come un esperimento a tarda notte quando osservai che le espressioni del file .rc stavano cominciando a rassomigliare ad un mini-linguaggio di comandi (questo fu il motivo per cui cambiai la direttiva originale di Popclient da "server" a "poll").

Pensai che il tentativo di rendere questo mini-linguaggio di comandi più simile all'inglese poteva renderne l'uso più semplice. Però, sebbene io sia un convinto sostenitore della scuola del "fanne un linguaggio" esemplificata da Emacs, HTML e molti motori di database, normalmente non sono un grande fan delle sintassi English-like.

Tradizionalmente i programmatori preferiscono le sintassi di controllo che sono molto precise, compatte e non hanno ridondanze. Questo è un patrimonio culturale derivato dal tempo in cui le risorse tecnologiche erano costose, e quindi la fase di analisi doveva essere il più possibile economica e semplice. L'Inglese, una lingua con circa il 50% di ridondanza, non sembrava comunque essere il modello più appropriato.

Non è però questo il motivo che normalmente mi fa evitare la sintassi di tipo Inglese - infatti, lo cito solo per confutarlo. In un periodo in cui memoria a cicli di macchina sono così economici, infatti la concisione non dovrebbe più essere fine a se stessa, perché è più importante che un linguaggio sia comodo per gli esseri umani che non economico per il calcolatore.

Ci sono altri motivi per stare attenti, comunque, a cominciare dal costo derivante dalla complessità della fase di traduzione, che non dovrebbe diventare tale da essere una sorgente di bachi e da confondere l'utente. Un altro possibile problema è che le sintassi di tipo Inglese spesso richiedono un ``Inglese'' così deformato da far sì che la sua superficiale somiglianza col linguaggio naturale divenga, essa stessa, un motivo di confusione pari a quella che sarebbe stata provocata da una sintassi più tradizionale. (È quello che si vede nei cosiddetti linguaggi ``di quarta generazione'' e nei linguaggi d'interrogazione per database).

La sintassi di controllo di fetchmail cerca di evitare questi problemi restringendo al massimo il dominio linguistico ed evitando di diventare un linguaggio di uso generale: si limita a dire in maniera semplice cose che non sono molto complesse, e questo riduce la potenziale confusione che deriva dal doversi muovere mentalmente tra un piccolo sottoinsieme della lingua Inglese e il linguaggio di controllo vero e proprio. La lezione che possiamo imparare da questo è:

16. Quando il linguaggio da sviluppare è ben lontano da essere completo secondo Turing, lo ``zucchero sintattico'' è un vostro alleato.

Un'altra lezione riguarda la riservatezza ottenuta tramite la segretezza. Alcuni utenti mi avevano chiesto di rendere possibile l'uso di password cifrate nel file di configurazione, in modo da proibire ai curiosi di vederle. Io decisi di non farlo, perché questa aggiunta non avrebbe di fatto accresciuto la sicurezza: infatti, chiunque possa leggere il file rc è anche in grado di eseguire fetchmail con l'identità del proprietario, e, se è interessato alla sua password, probabilmente sarà in grado di estrarre gli algoritmi di decodifica direttamente dal codice di fetchmail per ottenerla.

L'unico risultato ottenuto consentendo password cifrate in .fetchmailrc sarebbe stato dare un falso senso di sicurezza a persone irriflessive. La lezione che se ne può trarre è:

17. Un sistema di sicurezza è sicuro quanto il suo segreto: diffidate degli pseudo-segreti.

9 Condizioni necessarie allo stile bazaar

I primi recensori di questi articoli posero molte domande sulle condizioni che devono preesistere ad un modello bazaar di successo, sulle qualità necessarie al capo del progetto e la condizione in cui si trova il codice nel momento in cui ci si presenta al pubblico per creare una cooperativa di sviluppatori.

Sembra chiaro che lo stile bazaar non si presta a scrivere un programma da zero: si possono condurre test, debugging e introdurre miglioramenti grazie allo stile bazaar, ma iniziare un progetto in questo stile sarebbe molto difficile. Infatti Linus non ci si provò e nemmeno io. Bisogna dare alla comunità un programma che funziona e possa essere provato con cui sperimentare.

Quando si cerca di costruire una comunità bisogna essere in grado di presentare una promessa plausibile. Non è necessario che il programma funzioni particolarmente bene; può essere rudimentale, ``bacato'', incompleto e poco documentato. Ciò su cui il non può permettersi di sbagliare è nel convincere potenziali co-sviluppatori che ha la possibilità di evolvere in qualcosa di valido in tempi accettabili.

Linux e Fetchmail si presentarono al pubblico entrambi con un progetto di base forte ed attraente. Sono in molti a pensare - correttamente - che il modello bazaar, come l'ho presentato, dipenda in maniera essenziale da questo aspetto: subito dopo, però, saltano alla conclusione che un alto livello di intuizione progettuale ed intelligenza del capoprogetto sia altrettanto indispensabile.

Eppure, Linus prese il suo progetto da Unix, e io ereditai il mio dal vecchio popclient (anche se in questo caso i cambiamenti furono assai più radicali di quanto non avvenne con Linux). Così nasce la domanda: il leader-coordinatore di un'impresa a stile bazaar deve avere veramente un eccezionale talento progettuale o può far leva sul talento progettuale di altri?

Io non penso sia cruciale che il capoprogetto sia in grado di creare da solo progetti di spiccata originalità, ma che sia assolutamente indispensabile che il capoprogetto sia in grado di riconoscere le buone idee progettuali degli altri.

Entrambi i progetti di Linux e Fetchmail ne sono una prova. Linus, che non è un progettista incredibilmente originale (come già discusso in precedenza), ha però mostrato una particolare abilità nel riconoscere i buoni progetti ed integrarli nel kernel di Linux. Per quanto mi riguarda, ho già descritto come la migliore funzionalità introdotta in Fetchmail, cioè il forwarding SMTP, sia dovuto a qualcun altro.

I lettori delle prime versioni di questo documento mi hanno spesso detto - adulandomi - che sono propenso a sottovalutare l'apporto dell'originalità progettuale nei progetti a bazaar perché ne posseggo molta, e quindi tendo a darla per scontata. Questo può essere vero, e infatti la progettazione, al contrario della programmazione e del debugging, è senza dubbio la cosa in cui riesco meglio.

L'altra faccia dell'essere intelligente ed originale nel progettare software è che tende a diventare un'abitudine. Si comincia così a pensare cose ingegnose e complicate quando si dovrebbe invece cercare di mantenerle robuste e semplici. Proprio a causa di questo errore ho fallito in alcuni progetti, mentre Fetchmail fu un successo.

Credo che la riuscita del progetto Fetchmail sia dovuta in parte proprio all'essere riuscito a frenare la mia tendenza ad essere troppo acuto e questo dovrebbe sostenere l'ipotesi che l'originalità progettuale non sia essenziale per ottenere il successo con progetti a bazaar. Supponiamo che Linus Torvalds si fosse messo a cercare di realizzare innovazioni fondamentali nell'architettura dei sistemi operativi durante lo sviluppo di Linux: vi sembra possibile che il kernel risultante avrebbe finito con l'avere le caratteristiche di stabilità e popolarità che ha acquisito?

Naturalmente è richiesto un certo livello base di professionalità nella progettazione e programmazione, ma mi aspetto che tutti quelli seriamente intenzionati a lanciarsi in un'impresa a stile bazaar siano già in grado di andare oltre questi requisiti di base. Il mercato interno - un mercato dove si scambiano reputazione e credibilità - della comunità open source esercita una sottile pressione sulla gente che inibisce l'avvio di imprese di sviluppo a coloro che non sono abbastanza competenti per seguirle. Sino ad ora sembra aver funzionato tutto alla perfezione.

C'è un altro tipo di professionalità normalmente non associata con lo sviluppo del software che penso sia importante quanto le famose idee intelligentissime; forse addirittura più importante. Sto parlando della figura del leader-coordinatore che deve avere buone capacità comunicative e di gruppo.

Questo dovrebbe essere ovvio. Chi ha l'intenzione di realizzare una comunità di sviluppo, deve saper attrarre le persone, interessarle a ciò che sta facendo e mantenerle soddisfatte del lavoro che affrontano. Ci saranno problemi collegati a questioni tecniche, ma questo non è il luogo per parlarne. Anche la personalità ce si mette in luce ha importanza.

Non è una coincidenza che Linus sia un ragazzo simpatico che induce le persone ad imitarlo ed aiutarlo. Non è una coincidenza che io sia un energico estroverso che ama lavorare in compagnia ed talvolta si si esprime come un comico di professione. Per far sì che il progetto bazaar funzioni, avere un minimo di fascino personale è utilissimo.

10 Il contesto sociale del software Open Source

E' stato giustamente scritto: le migliori modifiche nascono come soluzioni dei problemi personali e quotidiani dell'autore e si diffondono perché il problema è condiviso da un'ampia classe di utenti. Questo ci rimanda alla lezione della regola 1, riformulata in maniera più adatta:

18. Per risolvere un problema interessante, comincia cercando un problema che sia interessante per te.

Così è stato con Carl Harris e l'originario Popclient e così con me e Fetchmail, ma si tratta di qualcosa che è scontato da tempo. Un aspetto interessante messo a fuoco dalle storie di Linux e Fetchmail è la fase successiva: l'evoluzione del software in presenza di una larga e attiva comunità di utenti e co-sviluppatori.

Nel libro "The Mythical Man-Month" Fred Brooks osserva che il tempo del programmatore non è flessibile, cioè che aggiungere sviluppatori ad un progetto software in ritardo lo fa ritardare ulteriormente, e sostiene che la complessità ed i costi di comunicazione di un progetto crescono col quadrato del numero degli sviluppatori, mentre il lavoro fatto da soli cresce linearmente. Questa affermazione si è poi diffusa come "la legge di Brooks" ed è ampiamente considerata come una verità auto-evidente. Ma se la legge di Brooks fosse l'unico fattore in gioco,allora il fenomeno Linux sarebbe impossibile. Il testo classico "La psicologia della programmazione dei computer" di Gerald Weinberg può essere letta a posteriori come una sostanziale correzione alla tesi di Brooks. Nella sua discussione sulla "programmazione altruistica", Weinberg ha osservato che in attività dove gli sviluppatori non sono possessivi verso il loro codice ed incoraggiano altre persone a cercare bachi e potenziali correzioni, le migliorie si susseguono assai più veloci che in altri progetti.

La terminologia usata da Weinberg ha probabilmente impedito che la sua analisi ricevesse l'attenzione che meritava; l'idea di descrivere gli hacker come "altruistici" faceva sorridere, ma penso che oggi la sua argomentazione sia più comprensibile che ai suoi tempi.

La storia di Unix dovrebbe averci preparato per ciò che stiamo imparando da Linux (e che ho verificato in scala ridotta dalla mia deliberata replica dei metodi di Linus), cioè che, mentre scrivere codice rimane un'attività essenzialmente solitaria, il vero grande salto sta nell'utilizzare l'interesse e le capacità intellettuali di intere comunità. Lo sviluppatore che impiega le proprie capacità in un progetto chiuso, soccomberà allo sviluppatore che sa come creare o aprire contesti evolutivi per individuare bachi e correzioni con l'aiuto di centinaia di persone.

Il tradizionale mondo Unix fu ostacolato, nello spingere questo approccio ai suoi estremi, da diversi fattori, tra i quali i vari contratti di licenza, i segreti industriali e gli interessi commerciali collegati. Un altro importante fattore (come sappiamo a posteriori) era che internet non era ancora sufficientemente sviluppata da fornire il supporto necessario.

Prima dell'internet a basso costo, c'erano alcune comunità geograficamente localizzate dove la cultura dominante incoraggiava la programmazione "altruistica" di Weinberg ed un programmatore poteva facilmente disporre di parecchi co-sviluppatori qualificati e persone con cui discutere. Fu così che i Bell Labs, il MIT AI Lab, UC Berkeley, divennero fucine di innovazioni che sono tuttora leggendarie e potenti.

Linux fu il primo progetto a fare un tentativo, consapevole e di successo, di utilizzare il mondo intero come una miniera di talenti. Non penso sia una coincidenza che il periodo di gestazione di Linux coincida con la nascita del Web e che Linux sia uscito dalla sua infanzia nello stesso periodo (del 1993-94) che vide il decollo dell'industria ISP e l'esplosione di interessi primari in internet. Linus è stato il primo che ha saputo utilizzare le nuove regole che il dilagare di internet rendeva possibili.

Mentre l'internet a basso costo era una condizione necessaria per l'evoluzione del modello Linux, penso che non sia stata, da sola, una condizione sufficiente. Un altro fattore vitale è stato lo sviluppo di uno stile di leadership adeguato ed il configurarsi di concezioni cooperative che permettevano ai programmatori di attrarre co-sviluppatori ed ottenere il massimo risultato consentito dal mezzo utilizzato.

Ma cos'è questo stile di Leadership e cosa sono queste concezioni? Non è possibile basarle su rapporti di potere ed anche se si potesse, una Leadership autoritaria non potrebbe dare il risultato che vediamo. Weinberg cita, dall'autobiografia dell'anarchico russo del XIX secolo Pyotr Alexeyvich Kropotkin, intitolata "Memorie di un rivoluzionario", parole appropriate a questo contesto:

"- Essendo cresciuto in una famiglia proprietaria di schiavi, entrai nella società attiva come tutti i giovani maschi del mio tempo, cioè con molta confidenza nella necessità dell'uso del dominio, sotto forma di disposizioni, rimproveri, punizioni eccetera. Ma quando ben presto mi trovai a gestire imprese serie, e farlo con uomini liberi, e quando ogni errore poteva portare a pesanti conseguenze, cominciai ad apprezzare la differenza tra l'agire secondo i principi del comando e disciplina e l'agire secondo i principi del giudizio condiviso. Le tradizioni funzionano a meraviglia nelle parate militari, ma non hanno senso nella vita reale, dove lo scopo può essere raggiunto solo attraverso il severo impegno di molte volontà convergenti -".

"Il severo impegno di molte volontà convergenti" è precisamente ciò che richiede un progetto come Linux. Il principio di comando è effettivamente impossibile da applicare tra volontari nel paradiso anarchico che chiamiamo internet. Per operare e competere efficacemente, gli hacker, che vogliono dar luogo a progetti collaborativi, devono imparare come reclutare efficienti comunità di interesse ed infondervi vigore nel modo a cui allude Kropotkin: il principio del giudizio condiviso. Devono imparare ad utilizzare la legge di Linus.

Prima ho parlato dell'effetto Delfi come una possibile spiegazione della legge di Linus, ma analogie forse più persuasive vengono dai sistemi adattativi in biologia ed economia. Il mondo Linux si comporta per molti aspetti come un libero mercato o come un sistema ecologico, dove un insieme di agenti si muovono egoisticamente tentando di massimizzare la funzione d'utilità, e in questo processo, producono un ordine spontaneo ed autocorreggente più complesso ed efficiente di qualsiasi forma di pianificazione centralizzata. Questo è il luogo dove ricercare il "principio di giudizio condiviso".

La funzione d'utilità che gli hacker di Linux stanno massimizzando non è quella data dell'economia classica ma è quella intangibile costituita dall'autogratificazione e e dalla reputazione acquisita tra gli altri hacker. (Questa si potrebbe chiamare una motivazione "altruistica" ma ignoreremmo il fatto che l'altruismo in sé è già una forma di autogratificazione dell'altruista.) Culture volontaristiche che funzionano in questo modo oggi sono comuni; un ambiente simile, al quale ho partecipato a lungo è il fanatismo (in senso buono) per la science fiction, in cui, però, non esiste quel fattore di crescita di reputazione di un individuo rispetto agli altri (detto anche ``egoboo'') e che è invece riconosciuto esplicitamente nell'hackerismo come guida fondamentale per l'attività dei volontari.

Linus ha dimostrato un'acuta padronanza del "principio di comprensione condivisa" di Kropotkin, proponendosi con successo nel ruolo di guardiano di un progetto nel quale lo sviluppo è fondamentalmente fatto da altri ed alimentando l'interesse nel progetto finché esso non è diventato auto-sufficiente. Questa prospettiva quasi-economica del mondo di Linux ci permette a riconoscere come questa "comprensione" è stata applicata.

Potremmo vedere il metodo di Linus come un modo di creare un efficiente ``mercato dell'egoboo'' che vincola il più possibile l'egoismo di singoli hacker a obiettivi assai ardui, che possono venir raggiunti solo con una prolungata collaborazione. Con il progetto Fetchmail ho dimostrato, sebbene in scala ridotta, che questo metodo può essere replicato con buoni risultati. Io, forse,l'ho fatto con più sistematicità e consapevolezza di Linus.

Molte persone, specialmente quelle che, per motivi ideologici, non accettano i mercati liberi, potrebbero aspettarsi che una cultura di "egoisti auto-guidati" sia frammentaria, territoriale, devastata, riservata ed ostile. Ma questa aspettativa è chiaramente disattesa, per esempio, dalla sbalorditiva varietà, qualità e profondità della documentazione di Linux; è ben noto che i programmatori odiano scrivere documentazione; com'è allora che gli hacker di Linux ne generano così tanta? Evidentemente il libero mercato del Linux-egoboo lavora meglio e produce comportamenti virtuosi e altruistici ignoti rispetto alla costose organizzazioni di documentazione tipiche dei produttori di software commerciale.

Entrambi i progetti di Fetchmail e del kernel di Linux mostrano che, ricompensando giustamente l'ego di molti altri hacker, un buon capoprogetto può riuscire a utilizzare internet per guadagnare il beneficio di avere un gran numero di co-sviluppatori, senza vedere il progetto sprofondare in un disordine caotico. È per questo che, alla Legge di Brooks, io contrappongo la seguente:

19. Se il capoprogetto ha un mezzo di comunicazione buono almeno quanto internet e ha la capacità di guidare senza costrizione, allora molte teste sono inevitabilmente meglio di una.

Penso che il futuro del software open source sarà dalla parte delle persone che sapranno come giocare al gioco di Linus, lasciando indietro la cattedrale per abbracciare il bazaar, ma questo non significa che la visione individuale e l'intelligenza vivace non avranno più una funzione: credo piuttosto che la frontiera dell'open source apparterrà alle persone che, cominciando con brillanti visioni individuali, sapranno amplificarle attraverso l'effettiva costruzione di comunità volontarie di interessi.

E forse questo non vale solo per il futuro del software open source. Nessuno sviluppatore di progetti ``chiusi'' potrà far concorrenza alla moltitudine di talenti della comunità Linux nel concentrarsi su un problema. In realtà, non sono molti quelli che potrebbero permettersi anche solo di pagare le persone (più di 200) che hanno contribuito a Fetchmail!

Forse, alla fine, la cultura open source trionferà non perché la cooperazione è moralmente giusta o l'accumulazione di software è moralmente sbagliata (e c'è chi lo pensa, al contrario ad esempio di Linus e e di me stesso) ma semplicemente perché il mondo dei sorgenti chiusi non può vincere una competizione evolutiva con comunità open source, che possono permettersi di utilizzare il tempo di professionisti in quantità che sono ordini di grandezza superiori.

11 Ringraziamenti

Questo articolo è stato migliorato da discussioni con un gran numero di persone che ne hanno reso possibile il debugging. Particolari ringraziamenti vanno a Jeff Dutky , che ha suggerito la formulazione ``il debugging è parallelizzabile'' e ha sviluppato l'analisi che ne consegue, a Nancy Lebovitz per avermi suggerito di imitare Weinberg citando Kropotkin. Critiche acute mi sono venute da Joan Eslinger e Marty Franz , della lista General Technics. Sono grato a tutti i membri del PLUG, the Philadelphia Linux User's Group, per essere stati il pubblico di prova della prima lettura di questo articolo. E infine, i commenti di Linus Torvalds mi sono stati di grande aiuto, e il suo sostegno di grande incoraggiamento.

12 Altre letture

Ho citato diverse parti dal classico di Frederick P. Brooks "The Mythical Man-Month" perché, sotto molti aspetti, le sue intuizioni sono ancora le migliori. Raccomando calorosamente l'edizione del 25° anniversario dell'Addison-Wesley (ISBN 0-201-83595-9) al quale ha aggiunto il suo documento "No silver bullet" del 1986.

La nuova edizione si chiude con una preziosa retrospettiva fatta 20 anni dopo, nella quale Brooks ammette che alcune argomentazioni nel testo originale non hanno resistito alla prova del tempo. La prima volta che lessi la retrospettiva questo documento era già nel suo stadio finale e fui sorpreso nello scoprire che Brooks attribuisce pratiche tipo bazaar alla Microsoft! (Comunque, a quanto pare, si sbagliava. Nel 1998 il Documento di Halloween ( http://www.opensource.org/halloween.html) ci rivelò che la comunità dei programmatori Microsoft è pesantemente balcanizzata e che l'accesso generalizzato ai sorgenti che è necessario per supportare il bazaar non è nemmeno remotamente concepibile)

Gerald M. Weinberg con "The Psychology of computer programming" (N.Y. Van Nostrand Reinhold, 1971) introdusse il concetto piuttosto sfortunatamente denominato "egoless programming" (programmazione altruista) e fu probabilmente il primo a riconoscerlo e a discuterlo nel contesto dello sviluppo del software.

Richard P. Gabriel, contemplando la cultura Unix dell'era pre-Linux, ha con riluttanza ammesso la superiorità di un primitivo modello di tipo bazaar nel suo documento del 1989 titolato "Lisp: good news, bad news, and how to win big". Sebbene per certi aspetti antiquato, questo saggio è ancora giustamente celebrato tra i fan del Lisp (me incluso. Un corrispondente mi ha suggerito che la sezione intitolata "Peggio è meglio" può essere vista quasi come un'anticipazione di Linux. Il documento è accessibile sul web all'indirizzo: http://www.naggum.no/worse-is-better.html

Il testo di De Marcon e Lister titolato "Peopleware: productive projects and teams" (N.Y. Dorset House, 1987; ISBN 0-932633-05-6) è un gioiello sottovalutato che sono stato lieto di veder citato da Fred Brooks nella sua retrospettiva. Mentre poco di ciò che gli autori dicono è applicabile a Linux o alla comunità open-source, l'intuizione degli autori sulle condizioni necessarie per il lavoro creativo è acuta e meritevole per chiunque tenti di importare alcune delle virtù del modello bazaar in un contesto commerciale.

Infine, devo ammettere di essere stato sul punto di chiamare questo documento "La cattedrale e l'Agorà": agorà, in Greco, significa un mercato aperto o un luogo di incontri pubblici. Sono stati i testi fondamentali di Mark Miller e Eric Drexler sui "sistemi agorici", che descrivono l' emergere di un'ecologia computazionale analoghe ai mercati aperti, che mi hanno aiutato nel pensare chiaramente ad fenomeni analoghi nella cultura open source, quando Linux me li mise sotto naso cinque anni fa. Questi documenti sono disponibili sul Web presso l'indirizzo http://www.agorics.com/agorpapers.html.

13 Epilogo: Netscape abbraccia il bazaar!

Il 22 gennaio 1998, circa sette mesi dopo la prima pubblicazione di questo documento, la Netscape Communications Inc. ha annunciato l'intenzione di distribuire i sorgenti di Netscape Communicator ( http://www.netscape.com/newsref/pr/newsrelease558.html). Prima del giorno dell'annuncio, non ne avevo il minimo sentore.

Eric Hahn, Vice Presidente esecutivo e capo ufficio tecnologico della Netscape, mi ha inviato una breve email di cui cito una parte: "a nome di tutta la Netscape, voglio ringraziarla per averci aiutato a comprendere l'importanza di questo fenomeno. Le Sue idee ed i Suoi scritti sono stati ispirazioni fondamentali per le nostre decisioni."

La settimana seguente andai nella Silicon Valley su invito della Netscape per partecipare ad una conferenza strategica (il 4 febbraio 1998) con alcuni dei loro top manager esecutivi e tecnici. Insieme progettammo la strategia e la licenza dei sorgenti di Netscape e disponemmo alcuni piani aggiuntivi con la speranza di avere un impatto positivo e di vasta portata nella comunità open source. Come ho scritto prima, è ancora troppo presto per essere più precisi ma presto potremo osservarne gli sviluppi.

Netscape è prossima a fornirci, su larga scala, un test di portata mondiale del modello bazaar nel mondo commerciale. La cultura open source ora è di fronte ad un problema: se l'iniziativa di Netscape non funzionerà, il concetto dell'open source potrebbe uscire così screditato da indurre il mondo commerciale a tenersene alla larga per un'altro decennio.

D'altra parte, questa è anche una opportunità spettacolare. Le reazioni iniziali di Wall Street a questa mossa sono state cautamente positive. Questa è anche un'opportunità di prova per noi. Se Netscape riconquisterà sostanziose quote di mercato grazie a questa mossa, potremo trovarci al principio di una rivoluzione attesa da parecchio nell'industria dell'information technology.

14 Versioni e modifiche

Ho cambiato il termine ``free software'' in ``open source' Il 9 Febbraio 1998, versione 1.29

Ho aggiunto la sezione ``Epilogo: Netscape entra nel Bazaar!'' il 10 Febbraio 1998, versione 1.31

La correzione di Brooks basata sul Documento di Halloween è del 20 Novembre 1998, versione 1.40

Altre versioni hanno recepito cambiamenti editoriali minori e aggiustamenti al markup.

Per la versione Italiana:

Prima versione ASCII (1.8) rilasciata sulla mailing list ERLUG (Emilia Romagna Linux User Group) il 14 Luglio 1999.

La cattedrale e il bazaar