# La cattedrale e il bazaar/Quando una rosa non è una rosa?

../Distribuire presto e spesso ../Popclient diventa Fetchmail IncludiIntestazione 5 settembre 2014 75% Open Source
La cattedrale e il bazaar Eric Steven Raymond 1997 CC BY-SA 3.0 GFDL //it.wikisource.org/w/index.php?title=La_cattedrale_e_il_bazaar/Quando_una_rosa_non_%C3%A8_una_rosa%3F&oldid=- 20140905143227 //it.wikisource.org/w/index.php?title=La_cattedrale_e_il_bazaar/Quando_una_rosa_non_%C3%A8_una_rosa%3F&oldid=- 20140905143227
Dopo aver osservato il comportamento di Linus e aver elaborato una mia teoria sul perché del suo successo, ho deciso coscientemente di mettere alla prova tale teoria sul mio nuovo progetto (palesemente assai meno complesso e ambizioso).
Per prima cosa però ho semplificato parecchio popclient. Le implementazioni di Carl Harris erano precise, ma mostravano quella complessità inopportuna comune a molti programmatori in C. Trattava il codice come elemento centrale, considerando solo come supporto a latere la struttura dati. Come conseguenza, il codice era eccezionale ma il design strutturale improvvisato e bruttino (almeno secondo gli standard elevati di questo vecchio hacker di LISP).
Oltre al miglioramento del codice e del design strutturale, perseguivo comunque un altro obiettivo nell’operazione di riscrittura. Volevo si evolvesse in qualcosa che fossi in grado di comprendere pienamente. Non c’è alcun divertimento nel sistemare i problemi di un programma che non si comprende appieno.
Fu così che mi ci volle tutto il primo mese soltanto per seguire le implicazioni del progetto di base di Carl. La prima vera modifica fu l’aggiunta del supporto per IMAP. In pratica riorganizzai le macchine del protocollo in un driver generico con tre opzioni (per POP2, POP3 e IMAP). Insieme ai cambiamenti precedenti, ciò illustra il principio generale che ogni programmatore dovrebbe tenere bene a mente, soprattutto lavorando con linguaggi come il C che non accettano facilmente gli inserimenti dinamici:
9. Meglio combinare una struttura dati intelligente e un codice non eccezionale che non il contrario.
Brooks, capitolo 9: “Mostrami [il codice] e nascondimi [la struttura dati], e io continuerò a essere disorientato. Mostrami [la struttura dati], e non avrò bisogno del [codice]; sarà del tutto ovvio.”
Per esser precisi, lui parlava di “diagrammi” e “tabelle”. Ma considerando il mutamento lessicale/culturale di questi trent’anni, il senso rimane invariato.
A questo punto (inizio Settembre 1996, sei settimane dopo esser partito da zero), ho cominciato a pensare all’opportunità di cambiare il nome – in fondo non si trattava più soltanto di un client POP. Ma esitavo perché mancava ancora qualcosa di genuinamente nuovo nel design. La mia versione di popclient doveva ancora acquisire una propria identità.
Il cambio radicale avvenne quando fetchmail imparò come fare il forward della posta prelevata verso la porta SMTP. Lo spiego meglio tra poco. Prima però: più sopra ho parlato della decisione di usare questo progetto come test per verificare la mia teoria sui brillanti risultati raggiunti da Linus Torvalds. Vi potreste chiedere, in che modo l’ho messa alla prova? Ecco come:
1. Ho diffuso le varie release presto e spesso (quasi mai a meno di dieci giorni di distanza; una volta al giorno nei periodi d’intenso lavoro).
2. Ho inserito nella lista dei beta chiunque mi avesse contattato riguardo fetchmail.
3. Ho mandato simpatici messaggi all’intera lista dei beta per annunciare ogni nuova release, incoraggiando la gente a partecipare.
4. E ho dato ascolto ai beta tester, ponendo loro domande sul design adottato e plaudendoli ogni volta che mi mandavano aggiustamenti e feedback.
Questi semplici accorgimenti produssero una ricompensa immediata. Fin dall’inizio del progetto, mi arrivavano report sui bug presenti di una qualità che qualunque sviluppatore avrebbe invidiato, spesso con buone soluzioni in attach. Ho ricevuto mail piene di critiche costruttive, lodi sperticate, suggerimenti intelligenti. Il che ci porta a:
10. Se tratti i beta tester come se fossero la risorsa più preziosa, replicheranno trasformandosi davvero nella risorsa più preziosa a disposizione.
Un’interessante caratteristica del successo di fetchmail risiede nell’ampiezza dell’elenco dei beta, i “fetchmail-friend”. Si è rapidamente raggiunta quota 249, con nuovi arrivi due o tre volte la settimana.
L’ultima revisione, fine Maggio 1997, ha rivelato che la lista andava perdendo membri, dopo aver raggiunto un massimo di 300 nominativi, e ciò per un motivo degno di nota. In parecchi mi hanno chiesto di essere rimossi perché fetchmail funzionava così bene che non c’era più alcun motivo di seguire il traffico della lista! Forse anche ciò fa parte del normale ciclo di vita di un progetto maturo in stile bazaar.