La cattedrale e il bazaar/Distribuire presto e spesso
 |
Questo testo è completo. | |
Traduzione dall'inglese di Bernardo Parrella (1999)
| ◄ | L'importanza di avere utenti | Quando una rosa non è una rosa? | ► |
Elemento centrale del processo di sviluppo di Linux è la rapida e frequente distribuzione delle varie release. La maggior parte degli sviluppatori (incluso il sottoscritto) aveva sempre considerato negativa questa usanza per progetti appena più che minimi, poiché le versioni iniziali sono piene di bug quasi per definizione e non pareva il caso di far spazientire inutilmente gli utenti.
Tale opinione era rinforzata dalla generale aderenza allo stile di sviluppo della costruzione a cattedrale. Se l’obiettivo finale era quello di far vedere meno bug possibili agli utenti, allora conveniva distribuire una nuova release ogni sei mesi (o ancora meno frequentemente) e lavorare duramente sul debugging tra una release e l’altra. Fu seguendo questo processo che venne sviluppato il nucleo centrale in C di Emacs. Ma non fu così per la libreria Lisp –perché erano attivi archivi Lisp al di fuori del controllo della FSF, dove era invece possibile trovare versioni di codice nuovo e in fase di sviluppo indipendentemente dal ciclo di release di Emacs.
Il più importante di tali archivi, l’archivio elisp dell’Ohio State, anticipava lo spirito e molte delle caratteristiche tipiche dei grandi archivi su Linux di oggi. Ma pochi di noi si resero davvero conto di quel che stavamo facendo, o di come l’esistenza stessa di quell’archivio paresse rispondere ai problemi insiti nel modello di sviluppo della costruzione a cattedrale della FSF. Verso il 1992 ho provato a far confluire formalmente gran parte del codice dell’Ohio nella libreria ufficiale Lisp di Emacs. Mi sono trovato politicamente nei guai e di fronte a un chiaro insuccesso.
Ma l’anno seguente, mentre Linux diventava ampiamente visibile, fu chiaro come stesse accadendo qualcosa di assai diverso e più salutare. La policy di sviluppo aperto di Linus rappresentava l’esatto opposto della costruzione a cattedrale. Gli archivi di sunsite e tsx-11 stavano moltiplicandosi, le distribuzioni multiple andavano proliferando. E tutto ciò sotto la spinta della diffusione, con una frequenza mai vista prima, delle varie release.
Linus trattava gli utenti al pari di co-sviluppatori nella maniera più efficace possibile:
7. Distribuisci presto. Distribuisci spesso. E presta ascolto agli utenti.
L’innovazione introdotta da Linus non consisteva tanto nel seguire questa pratica (qualcosa di simile faceva parte da molto tempo della tradizione del mondo Unix), quanto piuttosto nel farla crescere a un tale livello d’intensità da raggiungere la medesima complessità del lavoro di programmazione che stava facendo. A quei tempi (intorno al 1991) non era raro che egli diffondesse versioni del nuovo kernel anche più di una volta al giorno! Qualcosa che poté funzionare grazie all’attenzione dedicata ai co-sviluppatori e all’ampio utilizzo di Internet come strumento di collaborazione.
Ma come funzionava? Era qualcosa che avrei potuto duplicare, o tutto dipendeva esclusivamente dal genio di Linus Torvalds?
No, non lo credevo. Certo, Linus è un gran bell’hacker (quanti di noi saprebbero realizzare per intero un sistema operativo di qualità?). Ma a livello concettuale Linux non rappresentava alcun significativo salto in avanti. Linus non è (almeno, non ancora) quel genio innovativo del design allo stesso modo, ad esempio, di Richard Stallman o James Gosling (di NeWS e Java). Piuttosto, Linus mi sembrava un genio dell’engineering, dotato di un sesto senso per evitare bug e strade senza uscita, oltre che di un ottimo fiuto per arrivare dal punto A al punto B con il minimo sforzo possibile. Non a caso l’intero design di Linux trasuda queste qualità e rispecchia l’approccio essenzialmente conservativo e semplificativo tipico di Linus.
Se, quindi, la rapida diffusione delle release e il pieno sfruttamento del medium Internet non erano casuali, bensì parti integranti delle visioni da genio dell’engineering di Linus lungo il cammino del minimo sforzo possibile, cos’era che stava amplificando? Cos’è che riusciva a tirar fuori da tutto questo gran daffare?
Messa così, la domanda si risponde da sola. Linus tendeva a stimolare e ricompensare costantemente i suoi hacker/utenti – stimolati dalla soddisfazione di sé per aver preso parte all’azione, ricompensati dalla vista dei miglioramenti costanti (perfino giornalieri) ottenuti nel loro lavoro.
Linus puntava direttamente a massimizzare il numero di ore/uomo coinvolte nello sviluppo e nel debugging, rischiando perfino la possibile instabilità del codice e l’estinguersi del contributo degli utenti qualora fosse risultato impossibile tener traccia di qualche serio bug. Linus si comportava seguendo una concezione più o meno riassumibile come segue:
8. Stabilita una base di beta-tester e co-sviluppatori sufficientemente ampia, ogni problema verrà rapidamente definito e qualcuno troverà la soluzione adeguata.
O, in modo meno formale, “Dato un numero sufficiente di occhi, tutti i bug vengono a galla”. Io la chiamo la “Legge di Linus”.
La mia formulazione originale era che ogni problema “diventerà trasparente per qualcuno”. Linus fece notare come la persona che si rende conto e risolve il problema non necessariamente né di norma è la stessa persona che per prima lo mette a fuoco. “Qualcuno scopre il problema,” dice Linus, “e qualcun altro lo comprende. E secondo me il compito più difficile è proprio trovarlo”. Ma il punto è che entrambe le cose tendono ad accadere piuttosto rapidamente.
Questa ritengo che sia la differenza fondamentale tra lo stile a cattedrale e quello a bazaar. Nel primo caso la visualizzazione dei problemi relativi a programmazione, bug e sviluppo costituiscono fenomeni dubbi, insidiosi, complessi. Servono mesi di scrutinio ravvicinato da parte di più d’uno per poi sentirsi sicuri di aver risolto tutti i problemi. Da qui i lunghi intervalli tra le release, e l’inevitabile delusione quando le versioni così a lungo attese si rivelano imperfette.
Nella concezione a bazaar, d’altra parte, si dà per scontato che generalmente i bug siano fenomeni marginali – o che almeno divengano rapidamente tali se esposti all’attenzione di migliaia di volenterosi co-sviluppatori che soppesano ogni nuova release. Ne consegue la rapidità di diffusione per ottenere maggiori correzioni, e come positivo effetto collaterale, c’è meno da perdere se viene fuori qualche toppa raffazzonata.
Tutto qui. E non è certo poco. Se la “Legge di Linus” è falsa, allora ogni sistema complesso tanto quanto il kernel Linux, ricavato grazie al lavoro collettivo delle molte mani che lo hanno messo insieme, a un certo punto avrebbe dovuto crollare sotto il peso di interazioni negative impreviste e di “profondi” bug non scoperti. Se invece è vera, allora è sufficiente a spiegare la relativa assenza di bug di Linux.
E forse ciò non dovrebbe rappresentare affatto una sorpresa. Qualche anno addietro sono stati i sociologi a scoprire che l’opinione media di un gruppo di osservatori equamente esperti (o equamente ignoranti) si rivela parametro assai più affidabile di quella di un solo osservatore scelto casualmente in quel gruppo. Si tratta del cosiddetto “effetto Delfi”. Ora sembra che Linus abbia dimostrato come ciò vada applicato anche all’operazione di debugging di un sistema operativo – ovvero che l’effetto Delfi è in grado di addomesticare la complessità della programmazione, persino la complessità del kernel di un sistema operativo.
Sono in debito con Jeff Dutky dutky@wam.umd.edu per aver sottolineato come la Legge di Linus possa essere definita anche: “Il debugging è parallelizzabile”. Jeff fa notare come nel corso dell’intero processo, pur richiedendo il coordinamento di uno sviluppatore che curi le comunicazioni tra quanti si occupano del debugging, questi ultimi invece non richiedono particolare coordinamento. In tal modo non si cade preda della notevole complessità e dei costi gestionali imposti dal coinvolgimento di nuovi sviluppatori.
In pratica, nel mondo Linux la perdita di efficienza a livello teorico, dovuta alla duplicazione di lavoro da parte di quanti seguono il debugging, non arriva quasi mai a rappresentare un problema. Uno degli effetti della policy “distribuire presto e spesso” è proprio quello di minimizzare tale duplicazione di lavoro propagando rapidamente le soluzioni giunte col feedback degli utenti.
Anche Brooks ha fatto un’osservazione su quanto sostenuto da Jeff: “Il costo totale per il mantenimento di un programma ampiamente utilizzato in genere viene valutato intorno al 40 per cento, o più, del costo dello sviluppo. Non senza sorpresa, tale costo viene notevolmente influenzato dal numero di utenti coinvolti. Maggiori sono questi ultimi, più bug si trovano.”
Ciò per via del fatto che con un maggior numero di utenti ci sono più modi differenti di verificare il programma. Un effetto amplificato quando costoro sono anche co-sviluppatori. Ciascuno affronta il compito della definizione dei bug con un approccio percettivo e analitico leggermente differente, una diversa angolazione per affrontare il problema. L’effetto Delfi pare funzionare esattamente sulla base di tali differenze. Nel contesto specifico del debugging, le variazioni tendono anche a ridurre la duplicazione degli sforzi impiegati.
Quindi, dal punto di vista dello sviluppatore, l’aggiunta di altri beta-tester può non ridurre la complessità del bug “più profondo” attualmente sotto studio, ma aumenta la probabilità che l’approccio di qualcuno consentirà il corretto inquadramento del problema, così che per questa persona il bug non apparirà altro che una bazzecola.
Inoltre, in caso di seri bug, le varie versioni del kernel di Linux sono numerate in modo tale che i potenziali utenti possano scegliere o di far girare l’ultima versione definita “stabile” oppure rischiare d’incappare in possibili bug pur di provare le nuove funzioni. Una tattica ancora non formalmente imitata dalla maggior parte di hacker Linux, ma che forse dovrebbe esserlo. Il fatto che entrambe le scelte siano disponibili le rende entrambe più attraenti.