Nel 1997 Eric S. Raymond ha pubblicato un articolo sull’argomento destinato ad essere ampiamente letto: “La cattedrale ed il bazaar”, in cui descrive alcune caratteristiche dei modelli di sviluppo del software libero, sottolineando ciò che differenzia questi modelli dai modelli di sviluppo proprietari. Da allora quell’articolo è diventato uno dei più noti (e più criticati) nel mondo dell'ingegneria del software.
Raymond opera una analogia tra il modo in cui erano costruite le cattedrali del medioevo ed il modo di produzione classico del software. Egli sostiene che in entrambi i casi c’è una chiara distribuzione di compiti e di ruoli, dove il progettista (Designer) è in cima a tutto e controlla il processo dall’inizio alla fine. La pianificazione è strettamente controllata in entrambi i casi, dando origine a processi chiaramente definiti, in cui – idealmente - ogni partecipante all’attività ha un ruolo molto limitato e specifico.
Raymond vede come analoghi al modello di costruzione delle cattedrali non solo i processi dei grossi produttori dell’industria del software (ad esempio il classico modello a cascata, i vari aspetti dei modelli di tipo AGILE, ecc) ma anche alcuni progetti di software libero, come NetBSD. Secondo Raymond, progetti come questo sono centralizzati perché solo poche persone sono responsabili del progetto ed implementazione del software. Le attività che queste persone svolgono e i ruoli che ricoprono sono perfettamente definiti e per chiunque voglia inserirsi nella squadra di sviluppo, sarebbe necessaria l’assegnazione di una attività e di un ruolo in relazione alle necessità del progetto. Un’altra caratteristica è che i rilasci in questo tipo di progetti tendono ad essere distanziati nel tempo, secondo un rigido programma. Ciò comporta pochi rilasci del software, notevolmente distanziati tra loro, secondo fasi chiaramente definite dalla programmazione.
Il bazaar è all’opposto del modello della cattedrale.
Secondo Raymond, alcuni progetti di software libero, specialmente il kernel di Linux, sono stati sviluppati sulla falsariga di un bazaar orientale. In esso non c’è una autorità di governo che controlla i processi che sono sviluppati e che pianifica accuratamente ogni passo. Inoltre i ruoli dei partecipanti possono cambiare costantemente (i venditori possono diventare clienti) senza direttive dall’esterno.
Raymond analizza con accuratezza e descrive il processo che ha portato Linux ad essere una storia di successo nel mondo del software libero, si tratta di un insieme di “buoni metodi” che sfruttano appieno i vantaggi e le opportunità consentite dalla disponibilità del codice sorgente e dalla interattività dei sistemi e degli strumenti in rete.
Un progetto di software libero tende a nascere come risultato di una azione strettamente personale; comincia con uno sviluppatore che ammette di non essere in grado di risolvere completamente un problema. Lo sviluppatore deve almeno avere le conoscenze per cominciare a risolvere il problema. Dopo che lo sviluppatore è riuscito ad avere qualcosa di usabile, semplice e con qualche funzionalità (e se possibile ben progettato e ben codificato) la cosa migliore che può fare è condividere la soluzione con la comunità del software libero. Nel mondo del software libero questa prassi è nota come “rilascio anticipato”, ed ha l’effetto di attirare l’attenzione di altre persone (generalmente sviluppatori) che hanno lo stesso problema e che sono interessati alla soluzione.
Uno dei principi base di questo modello di sviluppo è di considerare gli utenti come co-sviluppatori. I rapporti con la leadership sono fondamentali, non solo perchè possono fare pubblicità col sistema del passaparola, ma anche perché essi potranno eseguire il testing, che una delle attività più dispendiose della produzione del software. Diversamente dal co-sviluppo, che non è facilmente scalabile, il debugging e il testing sono, per la loro stessa natura, altamente parallelizzabili. Infatti, l’utente che prende il software e lo prova sulla sua macchina in condizioni determinate (un tipo di architettura, gli strumenti, ecc.) e si tratta di un’attività che, moltiplicata per il rilevante numero di architetture ed ambienti, richiederebbe un notevole impegno da parte del gruppo di sviluppo. Questa modalità di operare ha ispirato modelli progettuali fondati sul calcolo diffuso, ossia una tipologia di applicativi che utilizzano la potenza di calcolo dei computer connessi alla rete commerciale dividendo il lavoro di elaborazione fra tutti i PC, quindi una qualsiasi operazione di calcolo viene scomposta fra tutti gli operatori connessi che ne elaborano separatamente i dati.
L'elemento caratterizzante del modello produttivo open source è che l'utente (privato, impresa o ente pubblico) può proporre e realizzare modifiche, correzione degli errori, controlli qualitativi e nuove caratteristiche. Questo processo annulla la distinzione tra utente e sviluppatore, incoraggiando così estenzioni e miglioramenti provenienti da un enorme numero di potenziali sviluppatori decentralizzati51. Se gli utenti sono considerati sviluppatori, c’è la possibilità che qualcuno di loro trovi un errore, lo corregga e mandi una file allegato agli sviluppatori del progetto, in modo da includere la soluzione nella versione successiva. Può anche succedere, ad esempio, che il problema sia approfondito e corretto da una persona diversa da chi ha segnalato per primo l’errore. In ogni caso, tutti questi scenari sono chiaramente molto favorevoli per lo sviluppo del software.
La situazione diventa ancora più efficace nel caso di rilasci frequenti; se si vede che i problemi sono affrontati rapidamente, c’è maggiore motivazione per trovare, segnalare e correggere gli errori. Ci sono anche vantaggi collaterali, come il fatto che l’integrazione è realizzata spesso (idealmente una volta al giorno) e quindi non è più necessaria la fase finale di integrazione dei moduli del prodotto. Questo principio del rilascio frequente permette una grande modularità e massimizza l’effetto pubblicitario dei rilasci di una nuova versione del software. La gestione dei rilasci nei progetti in grande scala tende a seguire un processo ben definito e in qualche modo complesso.
Per evitare che i rilasci frequenti respingano gli utenti che preferiscono la stabilità rispetto alla velocità di evoluzione del software, alcuni progetti di software libero hanno diversi filoni paralleli (branches) di sviluppo. Il caso più noto è il kernel di Linux, che ha un filone stabile – per chi apprezza l’affidabilità – ed un altro “instabile”, orientato agli sviluppatori, con le più recenti innovazioni e funzionalità.
Alcuni utenti correggono piccoli errori (detti shallow bug) che incontrano durante il loro utilizzo quotidiano attraverso una pratica detta di “impulsive debugging”, mentre altri correggono errori significativi e sviluppano nuove funzionalità per hobby o vocazione che producono innovazioni molto marginali. In altri casi gli utenti segnalano suggeriscono e richiedono modifiche, allegati o nuove caratteristiche al nucleo di programmatori che curano il progetto e che possono poi essere incluse nelle distribuzioni Linux.
Questa comunità di sviluppatori che contribuisce a Linux è geograficamente molto sparsa, molto numerosa e chiaramente internazionale.
Come in tutte le comunità esiste una vasta parte di contributori moderatamente impegnati che apportano un modesto ammontare di lavoro e partecipano irregolarmente, così come esiste un più piccolo ma più impegnato gruppo che forma di volta in volta il nucleo centrale di un progetto.
Vi sono poche difficoltà per entrare nella comunità di sviluppatori. Tipicamente i programmatori propongono le loro idee attraverso mailing lists, newsgroups, chat o portali costituiti per il progetto.
Gli utenti/sviluppatori sono rappresentati attraverso i profili più svariati.
