La cattedrale e il bazaar di Eric S

La cattedrale e il bazaar di Eric S. Raymond Traduzione a cura di Nicolas Giorza

Introduzione Contenuti di “The cathedral and the bazaar”

• Analisi di un progetto open-source di successo, fetchmail, che era stato eseguito come un premeditato test di alcune teorie sorprendenti riguardanti lo sviluppo dei software, suggerite dalla storia di Linux. • Discussione di queste teorie nei termini di due stili di sviluppo fondamentalmente differenti, il modello della “cattedrale” della maggior parte del mondo commerciale, contro il modello “bazaar”del mondo Linux.

• Dimostrazione del fatto che questi modelli derivano da opposte supposizioni sulla natura del degug del software. • Esposizione di una argomentazione sostenuta dall’esperienza di Linux per la proposizione che “dati abbastanza occhi, tutti i bugs sono superficiali” [legge di Linus] • Proposizione di analogie produttive con altri sistemi di agenti autonomi auto-correggenti • Conclusione: esplorazione delle implicazioni di questa analisi per il futuro del software

La cattedrale e il bazaar

Prima di Linux Credevo che i software più importanti (i sistemi operativi e le applicazioni veramente grosse) necessitassero di essere costruiti come cattedrali, lavorati con cura da singoli sapienti o piccoli gruppi di geni che lavorano in splendido isolamento, senza che una beta versione del loro prodotto venisse rilasciata prima del tempo.

Dopo Linux Lo stile di sviluppo di Linus Torvald – rilasciare presto e spesso, delegare tutto ciò che si può, essere aperti fino alla promiscuità – è stato una sorpresa. Nessuna quieta, reverente costruzione di una cattedrale qui – piuttosto, la comunità di Linux sembra somigliare ad un grande bazaar chiacchierone contenente diversi ordini del giorno ed approcci dai quali, apparentemente, un sistema stabile e coerente potrebbe emergere solo in seguito ad una successione di miracoli.

Il mondo di Linux non solo non è stato spazzato via dalla confusione ma è sembrato diventare sempre più forte, ad una velocità a malapena immaginabile ai costruttori di cattedrali

Il progetto fetchmail Il caso mi affidò un modo perfetto per testare la mia teoria, sotto forma di un progetto open-source che potevo coscientemente provare a gestire nello stile bazaar. Così feci – ed è stato un significativo successo.

La posta deve passare

Ciò che mi serviva era un programma che raggiungesse la mia connessione SLIP e deviasse la mia mail perché potessere recapitata localmente. PERO’ Seri problemi con il funzionamento dei reply

Massima n. 1 1. Ogni buon pezzo di software inizia scatenando un prurito personale nello sviluppatore. Questo dovrebbe essere ovvio ( “La necessità è madre dell’invenzione”) ma troppo spesso gli sviluppatori di software passano le proprie giornate a sgobbare per denaro su programmi che a loro non servono e che non amano (ma non nel mondo di Linux – il che potrebbe spiegare l’alta qualità media dei software originati nella comunità di Linux)

Massima n. 2 2. I buoni programmatori sanno cosa scrivere. Quelli eccellenti sanno come riscrivere (e riusare). Si prende il massimo dei voti non per lo sforzo, ma per il risultato, e quasi sempre è più facile iniziare da una buona soluzione parziale che non partire da zero

Per questo non mi sono subito lanciato in un vortice furioso di scrittura del codice di un nuovo POP 3 client per competere con quelli già esistenti. Ho invece guardato con attenzione alle POP utilities che avevo tra le mani, chiedendo a me stesso “qual è quella più vicina a ciò che voglio? ”.

Eredità di Unix La tradizione di condivisione delle fonti del mondo Unix è sempre stata favorevole al riutilizzo del codice. Il mondo di Linux ha portato questa tradizione quasi al suo limite tecnologico; ha terabytes di fonti aperte generalmente disponibili.

Restare o cambiare? • Inizialmente mi concentrai su Fetchpop • Poi arrivò Popclient: sebbene fetchpop presentasse qualche idea buona ed originale, poteva solo gestire POP 3 ed era codificato in maniera abbastanza amatoriale. Il codice di Popclient era migliore, abbastanza professionale e solido, ma il suo programma mancava di diverse caratteristiche di fetchpop importanti e piuttosto difficili da attuare (incluse quelle che io stesso avevo codificato)

Restare o cambiare? Se avessi cambiato, avrei buttato via il lavoro di codifica che avevo già fatto in cambio di una migliore base di sviluppo. Decisi di cambiare.

Massima n. 3 3. “Metti in conto di buttarne via uno; lo farai, comunque. ” ["Plan to throw one away; you will, anyhow. "] (Fred Brooks, The Mythical Man. Month, Chapter 11) Oppure, per metterla diversamente, molte volte non capisci il problema se non dopo la prima volta che gli dai una soluzione. La seconda volta, magari, ne sai abbastanza per farlo nella maniera giusta. Quindi, se la vuoi spuntare, sii pronto a ricominciare da capo almeno una volta.

Massima n. 5 5. Quando perdi interesse in un programma, il tuo ultimo dovere nei suoi confronti è di affidarlo ad un successore competente. Dopo che ho mandato il mio primo set di patches di popclient a Carl Harris, ho scoperto che aveva praticamente perso interesse verso popclient da un po’ di tempo. Presto convenemmo che la cosa più logica da fare per me sarebbe stata rilevare il programma.

Massima n. 4 4. Se hai l’atteggiamento giusto, i problemi interessanti ti troveranno. Senza che me ne rendessi nemmeno conto, il progetto si era intensificato. Non stavo più solo progettando patches minori ad un POP client esistente. Avevo iniziato a mantenerne uno intero, ed avevo alcune idee che mi frullavano in testa che sapevo che probabilmente mi avrebbero portato a cambiamenti ancora più grandi

L’importanza dell’avere utenti

Un altro punto di forza della tradizione Unix, che Linux spinge felicemente all’estremo, è che anche molti utenti sono hacker. Dal momento che il codice sorgente è disponibile, possono essere hacker effettivi. Questo può essere estremamente utile per accorciare il tempo di eliminazione degli errori [debugging]. Con un minimo di incoraggiamento, i tuoi utenti possono diagnosticare problemi, proporre correzioni, ed aiutare a migliorare il codice molto più velocemente di quanto potessi fare senza aiuto.

Massima n. 6 Gli utenti sono una cosa fantastica da avere, e non solo perché dimostrano che stai soddisfacendo un bisogno, che hai fatto qualcosa di giusto. Coltivati nella maniera giusta, possono diventare co-sviluppatori. 6. Trattare i propri utenti come co-sviluppatori è la via meno problematica verso un rapido miglioramento del codice ed un effettivo debugging.

La trovata più intelligente e ricca di conseguenze di Linus non è stata la costruzione in sé del nucleo di Linux, ma piuttosto la sua invenzione del “modello di sviluppo Linux”.

Rilascia spesso, rilascia presto

Bazaar vs. cattedrale • Rilasci precoci e frequenti sono una parte critica dello “stile di sviluppo Linux”. Tutti erano convinti che fosse una politica sbagliata. • Questa convinzione rinforzava l’impegno di tutti per uno stile di sviluppo “a costruzione di cattedrale” [cathedral-bulding style of development]. Se l’obiettivo generale era che gli utenti vedessero meno bugs possibile, allora avresti solo fatto un rilascio ogni sei mesi (o meno frequentemente), e avresti lavorato come un cane al debugging tra un rilascio e l’altro.

Bazaar vs. cattedrale La politica di sviluppo aperto [open development] di Linus era l’esatto opposto della “costruzione di cattedrale”.

Massima n. 7 Linus stava trattando i suoi utenti come cosviluppatori nella migliore maniera più efficace possibile: 7. Rilascia presto. Rilascia spesso. E dai ascolto ai tuoi clienti.

Perché funzionò lo stile Linux • L’innovazione di Linus non stava tanto nel fare questo (qualcosa del genere era stata tradizione del mondo-Unix per molto tempo), quanto nell’elevarlo ad un livello di intensità che compensava la complessità di ciò che stava sviluppando. • Poiché aveva coltivato la sua base di cosviluppatori e aveva sfruttato Internet in cerca di collaborazione più di ogni altro, questo funzionò.

Come funzionò lo stile di Linux Linus stava facendo in modo che i suoi hacker/utenti fossero costantemente stimolati e appagati – stimolazione dovuta alla prospettiva di avere una parte dell’azione soddisfacente per il proprio ego, appagamento proveniente dall’evidenza di un costante (anche quotidiano) miglioramento nel loro lavoro.

Massima n. 8 (legge di Linus) 8. Data una base abbastanza grande di beta -tester e co-sviluppatori, quasi ogni problema sarà definito subito e la riparazione sarà ovvia a qualcuno. Oppure, meno formalmente: “Dato un numero sufficiente di occhi, tutti i bugs sono superficiali”. Ho soprannominato questa “la legge di Linus”.

Inoltre La persona che capisce e risolve il problema non è necessariamente o nemmeno di solito quella che per prima lo individua.

Differenze tra bazaar e cattedrale Nella visione della programmazione del costruttore di cattedrale, i bugs ed i problemi di sviluppo sono fenomeni profondi, complessi ed insidiosi. Ci vogliono mesi di esami dettagliati da parte di un gruppo apposito di persone per far nascere la convinzione che siano stati tutti snidati. Da qui i lunghi intervalli di pubblicazione, e l’inevitabile disappunto quando rilasci tanto sospirati non sono perfetti.

Differenze tra bazaar e cattedrale Nella visione bazaar, dall’altra parte, si assume che i bugs sono generalmente fenomeni superficiali – o, al limite, che diventano superficiali abbastanza in fretta quando vengono esposti ad un migliaio di zelanti co-sviluppatori che esaminano ogni singolo nuovo rilascio. Di conseguenza, si rilascia spesso per ottenere più correzioni, e come effetto secondario benefico si ha meno da perdere se un rattoppo occasionale viene lasciato fuori dalla porta

Legge di Linus Se la “legge di Linus” è falsa, allora qualsiasi sistema complesso quanto la kernel di Linux, su cui lavorassero così tante mani quante per il kernel di Linux, ad un certo punto sarebbe dovuto collassare sotto il peso di impreviste interazioni sbagliate e bugs “profondi” non scoperti. Se invece è vera, è sufficiente a spiegare la relativa mancanza di bugs di Linux.

Il debugging è parallelizzabile La legge di Linus può essere riformulata come “Il debugging è parallelizzabile” [debugging is parallelizable]. Il debugging richiede che i debuggers comunichino con qualche sviluppatore di coordinamento, non è necessario un coordinamento significativo tra i debuggers. Per questo motivo non è preda della stessa complessità quadratica e dei costi di gestione che rendono problematico aggiungere sviluppatori nei progetti a cattedrale.

“Il costo totale di manutenzione di un programma largamente usato è solitamente pari al 40 per cento o più del costo di sviluppo. Sorprendentemente questo costo è fortemente legato al numero di utenti. Più utenti trovano più bugs”. (Brooks) Questo non è un problema se i tuoi utenti sono co-sviluppatori.

Quando una rosa non è una rosa

Parte descrittiva Avendo studiato il comportamento di Linus e avendo formulato una teoria sul perché abbia avuto successo, ho preso la decisione consapevole di mettere alla prova questa teoria sul mio nuovo (anche se molto meno complesso ed ambizioso) progetto.

Come l’ho fatto • • Ho rilasciato presto e spesso (quasi mai meno spesso che ogni dieci giorni; durante i periodi di sviluppo intenso, una volta al giorno). Ho accresciuto la mia beta list aggiungendovi chiunque mi avesse contattato a riguardo di fetchmail. Ho mandato annunci amichevoli alla mia beta list ogni volta che ho rilasciato, incoraggiando la gente a partecipare. E ho ascoltato i miei beta tester, interpellandoli sulle questioni di design e incoraggiandoli quando mi mandavano delle patch e delle risposte.

Massima n. 10 • La ricompensa per queste semplici misure è stata immediata. Sin dall’inizio del progetto, ho ricevuto segnalazioni di bug di una qualità per cui molti sviluppatori potrebbero anche uccidere, spesso con buone correzioni allegate. Ho ricevuto serie critiche, ho ricevuto mail di incoraggiamento, ho ricevuto intelligenti proposte di funzioni da inserire. Il che porta a: 10. Se tratti i tuoi beta-tester come la tua risorsa più importante, risponderanno diventando la tua risorsa più importante.

Popclient diventa fetchmail

Parte descrittiva Una volta aggiunta la caratteristica di invio SMTP, Popclient non era più un semplice agente di consegna locale (MDA), ma era diventato un puro agente di trasporto della posta (MTA).

Massima n. 11 11. La cosa migliore, dopo l’avere delle buone idee, è riconoscere le buone idee dei propri utenti. A volte l’ultima è la migliore. Infatti questa idea di invio SMTP è stata la migliore singola ricompensa per aver coscientemente provato ad emulare i metodi di Linus. Un utente mi ha dato un’idea eccezionale – tutto ciò che dovevo fare era capirne le implicazioni.

Massima n. 12 12. Spesso la soluzione più sorprendente ed innovativa viene dalla scoperta che la tua concezione del problema era sbagliata. Ho provato a risolvere il problema sbagliato, continuando a sviluppare popclient come un combinato MTA/MDA con tutte le modalità più bizzarre di consegna locale. Il progetto di fetchmail aveva bisogno di essere ripensato fin dalle fondamenta come un puro MTA, una parte del normale percorso della posta elettronica in internet, che si svolge in linguaggio SMTP.

Quando sbatti contro un muro nello sviluppo, spesso è ora di chiederti non se sei in possesso della risposta giusta, ma piuttosto se ti stai ponendo la domanda corretta.

Morale della favola Non esitate a buttare via caratteristiche antiquate quando lo potete fare senza una perdita di efficienza.

Fetchmail cresce

Punti d’incontro tra Linux e Fetchmail Andrew Tanenbaum ebbe l’idea originale di costruire un semplice Unix nato per il 386, da usare come strumento di insegnamento. Linus Torvald spinse il concetto di Minix più in là di quanto Andrew probabilmente pensava potesse andare – e si è evoluto in qualcosa di meraviglioso. Allo stesso modo (anche se su scala più ridotta), io presi alcune idee di Carl Harris ed Harry Hochheiser e le ho spinte verso il limite.

Linus ed io non siamo stati “originali”nella maniera romantica in cui la gente pensa alla genialità. Ma in realtà, la maggior parte dello sviluppo nei campi scientifico, dell’ingegneria e dei software non è effettuato da geni originali, contrariamente a quanto possa pensare la mitologia hacker.

Non accontentarsi mai! Dovetti addirittura innalzare i miei standard. Per rendere fetchmail tanto buono quanto ora vedevo che avrebbe potuto essere, avrei dovuto scrivere non solo per le mie necessità, ma anche includere e supportare applicazioni necessarie ad altri, ma al di fuori della mia orbita. E dovevo farlo mantenendo il programma semplice e robusto.

Un altro paio di lezioni da fetchmail (Molto tecnico)

Precondizioni necessarie per lo stile bazaar

No codifica da zero È abbastanza chiaro che uno non può codificare da zero in stile bazaar. Uno può testare, eliminare i bug e migliorare nello stile bazaar, ma sarebbe molto arduo dare vita a un progetto nella modalità bazaar. Linus non ci ha provato. Nemmeno io l’ho fatto. La tua nascente comunità di sviluppatori deve avere qualcosa di eseguibile e verificabile con cui giocare.

Una promessa plausibile Quando inizi a costruire la comunità, ciò che devi essere capace di presentare è una promessa plausibile. Il tuo programma non ha bisogno di lavorare particolarmente bene. Ciò in cui non deve fallire è nel convincere potenziali co-sviluppatori che può essere evoluto in qualcosa di davvero ben fatto in un futuro non troppo lontano.

Abilità necessarie per essere dei buoni coordinatori Credo che non sia fondamentale che il coordinatore sia capace di dare vita a design eccezionalmente splendidi, ma è assolutamente necessario che il coordinatore sia in grado di riconoscere le buone idee di design degli altri.

Abilità necessarie per essere dei buoni coordinatori C’è un altro tipo di capacità, che normalmente non è associato con lo sviluppo dei software e che credo sia importante, nei progetti bazaar, tanto quanto la bravura nel design – e magari è anche più importante: un coordinatore o leader di un progetto bazaar deve avere buone capacità di relazione con le persone e di comunicazione.

Abilità necessarie per essere dei buoni coordinatori Per creare una comunità di sviluppo, hai bisogno di attrarre le persone, destare interessare in loro per ciò che stai facendo, e mantenerle soddisfatte per la quantità di lavoro che stanno svolgendo. La passione per la tecnica farà molto in questo senso, ma è lontana dal fare tutto. INSOMMA: Per far funzionare il modello bazaar, aiuta molto avere almeno una piccola capacità di incantare le persone

Il contesto sociale dei software open source L’esperienza di Linux si apre ad aspetti non solo legati all’informatica, ma anche alla sociologia, alla biologia e all’economia

Massima n. 18 La massima n. 1 può essere riformulata come: 18. Per risolvere un problema interessante, inizia a trovare un problema che sia interessante per te.

Coinvolgere intere comunità • Mentre la scrittura del codice rimane un’attività essenzialmente solitaria, gli hack veramente grandi nascono catturando l’attenzione e capacità intellettuali di intere comunità. • Lo sviluppatore che usa solo la propria mente in un progetto chiuso sarà superato dallo sviluppatore che sa come creare un contesto aperto, evolutivo in cui la scoperta dei bug e i miglioramenti sono fatti da centinaia di persone.

Perché Linux e non già Unix? Molti fattori hanno impedito a questo approccio di essere spinto fino all’ultimo livello nel tradizionale mondo di Unix. Uno di essi erano i contenuti legali di molte licenze, segreti professionali ed interessi commerciali. Un altro (in retrospettiva) è che internet non era ancora abbastanza buono.

• Linux è stato il primo progetto a fare uno sforzo cosciente e di successo per utilizzare il mondo intero come fucina di talenti. • Non credo che sia una coincidenza che il periodo di gestazione di Linux sia coinciso con la nascita del World Wide Web, e che Linux abbia lasciato l'infanzia durante gli stessi anni che hanno visto il decollo dell’industria dei provider Internet e l'esplosione dell'interesse di massa per Internet.

Linus è stata la prima persona ad aver imparato come giocare secondo le nuove regole che Internet dilagando ha reso possibili: si è posizionato con successo come guardiano di un progetto in cui lo sviluppo è perlopiù svolto da altri, ed ha alimentato interesse nel progetto finché non è arrivato ad auto-alimentarsi.

Massima n. 19 19. Stabilito che il coordinatore dello sviluppo abbia a disposizione un medium almeno altrettanto buono di Internet, e sappia come comandare senza costrizione, molte teste sono inevitabilmente meglio di una sola.

Conclusione Penso che il futuro del software open source apparterrà sempre più alle persone che sanno giocare al gioco di Linus, persone che si lasceranno alle spalle la cattedrale ed abbracceranno il bazaar. Ciò non vuol dire che visione individuale ed intelligenza non importeranno più; piuttosto, credo che la punta avanzata del software open source apparterrà a persone che inizieranno da una brillante visione individuale, per poi amplificarle attraverso l'effettiva costruzione di comunità volontarie d'interesse.

Conclusione E probabilmente non soltanto il futuro del software open-source. Nessuno sviluppatore commerciale potrà mai pareggiare la fucina di talenti che la comunità Linux è in grado di riunire per affrontare un problema. In pochi potrebbero permettersi di assumere le oltre duecento persone che hanno contribuito a fetchmail!