o per dirla come gli antichi: la vanità è il motore del mondo?
tra le riflessioni di weinberg, la legge di brooks e la legge di linus, il paradiso anarchico di internet qualche legge comunque sembra avercela.

nell'articolo di Eric S. Raymond (22/11/1998 ore 04:01:20) vengono messi a confronto due diversi stili di sviluppo, il modello “cattedrale” in voga in gran parte del mondo commerciale, opposto al modello “bazaar” del mondo Linux. il seguente post ne è il riassunto. si dimostrerà come tali modelli derivino da premesse divergenti sulla natura dell'attività di debugging del software, arrivando a stabilire la validità dell'esperienza di Linux riguardo l'affermazione “Con molti occhi puntati addosso, ogni bug diventa una bazzecola”, che suggerisce analogie produttive con altri sistemi di agenti indipendenti in grado di auto-correggersi.

Linux è sovversivo. Chi avrebbe potuto pensare negli anni novanta che un sistema operativo di livello mondiale sarebbe emerso come per magia dal lavoro part-time di diverse migliaia di hacker e sviluppatori sparsi sull'intero pianeta, collegati tra loro solo grazie ai tenui cavi di Internet?

lo stile di sviluppo proprio di Linus Torvalds – diffondere le release presto e spesso, delegare ad altri tutto il possibile, essere aperti fino alla promiscuità - lasciò tutti sorpresi. Nessuna cattedrale da costruire in silenzio e reverenza.

Piuttosto, la comunità Linux assomiglia ad un grande e confusionario bazaar, pullulante di progetti e approcci tra loro diversi (efficacemente simbolizzati dai siti contenenti l'archivio di Linux dove apparivano materiali prodotti da chiunque).
Un bazaar dal quale soltanto una serie di miracoli avrebbe potuto far emergere un sistema stabile e coerente.

la cosa più strana è che il mondo Linux non soltanto non cade preda della confusione più totale, ma al contrario va rafforzandosi sempre più a una velocità a malapena immaginabile per quanti costruiscono cattedrali. sono numerose le lezioni da imparare e da applicare allo sviluppo di software. eccole:

1. Ogni buon lavoro software inizia dalla frenesia personale di uno sviluppatore.
Forse ciò avrebbe dovuto risultare ovvio (è risaputo da tempo che “la necessità è la madre di tutte le invenzioni”), ma troppo spesso gli sviluppatori trascorrono le giornate impegnati a guadagnarsi da vivere con programmi di cui non hanno alcun bisogno e che non apprezzano. Ma non nel mondo Linux – il che spiega l'alta qualità media del software originato dalla comunità Linux.

2. I bravi programmatori sanno cosa scrivere. I migliori sanno cosa riscrivere (e riusare).
Linus Torvalds, per esempio, non ha mai cercato di riscrivere Linux da zero. È invece partito riutilizzando codici e idee riprese da Minix, piccolo sistema operativo per macchine 386 assai simile a Unix. Alla fine il codice Minix è scomparso oppure è stato completamente riscritto – ma per il tempo che è rimasto lì presente è servito come impalcatura per l'infante che sarebbe infine divenuto Linux.

3. “Preparati a buttarne via uno: dovrai farlo comunque.” (Fred Brooks, “The Mythical Man-Month”, Capitolo 11)
In altri termini, spesso non si riesce a comprendere davvero un problema fino alla prima volta in cui si prova a implementarne la soluzione. La seconda volta forse se ne sa abbastanza per riuscirci. Per arrivare alla soluzione, preparati a ricominciare almeno una volta.

4. Se hai l'atteggiamento giusto, saranno i problemi interessanti a trovare te.
In una cultura del software che incoraggia la condivisione del codice, non si tratta altro che la naturale evoluzione di un progetto.

5. Quando hai perso interesse in un programma, l'ultimo tuo dovere è passarlo a un successore competente.

a questo punto è importante avere molti utenti. Altro punto di forza della tradizione Unix, portato felicemente agli estremi da Linux, è che molti utenti sono essi stessi degli hacker. Ed essendo i sorgenti disponibili a tutti, posso diventare degli hacker molto efficaci. Qualcosa di tremendamente utile per ridurre il tempo necessario al debugging. Con un po' d'incoraggiamento, ogni utente è in grado di diagnosticare problemi, suggerire soluzioni, aiutare a migliorare il codice in maniera impensabile per una persona sola.

6. Trattare gli utenti come co-sviluppatori è la strada migliore per ottenere rapidi miglioramenti del codice e debugging efficace.
È facile sottovalutare la potenza di un simile effetto. In realtà un po' tutti gli abitanti del mondo open source erano soliti sottovalutare drasticamente il fatto che tale potenza crescesse di pari passo con il numero degli utenti e con la complessità del sistema. Finché Linus Torvalds ha mostrato le cose in maniera diversa.

In realtà la mossa più scaltra e consequenziale di Linus non è stata la costruzione del kernel di Linux in sé, bensì l'invenzione del modello di sviluppo di Linux. Quando persone esprimono questo pensiero in sua presenza, sorridendo Torvalds ripete con calma quel che va spesso affermando: “Praticamente sono una persona molto pigra cui piace prendersi il merito di quel che sono gli altri a fare.” Pigro come una volpe. Oppure, come avrebbe detto Robert Heinlein, troppo pigro per fallire.

Elemento centrale del processo di sviluppo di Linux è la rapida e frequente distribuzione delle varie release. La maggior parte degli sviluppatori 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.

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 si può duplicare, o tutto dipendeva esclusivamente dal genio di Linus Torvalds?
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 è (o forse non ancora) quel genio innovativo del design allo stesso modo, ad esempio, di Richard Stallman o James Gosling (di NeWS e Java).

Piuttosto, Linus sembra 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”: la così detta “Legge di Linus”.

La 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 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.

Jeff Dutky ha sottolineato come la Legge di Linus possa essere definita anche: “Il debugging è parallelizzabile”. èpossibile 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 Dutky: “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.

9. Meglio combinare una struttura dati intelligente e un codice non eccezionale che non il contrario.
è questo il principio generale che ogni programmatore dovrebbe tenere bene a mente, soprattutto lavorando con linguaggi come il C che non accettano facilmente gli inserimenti dinamici: Brooks, capitolo 9: “Mostrami [il codice] e nascondimi [la struttura dati], e io continuerò a essere disorientato. Mostrami [la struttura dati], e non avrò bisogno del [codice]; sarà del tutto ovvio.”
Per esser precisi, lui parlava di “diagrammi” e “tabelle”. Ma considerando il mutamento lessicale/culturale di questi trent'anni, il senso rimane invariato.

ecco quindi una possibile roadmap:

1. Ho diffuso le varie release presto e spesso (quasi mai a meno di dieci giorni di distanza; una volta al giorno nei periodi d'intenso lavoro).
2. Ho inserito nella lista dei beta chiunque mi avesse contattato riguardo fetchmail.
3. Ho mandato simpatici messaggi all'intera lista dei beta per annunciare ogni nuova release, incoraggiando la gente a partecipare.
4. E ho dato ascolto ai beta tester, ponendo loro domande sul design adottato e plaudendoli ogni volta che mi mandavano aggiustamenti e feedback.

Questi semplici accorgimenti producono una ricompensa immediata. Fin dall'inizio del progetto, in genere è possibile ottenere report sui bug presenti di una qualità che qualunque sviluppatore potrebbe invidiare, spesso con buone soluzioni in attach. si ricevono anche mail piene di critiche costruttive, lodi sperticate, suggerimenti intelligenti. Il che ci porta a:

10. Se tratti i beta tester come se fossero la risorsa più preziosa, replicheranno trasformandosi davvero nella risorsa più preziosa a disposizione.
L'ultime revisioni di un software open source, rivelano in genere che la lista va perdendo membri, dopo aver raggiunto un massimo nei nominativi, e ciò per un motivo degno di nota. In parecchi chiedono di essere rimossi perché il software funziona così bene che non c'era più alcun motivo di seguire il traffico della lista! ciò fa parte del normale ciclo di vita di un progetto maturo in stile bazaar.

11. La cosa migliore, dopo l'avere buone idee, è riconoscere quelle che arrivano dagli utenti. Qualche volta sono le migliori.
Fatto interessante, è facile scoprire che se sei completamente onesto e autocritico su quanto è dovuto agli altri, il mondo intero ti tratterà come se ogni bit di quell'invenzione fosse opera tua, mentre impari a considerare con sempre maggior modestia il tuo genio innato. Abbiamo visto come tutto ciò abbia funzionato a meraviglia con Linus!

12. Spesso le soluzioni più interessanti e innovative arrivano dal fatto di esserti reso conto come la tua concezione del problema fosse errata.
Morale? Non esitare a buttar via opzioni inanellate una sull'altra quando puoi rimpiazzarle senza perdere in efficienza.

Diceva Antoine de Saint-Exupéry:

13. “La perfezione (nel design) si ottiene non quando non c'è nient'altro da aggiungere, ma quando non c'è più niente da togliere."
Quando il codice diventa migliore e più semplice, allora vuol dire che va bene.

14. Ogni strumento dovrebbe rivelarsi utile nella maniera che ci si attende, ma uno strumento davvero ben fatto si presta ad utilizzi che non ci si aspetterebbe mai.

15. Quando si scrive del software per qualunque tipo di gateway, ci si assicuri di disturbare il meno possibile il flusso dei dati – e mai buttar via alcun dato a meno che il destinatario non ti ci costringa!

16. Ma se scrivi programmi per tutto il mondo, devi dare ascolto ai tuoi clienti ed alle loro differenti necessità – e ciò rimane valido anche se non ti ricompensano in denaro.

a volte, all'interno del software, può venire da pensare che potrebbe esser più facile usare qualcosa di simile all'inglese comune piuttosto che un minilinguaggio imperativo. Ora, pur essendo in tanti i convinti fautore della scuola di design del tipo “trasformalo in linguaggio”, come esemplificato da Emacs, dall'HTML e da molti motori di database, generalmente può rivelarsi utile una sintassi in “quasi-inglese”.

Tradizionalmente i programmatori hanno sempre avuto la tendenza a favorire sintassi molto precise e compatte, del tutto prive di ridondanza. Si tratta di un'eredità culturale del tempo in cui le risorse informatiche erano costose, così gli analizzatori dovevano risultare semplici ed economici al massimo grado. Allora l'inglese, con quel 50% di ridondanza, sembrava un modello poco appropriato.

Con l'attuale economicità dei cicli e delle strutture, la pulizia non dovrebbe essere un obiettivo in sé. Al giorno d'oggi è più importante che un linguaggio sia conveniente per gli esseri umani anziché economico per il computer.

Esistono comunque buoni motivi per procedere con cautela. Uno è rappresentato dai costi della complessità dell'analizzatore – non è il caso di aumentare tale complessità fino a raggiungere il punto in cui produrrà bug significativi e confusione nell'utente. Un'altra ragione è che cercare di rendere un linguaggio in quasi-inglese spesso richiede un tale aggiustamento linguistico che le somiglianze superficiali con il linguaggio naturale generino confusione tanto quanto l'eventuale sintassi tradizionale.

il dominio riservato al linguaggio va quindi tenuto estremamente limitato. Non deve avvicinarsi neppure lontanamente a un linguaggio di tipo generale; con espressioni che non sono affatto complicate, e che lasciando quindi poco spazio a potenziali confusioni, quando ci si sposta mentalmente tra un ristretto ambito d'inglese e il linguaggio di controllo vero e proprio.Credo qui si tratti di una lezione di più ampia portata:

17. Quando il linguaggio usato non è affatto vicino alla completezza di Turing, un po' di zucchero sintattico può esserti d'aiuto.

ed infine:

18. Un sistema di sicurezza è sicuro soltanto finché è segreto. Meglio diffidare degli pseudo-segreti.

È alquanto evidente come lo stile bazaar non consenta la scrittura del codice partendo da zero. Si possono fare test, trovare i bug, migliorare il tutto, ma sarebbe molto difficile dar vita dall'inizio a un progetto in modalità bazaar. Linus non lo ha fatto. La nascente comunità di sviluppatori deve avere qualcosa da far girare e con cui giocare.

Quando s'inizia a costruire la comunità, bisogna essere in grado di presentare una promessa plausibile. Non è detto che il programma debba funzionare particolarmente bene. Può anche essere crudo, pieno di bug, incompleto, scarsamente documentato. Non deve però mancare di convincere i potenziali co-sviluppatori che possa evolversi in qualcosa di veramente ben fatto nel prossimo futuro.

Quando Linux e fetchmail venne diffuso pubblicamente, era dotato di un design di base forte e attraente. Molte persone ritengono che il modello bazaar riveli correttamente questa fase critica, per poi da qui saltare alla conclusione che sia indispensabile un elevato livello di intuizione e bravura da parte di chi guida il progetto.

Ma Linus prese il suo design da Unix. È dunque vero che il leader/coordinatore di un progetto in stile bazaar debba possedere un eccezionale talento nel design? Oppure può cavarsela facendo leva sui talenti altrui?
Non è essenziale che il coordinatore possa produrre design eccezionali, ma è assolutamente centrale che sia capace di riconoscere le buone idee progettuali degli altri.

È chiaro che occorrano capacità di un certo livello per il design e il codice. Il mercato interno della reputazione della comunità open source esercita una sottile pressione sulle persone in modo che non si lancino dei progetti se non si è abbastanza competenti per seguirli. Finora quest'approccio ha funzionato piuttosto bene.

Esiste un altro tipo di capacità normalmente non associata allo sviluppo del software, importante al pari della bravura nel design per i progetti bazaar – anzi, forse ancora più importante. Il coordinatore o leader deve essere in grado di comunicare efficacemente con gli altri.
D'altronde è ovvio che per metter su una comunità di sviluppatori occorra attirare gente, coinvolgerli in quel che stai facendo, tenerli contenti per il lavoro che fanno. Lo sfrigolìo tecnico aiuta molto in questo senso, ma è ben lungi dall'esser tutto. È anche importante il tipo di personalità che proietti.

Non è certo una coincidenza che Linus sia un tipo simpatico, capace di piacere alla gente e di farsi aiutare. Per far funzionare il modello a bazaar, aiuta parecchio essere in grado di esercitare almeno un po' di fascino sulla gente.

le migliori operazioni di hacking nascono come soluzioni personali ai problemi quotidiani dell'autore, e si diffondono perchè si scopre che tali problemi sono comuni a molte altre persone. Questo ci riporta indietro alla questione della regola numero uno, riformulata forse in maniera più consona:

19. Per risolvere un problema interessante, comincia a trovare un problema che risvegli il tuo interesse.

In “The Mythical Man-Month”, Fred Brooks osserva come il tempo del programmatore non sia calcolabile; aggiungendo altri sviluppatori ad un progetto in ritardo, lo si fa tardare ancora di più. Secondo lui, i costi della complessità e delle comunicazioni di un progetto crescono esponenzialmente con il numero degli sviluppatori coinvolti, mentre il lavoro cresce soltanto in senso lineare. Quest'affermazione è nota come la “Legge di Brooks”, ed è considerata una verità pressoché universale. Ma se la Legge di Brooks fosse stata l'unica verità, Linux non sarebbe mai esistito.

Il classico di Gerald Weinberg “The Psychology Of Computer Programming” spiega in che modo, a posteriori, sia possibile individuare una vitale correzione alla tesi di Brooks. Parlando di “programmazione senza ego”, Weinberg fa notare come laddove gli sviluppatori non si dimostrano territoriali rispetto al proprio codice, incoraggiando altre persone a cercare bug e offrire miglioramenti, questi ultimi prendono corpo molto più in fretta che altrove.
Ma cosa s'intende esattamente con un certo stile di leadership e quali sarebbero queste usanze cooperative? Intanto, non ci si basa su relazioni di potere – e anche se tali dovessero essere, una leadership fondata sulla costrizione non produrrebbe i risultati che abbiamo visto. Weinberg cita al riguardo l'autobiografia dell'anarchico russo del XIX secolo Pyotr Alexeyvich Kropotkin, “Memorie di un rivoluzionario”:

“Essendo cresciuto in una famiglia che aveva dei servitori, sono entrato nella vita attiva, al pari di tutti i giovani della mia epoca, con un notevole carico di confidenza nella necessità di comandare, impartire ordini, rimproverare, punire. Ma quando, ancora giovane, dovetti gestire degli affari seri e avere a che fare con uomini [liberi], quando ogni errore avrebbe portato da solo a pesanti conseguenze, iniziai ad apprezzare la differenza tra l'agire basato sul principio del comando e della disciplina e l'agire basato sul principio della comprensione condivisa. Il primo funziona mirabilmente in una parata militare, ma non ha valore alcuno allorché si tratta della vita reale, dove ogni obiettivo può essere raggiunto soltanto tramite i duri sforzi di molte volontà convergenti.”

È precisamente i “duri sforzi di molte volontà convergenti” sono quel che un progetto come Linux richiede – e il “principio del comando” è veramente impossibile da praticare tra i volontari di quel paradiso anarchico chiamato Internet. Per operare e competere con efficacia, ogni hacker che voglia guidare progetti collettivi deve imparare come creare e dare energia a reali comunità d'interesse secondo le modalità vagamente suggerite dal “principio della comprensione” citato da Kropotkin. Deve imparare ad usare la Legge di Linus.

l'effetto Delfi potrebbe esser possibile spiegazione della Legge di Linus. Ma si potrebbero anche fare analogie forse più calzanti con i sistemi d'adattamento delle scienze biologiche ed economiche. Sotto molti aspetti il mondo Linux si comporta come un “free market” oppure come un sistema ecologico, una serie di agenti indipendenti che cercando di massimizzare quell'utilitarismo che nel processo va producendo un ordine spontaneo e in grado di auto-correggersi, più elaborato ed efficiente di quanto avrebbe potuto raggiungere qualsiasi pianificazione centralizzata. È dunque questo il luogo dove cercare il “principio della comprensione”.

La “funzione utilitaristica” che gli hacker di Linux vanno massimizzando non è economica in senso classico, quanto piuttosto espressione dell'intangibile, egoistica reputazione e soddisfazione che si guadagna tra gli altri hackers. (La loro motivazione potrebbe essere definita “altruista”, ma ciò significherebbe ignorare il fatto che a ben vedere l'altruismo stesso altro non è che una forma di soddisfazione egoistica). In realtà le culture del lavoro volontario che funzionano in tal modo non sono così rare; un'altra è quella dei fan della fantascienza, che al contrario del giro hacker riconosce esplicitamente come motore propulsore dietro tale attività volontaria proprio il cosiddetto “egoboo” (l'esaltazione della reputazione individuale tra gli altri fan).

Linus, posizionandosi con successo come filtro di un progetto nel quale il lavoro è in gran parte svolto da altri, ealimentando interesse nel progetto stesso finché non arriva ad auto-alimentarsi, ha dimostrato di aver acutamente fatto proprio il “principio della comprensione condivisa” di Kropotkin. Questa visione quasi-economica del mondo Linux ci consente di vedere come applicare tale comprensione.

È possibile ritenere il metodo di Linus come un modo per creare un mercato efficiente all'interno dell'egoboo – per collegare nel modo più sicuro possibile l'egoismo dei singoli hacker con quegli obiettivi difficili che possono essere raggiunti soltanto grazie alla concreta cooperazione collettiva.

Molte persone (soprattutto quanti politicamente diffidano del “free market”) immaginavano che una cultura di egoisti auto-referenziale si rivelasse frammentaria, territoriale, sprecona, segreta, ostile. Ma tale aspettativa viene chiaramente confutata (per fornire un solo esempio) dalla notevole varietà, qualità e profondità della documentazione relativa a Linux. Se è un dato di fatto che i programmatori odiano lavorare sulla documentazione, com'è allora che gli hacker di Linux ne producono di così copiosa? Evidentemente il “free market dell'egoboo” di Linux funziona meglio nella produzione di comportamenti virtuosi, diretti verso gli altri, rispetto a quei negozi dei produttori di software commerciale che si occupano della documentazione, avendo alle spalle massicci finanziamenti.

dando la giusta ricompensa all'ego di molti altri hacker, un bravo sviluppatore/coordinatore può utilizzare Internet per catturare i vantaggi dell'avere a disposizione molti co-sviluppatori senza che il progetto si frantumi in una confusione caotica. Ecco quindi una controproposta alla Legge di Brooks:

20: Stabilito che il coordinatore dello sviluppo abbia a disposizione un medium almeno altrettanto affidabile di Internet, e che sappia come svolgere il ruolo di leader senza costrizione, molte teste funzionano inevitabilmente meglio di una sola.

il futuro del software open source apparterrà allora sempre più alle persone che sanno come giocare al gioco di Linus, persone che si lasceranno alle spalle la cattedrale per entrare nel bazaar. Ciò non significa che non saranno più importanti le visioni e l'intelligenza individuali; piuttosto la punta avanzata del software open source apparterrà a quanti sapranno muovere da visioni e intelligenza individuali per poi amplificarle tramite l'effettiva costruzione di comunità volontarie d'interesse.

E forse ciò vale non soltanto per il futuro del software open source. Nessuno sviluppatore in “closed-source” potrà mai pareggiare la fucina di talenti che la comunità Linux è in grado di riunire per affrontare un problema.

Forse alla fine la cultura dell'open source trionferà non perchè la cooperazione sia moralmente giusta o perché il software “costretto” sia moralmente sbagliato (dando per scontato che si creda a quest'ultima affermazione, cosa chenemmeno Linus fa), ma semplicemente perché il mondo “closed-source” non è in grado di vincere la corsa agli armamenti dell'evoluzione contro quelle comunità open source capaci di affrontare un problema con tempi e capacità superiori di diversi ordini di grandezza.