La cattedrale e il bazaar di Eric Steven Raymond è un testo (o saggio… ma mi sembra eccessivo) del 1997 dove Raymond, utilizzando come esempio lo sviluppo del software fetchmail (sviluppato dallo stesso Raymond), analizza il successo della metodologia di sviluppo software introdotte la Linus Torvald per il progetto Linux, in contrasto al paradigma di programmazione “a cattedrale” in voga in gran parte del mondo commerciale (ma anche all’interno della stessa Free Software Foundation di Stallman di cui Raymond era un “seguace”). L’analisi dei due modelli viene condotta confrontando le diverse modalità di interpretare l’attività di debugging.

Al di là dei tecnicismi però ci sono degli spunti molto interessanti che scorrono costantemente su due binari paralleli: da un parte Raymond con il suo software fetchmail e sull’altro binario Torvalds con Linux e la grande rivoluzione del software open source.

Stallman storcerebbe il naso ad una simile definizione… preferirebbe “free software”… ma d’altronde HURD non ha ancora visto la luce…

Ed ecco le 19 regole che emergono, come capisaldi, dal nuovo paradigma del bazaar:

  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 codice non eccezionale che non il contrario.
  10. Se tratti 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.” Antoine de Saint-Exupèry (aviatore e designer di aerei, quando non scriveva libri per bambini)
  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.