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

NOTA: Questo articolo è il terzo 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.

11. La migliore alternativa ad avere buone idee è riconoscere le buone idee dei tuoi utenti. Talvolta quest’ultima opzione è migliore.
Riconoscere il lavoro altrui, anche intellettuale, è essenziale, specie quando non si riescono a trovare buone idee.

12. Spesso, le soluzioni più d’impatto ed innovative arrivano capendo che la tua idea del problema era sbagliata.
“Quando colpisci un muro nello sviluppo è spesso il momento di chiedersi non se hai la giusta risposta, ma se stai ponendo la giusta domanda. Forse il problema deve essere riformulato”. Questa indicazione non è valida solo nello sviluppo, ma in generale: se non si riesce ad abbattere l’ostacolo, aggirarlo può essere una buona soluzione.

13. “La perfezione (nel design) si raggiunge non quando non c’è più nulla da aggiungere, ma piuttosto quando non c’è più nulla da togliere”. (A. de Saint-Exupéry)
Il codice è tanto migliore quanto più è semplice, per svariati motivi: in primis, il debugging del codice risulta anch’esso più semplice, poiché la semplicità è sinonimo di comprensibilità. Inoltre, si ricalca il sempreverde principio del “tutto ciò che non c’è non si può rompere”. Senza tener conto che diventa più semplice scrivere nuovi pezzi di codice che si adattino a quanto già fatto.

14. Un qualunque tool dovrebbe essere utile nel modo atteso, ma un tool veramente grandissimo ti porta ad usi inaspettati.
Chiaramente, tali usi devono essere leciti.

15. Scrivendo software a livello gateway di qualunque tipo, sforzati al massimo di disturbare il flusso di dati il meno possibile — e non gettare mai alcuna informazione fino a che il ricevente non ti forza a farlo!
“Se stai scrivendo per il mondo, devi ascoltare i tuoi clienti – questo non cambia solo perché non ti stanno pagando in denaro”.
E’ essenziale, quando si manipolano dati altrui, non cancellare MAI nulla.

16. Quando il tuo linguaggio non è in nessun modo vicino ad essere Turing-completo, lo zucchero sintattico può essere tuo amico.
Lasciando da parte la definizione di “Turing-completo”, si può affermare che se un linguaggio è estremamente ristretto, può rendersi necessario “ammorbidirne” l’impatto mediante l’uso di costrutti superflui di per sé ma che lo rendano più usabile. Tali costrutti sono il cosiddetto “zucchero sintattico”.

17. Un sistema di sicurezza è sicuro solo quanto il suo segreto. Stai lontano dagli pseudo-segreti.
E’ uno dei pilastri della crittografia: un sistema crittografico è sicuro quando la sua chiave è sicura, e la segretezza dell’algoritmo non ne aumenta la sicurezza.

18. Per risolvere un problema interessante, inizia trovando un problema interessante per te.
Questo punto è diretta conseguenza del punto 1, partendo però dall’approccio di chi voglia diventare responsabile di un nuovo progetto Open. Se un problema è interessante per una persona, può esserlo per molte.

19. Quando un coordinatore dello sviluppo ha un mezzo di comunicazione almeno buono quanto Internet, e sa come guidare senza costringere, molte teste sono inevitabilmente meglio di una.
E’ essenziale non costringere i co-sviluppatori a fare qualcosa, ma guidarli perché tutti insieme si segua la stessa strada. Quando si ha questa capacità, e avendo a disposizione Internet (economico, rapido, mondiale), è conveniente non sviluppare il progetto da soli.

Si conclude qui l’analisi puntuale dello sviluppo Open Source. Nell’ultima puntata di questa serie si prenderà in considerazione tutto il processo e si trarranno le dovute conclusioni.

(continua…)