Alcuni utenti europei mi hanno costretto a inserire un'opzione per limitare il numero dei messaggi prelevati a ogni sessione (in modo da controllare i costi di collegamento, per via delle care tariffe imposte dalle aziende telefoniche nazionali). Ho resistito per parecchio tempo, e ancor'oggi non ne sono pienamente soddisfatto. Ma se scrivi programmi per tutto il mondo, devi dare ascolto ai tuoi clienti ? e ci? rimane valido anche se non ti ricompensano in denaro.

8. Qualche altra lezione da Fetchmail

Prima di tornare alle questioni generali sul ?software-engineering?, ? il caso di considerare qualche altro insegnamento specifico a seguito di quest'esperienza con fetchmail.

La sintassi del file rc include una serie di parole-chiave facoltative completamente ignorate dall'analizzatore. La sintassi in ?quasi-inglese? che si ottiene ? notevolmente pi? leggibile delle semplici coppie nome/valore che si rimangono dopo aver eliminato le prime.

Tutto ebbe inizio come un esperimento a notte fonda dopo essermi accorto di quante fossero le dichiarazioni del file rc che cominciavano ad assomigliare a un minilinguaggio imperativo. (Per lo stesso motivo ho modificato in ?poll? la parola-chiave ?server? del popclient originale).

Mi venne da pensare che sarebbe stato pi? facile usare qualcosa di simile all'inglese comune piuttosto che quel minilinguaggio imperativo. Ora, pur essendo il sottoscritto un convinto fautore della scuola di design del tipo ?trasformalo in linguaggio?, come esemplificato da Emacs, dall'HTML e da molti motori di database, generalmente non mi annovero tra i fan delle 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.

Non ? questa la ragione per cui generalmente io evito le sintassi in quasi-inglese; l'ho citata qui soltanto per demolirla. 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. (Come si pu? notare con evidenza nei linguaggi di interrogazione dei database di ?quarta generazione? e commerciali).

La sintassi di controllo di fetchmail riesce a evitare questi problemi perch? il dominio riservato al linguaggio ? estremamente limitato. Non si avvicina neppure lontanamente a un linguaggio di tipo generale; le cose che dice non sono affatto complicate, 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:

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

Un'altra lezione riguarda la sicurezza ?al buio?. Alcuni utenti di fetchmail mi avevano chiesto di modificare il software in modo che potesse conservare le password crittografate nel file rc, evitando cos? il rischio che qualche ficcanaso potesse scoprirle casualmente.

Non l'ho fatto perch? in realt? ci? non aggiunge alcuna protezione. Chiunque sia stato autorizzato a leggere il file rc, sarebbe comunque in grado di far girare fetchmail ? e se ? la password che cerca, saprebbe come decodificarla tirandola fuori dallo stesso codice di fetchmail.

Qualsiasi possibile codifica della password operata da .fetchmailrc, non avrebbe fatto altro che fornire un falso senso di sicurezza a quelli che non vogliono spremersi le meningi.
La regola generale ?:

17. Un sistema di sicurezza ? sicuro soltanto finch? ? segreto. Meglio diffidare degli pseudo-segreti.

9. Le pre-condizioni necessarie per lo stile bazaar

I primi lettori e revisori di questo scritto hanno ripetutamente sollevato domande sulle pre-condizioni necessarie per il successo dello sviluppo in stile bazaar, comprendendo con ci? sia le qualifiche del leader del progetto sia lo stato del codice al momento della diffusione pubblica e della nascita della possibile comunit? di co-sviluppatori.

? 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. Neppure io. 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 vennero diffusi pubblicamente, erano dotati di un design di base forte e attraente. Molte persone ritengono che il modello bazaar da me presentato 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. All'inizio ho fatto lo stesso con il popclient originario (anche se poi risult? molto diverso, assai pi? di quanto ? accaduto con Linux, fatte le debite proporzioni). ? 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 credo sia essenziale che il coordinatore possa produrre design eccezionali, ma ? assolutamente centrale che sia capace di riconoscere le buone idee progettuali degli altri.

Ci? appare evidente da entrambi i progetti di Linux e fetchmail. Pur non essendo un designer particolarmente originale (come discusso in precedenza), Linus ha dimostrato un ottima intuizione nel saper riconoscere il buon design per poi integrarlo nel kernel di Linux. Ed ho gi? descritto come l'idea pi? potente di fetchmail (SMTP forwarding) mi sia arrivata da qualcun altro.

I primi lettori di questo testo mi hanno fatto i complimenti mettendo a fuoco la mia propensione a sottovalutare l'originalit? del design nei progetti in stile bazaar perch? ne possiedo a volont? io stesso, e quindi la d? per scontata. In effetti, c'? qualcosa di vero in quest'affermazione; il design (in alternativa al codice o al debugging) ? la mia capacit? migliore.

Ma il problema con il fatto di essere bravi e originali nel design del software ? che tende a divenire un'abitudine ? prendi a fare cose carine e complicate quando invece dovresti tenerle semplici e robuste. Proprio per questa ragione mi sono crollati addosso vari progetti, ma con fetchmail sono stato attento a non farlo.

Credo insomma che il progetto di fetchmail abbia avuto successo in parte perch? ho limitato la mia tendenza a esser bravo; ci? va (almeno) contro l'essenzialit? dell'originalit? del design per il successo dei progetti a bazaar. Consideriamo Linux. Supponiamo che Linus Torvalds avesse cercato di tirar fuori le innovazioni fondamentali dal design del sistema operativo nel corso dello sviluppo; quali probabilit? esistono che il kernel risultante fosse ugualmente stabile ed efficace come quello che abbiamo ora?

? chiaro che occorrano capacit? di un certo livello per il design e il codice, ma personalmente mi aspetto, da quasi tutte le persone che pensano seriamente di lanciare un progetto bazaar, un livello superiore. 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 che ritengo 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. Da parte mia, io sono un estroverso energetico cui piace lavorare tra la folla, oltre ad avere qualcosa dei modi e dell'istinto del comico. Per far funzionare il modello a bazaar, aiuta parecchio essere in grado di esercitare almeno un po' di fascino sulla gente.

10. Il contesto sociale del software open source

? proprio vero: 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:

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

Cos? ? successo con Carl Harris e l'iniziale popclient, lo stesso con me e fetchmail. Ma ci? era chiaro da molto tempo. Il punto interessante che richiede attenzione, sulla base dell'evolversi di Linux e di fetchmail, ? il palcoscenico successivo ? l'evoluzione del software in presenza di una vasta e attiva comunit? di utenti e co-sviluppatori.

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.

Forse le scelte terminologiche operate da Weinberg hanno impedito alla sua analisi di ottenere il riconoscimento che merita ? viene da ridere al solo pensiero di riuscire a descrivere un hacker ?senza ego?. Ma ritengo la sua posizione stringente pi? che mai.

La storia di Unix avrebbe dovuto prepararci per quel che stiamo imparando da Linux (e per quello che io stesso ho verificato sperimentalmente su scala ridotta, copiando deliberatamente i metodi di Linus). Ovvero, pur rimandando la scrittura del codice un'attivit? prettamente solitaria, la questione davvero importante rimane la capacit? di sfruttare l'attenzione e la potenza dell'intera comunit?. Lo sviluppatore che impiega soltanto il proprio cervello su un progetto chiuso risulter? sempre dietro allo sviluppatore che sa come creare un contesto aperto, evolutivo dove sono centinaia le persone che si occupano dei miglioramenti e del debugging.

Ma una serie di elementi hanno impedito al mondo tradizionale Unix di applicare tale approccio. Tra questi, gli impedimenti legali connessi alle varie licenze, ai segreti e agli interessi commerciali. Altro impedimento (in retrospettiva), il fatto che allora Internet non fosse ancora abbastanza sviluppata.

Prima dell'attuale Internet super-diffusa, esistevano poche comunit? geograficamente compatte in cui veniva incoraggiata la cultura della programmazione ?senza ego? di Weinberg, dove uno sviluppatore poteva facilmente attirare molti altri co-sviluppatori in gamba. Il Bell Lab, il MIT, UC Berkeley ? queste le dimore dell'innovazione che rimangono leggendarie e potenti ancor'oggi.

Linux ? stato il primo progetto a proporre lo sforzo cosciente e coronato da successo verso l'utilizzo del mondo intero come fucina di talenti. Non ritengo una combinazione il fatto che la gestazione di Linux sia coincisa con la nascita del World Wide Web, e che Linux si sia lasciato alle spalle l'infanzia negli stessi anni 1993-1994 che hanno visto il decollo dei provider locali e l'esplosione dell'interesse di massa per Internet. Linus ? stata la prima persona ad aver imparato come giocare secondo le nuove regole rese possibili dalla diffusione di Internet.

Se ? vero che tale diffusione si ? rivelata necessaria per l'evoluzione del modello Linux, non credo per? possa ritenersi da sola una condizione sufficiente. Altro fattore vitale ? stata l'implementazione di un certo stile di leadership e di un insieme di usanze cooperative che hanno consentito agli sviluppatori di coinvolgere altri co-sviluppatori e ottenere il massimo possibile dal medium stesso.

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.

Pi? sopra mi sono riferito all'effetto Delfi come 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 cui ho preso parte a lungo ? 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, e alimentando 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. Con il progetto fetchmail ho dimostrato (pur se su scala pi? ridotta) che ? possibile duplicarne il metodo ottenendo buoni risultati. Forse l'ho perfino messo in atto un po' pi? coscientemente e sistematicamente di quanto non abbia fatto Linus.

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.

Sia il progetto di fetchmail che del kernel di Linux dimostrano come, dando la giusta ricompensa all'ego di molti altri hacker, un bravo sviluppatore/coordinatore possa 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 la mia controproposta alla Legge di Brooks:

19: 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.

Penso che il futuro del software open source apparterr? 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; credo piuttosto che 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. Sono davvero in pochi a potersi permettere di assumere le oltre duecento persone che hanno contribuito a fetchmail!

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 che n? io n? Linus facciamo), 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.

11. Ringraziamenti

Questo scritto ? stato migliorato grazie alle conversazioni avute con molte persone che hanno contribuito a trovarne i bug. Ringrazio in modo particolare Jeff Dutky , che mi ha suggerito la formulazione ?il debugging ? parallelizzabile? e che mi ha aiutato a svilupparne le analisi conseguenti. Grazie anche a Nancy Lebovitz per avermi suggerito di emulare Weinberg citando Kropotkin. Critiche costruttive sono venute anche da Joan Eslinger e Marty Franz della lista General Technics. Sono grato ai membri del PLUG, Philadelphia Linux User's Group, per essersi prestati come primo test pubblico per la versione iniziale di questo testo. Infine, i commenti iniziali di Linus Torvalds sono stati di grande aiuto e il suo sostegno molto incoraggiante.

12. Letture consigliate

Ho citato diversi passaggi dal classico di Frederick P. Brooks ?The Mythical Man-Month? perch?, in molti sensi, le sue introspezioni meritano ulteriori riflessioni. Raccomando di cuore l'edizione pubblicata in occasione del 25? Anniversario da Addison-Wesley (ISBN 0-201-83595-9), che contiene anche il suo saggio del 1986 ?No Silver Bullet?.

Questa nuova edizione contiene un'importante retrospettiva dei 20 anni successivi in cui Brooks ammette schiettamente come alcuni giudizi espressi nel testo originale non abbiano sostenuto la prova del tempo. Ho letto la retrospettiva dopo aver sostanzialmente completato questo scritto, e sono rimasto sorpreso nello scoprire che Brooks attribuisse pratiche da quasi-bazaar a Microsoft! (In realt?, per?, si ? poi visto come tale attribuzione fosse erronea. Nel 1998 abbiamo appreso dagli Halloween Documents come la comunit? interna dei programmatori di Microsoft risulti pesantemente balcanizzata, senz'alcuna possibilit? per quel tipo di accesso generale ai sorgenti tipico dello stile bazaar).

?The Psychology Of Computer Programming? di Gerald M. Weinberg (New York, Van Nostrand Reinhold 1971) presenta il concetto, malamente etichettato, di ?programmazione senza ego.? Pur essendo l'autore nient'affatto tra i primi a rendersi conto della futilit? del ?principio del comando?, probabilmente fu il primo a riconoscere e sostenere tale punto in particolare connessione con lo sviluppo del software.

Richard P. Gabriel, occupandosi della cultura Unix dell'era pre-Linux, sosteneva con riluttanza la superiorit? di un modello quasi-bazaar nel suo saggio del 1989: ?Lisp: Good News, Bad News, and How To Win Big?. Anche se per molti versi un po' datato, il testo ? ancora giustamente celebrato dai fan del Lisp (incluso il sottoscritto). Qualcuno mi ha ricordato che la sezione intitolata ?Worse Is Better? si propone quasi come un'anticipazione di Linux. L'articolo ? disponibile sul World Wide Web:
http://www.naggum.no/worse-is-better.html.

?Peopleware: Productive Projects and Teams? di De Marco e Lister (New York; Dorset House, 1987; ISBN 0-932633-05-6) ? una gemma sottovalutata che mi ha fatto piacere veder citata nella retrospettiva di Fred Brooks. Anche se poco di quanto scrivono gli autori pu? applicarsi direttamente alle comunit? Linux o open source, le loro riflessioni sulle condizioni necessarie per un lavoro creativo sono acute e valide per chiunque volesse provare ad applicare alcune delle virt? del modello bazaar in un contesto commerciale.

Devo infine ammettere d'aver inizialmente intitolato questo scritto ?La cattedrale e l'agor??, essendo quest'ultimo il termine greco per indicare un mercato all'aperto o un luogo d'incontro pubblico. Ci? per l'influenza dei saggi embrionali di Mark Miller e Eric Drexler ?Agoric systems? in cui venivano descritte le propriet? emergenti dell'ecologia computazionale di tipo quasi-commerciale. Tali scritti mi hanno preparato a riflettere con chiarezza sugli analoghi fenomeni nell'ambito della cultura open source quando Linux mi ci ha fatto sbattere il muso cinque anni dopo. Questi scritti sono reperibili sul Web: http://www.agorics.com/agorpapers.html.

13. Epilogo: Netscape si unisce al bazaar!

? proprio strano rendersi conto di aiutare lo sviluppo della storia...

Il 22 gennaio 1998, circa sette mesi dopo la prima pubblicazione di questo scritto, Netscape Communications, Inc. ha annunciato la diffusione pubblica dei codici sorgenti di Netscape Communicator. Fino al momento dell'annuncio, non avevo alcuna idea che ci? sarebbe mai potuto accadere.

Subito dopo l'annuncio, Eric Hahn, Executive Vice President e Chief Technology Officer di Netscape, mi ha inviato questa breve email: ?A nome di tutti noi di Netscape, voglio ringraziarti per averci aiutato innanzitutto a compiere questo passo. Il tuo pensiero e i tuoi scritti sono stati di fondamentale ispirazione per la nostra decisione.?

La settimana successiva (4 Febbraio 1998), sono arrivato in aereo nella Silicon Valley su invito di Netscape per partecipare a una giornata di incontri sulle strategie future con alcuni dei loro dirigenti esecutivi e il personale tecnico. Abbiamo progettato insieme la strategia e la licenza per la release del codice di Netscape, oltre ad aver buttato gi? ulteriori piani che speriamo alla fine possano avere un impatto positivo e profondo sulla comunit? open source. Al momento in cui scrivo, ? troppo presto per entrare nello specifico; ma entro qualche settimana dovrebbero essere noti maggiori dettagli.

Netscape sta per fornirci un test su larga scala e assai concreto del modello bazaar all'interno del mondo commerciale. La cultura dell'open source si trova di fronte a un pericolo; se l'operazione di Netscape non dovesse funzionare, il concetto stesso di open source potrebbe risultarne cos? screditato che il mondo commerciale non gli si avviciner? per un'altra decade.

D'altra parte, per?, si tratta di una spettacolare opportunit?. L'iniziale reazione a tale mossa in quel di Wall Street e altrove ? stata cautamente positiva. Ci ? stata data la possibilit? di provare cosa sappiamo fare. Se grazie a questa mossa Netscape sapr? riguadagnare una sostanziale quota di mercato, ci? potrebbe davvero innescare la rivoluzione attesa da lungo tempo nell'industria del software.

L'anno prossimo sar? un anno molto istruttivo e interessante.

14. Cronologia delle versioni e delle modifiche

$Id: cathedral-bazaar.sgml,v 1.42 22/11/1998 04:01:20 esr Exp $

Presentazione della 1.16 al Linux Kongress, 21 Maggio 1997.

Bibliografia aggiunta il 7 Luglio 1997 nella 1.20.

Aggiunto l'aneddoto sulla Perl Conference il 18 Novembre 1997 nella 1.27.

Modificato ?free software? in ?open source? il 9 Febbraio 1998 nella 1.29.

Aggiunto ?Epilogo: Netscape si unisce al bazaar!? il 10 Febbraio 1998 nella 1.31.

Eliminato il grafico di Paul Eggert sulla questione GPL-bazaar dopo vivaci discussioni con RMS il 28 Luglio 1998.

Aggiunta correzione su Brooks basata sugli Halloween Documents il 20 Novembre 1998 nella 1.40.

Altri livelli di revisione hanno incorporato minori aggiustamenti editoriali.

Traduzione italiana a cura di Bernardo Parrella berny@apogeonline.com, Giugno 1999

Per il testo originale inglese: http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar.html