Viaggio nell’Open Source – 3: La cattedrale e il bazaar (2)

NOTA: Questo articolo è il secondo di una serie dedicata allo sviluppo del software Open Source. Il linguaggio spesso diretto e pratico vuole rispecchiare quello utilizzato da Eric S. Raymond nella sua opera “The Cathedral and the Bazaar”, rilasciato sotto Open Publication License 2.0 nel 2000; il contenuto non è perciò frutto della mente dell’autore, ma rappresenta l’elaborazione di un’altra opera, nella speranza che le circa 35 pagine del testo originale (inglese, ma è presente anche una traduzione italiana) siano oggetto di futura lettura da parte vostra.

6. Trattare i tuoi utenti da co-sviluppatori è la strada meno dura per il miglioramento rapido del codice ed un debugging reale.
“Un sacco di utenti sono anche hacker”; trattandoli come se fossero co-sviluppatori, anche se lo sono solo potenzialmente, li invoglierà a provare, riprovare, testare il codice per migliorarlo e/o trovare qualche malfunzionamento. Inoltre, poiché hanno una base di programmazione, potranno trovare le giuste soluzioni.

7. Rilascia presto. Rilascia spesso. E ascolta i tuoi clienti.
Non è la filosofia Open Source, ma un principio-guida lanciato e messo subito in pratica da Linus Torvalds, l’inventore del più imponente progetto Open Source al mondo: Linux. La sua innovazione principale è stata raggiungere un livello di intensità che rispecchiasse la complessità del progetto in sviluppo. Tanto più complesso è il software, tanto più deve essere frequente il rilascio di nuove versioni; gli utenti saranno stimolati e ricompensati (“stimolati dalla prospettiva di avere un pezzo dell’azione che soddisfi il proprio ego, ricompensati dalla vista di un costante miglioramento del proprio lavoro”).

8. Data una larga base di beta-tester e co-sviluppatori, quasi tutti i problemi saranno individuati in fretta e la soluzione sarà ovvia per qualcuno.
Questa è la “Legge di Linus”: qualcuno prima o poi individuerà il problema, qualcun altro lo capirà e troverà una soluzione. In ogni caso, sia la ricerca che la soluzione del problema tendono ad essere sempre più rapide. Secondo Torvalds, “qualcuno trova il problema e qualcun altro lo capisce. E continuerò a dire che trovarlo è la sfida più grande”.
Qui risiede la maggiore differenza tra cattedrale e bazaar: da un lato, la volontà di rilasciare qualcosa di perfettamente stabile, cercando soluzioni a problemi che ancora non si vedono; dall’altro, quando si presenta un problema, qualcuno troverà il modo di risolverlo. Rilasciare presto implica quindi ottenere più correzioni, e come side effect benefico “avrai meno da perdere se succede un casino”.
Inoltre, i software Open Source non risentono (o risentono in modo molto mitigato) del cosiddetto effetto Delphi: “l’opinione media di una massa di osservatori ugualmente esperti (o ugualmente ignoranti) fornisce previsioni appena più affidabili dell’opinione di uno di essi scelto a caso”. Ciò non avviene per i software Open Source perché gli osservatori sono auto-selezionati. E non solo: più utenti utilizzeranno il software in diversi modi possibili, ciascuno secondo le proprie esigenze, stressandolo così in modi diversi e scoprendo potenzialmente diversi errori.

9. Strutture dati intelligenti e codice stupido funzionano un sacco meglio dell’altra strada.
E’ più importante progettare per bene il programma e le sue strutture dati, in modo che il codice sia “stupido”, cioè intuitivo, auto-esplicativo, e tratti le strutture dati nel modo più semplice possibile. Il codice sarà quindi estremamente comprensibile all’utente, e ciò permetterà anche di trovare più errori, o di trovare più facilmente le correzioni per i detti errori.

10. Se tratti i tuoi beta-tester come se fossero la tua risorsa più preziosa, diventeranno la tua risorsa più preziosa.
E’ importante, anche dal punto di vista psicologico, che chi partecipa ad un progetto Open Source si senta in qualche modo importante. Potrà quindi fornire i report migliori che possa dare, o, come suggerisce l’autore, “report di una qualità per cui la maggior parte degli sviluppatori ucciderebbe”.

(continua…)