Rilasci precosi e frequenti sono una parte fondamentale del modello di sviluppo Linux. Molti sviluppatori (incluso me) pensavano che fosse una cattiva politica, perch� le versioni precoci sono per definizione versioni piene di bug e nessuno vuole mettere alla prova la pazinenza degi suoi utenti.
Questo convincimento ha portato la committenza
ad adottare lo stile di sviluppo da cattedrale.
Se l'obiettivo principale per gli utenti era vedere meno bug possibili,
perch� alora rilasciare una versione ogni sei mesi
e lavorare come cani a cercare gli errori
tra una cersione e l'altra? Il cuore C di Emacs
� stato sviluppato in questo modo.
La libreria Lisp, in effetti, non era (a causa del fatto che
c'erano archivi Lisp al di fuori del controllo della FSF)
un posto dove trovare versioni di codice nuovo e in sviluppo
indipendentemente dal ciclo delle versioni Emacs
[QR].
La pi� importante di queste, l'Ohio State elisp archive,
ha anticipato lo spirito e molte delle caratteristiche
degli odierni grandi archivi di Linux.
Ma pochi di noi pensavano a quello che stavano facendo, o
a quello che significava l'esistenza di quegli archivi
nel modello di sviluppo da cattedrale dell'FSF.
Ho fatto un serio tentativo nel 1992
per integrare formalmente il codice Ohio
nella libraria ufficiale Lisp Emacs.
Ho tovato problemi politici e non ho avuto successo.
Ma poco dopo, appena Linux si � reso visibile,
era chiaro che qualcosa di differente stava succedendo.
La politica di sviluppo aperto di Linux era l'opposto alla politica di costruzione delle cattedrali. Gli archivi Internet di Linux crescevano rapidamente, versioni multiple si succedevano. E tutto ci� non era guidato da una frequenza preordinata di versioni di core system.
Linux trattavo gli utenti come co-sviluppatori nel modo pi� efficiente:
7. Rilascia presto, Rilascia spesso. E ascolta i tuoi clienti.
L'innovazione non era tanto nell'aumento della frequenza dei rilasci, che incorporavano molti ritorni degli utenti, ma portarli a un livello i intnsit� che corrispondeva alla complessit� di ci� che veniva sviluppato. In quei primi tempi (1991) non era impossibile per lui rilasciare un nuovo kernel pi� di una volta al giorno! Ma poich� lui coltivava la sua base di co-sviluppatori e faceva leva su Internet per la collaborazione pi� di chiunque altro, questo funzionava.
Ma come funzionava? E si poteva copiare o stava solo nel genio unico di Linus Torvalds?
Non oensavo cos�. Certo, Linus � un hacker dannatamente fine. Quanti di noi potrebbero ingegnerizzare la produzione di un intero sistema operativo di qualit�, partendo da scratch?. Ma Linux non rappresenta uno splendido salto in avanti concettuale. Linus non � (o almeno non ancora) un genio innovativo della progettazione nel modo in cui lo sono Richard Stallman or James Gosling (of NeWS and Java). Piuttosto, Linus mi sembra un genio dell'ingegnerizzazione, con un sesto senso nell'evitare bugs e dead end e con il talento di trovare il minimo sforzo per andare dal punto A al punto B. Infatti dall'intero progetto di Linux traspira questa qualit� e rispecchia l'approccio essenzialmente conservativo e semplificativo di Linux.
Cos�, se i rilasci rapidi e l'utilizzo intensivo di Internet non erano casuali, ma parte integrante del genio di Linus entro il percorso del minimo sforzo, cosa stava massimizzando? Che sorpresa stava tirando fuori dalla macchina?
Mettiamola in questo modo: la domanda si risponde da sola. Linus teneva i suoi hacker/utenti sempre stimolati e ricompensati: stimolati dalla prospettiva (che soddisfa l'ego) di esser parte dell'azione, ricompensati dalla vista di un costante (anche quotidiano) migliormento del loro lavoro.
Linus aveva l'obiettivo di massimizzare il numero di persone-ora da gettare nel debug e nello sviluppo, anche con i rischi dell'instabilit� del codice e della delusione degli utenti in caso di problemi seri e difficili da trattare. Linus si comportava come se pensasse qualcosa del genere:
8. Data una base di co-sviluppatori e beta-tester sufficientemente grande, tutti i problemi possono essere caratterizzati rapidamente e risolti in modo ovvio da qualcuno.
O, meno formalmente, 'dato un numero sufficiente di occhi, tutti i problemi diventano piccoli' e io chiamo questa 'Legge di Linus'.
La mia formulazione originale era che tutti i problemi sono trasparenti per qualcuno. Linus ha dubitato che la persona che risolve il problema sia la stessa che lo caratterizza e dice: 'qualcuno trova il problema e qualcun altro lo capisce. E credo che trovarlo sia la sfida maggiore.' Ma il punto � che le due cose avvengono rapidamente.
Credo che questa sia la differenza fondamentale tra lo stile di costruzione di una cattedrale e di un bazaar. Nella mentalit� del costruttore di cattedrali i bug e i problemi di sviluppo sono un problema profondo, insidioso e rischioso. Ci vogliono mesi di ricerche per aver la convinzione di averli tolti tutti. Da qui i lunghi intervalli tra i rilasci e l'inevitabile fruztrazione davanti a versioni non perfette dopo una lunga attesa.
Mella mentalit� del bazaar si pensa che i bug siano fenomeni limitati --o, almeno, che diventano limitati molto in fretta se si espongono a migliaia di co-sviluppatori affamati e palpitanti ad ogni nuova versione. Cos� si rilascia spesso per avere pi� correzioni e, come beneficio collaterale, c'� meno da perdere se si fa una cavolata.
Questo �. Ed � abbastanza. Se la Legge di Linus � falsa, allora i sistemi complessi devono collassare sotto ilpeso di cattive interazioni non previste e di bug non scoperti. D'altra parte, se questo � vero, � sufficiente a spiegare la mancanza di bug in Linux e la sua durata di vita, che ormai si misura in mesi, quando non in anni.
Forse non dovrebbe essere una sopresa. I sociologi hanno scoperto anni fa che l'opinione media di un gruppo di osservatori ugualmente esperti (o egualmente ignoranti) � pi� affidabile dell'opinione di uno solo di essi scelto a caso. L'hanno chiamato 'effetto Delphi'. Sembra che Linus abbia dimostrato che si applica anche ai bug e ai sistemi operativi.
Il mio amico Jeff Dutky <dutky@wam.umd.edu> ha parafrasato la Legge di Linux in questo modo: 'il debugging � pararellizzabile'. Jeff osserva che sebbene il debugging richieda la comunicazione con qualche coordinatore, non richiede coordinamento tra gli operatori. E perci� non cade nella complessit� quadratica e nei costi che rendono problematica l'aggiunta di sviluppatori.
In pratica la perdita di efficienza teorica dovuta alla duplicazione del lavoro non pare si sia verificata nel mondo Linux. Probabilmente la politica 'rilascia presto e spesso' minimizza la duplicazione propagando rapidamente le soluzioni [JH].
Brooks (l'autore di `The Mythical Man-Month')
ha fatto un'osservazione a quella di Jeff:
`Il costo totale della manutenzione di un programma
ampiamente usato � tipicamente il 40% o pi�
del costo di sviluppo. Sorpredentemente questo costo
� fortemente condizionato dal numero di utenti
Pi� utenti trovano pi� bug (mia riflessione).
Pi� utenti trovano pi� bug perch� aggiungere utenti
aggiunge differenti modi di stressare il programma.
Questo effetto � amplificato se gli utenti
sono anche co-sviluppatori.
Ognuno affronta il compito in modo diverso,
per percezione, punto di vista e strumenti.
L'effetto Delphi sembra funzionare proprio per questo motivo.
Nel contesto specifico del debug, la variabilt�
riduce la duplicazione degli sforzi.
Cos� aggiungere beta-testers non � detto che riduca la complessit� del bug pi� profondo dal punto di vista dello sviluppatore, ma aumenta la probabilit� che il toolkit di qualcuno trovi il problema.
Inoltre Linux prende le sue precauzioni. Nel caso ci siano bug seri, le versioni del kernel di Linux sono numerati in modo tale che l'utente pu� scegliere se utilizzare la versione pi� recente definita stabile o sfidare i rischi per utilizzare le nuove potenzialit�. La possibilit� di scegliere � attraente. [HBS]