La cattedrale e il bazaar

Eric Raymond aveva già una quindicina di anni di esperienza nello sviluppo di software quando, nel 1997, scrive quello che è considerato il manifesto dell'opensource (e non del software libero, come erroneamente si dice nella pagina italiana di wikipedia: La cattedrale e il bazaar).

Raymond mette in opposizione due modelli di sviluppo - o meglio, di correzione degli errori - di software complessi.

Il primo, la cattedrale, è quello usato nel medioevo per realizzare opere enormi, che avrebbero dovuto durare nel tempo, e che richeidevano competenze diverse e grandi risorse umane. Questo è il modello di sviluppo usato normalmente nello sviluppo di software all'interno delle aziende "tradizionali" di software: c'è un progetto, un capo progetto, e poi ci sono tanti task separati, ognuno dei quali è assegnato ad uno sviluppatore diverso. Nessuno degli sviluppatori ha un'idea precisa del disegno complessivo e il controllo della qualità - come quello sul rispetto dei tempi - è affidato al capo progetto.

Il secondo, il bazaar, è quello usato da millenni in oriente per gestire i mercati (famosi ancora oggi quelli di Istanbul e di Marrakech). Ogni mercante arriva e occupa uno spazio accanto agli altri. A sorpresa (ma solo per un occidentale scolarizzato) quello che dovrebbe essere un caos ingovernabile si auto-struttura in un organismo cone delle regole che emergono dal basso: i venditori di spezie si collocano tutti nella stessa area, lo spazio lasciato per lo spostamento dei clienti è coperto in maniera equilibrata con le tende delle bancarelle dai due lati opposti, quando un mercante deve lasciare la bancarella viene sostituito dal vicino. In questo modello non c'è un progetto e non c'è un capo progetto, ma ognuno collabora per la riuscita complessiva come meglio può. Questo è il modello con cui Raymond stesso ha sviluppato fetchmail, un software di posta elettronica, come racconta nel testo.

In pratica, il codice sorgente scritto dall'autore originale viene pubblicato con un sistema di gestione del codice (come Subversion, Mercurial o Git). Tutti gli sviluppatori che sono interessati si iscrivono, scaricano il codice e se vogliono apportare modifiche, correggere o aggiungere funzionalità lo fanno liberamente. In realtà non si tratta proprio di un processo gestito in autonomia: gli sviluppatori devono chiedere al coordinatore, cioè all'autore originale, il permesso di integrare le loro proposte di modifica al progetto principale.

Secondo Raymond questa seconda modalità produce risultati migliori qualitativamente. La prova, secondo lui, è proprio il kernel di Linux, che è sviluppato in questo modo ed è considerato uno dei pezzi di codice sorgente più robusti al mondo, visto che viene inserito in una quantità enorme di computer diversi, da quelli enormi a quelli quasi invisibili.

Non è un modello riservato allo sviluppo di software: anche Wikipedia utilizza lo stesso modello, in maniera esplicita: Jimmy Wales, il suo creatore, sostiene di essersi ispirato, tra l'altro, proprio al libro di Raymond. Ma l'idea non è così nuova: Wales cita anche "The Use of Knowledge in Society", un articolo di un economista, Friedrich Hayek, pubblicato nel 1945 in cui si sostiene che un'economia pianificata produce effetti negativi proprio perché la conoscenza è distribuita tra gli utenti e non è mai del tutto disponibile a chi ha un potere centrale. In pratica, ciò che è dietro il modello del bazaar è il libero mercato.

"La cattedrale e il bazaar" contiene anche alcune "lezioni" imparate da Raymond durante l'esperienza di sviluppo collettivo di sofware, oppure prese in prestito da altri. Alcune di queste fanno parte di una specie di enciclpedia condivisa delle buone pratiche di sviluppo del software, come queste:

    - Meglio avere strutture dati intelligenti e codice stupido che il contrario
    - Ogni strumento divrebbe essere utile se usato secondo le istruzioni, ma 
    uno strumento veramente buono deve permettere utilizzi inaspettati

mentre altre sottolineano l'importanza di coinvolgere il maggior numero possible di persone (utenti, beta-tester, sviluppatori) e di ascoltare i loro suggerimenti:

    - Se tratti i tuoi beta-testers come se fossero la tua risorsa più valida, 
    risponderanno diventanto dala tua risorsa più valida.
    - La cosa migliore, dopo avere buone idee, è riconoscere le buone idee
    dei tuoi utenti. Qualche volta è ancora meglio.
    - Molte teste sono inevitabilmente meglio di una, a patto che il coordinatore 
    dello sviluppo abbia un sistema di comunicaione buona almeno quanto internet, 
    e sappia come condurre senza obbligare.

La cosa interessante è che nel preferire il modello bazaar Raymond non fa riferimento a questioni di libertà, diritti, democrazia, ma solo alla qualità del risultato. E' questo diverso accento che distingue il significato delle espressioni "software libero" e "opensource", anche se spesso vengono usate come sinonimi.

Non tutti sono d'accordo con l'entusiasmo e l'ottimismo di Raymond. In particolare, Nikolaj Bezroukov ha scritto a più riprese una critica del testo di Raymond e in generale una descrizione della modalità di sviluppo "opensource" molto più realistica. Bezroukov nega che la semplice aggiunta di persone allo sviluppo di un software possa portare ad una conclusione più rapida e qualitativamente superiore e cita un testo di quindici anni precendente: The Mythycal Man-Month, di Frederick Brook. In quel testo veniva formulata quella che poi è diventata famosa come la Legge di Brook: "Aggiungere più sviluppatori ad un progetto che è in ritardo non farà che aumentare il ritardo".

Bezroukov sostiene che non solamente lo sviluppo di Linux non segue affatto il paradigma del bazaar, ma è diretto con mano di ferro da Linus Torvalds che è una sorta di dittatore con pieni poteri (come accade anche nello sviluppo dei più importanti linguaggi opensource, da cui l'idea di chiamare i loro inventori BDFL, cioè "Benevelent Dictator For Life"), ma anche che la maggior parte dei progetti opensource stanno in realtà in qualche punto all'interno dello spazio tra cattedrale e bazaar.

Fondamentalmente, Bezroukov ritiene che programmare per il solo gusto di farlo è qualcosa che va bene per il software dedicato agli stessi sviluppatori, mentre per il software rivolto a tutti gli altri utenti è necessario un approccio "commerciale".