Questa voce o sezione sull'argomento informatica è priva o carente di note e riferimenti bibliografici puntuali.

---

Sebbene vi siano una bibliografia e/o dei collegamenti esterni, manca la contestualizzazione delle fonti con note a piè di pagina o altri riferimenti precisi che indichino puntualmente la provenienza delle informazioni. Puoi migliorare questa voce citando le fonti più precisamente. Segui i suggerimenti del progetto di riferimento.

La cattedrale e il bazaar (The Cathedral and the Bazaar) è un saggio sullo sviluppo del software scritto da Eric Steven Raymond. Esso descrive un nuovo modello di sviluppo, il cui esempio più famoso ed efficace è la modalità di costruzione del kernel Linux, chiamato appunto bazaar per lo spirito di decentralizzazione con cui gli sviluppatori sono spinti a collaborare tra loro. Il titolo del saggio è stata fonte di ispirazione per dare il nome a un software libero di controllo versione, sviluppato da Canonical Ltd., .^[1]

L'autore, per verificare le proprie ipotesi, decide di utilizzare lo sviluppo collaborativo per il programma fetchmail, e nel saggio viene descritta la genesi e lo sviluppo del progetto, analizzando le interazioni con gli altri sviluppatori e i vantaggi rispetto al modello classico.^[2] La prima presentazione del saggio si è avuta durante un congresso su Linux il 27 maggio 1997 e in seguito il saggio è stato pubblicato come parte dell'omonimo libro. Questo saggio viene generalmente considerato il manifesto del movimento del software libero.

Il saggio descrive in sostanza due contrapposte modalità di sviluppo del software libero:

• nel modello a cattedrale il programma viene realizzato da un numero limitato di "esperti" che provvedono a scrivere il codice in quasi totale isolamento. Il progetto ha una suddivisione gerarchica molto stretta e ogni sviluppatore si preoccupa della sua piccola parte di codice. Le revisioni si susseguono con relativa lentezza e gli sviluppatori cercano di distribuire programmi il più possibile completi e senza bug. Il programma Emacs, il GCC e molti altri programmi si basano su questo modello di sviluppo;
• nel modello a bazaar il codice sorgente della revisione in sviluppo è disponibile liberamente, gli utenti possono interagire con gli sviluppatori e se ne hanno le capacità possono modificare e integrare il codice. Lo sviluppo è decentralizzato e non esiste una rigida suddivisione dei compiti, un programmatore di buona volontà può modificare e integrare qualsiasi parte del codice. In sostanza lo sviluppo è molto più diluito e libero, da qui il nome di modello a bazaar. Il kernel Linux e molti programmi utilizzano questo nuovo modello di sviluppo associativo.

La tesi centrale di Raymond è che "Dato un numero sufficiente di occhi, tutti i bug vengono a galla". Questa affermazione (che Raymond chiama "Legge di Linus") costituisce, a suo parere, il motivo centrale del successo del progetto del Kernel Linux. Prima dell'avvento di Linux si riteneva che ogni progetto di una certa complessità avesse bisogno di essere adeguatamente gestito e coordinato: in caso contrario il progetto sarebbe collassato sotto il peso di moltissime revisioni e modifiche, prodotte da più persone e quindi spesso incompatibili. Il progetto Linux riuscì a dimostrare che non solo questo non accadeva, ma che al contrario al crescere del numero di sviluppatori anche la qualità e l'affidabilità del software migliorava.

Il modello a cattedrale è un modello tipico delle aziende commerciali. Queste normalmente non divulgano il codice sorgente, e una nuova revisione del programma può richiedere anni; viceversa, il modello a bazaar è un modello che si è molto diffuso nell'ambiente del software libero, poiché consente a ogni utente di ricoprire il ruolo di beta tester dei programmi. Lo stesso utente può perfino modificare il programma, se lo desidera: questo consente un rapporto stretto tra utilizzatori e programmatori, un rapporto paritario che ben si adatta alla filosofia del software libero. Consente inoltre un attento controllo del codice, aiutando a eliminare rapidamente la maggior parte dei bug; questione invece complessa per un software prodotto con la modalità a cattedrale, dove solo un numero limitato di persone lavora sul codice.

La modalità a cattedrale è la stessa metodologia di sviluppo che viene utilizzata dagli editori di enciclopedie commerciali: un numero limitato di esperti si preoccupa di compilare tutte le voci. La modalità a bazaar invece è quella utilizzata da Teknopedia: ogni lettore, se lo desidera, può integrare e migliorare i contenuti e la verifica delle modifiche apportate al testo è gestita dagli stessi utenti.

Raymond sottolinea 19 "best-practice" apprese durante lo sviluppo del software, ognuna di esse descrive le linee guida che sarebbe utile seguire nello sviluppo del software open source:^[3]

1. Ogni buon lavoro software inizia dalla frenesia personale di uno sviluppatore.
2. I bravi programmatori sanno cosa scrivere. I migliori sanno cosa riscrivere (e riusare).
3. "Preparati a buttarne via uno; dovrai farlo comunque." (Fred Brooks, "The Mythical Man-Month", Capitolo 11)
4. Se hai l'atteggiamento giusto, saranno i problemi interessanti a trovare te.
5. Quando hai perso interesse in un programma, l'ultimo tuo dovere è passarlo a un successore competente.
6. Trattare gli utenti come co-sviluppatori è la strada migliore per ottenere rapidi miglioramenti del codice e debugging efficace.
7. Distribuisci presto. Distribuisci spesso. E presta ascolto agli utenti.
8. Stabilita una base di beta-tester e co-sviluppatori sufficientemente ampia, ogni problema verrà rapidamente definito e qualcuno troverà la soluzione adeguata.
9. Meglio combinare una struttura dati intelligente e un codice non eccezionale che non il contrario.
10. Se tratti i beta tester come se fossero la risorsa più preziosa, replicheranno trasformandosi davvero nella risorsa più preziosa a disposizione.
11. La cosa migliore, dopo l'avere buone idee, è riconoscere quelle che arrivano dagli utenti. Qualche volta sono le migliori.
12. Spesso le soluzioni più interessanti e innovative arrivano dal fatto di esserti reso conto come la tua concezione del problema fosse errata.
13. "La perfezione (nel design) si ottiene non quando non c'è nient'altro da aggiungere, bensì quando non c'è più niente da togliere."
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.
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!
16. Quando il linguaggio usato non è affatto vicino alla completezza di Turing, un po' di zucchero sintattico può esserti d'aiuto.
17. Un sistema di sicurezza è sicuro soltanto finché è segreto. Meglio diffidare degli pseudo-segreti.
18. Per risolvere un problema interessante, comincia a trovare un problema che risvegli il tuo interesse.
19. Stabilito che il coordinatore dello sviluppo abbia a disposizione un medium almeno altrettanto affidabile di Internet, e che sappia come svolgere il ruolo di leader senza costrizione, molte teste funzionano inevitabilmente meglio di una sola.

• Eric Steven Raymond
• Bazaar (software)
• Open source
• Software libero

• Wikisource contiene il testo completo di o su La Cattedrale e il Bazaar

• (EN) Sito ufficiale, su catb.org.
• (EN) Edizioni e traduzioni di La cattedrale e il bazaar, su Open Library, Internet Archive.
• (EN) La cattedrale e il bazaar, su Goodreads.
• Traduzione italiana Archiviato il 5 aprile 2007 in Internet Archive. di Bernardo Parrella sul sito di Apogeo
• (EN) Testo originale sul sito di Eric Raymond

Portale Informatica

Portale Letteratura

Portale Software libero