La cattedrale e il bazaar/Distribuire presto e spesso: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Conversione intestazione / correzione capitolo by Alebot |
Correzione pagina via bot |
||
Riga 1:
{{Qualità|avz=100%|data=20 luglio 2008|arg=Open Source}}{{IncludiIntestazione|sottotitolo=Distribuire presto e spesso|prec=../L'importanza di avere utenti|succ=../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
Il più importante di tali archivi,
Ma
Linus trattava gli utenti al pari di co-sviluppatori nella maniera più efficace possibile:
Line 19 ⟶ 14:
'''7. Distribuisci presto. Distribuisci spesso. E presta ascolto agli utenti.'''
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
Se, quindi, la rapida diffusione delle release e il pieno sfruttamento del medium Internet non erano casuali, bensì parti integranti delle visioni da genio
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
Linus puntava direttamente a massimizzare il numero di ore/uomo coinvolte nello sviluppo e nel debugging, rischiando perfino la possibile instabilità del codice e
'''8. Stabilita una base di beta-tester e co-sviluppatori sufficientemente ampia, ogni problema verrà rapidamente definito e qualcuno troverà la soluzione adeguata.'''
Line 37 ⟶ 32:
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ù
Nella concezione a bazaar,
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
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
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
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.
Quindi, dal punto di vista dello sviluppatore,
▲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.
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
▲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.
[[pt:A Catedral e o Bazar/IV]]
|