|
Open Sources Per
accordo con la casa editrice originale americana e con gli autori,
parte di questi saggi vengono presentati sul nostro sito con una licenza
di tipo GPL (General
Publication License),
L'articolo "Il progetto GNU" di Richard Stallman è invece
pubblicato
autorizzando la copia integrale (verbatim copying) senza modifiche.
Sommario
di Eric S. Raymond
I Real Programmer di solito provenivano dai settori dell'ingegneria e della fisica. Indossavano calzini bianchi, camicie e cravatte in poliestere e lenti spesse, programmavano in linguaggio macchina, in FORTRAN e in un'altra mezza dozzina di linguaggi ormai dimenticati. Si tratta dei precursori della cultura hacker, dei ben poco celebrati protagonisti della sua preistoria. Dalla fine della Seconda Guerra Mondiale ai primi anni '70, nella grande era dei computer a linea di comando e dei mainframe chiamati "big iron", i Real Programmer dominarono la scena della cultura tecnica dei computer. Alcuni articoli del venerato folklore degli hacker risalgono proprio a quegli anni: la famosa storia di Mel (inclusa nel Jargon File), vari passi di Murphy's Laws (La legge di Murphy) e il manifesto caricatura tedesco "Blinkenlights" che ancora adorna molte sale di computer. Molte persone formatesi nella cultura "Real Programmer", rimasero attive anche negli anni '90. Si narra che Seymour Cray, progettista della linea di supercomputer Cray, abbia una volta trasportato un intero sistema operativo di sua concezione in un computer di sua creazione. Col sistema ottale e senza un errore. Funzionò tutto alla perfezione. Macho supremo dei Real Programmer. Su scala minore, Stan Kelly-Bootle, autore di The Devil's DP Dictionary (McGraw-Hill, 1981) e straordinario folklorista, programmò sul Manchester Mark I nel 1948, il primo computer digitale completamente operativo. Oggi scrive strisce tecnico-umoristiche per riviste di informatica, che spesso hanno il sapore di un energico e complice dialogo con la odierna cultura hacker. Altri, come David E. Lundstrom, hanno scritto aneddoti su quei primi anni (A Few Good Men From UNIVAC, 1987). Ciò che, comunque, ebbe origine dalla cultura "Real Programmer", è lo slancio innovativo che investì il computer interattivo, le università e le reti. Elementi che hanno avuto un ruolo fondamentale nella nascita di una tradizione tecnica che sarebbe sfociata nell'attuale cultura hacker Open Source.
La cultura informatica del MIT sembra essere stata la prima ad adottare il termine "hacker". Gli hacker della TMRC divennero il nucleo dell'Artificial Intelligenge Laboratory (Laboratorio di Intelligenza Artificiale) del MIT, il principale centro di ricerca AI (Intelligenza Artificiale) su scala mondiale, nei primi anni '80. La loro influenza si protrasse ben oltre il 1969, il primo anno di ARPAnet. ARPAnet è stata la prima rete transcontinentale di computer ad alta velocità. Ideata e realizzata dal Ministero della Difesa statunitense come esperimento nelle comunicazioni digitali, crebbe fino a diventare un collegamento tra centinaia di università, esponenti della difesa e laboratori di ricerca. Permise a tutti i ricercatori, ovunque essi si trovassero, di scambiarsi informazioni con velocità e flessibilità senza precedenti, dando un forte impulso allo sviluppo del lavoro di collaborazione e accelerando enormemente il ritmo e l'intensità del progresso tecnologico. Ma ARPAnet fece anche qualcos'altro. Le sue autostrade elettroniche misero in contatto gli hacker di tutti gli Stati Uniti e questi, finora isolati in sparuti gruppi, ognuno con la propria effimera cultura, si riscoprirono (o reinventarono) nelle vesti di vera a propria tribù di rete. Le prime intenzionali azioni di hackeraggio - i primi linguaggi caratteristici, le prime satire, i primi dibattiti autocoscienti sull'etica hacker - tutto questo si propagò su ARPAnet nei suoi primi anni di vita. (Basti come esempio la prima versione del Jargon File, datato 1973.) La cultura hacker mosse i primi passi nelle università connesse alla Rete, in particolar modo (ma non esclusivamente) nei loro dipartimenti di scienza informatica. Dal punto di vista culturale, l'AI (Intelligenza Artificiale) Lab del MIT è da considerarsi il primo tra laboratori di pari natura a partire dai tardi anni '60. Anche se istituti come il Laboratorio di Intelligenza Artificiale dell'Università di Stanford (SAIL) e, più tardi, l'Università Carnegie-Mellon (CMU), divennero in seguito quasi altrettanto importanti. Tutti costituivano fiorenti centri di scienza dell'informazione e ricerca sull'intelligenza artificiale. Tutti attiravano individui brillanti che contribuirono al grande sviluppo del mondo degli hacker, sia dal punto di vista tecnico che folkloristico. Per comprendere ciò che successe dopo, comunque, è necessario un ulteriore sguardo ai computer stessi, poiché sia la nascita del Laboratorio che il suo futuro declino furono fortemente influenzati dalle correnti di cambiamento nell'ambito della tecnologia informatica. Fin dai giorni del PDP-1, le sorti dell'hacking si intrecciarono alla serie di minicomputer PDP della Digital Equipment Corporation (DEC). La DEC aprì la strada a prodotti interattivi di stampo commerciale ed a sistemi operativi time-sharing. La flessibilità, la potenza e la relativa economicità di queste macchine, portarono molte università al loro acquisto. L'economicità dei sistemi time-sharing, costituì l'habitat ideale per lo sviluppo della cultura hacker e anche ARPAnet fu costituita, per la maggior parte della sua durata, da una rete di macchine DEC. La più importante fra queste fu il PDP-10 che fece la sua comparsa nel 1967. Essa rappresentò la macchina preferita dagli hacker per quasi quindici anni; il TOPS-10 (sistema operativo DEC per la macchina) e il MACRO-10 (suo assemblatore), sono ancora ricordati con passione nostalgica nell'ambito della cultura hacker. Il MIT, pur utilizzando lo stesso PDP-10, imboccò una strada lievemente diversa; rifiutò il software DEC del PDP-10 scegliendo di creare un proprio sistema operativo, il leggendario ITS. ITS stava per "Incompatible Timesharing System", (Sistema Time-Sharing Incompatibile), sigla che rendeva perfettamente l'idea delle intenzioni insite nel progetto: volevano fare a modo loro. Fortunatamente per tutti noi, la gente della MIT possedevano un grado di intelligenza in grado di contrastare la sua arroganza. L'ITS, strambo, eccentrico e a volte perfino pieno di difetti, portò tuttavia una brillante serie di innovazioni tecniche, e ancora detiene senza dubbio il record di sistema operativo time-sharing più a lungo utilizzato. Lo stesso ITS fu scritto in Assembler, ma molti progetti ITS furono scritti nel linguaggio LISP dell'AI. Il LISP si rivelò il più potente e flessibile linguaggio dell'epoca e, a distanza di vent'anni, si presenta ancora meglio congegnato rispetto a molti dei linguaggi odierni. Il LISP permise agli hacker di ITS di dare libero sfogo a tutta la loro creatività. Fu forse questa la formula del successo straordinario di questo linguaggio, che resta uno dei preferiti dagli hacker. Molte creazioni tecniche della cultura ITS, sopravvivono ancora oggi; l'editor Emacs è forse il più conosciuto. Così come molto del folklore ITS è tuttora "vivo" per gli hacker, come dimostra il Jargon File. Non si può certo dire che il SAIL e il CMU si fossero nel frattempo assopiti. Molti nuclei di hacker, sviluppatisi intorno al PDP-10 del SAIL, divennero più tardi figure chiave nel progresso dei personal computer e delle interfacce di software finestra/icona/mouse, come oggi le conosciamo. Gli hacker di CMU, dal canto loro, stavano portando avanti ciò che avrebbe dato vita alle prime applicazioni pratiche su larga scala di sistemi esperti e di robotica industriale. Un altro luogo che ha giocato un ruolo fondamentale per il progresso culturale fu lo Xerox PARC, il famoso Centro Ricerche di Palo Alto. Per più di un decennio, a partire dai primi anni '70 fino alla metà degli '80, il PARC produsse un'impressionante quantità di innovazioni hardware e software. Le moderne interfacce di software costituite da mouse, finestre e icone, videro la luce proprio in quell'ambito, ma anche le stampanti laser e la local area network (LAN). La serie PARC di macchine D, anticipò di un decennio i potenti personal computer degli anni '80. Purtroppo, questi profeti non ebbero né onori né gloria in seno alla loro azienda e presto diventò un'abitudine descrivere sarcasticamente il PARC come un luogo caratterizzato dallo sviluppo di brillanti idee per chiunque altro, tranne che per se stessi. L'influenza di queste menti sulla cultura hacker fu comunque a dir poco pervasiva. Le culture ARPAnet e PDP-10 crebbero in forza e varietà nell'arco degli anni '70. I programmi per le mailing list elettroniche, utilizzati fino ad allora per incoraggiare la cooperazione tra i diversi gruppi di interesse disseminati a quattro angoli del mondo, furono sempre più impiegati per scopi sociali e ricreativi. DARPA chiuse deliberatamente un occhio di fronte alle attività tecniche "non-autorizzate", ben comprendendo come queste spese extra fossero un piccolo prezzo da pagare rispetto all'effetto di convogliare l'attenzione di un'intera generazione di menti giovani e brillanti alla causa dell'informatica. Probabilmente, la più nota delle mailing list a sfondo "sociale" di ARPAnet fu la SF-LOVERS, per gli appassionati di fantascienza; basti pensare che ancora oggi essa continua ad esistere in "Internet", l'erede naturale e senza confini della rete ARPAnet. In questo scenario, si contano numerosi altri pionieri di questo stile di comunicazione che più tardi venne commercializzato in servizi time-sharing a pagamento come CompuServe, Genie e Prodigy.
Thompson si era trovato coinvolto nella fase di sviluppo di un Sistema Operativo Time-Sharing chiamato Multics, che divideva la propria discendenza con ITS. Multics costituì un importante banco di prova su come la complessità di un sistema operativo potesse essere celata fino a essere resa invisibile all'utente e perfino alla maggioranza dei programmatori. L'idea fu quella di rendere l'uso di Multics molto più semplice e programmabile in modo da permettere di operare anche dall'esterno. I Laboratori Bell si tirarono fuori dal progetto quando Multics iniziò a mostrare segni di crescita non giustificata (il sistema fu poi commercializzato da Honeywell, senza successo). Ken Thompson cominciò ad avere nostalgia dell'ambiente Multics, e pensò di giocare un po' miscelando alcune caratteristiche del sistema operativo naufragato con altre di sua concezione su un rottame di DEC PDP-7. Un altro hacker, di nome Dennis Ritchie, inventò un nuovo linguaggio chiamato "C", da usare con una versione Unix di Thompson ancora allo stato embrionale. Come Unix, C fu progettato per essere piacevole e facile da usare oltre che flessibile. L'interesse per questi strumenti non tardò a crescere nell'ambito dei Laboratori Bell, e subì un'impennata nel 1971 quando Thompson e Ritchie vinsero un appalto per produrre quello che oggi chiameremmo sistema di office-automation per uso interno. Ma Thompson e Ritchie avevano in mente qualcosa di ben più ambizioso. Per tradizione, i sistemi operativi erano stati, fino ad allora, scritti in Assembler in modo da ottenere la maggiore efficienza possibile dalle macchine host. Thompson e Ritchie furono tra i primi a capire che la tecnologia dell'hardware e dei compilatori aveva raggiunto un tale livello di maturità da poter scrivere in C un intero sistema operativo: nel 1974 l'intero ambiente operativo era regolarmente installato su numerose macchine di diversa tipologia. Si tratta di un evento senza precedenti e le implicazioni che ne derivarono furono enormi. Se davvero Unix poteva presentare la stessa interfaccia e le stesse funzionalità su macchine di diverso tipo, era sicuramente in grado di fungere da ambiente software comune per tutte. Gli utenti non avrebbero mai più dovuto pagare per nuovi software appositamente progettati ogni volta che una macchina diventava obsoleta. Gli hacker erano in grado di utilizzare gli stessi strumenti software da una macchina all'altra, piuttosto che dover reinventare l'equivalente di fuoco e ruota ogni volta. Oltre alla portabilità, Unix e C presentavano altri punti di forza. Entrambi si basavano sulla filosofia "Keep it simple, stupid!" letteralmente "Semplifica, stupido!". Un programmatore poteva senza difficoltà tenere a mente l'intera struttura logica di C (a differenza di molti altri linguaggi precedenti, ma anche successivi), e non dover più ricorrere continuamente ai manuali. Unix era un insieme flessibile di semplici strumenti che si mostravano complementari l'un l'altro. Questa combinazione si rivelò adatta per una vasta gamma di operazioni, incluse alcune completamente nuove, non previste in origine dagli stessi progettisti. La sua diffusione in AT&T fu estremamente rapida, a dispetto della mancanza di programmi di supporto formale. Entro il 1980, il suo uso si era già allargato a un gran numero di università e siti di ricerca informatica, e centinaia di hacker la consideravano come la propria casa. Le macchine da lavoro della prima cultura Unix furono i PDP-11 e il loro discendente fu il VAX. Ma, proprio per la sua caratteristica portabilità, Unix funzionava senza alcuna modifica su una vasta gamma di macchine che costituivano ARPAnet. Nessuno usava l'Assembler, i programmi creati in C erano facilmente utilizzabili su tutte queste macchine. Unix aveva persino una propria rete non certo di qualità eccelsa: Unix-to Unix Copy Protocol (UUCP), bassa velocità, poco affidabile ma economica. Due macchine Unix qualsiasi potevano scambiarsi posta elettronica point-to-point attraverso le ordinarie linee telefoniche. Questa funzionalità era parte integrante del sistema e non solo un'opzione. Le postazioni Unix cominciarono a formare una rete a se stante, e una cultura hacker iniziò a crescere al suo interno. È del 1980 la prima Usenet board, che sarebbe rapidamente diventata più grande di ARPAnet. ARPAnet stessa ospitò alcuni siti Unix. PDP-10 e le culture Unix e cominciarono a incontrarsi e fondersi, anche se, dapprima, senza grande successo. Gli hacker di PDP-10 consideravano la gente di Unix come una banda di principianti che utilizzava strumenti dall'aspetto primitivo, se paragonati alla squisita e perfino barocca complessità di LISP e ITS. "Coltelli di pietra e pelli d'orso!" brontolavano. Ecco allora che si delineò un terzo scenario. Il primo personal computer fu immesso sul mercato nel 1975. La Apple fu fondata nel 1977, e il suo progresso avvenne con impressionante rapidità negli anni che seguirono. Il potenziale dei microcomputer era ormai chiaro e attrasse inevitabilmente un'altra generazione di giovani e brillanti hacker. Il loro linguaggio era il BASIC, talmente primitivo che i partigiani del PDP-10, e gli aficionados di Unix lo considerarono subito indegno di qualsiasi considerazione.
Tra tutte queste, la cultura ITS poteva ancora rivendicare il posto d'onore. Ma sul Laboratorio si stavano addensando nubi minacciose. La tecnologia PDP-10 dipendente da ITS, cominciava a essere datata e il Laboratorio stesso era diviso in fazioni fin dai primi tentativi di commercializzazione della tecnologia AI. Alcune delle migliori menti del Laboratorio (e di SAIL e CMU), si erano lasciate attirare da lavori molto ben retribuiti presso società di nuova costituzione. Il colpo di grazia fu inferto nel 1983, quando DEC cancellò la sua adesione al PDP-10 per concentrarsi sulle linee VAX e PDP-11. ITS non aveva più un futuro. In virtù della sua scarsa portabilità, infatti, l'idea di trasportarlo da un hardware all'altro era impensabile per chiunque. La variante funzionante su Unix di Berkeley VAX, divenne il sistema prediletto dagli hacker, e chiunque avesse rivolto lo sguardo al futuro, si sarebbe reso conto di quanto rapidamente crescesse la potenza dei microcomputer e con quale velocità avrebbero spazzato via tutto quello che li aveva preceduti. Fu all'incirca in questo periodo che Levy scrisse Hackers. Una delle sue principali fonti di informazione fu Richard M. Stallman (inventore di Emacs), una figura chiave del Laboratorio e accanito oppositore della commercializzazione della tecnologia del Laboratorio. Stallman (meglio conosciuto con le sue iniziali e login name, RMS), creò la Free Software Foundation, dedicandosi alla produzione di free software di alta qualità. Levy lo elogiò quale "ultimo vero hacker", una descrizione che si rivelò fortunatamente errata. Il grandioso progetto di Stallman riassunse chiaramente la transizione che subì la cultura degli hacker nei primi anni '80: nel 1982 egli iniziò la costruzione di un intero clone di Unix, scritto in C e disponibile gratuitamente. Si può quindi dire che lo spirito e la tradizione di ITS furono preservati come parte importante della più nuova cultura hacker, incentrata su Unix e VAX. Sempre in quello stesso periodo, la tecnologia dei microchip e della local area network iniziarono a fare presa sul mondo degli hacker. Ethernet e il microchip Motorola 68000 costituirono una combinazione teoricamente molto potente e solo dopo numerosi tentativi si arrivò alla prima generazione di ciò che oggi conosciamo come workstation. Nel 1982, un gruppo di hacker Unix di Berkeley, fondò Sun Microsystems con la convinzione che Unix funzionante su un hardware con base 68000, relativamente economico, sarebbe stata la combinazione vincente per una grande varietà di applicazioni. La previsione si rivelò esatta e la loro intuizione definì il modello che l'intera industria avrebbe seguito. Sebbene i loro prezzi non erano ancora alla portata della maggior parte degli utenti, le workstation erano relativamente economiche per università e grandi aziende. Reti formate da questa nuova generazione di computer (uno per utente), sostituirono rapidamente gli ormai sorpassati VAX e altri sistemi time-sharing.
La classe di macchine workstation costruite da Sun e da altri, aprì nuovi orizzonti agli hacker. Queste erano concepite per realizzare grafica di livello professionale e trasferire e gestire dati condivisi attraverso una rete. Nel corso degli anni '80, il mondo degli hacker si mostrò attento alle sfide di software e strumenti per sfruttare al massimo queste caratteristiche. Il gruppo Unix di Berkeley sviluppò un supporto integrato per i protocolli ARPAnet che offriva una soluzione al problema delle reti favorendo un'ulteriore crescita di Internet. Numerosi furono i tentativi di semplificare l'uso degli strumenti di grafica delle workstation. Il sistema che prevalse fu l'X Window System. Uno dei fattori che determinarono il suo successo fu dato dalla disponibilità dei suoi sviluppatori a fornire gratuitamente i sorgenti, secondo l'etica hacker, e a distribuirli tramite Internet. La vittoria di X sui sistemi di grafica proprietari (incluso quello offerto dalla stessa Sun), fu un'importante messaggio di cambiamento che, pochi anni dopo, avrebbe profondamente influenzato lo stesso Unix. La rivalità tra ITS e Unix generava ancora qualche occasionale manifestazione di collera faziosa (per lo più proveniente dalla parte dei sostenitori dell'ex-ITS). L'ultima macchina ITS cessò comunque di funzionare per sempre nel 1990. I suoi partigiani si ritrovarono senza più un posto dove stare e furono in larga parte assimilati dalla cultura Unix non senza lamentele. Nell'ambito degli hacker della rete, la grande rivalità negli anni '80 era tra i sostenitori della versione Unix di Berkeley e quella di AT&T. Sono ancora oggi reperibili copie di un manifesto di quel periodo che riportava un combattente, in stile cartoon, con ali a forma di X, preso in prestito dal film Guerre Stellari, in fuga da una Death Star (stella morta) in esplosione contrassegnata dal logo AT&T. Gli hacker di Berkeley amavano vedersi come i ribelli contro i crudeli imperi aziendali. La versione Unix di AT&T non riuscì mai a competere sul mercato con il concorrente BDS/Sun, sebbene si aggiudicò la guerra degli standard. Nel 1990, le versioni AT&T e BSD divennero difficili da distinguere avendo l'una adottato molte innovazioni dell'altra e viceversa. Agli inizi degli anni '90, la tecnologia delle workstation del decennio precedente cominciava a vedersi seriamente minacciata da nuovi personal computer, a basso costo e dalle alte prestazioni, basati sul chip Intel 386 e i suoi discendenti. Per la prima volta, ogni singolo hacker poteva finalmente permettersi di disporre anche a casa di macchine paragonabili, per potenza e capacità di memoria, ai minicomputer di un decennio prima, macchine Unix in grado di supportare un ambiente di sviluppo completo e di comunicare con Internet. In questo nuovo scenario, il mondo MS-DOS rimase beatamente allo scuro degli sviluppi in corso. Nonostante le fila degli appassionati di microcomputer della prima ora si ingrandirono rapidamente fino a diventare una popolazione di hacker DOS e Mac di dimensioni ancora maggiori rispetto alla cultura "network nation", essi non riuscirono mai a sviluppare una cultura consapevole. Il ritmo dei cambiamenti era talmente veloce che ben cinquanta diverse culture tecniche nacquero e cessarono di esistere con la rapidità di una farfalla, senza mai raggiungere la stabilità necessaria allo sviluppo di un gergo, di un folklore e di una storia propri. L'assenza di una rete realmente pervasiva, paragonabile a UUCP o a Internet, non permise loro di diventare una network nation. Il crescere degli accessi a servizi commerciali online, come CompuServe e Genie, ma parallelamente la non diffusione in bundle di strumenti di sviluppo per sistemi operativi non-Unix, significava poco materiale su cui lavorare. Questa situazione impedì lo svilupparsi di una tradizione di collaborazione tra gli hacker. La corrente hacker più importante, (dis)organizzata intorno a Internet, e finora largamente identificata con la cultura tecnica di Unix, non era interessata ai servizi commerciali. I suoi adepti volevano solo strumenti migliori e più Internet, cose che l'economico PC a 32-bit promise di mettere alla portata di tutti. Ma dov'era il software? Le macchine Unix commerciali restavano comunque costose. Nei primi anni '90, numerose società fecero una prova vendendo porting di Unix BDS o AT&T per macchine PC. Il successo si rivelò elusivo, i prezzi non erano scesi di molto e (ancora peggio) non si ottenevano sorgenti modificabili e ridistribuibili per il proprio sistema operativo. Il tradizionale modello di software-business non stava affatto fornendo agli hacker ciò che volevano. Neanche con la Free Software Foundation la situazione migliorò. Lo sviluppo di HURD, il tanto sospirato kernel Unix gratuito per hacker promesso da RMS, rimase fermo per anni e non riuscì a produrre alcunché di utilizzabile fino al 1996 (sebbene dal 1990 la FSF avesse fornito quasi tutti gli altri complicati componenti di un sistema operativo simile a Unix). Ciò che dava davvero motivo di preoccupazione era che, con l'inizio degli anni '90, si cominciava a vedere con chiarezza come dieci anni di tentativi di commercializzare Unix stessero dopotutto fallendo. La promessa di Unix, di rendere portabili le cross-platform si perse tra mezza dozzina di versioni proprietarie di Unix. I detentori di Unix proprietario diedero prova di tanta lentezza e inettitudine nel campo del marketing, che Microsoft fu in grado di inglobare la maggior parte della loro fetta di mercato con la tecnologia del sistema operativo Windows, incredibilmente inferiore a quella Unix. Nei primi mesi del 1993, qualsiasi osservatore pessimista avrebbe avuto tutti i motivi per decretare l'imminente fine della storia di Unix e della fortuna della sua tribù di hacker, cosa tra l'altro predetta sin dai tardi anni '70 a intervalli regolari di 6 mesi. In quei giorni, era pensiero comune la fine dell'era del tecno-eroismo individuale e che l'industria del software e la nascente Internet sarebbero state dominate da colossi come Microsoft. La prima generazione di hacker Unix sembrava invecchiata e stanca (il gruppo di Ricerca della Scienza Informatica di Berkeley chiuse i battenti nel 1994). Il periodo non era tra i più felici. Fortunatamente, ci furono cose che sfuggirono all'attenzione della stampa specializzata e perfino alla maggior parte degli hacker, cose che avrebbero prodotto sviluppi positivi verso la fine del 1993 e l'inizio del 1994. In futuro, questa situazione avrebbe portato la cultura a imboccare una strada completamente nuova, disseminata di insperati successi.
Anche Linux aveva i suoi concorrenti. Nel 1991, contemporaneamente ai primi esperimenti di Linus Torvald, William e Lynne Jolitz stavano sperimentando il porting di Unix BSD sul 386. La maggior parte di coloro che paragonavano la tecnologia BSD agli sforzi iniziali di Linus, si aspettavano che i porting di BSD diventassero i più importanti free Unix su PC. La caratteristica fondamentale di Linux, tuttavia, non era tanto tecnica quanto sociologica. Fino allo sviluppo di Linux, era pensiero comune che qualsiasi software complicato come un sistema operativo, dovesse essere sviluppato in modo attentamente coordinato da un ristretto gruppo di persone ben collegate tra di loro. Questo modo di operare era, ed è tuttora, tipico sia del software commerciale che delle grosse cattedrali di freeware costruiti dalla Free Software Foundation negli anni '80; così come dei progetti freeBSD/netBSD/OpenBSD, che allargarono il campo di applicazione del porting originale 386BSD dei Jolitz. Linux si evolse in modo completamente differente. Fin quasi dalla sua nascita, fu casualmente "preda di hacking" da parte di un vasto numero di volontari collegati solo tramite Internet. La qualità fu mantenuta non da rigidi standard o autocrazia, ma dalla strategia semplice e naive di proporre settimanalmente delle idee e di ricevere opinioni in merito da centinaia di utenti ogni giorno, creando una sorta di rapida selezione darwiniana sulle modifiche introdotte dagli sviluppatori. Con stupore da parte di quasi tutti, il progetto funzionava piuttosto bene. Verso la fine del 1993, Linux fu in grado di competere per stabilità e affidabilità, con molti Unix commerciali, ospitando una grande quantità di software. Esso stava perfino cominciando ad attirare il porting di applicazioni software commerciali. Un effetto indiretto di questo sviluppo, fu lo spazzare via la maggior parte dei piccoli fornitori di Unix commerciali - la loro caduta fu anche determinata dalla mancanza di hacker e potenziali utenti ai quali vendere. Uno dei pochi sopravvissuti, BSDI (Berkeley System Design, Incorporated), fiorì offrendo sorgenti completi, con il suo Unix base BSD, e coltivando stretti legami con la comunità hacker. All'epoca tali sviluppi non furono pienamente rilevati dalle comunità hacker e non lo furono affatto al di fuori di essa. La tradizione hacker, a dispetto delle ripetute predizioni su una sua imminente fine, stava proprio iniziando a riorganizzare il mondo del software commerciale a propria immagine. Trascorsero ancora cinque anni prima che questa tendenza iniziasse a palesarsi.
Nel 1994, anno in cui il gruppo di sviluppo Unix di Berkeley chiuse ufficialmente i battenti, molte diverse versioni di free Unix (Linux e i discendenti del 386BSD) catalizzarono l'interesse degli hacker. Linux era distribuito su CD-ROM, e andava via come il pane. Alla fine del 1995, le maggiori aziende informatiche cominciarono a promuovere i propri hardware e software giocando la carta della loro grande compatibilità con Internet! Nella seconda metà degli anni '90, l'attività degli hacker si incentrò sullo sviluppo di Linux e sulla diffusione di massa di Internet. Il World Wide Web era riuscito a trasformare Internet in un mezzo di comunicazione di massa, e molti hacker degli anni '80 e '90, intrapresero l'attività di Internet Service Provider fornendo accesso a questo nuovo mondo. La diffusione di massa di Internet, aveva perfino portato la cultura hacker ad essere rispettata in quanto tale. Nel 1994 e 1995, l'attivismo hacker fece naufragare la proposta Clipper che avrebbe posto sotto il controllo del governo un metodo di codifica. Nel 1996, gli hacker si mobilitarono per sconfiggere il "Communications Decency Act" (CDA), e scongiurare il pericolo di censura su Internet. Con la vittoria sul CDA, si arriva ai giorni nostri, periodo in cui chi scrive diviene attore e non solo osservatore. Questa narrazione continua con "La vendetta degli Hacker".
Vent'anni di Unix a Berkeley Dalla AT&T alla ridistribuzione gratuita di Marshall Kirk McKusick
La storia dall'inizio A quel tempo, Berkeley, era dotata solo di grandi sistemi mainframe per l'elaborazione batch, così il primo acquisto fu un PDP-11/45, in grado di eseguire la versione 4 di Unix di allora. La Facoltà di Informatica di Berkeley, insieme a quelle di Matematica e di Statistica, fu in grado di acquistare un PDP-11/45. Nel gennaio 1974, una versione 4 su nastro magnetico fu disponibile e Unix fu installato dallo studente laureato Keith Standiford. Sebbene Ken Thompson a Purdue non fu coinvolto in questa installazione avvenuta a Berkeley, come era solito essere per la maggior parte dei sistemi fino a quel momento, la sua competenza fu subito necessaria per poter determinare la causa di svariati e strani crash del sistema. Siccome Berkeley aveva al tempo solo un modem a una velocità di trasmissione di 300-baud con accoppiatore acustico senza risposta automatica, Thompson chiamò Standiford nella sala macchine e gli fece collegare il telefono al modem; in questo modo Thompson fu in grado di collaudare in remoto - dal New Jersey - i problemi del software. La maggior parte dei problemi riscontrati erano dovuti all'incapacità del controller del disco di svolgere ricerche sovrapposte in modo affidabile, contrariamente a quanto asseriva la documentazione. L'11/45 di Berkley fu tra i primi sistemi nei quali Thompson si imbatté con due dischi sullo stesso controller! Il debugging remoto di Thompson fu il primo esempio di cooperazione che nacque tra Berkeley e Bell Labs. La buona volontà dei ricercatori dei laboratori di condividere il loro lavoro con Berkeley fu di valido aiuto nel rapido miglioramento dei software disponibili a Berkeley. Sebbene Unix fu presto ristabilito e reso funzionante, l'alleanza tra le facoltà di Informatica, Matematica e Statistica iniziò a incontrare ostacoli; Matematica e Statistica preferivano lavorare con il sistema RSTS della Digital Equipment Corporation (DEC). Dopo molte discussioni, fu raggiunto un compromesso nel quale ciascuna facoltà avrebbe usufruito di un turno di otto ore; Unix sarebbe stato messo in funzione per otto ore seguito da sedici ore di RSTS. Al fine di garantire l'equità, gli intervalli di tempo erano giornalmente a rotazione. Perciò, Unix funzionava dalle otto del mattino alle quattro del pomeriggio un giorno, dalle quattro pomeridiane a mezzanotte il giorno successivo, e da mezzanotte alle otto del mattino il terzo giorno. Nonostante questo orario bizzarro, gli studenti che frequentavano il corso su "I Sistemi Operativi" preferirono portare avanti i loro progetti con Unix piuttosto che con macchine per l'elaborazione di tipo batch. I professori Eugene Wong e Michael Stonebraker furono entrambi intralciati dalle restrizioni dell'ambiente a lotti, perciò il loro progetto di database INGRES fu tra i primi gruppi che passarono dalle macchine per l'elaborazione batch a un ambiente interattivo fornito da UNIX. Molto presto essi trovarono intollerabili i tempi corti e insoliti del 11/45, così nella primavera del 1974, comprarono un 11/40 in grado di eseguire la versione 5 appena disponibile. Con la loro prima distribuzione di INGRES nell'autunno del 1974, il progetto INGRES diventò il primo gruppo della facoltà di Informatica a distribuire il loro software. Diverse centinaia di nastri INGRES furono distribuiti nei sei anni successivi, aiutando a consolidare la reputazione di Berkeley per aver progettato e costruito sistemi efficaci. Anche con l'eliminazione del progetto INGRES dall'11/45, c'era ancora poco tempo disponibile per gli altri studenti. Per alleviare la carenza, i professori Michael Stonebraker e Bob Fabry, nel giugno del 1974, si prefissero di avere disponibili due 11/45 a fini didattici per la facoltà di Informatica. All'inizio del 1975 furono stanziati i fondi. All'incirca nello stesso periodo, la DEC presentò l'11/70, una macchina che pareva essere molto superiore all'11/45. I fondi per le due 11/45 furono ricongiunti al fine di comprare un solo 11/70 che fu consegnato nell'autunno del 1975. In concomitanza con l'arrivo del 11/70, Ken Thompson decise di prendersi un anno sabbatico come professore straordinario all'università californiana di Berkeley, la sua università. Thompson, insieme a Jeff Scriebman e Bob Kridle, caricò la versione più aggiornata di Unix, la 6, sull'11/70 appena implementato. In quello stesso autunno del 1975 spuntarono due studenti laureati fino ad allora sconosciuti, Bill Joy e Chuck Haley; entrambi mostrarono un immediato interesse per il nuovo sistema. All'inizio iniziarono a lavorare sul Pascal, il sistema che Thompson aveva messo insieme mentre bighellonava nella stanza dell'11/70. Essi ampliarono e migliorarono l'interprete del Pascal fino al punto che questo diventò il sistema di programmazione scelto per gli studenti, vista la sua eccezionale capacità di gestione degli errori, oltre a una compilazione veloce e un ottima velocità di esecuzione. Con la sostituzione del Modello 33 con telescrivente con il modello ADM-3 con videoterminale, Joy e Haley iniziarono a sentirsi intralciati dalle forzature dell'editor ed. Lavorando con un programma di utilità chiamato em che era stato fornito dal professor George Coulouris del Queen Mary's College di Londra, poterono continuare il lavoro fino alla creazione di un programma in grado di fornire editing di testo riga per riga. Con la partenza di Ken Thompson alla fine dell'estate del 1976, Joy e Haley iniziarono ad essere interessati nell'esplorazione del kernel dall'interno. Sotto l'occhio vigile di Schriebman, installarono prima quanto rifinito e migliorato cioè il nastro dei cinquanta cambiamenti fornito dai Bell Labs. Avendo imparato a maneggiare l'interno del file sorgente, suggerirono svariati piccoli incrementi al fine di semplificare e sveltire alcuni impedimenti del kernel.
La prima
distribuzione Con l'arrivo di alcuni terminali ADM-3a dotati di cursori posizionabili sullo schermo, Joy fu finalmente in grado di vedere a video quanto scriveva, portando quindi l'editing visuale a Berkeley. Ben presto si ritrovò con un dilemma. Come molto spesso succede nelle università con poche capacità economiche, i vecchi apparecchi non sono mai rimpiazzati tutti in una volta. Piuttosto che adottare un codice per ottimizzare gli aggiornamenti a differenti terminali, egli decise di unificare la gestione del video usando un piccolo interprete al fine di ridisegnare il video. Questo interprete veniva guidato con una descrizione delle caratteristiche del terminale, uno sforzo che portò finalmente al termcap. Per la metà del 1978, la distribuzione del software aveva chiaramente bisogno di essere aggiornata. Il sistema Pascal fu espressamente e marcatamente irrobustito grazie a feedback ricevuti dagli utenti finali sempre più in crescita; inoltre, era stato suddiviso in due passaggi così da poter essere eseguito sui PDP-11/34. Il risultato dell'aggiornamento fu La Seconda Berkeley Software Distribution, un nome che fu presto siglato con 2BSD. Insieme al sistema Pascal migliorato, furono anche inclusi vi e termcap per alcuni terminali. Ancora una volta Bill Joy mise in piedi da solo la distribuzione, rispondendo al telefono e incorporando i feedback degli utenti nel sistema. Poco dopo nell'anno successivo, quasi settantacinque nastri furono messi in circolo. Sebbene Joy si dedicò ad altri progetti l'anno successivo, la 2BSD continuò a espandersi. La versione finale di questa distribuzione - 2.11BSD - è un sistema completo usato da centinaia di PDP-11 ancora in funzione in svariati angoli del mondo.
VAX Unix Inizialmente sul VAX era caricato il sistema operativo VMS della DEC, ma la facoltà era abituata all'ambiente Unix e voleva continuare a usarlo. Così, appena dopo l'arrivo del VAX, Fateman riuscì ad avere - da John Reiser e Tom London dei Bell Labs - una copia 32/V di Unix sul VAX. Sebbene la 32/V forniva Unix versione 7 sul VAX, non si era in condizioni di sfruttare la capacità della memoria virtuale dell'hardware VAX. Come i suoi predecessori sul PDP-11, questo era un sistema interamente basato sulla funzione di swap. Per il gruppo Macsyma di Berkeley, la carenza di memoria virtuale significò che lo spazio di indirizzamento del processo era limitato dalle dimensioni della memoria fisica, inizialmente 1 megabyte sul nuovo VAX. Per alleggerire questo problema, Fateman contattò il professor Domenico Ferrari, un membro della facoltà di sistemistica a Berkeley, così da sondare la possibilità di far mettere a punto al suo gruppo un sistema di memoria virtuale per Unix. Ozalp Babaoglu, uno degli studenti del professor Ferrari, si mise all'opera per poter trovare un qualche modo di implementare un sistema per settare l'indirizzamento delle pagine di memoria che funzionasse sul VAX; il suo compito era complicato perché il VAX non era dotato di bit di riferimento. Appena Babaoglu raggiunse la fine della sua prima modifica dell'implementazione, si mise in contatto con Bill Joy per avere una mano nella comprensione delle complessità del kernel di Unix. Intrigato dall'approccio di Babaoglu, Joy si aggregò per aiutare a integrare il codice nel 32/V e poi collaborò anche per il successivo collaudo del programma. Sfortunatamente, Berkeley aveva solo un unico VAX, sia per lo sviluppo dei sistemi che per la produzione generale. Così, alcune settimane subito dopo le vacanze di Natale, la ben tollerante utenza si ritrovò collegata alternativamente sul 32/V e su Virtual VAX/Unix. Spesso il lavoro svolto su quest'ultimo sistema si arrestava improvvisamente, seguito, alcuni minuti più tardi, da un prompt del 32/V. Nel 1979, a gennaio, la maggioranza degli errori furono corretti, e il 32/V entrò a far parte del passato. Joy capì che il VAX a 32 bit avrebbe ben presto reso obsoleto il 16-bit PDP-11, e iniziò a trasferire il software della 2BSD al VAX. Mentre io e Peter Kessler trasferivamo il sistema Pascal, Joy fece la medesima cosa con l'editor ex e vi, la shell C, e una miriade di altri programmi più piccoli provenienti dalla 2BSD. Una distribuzione completa fu organizzata per la fine del 1979. Questa distribuzione comprendeva la memoria virtuale del kernel, le utilità standard 32/V, e le aggiunte dal 2BSD. Nel dicembre dello stesso anno, Joy rilasciò la prima copia di quasi un centinaio della 3BSD, la prima distribuzione VAX a Berkeley. La versione finale dei Bell Laboratories fu la 32/V; dopodiché tutte le versioni Unix di AT&T, inizialmente System III e dopo System V, furono gestite da diversi gruppi che spinsero commercialmente delle versioni stabili. Con la commercializzazione di Unix, i ricercatori di Bell Laboratories non furono più in grado di fungere da stanza di compensazione per la continuazione delle ricerche su Unix. Dato che i ricercatori continuavano a modificare il sistema Unix, essi si resero conto che avrebbero avuto bisogno di un'organizzazione che potesse produrre versioni di ricerca. A causa del suo originario coinvolgimento con Unix e il suo passato di distributrice di strumenti basati su Unix, Berkeley si ritrovò ben presto a ricoprire il ruolo che precedentemente era stato svolto dai laboratori Bell.
Il supporto di
DARPA La scelta di un solo rivenditore hardware era impraticabile a causa dei molteplici e differenti bisogni dei gruppi di ricerca e il non interesse di dipendere da un solo produttore. Perciò, i pianificatori di DARPA decisero che la soluzione migliore era di unificare il livello dei sistemi operativi. Dopo molte discussioni, Unix fu scelto come sistema standard vista la sua provata portabilità. Nell'autunno del 1979, Bob Fabry si mostrò disponibile verso l'idea di DARPA, di muoversi verso Unix scrivendo una proposta nella quale suggeriva a Berkeley di sviluppare una versione potenziata del 3BSD a uso dell'utenza del DARPA. Fabry portò una copia di questa sua proposta a un meeting di DARPA sull'elaborazione dell'immagine e la fornì anche ai fornitori del VLSI (integrazione a larghissima scala, ndt), oltre che ai rappresentanti di Bolt, Beranek e Newman - gli sviluppatori di ARPAnet (progetto di collegamento in rete di calcolatori di centri di ricerca del Ministero della Difesa e di università statunitensi, ndt). Vi erano delle riserve sul fatto che Berkeley fosse in grado di produrre un sistema funzionante; a ogni buon conto, l'uscita di 3BSD nel dicembre del 1979 dissipò ogni dubbio. Con la crescente buona reputazione subito dopo l'uscita del 3BSD, così da poter convalidare le sue aspirazioni, Bob Fabry fu in grado di stipulare un contratto di 18 mesi con DARPA all'inizio di aprile del 1980. Questo contratto prevedeva l'aggiunta di alcune caratteristiche richieste da DARPA. Sotto i migliori auspici di tale accordo, Bob Fabry creò un'organizzazione che fu battezzata come Computer Systems Research Group, siglata come CSRG. Immediatamente assunse Laura Tong per seguire il progetto amministrativo. Fabry pose la sua attenzione sulla ricerca di un capo progetto in grado di seguire lo sviluppo del software. Fabry ritenne che, dato che Joy aveva appena passato l'esame di ammissione per il conseguimento del Ph.D (dottorato di ricerca), si sarebbe concentrato sul conseguimento della laurea piuttosto che ricoprire una posizione di sviluppatore di software. Ma Joy aveva altri piani. Una notte, all'inizio di marzo, chiamò Fabry a casa dimostrandosi interessato nel prendersi l'incarico di seguire l'ulteriore sviluppo di Unix. Nonostante la sorpresa, Fabry non ci mise molto ad accettare questa offerta. Il progetto iniziò immediatamente. Tong strutturò un sistema di distribuzione che potesse gestire un maggior volume di ordini rispetto alla precedente distribuzione organizzata da Joy. Fabry fu in grado di coordinare insieme a Bob Guffy alla AT&T, unitamente ai legali, all'università di california, l'uscita ufficiale di Unix con termini che fossero accettati da tutti. Joy introdusse il "job control" da parte di Jim Kulp e aggiunse il riavvio automatico, un gestore di file a blocco da 1K, e ulteriore supporto alla macchina VAX più recente: la VAX-11/750. Per l'ottobre del 1980, una distribuzione impeccabile che includeva anche il compilatore Pascal, il sistema di Franz Lisp, e un sistema di gestione posta rinnovato, che fu messo in circolazione come 4BSD. Durante la sua vita, della durata di nove mesi, furono distribuite circa 150 copie. Gli accordi di licenza erano su una base per-istituzione piuttosto che per-macchina; in questo modo la distribuzione raggiunse circa 500 macchine. Con la distribuzione sempre più ampliata e la visibilità di Berkeley Unix, alcuni critici iniziarono a emergere. David Kashtan del Stanford Research Institute produsse una relazione nella quale descriveva i risultati dei benchmark che provò sia sul VMS che sul Berkeley Unix. Questi benchmark rilevarono seri problemi di prestazioni con il sistema Unix sul VAX. Mettendo da parte i suoi piani futuri per alcuni mesi, Joy iniziò sistematicamente a mettere a punto il kernel. In poche settimane ebbe pronto un rapporto scritto quale controprova che dimostrava che i benchmark di Kashtan potevano essere adattati sia a Unix che a VMS. Piuttosto che continuare a caricare il 4BSD, il sistema appena approntato, con l'aggiunta del codice di autoconfigurazione di Robert Elz, uscì come 4.1BSD nel giugno del 1981. Nei suoi due anni di vita ne furono rilasciate circa 400 copie. L'intento originario era stato quello di definirla come la versione 5BSD; ad ogni modo, vi furono delle obiezioni da parte di AT&T sul fatto che avrebbe potuto crearsi della confusione tra i clienti con l'uscita commerciale di Unix, System V, e un'ulteriore uscita a Berkeley denominata 5BSD. Così, con l'intento di risolvere la questione, Berkeley si mostrò d'accordo nel cambiare la serie di nomi per le uscite a venire lasciando valido 4BSD e semplicemente incrementando il numero iniziale con un decimale.
4.2BSD Basandosi sui bisogni del gruppo DARPA, furono stabiliti gli obiettivi e il lavoro iniziò in modo da poter definire le modifiche da apportare al sistema. In particolare, il nuovo sistema avrebbe dovuto includere un file system più veloce che avrebbe aumentato le sue prestazioni fino a raggiungere quelle permesse dai dischi, supportare processi che richiedevano maggiore spazio di indirizzamento, fornire una comunicazione tra i processi flessibile e facilitata, così da mettere in grado i ricercatori di fare il loro lavoro su sistemi distribuiti; e inoltre, avrebbe integrato il supporto di rete così che le macchine fossero in grado di far girare il nuovo sistema partecipando con facilità all'ARPAnet. Al fine di prestare assistenza nella definizione del nuovo sistema, Duane Adams, il supervisore di Berkeley del contratto presso DARPA, formò un gruppo conosciuto come "steering committee" per coadiuvare il lavoro di design assicurandosi che i bisogni del gruppo di ricerca fossero tenuti in conto. Questo comitato si riunì due volte l'anno, tra l'aprile del 1981 e giugno del 1983. Vi facevano parte tra gli altri Bob Fabry, Bill Joy e Sam Leffler dell'università californiana di Berkeley; Alan Nemeth e Rob Gurwitz di Bolt, Beranek, e Newman; Dennis Ritchie dei Bell Laboratories; Keith Lantz della Stanford University; Rick Rashid della Carnegie-Mellon University; Bert Halstead dello Massachusetts Institute of Technology; Dan Lynch de "The Information Science Institute"; Duane Adams e Bob Baker di DARPA; e Jerry Popek dell'Università Californiana di Los Angeles. Iniziate nel 1984, queste riunioni furono soppiantate con seminari che si allargavano accogliendo molte più persone. Un documento iniziale che proponeva facilitazioni da apportare al nuovo sistema fu messo in circolo tra i membri del steering committee e altre persone al di fuori di Berkeley nel luglio del 1981, facendo nascere dibattiti prolissi. Nell'estate del 1981, mi aggregai al CSRG e misi in opera l'implementazione del nuovo file system. Durante l'estate Joy si concentrò sull'implementazione di un prototipo delle utilità di comunicazione tra processi. Nell'autunno dello stesso anno, Sam Leffler si unì al CSRG come membro dello staff a tempo pieno, lavorando con Bill Joy. Quando Rob Gurwitz rese disponibile una prima implementazione del protocollo TCP/IP a Berkeley, Joy lo integrò nel sistema e ne calibrò le prestazioni. Durante questo lavoro, fu chiaro a Joy e Leffler che il nuovo sistema richiedeva un supporto superiore a quello standard previsto dai protocolli della rete DARPA. Quindi, fu ridisegnata la struttura interna del software, ridefinendo le interfacce in modo tale che potessero essere utilizzati simultaneamente più protocolli di rete. Appena terminata la ristrutturazione interna e integrati i protocolli TCP/IP con i miglioramenti derivanti dal prototipo IPC, furono create diverse semplici applicazioni per poter fornire agli utenti locali un accesso alle risorse remote. Questi programmi, rcp, rsh, rlogin e rwho furono intesi come strumenti temporanei che potevano essere poi rimpiazzati da comandi più ragionevoli (così si spiega l'uso della "r" come prefisso). Questo sistema, chiamato 4.1a, fu distribuito la prima volta nell'aprile del 1982 per un uso limitato; non era mai stato previsto per una distribuzione più ampia, sebbene copie "piratate" del sistema proliferavano nell'impaziente attesa del edizione 4.2. Il sistema 4.1a si rivelò essere obsoleto ancora prima di raggiungere il suo compimento. Comunque, il feedback degli utenti forniva utili informazioni che vennero usate per creare una proposta riveduta per un nuovo sistema chiamato 4.2BSD System Manual. Questo documento fu messo in circolazione nel febbraio 1982 e conteneva una descrizione concisa delle interfacce utente proposte per rendere più agevole il sistema che si sarebbe chiamato 4.2BSD. In concomitanza con lo sviluppo del 4.1a, ho completato io stesso l'implementazione del nuovo, e per il mese di giugno 1982, l'avevo pienamente integrato nel kernel del 4.1a. Il sistema risultante fu chiamato 4.1b e girava solo a Berkeley su poche macchine selezionate. Joy presagiva che con delle imminenti variazioni significative da apportare al sistema, era meglio evitare anche una distribuzione locale, soprattutto visto che sarebbe stato necessario che il file system su ciascuna macchina venisse scaricato e reinstallato per convertirlo da 4.1a a 4.1b. Una volta che il file system si dimostrò essere affidabile, Leffler procedette con l'aggiunta di un nuovo file system collegato con il sistema di comunicazione, mentre Joy era al lavoro per revisionare i servizi di comunicazione tra processi. Nella primavera inoltrata del 1982, Joy annunciò che stava per approdare alla Sun Microsystems. Durante l'estate, suddivise il suo tempo tra Sun e Berkeley, utilizzando la maggioranza del suo tempo per raffinare le sue revisioni ai servizi di comunicazione tra processi e riorganizzando i sorgenti del kernel di Unix al fine di isolare porzioni legate alla macchina. Con la partenza di Joy, Leffler assunse la responsabilità del completamento del progetto. Alcuni termini erano già stati fissati e l'uscita era stata promessa a DARPA per la primavera del 1983. Dati i tempi ristretti, il lavoro restante per il completamento della versione fu valutato e vennero stabilite delle priorità. In particolare, le migliorie alla memoria virtuale e la progettazione di parti più sofisticate di comunicazione tra processi furono relegate tra le ultime priorità (e più tardi accantonate del tutto). In più, con l'implementazione da quasi un anno e con l'alzarsi delle aspettative dell'utenza di Unix, si decise di mettere insieme una versione intermedia per tenersi stretti gli utenti fino a quando il sistema finale sarebbe stato completato. Questo sistema, chiamato 4.1c, fu distribuito nell'aprile del 1983; molti rivenditori usarono questa versione per predisporre il porting sul proprio hardware necessario per la 4.2. Pauline Schwartz fu assunta al fine di prendersi carico di tutti gli oneri relativi alla distribuzione cominciando con la versione 4.1c. Nel giugno 1983, Bob Fabry passò il controllo della parte amministrativa del CSRG ai professori Domenico Ferrari e Susan Graham, così da poter iniziare il suo anno sabbatico liberandosi dalla marcia frenetica sostenuta per tutti i quattro anni precedenti. Leffler procedette con il completamento del sistema, implementando nuovi accorgimenti per i segnali, facendo aggiunte al supporto di rete, rifacendo il sistema unico di ingresso e uscita, così da semplificare il processo di installazione, integrando le limitazioni dei dischi con l'aiuto di Robert Elz, aggiornando tutta la documentazione, ed evidenziando tutti i difetti della versione 4.1c. Nell'agosto del 1983, il sistema 4.2BSD era pronto. Quando Leffler lasciò Berkeley per Lucasfilm dopo aver completato il 4.2, fu rimpiazzato da Mike Karels. La precedente esperienza di Karel con la distribuzione del software 2.9BSD PDP-11, rappresentò il supporto migliore per il suo nuovo lavoro. Dopo aver terminato il mio Ph.D. nel dicembre del 1984, raggiunsi a tempo pieno Mike Karels al CSRG. La popolarità del 4.2BSD fu impressionante: in un anno e mezzo furono emesse più di 1.000 licenze. Di conseguenza, furono immesse sul mercato più copie della versione 4.2BSD da sola, che non tutto quanto il software distribuito da Berkeley fino a quel momento. La maggior parte dei rivenditori di Unix ordinarono il sistema 4.2BSD, piuttosto che il sistema commerciale V della AT&T. La ragione di ciò fu che il System V non aveva né il servizio di comunicazione dati, né il file system Berkeley Fast. L'uscita di Unix da parte della BSD fu in grado di mantenere il posizionamento sul mercato per alcuni anni, prima di ritornare alle origini. Sia il servizio di comunicazione dati e altri miglioramenti del 4.2BSD, furono integrati nel System V, ma i rivenditori solitamente ritornarono al primo. Ad ogni modo, più avanti i miglioramenti messi a punto dal BSD continuarono comunque a essere incorporati nel System V.
4.3BSD Dopo due anni di lavoro sulla messa a punto e sulla rifinitura del codice di rete, decidemmo di fare un annuncio alla conferenza Usenix nel giugno 1985, anticipando l'uscita del 4.3BSD entro l'estate. Comunque, i nostri piani furono interrotti brutalmente da quelli della BBN. Essi molto correttamente sottolinearono che non avevamo mai aggiornato la 4.2BSD con la versione finale del loro codice di rete. Piuttosto, stavamo ancora usando il prototipo iniziale che loro stessi ci avevano fornito molti anni prima. Si lamentarono con il DARPA che a Berkeley fu implementata un'interfaccia mentre BBN avrebbe dovuto implementare il protocollo, quindi Berkeley avrebbe dovuto rimpiazzare il codice TCP/IP sul 4.3BSD con l'implementazione della BBN. Mike Karels ottenne il codice della BBN; fece una valutazione del lavoro che era stato fatto a partire dal momento in cui il prototipo fu dato in mano a quelli di Berkeley. Fu lui che decise che il piano migliore era di incorporare le idee più valide riscontrabili nel codice BBN nel codice di base di Berkeley. La ragione per la quale si conservò il codice di base di Berkeley era che questo fu testato considerevolmente e poi molto migliorato dopo la massiccia distribuzione nella versione 4.2BSD. Ad ogni modo, come compromesso, Mike propose di includere entrambe le implementazioni nella distribuzione del 4.3BSD, lasciando libera scelta agli utenti su quale dei due selezionare per il loro kernel. Dopo aver rivisto la decisione di Mike Karels, DARPA decise che rendere disponibili due codici base avrebbe condotto a inutili problemi di operatività multiutente, e che perciò avrebbe dovuto uscire con una sola implementazione. Al fine di decidere quale dei due codici base usare, li passarono entrambi a Mike Muuse del Ballistics Research Laboratory, che fu riconosciuto sia da Berkeley che da BBN come parte terza neutrale. Dopo un mese di valutazioni, venne prodotto un rapporto nel quale si asseriva che il codice Berkeley era più efficiente ma che quello BBN gestiva meglio la congestione. Il risultato fu che il codice Berkeley eseguì tutti i test in modo ineccepibile, mentre il codice BBN si trovò inguaiato se posto in situazioni di stress. La decisione finale di DARPA fu che il 4.3BSD avrebbe avuto il codice Berkeley. Il sistema 4.3BSD rifinito fu alla fine in circolazione nel giugno 1986. Come ci si aspettava, zittì molte delle lamentele sulle sue performance, così come il 4.1BSD calmò le riprovazioni sul 4BSD. Sebbene la maggior parte dei rivenditori erano tornati ancora al System V, un'altra buona parte avevano caricato il 4.3BSD sui loro sistemi, particolarmente sul sottosistema di rete. Nell'ottobre del 1986, Keith Bostic si unì al CSRG. Un aspetto del suo nuovo impiego era che avrebbe potuto finire un progetto sul quale aveva lavorato nel suo precedente ufficio; tale progetto consisteva nell'interfacciare il 4.3BSD al PDP-11. Mentre sia io che Karels eravamo convinti che sarebbe stato impossibile fare in modo che un sistema compilato a 250 Kbyte sul VAX potesse andare bene su un PDP-11 che aveva una spazio di indirizzamento di 64 Kbyte, ci accordammo che Bostic avrebbe continuato in questa ricerca. Con nostra grande sorpresa, l'interfacciamento fu completato con successo; venne usata una serie intricata di overlay e stati del processore ausiliari trovati nel PDP-11. Il risultato fu la versione 2.11BSD, creata da Casey Leedom e Bostic, che è tuttora usata in alcuni degli ultimi PDP-11 ancora in funzione nel 1998. Nel frattempo, diventava sempre più ovvio che l'architettura del VAX stava per giungere alla fine dei suoi giorni, e che era ora di cominciare a prendere in considerazione l'utilizzo di altre macchine su cui far eseguire il BSD. Una nuova e promettente architettura, per quei tempi, fu creata da Computer Consoles Incorporated, e denominata Power 6/32. Sfortunatamente, l'architettura in questione decadde appena la società decise di adottare nuove strategie. In ogni caso, queste due società fornirono al CSRG diverse macchine che resero possibile in compimento del lavoro, iniziato da Bill Joy, di suddividere il kernel del BSD in porzioni dipendenti e indipendenti dalle macchine. Il risultato di questo lavoro uscì con il nome di 4.3BSD-Tahoe nel giugno del 1988. Il nome Tahoe derivava dalla denominazione di sviluppo usata da Computer Consoles Incorporated, per la macchina che fecero finalmente uscire sul mercato con il nome di Power 6/32. Nonostante l'utilità e la durevolezza del Power 6/32 risultò breve, il lavoro svolto per suddividere in parti il kernel si dimostrò di estrema utilità, appena il BSD venne interfacciato con altre architetture.
Networking,
Release 1 Con l'incremento del costo delle licenze sul sorgente di AT&T, i rivenditori che volevano costruirsi dei prodotti di rete autonomi basati sul TCP/IP, adatti per il mercato dei PC, usando il codice BSD, riscontrarono che i costi per codice binario erano proibitivi. Quindi, fu richiesto a Berkeley di lasciar perdere il codice di rete e le sue utilità, facendo in modo di fornire termini di licenza tali da non richiedere una licenza AT&T del sorgente. Il codice di rete TCP/IP non esisteva ovviamente su 32/V e quindi fu sviluppato interamente da Berkeley e dai suoi collaboratori. Il codice di rete originato da BSD e le utilità di supporto, furono rese disponibili nel giugno 1989 come Networking Release 1, il primo codice ridistribuito gratuitamente da Berkeley. I termini della licenza erano ampi. Un licenziatario poteva rilasciare del codice modificato o intatto sorgente o in forma binaria senza contabilizzazione o diritti per Berkeley. I soli requisiti erano che le specifiche ai diritti d'autore nel file sorgente venissero lasciate intatte; che i prodotti che incorporavano il codice indicassero nella loro documentazione che il prodotto conteneva codice dell'università di California e dei suoi collaboratori. Sebbene Berkeley richiedeva un contributo di 1.000 dollari per un nastro, chiunque era libero di averne una copia da chiunque altro che già lo aveva ricevuto. Diversi grandi siti furono costruiti per utenti ftp anonimi subito dopo il rilascio. Dato che era così facilmente disponibile, il CSRG fu compiaciuto che diverse centinaia di organizzazioni lo ordinassero, dato che con le loro quote accrescevano il fondo istituito per ulteriori sviluppi.
4.2BSD Le altre aggiunte più importanti al sistema in quel momento furono una versione compatibile da Sun del gestore di file di rete (NFS). Di nuovo il CSRG fu in grado di evitare di scrivere il codice NFS da zero, fece invece in modo che un implementazione venisse fatta da Rick Macklem dell'università canadese di Geulph. Sebbene la configurazione completa del 4.4BSD non era ancora pronta per il lancio, il CSRG decise di provare una versione provvisoria per poter così ottenere un ulteriore feedback e sperimentare le due maggiori aggiunte apportate al sistema. Questa versione provvisoria fu denominata 4.3BSD-Reno e questo successe all'inizio del 1990. La versione fu battezzata così in onore di una città del Nevada, famosa per le scommesse; questa scelta era un modo indiretto per rammentare ai suoi destinatari che, far girare una versione provvisoria rappresentava un po' una scommessa.
Networking,
Release 2 Bostic fu il pioniere imperterrito della tecnica di sviluppo di massa via rete. Egli sollecitò gli altri a riscrivere le utilità di Unix dal niente, a parte le caratteristiche già note. La loro unica soddisfazione sarebbe stata quella di leggere il loro nome nella lista dei collaboratori di Berkeley, proprio accanto al nome dell'utilità che avevano riscritto. I collaboratori iniziarono lentamente e misero mano in maggioranza alle utilità più futili. Ma appena la lista delle utilità completate si allungava, e Bostic continuava a cercare nuove contribuzioni in occasione di eventi pubblici, come per esempio all'Usenix, il numero delle contribuzioni continuava a crescere. Ben presto la lista raggiunse il centinaio di utilità ed entro un anno e mezzo, quasi tutte le utilità più importanti, come pure le librerie, furono riscritte. Bostic entrò con orgoglio e decisione nel mio ufficio e in quello di Mike Karelos, lista in pugno, chiedendo come stavamo procedendo con il lavoro sul kernel. Rassegnati al nostro lavoro - Karels, Bostic e io - passammo i mesi seguenti rivedendo tutta la distribuzione, file per file, rimuovendo i codici che erano nel 32/V. Passata la bufera, scoprimmo che rimanevano solo sei file del kernel che erano ancora contaminati e che non potevano essere riscritti così banalmente. Mentre prendevamo in considerazione la riscrittura di questi sei file, così da avere un sistema completo, decidemmo invece di rendere disponibile solo ciò che avevamo. Abbiamo cercato, sul serio e in ogni modo, di avere il permesso da parte dell'alta amministrazione dell'università di ampliare la nostra versione. Dopo lunghi dibattiti interni e verifiche del nostro metodo per determinare il codice proprietario, ci venne dato l'ok finale. La nostra preoccupazione iniziale era di trovare un nome completamente nuovo per la nostra seconda versione in distribuzione gratuita. Comunque, consideravamo l'ottenimento di una licenza completa, nuova e approvata dai legali dell'università come un'inutile perdita di tempo e di risorse. Perciò, decidemmo di chiamare la nuova versione Networking Release 2, visto che potevamo fare solo una revisione alla già approvata licenza del Networking Release 1. Quindi, la nostra seconda grande e allargata versione gratuita iniziò a essere disponibile nel giugno del 1991. I termini di ridistribuzione e il costo erano gli stessi della prima versione. Come per la prima, alcune centinaia di singoli e organizzazioni pagarono i diritti a Berkeley, pari a 1.000 dollari. L'intervallo dal Networking Release 2 a un sistema pienamente funzionante non fu molto lungo. Entro sei mesi dall'uscita, Bill Jolitz aveva riscritto le modifiche ai sei file mancanti. Egli prontamente approntò un sistema completamente compilato e scaricabile per i PC 386 che si chiamava 386/BSD. La distribuzione del sistema di Jolitz 386/BSD fu fatta quasi interamente sulla Rete. Semplicemente lo caricò per gli utenti ftp anonimi e lasciò che chiunque volesse fosse in grado di scaricarlo in modo del tutto gratuito. In poche settimane si creò un folto gruppo di seguaci. Sfortunatamente, il bisogno di avere un lavoro a tempo pieno significò che Jolitz non poteva dedicare tutto il tempo necessario per mantenere aggiornato il flusso di intoppi e miglioramenti al 386/B54. Perciò, entro pochi mesi dall'uscita del 386/BSD, un gruppo di avidi utenti dello stesso, formarono il gruppo NetBSD mettendo insieme tutte le loro risorse, così da dare una mano nel mantenimento, e più avanti nel miglioramento, del sistema stesso. Queste versioni divennero conosciute come NetBSD. Il gruppo NetBSD scelse di enfatizzare il supporto di quante più piattaforme possibili, e continuò con lo stesso stile di ricerca e sviluppo utilizzato da CSRG. Fino al 1998 era solo sulla Rete; nessun altro mezzo di distribuzione era disponibile. Il loro gruppo continuò a porsi come obiettivo primario il reale fulcro composto dagli utenti tecnici. Maggiori informazioni sul progetto NetBSD si possono ottenere consultando il sito http://www.netbsd.org. Il gruppo FreeBSD si formò qualche mese dopo il NetBSD con uno statuto tale da supportare solo l'architettura di PC, interessando un gruppo di utenti più grande ma meno avanzati tecnicamente, così come Linux aveva fatto. Tale gruppo costruì degli script di installazione elaborati e iniziò a mettere in distribuzione questo sistema su un CD-ROM a basso costo. La combinazione di un'installazione facilitata e una forte promozione sia sulla Rete che nelle principali fiere di settore - come il Comdex - portò a una veloce crescita. Sicuramente FreeBSD vanta al momento la più larga base installata di tutti gli altri sistemi derivanti dalla versione 2. FreeBSD ha anche sfruttato l'onda della popolarità di Linux aggiungendo una modalità simulata che permette ai file binari di Linux di essere eseguiti su una piattaforma FreeBSD. Questa caratteristica permette agli utenti FreeBSD di usare il gruppo di applicazioni, sempre in crescita, disponibili per Linux mentre sfruttano la robustezza, l'affidabilità e le prestazioni del sistema FreeBSD. Il gruppo ha recentemente aperto un FreeBSD Mall (http://www.freebsdmall.com), che raduna molte componenti dell'utenza FreeBSD, compresi i servizi di consulenza, prodotti derivati, libri, e newsletter. A metà degli anni 90, OpenBSD si sganciò dal gruppo NetBSD. I loro obiettivi tecnici erano orientati a migliorare la sicurezza del sistema. Quelli di marketing erano di rendere il sistema più facile da usare e maggiormente disponibile. Quindi, iniziarono a produrre e vendere CD-ROM con molte di queste facili installazioni per la distribuzione con FreeBSD. Maggiori informazioni sul progetto OpenBSD possono essere reperite sul sito http://www.openbsd.org.
La causa legale Subito dopo l'inizio della campagna vendite della BSDI, quest'ultima ricevette una lettera dalla Unix System Laboratories (USL) (una società consociata alla maggioritaria AT&T, che cercò di frenare lo sviluppo di Unix e la sua vendita). La lettera richiedeva l'interruzione della promozione del loro prodotto come Unix, e in particolare che si smettesse di usare un numero di telefono ingannevole. Sebbene il numero di telefono fu subito eliminato e gli annunci cambiarono in modo da informare che il prodotto non era Unix, USL era ancora insoddisfatta e sporse querela, così da diffidare la BSDI dalla vendita del loro prodotto. La querela adduceva che il prodotto della BSDI conteneva il codice proprietario USL oltre ai suoi segreti commerciali. USL cercò di ottenere un'ingiunzione per fermare le vendite della BSDI fino a quando la causa non fosse terminata, sostenendo che USL sarebbe stata soggetta a danni irreparabili, dovuti alla rivelazione dei loro segreti commerciali, se la distribuzione BSDI fosse continuata. Al primo sentore dell'ingiunzione, la BSDI asserì fermamente che stava semplicemente usando i sorgenti distribuiti gratuitamente dall'Università di California, più sei file aggiuntivi. Si rese disponibile a discutere il contenuto di ciascuno dei sei file aggiunti, ma non riteneva che si dovesse considerare responsabile del fatto che i file fossero in distribuzione dall'Università di California. Il giudice accolse le ragioni della BSDI e decise che USL avrebbe dovuto portare avanti la causa solo per quel che riguardava i sei file, altrimenti avrebbe chiuso così il procedimento. L'USL rendendosi conto delle difficoltà che avrebbe incontrato nel farne un caso solo per i sei file, decise di sporgere di nuovo querela contro entrambe BSDI e l'Università di California. Come già prima, USL richiese un ingiunzione sulla distribuzione del Networking Release 2, sia dai prodotti dell'Università che da quelli della BSDI. Rendendosi conto che l'ingiunzione era così imminente da essere obbligatoria in poche settimane, ci si preparò con la massima serietà. Tutti i membri del CSRG deposero, così come quasi tutti gli impiegati della BSDI. Le memorie difensive, le contro-memorie difensive, le contro-contro-memorie difensive andavano avanti e indietro da un avvocato all'altro. Keith Bostic dovette personalmente scrivere, insieme a me, diverse centinaia di pagine di materiale che fu inserito in varie memorie difensive. Nel dicembre 1992, Dickinson R. Debevoise, un giudice distrettuale dello stato del New Jersey, ascoltò le ragioni dell'ingiunzione. Sebbene i giudici solitamente regolarizzano le richieste di ingiunzione immediatamente, lui decise di farlo solo dopo consultazione. Un venerdì, circa sei settimane più tardi, produsse un rapporto di quaranta pagine nel quale annullò l'ingiunzione e respinse tutte le richieste, tranne due. Queste ultime erano ridotte ai diritti d'autore più recenti e alla possibilità di perdita dei segreti commerciali. Egli suggerì altresì che la questione avrebbe dovuto essere posta a una corte giurisdizionale statale, prima di essere sottoposta al giudizio di una corte federale. L'Università di California raccolse subito il suggerimento e si affrettò a contattare la corte giurisdizionale californiana il lunedì mattina seguente, sporgendo una contro-querela alla USL. Nel querelare per prima in California, l'Università predispose l'ambiente ove si sarebbe svolta qualsiasi altra azione legale. La legge costituzionale prevedeva infatti che tutte le querele venissero sporte in un singolo stato, così da evitare che una delle parti con maggiori mezzi economici potesse permettersi di sporgere una querela in ciascuno dei cinquanta stati, penalizzando l'opponente. Il risultato fu che, se USL voleva portare avanti un'altra causa contro l'Università in un tribunale statale, sarebbe stata obbligata a farlo in California, piuttosto che nel suo stato, il New Jersey. La querela dell'università sosteneva che la USL aveva fallito nel suo tentativo di vantare un credito dalla università per l'uso che quest'ultima aveva fatto del codice BSD nel System V, così come previsto dalla licenza che aveva concordemente firmato con l'università. Se questa rivendicazione fosse stata dimostrata valida, l'Università avrebbe chiesto che USL fosse obbligata a ristampare tutta la sua documentazione con i ringraziamenti esatti, notificando tutti i suoi licenziatari della sua svista, oltre che pubblicare una pagina pubblicitaria intera su tutte le pubblicazioni finanziarie più note quali The Wall Street Journal e la rivista Fortune, rendendo noto a tutto il mondo degli affari del suo errore involontario. Subito dopo la presentazione della querela al tribunale, USL cambiò proprietario da AT&T a Novell. Il direttore generale di Novell, Ray Noorda, asserì pubblicamente che avrebbe perorato la sua causa sul mercato, piuttosto che in tribunale. Per l'estate del 1993, iniziò la conciliazione. Sfortunatamente, le due parti in causa avevano scavato talmente in profondità che questa fase procedette a rilento. Con alcune ulteriori sollecitazioni da parte di Ray Noorda verso USL, molti dei punti in questione vennero risolti e una conciliazione fu finalmente raggiunta nel gennaio del 1994. Il risultato fu che tre file vennero rimossi dai 18.000 creati nel Networking Release 2, e un numero di cambiamenti minori vennero apportati ad altri file. In aggiunta, l'Università concordò di aggiungere i diritti d'autore della USL a circa altri 70 file, sebbene questi ultimi continuassero a essere distribuiti gratuitamente.
4.4BSD La fine della causa legale prevedeva anche che USL non avrebbe citato in giudizio alcuna organizzazione che usasse il 4.4BSD-Lite come base per il suo sistema. Quindi, tutti i gruppi BSD che stavano creando versioni in quel momento, BSDI, NetBSD, e FreeBSD, dovettero ritoccare il loro codice base con i file sorgenti del 4.4BSD-Lite, nel quale avrebbero poi incorporato i loro abbellimenti e miglioramenti. Mentre questa reintegrazione causò un piccolo ritardo nello sviluppo dei vari sistemi BSD, questo fu comunque un bene, perché obbligò tutti i gruppi divergenti a sincronizzarsi nuovamente per i tre anni di sviluppo al CSRG, a partire dall'uscita del Networking Release 2.
4.4BSD-Lite,
Release 2 Subito dopo l'uscita del 4.4BSD-Lite Release 2, il CSRG fu sciolto. Dopo essere stato per quasi vent'anni il capitano del BSD, ritenemmo che era giunto il momento di dare ad altri la possibilità di continuare, apportando nuove idee e maggior entusiasmo. Anche se può sembrare meglio avere un solo punto di riferimento autorevole che controlla lo sviluppo del sistema, l'idea di avere gruppi diversi con statuti differenti, assicurava che più di un approccio poteva essere ritenuto valido. Dato che il sistema è disponibile come sorgente, le migliori idee possono essere raccolte anche dagli altri gruppi. Se un gruppo diventa particolarmente efficace, potrebbe eventualmente diventare il sistema dominante.
Oggi,
il movimento dell'Open Source software, sta ottenendo molta attenzione
e rispetto. Sebbene il sistema Linux è forse il più
conosciuto, almeno
la metà delle utilità di cui è fornito derivano
dalla distribuzione
BSD. Le distribuzioni di Linux sono anche pesantemente dipendenti dagli
aggiornamenti, dal collaudo di programmi e da altri strumenti di
sviluppo scritti dalla Free Software Fundation. Insieme, il CSRG, la
Free Software Fundation e gli sviluppatori del kernel di Linux, hanno
creato una piattaforma dalla quale è stato lanciato il movimento
del
software Open Source. Sono orgoglioso di aver avuto
l'opportunità di
aiutare i pionieri dell'Open Source software. Attendo con ansia il
giorno in cui questo diventerà il modo preferito di sviluppare e
comprare software ovunque, sia per gli utenti singoli che per le
società.
di Scott Bradner Per essere qualcosa che in realtà non esiste, la Internet Engineering Task Force (IETF) ha avuto un impatto notevole. A parte il TCP/IP, tutte le tecnologie di base di Internet sono state sviluppate o perfezionate dalla IETF. I gruppi di lavoro IETF hanno creato gli standard di routing, gestione e trasporto senza i quali Internet non esisterebbe. Inoltre, essi hanno definito gli standard di sicurezza necessari a Internet, quelli per la qualità del servizio che renderanno Internet un ambiente più stabile e gli standard per la futura generazione dello stesso protocollo Internet. Tali standard hanno avuto un successo fenomenale. La crescita di Internet supera di gran lunga quella di ogni singola tecnologia della storia, correndo molto più veloce della ferrovia, della luce elettrica, del telefono o della televisione, e pensare che è solo all'inizio... Tutto ciò è stato possibile grazie a degli standard aparti e fortemente voluti. Nessun governo ha mai fatto richiesta per le misure adottate dalla IETF, valgano da esempio tutti gli standard concorrenti, alcuni voluti proprio da forze di governo, che a pieno vantaggio di quelli IETF, si sono persi per strada. È comunque giusto dire che non tutti gli standard IETF hanno avuto lo stesso successo. Sono, infatti, solo gli standard che soddisfano specifiche richieste del mondo reale e le sue reali necessità, quelli che lo diventano veramente. La IETF e i suoi standard hanno avuto una buona riuscita per le stesse motivazioni che hanno portato al decollo della comunità Open Source. Gli standard IETF sono stati sviluppati con un processo aperto, aperto alla partecipazione di chiunque vi fosse interessato. Tutti i documenti IETF sono gratuitamente accessibili su Internet, e possono essere riprodotti, volendolo. È un dato di fatto che il processo di documento aperto della IETF costituisca uno studio analitico del potenziale racchiuso nel movimento Open Source. Questo saggio fornirà una breve storia della IETF, una rivisitazione dei processi e dell'organizzazione della stessa, alcune ulteriori opinioni sull'importanza degli standard aperti, dei documenti aperti e dell'Open Source.
Storia della IETF La IETF usufruisce di un piccolo segretariato, attualmente operante fuori da Reston, Virginia, e una direzione RFC, attualmente rappresentata dall'Istituto di Scienze dell'Informatica dell'Università della California Meridionale. La IETF non è mai stata riconsciuta come entità legale. È semplicemente stata un'attività priva di fondamento legale. Fino alla fine del 1997, le spese della IETF furono coperte da una combinazione di sovvenzioni del governo e tasse di iscrizione agli incontri. Dagli inizi del 1998, la copertura è stata effettuata dalle stesse tasse di adesione ai meeting e dalla Internet Society. La Internet Society fu costituita nel 1992, in parte per fornire una copertura legale al processo degli standard IETF e in parte per sovvenzionare le attività a essa collegate. La Internet Society, organizzazione internazionale senza fini di lucro basata su alleanze, ha anche giocato il ruolo di evangelista di Internet, nella porzione di mondo non ancora raggiunta dalla Rete. A questo punto, la IETF può meglio essere descritta come una funzione di sviluppo di standard, operante sotto gli auspici della Internet Society. Il concetto di gruppo di lavoro, fu introdotto durante il 5° meeting IETF nel Febbraio 1987, e oggi esistono più di 110 gruppi di lavoro operanti nell'ambito IETF.
Struttura e configurazione della IETF Al momento della stesura di questo testo, esistono 115 gruppi di lavoro ufficialmente riconosciuti, all'interno della IETF. Tali gruppi di lavoro sono organizzati in otto aree: Applicazioni, Generale, Internet, Operazioni e Gestione, Routing, Sicurezza, Trasporti e servizi per l'utente. Ognuna di queste aree, è gestita da uno o due direttori di area volontari. Il gruppo dei direttori di area, insieme alla presidenza della IETF, formano il Internet Engineering Steering Group (IESG - Gruppo Guida dell'Internet Engineering). L'IESG è il consiglio di approvazione per gli standard IETF. Inoltre, esiste un IAB (Internet Architecture Board, una sorta di consiglio dell'architettura di Internet) formato da 12 membri, che funge da consigliere per la IETF riguardo alla formazione dei suoi gruppi di lavoro e alle implicazioni dell'architettura dell'attività degli stessi gruppi. I membri del IAB e i direttori di area sono selezionati con scadenza biennale, da una commissione di nomina casualmente scelta ogni anno tra i volontari che abbiano preso parte ad almeno 2 dei precedenti 3 meeting IETF.
I gruppi di lavoro IETF Quasi tutti i gruppi di lavoro prendono vita nel momento in cui un piccolo nucleo di individui si mette insieme di loro spontanea volontà e, successivamente, propongono un gruppo di lavoro a un direttore di area. Ciò vuol dire che la IETF non può programmare piani di azione per un intervento futuro, ma allo stesso tempo assicura che si conservi abbastanza entusiasmo e abilità da rendere un successo ogni singolo gruppo di lavoro formatosi. Il direttore di area lavora insieme ai proponenti del gruppo di lavoro, per sviluppare una sorta di statuto. Tale documento elenca, di solito, i compiti del gruppo di lavoro, eventuali attività collegate ad altri gruppi e, cosa più importante, i limiti di esplorazione del gruppo in questione. Il documento viene poi sottoposto alle mailing list di IESG e IAB per ottenerne dei commenti. Nel caso in cui non si sollevino discussioni significative nel giro di una settimana, lo statuto viene inviato all'elenco pubblico IETF e ad altre organizzazioni di standard, per verificare l'esistenza di altro lavoro in altri forum, di cui IETF debba prendere atto. Trascorre un'altra settimana, per eventuali commenti, quindi IETF può procedere al benestare del documento e alla creazione del gruppo di lavoro.
I documenti IETF La serie di pubblicazione di base per IETF, è la serie RFC. RFC stava per "Request for Comments" (richiesta di commenti), ma dal momento in cui i documenti pubblicati come RFC provenivano da un vasto processo di revisione precedente la pubblicazione, si può dire che oggi RFC vuol dire solo "RFC". Due sono le categorie che la compongono: la sezione standard e quella non-standard. I cosiddetti "track" (proposte) RFC degli standard, possono presentarsi in diversi modi: standard proposto, bozza di standard o standard Internet. I track RFC non-standard, possono essere classificati come: di informazione, sperimentali o storici. Oltre a RFC, IETF fa uso di Internet-Draft. Si tratta di documenti temporanei la cui finalità si avvicina all'originale concetto di "Request for Comments" di RFC, e che vengono automaticamente rimossi dopo sei mesi. Questi non sono citabili o altrimenti definibili se non come lavori in corso.
Il processo IETF I documenti di tipo non-standard, possono avere origine sia dall'attività dei gruppi di lavoro IETF che da singoli desiderosi di rendere disponibili alla comunità Internet le proprie proposte tecniche o di pensiero. Quasi tutte le proposte da pubblicare con RFC, vengono revisionate da IESG; succesivamente IESG consiglia l'Editor (responsabile) RFC circa l'opportunità o meno di pubblicare il documento. L'Editor RFC decide poi di pubblicare o non pubblicare il documento e se includervi o no una nota di IESG, nel caso in cui questa ne rendesse disponibile una. Le note IESG, in questo caso, sono utili per indicare eventuali inconvenienti della proposta, qualora IESG ritenga necessario un ammonimento in proposito. Nel caso di un documento standard, un gruppo di lavoro IETF produrrà un Internet-Draft da pubblicare come RFC. La fase finale della valutazione di una proposta è la "last call" (ultima chiamata) che durava circa due settimane, durante le quali il gruppo di lavoro, chiede alla mailing list del gruppo se siano presenti questioni in sospeso riguardo la proposta. Se il risultato di questa consultazione evidenzia il consenso del gruppo di lavoro in merito all'accettazione della proposta, questa viene inoltrata alla IESG per una valutazione. Il primo passo di questa valutazione, prevede una last call inoltrata a tutta la IETF rappresentata dalla principale mailing list di annunci IETF. E questo per dare la possibilità di commentare la proposta, anche alle persone che non hanno seguito l'attività del gruppo di lavoro. La normale durata della last call IETF è di due settimane per le proposte derivanti da gruppi di lavoro IETF, e di quattro settimane per quelle non derivanti dai gruppi di lavoro IETF. IESG utilizza i risultati della last call IETF come input per le proprie deliberazioni riguardanti la proposta. IESG può approvare il documento e richiederne la pubblicazione, o può rimandare la proposta all'autore/i per una revisione basata sulla valutazione della proposta operata da IESG. Lo stesso processo è impiegato per ogni passo standard proposto. Le proposte accedono di norma in modo standard come "Proposed Standards" (standard proposti), ma a volte, se c'è incertezza sulla tecnologia o si ritengono utili test aggiuntivi, il documento viene dapprima pubblicato come RFC sperimentale. I "Proposed Standards" devono essere buone idee e devono essere prive di difetti tecnici riconosciuti. Dopo un minimo di sei mesi si può considerare la promozione della proposta alla condizione di "Draft Standard". In questo caso gli standard devono aver dimostrato la chiarezza della documentazione e che tutte le questioni sui diritti di proprietà intellettuale relative alla proposta siano ben comprese e risolvibili. Ciò si attua richiedendo l'esistenza di almeno due implementazioni della proposta fra loro indipendenti interoperabili, con differenti esempi di licenze, nel caso ne esistano. Si noti la necessità dell'esecuzione multipla di tutte le caratteristiche separate del protocollo. Qualsiasi caratteristica non rispondente a queste richieste, deve essere rimossa prima di rendere possibile l'avanzamento della proposta. Si può dire, quindi, che gli standard IETF si semplificano man mano che progrediscono. È questa la parte "running code" del motto IETF. La fase finale del processo per gli standard IETF è l'Internet Standard. Dopo aver stazionato nella condizione di Draft Standard per almeno quattro mesi e aver dimostrato un rilevante successo di mercato, una proposta può essere considerata degna di passare allo status di Internet Standard. Due sono le maggiori differenze che saltano all'occhio paragonando i procedimenti standard IETF al processo in atto presso altre organizzazioni di standard. La prima riguarda il risultato finale della maggior parte degli altri standard, che è approssimativamente equivalente alla condizione "Proposed Standard" di IETF. Certo, l'idea resta buona, ma non è presente alcuna richiesta per una effettiva unanimità del consenso. La seconda differenza sta nel fatto che il consenso dei membri, diversamente dall'unanimità, può produrre proposte che presentano meno caratteristiche tante volte necessariamente aggiunte per zittire un singolo brontolone. In breve, la IETF opera in modo ascendente e crede nel detto "fly before you buy", una sorta di "prova prima di acquistare".
Libero accesso a standard, documenti e fonti Una restrizione della partecipazione al processo di sviluppo degli standard, sfocia spesso in risultati che non soddisfano il fabbisogno delle comunità di utenti e fornitori, essendo gli standard in questione molto più complessi di quanto il gruppo di operatori possa ragionevolmente supportare. Una restrizione dell'accesso ai documenti in via di sviluppo, rende più difficile agli esecutori la comprensione della genesi e della logica delle caratteristiche specifiche dello standard, cosa che può portare a implementazioni difettose. Una restrizione dell'accesso agli standard finali, inibisce l'abilità degli studenti, o di coloro che si accingono a sviluppare qualcosa di analogo, alla comprensione e di conseguenza all'uso degli standard. La IETF ha sostenuto il concetto di fonti di libero accesso molto prima che il movimento Open Source prendesse vita. Fino a poco tempo fa, era normale che le "reference implementations" (realizzazioni di riferimento) delle tecnologia IETF fossero fatte come parte delle differenti implementazioni necessarie per l'avanzamento dei lavori standard. Ciò non ha mai costituito una parte formale del processo IETF, ma è stata in genere una conseguenza molto utile. Sfortunatamente, questo metodo ha subito un rallentamento in quest'era di standard più complessi e maggiori implicazioni economiche. La fase pratica non si è fermata, ma sarebbe molto apprezzato, da parte di Open Source, un rinvigorimento di questa parte non ufficiale del processo di standard IETF.
Può
non essere subito chiaro, ma la disponibilità di liberi processi
di
standard e documentazione è un fattore vitale per Open Source.
Senza un
chiaro accordo sul materiale elaborato, normalmente articolato in
documentazioni di standard, è molto più facile che
progetti di sviluppo
distribuiti, come il movimento Open Source, si frammentino e si
indeboliscano. Esiste una partnership intrinseca tra processi di
standard, documentazione e fonti che siano di libero accesso. Tale
partnership ha prodotto Internet, e nel futuro darà vita ad
altri
miracoli.
di Richard Stallman
Il laboratorio di Intelligenza Artificiale (AI) usava un sistema operativo a partizione di tempo (timesharing) chiamato ITS (Incompatible Timesharing System) che il gruppo di hacker1 del laboratorio aveva progettato e scritto in linguaggio assembler per il Digital PDP-10, uno dei grossi elaboratori di quel periodo. Come membro di questa comunità, hacker di sistema nel gruppo laboratorio, il mio compito era migliorare questo sistema. Non chiamavamo il nostro software "software libero", poiché questa espressione ancora non esisteva, ma si trattava proprio di questo. Quando persone di altre università o di qualche società volevano convertire il nostro programma per il proprio sistema e utilizzarlo, erano le benvenute. Se si vedeva qualcuno usare un programma sconosciuto e interessante, si poteva sempre chiedere di vederne il codice sorgente, in modo da poterlo leggere, modificare, o prenderne cannibalizzarne alcune parti per creare un nuovo programma.
La comunità di hacker del laboratorio di Intelligenza Artificiale si era già dissolta non molto tempo prima. Nel 1981 la Symbolics, nata da una costola del laboratorio stesso, gli aveva sottratto quasi tutti gli hacker; l'ormai esiguo gruppo rimasto fu dunque incapace di sostenersi (il libro "Hackers" di Steve Levy narra questi eventi, oltre a fornire una fedele ricostruzione di questa comunità ai suoi inizi). Quando il laboratorio di Intelligenza Artificiale nel 1982 acquistò un nuovo PDP-10, i sistemisti decisero di utilizzare il sistema timesharing non libero della Digital anziché ITS. I moderni elaboratori di quell'epoca, come il VAX o il 68020, avevano il proprio sistema operativo, ma nessuno di questi era libero: si doveva firmare un accordo di non-diffusione persino per ottenerne una copia eseguibile. Questo significava che il primo passo per usare un computer era promettere di negare aiuto al proprio vicino. Una comunità cooperante era vietata. La regola creata dai proprietari di software proprietario era: "se condividi il software col tuo vicino sei un pirata. Se vuoi modifiche, pregaci di farle". L'idea che la concezione sociale di software proprietario - cioè il sistema che impone che il software non possa essere condiviso o modificato - sia antisociale, contraria all'etica, semplicemente sbagliata, può apparire sorprendente a qualche lettore. Ma che altro possiamo dire di un sistema che si basa sul dividere utenti e lasciarli senza aiuto? Quei lettori che trovano sorprendente l'idea possono aver data per scontata la concezione sociale di software proprietario, o averla giudicata utilizzando lo stesso metro suggerito dal mercato del software proprietario. I produttori di software hanno lavorato a lungo e attivamente per diffondere la convinzione che c'è un solo modo di vedere la cosa. Quando i produttori di software parlano di "difendere" i propri "diritti" o di "fermare la pirateria", quello che dicono è in realtà secondario. Il vero messaggio in quelle affermazioni sta nelle assunzioni inespresse, che essi danno per scontate; vogliono che siano accettate acriticamente. Esaminiamole, dunque. Una prima assunzione è che le aziende produttrici di software abbiano il diritto naturale indiscutibile di proprietà sul software, e di conseguenza, abbiano controllo su tutti i suoi utenti. Se questo fosse un diritto naturale, non potremmo sollevare obiezioni, indipendentemente dal danno che possa recare ad altri. È interessante notare che, negli Stati Uniti, sia la costituzione che la giurisprudenza rifiutano questa posizione: il diritto d'autore non è un diritto naturale, ma un monopolio imposto dal governo che limita il diritto naturale degli utenti a effettuare delle copie. Un'altra assunzione inespressa è che la sola cosa importante del software sia il lavoro che consente di fare - vale a dire che noi utenti non dobbiamo preoccuparci del tipo di società in cui ci è permesso vivere. Una terza assunzione è che non avremmo software utilizzabile (o meglio, che non potremmo mai avere un programma per fare questo o quell'altro particolare lavoro) se non riconoscessimo ai produttori il controllo sugli utenti di quel programmi. Questa assunzione avrebbe potuto sembrare plausibile, prima che il movimento del software libero dimostrasse che possiamo scrivere quantità di programmi utili senza bisogno di metterci dei catenacci. Se rifiutiamo di accettare queste assunzioni, giudicando queste questioni con comuni criteri di moralità e di buon senso dopo aver messo al primo posto gli interessi degli utenti, tenendo conto che gli utenti vengono prima di tutto, arriviamo a conclusioni del tutto differenti. Chi usa un calcolatore dovrebbe essere libero di modificare i programmi per adattarli alle proprie necessità, ed essere libero di condividere il software, poiché aiutare gli altri è alla base della società. Non c'è modo in questa sede di trattare approfonditamente i ragionamenti che portano a questa conclusione; il lettore interessato può cercare le informazioni in rete a questo indirizzo: http://www.gnu.org/philosophy/why-free.html.
La scelta facile sarebbe stata quella di unirsi al mondo del software proprietario, firmando accordi di non-diffusione e promettendo di non aiutare i miei compagni hacker. Con ogni probabilità avrei anche sviluppato software che sarebbe stato distribuito secondo accordi di non-diffusione, contribuendo così alla pressione su altri perché a loro volta tradissero i propri compagni. In questo modo avrei potuto guadagnare, e forse mi sarei divertito a programmare. Ma sapevo che al termine della mia carriera mi sarei voltato a guardare indietro, avrei visto anni spesi a costruire muri per dividere le persone, e avrei compreso di aver contribuito a rendere il mondo peggiore. Avevo già sperimentato cosa significasse un accordo di non diffusione per chi lo firmava, quando qualcuno rifiutò a me e al laboratorio AI del MIT il codice sorgente del programma di controllo della nostra stampante; l'assenza di alcune funzionalità nel programma rendeva oltremodo frustrante l'uso della stampante. Per cui non mi potevo dire che gli accordi di non-diffusione fossero innocenti. Ero molto arrabbiato quando quella persone si rifiutò di condividere il programma con noi; non potevo far finta di niente e fare lo stesso con tutti gli altri. Un'altra possibile scelta, semplice ma spiacevole, sarebbe stata quella di abbandonare l'informatica. In tal modo le mie capacità non sarebbero state mal utilizzate, tuttavia sarebbero state sprecate. Non sarei mai stato colpevole di dividere o imporre restrizioni agli utenti di calcolatori, ma queste cose sarebbero comunque successe. Allora cercai un modo in cui un programmatore potesse fare qualcosa di buono. Mi chiesi dunque: c'erano un programma o dei programmi che io potessi scrivere, per rendere nuovamente possibile l'esistenza di una comunità? La risposta era semplice: innanzitutto serviva un sistema operativo. Questo è difatti il software fondamentale per iniziare a usare un computer. Con un sistema operativo si possono fare molte cose; senza, non è proprio possibile far funzionare il computer. Con un sistema operativo libero, avremmo potuto avere nuovamente una comunità in cui hacker possono cooperare, e invitare chiunque a unirsi al gruppo. E chiunque sarebbe stato in grado di usare un calcolatore, senza dover cospirare fin dall'inizio per sottrarre qualcosa ai propri amici. Essendo un programmatore di sistemi, possedevo le competenze adeguate per questo lavoro. Così, anche se non davo il successo per scontato, mi resi conto di essere la persona giusta per farlo. Scelsi di rendere il sistema compatibile con Unix, in modo che fosse portabile, e che gli utenti Unix potessero passare facilmente a esso. Il nome GNU fu scelto secondo una tradizione hacker, come acronimo ricorsivo che significa "GNU's Not Unix" (GNU non è Unix). Un sistema operativo non si limita solo al suo nucleo, che è proprio il minimo per eseguire altri programmi. Negli anni '70, qualsiasi sistema operativo degno di questo nome includeva interpreti di comandi, assemblatori, compilatori, interpreti di linguaggi, debugger, editor di testo, programmi per la posta e molto altro. ITS li aveva, Multics li aveva, VMS li aveva e Unix li aveva. Anche il sistema operativo GNU li avrebbe avuti. Tempo dopo venni a conoscenza di questa massima, attribuita a Hillel2: Se non sono per me stesso, chi sarà per me? E se sono solo per me stesso, che cosa sono? E se non ora, quando? La decisione di iniziare il progetto GNU si basò su uno spirito simile.
A causa dell'ambiguità del termine "free", si è cercata a lungo un'alternativa, ma nessuno ne ha trovata una valida. La lingua inglese ha, più termini e sfumature di ogni altra, ma non ha una parola semplice e non ambigua che significhi libero; "unfettered" è la parola più vicina come significato (N.d.T. unfettered è una parola di tono aulico o arcaico che significa libero da ceppi, vincoli o inibizioni). Alternative come "liberated", "freedom" e "open" hanno altri significati o non sono adatte per altri motivi (N.d.T. rispettivamente, liberato, libertà, aperto).
A causa di questa decisione, il sistema GNU e la raccolta di tutto il software GNU non sono la stessa cosa. Il sistema GNU comprende programmi che non sono GNU, sviluppati da altre persone o gruppi di progetto per i propri scopi, ma che possiamo usare in quanto software libero.
Sperando di evitare di dover scrivere da me l'intero compilatore, ottenni il codice sorgente del Pastel, un compilatore multipiattaforma sviluppato ai Laboratori Lawrence Livermore. Il linguaggio supportato da Pastel, in cui il Pastel stesso era scritto, era una versione estesa del Pascal, pensata come linguaggio di programmazione di sistemi. Io vi aggiunsi un frontend per il C, e cominciai il porting per il processore Motorola 68000, ma fui costretto a rinunciare quando scoprii che il compilatore richiedeva diversi megabyte di memoria sullo stack, mentre il sistema Unix disponibile per il processore 68000 ne permetteva solo 64K. Mi resi conto allora che il compilatore Pastel interpretava tutto il file di ingresso creandone un albero sintattico, convertiva questo in una catena di "istruzioni", e quindi generava l'intero file di uscita senza mai liberare memoria. A questo punto, conclusi che avrei dovuto scrivere un nuovo compilatore da zero. Quel nuovo compilatore è ora noto come Gcc; non utilizza niente del compilatore Pastel, ma riuscii ad adattare e riutilizzare il frontend per il C che avevo scritto. Questo però avvenne qualche anno dopo; prima, lavorai su GNU Emacs.
A questo punto alcuni cominciarono a voler usare GNU Emacs, il che pose il problema di come distribuirlo. Naturalmente lo misi sul server ftp anonimo del computer che usavo al MIT (questo computer, prep.ai.mit.edu, divenne così il sito ftp primario di distribuzione di GNU; quando alcuni anni dopo andò fuori servizio, trasferimmo il nome sul nostro nuovo ftp server). Ma allora molte delle persone interessate non erano su Internet e non potevano ottenere una copia via ftp, così mi si pose il problema di cosa dir loro. Avrei potuto dire: "trova un amico che è in rete disposto a farti una copia". Oppure avrei potuto fare quel che feci con l'originario Emacs su PDP-10, e cioè dir loro: "spediscimi una busta affrancata e un nastro, e io te lo rispedisco con sopra Emacs". Ma ero senza lavoro, e cercavo un modo di far soldi con il software libero. E così feci sapere che avrei spedito un nastro a chi lo voleva per 150 dollari. In questo modo, creai un'impresa di distribuzione di software libero, che anticipava le compagnie che oggi distribuiscono interi sistemi GNU basati su Linux.
L'esempio emblematico della questione è l'X Window System. Sviluppato al MIT, e pubblicato come software libero con una licenza permissiva, fu rapidamente adottato da diverse società informatiche. Queste aggiunsero X ai loro sistemi Unix proprietari, solo in forma binaria, e coperto dello stesso accordo di non-diffusione. Queste copie di X non erano software più libero di quanto lo fosse Unix. Gli autori dell'X Window System non ritenevano che questo fosse un problema, anzi se lo aspettavano ed era loro intenzione che accadesse. Il loro scopo non era la libertà, ma semplicemente il "successo", definito come "avere tanti utenti". Non erano interessati che questi utenti fossero liberi, ma solo che fossero numerosi. Questo sfociò in una situazione paradossale, in cui due modi diversi di misurare la quantità di libertà risultavano in risposte diverse alla domanda "questo programma è libero"? Giudicando sulla base della libertà offerta dai termini distributivi usati dal MIT, si sarebbe dovuto dire che X era software libero. Ma misurando la libertà dell'utente medio di X, si sarebbe dovuto dire che X era software proprietario. La maggior parte degli utenti di X usavano le versioni proprietarie fornite con i sistemi Unix, non la versione libera.
Il permesso d'autore (copyleft)4 usa le leggi sul diritto d'autore (copyright), ma le capovolge per ottenere lo scopo opposto: invece che un metodo per privatizzare il software, diventa infatti un mezzo per mantenerlo libero. Il succo dell'idea di permesso d'autore consiste nel dare a chiunque il permesso di eseguire il programma, copiare il programma, modificare il programma, e distribuirne versioni modificate, ma senza dare il permesso di aggiungere restrizioni. In tal modo, le libertà essenziali che definiscono il "free software" (software libero) sono garantite a chiunque ne abbia una copia, e diventano diritti inalienabili. Perché un permesso d'autore sia efficace, anche le versioni modificate devono essere libere. Ciò assicura che ogni lavoro basato sul nostro sia reso disponibile per la nostra comunità, se pubblicato. Quando dei programmatori professionisti lavorano su software GNU come volontari, è il permesso d'autore che impedisce ai loro datori di lavoro di dire: "non puoi distribuire quei cambiamenti, perché abbiamo intenzione di usarli per creare la nostra versione proprietaria del programma". La clausola che i cambiamenti debbano essere liberi è essenziale se vogliamo garantire libertà a tutti gli utenti del programma. Le aziende che privatizzarono l'X Window System di solito avevano apportato qualche modifica per portare il programma sui loro sistemi e sulle loro macchine. Si trattava di modifiche piccole rispetto alla mole di X, ma non banali. Se apportare modifiche fosse una scusa per negare libertà agli utenti, sarebbe facile per chiunque approfittare di questa scusa. Una problematica correlata è quella della combinazione di un programma libero con codice non libero. Una tale combinazione sarebbe inevitabilmente non libera; ogni libertà che manchi dalla parte non libera mancherebbe anche dall'intero programma. Permettere tali combinazioni aprirebbe non uno spiraglio, ma un buco grosso come una casa. Quindi un requisito essenziale per il permesso d'autore è tappare il buco: tutto ciò che venga aggiunto o combinato con un programma protetto da permesso d'autore dev'essere tale che il programma risultante sia anch'esso libero e protetto da permesso d'autore. La specifica implementazione di permesso d'autore che utilizziamo per la maggior parte del software GNU è la GNU General Public License (licenza pubblica generica GNU), abbreviata in GNU GPL. Abbiamo altri tipi di permesso d'autore che sono utilizzati in circostanze specifiche. I manuali GNU sono anch'essi protetti da permesso d'autore, ma ne usano una versione molto più semplice, perché per i manuali non è necessaria la complessità della GPL.
La FSF accetta donazioni, ma gran parte delle sue entrate è sempre stata costituita dalle vendite: copie di software libero e servizi correlati. Oggi vende CD-ROM di codice sorgente, CD-ROM di programmi compilati, manuali stampati professionalmente (tutti con libertà di ridistribuzione e modifica), e distribuzioni Deluxe (nelle quali compiliamo l'intera scelta di software per una piattaforma a richiesta). I dipendenti della Free Software Foundation hanno scritto e curato la manutenzione di diversi pacchetti GNU. Fra questi spiccano la libreria C e la shell. La libreria C di GNU è utilizzata da ogni programma che gira su sistemi GNU/Linux per comunicare con Linux. È stata sviluppata da un membro della squadra della Free Software Foundation, Roland McGrath. La shell usata sulla maggior parte dei sistemi GNU/Linux è Bash, la Bourne Again Shell5, che è stata sviluppata da Brian Fox, dipendente della FSF. Finanziammo lo sviluppo di questi programmi perché il progetto GNU non riguardava solo strumenti di lavoro o un ambiente di sviluppo: il nostro obiettivo era un sistema operativo completo, e questi programmi erano necessari per raggiungere quell'obiettivo.
La vendita di copie di Emacs esemplifica un modo di condurre affari col software libero. Quando la FSF prese in carico quest'attività, dovetti trovare un'altra fonte di sostentamento. La trovai nella vendita di servizi relativi al software libero che avevo sviluppato, come insegnare argomenti quali programmazione di Emacs e personalizzazione di GCC, oppure sviluppare software, soprattutto adattamento di GCC a nuove architetture. Oggi tutte queste attività collegate al software libero sono esercitate da svariate aziende. Alcune distribuiscono raccolte di software libero su CD-ROM, altre offrono consulenza a diversi livelli, dall'aiutare gli utenti in difficoltà, alla correzione di errori, all'aggiunta di funzionalità non banali. Si cominciano anche a vedere aziende di software che si fondano sul lancio di nuovi programmi liberi. Attenzione, però: diverse aziende che si fregiano del marchio "open source" (software aperto) in realtà fondano le loro attività su software non libero che funziona insieme con software libero. Queste non sono aziende di software libero, sono aziende di software proprietario i cui prodotti attirano gli utenti lontano dalla libertà. Loro li chiamano "a valore aggiunto", il che riflette i valori che a loro farebbe comodo che adottassimo: la convenienza prima della libertà. Se noi riteniamo che la libertà abbia più valore, li dovremmo chiamare prodotti "a libertà sottratta".
Tuttavia risultò naturale applicare al lavoro le regole classiche di buona programmazione; per esempio, allocare le strutture dati dinamicamente per evitare limitazioni arbitrarie sulla dimensione dei dati, o gestire tutti i possibili codici a 8 bit in tutti i casi ragionevoli. Inoltre, al contrario di Unix che era pensato per piccole dimensioni di memoria, decidemmo di non supportare le macchine a 16 bit (era chiaro che le macchine a 32 bit sarebbero state la norma quando il sistema GNU sarebbe stato completo), e di non preoccuparci di ridurre l'occupazione di memoria a meno che eccedesse il megabyte. In programmi per i quali non era essenziale la gestione di file molto grandi, spingemmo i programmatori a leggere in memoria l'intero file di ingresso per poi analizzare il file senza doversi preoccupare delle operazioni di I/O. Queste decisioni fecero sì che molti programmi GNU superassero i loro equivalenti Unix sia in affidabilità che in velocità di esecuzione.
Unix era (ed è) software proprietario, e la filosofia del progetto GNU diceva che non avremmo dovuto usare software proprietario. Ma, applicando lo stesso ragionamento per cui la violenza è ammessa per autodifesa, conclusi che fosse legittimo usare un pacchetto proprietario, se ciò fosse stato importante nel crearne un sostituto libero che permettesse ad altri di smettere di usare quello proprietario. Tuttavia, benché fosse un male giustificabile, era pur sempre un male. Oggi non abbiamo più alcuna copia di Unix, perché le abbiamo sostituite con sistemi operativi liberi. Quando non fu possibile sostituire il sistema operativo di una macchina con uno libero, sostituimmo la macchina.
Oggi non compare quasi nessun componente Unix nell'elenco dei compiti GNU; tutti questi lavori, a parte qualcuno non essenziale, sono già stati svolti. D'altro canto l'elenco è pieno di quei progetti che qualcuno chiamerebbe "applicazioni": ogni programma che interessi a una fetta non trascurabile di utenti sarebbe un'utile aggiunta a un sistema operativo. L'elenco comprende anche dei giochi, e così è stato fin dall'inizio: Unix comprendeva dei giochi, perciò era naturale che così fosse anche per GNU. Ma poiché non c'erano esigenze di compatibilità per i giochi, non ci attenemmo alla scelta di giochi presenti in Unix, preferendo piuttosto fornire un elenco di diversi tipi di giochi potenzialmente graditi agli utenti.
Non si tratta di questioni di principio: non c'è nessun principio che dica che i prodotti software proprietari abbiano il diritto di includere il nostro codice (perché contribuire a un progetto fondato sul rifiuto di condividere con noi?). L'uso della licenza LGPL per la libreria C, o per qualsiasi altra libreria, è una questione di strategia. La libreria C svolge una funzione generica: ogni sistema operativo proprietario e ogni compilatore includono una libreria C. Di conseguenza, rendere disponibile la nostra libreria C solo per i programmi liberi non avrebbe dato nessun vantaggio a tali programmi liberi, avrebbe solo disincentivato l'uso della nostra libreria. C'è un'eccezione a questa situazione: sul sistema GNU (termine che include GNU/Linux) l'unica libreria C disponibile è quella GNU. Quindi i termini di distribuzione della nostra libreria C determinano se sia possibile o meno compilare un programma proprietario per il sistema GNU. Non ci sono ragioni etiche per permettere l'uso di applicazioni proprietarie sul sistema GNU, ma strategicamente sembra che impedirne l'uso servirebbe più a scoraggiare l'uso del sistema GNU che non a incoraggiare lo sviluppo di applicazioni libere. Ecco perché l'uso della licenza LGPL è una buona scelta strategica per la libreria C, mentre per le altre librerie la strategia va valutata caso per caso. Quando una libreria svolge una funzione particolare che può aiutare a scrivere certi tipi di programmi, distribuirla secondo la GPL, quindi limitandone l'uso ai soli programmi liberi, è un modo per aiutare gli altri autori di software libero, dando loro un vantaggio nei confronti del software proprietario. Prendiamo come esempio GNU-Readline, una libreria scritta per fornire a Bash la modificabilità della linea di comando: Readline è distribuita secondo la normale licenza GPL, non la LGPL. Ciò probabilmente riduce l'uso di Readline, ma questo non rappresenta una perdita per noi; d'altra parte almeno una applicazione utile è stata resa software libero proprio al fine di usare Readline, e questo è un guadagno tangibile per la comunità. Chi sviluppa software proprietario ha vantaggi economici, gli autori di programmi liberi hanno bisogno di avvantaggiarsi a vicenda. Spero che un giorno possiamo avere una grande raccolta di librerie coperte dalla licenza GPL senza che esista una raccolta equivalente per chi scrive software proprietario. Tale libreria fornirebbe utili moduli da usare come i mattoni per costruire nuovi programmi liberi, e costituendo un sostanziale vantaggio per la scrittura di ulteriori programmi liberi.
Per esempio, abbiamo sviluppato la libreria C di GNU perché un sistema di tipo Unix ha bisogno di una libreria C, la Bourne-Again Shell (bash) perché un sistema di tipo Unix ha bisogno di una shell, e GNU tar perché un sistema di tipo Unix ha bisogno un programma tar. Lo stesso vale per i miei programmi: il compilatore GNU, GNU Emacs, GDB, GNU Make. Alcuni programmi GNU sono stati sviluppati per fronteggiare specifiche minacce alla nostra libertà: ecco perché abbiamo sviluppato gzip come sostituto per il programma Compress, che la comunità aveva perduto a causa dei brevetti sull'algoritmo LZW. Abbiamo trovato persone che sviluppassero LessTif, e più recentemente abbiamo dato vita ai progetti GNOME e Harmony per affrontare i problemi causati da alcune librerie proprietarie (come descritto più avanti). Stiamo sviluppando la GNU Privacy Guard per sostituire i diffusi programmi di crittografia non liberi, perché gli utenti non siano costretti a scegliere tra riservatezza e libertà. Naturalmente, i redattori di questi programmi sono coinvolti nel loro lavoro, e varie persone vi hanno aggiunto diverse funzionalità secondo le loro personali necessità e i loro interessi. Tuttavia non è questa la ragione dell'esistenza di tali programmi.
Poiché i componenti del sistema GNU sono stati implementati su un sistema Unix, ognuno di essi poteva girare su sistemi Unix molto prima che esistesse un sistema GNU completo. Alcuni di questi programmi divennero diffusi e gli utenti iniziarono a estenderli e a renderli utilizzabili su nuovi sistemi: sulle varie versioni di Unix, incompatibili tra loro, e talvolta anche su altri sistemi. Questo processo rese tali programmi molto più potenti e attirò finanziamenti e collaboratori al progetto GNU; tuttavia probabilmente ritardò di alcuni anni la realizzazione di un sistema minimo funzionante, perché il tempo degli autori GNU veniva impiegato a curare la compatibilità di questi programmi con altri sistemi e ad aggiungere nuove funzionalità ai componenti esistenti, piuttosto che a proseguire nella scrittura di nuovi componenti.
Una ragione di questa scelta progettuale fu di evitare quella che sembrava la parte più complessa del lavoro: effettuare il debugging del kernel senza un debugger a livello sorgente. Questo lavoro era già stato fatto, appunto in Mach, e avevamo previsto di effettuare il debugging dei server Hurd come programmi utente, con GDB. Ma questa fase si rivelò molto lunga, e il debugging dei server multi-thread che si scambiano messaggi si è rivelato estremamente complesso. Per rendere Hurd robusto furono così necessari molti anni.
Le cose non andarono così. Michael Bushnell (ora Thomas), principale autore del kernel, preferì il nome Hurd, e chiamò Alix una parte del kernel, quella che serviva a intercettare le chiamate di sistema e a gestirle inviando messaggi ai server che compongono HURD. Infine io e Alix ci lasciammo e lei cambiò nome; contemporaneamente la struttura di Hurd veniva cambiata in modo che la libreria C mandasse messaggi direttamente ai server, e così il componente Alix scomparve dal progetto. Prima che questo accadesse, però, un amico di Alix si accorse della presenza del suo nome nel codice sorgente di Hurd e glielo disse. Così il nome raggiunse il suo scopo.
Chiamiamo GNU/Linux questa versione del sistema, per indicare la sua composizione come una combinazione del sistema GNU col kernel Linux.
Esistono due modi per affrontare il problema. Un programmatore può ricostruire le specifiche dell'hardware usando tecniche di reverse engineering. Oppure si può scegliere hardware supportato dai programmi liberi: man mano che il nostro numero aumenta, la segretezza delle specifiche diventerà una pratica controproducente. Il reverse engineering è difficile: avremo programmatori sufficientemente determinati da dedicarvisi? Sì, se avremo costruito una forte consapevolezza che avere programmi liberi sia una questione di principio e che i driver non liberi non sono accettabili. E succederà che molti di noi accettino di spendere un po' di più o perdere un po' più di tempo per poter usare driver liberi? Sì, se il desiderio di libertà e la determinazione a ottenerla saranno diffusi.
Il problema si concretizzò per la prima volta con la libreria Motif, negli anni '80. Sebbene non ci fossero ancora sistemi operativi liberi, i problemi che Motif avrebbe causato loro erano già chiari. Il progetto GNU reagì in due modi: interessandosi presso diversi progetti di software libero perché supportassero gli strumenti grafici X liberi in aggiunta a Motif, e cercando qualcuno che scrivesse un sostituto libero di Motif. Il lavoro richiese molti anni: solo nel 1997 LessTif, sviluppato dagli "Hungry Programmers", divenne abbastanza potente da supportare la maggior parte delle applicazioni Motif. Tra il 1996 e il 1998 un'altra libreria non libera di strumenti grafici, chiamata Qt, veniva usata in una significativa raccolta di software libero: l'ambiente grafico KDE. I sistemi liberi GNU/Linux non potevano usare KDE, perché non potevamo usare la libreria; tuttavia, alcuni distributori commerciali di sistemi GNU/Linux, non scrupolosi nell'attenersi solo ai programmi liberi, aggiunsero KDE ai lori sistemi, ottenendo così sistemi che offrivano più funzionalità, ma meno libertà. Il gruppo che sviluppava KDE incoraggiava esplicitamente altri programmatori a usare Qt, e milioni di nuovi "utenti Linux" non sospettavano minimamente che questo potesse costituire un problema. La situazione si faceva pericolosa. La comunità del software libero affrontò il problema in due modi: GNOME e Harmony. GNOME (GNU Network Object Model Environment, modello di ambiente per oggetti di rete) è il progetto GNU per l'ambiente grafico (desktop). Intrapreso nel 1997 da Miguel de Icaza e sviluppato con il supporto di Red Hat Software, GNOME si ripromise di fornire funzionalità grafiche simili a quelle di KDE, ma usando esclusivamente software libero. GNOME offre anche dei vantaggi tecnici, come il supporto per svariati linguaggi di programmazione, non solo il C++. Ma il suo scopo principale era la libertà: non richiedere l'uso di alcun programma che non fosse libero. Harmony è una libreria compatibile con Qt, progettata per rendere possibile l'uso del software KDE senza dover usare Qt. Nel novembre 1998 gli autori di Qt annunciarono un cambiamento di licenza che, una volta operativo, avrebbe reso Qt software libero. Non c'è modo di esserne certi, ma credo che questo fu in parte dovuto alla decisa risposta della comunità al problema posto da Qt quando non era libero (la nuova licenza è scomoda e iniqua, per cui rimane comunque preferibile evitare l'uso di Qt). Come risponderemo alla prossima allettante libreria non libera? Riuscirà la comunità in toto a comprendere l'importanza di evitare la trappola? Oppure molti di noi preferiranno la convenienza alla libertà, creando così ancora un grave problema? Il nostro futuro dipende dalla nostra filosofia.
Ci sono modi per affrontare la questione brevetti: possiamo cercare prove che un brevetto non sia valido oppure possiamo cercare modi alternativi per ottenere lo stesso risultato. Ognuna di queste tecniche, però, funziona solo in certe circostanze; quando entrambe falliscono un brevetto può obbligare tutto il software libero a rinunciare a qualche funzionalità che gli utenti desiderano. Cosa dobbiamo fare quando ciò accade? Chi fra noi apprezza il software libero per il valore della libertà rimarrà comunque dalla parte dei programmi liberi; saremo in grado di svolgere il nostro lavoro senza le funzionalità coperte da brevetto. Ma coloro che apprezzano il software libero perché si aspettano che sia tecnicamente superiore probabilmente grideranno al fallimento quando un brevetto ne impedisce lo sviluppo. Perciò, nonostante sia utile parlare dell'efficacia pratica del modello di sviluppo "a cattedrale", e dell'affidabilità e della potenza di un dato programma libero, non ci dobbiamo fermare qui; dobbiamo parlare di libertà e di principi.
La documentazione libera, come il software libero, è una questione di libertà, non di prezzo. Il criterio per definire libero un manuale è fondamentalmente lo stesso che per definire libero un programma: si tratta di offrire certe libertà a tutti gli utenti. Deve essere permessa la ridistribuzione (compresa la vendita commerciale), sia in formato elettronico che cartaceo, in modo che il manuale possa accompagnare ogni copia del programma. Autorizzare la modifica è anch'esso un aspetto cruciale; in generale, non credo sia essenziale permettere alle persone di modificare articoli e libri di qualsiasi tipo. Per esempio, non credo che voi o io dobbiamo sentirci in dovere di autorizzare la modifica di articoli come questo, articoli che descrivono le nostre azioni e il nostro punto di vista. Ma c'è una ragione particolare per cui la libertà di modifica è cruciale per la documentazione dei programmi liberi. Quando qualcuno esercita il proprio diritto di modificare il programma, aumentandone o alterandone le funzionalità, se è coscienzioso modificherà anche il manuale, in modo da poter fornire una documentazione utile e accurata insieme al programma modificato. Un manuale che non permetta ai programmatori di essere coscienziosi e completare il loro lavoro non soddisfa i bisogni della nostra comunità. Alcuni limiti sulla modificabilità non pongono alcun problema; per esempio, le richieste di conservare la nota di copyright dell'autore originale, i termini di distribuzione e la lista degli autori vanno bene. Non ci sono problemi nemmeno nel richiedere che le versioni modificate dichiarino esplicitamente di essere tali, così pure che intere sezioni non possano essere rimosse o modificate, finché queste sezioni vertono su questioni non tecniche. Restrizioni di questo tipo non creano problemi perché non impediscono al programmatore coscienzioso di adattare il manuale perché rispecchi il programma modificato. In altre parole, non impediscono alla comunità del software libero di beneficiare appieno dal manuale. D'altro canto, deve essere possibile modificare tutto il contenuto tecnico del manuale e poter distribuire il risultato in tutti i formati usuali, attraverso tutti i normali canali di distribuzione; diversamente, le restrizioni creerebbero un ostacolo per la comunità, il manuale non sarebbe libero e avremmo bisogno di un altro manuale. Gli sviluppatori di software libero avranno la consapevolezza e la determinazione necessarie a produrre un'intera gamma di manuali liberi? Ancora una volta, il nostro futuro dipende dalla nostra filosofia.
Gli effetti positivi di questa situazione sono evidenti: maggior interesse a sviluppare software libero, più clienti per le imprese di software libero e una migliore capacità di incoraggiare le aziende a sviluppare software commerciale libero invece che prodotti software proprietari. L'interesse per il software, però, sta crescendo più in fretta della coscienza della filosofia su cui è basato, e questa disparità causa problemi. La nostra capacità di fronteggiare le sfide e le minacce descritte in precedenza dipende dalla determinazione nell'essere impegnati per la libertà. Per essere sicuri che la nostra comunità abbia tale determinazione, dobbiamo diffondere l'idea presso i nuovi utenti man mano che entrano a far parte della comunità. Ma in questo stiamo fallendo: gli sforzi per attrarre nuovi utenti nella comunità sono di gran lunga maggiori degli sforzi per l'educazione civica della comunità stessa. Dobbiamo fare entrambe le cose, e dobbiamo mantenere un equilibrio fra i due impegni.
Alcune delle persone che suggerirono questo termine intendevano evitare che si confondesse "free" con "gratis", un valido obiettivo. D'altra parte, altre persone intendevano mettere da parte lo spirito del principio che aveva dato la spinta al movimento del software libero e al progetto GNU, puntando invece ad attrarre i dirigenti e gli utenti commerciali, molti dei quali afferiscono a una ideologia che pone il profitto al di sopra della libertà, della comunità, dei principi. Perciò la retorica di "open source" si focalizza sul possibilità di creare software di buona qualità e potente ma evita deliberatamente le idee di libertà, comunità, principio. Le riviste che si chiamano "Linux..." sono un chiaro esempio di ciò: sono piene di pubblicità di software proprietario che gira sotto GNU/Linux; quando ci sarà il prossimo Motif o Qt, queste riviste avvertiranno i programmatori di starne lontano o accetteranno la sua pubblicità? L'appoggio delle aziende può contribuire alla comunità in molti modi; a parità di tutto il resto è una cosa utile. Ma ottenere questo appoggio parlando ancor meno di libertà e principi può essere disastroso; rende ancora peggiore lo sbilanciamento descritto tra diffusione ed educazione civica. "Software libero" (free software) e "sorgente aperto" (open source) descrivono più o meno la stessa categoria di software, ma dicono cose differenti sul software e sui valori. Il progetto GNU continua a usare il termine "software libero" per esprimere l'idea che la libertà sia importante, non solo la tecnologia.
A volte ho fallito, alcune delle mie città sono cadute; poi ho trovato un'altra città minacciata e mi sono preparato a un'altra battaglia. Con l'andar del tempo ho imparato a cercare le possibili minacce e a mettermi tra loro e la mia città, facendo appello ad altri hacker perché venissero e si unissero a me. Oggigiorno spesso non sono da solo. È un sollievo e una gioia quando vedo un reggimento di hacker che scavano trincee per difendere il confine e quando mi rendo conto che questa città può sopravvivere; per ora. Ma i pericoli diventano più grandi ogni anno, e ora Microsoft ha esplicitamente preso di mira la nostra comunità. Non possiamo dare per scontato il futuro della libertà; non diamolo per scontato! Se volete mantenere la vostra libertà dovete essere pronti a difenderla. * La traduzione di questo saggio è stata revisionata e curata, con la supervisione dell'autore, da Lorenzo Bettini, Antonio Cisternino, Francesco Potortì e Alessandro Rubini.
Original article Copyright
© 1998 by Richard Stallman
di Michael Tiemann
Fondata nel 1989, la Cygnus Solutions è la prima, e secondo un sondaggio della rivista Forbes nell’agosto 1998, di gran lunga la maggiore azienda di Open Source oggi esistente. La Cygnus ha piazzato il proprio prodotto principale, lo GNUPro Developers Kit, quale prodotto compilatore e debugger leader del mercato degli strumenti software integrati. La Cygnus annovera tra i propri clienti i più grandi produttori di software del mondo nonché importanti aziende di settori quali: elettronica di consumo, Internet, telecomunicazioni, office automation, networking, industria aerospaziale e automobilistica. Con la sede centrale a Sunnyvale (California) e filiali ad Atlanta, Boston, Cambridge (Gran Bretagna), Tokyo, Toronto e collaboratori a distanza operanti da varie località dall’Australia all’Oregon, la Cygnus è la maggiore azienda privata del settore del software integrato, più grande di due aziende pubbliche quotate in Borsa e sul punto di rilevare la terza maggiore azienda quotata in Borsa. Con un tasso di crescita annuale superiore al 65% dal 1992, la Cygnus è stata presente per 3 anni di seguito nella classifica delle 100 aziende private a maggior crescita del San Jose Business Journal e ora fa parte della lista delle 500 maggiori aziende di software (lista elaborata in base ai proventi di tutte le aziende produttrici di software del mondo). Nel presente saggio descriverò il modello di Open Source che ha rappresentato la base del nostro successo e come lo stiamo rivedendo e ampliando per il futuro. Il 13 novembre 1989 ricevemmo finalmente la lettera del California Department of Corporations che ci comunicava che la nostra richiesta era stata accolta e che potevano depositare un capitale iniziale di 6.000 dollari e iniziare la nostra attività con il nome di "Cygnus Support". Quel giorno ha rappresentato il culmine di una visione nata oltre due anni prima nonché l’inizio di un viaggio che continua tuttora, a quasi 10 anni di distanza. La visione nacque abbastanza innocentemente. Mio padre un giorno mi disse: "Se hai intenzione di leggere un libro, assicurati di leggerlo dall’inizio alla fine". Come accade con la maggior parte dei consigli paterni, lo applicai soltanto quando mi faceva comodo e, nel 1987, quando mi stancai del mio lavoro e cominciai a interessarmi al software GNU, decisi di leggere il libro pubblicato a proprie spese da Richard Stallman, il Manuale Emacs GNU dall’inizio alla fine. (Il testo fu pubblicato dall’autore a proprie spese perché a quel tempo nessun editore degno di tale nome avrebbe pubblicato un libro che incoraggiava i lettori a fare liberamente copie legali del testo. Anche oggi il concetto è ancora difficile da digerire per alcuni editori). Emacs è un programma affascinante. Al di là della funzione di editor di testo, è stato personalizzato per permettere di leggere e rispondere a email, leggere e scrivere a gruppi di discussione, aprire una shell, far girare il compilatore e fare il debug dei programmi risultanti. Il programma dà persino accesso interattivo all’interprete LISP che lo gestisce. Utenti creativi (o hacker annoiati) hanno esteso Emacs conferendogli caratteristiche bizzarre, quali per esempio il "doctor" mode (programma di psicoanalisi Rogeriana ispirato dal programma ELIZA di John McCarthy), il "dissociated-press" che rimescola il testo in modo da rendere la lettura difficile o spassosa, e addirittura un programma che anima la soluzione delle Torri di Hanoi su una videata di testo. Proprio questa profondità e ricchezza mi spinsero a volerne sapere di più leggendo il Manuale Emacs GNU e il codice sorgente del Emacs GNU. L’ultimo capitolo del libro, il "Manifesto GNU", è una risposta personale dell’autore alla domanda principale che mi aveva attanagliato durante la lettura: perché un programma così eccezionale è disponibile sotto forma di software liberamente distribuibile (Open Source)? Stallman risponde alla domanda più generale: Perché devo scrivere il GNU ? La mia regola d’oro è: se un programma mi piace devo condividerlo con altre persone che lo apprezzano. Chi vende software adotta il metodo divide et impera con gli utenti, facendo in modo che ogni utente non voglia condividere nulla con gli altri. Io rifiuto una tale mancanza di solidarietà. Il manifesto di Stallman dice molto di più – troppo per poter riportare tutto in questa sede. (Un riferimento: http://www.fsf.org/gnu/manifesto.html). Sarà sufficiente dire che in superficie può apparire polemica socialista, ma io vi ho trovato qualcosa di diverso. Nascosto tra le righe vi ho intravisto un progetto commerciale. L’idea di fondo è molto semplice: l’Open Source univa gli sforzi dei programmatori di tutto il mondo e le aziende fornitrici di servizi commerciali (personalizzazioni, implementazioni, correzione dei bug, assistenza) basate su tale software avrebbero potuto capitalizzare sull’economia di scala e sull’ampio richiamo di questo nuovo tipo di software. Emacs non era il solo programma eccezionale creato dalla Free Software Foundation. Vi era il Debugger GNU (GDB), che Stallman dovette scrivere in quanto i debugger della Digital Equipment Corporation (ora parte della Compaq) e della Sun Microsystems semplicemente non erano in grado di fare il debug di un programma così complesso come Emacs. Il programma di Stallman invece, non soltanto era in grado di gestire operazioni consistenti, ma le gestiva con eleganza, con comandi ed estensioni pensati per i programmatori. E poiché il GDB era software open source, i programmatori cominciarono ad aggiungere nuove estensioni che lo resero ancora più potente. Questo tipo di scalabilità non esisteva nel software proprietario. La vera bomba scoppiò nel giugno 1987, quando Stallman pubblicò il Compilatore GNU (GCC), versione 1.0. Lo scaricai immediatamente e utilizzai tutti i trucchi imparati dai manuali di Emacs e GDB per imparare rapidamente tutte le 110.000 linee di codice. Il compilatore di Stallman supportava due piattaforme nella prima versione: la vecchia workstation VAX e la nuova Sun3. Generava con facilità un codice migliore su queste piattaforme rispetto al compilatore dei due distributori. In due settimane riuscii ad adattare il GCC a un nuovo microprocessore (il 32032 della National Semiconductor) e il tempo di elaborazione risultante superava del 20% il compilatore proprietario fornito dalla National. In altre due settimane di lavoro da bravo hacker il delta passò al 40%. (Si è spesso detto che il chip della National scomparve dalla circolazione perché avrebbe dovuto essere un chip da 1 MIPS in concorrenza con il 68020 della Motorola, ma quando fu immesso sul mercato la velocità di clock risultò di soli 0,75 MIPS su benchmark applicativi. Si noti che 140% * 0,75 MIPS = 1,05 MIPS. Quant’è costata alla National la tecnologia di questo compilatore così scarso?) I Compilatori, i Debugger e gli Editor sono i 3 Grandi Strumenti che i programmatori utilizzano quotidianamente. Il GCC, il GDB e l’Emacs erano così superiori ai corrispondenti software proprietari che non potei fare a meno di pensare a quanti soldi si sarebbero potuti fare (per non parlare del beneficio economico) sostituendo la tecnologia proprietaria con una tecnologia che non soltanto era migliore, ma che migliorava più in fretta. Ecco un’altra citazione dal Manifesto GNU : Non c’è nulla di sbagliato nel voler essere pagati per il lavoro che si fa o nel cercare di massimizzare le proprie entrate, a patto che non si faccia uso di metodi distruttivi. I mezzi che si utilizzano oggi nel campo del software si basano sulla distruzione. Spillare soldi agli utenti di un programma limitandone l’uso è distruttivo, poiché tali restrizioni riducono la portata e le modalità in cui un programma può essere utilizzato, limitando la ricchezza che l’umanità può trarre da tale programma. Quando si opera una scelta deliberata di restrizione la conseguenza deleteria è la distruzione deliberata. Il motivo per il quale un buon cittadino non usa mezzi distruttivi per arricchirsi è che, se tutti facessero così, diventeremmo tutti più poveri a causa della distruttività reciproca.
Roba pesante. Il Manifesto GNU è in effetti un documento filosofico. Fa un’attenta analisi della natura del software, della programmazione, della grande tradizione accademica, e conclude dicendo che, a prescindere dalle conseguenze economiche, esistono imperativi etici e morali che impongono di condividere liberamente le informazioni che ci sono state liberamente trasmesse. Personalmente ho raggiunto una conclusione diversa, sulla quale io e Stallman abbiamo spesso discusso: la libertà di utilizzare, distribuire e modificare software prevarrà su qualsiasi modello che tenti di limitare tale libertà. E prevarrà non per motivi etici, ma per motivi di competitività, per le ragioni del mercato. Prima cercai di far valere le mie ragioni alla maniera di Stallman: considerandone i meriti. Spiegai come la libertà di condividere il software avrebbe determinato una maggiore innovazione a costi inferiori, maggiore economia di scala attraverso standard più aperti, ecc. e mi si rispose universalmente: "È una grande idea, ma non funzionerà mai, perché nessuno pagherà mai per del software gratuito". In due anni di rifinitura della mia retorica, delle mie argomentazioni e di discorsi per persone che pagavano per farmi viaggiare per il mondo, non andai mai oltre il: "È una grande idea, ma ..." A questo punto ebbi la mia seconda intuizione: se tutti pensano che sia una grande idea, probabilmente lo è, e se nessuno pensa che funzionerà, allora non avrò nessun concorrente a sbarrarmi la strada!
- F = - ma
Non troverete mai un libro di fisica che presenti la legge di Newton in questo modo. Dal punto di vista matematico, però, la formulazione è valida quanto "F=ma". Il punto di questa osservazione è che se si ribaltano con attenzione alcuni presupposti, si può mantenere la validità dell’equazione, anche se il risultato può apparire sorprendente. Credevo che il modello della fornitura di assistenza tecnica commerciale per il software open source sembrasse impossibile, perché la gente era così colpita dai segni meno dell’equazione da dimenticarsi di calcolare e cancellarli.
SI PUO' RESISTERE
ALL’INVASIONE DI UN ESERCITO, Vi era un interrogativo finale (e profondamente ipotetico) cui dovevo trovare risposta prima di essere pronto ad abbandonare il corso di specializzazione a Stanford e aprire la mia azienda. Supponiamo che invece di essere quasi al verde, avessi avuto i soldi per comprare tutta la tecnologia proprietaria allo scopo di creare un business intorno a questa tecnologia. Pensai alla tecnologia della Sun. Alla tecnologia Digital. Ad altre tecnologie che conoscevo. Per quanto tempo avrei potuto avere successo in quel business prima che qualcun altro iniziasse la propria attività con il GNU e mi spazzasse via? Avrei potuto recuperare perlomeno il mio investimento iniziale? Mi resi conto che fare concorrenza al software Open Source era una prospettiva per nulla allettante. Allora capii che era giunto il momento di realizzare la mia idea.
LA DIFFERENZA TRA
LA TEORIA E LA PRATICA TENDE A ESSERE In questa sezione spiegherò in dettaglio la teoria che sta dietro il modello di business Open Source e come abbiamo cercato di trasformare la teoria in pratica. Iniziamo con alcune osservazioni famose :
I
MERCATI LIBERI SI ORGANIZZANO AUTONOMAMENTE, PERMETTENDO L’USO PIU'
EFFICIENTE DELLE RISORSE PER LA MAGGIORE CREAZIONE DI VALORE POSSIBILE.
L’INFORMAZIONE,
ANCHE SE COSTOSA DA CREARE, PUO' ESSERE RIPRODOTTA E CONDIVISA A UN
COSTO MOLTO BASSO SE NON ADDIRITTURA NULLO.
Il concetto di economia di libero mercato è vastissimo: ogni anno, quando si deve assegnare il Nobel in economia, il premio va all’economista che meglio ha parafrasato Adam Smith. Questa è una mia battuta ricorrente che nasconde però un fondo di verità: esiste un potenziale economico ancora intatto e illimitato che aspetta di essere dominato con l’utilizzo di un sistema di mercato libero più vero per il software. Ai tempi di Adam Smith l’economia di libero mercato arrivava soltanto fin dove una persona poteva viaggiare o commerciare, mentre le attività commerciali di più ampio respiro, in particolare il commercio tra paesi, erano pesantemente controllate. Sino a quando un certo numero di operatori commerciali si stancarono del sistema prevalente basato sull’autorità e si ribellarono, creando un nuovo governo che si sarebbe interessato meno dei loro affari. Fu infatti la libertà a fornire la visione e l’architettura sottostante la Costituzione del governo americano ed è ancora la libertà che sembra essere alla radice di ogni causa o azione nell’agone economico e politico globale dei nostri giorni. Che cos’è che rende la libertà così irrinunciabile? E che cos’è che rende la libertà così fondamentale per la prosperità economica? Risponderemo brevemente a questi quesiti.
PIU' SI COMPRENDE
CHE COSA C'E' CHE NON VA IN UNA CIFRA, Parlando di strumenti per programmatori nel 1989, la situazione del software proprietario naturalmente era disastrosa. Innanzitutto, gli strumenti erano primitivi nelle caratteristiche che offrivano. Secondo, tali caratteristiche, quando erano disponibili, spesso presentavano limitazioni intrinseche che tendevano a bloccarsi quando i progetti cominciavano a diventare complicati. Terzo, l’assistenza delle aziende distributrici era terribile; a meno che non si acquistasse una gran quantità di hardware o si rinnovassero una gran quantità di licenze software di gruppo e si potesse quindi far valere il potere del portafoglio a proprio vantaggio, per il resto, se si incappava in una di queste limitazioni, ci si poteva ritenere sfortunati. Inoltre ogni distributore implementava le proprie estensioni proprietarie, perciò se si utilizzavano le caratteristiche mediocri di una piattaforma, si diventava, inizialmente in modo impercettibile e in seguito in modo sempre più evidente, irrimediabilmente vincolati a questa piattaforma. In definitiva, era chiaro che i benefici dell’economia di libero mercato, per quanto grandi, non funzionavano nel mercato del software. Il modello del software proprietario era molto difettoso, il che lo rendeva oggetto di studio di estremo valore. Oggi, come allora, l’economia di libero mercato vive all’interno delle mura delle aziende di software proprietario (dovere ingegneri e gruppi di prodotto in competizione lottano per accaparrarsi fondi o favori). Al di fuori di queste mura l’utilizzo e la distribuzione di quel software sono controllati pesantemente da accordi di licenza, brevetti e segreti commerciali. Chissà quanto potere e quanta efficienza si perdono mettendo in pratica la libertà a microlivello e non a macrolivello. Lo avremmo scoperto dando vita a un’azienda pronta a dare assistenza tecnica agli utenti a livello di codice sorgente.
L’INVENZIONE E' 1%
ISPIRAZIONE 99% TRASPIRAZIONE.
La visione semplicistica di un’azienda produttrice di software è che una volta che si è creato un software che la gente vuole comprare, produrre copie di quel software e distribuirle non è dissimile dal coniare moneta: il costo del materiale è risibile e il margine praticamente perfetto. Ritengo che un motivo che determinò la situazione negativa del software negli anni 80 fu che ci si concentrò sul perfezionamento del modello astratto del coniare moneta, senza preoccuparsi di che cosa accadeva una volta che la gente cominciava a utilizzare la moneta in pratica. Il concetto di assistenza software era visto come un sottoprodotto generato da pecche nel processo di produzione del software stesso. Riducendo al minimo gli investimenti sull’assistenza software, si sarebbero massimizzati i profitti. Ciò fu negativo non soltanto per gli utenti, ma anche per il software stesso. Caratteristiche semplici da implementare vennero spesso tralasciate in quanto "non strategiche". Senza l’accesso al codice sorgente, caratteristiche implementabili direttamente dagli utenti rimasero oggetto di speculazione e dispute. In ultima analisi furono i distributori (e i loro responsabili marketing) e non gli utenti a determinare il terreno di competizione, con una miriade di caratteristiche inutili, ma facili da usare. L’economia di libero mercato era stata rovesciata.
NESSUNO HA IL
MONOPOLIO DELLA VERITA'.
È tanto bello e giusto avere delle meravigliose teorie su come migliorare il mondo. Un’altra cosa è trovare loro un fondamento tale per cui si reggano da sole. Le aziende di servizi erano rare nel mondo dei prodotti software, vi erano però alcuni casi da studiare in altri settori. Si consideri l’esercizio della professione forense in America (o Gran Bretagna). Il Common Law è disponibile liberamente per tutti coloro che desiderino utilizzarlo. Non c’è bisogno di una licenza per utilizzare la sentenza del caso Roe contro Wade. Al contrario le sentenze, una volta emesse, sono a libera disposizione di tutti. Nonostante tutta questa libertà, gli avvocati sono però tra i professionisti meglio pagati al mondo. Com’è possibile che l’esercizio della professione forense, che non dispone di codice primario proprietario, abbia un tale valore? Non è soltanto l’atto di perseguire la legge ad avere così tanto valore per la gente, è anche il valore cumulativo di tale atto. Se si ingaggia un buon avvocato e nel corso della causa viene emessa una sentenza a proprio favore, il precedente diventa parte della legge. La giustizia non è cieca; è piena di storia. Ciò è analogo al concetto di creare e mantenere standard con software open source. È molto costoso creare uno standard e farlo bene. Ma è molto più costoso lavorare senza standard o cercare di mantenere uno standard se tale standard non è valido. Vi è un grande valore nel disporre di persone che lavorano su software i cui precedenti stabiliranno gli standard di domani. All’inizio credemmo che la gente avrebbe compreso tale valore e ci avrebbe pagato per creare programmi open source di alta qualità che sarebbero di fatto diventati gli standard dell’universo software.
I primi anni
della Cygnus
COMMETTERE SEMPRE
NUOVI ERRORI.
Facemmo uso dei testi della Nolo Press per costituire la nostra azienda, stabilire lo statuto di società ed espletare le varie formalità. Ogni penny che riuscimmo a risparmiare nel primo anno, ci costò in seguito migliaia di volte tanto. (Non è chiaro se sarebbe stato meglio assumere un consulente professionista, poiché la prima consulenza professionale che ricevemmo ci costò centinaia di dollari all’ora, e ce ne costò decine di migliaia in seguito per riparare il danno fatto. Ciò la dice lunga sulla nostra incompetenza a quel tempo in fatto di problemi legali/aziendali, sulla nostra incapacità di trovare la giusta consulenza nonché sull’incompetenza specifica dei molti esperti che cercammo di interpellare). Avendo creato un modello di business del tutto nuovo, creammo anche i nostri particolari concetti di finanza, contabilità, marketing, vendita, informazioni al cliente e assistenza. Tutte queste creazioni ci servirono in modo adeguato per il primo anno di attività, in cui tutto era caotico e ciascuno cercava di svolgere qualsiasi lavoro fosse necessario per farci decollare. Dovettero però essere completamente riviste col crescere della nostra attività.
CYGNUS: SOFTWARE
GRATUITO PER TUTTE LE TASCHE.
Per combattere il caos, lavorammo duramente per rendere il presupposto della nostra attività il più semplice possibile: fornire assistenza tecnica provata per software tecnico provato e utilizzare l’economia di scala per rendere tale attività proficua. Secondo le nostre stime, saremmo stati in grado di fornire qualità di assistenza e capacità di sviluppo superiori da due a quattro volte a quelle del personale interno delle aziende costruttrici e avremmo fornito tale servizio per la metà o un quarto del costo. Non prendemmo in considerazione il resto del software open source perché troppo complicato. Ci concentrammo semplicemente sul fornire alla gente strumenti migliori a un prezzo inferiore e, contratto dopo contratto, diventammo bravi. Stipulammo il primo contratto nel Febbraio 1990 e, per la fine di Aprile, disponevamo di contratti per un valore di 150.000 dollari. Nel mese di Maggio inviammo lettere a 50 possibili clienti che potevano essere interessati alla nostra assistenza e nel mese di giugno ad altri 100. All’improvviso il nostro business divenne realtà. Al termine del primo anno avevamo stipulato contratti di assistenza e sviluppo per 725.000 dollari e dovunque guardavamo trovavamo nuove opportunità. Tutto questo successo comportava però seri problemi. Vendendo i nostri servizi per un costo pari alla metà o un quarto di quello del personale interno delle aziende costruttrici, i contratti stipulati avrebbero avuto un costo totale di realizzazione di 1,5-3 milioni di dollari, e noi disponevamo soltanto di cinque persone in tutta l’azienda: un addetto alle vendite, uno studente universitario part-time e i tre fondatori che facevano un po’ di tutto, dal cablaggio delle reti Ethernet alle bozze di intestazione delle lettere. Quanto avrebbe dovuto crescere il nostro business affinché l’economia di scala avesse veramente effetto? Considerando il nostro ritmo, quante altre nottate di lavoro avremmo dovuto fare per arrivare all’obiettivo? Nessuno lo sapeva, poiché non disponevamo di alcun modello finanziario o operativo.
GNUPro
PRIMO: STABILIRE
UNA BASE FERMA.
Lasciammo quindi perdere i nostri progetti di supporto per shell, file utility, software di controllo del codice sorgente e persino il progetto di scrivere un kernel libero per il 386 Intel, e ci concentrammo sulla vendita del compilatore e debugger GNU come prodotto pronto per l’uso. Esisteva circa una dozzina di aziende che vendevano compilatori a 32 bit prodotti da altri e un’altra dozzina di gruppi di compilatori di aziende quali Sun, HP, IBM, ecc. I nostri calcoli dimostravano che impadronendoci del mercato dei compilatori a 32 bit, saremmo diventati abbastanza grandi da poter fare tutte le altre grandi cose che ci eravamo prefissati originariamente (un gestore completo Open Source, simile al modello di outsorcing EDS dei sistemi IBM). Il compilatore GNU supportava già dozzine di ambienti host e oltre una dozzina di architetture target (io stesso avevo scritto 6 versioni dell’adattatore), il che lo rendeva uno dei compilatori con maggior numero di versioni dell’adattatore di quel tempo. Il debugger GNU girava su circa 5 piattaforme native e molti lo avevano adattato per supportare anche i sistemi integrati. Ingenuamente credevamo che per creare un prodotto pronto per l’uso fosse sufficiente raccogliere i vari pezzi in un unico contenitore, scrivere un README, aggiungere uno script di installazione, trovare qualche prodotto parallelo, testarlo e spedirlo. La realtà era molto diversa. Innanzitutto il GCC era nella fase di transizione dalla Versione 1.42 alla Versione 2.0. Se il GCC Versione 1 era in grado di battere la maggior parte dei compilatori su macchine CISC come m68k e il VAX, erano invece necessarie numerose ottimizzazioni per renderlo competitivo su piattaforme RISC. Quando creai la prima versione dell’adattatore GCC per lo SPARC nel 1988, il GCC era più lento del 20% rispetto al compilatore Sun. Nel 1989 scrissi uno scheduler di istruzioni che ridusse il gap al 10% e lavorai su uno scheduler di diramazione che, insieme allo scheduler di istruzioni, portò il gap al 5%. Con il mondo che passava dal CISC al RISC, passammo dal miglior compilatore sotto quasi tutti gli aspetti a un certo numero di valutazioni più complesse che il cliente avrebbe dovuto fare per decidere. Non si trattava più quindi di una vendita semplice, diretta. Secondo, il GNU C++ cominciava ad essere superato. Scrissi il GNU C++ nell’autunno del 1987, creando il primo compilatore in codice nativo C++ al mondo. Il C++ era un linguaggio molto più complesso di C ed era ancora in evoluzione quando nacque la Cygnus. Nel 1990 molte caratteristiche nuove e più complesse diventarono "standard" e poiché la Cygnus mi distraeva abbastanza, non avevo tempo di aggiornare il GNU C++. Terzo, il GDB era nel caos. Mentre il GCC e il G++ erano rimasti ragionevolmente coerenti, con pubblicazioni regolari da parte di una sede centrale, il GDB risentiva della frammentazione. Gli oppositori dell’open source farebbero notare a questo punto che un vantaggio del software proprietario è che esiste una sola versione "autentica", mentre il software open source può frammentarsi in milioni di versioni incompatibili, senza che alcuna rappresenti lo "standard" legittimo. Poiché non esisteva un detentore forte del GDB, il risultato fu la frammentazione, con centinaia di persone in tutto il mondo che creavano le loro versioni in base alle proprie esigenze. Quarto, noi in effetti non disponevamo di un kit di sviluppo completo: disponevamo di un assemblatore, di un linker e di altre utility binarie (le cosiddette binutils) che funzionavano soltanto su alcune delle piattaforme supportate da GCC e GDB. Se si combinavano le piattaforme supportate da GCC con quelle di GDB combinate a loro volta con GAS, GLD, ecc., il risultato era esattamente zero piattaforme che funzionassero su una base sorgente comune. Quinto, non disponevamo di alcuna libreria C, il che non rappresentava un problema per le piattaforme native come quelle della Sun o della HP, ma un bel problema per chi progettava sistemi integrati e necessitava della completa funzionalità per le proprie applicazioni indipendenti. Sesto, è vero che la concorrenza non aveva nulla di paragonabile alle nostre imprese di ingegneria just-in-time, ma disponeva di prodotti già completi che si vendevano molto bene nelle rispettive nicchie. Con la creazione e vendita di un prodotto pronto per l’uso, trasformavamo il nostro piano di attacco da un’elaborata manovra di affiancamento a un attacco frontale contro aziende con profitti superiori di 10-100 volte ai nostri. Infine vi era la questione della fiducia in noi stessi. L’aspetto positivo dell’essere l’integratore di molti strumenti che si evolvono rapidamente è che la necessità di questo tipo di servizio è assolutamente ovvia. Gli scettici si opponevano al concetto di prodotto Open Source pronto per l’uso sostenendo che non appena avremmo prodotto qualcosa di qualità decente, non ci sarebbe più stato alcun bisogno della nostra attività di assistenza e avremmo chiuso i battenti nel giro di sei mesi. Questa critica ci sarebbe stata mossa per i 4 anni seguenti.
IL MONDO E' PIENO
DI OPPORTUNITA' INSORMONTABILI.
Non avevamo altra scelta che continuare e, avendo previsto inizialmente 6 mesi per fare il lavoro, decidemmo di "raddoppiare i turni" per farcela. Mi fu assegnato il compito di incrementare la nostra top line di prodotti durante il giorno, e di aiutare a ultimare il lavoro per il GCC 2.0 e il G++ di notte. David Henkel-Wallace (soprannominato Gumby), il secondo fondatore della Cygnus, si occupò delle cosiddette binutils e della libreria, oltre a svolgere la sua normale funzione di Direttore Finanziario e Responsabile dell’Assistenza. John Gilmore, il terzo fondatore della Cygnus, si occupò del GDB. Assumemmo qualcuno per aiutarci a (1) adottare il CVS (un sistema di controllo del codice sorgente dell’open source), (2) scrivere script di configurazione e installazione per gestire le centinaia di piattaforme possibili su cui poteva lavorare il nostro prodotto pronto per l’uso, (3) automatizzare le nostre procedure di test e (4) gestire i nuovi contratti di sviluppo che stipulavamo a ritmo sempre crescente. Sei mesi dopo, il lavoro era cresciuto in modo inaspettato e qualcuno si era ormai stancato di concentrarsi esclusivamente (qualcuno direbbe in modo restrittivo) su un prodotto. Il GNU rappresentava il grosso delle vendite e dei nostri sforzi di progettazione, tuttavia stipulavamo contratti anche per altre tecnologie, quali per es. il Kerberos (software di sicurezza network), l’Emacs e persino il nostro software di bug tracking e test framework (ancora in fase di progettazione a quel tempo). John aveva inviato un messaggio in Rete che diceva più o meno così "D’ora innanzi sarò io il nuovo detentore del GDB. Se volete che le caratteristiche da voi implementate nel GDB vengano mantenute nella prossima versione, inviatemi tutti i vostri sorgenti GDB e io penserò a come integrarli". In sei settimane raccolse 137 versioni di GDB (per lo più versioni pirata della 3.5) ciascuna delle quali aveva una o più caratteristiche da integrare. John cominciò a progettare l’architettura del GDB 4.0 in modo da supportare tutte queste caratteristiche. Chi ero io per obiettare ? Gumby aveva deciso che tutte le utility di file binari dovessero utilizzare una libreria comune che descrivesse tutti i file di oggetto e i formati di debug conosciuti. La ragione di una tale decisione appare chiara se si considera la funzionalità dei vari strumenti che stanno dietro a un compilatore:
Ogni strumento aveva la propria implementazione per la lettura e/o scrittura di formati di file binari, e ciascuna di queste implementazioni aveva livelli diversi di supporto per ogni formato binario : a.out, b.out, coff, ecoff, xcoff, elf, ieee695, e altri. Inoltre, una volta configurato, ogni strumento supportava soltanto un unico formato di file binario. Poteva capitare che una modifica fatta a un assemblatore m68k-a.out dovesse venire applicata anche a tutti gli altri strumenti a.out specifici, o dovesse essere riprodotta quale modifica indipendente da file oggetto. A seconda di come veniva scritta, un’utility poteva rappresentare una modifica a.out specifica per uno strumento e una modifica generica per un altro! Creando un’unica libreria che supportasse tutte le funzionalità su un’unica base sorgente, la realizzazione dell’economia di scala sarebbe stata più rapida in quanto tutto si sarebbe potuto fattorizzare e mantenere in modo coerente. Inoltre sarebbe stato facile dimostrare la possibilità di collegare un codice di oggetto a.out a una libreria coff e generare un ieee695 eseguibile! Gumby cominciò a progettare la libreria e a discutere del progetto con Stallman. Stallman disse che l’impresa era troppo complicata– avrebbe significato riscrivere completamente tutti gli strumenti e sarebbe stato troppo difficile mantenerla. Gumby gli rispose che non era poi "una gran cosa" e diede alla sua creazione il nome di libreria BFD. (Spiegammo ai nostri clienti che BFD stava per Binary File Descriptor, libreria Descrittore di File Binari). Mentre John e Gumby facevano gli hacker, io invece dovevo continuare a vendere per mantenere le entrate. Ogni trimestre mi ponevo nuovi obiettivi sempre più alti che richiedevano l’utilizzo di sempre più risorse per evadere gli ordini conseguiti, mentre tutti gli ingegneri migliori erano impegnati in questo progetto cui io non avevo accesso. Sorsero delle tensioni tra le vendite e la progettazione mentre il modello di Open Source sembrava funzionare al contrario: più si sviluppava il software GNU, meno feedback si otteneva dalla Rete, al punto che arrivammo a fare noi oltre il 50% dello sviluppo del toolkit GNU. E la situazione non era soltanto temporanea. Ci volle un anno e mezzo (!) per ultimare la prima "Versione Progressiva". In quel giorno tanto atteso mi assicurarono che si poteva creare un developer kit completo C e C++ su un’unica base sorgente, e che eravamo in grado di supportare due piattaforme: la Sun3 e la Sun4. Rimasi senza parole. Avevo scritto 6 versioni dell’adattatore GCC, 3 versioni dell’adattatore GDB e un compilatore e debugger in codice originario C++ in un tempo minore di quello impiegato da un team di hacker per far funzionare due kit su un’unica base sorgente!? Vi erano però due fattori mitiganti: (1) gli strumenti funzionavano meglio di quanto avessero mai funzionato prima, con molte caratteristiche nuove e utili, e (2) grazie a tutto il lavoro di infrastruttura eseguito (non soltanto riscrivendo gli strumenti, ma anche implementando uno script di configurazione e un framework di test automatizzato), potevamo prevedere di supportare molte altre combinazioni host/target in futuro, compreso un numero praticamente illimitato di piattaforme di sistemi integrati. Mettemmo alla prova questo framework. L’esito fu brillante.
Mentre gli ingegneri si davano da fare per creare il GNUPro, il team vendite cercava il modo per venderlo. Nel 1991 assumemmo una giovane studentessa di economia, appena licenziata dalla Applied Materials che voleva imparare a vendere software. Sebbene l’inglese non fosse la sua lingua madre, imparava molto in fretta. Non era assolutamente una hacker (anche se trascorse alcuni week-end alla Cygnus per imparare a programmare in C), divenne però un’accesa sostenitrice dell’approccio Open Source. Dopo sei mesi di successi nelle vendite, mi invitò ad assistere a una sua presentazione ai clienti. Rimasi senza fiato. Avevo sempre venduto l’Open Source come lo avrebbe fatto un hacker: puntando principalmente sui vantaggi tecnici. Lei invece spiegò la complessità intrinseca del lavoro che stavamo svolgendo e il valore commerciale del software che fornivamo, il che aiutava a spiegare in ultima istanza ai clienti il motivo per comprare da noi invece di tentare di fare il lavoro da soli. Io vendevo il fatto che i nostri ingegneri erano in qualche modo migliori (messaggio che la maggior parte dei manager non è contento di sentire), mentre lei era in grado di spiegare il vantaggio che i progettisti dei clienti avrebbero derivato dal far fare da noi il lavoro di porting, assistenza e manutenzione di base. Alla fine la nostra abilità tecnica combinata al vantaggio economico portarono a brillanti risultati di vendita.
WATSON ! VIENI
QUI!
I nostri sforzi hanno prodotto numerose nuove tecnologie ridistribuite in Rete e divenute standard di fatto: il GNU configure (script di configurazione generico in grado di configurare software in base a tre variabili indipendenti: una piattaforma di costruzione, una piattaforma host e una piattaforma target), autoconf (script di livello superiore per la creazione di script di configurazione), automake (un generatore di makefile per ambienti autoconf), DejaGNU (framework di test a regressione), GNATS (sistema di gestione del problem report) e altri. Oggi il toolkit GNUPro supporta oltre 175 combinazioni host/target, quantità limitata dall’oggettiva diversità del mercato e non dalla nostra tecnologia di pubblicazione o configurazione. Al contrario GNUPro ha assunto una tale predominanza sul mercato che alcune aziende concorrenti hanno annunciato di voler vendere supporto commerciale per il software GNU in concorrenza con noi! Per nostra fortuna il modello Open Source corre nuovamente in nostro soccorso. A meno che non riesca ad eguagliare gli oltre 100 ingegneri di cui disponiamo oggi, la maggior parte dei quali sono i principali autori o detentori del software da noi supportato, la concorrenza non riuscirà mai a scalzarci dalla posizione di "vero sorgente GNU" (forniamo oltre l’80% di tutte le modifiche del GCC, GDB e utility collegate). Il massimo che possono sperare di ottenere è aggiungere caratteristiche incrementali per le quali i loro clienti siano disposti a pagare. Ma dato che il software è Open Source, qualsiasi valore aggiungano ritornerà alla Cygnus sotto forma di software open source perché venga da noi integrato, se valido, oppure ignorato se non lo è. Al contrario del software proprietario in cui le aziende concorrenti si scontrano in una lotta su due fronti con un vincitore e un perdente, nel caso dell’Open Source la battaglia avviene come in una striscia di Moebius, in cui tutto finisce dalla parte del detentore principale. Quindi, anche se la concorrenza potrà avvantaggiarsi tatticamente entrando nello spazio GNU, la Cygnus trarrà comunque i benefici sul lungo termine. Essendo nati nel 1989, abbiamo un vantaggio di dieci anni rispetto alla concorrenza.
Sfide
Buon senso
Economia di
scala
Durata
Profitto
Gestibilità
Possibilità
di investimento
Vi immaginate dover vendere un contratto di assistenza da 10.000 dollari a un manager responsabile di un gruppo di programmatori di sistemi integrati, e rimanere bloccati sul quesito se la Cygnus può venire allo scoperto dato il modello commerciale adottato? L’Open Source apriva molte strade verso i gruppi di progettisti software migliori e più innovativi, ma si trasformava in un ostacolo quando si cercava di venderlo sul mercato di tradizionale. Stavamo per sperimentare di prima mano quel che Geoffrey Moore aveva scritto nel suo libro "Crossing the Chasm". L’ostacolo diventò evidente quando feci visita a un gruppo di progettisti che stavano creando sistemi di comunicazione senza cavo presso un’azienda annoverata tra le 100 di Fortune. Il processo di qualità che adottavano non valutava soltanto la qualità interna, ma anche quella dei distributori, in base a determinati parametri. La maggior parte dei loro distributori rientrava nella categoria "Molto Buono/Ottimo" in quasi tutti i parametri. I fornitori di strumenti integrati, invece, erano messi veramente male: "Scarso o Insufficiente" in tutte le categorie per tutti i tre anni in cui venne utilizzato questo sistema di monitoraggio qualità. Non intendevano tuttavia acquistare i nostri strumenti perché, nonostante le testimonianze a nostro favore (addirittura da parte dei loro stessi clienti!), le caratteristiche tecniche superiori e il prezzo più basso, il management non voleva scegliere una soluzione sconosciuta. Me ne andai chiedendomi perché si erano presi la briga di raccogliere dati per poi non utilizzarli. Mi ponevo però la domanda sbagliata. Avrei invece dovuto capire che questo era il tipico comportamento del mercato tradizionale, e che per risolvere il problema non bisognava dare la colpa al cliente, ma migliorare il nostro marketing e il nostro messaggio. I nostri problemi non provenivano però soltanto dall’esterno. Molti clienti non credevano che fossimo in grado di assumere personale a sufficienza per far crescere la nostra attività di supporto al di là di quello che dicevamo essere il nostro stato attuale. Si sbagliavano e avevano ragione. Si sbagliavano a riguardo degli ingegneri che eravamo in grado di assumere. La Cygnus era stata fondata da ingegneri e la nostra cultura, il modello Open Source, nonché l’opportunità di far parte del team di progettazione di Open Source più importante al mondo ha sempre reso la Cygnus molto appetibile per i progettisti. Il nostro turnover, se paragonato alla media nazionale (specialmente se paragonato alla media della Silicon Valley) va da un quarto a un decimo di quello delle altre aziende. Quando si trattava però di trovare manager era tutta un’altra storia. Condividendo molte delle preoccupazioni e pregiudizi comuni ai nostri clienti del mercato tradizionale, gran parte dei manager da noi contattati non era interessata a lavorare per la Cygnus. Quelli che lo sarebbero stati non ne erano particolarmente attratti. Quelli che ne erano attratti, spesso lo erano per le ragioni sbagliate. Disponevamo già di 50 ingegneri quando finalmente riuscimmo ad avere 2 manager per la progettazione. La comunicazione, il processo, il controllo di gestione, la soddisfazione dei dipendenti: tutto crollava mentre i nostri manager cercavano di capire, spesso con scarso successo, che cosa significasse essere e gestire una azienda di Open Source. Ironicamente, arrivammo addirittura a scartare manager che non erano disposti ad accettare la creazione di componenti closed source. L’Open Source era una strategia commerciale, non una filosofia, e non volevamo assumere manager non abbastanza flessibili da gestire sia prodotti open source che closed source per raggiungere gli obiettivi generali dell’azienda. Alla fine dovemmo accettare il fatto che non si può pensare di assumere manager in grado di comprendere subito tutte le implicazioni del software open source. Ci si deve aspettare che i manager possano commettere degli errori (il che significa che il budget deve prevedere questi errori) e imparino da tali errori. La maggior parte dei manager che apportano le loro esperienze cercano di cambiare le cose per adattare la situazione alle loro esperienze – ricetta sicura per fallire alla Cygnus. È stato molto difficile trovare manager in grado di lavorare in base alle esperienze fatte e di imparare velocemente dalle esperienze nuove. E ce ne servivano a dozzine. Il modello Open Source, con tutti i suoi problemi, si è dimostrato particolarmente resistente. Anche se occasionalmente abbiamo perso dei clienti per non avere compreso esattamente le loro aspettative o per difetti nell’esecuzione, il tasso annuale di rinnovo dei contratti dal 1993 è rimasto del 90% circa per dollaro di valore e la ragione principale per cui abbiamo perso dei clienti è la "chiusura": la conclusione del progetto del cliente. Due fattori ci hanno aiutato a sopravvivere laddove altre aziende avrebbero fallito: (1) ciascuno, a prescindere dal titolo o dagli anni di servizio, riconosceva l’importanza del rispettare gli impegni con il cliente (nessuno era "al di sopra" dell’assistenza cliente), e (2) quando tutto il resto falliva, il cliente aveva il diritto di fare da solo (perché tutti i clienti disponevano del codice sorgente). Così, nonostante il tumulto di quel periodo alla Cygnus, furono pochissimi i clienti abbandonati perché il software non funzionava, in netto contrasto con le tristi storie che si sentivano sulla concorrenza del software proprietario e su chi usava software open source senza assistenza.
Trovare fondi
oltre l’Open Source: eCos
Tra i distributori di semiconduttori e gli OEM vi sono centinaia di piccole aziende produttrici di software che vendono tutte la loro merce. Per esempio, sul mercato oggi esistono oltre 120 Sistemi Operativi Real Time (RTOS) con assistenza commerciale. Secondo la IDC nessuno di questi ha una quota di mercato superiore al 6%. È come il mondo Unix dieci anni fa, solo con una frammentazione 20 volte superiore! Tale frammentazione porta a tutti quei casi di degenerazione tipici dell’economia di libero mercato: eccedenza, incompatibilità, truffe sui prezzi, ecc. L’obiettivo originario dei distributori di semiconduttori e degli OEM era realizzare standard che avrebbero accelerato il TTM (Time To Money, tempo per fare soldi) e i distributori commerciali di RTOS o erano troppo lenti o costavano troppo, o entrambi. Noi eravamo la stella nascente del mercato dei sistemi integrati: crescevamo a un ritmo due volte superiore a quello del leader del settore e riuscivamo a contenere il livello di crescita dei nostri quattro concorrenti principali al di sotto del 10%. Ciononostante non eravamo trattati e non ci comportavamo da veri leader del mercato. Nel 1995, dopo molte discussioni con i nostri maggiori clienti in merito a che cosa funzionasse e che cosa non funzionasse nei loro sistemi integrati, cominciammo a renderci conto che i compilatori e i debugger GNU di nostra creazione non potevano andare oltre nel risolvere questo tipo di problemi. Quello che realmente serviva ai nostri clienti era un livello di affinamento del silicio – un livello di software sottostante la libreria C standard o un POSIX API real time. Avevamo trovato una nuova opportunità per espandere l’offerta del nostro prodotto. Affilammo le armi e considerammo l’ovvio: gli oltre 120 RTOS commerciali e gli 1000 RTOS delle aziende costruttrici dimostravano che a livello tecnico nessuno aveva ancora creato un RTOS sufficientemente configurabile per poter realizzare la "taglia unica" e, dal punto di vista commerciale, ci rendevamo conto del fatto che i diritti di run-time riducevano drasticamente i margini. L’RTOS non doveva quindi essere vincolato da diritti. In altre parole, per consolidare il mercato su un’unica soluzione, era necessario creare una tecnologia completamente nuova a livello mondiale e fornirla gratuitamente. Il management menò il can per l’aia per un anno prima di mettercisi veramente al lavoro. Una volta deciso di andare avanti con questa strategia, il nostro team manageriale continuò a tormentarci con la domanda "Come faremo i soldi?" Benché il GNUPro continuasse a consolidarsi sul mercato, ancora non era chiaro al nostro team come sarebbe stato possibile ripetere il modello per un sistema operativo integrato. Facemmo la cosa più intelligente che ogni azienda fa quando si trova ad affrontare un problema del tutto incoerente: facemmo delle supposizioni. Supponendo che avremmo trovato il modo per fare soldi, ci chiedemmo quali fossero le altre n cose da farsi per risolvere i problemi dei nostri clienti e diventare il numero uno sul mercato. (1) Bisognava sviluppare questa nuova strabiliante tecnologia di configurazione, (2) bisognava creare il resto del sistema in modo che anche la gente avesse qualcosa da configurare, e (3) bisognava fare tutto prima che l’opportunità di mercato svanisse. Sviluppare software costa, sviluppare software orientato a un prodotto entro un limite di tempo stabilito costa molto caro. Quando iniziammo l’attività della Cygnus tutti pensavamo che la comunità dei finanziatori non avrebbe mai capito quello che stavamo facendo, e se lo avesse capito, ciò sarebbe accaduto perlomeno con cinque anni di ritardo, quando ormai non avrebbe più potuto fare nulla di utile per noi. Fortunatamente ci sbagliavamo su entrambi i fronti. Il nostro primo membro esterno del consiglio di amministrazione, Philippe Courtot, non perse tempo e nel 1992 mi presentò a importanti finanziatori. Spiegai chiaramente a tutti il nostro modello, la nostra tecnologia e i nostri obiettivi per il futuro e fui anche molto chiaro sul fatto che avevamo ideato la Cygnus quale entità autofinanziata e che quindi non avevamo bisogno dei loro soldi. In effetti, il fatto che la nostra redditività aumentasse di un punto percentuale all’anno, mentre l’azienda cresceva annualmente dell’80% era una bella indicazione (per quanto ne sappia io) che il nostro business stava maturando molto bene. Roger McNamee, analista di punta del settore software nella comunità dei finanziatori, espresse al meglio la situazione quando disse "Il vostro modello di business mi stupisce e mi sorprende. Mi stupisce che stia funzionando così bene, ma più ci penso e più mi sorprendo di non averci pensato io per primo!" Se da un lato ci gratificava aver eliminato il problema e non avere bisogno di finanziamenti esterni, la realtà era che nel 1996 avevamo creato così tante opportunità oltre al business autofinanziato del GNUPro al punto da avere bisogno di un nuovo piano e di nuovi soci. Trovammo due investitori, la Greylock Management e la August Capital che compresero ciò che stavamo facendo e come, e compresero quel che avremmo potuto fare sotto la giusta guida e disciplina. Disponevano inoltre di capitale sufficiente a concretizzare il nostro progetto. Nella prima metà del 1997 investirono 6,25 milioni di dollari, il più grande investimento privato per un’azienda software, e subito si diede inizio all’esecuzione del progetto.
NON MI PIACCIONO,
SONO SAM. NON MI PIACCIONO LE UOVA VERDI E IL PROSCIUTTO.
Se da una parte il team tecnico continuava la scalata, il team vendite continuava a tormentarsi su come si sarebbero fatti i soldi, poiché inizialmente non era chiaro il nesso tra l’architettura di eCos e il modello di business da utilizzare per commercializzarlo. Sul fronte tecnico sapevamo che la configurabilità del sistema era la chiave per creare un’architettura a "taglia unica". Dal punto di vista commerciale, sapevamo che la "taglia unica" era la chiave per creare uno standard unitario e vantaggioso per lo sviluppo dei sistemi integrati. Ancora non capivamo, però, chi sarebbe stato disposto a pagare per un tale vantaggio. I due team lavorarono indipendentemente per un anno e mezzo. I costi per la Ricerca e Sviluppo salirono alle stelle. Incapaci di conciliare il paradosso dell’Open Source, molti manager dovettero arrendersi. Quando i tecnici furono finalmente in grado di dimostrare quanto si erano prefissi sin dall’inizio, allora per il team vendite fu finalmente chiaro ciò che si stava creando: la prima architettura Open Source al mondo. Per me il momento fu così esaltante come quando per la prima volta vidi il GCC. L’Open Source è una gran bella cosa per gli hacker, e il modo in cui l’Open Source è in grado di creare standard è importante per l’utente finale, ma esiste un divario tra quanto gli hacker sanno fare con il software open source rispetto agli utenti normali. Volevamo che eCos fosse un prodotto apprezzato anche dal programmatore di sistemi integrati tradizionale, non soltanto dalla comunità degli hacker. La nostra idea era di dotare gli utenti di strumenti ad alto livello per configurare, personalizzare e validare eCos in modo automatico, sostituendo le operazioni manuali che i progettisti RTOS delle aziende costruttrici attualmente svolgono. Facendo in modo che gli strumenti ad alto livello controllassero eCos a livello di codice sorgente e strutturando il codice sorgente in modo tale da poter essere gestito da questi strumenti, davamo agli utenti finali la possibilità di lavorare praticamente a livello di codice sorgente senza dover nemmeno leggere o scrivere una riga di codice C o C++. La dimostrazione del nostro successo è che eCos può passare da 700 byte (livello minimo di affinamento del silicio) a oltre 50 Kbyte (RTOS completo con stack Internet e file system)! Una volta compreso che l’Open Source non era soltanto una caratteristica, ma il perno di eCos, e una volta dimostrato che con tale caratteristica la nostra performance era 10 volte tanto quella della concorrenza (risparmio di spazio sulla configurabilità a livello di oggetti di 10 volte superiore ed efficienza di programmazione da 10 a 100 volte superiore su RTOS con sorgente disponibile, ma non con architettura sorgente), preparammo pacchetti di soluzioni pronti da presentare sul mercato contenenti questi incredibili vantaggi di performance, e la prima risposta del mercato fu estremamente positiva. Se si considerano i limiti del vecchio GNU, si può soltanto immaginare che cosa potrà portare eCos alla Cygnus Solutions e al mondo intero.
Riflessioni e
visioni del futuro
Creato da software open source, Internet è stato una base eccezionale per lo sviluppo di nuovo software open source. La gente continua a connettersi a Internet e grazie all’Open Source assisteremo a cambiamenti nello sviluppo e utilizzo del software, così come nel Rinascimento si assistette al mutamento del nostro modo di sviluppare e utilizzare la conoscenza accademica. Con la libertà data dal software open source, è il minimo che può succedere!
SI MISE A LAVORARE
AD ARTI SCONOSCIUTE,
Progettazione del software di Paul Vixie
La progettazione software è un campo più vasto che non lo "scrivere programmi". Tuttavia, in molti progetti Open Source, i programmi vengono semplicemente scritti e distribuiti. Ci sono chiari precedenti storici del fatto che il software non richiede necessariamente di essere progettato per poter essere usato largamente e con soddisfazione. In questo saggio vedremo alcuni elementi generali di progettazione software, quindi i corrispondenti di questi elementi nella comunità Open Source e infine le implicazioni delle differenze fra i due approcci.
Il processo di progettazione software
Nessuno degli elementi di questo processo dovrebbe avviarsi prima che i precedenti siano sostanzialmente completati e ogni qualvolta viene operata una modifica a qualche elemento, tutti gli elementi dipendenti dovrebbero essere revisionati o rifatti alla luce di quella modifica. È possibile che un dato modulo sia specificato e implementato prima che i moduli da questo dipendenti siano stati completamente specificati: questa pratica è nota come sviluppo avanzato o ricerca. È assolutamente essenziale che ogni elemento della progettazione software includa diversi tipi di revisione: revisione dei pari, revisione del consulente/della dirigenza e revisione interdisciplinare. Gli elementi della progettazione software (si tratti di documenti o di codice sorgente) devono avere numeri di versione e una storia verificabile. "Registrare" una modifica a un elemento dovrebbe richiedere una qualche forma di revisione, e la profondità della revisione dovrebbe corrispondere direttamente allo scopo della modifica.
Requisiti di marketing In molti progetti finiti male il MRD era stato tramandato come fosse una tavoletta di pietra con iscrizioni dal marketing ai progettisti, che avrebbero quindi piagnucolato incessantemente contro le leggi della fisica e su come fosse loro impossibile costruire il prodotto data la mancanza di scorte di Kryptonite o di chissà cosa. Il MRD è uno sforzo congiunto, in cui i progettisti non solo revisionano, ma anche scrivono gran parte del testo.
Progetto a livello di sistema La progettazione a livello di sistema dovrebbe anche delineare il piano di testing a livello di sistema, in termini di necessità del cliente e se esse siano soddisfatte dal progetto di sistema proposto.
Progetto dettagliato Ogni modulo ha bisogno di un piano di test di unità, che dica agli implementatori quali situazioni di test o quale tipo di situazioni di test essi debbano generare nei loro testing di unità per verificare la funzionalità. Si noti che ci sono test di unità aggiuntivi e non-funzionali che verranno discussi in seguito.
Implementazione Un modulo può considerarsi implementato quando è stato creato, testato e usato con successo da alcuni altri moduli (o dal processo di testing a livello di sistema). La creazione di un modulo consiste nel classico ciclo scrittura-compilazione-ripetizione. Il testing dei moduli include il test funzionale a livello di unità e il test di regressione richiamati dal progetto dettagliato, e anche il testing di prestazione/stress e l'analisi di copertura del codice.
Integrazione L'integrazione include lo sviluppo di un test a livello di sistema. Se il pacchetto creato deve potersi installare da sé (il che può significare tanto scompattare un archivio compresso quanto copiare dei file da un CD-ROM), allora dovrebbe esserci modo di farlo automaticamente, su sistemi di crash & burn dedicati o in ambienti di contenimento/simulazione. Talvolta, nell'arena del middleware, il pacchetto non è che una raccolta di sorgente costruita, nel qual caso non esisterà strumento d'installazione e il testing di sistema dovrà essere fatto sulla raccolta così costruita. Una volta che il sistema sia stato installato (se installabile), il processo automatizzato di testing a livello di sistema dovrebbe essere in grado di invocare ogni comando pubblico e di richiamare ogni punto pubblico di entrata, con ogni immaginabile combinazione di argomenti sensata. Se il sistema è in grado di creare un database di qualsiasi tipo, allora il testing automatizzato a livello di sistema dovrebbe crearne uno e quindi usare strumenti esterni (scritti separatamente) per verificare l'integrità del database. È possibile che i test di unità provvedano ad alcuni di questi bisogni, e tutti i test di unità dovrebbero essere eseguiti in sequenza durante i processi d'integrazione, costruzione e confezione.
Testing sul campo Risulterà alla fine necessario eseguire il software esternamente, cioè sui computer dei clienti (o possibili tali). È consigliabile, per quest'esercizio, scegliere clienti "amichevoli", dal momento che è probabile che troveranno molti difetti, alcuni anche banali e ovvii, semplicemente perché i loro schemi d'uso e le loro abitudini saranno probabilmente diversi da quelli dei vostri utenti interni. Durante il testing sul campo esterno, gli sviluppatori del software dovrebbero restare presso il fronte di questo percorso di scalata. I difetti riscontrati durante il testing sul campo debbono passare al vaglio dei capo-sviluppo e degli esperti del marketing tecnico, per determinare quali possano essere riparati nella documentazione, quali debbano essere riparati prima che la versione corrente venga rilasciata e quali possano essere riparati nella release successiva (oppure mai).
Supporto Proprio come l'MRD era uno sforzo congiunto di progettazione e marketing, così il supporto è uno sforzo congiunto fra progettazione e servizio clienti. I terreni di battaglia in quest'impresa sono le liste dei bug, la categorizzazione di particolari bug, il numero massimo di difetti critici ammesso in una release software distribuibile, eccetera.
Dettagli del testing
Considerate il seguente, piuttosto tipico frammento di C:
Se la variabile d'errore non è stata inizializzata, allora il codice è difettoso, e se mai la riga 2 venga eseguita, il risultato del resto del programma sarà indefinito. La probabilità che un errore in read (e che esso restituisca un valore di ritorno di -1) occorra durante un testing normale è abbastanza bassa. Il modo per evitare eventi costosi in termini di supporto causati da questo tipo di bug è assicurarsi che i vostri test di unità tentino ogni possibile path del codice e che i risultati siano corretti in tutti i casi. Ma aspettate: il meglio viene adesso. I path del codice sono combinatori. Nel nostro esempio, la variabile d'errore può essere stata inizializzata prima: per esempio, da un simile frammento di codice il cui predicato ("fallimento della chiamata di sistema") era falso (cioè, nessun errore era occorso). L'esempio che segue, di codice patentemente difettoso che non avrebbe comunque alcuna chance di passare una qualsiasi revisione di codice, mostra come sia facile che delle cose semplici diventino complicate:
1. if (connect(s, &sa, &sa_len) == -1)
Ci sono ora quattro path di codice da testare:
È di norma impossibile testare ogni possibile path del codice: possono essercene centinaia perfino attraverso una piccola funzione di poche dozzine di righe. E d'altra parte, limitarsi ad accertare che i vostri test di unità siano in grado (magari in riprese successive) di usare ogni linea del codice, non è sufficiente. Questo tipo di analisi della copertura non si trova nella valigia degli attrezzi di qualunque progettista software nel campo: ed ecco perché il QA (Questions & Answers) è la sua specialità.
Test di regressione Nel caso più comune, il bug non risulta evidente all'ispezione e il rimedio si troverà in una parte del codice sorgente diversa da quella in cui il programma ha smarrito il core o comunque si è comportato irregolarmente. In questi casi, dovrebbe essere scritto un nuovo test che usi il path difettoso del codice (o lo stato di programma difettoso o quant'altro) e quindi il rimedio dovrebbe essere verificato su questo nuovo test di unità. Dopo la revisione e il check-in, il nuovo test di unità dovrebbe pure essere sottoposto a check-in, in modo che, se il medesimo bug è reintrodotto più tardi come effetto collaterale o modifica d'altro tipo, il reparto QA avrà qualche speranza di beccarlo prima che lo facciano i clienti.
Progettazione di software Open Source Un caso anche troppo comune di progetto Open Source è quello in cui i soggetti coinvolti si stanno divertendo e vogliono che il loro lavoro sia usato dal maggior numero possibile di persone: per questo lo danno via gratis e spesso senza porre alcuna restrizione alla ridistribuzione. Si tratta magari di gente ch non ha accesso agli strumenti software cosiddetti "di livello commerciale" (analizzatori della copertura del codice, interpreti bounds-checking, verificatori dell'integrità della memoria). E le cose che più sembrano divertirli sono: programmare, confezionare ed evangelizzare: niente QA, niente MRD, di norma niente date di rilascio troppo vincolanti. Rivisitiamo ciascuno degli elementi del processo di progettazione software e vediamo che cosa di solito avviene in un progetto Open Source non sovvenzionato. Fatto per amore.
Requisiti di marketing Il terreno di battaglia per un MRD Open Source è di solito una mailing list o un newsgroup, in cui utenti e sviluppatori, senza intermediari, si scambiano frizzi e lazzi. Il consenso è qualunque cosa con cui lo sviluppatore concordi o di cui si ricordi. La mancanza di consenso si traduce abbastanza spesso in biforcazioni del codice, dove altri sviluppatori cominciano a rilasciare le proprie versioni. L'analogo Open Source di un MRD può essere molto istruttivo ma ha margini pericolosamente taglienti e la risoluzione dei conflitti non è spesso possibile (o nemmeno ci si prova).
Progetto a livello di sistema È qui, più che in ogni altra discrepanza dalle regole normali del percorso della progettazione software, che l'Open Source si guadagna la reputazione di cui gode, di leggera eccentricità. La mancanza di un MRD o anche di un QA come si deve può essere compensata dalla presenza di programmatori realmente in gamba (o di utenti realmente amichevoli), ma quando non c'è progetto di sistema (sia pure solo nella testa di qualcuno), la qualità del progetto si limiterà da se stessa.
Progetto dettagliato È un peccato, perché una quantità di codice buono e altrimenti riusabile rimane in questo modo nascosto. Perfino moduli che non sono riusabili o strettamente legati al progetto in cui sono stati creati, e le cui API non sono parte delle caratteristiche distribuibili, dovrebbero avere linee-guida che spieghino quello che fanno e come richiamarle. È d'immenso aiuto a chiunque altro voglia potenziare il codice, dal momento che bisogna cominciare con il leggerlo e comprenderlo.
Implementazione I progetti Open Source sono il modo in cui la maggior parte dei programmatori sperimenta nuovi stili, siano stili d'indentazione o modi di nominare le variabili, "tentativi di risparmiare memoria" o "tentativi di salvare cicli della CPU" o quello che si voglia. E ci sono alcuni manufatti di grande bellezza che aspettano, racchiusi in archivi compressi un po' dovunque, in cui alcuni programmatori hanno provato uno stile per la prima volta e ha funzionato. Un progetto Open Source non sovvenzionato può avere il rigore e la coerenza che vuole: gli utenti eseguiranno il codice se è funzionale; la maggior parte della gente se ne infischia se lo sviluppatore ha cambiato stile tre volte durante il processo d'implementazione. Agli sviluppatori, generalmente, importa, o se no, basta poco tempo perché imparino che importa. In situazioni come queste, le vecchie osservazioni di Larry Wall sulla programmazione come forma d'espressione artistica vanno esattamente a segno. La principale differenza in un'implementazione Open Source non sovvenzionata è che la revisione è informale. Di solito non c'è consulente o pari che esamini il codice prima che sia rilasciato. E di solito non ci sono test di unità, di regressione né di nessun tipo.
Integrazione Si noti che il newsgroup comp.sources.unix è stato riportato in vita da Rob Braun nel 1998 ed è un luogo molto adatto per annunci di pacchetti software Open Source nuovi o aggiornati. Funge anche da deposito/archivio. È vero, non c'è testing a livello di sistema. Ma, del resto, non c'è nemmeno piano di test a livello di sistema né test di unità. Infatti, gli sforzi Open Source risultano alquanto sguarniti sull'intero fronte del testing (con eccezioni, come Perl e PostgreSQL). Questa lacuna nel testing pre-rilascio, tuttavia, non è una debolezza, come si spiega sotto.
Testing sul campo L'essenza del testing sul campo è nella sua mancanza di rigore. Quello che la progettazione software si aspetta dai suoi testatori sul campo sono schemi d'uso che siano intrinsecamente imprevedibili al momento in cui il sistema viene progettato e costruito: in altre parole, l'esperienza di utenti reali nel mondo reale. I progetti Open Source non sovvenzionati, in questo campo, sono semplicemente imbattibili. Un vantaggio aggiuntivo goduto dai progetti Open Source è la revisione da parte dei pari, cioè da parte di dozzine o centinaia di altri programmatori a caccia di bug tramite la lettura del codice sorgente piuttosto che limitandosi a far girare gli esecutibili pacchettizzati. Alcuni di questi lettori si concentreranno nella ricerca di difetti nella sicurezza, dei quali molti non verranno mai riportati (se non ad altri cracker), ma questo pericolo toglie poco al vantaggio complessivo di avere un numero incalcolabile di elementi esterni al progetto che leggono il codice sorgente. Questi elementi esterni possono davvero tenere uno sviluppatore Open Source all'erta come nessun consulente o dirigente riuscirebbe mai a fare.
Supporto Quando la comunità di produttori Unix incontrò per la prima volta un forte desiderio da parte dei suoi utenti di distribuire software Open Source preconfezionato con i loro sistemi-base, la prima reazione fu più o meno: "fate come vi pare, ma noi non li supporteremo". Il successo di aziende come Cygnus ha portato al riesame di questa posizione, ma lo scontro culturale ha radici piuttosto profonde. Le software house tradizionali, e fra queste i produttori Unix, non sono semplicemente in grado di stilare un piano o un budget per il costo di vendita di un'iniziativa di assistenza quando si danno modifiche non revisionate da parte di innumerevoli elementi esterni. Talvolta la risposta è quella di riportare il software all'interno, farlo passare attraverso il normale processo QA comprendente il testing di unità e di sistema, l'analisi di copertura del codice e così via. Questo può comportare una progettazione inversa dell'MRD e del DDD per fornire un qualche contesto al QA (cioè, a quali funzionalità indirizzare i test). Altre volte, la risposta è riscrivere i termini dell'accordo di assistenza sostituendo ai "risultati garantiti" i "massimi sforzi possibili". In ultima analisi, lo spazio di mercato del supporto del software verrà occupato da chi saprà trarre impulso da tutti questi innumerevoli elementi esterni, dal momento che molti di loro sono gente valida che scrive software valido, e la cultura Open Source è più efficace, in molti casi, nel generare il livello di funzionalità che gli utenti effettivamente richiedono (ne faccia fede Linux contro Windows).
Conclusioni
Alcuni campi mettono più enfasi su certe fasi. Per esempio, i costruttori di ponti ferroviari di solito non si preoccupano tanto di un MRD, del processo di implementazione o del supporto, ma devono stare attentissimi al SDD e al DDD, e naturalmente al QA. Il momento cruciale nella conversione di un "programmatore" in un "progettista software" è quell'istante in cui egli si accorge che la progettazione è un campo e che egli vi può entrare, ma che ciò gli richiederà un'attitudine mentale sostanzialmente diversa, e molto più lavoro. Gli sviluppatori Open Source possono andare avanti per anni con successo prima che la differenza fra la programmazione e la progettazione del software li raggiunga e gliela faccia pagare, e questo per il semplice fatto che i progetti Open Source soffrono in ritardo della mancanza di rigore progettistico.
Questo
capitolo non ha dato che una panoramica molto ristretta della
progettazione software, e (io spero) ha fornito qualche motivazione e
un po' di contesto ai programmatori Open Source perché
contemplino la
possibilità di entrare in questo campo. Ricordate che il futuro
è
sempre un ibrido di tutto quanto di meglio è andato a comporre
il
passato e il presente. La progettazione software non è affare
esclusivo
di quelli che girano con il regolo e quattro penne nel taschino della
camicia: è un campo ricco e vario, consistente di molte, ben
sperimentate tecniche per costruire sistemi di alta qualità, in
particolare sistemi di alta qualità che non sono gestibili
secondo
l'approccio del "geniale programmatore solitario" che è proprio
dei
progetti Open Source.
di Linus Torvalds
Linux si trova oggi ad avere milioni di utenti, migliaia di
sviluppatori e un mercato in espansione. È presente in sistemi
integrati, è usato per il controllo di dispositivi robotizzati e
ha
volato a bordo dello Shuttle. Sarebbe bello poter dire che avevo
immaginato quello che sarebbe successo, che era tutto parte di un mio
piano per la conquista del mondo: ma, onestamente, sono stato colto di
sorpresa. Ho avvertito, sì, la transizione dall'essere l'unico
utente
di Linux all'essercene un centinaio, ma quella da cento utenti ai
milioni mi è sfuggita.
Linux ha avuto successo non tanto grazie al suo intento originario -
essere largamente portabile e disponibile - quanto perché
è basato su
solidi principi di progettazione e su un solido modello di sviluppo. La
portabilità e la disponibilità risultano da queste
robusta fondamenta. All'inizio Linux era indirizzato a un'unica architettura: l'Intel 386. Oggi Linux gira su qualunque cosa, dai PalmPilot alle workstation Alpha, ed è il sistema operativo più soggetto a porting fra quelli disponibili per PC. Se dunque si scrive un programma che gira su Linux, per un'ampia gamma di macchine, quel programma sarà effettivamente "scritto una volta ed eseguito dappertutto". È interessante allora ripercorrere le decisioni che portarono al progetto di Linux, vedere come lo sforzo di sviluppo di Linux si sia evoluto, e come Linux abbia finito per diventare un qualcosa che l'intuizione originale non aveva affatto contemplato. Amiga e il porting su
Motorola In quel modo, gli utenti Amiga si trovarono in effetti un sistema che girava sul 68K. Ma io esiterei a definirlo un porting di Linux riuscito. L'approccio era più o meno quello che avevo adottato io quando mi ero messo a creare Linux: scrivere del codice radicalmente nuovo, che supportasse un'interfaccia di un certo tipo. Possiamo allora definire meglio il porting su 68K come un sistema operativo affine a Linux, che ha portato a una biforcazione della struttura di base del codice. Se,
da una parte, questo primo Linux per 68K non aiutò veramente a
creare
un Linux portabile, fu utile in un altro senso. Quando cominciai a
pensare al porting su Alpha, l'esperienza del 68K mi diede pure da
pensare. Se avessi adottato su Alpha quel medesimo approccio, mi sarei
ritrovato con tre diverse strutture di base del codice che avrei dovuto
supportare per mantenere in vita Linux. Se anche la cosa fosse stata
fattibile quanto alla programmazione, non lo sarebbe stata in termini
di gestione. Come avrei potuto gestire lo sviluppo di Linux, se per
farlo avessi dovuto tener traccia di una struttura di base del codice
nuova di zecca ogni volta che qualcuno avesse richiesto Linux su una
nuova architettura? Quello che invece io volevo fare era un sistema in
cui poter avere uno specifico albero Alpha, uno specifico albero 68K e
uno specifico albero x86, ma tutto su una sola e comune struttura di
base del codice. Microkernel Un microkernel esegue un insieme di operazioni assai più ridotto, e in forma più ristretta: comunicazione dei processi interni, limitata gestione e scheduling dei processi e qualche I/O di basso livello. È chiaro che i microkernel sono meno specificamente collegati all'hardware, dato che molte delle peculiarità del sistema sono demandate allo spazio dell'utente. Un'architettura a microkernel è fondamentalmente una maniera per astrarre i dettagli del controllo dei processi, dell'allocazione di memoria e dell'allocazione delle risorse, in modo che il porting su un chipset diverso non richieda che modifiche minime. È per questo che, al tempo in cui mi misi al lavoro su Linux (1991), si dava per assodato che la portabilità dovesse derivare da un approccio in stile microkernel (si ricordi che in quell'epoca questo era una specie di chiodo fisso per gli informatici). Ma io, che sono un pragmatico, mi ero reso conto che i microkernel a) erano sperimentali, b) erano palesemente più complessi dei kernel monolitici, e c) rispetto a quelli, avevano una velocità d'esecuzione notevolmente inferiore. La velocità è, nella pratica, un fattore-chiave per qualunque sistema operativo: dunque gran parte del denaro per la ricerca veniva allora speso per escogitare un'ottimizzazione dei microkernel, tale che essi potessero eseguirsi alla velocità dei kernel normali. La cosa buffa è che, se si ha la pazienza di leggere quelle relazioni, si scopre che i trucchi adottati dai ricercatori per ottimizzare i microkernel avrebbero potuto agevolmente essere applicati ai kernel tradizionali, per accelerarne l'esecuzione. Fu proprio questo a farmi pensare che l'approccio a microkernel non fosse che un espediente disonesto, volto a ottenere più fondi per le ricerche. Non voglio dire che quei ricercatori fossero disonesti intenzionalmente: può darsi che fossero solo stupidi, o illusi - nel vero senso della parola. La disonestà era il risultato della pressione ossessiva sull'argomento "microkernel" che allora pesava sulla comunità dei ricercatori. Nei laboratori di ricerca informatica, o si studiavano i microkernel oppure i kernel non si studiavano affatto. Restare onesti e resistere alla pressione era dunque difficile per tutti, anche per chi stava realizzando Windows NT. Il team di sviluppo di NT sapeva benissimo che il risultato finale sarebbe stato ben lontano da un microkernel, ma si rassegnò a pagare il suo tributo formale a quell'idea. Devo dire che, per mia fortuna, non dovetti mai subire simili pressioni. L'Università di Helsinki svolgeva ricerca sui sistemi operativi fin dai tardi anni Sessanta, e il kernel di un sistema operativo non più era da noi considerato un soggetto degno di particolari studi. Era giusto, in un certo senso: i fondamenti dei sistemi operativi, e per estensione il kernel di Linux, potevano considerarsi sviscerati già dai primi anni Settanta; quanto è venuto dopo allora è stato, entro certi limiti, un esercizio di autogratificazione. Se si vuole che un codice sia portabile, non è necessario creare un livello astratto per raggiungere la portabilità: bisogna piuttosto programmare con intelligenza. In parole povere, cercare di rendere portabili i microkernel è una perdita di tempo: come costruire un'automobile velocissima e montarvi pneumatici quadrati. L'idea di rendere astratta proprio quella parte che dovrebbe essere veloce come il fulmine - il kernel - è intrinsecamente controproducente. Non è con questo che io voglia dire che la ricerca sui microkernel si esaurisce lì, ma gran parte del problema è una discrepanza negli obiettivi. Quello della maggior parte delle ricerche sui microkernel era la produzione di un ideale teorico, l'invenzione di un progetto che fosse portabile al massimo su ogni possibile architettura. Con Linux, io miravo molto più in basso; m'interessava la portabilità non su sistemi teorici, ma su sistemi reali. Da Alpha alla
portabilità Il kernel di Linux non è concepito per essere portato su qualsiasi architettura. Stabilii che, se l'architettura di destinazione è salda abbastanza nelle sue basi e si attiene a certe regole fondamentali, Linux sarà in grado di supportare quel modello. Per esempio, la gestione della memoria può variare molto da una macchina a un'altra. Dopo aver letto con cura le specifiche sulla gestione della memoria nel 68K, nello Sparc, nell'Alpha e nel PowerPC, scoprii che, pur fra molti dettagli differenti, c'era molto in comune nell'uso della paginazione, nel caching e così via. Queste architetture avevano un denominatore comune su cui scrivere la gestione della memoria del kernel di Linux; in seguito, non sarebbe stato troppo arduo modificare il codice di gestione della memoria secondo i dettagli di un'architettura specifica. Alcuni punti fermi aiutano immensamente a semplificare il problema del porting. Per esempio, se una CPU ha funzioni di paginazione, deve per estensione avere un TLB (Translation Lookup Buffer, area di memoria temporanea di traduzione) che indichi alla CPU come mappare la memoria virtuale perché la CPU possa usarla. Naturalmente, non si può sapere con certezza quale forma debba prendere il TLB: va detto però che la sola cosa che importi sapere è come riempirlo e come svuotarlo quando si decide che debba scomparire. Così, in quest'architettura ben congegnata, si saprà che il kernel dovrà avere alcune parti specifiche per la macchina, ma che la gran parte del codice sarà basato sul meccanismo generale col quale funziona qualcosa come il TLB. Un'altra regola pratica che io seguo è che è sempre meglio usare una costante di tempo di compilazione piuttosto che una variabile: seguendo questa regola, il compilatore ottimizzerà assai meglio il codice. L'astuzia è evidente, dato che permette di scrivere il codice così che sia definito con flessibilità ma ottimizzato facilmente. La cosa interessante di quest'approccio - tentare di definire una solida architettura comune - è che, così facendo, si presenta al sistema operativo un'architettura migliore di quella effettivamente disponibile sulla piattaforma hardware. Questo non è molto intuitivo, ma è importante. Le generalizzazioni che si ricercano quando si fa la ricognizione di un sistema corrispondono spesso alle ottimizzazioni che si desiderano operare per migliorare la prestazione del kernel. Quando si fa una ricognizione abbastanza approfondita di cose quali l'implementazione delle tabelle (o matrici) di pagina e sulla base delle osservazioni fatte si decide, per esempio, che l'albero di pagina dev'essere profondo solo tre livelli, si scopre più tardi che ciò poteva essere fatto solo sulla base di un interesse autentico per alte prestazioni. In altre parole, avendo come meta non la portabilità ma l'ottimizzazione del kernel su una certa architettura, si raggiungerà spesso la medesima conclusione: ovvero, la profondità ideale per il kernel per rappresentare l'albero della pagina è di tre. Questo non è semplicemente un caso fortunato. Spesso, quando un'architettura si scosta in alcuni particolari da un progetto generale solido, è perché si tratta di un cattivo progetto. Così, lo stesso pincipio che porta ad aggirare nella programmazione le specifiche di progetto per raggiungere la portabilità, conduce anche ad aggirare le caratteristiche di progetto difettose e ad attenersi a un progetto generale più ottimizzato. Fondamentalmente, ho cercato di raggiungere un compromesso mischiando il meglio della teoria a una considerazione realistica delle architetture odierne. Spazio del kernel e spazio
dell'utente Altri campi richiedono equilibro. È una buona implementazione? La funzione aggiunta è davvero buona? A volte, anche quando è buona, salta poi fuori che è cattiva l'interfaccia o che l'implementazione di quella funzione implica in qualche modo che non si potrà mai più fare una cosa diversa, né ora né in futuro. Per esempio - anche se questa, per la verità, è una questione d'interfaccia - si supponga che qualcuno abbia implementato sconsideratamente un file system così che i nomi non possano avere di più di quattordici caratteri: la tipica cosa da evitare, dal momento che questa limitazione ha luogo in un'interfaccia che è scolpita nella roccia. Diversamente, quando si cerca di estendere il file system, si resta con un palmo di naso, perché toccherà trovare il modo di inserirvi in quest'interfaccia inferiore, che era bloccata. Ancora peggio, ogni programma che richieda un nome di file potrà aver spazio in una variabile solo per, diciamo, tredici caratteri: se si vuole passargli un nome di file più lungo, lo si manderebbe in crash. Al momento il solo produttore che faccia una scemenza simile è Microsoft. Essenzialmente, per leggere file DOS/Windows c'è questa ridicola interfaccia in cui ogni file aveva undici caratteri, otto più tre. Con NT, che consente nomi più lunghi, Microsoft ha dovuto aggiungere un set completo di nuove routine per fare la stessa cosa che facevano altre routine: solo che queste nuove gestiscono anche nomi di file più lunghi. Ecco un esempio di cattiva interfaccia, che inquina anche i lavori a venire. Un altro esempio lo vediamo nel sistema operativo Plan 9. Qui si trovava una chiamata al sistema veramente ben fatta per migliorare una biforcazione di un processo (process fork): una maniera semplice perché un programma si divida in due e continui a elaborare lungo entrambi i rami. Questo nuovo ramo, che Plan 9 ha chiamato R-Fork (e SGI, più tardi, S-Proc) in pratica crea due spazi separati di processo che condividono uno spazio d'indirizzamento. Questo risulta utile soprattutto nel threading. Linux fa la stessa cosa con la sua chiamata di sistema clone, che qui è però implementata correttamente. Tuttavia, con le routine di SGI e Plan 9 si decise che i programmi con due rami potessero condividere lo stesso spazio d'indirizzamento ma usando stack separati. Di solito, se si usa lo stesso indirizzamento in entrambi i thread, si ottiene la stessa zona di memoria. Ma si ha un segmento di stack che è specifico, così, se si adopera un indirizzo di memoria basato su stack si ottengono in pratica due diverse zone di memoria che possono condividere un puntatore di stack senza sovrapporsi all'altro stack. È un risultato intelligente, ma con un rovescio, e cioè che il dispendio complessivo per mantenere gli stack rende il tutto, all'atto pratico, una vera stupidaggine. Troppo tardi si è capito che le prestazioni andavano in malora, e dal momento che i programmi in uso erano dotati d'interfaccia, non si poté porvi rimedio. Si dovette invece introdurre un'interfaccia aggiuntiva, meglio scritta, perché si potesse alla fine fare un uso sensato dello spazio dello stack. Mentre a un produttore con un marchio è possibile, talvolta, dar la colpa all'architettura, Linux non ha questa libertà. È questo un altro campo in cui gestire lo sviluppo di Linux e prendere decisioni su di esso suggeriscono il medesimo approccio. Da un punto di vista pratico, non mi era possibile gestire un gran numero di sviluppatori che fornivano interfacce al kernel. Avrei perso il controllo sul kernel. Ma dal punto di vista del progetto questa è la cosa giusta da fare: tenere il kernel piccolo e limitare al minimo il numero d'interfacce e di altri vincoli allo sviluppo futuro. Va da sé che nemmeno Linux è esente da peccati. Ha ereditato una quantità d'interfacce orripilanti da implementazioni precedenti di Unix. Dunque, in alcuni casi sarei stato ben felice di non dover mantenere la stessa interfaccia di Unix. Ma Linux è tanto "pulito" quanto può esserlo un sistema operativo che non nasce dal nulla: e se si desidera poter eseguire applicazioni Unix, bisogna accettare il fardello di Unix come conseguenza. Ma ne è valsa la pena, perché poter eseguire quelle applicazioni si è rivelato vitale per la popolarità di Linux GCC Unix stesso è un eccellente esempio di portabilità operata con successo. Il kernel Unix, come molti altri, conta sull'esistenza del C per gran parte della portabilità che gli serve; lo stesso è per Linux. Per Unix, la grande disponibilità di compilatori per C su molte architetture diverse ha reso possibile portarvi Unix. Unix sottolinea dunque l'importanza dei compilatori, che è una della ragioni per cui ho scelto porre Linux sotto la GNU Public License (GPL). La GPL era la licenza del compilatore GCC. Penso che ogni altro progetto del gruppo GNU scompaia di fronte a Linux: l'unico che io tenga in qualche conto è GCC. Molti degli altri li odio con passione: l'editor Emacs, per dirne uno, è orribile. Linux è più grosso di Emacs, ma almeno ha la scusa di esserlo per buoni motivi. Ma, fondamentalmente, i
compilatori sono davvero una necessità primaria. Moduli del kernel Per esempio, Hans Reiser è al lavoro su un nuovo file system che ha appena cominciato a funzionare. È mia opinione che, a questo punto, non valga la pena accingersi alla versione 2.2 del kernel: ma grazie alla sua modularità, se volessi potrei farlo, e non sarebbe nemmeno difficile. La cosa difficile è far sì che i programmatori non si pestino i piedi l'un l'altro. Col kernel 2.0 Linux è veramente cresciuto. È in questa versione che abbiamo aggiunto dei moduli caricabili del kernel, il che ha comprensibilmente migliorato la modularità producendo una struttura esplicita per scrivere i moduli. I programmatori potrebbero lavorare su moduli diversi senza rischio d'interferenza e io potrei mantenere il controllo su quanto viene scritto all'interno del kernel vero e proprio. Dunque, una volta di più, la gestione dell'elemento umano e quella del codice hanno condotto alle medesime decisioni progettuali. Per mantenere la coordinazione fra le persone al lavoro su Linux ci serviva qualcosa come i moduli del kernel: e questa si è rivelata una decisione savia anche dal punto di vista del progetto. L'altra faccia della modularità è meno ovvia e più problematica. Concerne il caricamento del run-time, riconosciuto da tutti come cosa buona ma non di meno fonte di nuovi problemi. Il primo è tecnico, e come (quasi) tutti i problemi tecnici, non difficile da risolvere. Più scottanti le questioni extra-tecniche, per esempio: fino a che punto un modulo è un derivato di Linux, e quindi soggetto a GPL? Quando uscì il primo modulo d'interfaccia, ci fu chi aveva scritto driver per SCO e che rifiutò di rilasciare il sorgente, come la GPL prevede, dichiarandosi invece disposto a fornire i binari per Linux. Fu allora che conclusi, per ragioni morali, che la GPL non era in casi simili applicabile. La GPL richiede che prodotti "derivati da" un altro prodotto brevettato sotto GPL ricadano pure sotto la GPL. Purtroppo, la nozione di "derivazione" è vaga. Nel momento in cui si tenta di tracciare un confine che contenga i lavori derivati, subito sorge il problema di dove tracciarlo. Abbiamo finito per decidere (o, forse meglio: ho finito per decretare) che le chiamate al sistema non venissero considerate come collegamenti al kernel: quanto a dire che ogni programma eseguito sotto Linux non sarebbe stato coperto da GPL. La decisione è stata presa molto per tempo e a tale scopo ho perfino aggiunto uno speciale file read-me (v. appendice B) perché non sfuggisse a nessuno. Questo perché l'industria possa scrivere programmi per Linux senza temere la GPL. Il risultato, per gli autori dei moduli, è stato che era possibile scrivere un modulo proprietario qualora si fosse usata per il caricamento solo l'interfaccia normale. Tuttavia questa è ancora una zona grigia del kernel. Queste zone grigie lasciano forse agio a qualcuno di approfittare dello stato di cose, e questo accade perché la GPL è poco chiara su argomenti come l'interfaccia a moduli. Se qualcuno violasse la normativa usando i simboli esportati in modo tale che sia chiaro che lo fa solo per aggirare la GPL, credo che ci sarebbe materia per perseguire penalmente quella persona. Ritengo, tuttavia, che nessuno intenda abusare del kernel; chi ha mostrato interesse commerciale nel kernel lo ha fatto solo perché interessato ai benefici del modello di sviluppo. La potenza di Linux risiede nella cooperazione comunitaria che c'è dietro non meno che nel codice stesso. Se Linux venisse dirottato, se si cercasse di produrne e distribuirne una versione proprietaria, svanirebbero da quella versione le ragioni del suo richiamo di Linux, che sono le stesse del modello di sviluppo open source. La portabilità oggi Ma l'approccio di Linux alla portabilità è stato benefico anche per la comunità di sviluppatori che gli si è raccolta intorno. Le decisioni che motivano la portabilità consentono anche a un ampio gruppo il lavoro simultaneo su parti di Linux senza ch'io perda il controllo sul kernel. Le generalizzazioni d'architettura su cui Linux si basa mi danno un quadro di riferimento sul quale controllarlo e forniscono un'astrazione sufficiente perché io non debba mantenere biforcazioni del codice rigidamente separate per diverse architetture. Così, nonostante il gran numero di persone che lavorano su Linux, riesco a tener dietro al nucleo del kernel. E i moduli del kernel forniscono un modo ovvio perché i programmatori lavorino indipendentemente su parti del sistema che dovrebbero effettivamente essere indipendenti. Il futuro di Linux Vedremo nuove interfacce, ma - io credo - in gran parte legate ai nuovi sistemi supportati. Per esempio, quando si comincerà a fare clustering, si vorrà dire allo scheduler di pianificare certi gruppi di processi come pianificazioni di gruppo (gang secheduling), e cose simili. Ma, allo stesso tempo, non vorrei vedere una concentrazione esclusiva sul clustering o sulle applicazioni di calcolo intensivo: gran parte del futuro risiede nei computer laptop, o in schede da inserire dovunque ci si trovi. Mi piacerebbe che Linux esplorasse anche queste strade. Ci sono poi i sistemi integrati (embedded), dove non esiste letteralmente interfaccia. Il sistema è accessibile solo per l'upgrade del kernel, forse, ma per il resto rimane invisibile: e questa è un'altra direzione per Linux. Non penso che Java o Inferno (il sistema operativo integrato di Lucent) si affermeranno nel campo dei dispositivi integrati, perché non hanno colto il succo della legge di Moore. Può sembrare giusta, sulle prime, l'idea di progettare un sistema ottimizzato specifico per un particolare dispositivo integrato, ma al momento in cui il progetto sarà praticamente maneggiabile, la legge di Moore avrà abbassato il prezzo dell'hardware più potente, svalutando il potenziale insito nello sviluppo per un dispositivo specifico. I prezzi calano così velocemente che conviene avere sulla scrivania lo stesso sistema che si ha in un dispositivo integrato; la vita sarà più semplice per tutti. Il
multi-processing simmetrico (SMP) è un'area che avrà
sviluppo. Il
kernel 2.2 di Linux gestirà a dovere quattro processori e
verrà
sviluppato fino a supportarne otto o sedici. Il supporto per più
di
quattro processori esiste già, ma non è ancora usabile.
Avere più di
quattro processori, in questo momento, è tempo sprecato. Ci sono
insomma ampi margini di miglioramento. Alcune aree specifiche d'applicazione continueranno a stimolare sviluppi del kernel. I server Web sono stati sempre una sfida interessante, in quanto applicazioni molto impegnative per il kernel. Potrei dire che per me sono un pericolo, perché tale è il riscontro che ho da chi usa Linux come piattaforma di Web serving, che sarei tentato di ottimizzare il kernel a quel solo scopo. Così, mi devo sforzare di ricordare che il server Web è un'applicazione importante, ma non è tutto. Naturalmente, i server Web attuali non impiegano Linux alla sua massima potenza; Apache stesso, per esempio, non gestisce i thread nel modo migliore. Questo tipo di ottimizzazione è stata rallentata dai limiti dell'ampiezza di banda in rete. Al presente, una rete da 10 Mbit viene saturata con tanta facilità che non c'è ragione di ottimizzare oltre. L'unico modo per non saturare reti da 10 Mbit è di avere un'infinità di CGI che lavorino a pieno regime: ma qui il kernel non può aiutare. Ciò che potrebbe fare, piuttosto, è rispondere direttamente alle richieste di pagine statiche e passare le richieste più complicate ad Apache. Quando le reti veloci saranno più diffuse la cosa si farà più interessante, ma al momento ci manca la massa critica di hardware per il testing e lo sviluppo. Cosa
ricavare da tutto quanto precede? Che io voglio che Linux sia sempre
sulla breccia, e se possibile un po' oltre, perché quanto oggi
è "oltre
la breccia", domani sarà sulle vostre scrivanie. Fra quindici anni mi aspetto di veder arrivare qualcuno che dirà "Ehi, faccio tutto quello che fa Linux ma sono più leggero e più scattante, perché il mio sistema non ha un bagaglio di vent'anni sulle spalle". Dirà che Linux è stato creato con il 386 in mente e che le nuove CPU fanno in modo diverso delle cose molto interessanti, e insomma di lasciar perdere quel ferrovecchio di Linux. È più o meno quanto ho fatto io quando ho scritto Linux. E in futuro si potrà esaminare il nostro codice, usare le nostre interfacce e fornire la compatibilità binaria, e quando tutto questo succederà, io ne sarò felice.
di Robert Young In quanto fondatore di una delle aziende leader nell'offerta di software open source, qualunque cosa io possa dire risulterà sospetta ai fini dell'analisi o della ricerca accademica. Il lettore scettico non vedrà questo mio come un contributo decisivo sulla materia, ma semplicemente come una raccolta di storie interessanti, illuminanti o solo curiose sui momenti e sugli eventi che hanno influenzato la vicenda di Red Hat Software. Da dove viene Red Hat? Se mai il crollo del muro di Berlino ci ha insegnato qualcosa, è che il socialismo, di per sé, non era un modello economico sostenibile. Slogan speranzosi a parte, le attività umane non erano in grado di replicarsi senza un solido modello economico a guidarle. Sembrava che Linux questo modello non l'avesse. Concludemmo dunque che l'intero affare Linux era un gran fuoco di paglia. Un fuoco che generava abbastanza contante per mantenere in attivo il nostro modesto business e un certo numero di altri, ma pur sempre un fuoco di paglia. Tuttavia constatammo che questo bizzarro sforzo del Linux OS, anziché collassare, continuava a rinforzarsi. Il numero di utenti era sempre in crescita e le applicazioni che esso supportava, sempre più sofisticate. Cominciammo dunque a studiare con più attenzione lo sviluppo dell'OS. Parlammo con gli sviluppatori-chiave e con gli utenti più intensivi. Più studiavamo, più ci appariva un modello economico solido (per quanto insolito). Era un modello efficace. Cosa ancor più importante, le nostre vendite di Linux, paragonate alle nostre vendite di altri Unix, bastarono a convincerci che questa era una tecnologia vera, con un vero futuro. A questo punto (autunno 1994) eravamo in cerca di prodotti Linux che potessimo vendere presso CompUSA e altre catene importanti della grande distribuzione. Fu così che Marc Ewing e io creammo Red Hat Software, Inc. nel gennaio del 1995. Il resto di questo capitolo illustrerà i tentativi e gli errori nel corso di sviluppo di una strategia commerciale compatibile con quel bizzarro modello economico. Bizzarro quanto volete, questo modello stava producendo un OS straordinario, di grande valore aggiunto per i clienti e remunerativo per i nostri azionisti. Il nostro ruolo, come Red Hat, è di lavorare attraverso Internet con tutti i team di sviluppo all'assemblaggio di circa quattrocento pacchetti software in un sistema operativo usabile. Lavoriamo in modo molto simile a uno stabilimento di assemblaggio di automobili: testiamo il prodotto finito e offriamo assistenza e servizi agli utenti del sistema operativo Red Hat Linux. La "proposta di valore esclusivo" della nostra strategia era, e continua a essere, provvedere alla necessità dei nostri clienti di avere pieno controllo dei loro sistemi operativi dando loro i benefici tecnici del software ridistribuibile liberamente (codice sorgente e una licenza d'uso gratuita) a utenti dell'OS tecnicamente orientati. Come si guadagna con il software libero? È un errore. La maggior parte delle imprese software, siano basate su software libero o proprietario, falliscono. Dato che fino a tempi recentissimi tutte le imprese software erano del tipo proprietario binary-only, è prudente affermare che col modello IP (Intellectual Property) di sviluppo e marketing del software è difficile guadagnarsi da vivere. Lo era anche, naturalmente, cercare l'oro col setaccio durante la corsa all'oro del XIX secolo. Ma quando le società software trovano la vena generano una gran quantità di denaro, proprio come nelle antiche corse all'oro; molti, dunque, decidono di assumersi i rischi per avere l'opportunità di "trovare la vena" anche loro. Nessuno si aspetta che far soldi col software libero sia cosa facile. È bensì una sfida, ma non più grande che con il software proprietario. Di fatto, con il software libero il guadagno si genera esattamente nello stesso modo che con quello proprietario: creando un grande prodotto, commercializzandolo con accortezza e fantasia, prendendosi cura dei clienti e, di lì, costruendo un marchio che sia sinonimo di qualità e di servizio alla clientela. Un marketing accorto e fantasioso, specialmente nei mercati molto competitivi, richiede che si offrano ai clienti soluzioni che altri non possano o non vogliano eguagliare. A questo fine, l'Open Source non è un vincolo ma un vantaggio competitivo. Il modello di sviluppo Open Source produce software stabile, flessibile e altamente personalizzabile. In questo modo, il produttore di software Open Source comincia avendo un prodotto di qualità. Il trucco è immaginare un modo efficace di guadagnare fornendo ai vostri clienti i vantaggi del software Open Source. Inventare dei modelli economici nuovi non è impresa da poco, e le innovazioni in cui la Red Hat si è imbattuta non sono sicuramente applicabili a chiunque o a qualunque prodotto. Ma ci sono alcuni principi che dovrebbero adattarsi a molte imprese software e Open Source. Molte società tentano un approccio Open Source parziale al mercato. Per lo più adottano una licenza che permette la distribuzione gratuita del loro software se l'utente non adopera il software per scopi commerciali; se lo fa, deve pagare all'editore una concessione o un diritto. La definizione di Open Source è "un software che include il codice sorgente e una licenza d'uso gratuita": queste società parzialmente Open Source forniscono il codice sorgente ma non una licenza gratuita. E ricordate: siamo solo all'inizio della diffusione e della crescita delle quote di mercato del software libero. Se al momento non state guadagnando, potrebbe semplicemente essere perché il mercato per il vostro prodotto è ancora piccolo. Ci fa piacere sapere che il Linux OS, in crescita continua, ha un parco utenti stimato di 10 milioni (nel 1998), ma non dobbiamo dimenticare i 230 milioni di utenti DOS/Windows. Nel mercato dei prodotti primari Per rispondere, ci siamo guardati intorno per trovare, fra le altre industrie, quella a noi più affine. Cercavamo un'industria in cui le materie prime fossero gratis, o almeno liberamente disponibili. Abbiamo considerato l'industria legale: le argomentazioni legali non possono essere soggette a marchio di fabbrica o a brevetto. Quando un avvocato vince una causa dinanzi alla Corte Suprema, gli altri avvocati possono usare le argomentazioni da quello presentate senza chiedere permesso. Di fatto, le argomentazioni sono divenute di dominio pubblico. Abbiamo considerato l'industria automobilistica, che riceve le sue parti da un ampio numero di fornitori. Nessuno guida "una macchina": guidiamo una Honda o una Ford o uno qualunque delle centinaia di modelli alternativi di auto assemblate con le parti comuni disponibili per quell'industria. Ben pochi hanno la perizia tecnica per assemblare la propria auto, e chi ce l'ha raramente ne ha il tempo o la voglia. L'assemblaggio e il servizio sono il nucleo del modello commerciale automobilistico. Abbiamo insomma considerato l'industria delle materie prime e cominciato a riconoscere alcune idee. Tutte le maggiori società che vendono prodotti primari, inclusa l'acqua in bottiglia (Perrier o Evian), il sapone (Tide) o la pasta di pomodoro (Heinz), basano le loro strategie di marketing sulla costruzione di marchi forti. Questi marchi devono essere sinonimo di qualità, coerenza e affidabilità. Nella gestione del marchio di questi prodotti primari ci è parso di vedere qualcosa che potessimo emulare. Il ketchup non è altro che pasta di pomodoro aromatizzata. Una cosa del tutto simile al ketchup Heinz ve la potete preparare in cucina senza nemmeno torcere un capello alla legislazione sul copyright. Si tratta in effetti di ingredienti tutti liberamente ridistribuibili: pomodori, aceto, sale e spezie. Com'è, allora, che noi, consumatori, non ci facciamo il ketchup in cucina e invece la Heinz ha l'80% del mercato del ketchup? Non facciamo il ketchup perché è più economico e molto più conveniente comprarlo dalla Heinz, dalla Hunts o dalla Del Monte che farlo da noi. Ma la convenienza non è che una delle ragioni. Da sola, la convenienza suggerirebbe che Heinz, Hunts e Del Monte si spartissero il mercato in parti uguali, perché i loro prodotti sono più o meno ugualmente convenienti. Però, Heinz ha l'80%. Heinz non ha l'80% del mercato perché è migliore. Andate nel Terzo Mondo e prendete cento persone che non abbiano mai assaggiato prima il ketchup. Scoprirete due cose: la prima, che, di fatto, alla gente il ketchup di pomodoro non piace; la seconda, che trovano tutte le diverse marche egualmente sgradevoli. Heinz ha l'80% del mercato del ketchup perché ha saputo definire il gusto del ketchup nella mente dei consumatori di ketchup. Adesso, il marchio "Heinz Ketchup" è così efficace che, come consumatori, noi pensiamo che il ketchup che non esce dalla bottiglia sia in qualche modo migliore di quello che si versa facilmente! Ecco l'opportunità di Red Hat: offrire convenienza, qualità e soprattutto contribuire a definire, nella mente dei clienti, che cosa può essere un sistema operativo. Alla Red Hat, se riusciremo nell'intento di fornire e supportare un prodotto di qualità uniformemente alta, avremo una grande opportunità per stabilire un marchio che i clienti del Linux OS preferiranno, semplicemente. Ma come conciliare la nostra necessità di creare più utenti Linux con quella di assicurarci che questi utenti Linux usino Red Hat? Abbiamo osservato le attività industriali i cui attori traggono vantaggio non malgrado, ma grazie alle attività degli altri attori. Per bere acqua, nella maggior parte dei paesi industrializzati, basta solo aprire il primo rubinetto che capita: e allora, perché Evian vende acqua di rubinetto francese per milioni di dollari su quei mercati? Sotto sotto, sfrutta la paura, largamente irrazionale, che dell'acqua del rubinetto non ci si possa fidare. È per la medesima ragione che molti preferiscono comprare il Red Hat Linux "ufficiale" nella sua confezione per cinquanta dollari quando potrebbero scaricarlo per niente dalla Rete o comprarne una copia non ufficiale in CD-ROM per due dollari. Gioca a vantaggio di Evian il fatto che l'umanità quasi per intero beva acqua: noi dobbiamo ancora creare una quantità di consumatori di Linux prima di avere un mercato in cui vendere il nostro marchio. La sfida è concentrarsi sulla dimensione del mercato, oltre che sulle quote. Quando la domanda dei consumatori per l'acqua in bottiglia cresce, la Evian ne trae vantaggio, anche se molti cominciano con una bottiglia che non è di Evian. Red Hat, come Evian, ha beneficio quando altri fornitori di Linux lavorano bene nell'instaurare un "gusto" per il prodotto. Più utenti Linux in circolazione, più clienti potenziali per il "gusto" Red Hat. Il potere dei marchi si traduce efficacemente nell'industria della tecnologia. Ne abbiamo la prova negli investitori di Venture Capital che di recente hanno investito in molte società di software Open Source. Il solo denominatore comune, finora, fra tutti gli investimenti è stato che le società o i loro prodotti hanno un nome riconoscibile, e sono riconosciuti come prodotti di qualità. In altre parole, hanno costruito un marchio di successo. L'interesse strategico di questo modello per l'industria
dei computer Linux svolge questo ruolo con naturalezza e assai bene. La rimostranza più comune contro il leader di mercato concerne il controllo che quel produttore ha dell'industria. Un nuovo sistema operativo dovrebbe fornire ai suoi utenti il controllo della piattaforma dell'OS e non diventare un altro OS proprietario binary-only il cui titolare conquisterebbe proprio la stessa posizione dominante il mercato di cui i consumatori vanno oggi lamentandosi. Considerate che Linux non è veramente un sistema operativo. È arrivato a descrivere un'intera raccolta di componenti Open Source in maniera molto simile a come il termine "automobile" descrive più un settore industriale che non quella cosa che guidiamo sull'autostrada. Non guidiamo automobili: guidiamo Ford Taurus o Honda Accord. Red Hat è l'equivalente di uno stabilimento di assemblaggio in OS dell'industria dei sistemi operativi basati su software libero. Red Hat ha successo quando i clienti non si percepiscono come acquirenti di un sistema operativo, o anche di Linux, ma prima e sopra tutto come acquirenti di Red Hat. La Honda compra i pneumatici dalla Michelin, gli airbags dalla TRW e la vernice dalla Dupont e assembla queste diverse componenti in un'Accord che arriva con certificazioni, garanzie e tutta una rete di officine di assistenza Honda e indipendenti. Red Hat prende compilatori da Cygnus, server Web da Apache, un X Windows System dall'X Consortium (che l'ha costruito con il supporto di Digital, HP, IBM, Sun e altri) e li assembla in un sistema operativo Red Hat Linux certificabile, garantito e premiato. A spiccata somiglianza dell'industria dell'auto, è compito di Red Hat scegliere quanto considera il meglio delle componenti Open Source disponibili per costruire il miglior OS possibile. Ma il controllo sull'OS non è mantenuto da Red Hat né da alcun altro. Se un nostro cliente non apprezza la nostra scelta di Sendmail e preferisce usare Qmail o un'altra soluzione qualsiasi, non gli mancherà mai il controllo che gli permetterà di farlo. Allo stesso modo, chi compra una Ford Taurus può desiderare di aver nel motore un carburatore con prestazioni più alte rispetto a quelle del carburatore di serie. È perché il proprietario di una Taurus può aprire il cofano della macchina che ha il controllo della macchina stessa. Analogamente, gli utenti Red Hat controllano il Linux OS che usano perché hanno la licenza per aprire e modificare il codice sorgente. Non è possibile competere con un monopolista giocando secondo le sue regole. Il monopolio ha le risorse, i canali di distribuzione, le risorse di ricerca e sviluppo; in breve, ha troppi punti forti. Col monopolio si compete cambiando le regole del gioco a favore dei nostri punti forti Alla fine del XIX secolo il monopolio americano non si affaccendava intorno ai sistemi operativi, ma alle ferrovie. Le compagnie ferroviarie maggiori detenevano un monopolio effettivo dei trasporti fra le città principali. Di fatto, alcune grandi città americane, come Chicago, si erano sviluppate intorno alle grandi stazioni di proprietà delle compagnie ferroviarie. Questi monopoli non furono spezzati costruendo altre ferrovie e facendo pagare i biglietti qualche dollaro in meno. Furono spezzati dal sistema autostradale fra gli stati e dal vantaggio della consegna porta a porta che le compagnie di trasporti su gomma offrivano contro il più limitato sistema di consegna da centro a centro offerto in precedenza dalle ferrovie. Oggi i produttori dei sistemi operativi proprietari attuali possiedono una tecnologia che ricorda molto il possesso delle strade ferrate. Le API di un OS proprietario somigliano ai percorsi e agli orari dei treni. I produttori di OS possono chiedere il balzello che pare loro. Possono anche controllare e cambiare il "percorso" delle API attraverso il sistema operativo a vantaggio delle applicazioni che vendono, infischiandosi bellamente dei bisogni delle applicazioni vendute dai concorrenti. Il più gran vantaggio competitivo di questi produttori di OS è che possono controllare l'accesso al codice sorgente su cui sia le loro applicazioni che quelle dei produttori indipendenti di software (ISV, Independent Software Vendors) devono essere eseguite. Per evadere da questo modello, gli ISV hanno bisogno di un modello di OS in cui il produttore di quell'OS (Linux) non controlli l'OS; dove il fornitore dell'OS sia responsabile solo per la manutenzione dell'OS; e dove l'ISV possa vendere la sua applicazione sapendo che il produttore dell'OS non è per lui la più grande minaccia competitiva. Il richiamo di questo modello di OS ha cominciato a farsi sentire nel mondo del software. Si trova senz'altro dietro la decisione di Corel di portare WordPerfect su Linux, o dietro il porting su Linux del database di Oracle, o dietro il supporto di IBM ad Apache. Il vantaggio offerto da un OS Open Source sugli OS proprietari binary-only è nel controllo dato agli utenti sulla tecnologia che usano. I produttori di OS proprietari, con i loro cospicui investimenti nel software proprietario di cui i loro prodotti consistono, dovrebbero essere pazzi per cercare di pareggiare il vantaggio che noi offriamo ai nostri clienti, dal momento che generiamo una frazione della rendita per utente su cui i produttori degli attuali OS proprietari possono contare. Naturalmente, se il nostro modello tecnologico verrà accettato da un gruppo ampio abbastanza di utenti, i produttori degli OS esistenti dovranno in qualche modo reagire. Ma ci sono ancora alcuni anni prima di doversene preoccupare. Se reagiranno "liberalizzando" il loro codice così come Netscape ha "liberalizzato" il codice di Netscape, ne risulteranno prodotti migliori a prezzi spettacolarmente più bassi. Fosse anche questo il solo risultato dei nostri sforzi, l'industria in generale ne avrà ricevuto un gran servizio. Ma non è certo intenzione di Red Hat fermarsi qui. Come illustrazione dell'importanza del vantaggio del "controllo" del Linux OS, è interessante osservare l'esperienza del Fermilab. Fermilab è il grande laboratorio di ricerca con acceleratore di particelle poco fuori Chicago. Impiega oltre mille fisici di alto livello che necessitano di tecnologia allo stato dell'arte che possa poi poi essere adeguata ai bisogni dei progetti su cui lavorano. Un esempio dei vantaggi di Linux è la sua possibilità di venir usato in laboratori di clustering per la costruzione di super-computer massicciamente paralleli. Il Fermilab ha bisogno di questa funzione, dal momento che vuole accrescere le prestazioni del suo acceleratore. Come risultato di quest'incremento ci si aspetta di dover analizzare una massa di dati per secondo dieci volte superiore all'attuale. Il budget del laboratorio non consente l'acquisizione della potenza di calcolo desiderata dai fornitori esistenti di super-computer. Per questo motivo, e per altri, il Fermilab voleva un Open Source. Red Hat è stata riconosciuta come una delle opzioni Open Source più popolari, e così siamo stati chiamati. Di fatto, ci hanno chiamato sei volte durante i quattro mesi della fase di selezione del sistema prevista dal progetto; non abbiamo risposto nemmeno una volta. Non di meno, il risultato del loro studio è stato di scegliere Red Hat come un OS supportato ufficialmente al Fermilab. La morale è: a) che dobbiamo imparare a rispondere meglio al telefono (l'abbiamo fatto); b) che il Fermilab ha saputo riconoscere che il nostro modello commerciale conferiva loro il controllo sull'OS Red Hat Linux che volevano usare: e questo, che la Red Hat Software, Inc. fosse in grado di supportarli, oppure no. Quindi, si tratti di grandi organizzazioni con ampie esigenze di calcolo o di grandi fornitori di tecnologia informatica (ISV), l'OS Linux fornisce vantaggi ed è libero dalle principali limitazioni di tutti gli OS proprietari binary-only attualmente disponibili. Un'attenta gestione del marchio Red Hat Linux fra i distributori Linux e un'attenta posizione di mercato di Linux fra gli OS alternativi hanno permesso alla Red Hat la crescita e il successo che sta avendo. Licenze, Open Source o software libero La NASA, quel gruppo di persone che di mestiere ne spara delle altre nello spazio coi razzi, ha un modo di dire: "il software non è software senza codice sorgente". Per gli ingegneri della NASA, l'alta affidabilità non è abbastanza. Nemmeno l'affidabilità altissima. Per la NASA, l'affidabilità dev'essere totale. Non possono permettersi lo "schermo blu della morte" con dodici anime in orbita intorno alla terra a milleseicento chilometri all'ora, la cui vita dipende dai loro sistemi. Alla NASA vogliono l'accesso al codice sorgente del software usato per costruire quei sistemi. E vogliono che quel software arrivi con una licenza che li autorizzi a modificare quel sorgente secondo le loro necessità. Ora, io riconosco che uno studio dentistico medio non avrà lo stesso standard di affidabilità da cui dipendono gli astronauti per emettere ai suoi pazienti le fatture della pulizia annuale dei denti, ma il principio rimane. E a differenza che con i sistemi operativi proprietari binary-only, con Linux i nostri clienti possono modificare il prodotto per adeguarlo alle esigenze dell'applicazione che stanno costruendo. Ecco la proposta di valore esclusivo di Red Hat ai suoi clienti. Ecco la proposta che nessuno dei nostri tanto più grandi concorrenti vuole o può offrire. È una proposta di valore che sovverte la nozione consueta di proprietà intellettuale. Invece che usare una licenza per chiudere a chiave gli utenti ed erigere un muro fra loro e il codice, Red Hat vuole una licenza che incarni l'idea stessa di accesso e controllo sul codice sorgente. Qual è dunque una forma di licenza accettabile per poter avanzare questa proposta di valore esclusivo? La risposta non è univoca fra i ragionevoli membri della comunità Open Source. Ma alla Red Hat abbiamo in questo momento le nostre opinioni in materia. Eccole: La nostra definizione di "efficienza" risale ai giorni dello sviluppo di Unix. Prima del 1984, AT&T era solita condividere il codice sorgente dell'OS Unix con qualunque team potesse contribuire a migliorarlo. Quando l'AT&T fu sciolta, l'AT&T risultante non era più confinata alla telefonia. Decise dunque di provare a guadagnare licenziando l'OS Unix. Tutte le università e i centri di ricerca che avevano partecipato alla costruzione di Unix si trovarono di colpo a dover pagare licenze per un OS che avevano contribuito a creare. Ciò non li rese allegri, ma non c'era gran che da fare: dopo tutto, AT&T possedeva il copyright di Unix. Gli altri team di sviluppo avevano aiutato AT&T a discrezione di questa. La nostra preoccupazione è la stessa. Se Red Hat introduce un'innovazione che i concorrenti possono usare, pretendiamo almeno che le innovazioni dei nostri concorrenti siano ugualmente disponibili per i nostri team di progetto. E la GPL è la licenza più efficiente nell'assicurare che questa cooperazione forzata fra i vari team membri continui malgrado l'ambiente competitivo contingente. Non dimenticate che uno dei punti di maggior forza del Linux OS è il fatto che si tratta di una tecnologia altamente modulare. Quando rilasciamo una versione di Red Hat Linux, rilasciamo in realtà 435 pacchetti distinti. Si capisce allora come la licenza abbia anche una dimensione pratica. Una licenza che consenta a Red Hat di rilasciare il software ma non di modificarlo, creerebbe problemi perché gli utenti non potrebbero correggere o modificare il software secondo necessità. Una licenza meno restrittiva, che pretenda che l'utente chieda il permesso all'autore originale prima di apportare una modifica, è ancora un peso eccessivo per Red Hat e per i suoi clienti. Dover chiedere a 435 autori o team di sviluppo il permesso di fare una modifica non appare cosa pratica. Ma non intendiamo farne una questione ideologica. Ci va bene qualunque licenza che ci permetta il controllo del software che usiamo, perché questo ci mette in grado a nostra volta di offrire ai nostri clienti e utenti il vantaggio del controllo, siano essi ingegneri della NASA o sviluppatori di applicazioni gestionali per studi dentistici. Il motore economico dietro lo sviluppo del software Open
Source La comunità Open Source ha dovuto superare lo stereotipo dell'hacker, dello smanettone della domenica, secondo il quale Linux, per esempio, sarebbe l'opera di quattordicenni smanettoni nelle loro camerette. Ecco un bell'esempio di Paura, Incertezza e Dubbio (PID) gettati maliziosamente sull'industria del software dai produttori di sistemi proprietari. Chi vorrà, dopo tutto, affidare le applicazioni critiche della propria azienda al software scritto da un quattordicenne nelle ore marinate a scuola? La realtà non ha niente a che spartire con lo stereotipo. Non che lo "hacker solitario" non sia una figura importante e apprezzabile nel processo di sviluppo, ma i programmatori di questo tipo hanno paternità su una porzione molto piccola del codice che compone il Linux OS. Il creatore di Linux, Linus Torvalds, cominciò a lavorarci mentre era ancora all'università, e molto del codice è opera di sviluppatori professionali presso organizzazioni di software, progettazione e ricerca di primaria importanza. Qualche esempio può comprendere i compilatori GNU e C++ della Cygnus Solutions Inc. di Sunnyvale, California. Il sistema X Windows originò dall'X Consortium (reso possibile dal supporto di IBM, HP, Digital e Sun). Di un buon numero di driver Ethernet sono per larga parte responsabili degli ingegneri della NASA. I driver per periferiche provengono sempre più spesso dai produttori stessi delle periferiche. In breve, creare software Open Source spesso non è tanto diverso dal creare software convenzionale, e il talento dietro l'Open Source è suppergiù lo stesso che si trova dietro il software convenzionale. Grant Günther, all'epoca membro del team di sviluppo database della Empress Software, desiderava che i suoi collaboratori potessero lavorare da casa. Serviva un metodo sicuro per spostare grandi file dal loro ufficio a casa e ritorno. Adoperavano Linux su PC e driver Zip. Il solo guaio era che in quel momento (1996) non esisteva un buon driver Linux per Zip. A Grant si presentò dunque una scelta: buttar via Linux e comprare una costosissima soluzione proprietaria, oppure prendersi un paio di giorni per scrivere un driver Zip decente. Ne scrisse uno e poi lavorò su Internet con altri utenti di Zip per testarlo e rifinirlo. Pensate ora a quanto sarebbe costato alla Red Hat, o a qualunque altra azienda, dover pagare Empress e Grant Günther per sviluppare quel driver. Una stima prudente sarebbe di qualche decina di migliaia di dollari: malgrado ciò, Grant scelse di regalare il suo lavoro. In cambio dei soldi ha avuto una soluzione magnifica al suo problema (mettere i programmatori Empress in grado di lavorare a casa loro) a una frazione del costo delle soluzioni alternative. È questo il tipo di soluzione vincente offerta da modelli cooperativi quali il modello di sviluppo Open Source. Vantaggi unici Per l'incessante delusione della comunità tecnico-informatica, raramente la tecnologia migliore vince, perfino sui mercati più tecnici. Non è che costruire una trappola per topi migliore di altre vi assicuri il successo. Linux non è destinato al successo perché si può installare su macchine con meno memoria di quella richiesta da altri OS, né perché costa meno di altri OS, né perché è più affidabile. Queste sono solo caratteristiche che ne fanno probabilmente una trappola per topi migliore di NT o di OS/2. Le forze che, in ultima analisi, determineranno il successo o la caduta di Linux agiscono su un altro livello. Si tratta, in effetti, di quei fattori di solito raggruppati alla meglio sotto la categoria "posizionamento di mercato". Di recente un alto dirigente della Lotus ci ha chiesto: "Che bisogno ha il mondo di un nuovo sistema operativo?". Linux ce la farà soltanto se non sarà solo "un altro sistema operativo". In altre parole, Linux rappresenta un modello nuovo per lo sviluppo e la diffusione di sistemi operativi, oppure è solo "un altro OS"? Questo è il problema. E la risposta è: Linux e l'intero movimento Open Source rappresentano una rivoluzione nello sviluppo del software che migliorerà profondamente i sistemi di computer che costruiremo adesso e in futuro. Il codice Open Source è una caratteristica. Il controllo è il vantaggio. Ogni azienda vuole controllare il suo software e la caratteristica di Open Source è il modo migliore che l'industria abbia trovato finora per ottenere quel vantaggio. Il grande difetto di Unix Ma le forze della deriva degli Unix sono le stesse che
unificheranno i Linux. In Linux le pressioni sono opposte. Se un fornitore di Linux presenta un'innovazione che diventa popolare sul mercato, gli altri produttori di Linux la adotteranno immediatamente, e questo perché hanno accesso al codice sorgente di quell'innovazione, che del resto arriva con una licenza che permette a chiunque di usarla. Un esempio di come ciò funzioni è proprio il medesimo usato dagli scettici per pronosticare la caduta libera dell'OS, cioè la diatriba del 1997 fra le vecchie librerie C libc e le più nuove librerie C glibc. Red Hat adottò queste ultime per ottime ragioni tecniche. Altre versioni popolari di Linux mantennero le vecchie. La diatriba infuriò per circa sei mesi: con tutto ciò, alla fine del 1998 tutte le distribuzioni più popolari di Linux erano passate o avevano annunciato l'intenzione di passare alle nuove, più stabili, più sicure e più performanti librerie glibc. Qui si vede un aspetto della potenza dell'Open Source: crea una pressione unificante verso un punto di riferimento comune di fatto, uno standard aperto e rimuove le barriere della proprietà intellettuale che altrimenti ostacolerebbero questa convergenza. A voi la scelta Il vantaggio principale di questo nuovo modello tecnologico si può vedere nella nascita del PC. Perché mai, quando IBM pubblicò le specifiche del suo PC, nel 1981, il mondo adottò il modello PC con tale entusiasmo? Non è da dire che il PC IBM fosse una trappola per topi migliore. Il PC originale 8086 arrivava con 64 K (sì, K) di memoria principale. Aveva un limite superiore di memoria di 640 K. Nessuno poteva immaginare che un utente individuale potesse mai aver bisogno di più di 640 K su una singola macchina. Per il back-up dei dati era disponibile un registratore a cassette. L'impulso della rivoluzione PC fu il fatto che essa forniva agli utenti il controllo della loro piattaforma di lavoro. Potevano comprare il primo computer da IBM, il secondo da Compaq e il terzo da HP. La memoria o gli hard disk, potevano comprarli da uno di centinaia di fornitori, e così una gamma quasi infinita di periferiche per quasi ogni scopo o applicazione immaginabile. Questo nuovo modello introdusse anche un bel numero di incoerenze, incompatibilità e confusione fra tecnologie, prodotti e fornitori. Ma, come il mondo ora sa, i consumatori amano la varietà di scelta. Sono disposti a sopportare confusione e incoerenza in discrete quantità per poter scegliere e controllare. Notate anche che il mercato dell'hardware PC non si frammentò. Le specifiche sono generalmente rimaste aperte e la pressione verso l'adeguamento agli standard, per preservare l'interoperabilità, è forte. Nessuno può vantare una trappola per topi tanto migliore con cui allettare gli utenti e tenerli quindi in ostaggio, rendendo la tecnologia proprietaria. Al contrario, le innovazioni, le trappole per topi migliori, arrichiscono la comunità. Linux OS consente ai consumatori di scegliere a livello del sistema operativo la tecnologia che arriva dentro i loro computer. Richiede dunque un livello del tutto nuovo di responsabilità e di perizia da parte dell'utente? Senza alcun dubbio, sì. Quello stesso utente preferirebbe tornare al vecchio modello, cioè essere costretto a fidarsi del suo fornitore di OS proprietario binary-only, una volta che abbia sperimentato la scelta e la libertà del nuovo modello? Difficilmente. I critici continueranno a cercare (e, qualche volta, a trovare) seri problemi nella tecnologia Linux. Ma i consumatori amano la scelta, e l'enorme mercato Internet dello sviluppo software Open Source troverà modo di risolverli tutti.
Open Source di Brian Behlendorf
Nel corso del 1997 e del 1998, software Open Source come Linux, FreeBSD, Apache e Perl hanno cominciato ad attirare largamente l'attenzione di un pubblico nuovo: manager di progetto, dirigenti, analisti d'industria e investitori. La maggior parte degli sviluppatori Open Source ha accolto quest'attenzione con molto favore: non solo per orgoglio, ma anche perché consente loro di giustificare di fronte a colleghi e dirigenze i loro sforzi (ora sempre più collegati ai loro compensi). Questo pubblico nuovo, tuttavia, pone domande imbarazzanti:
La mia idea è che il modello Open Source sia davvero un modello affidabile per la conduzione dello sviluppo software a scopi commerciali. Cercherò di esporre le condizioni preliminari per un progetto simile, a quali tipi di progetto questo modello si adatti e quali passi dovrebbe fare un'azienda per lanciare un progetto Open Source. Questo saggio vuole indirizzarsi alle società che rilasciano, vendono e supportano commercialmente software o alle società che usano certe parti software come componenti fondamentali nei loro processi di business.
È tutta
una questione di piattaforme Esaminiamo per prima cosa le Application Programming Interfaces (API), le piattaforme e gli standard. Per la comodità di questo saggio riunirò nel termine generico "piattaforma" le API (come il server API di Apache per la costruzione di moduli personalizzati), i protocolli on-line come l'HTTP e le convenzioni dei sistemi operativi (quali il modo in cui Linux organizza i file di sistema, o quello in cui sono amministrati i server NT). Win32, la raccolta di routine e risorse offerte e definite da Microsoft per tutti gli sviluppatori di applicazioni per Windows 95 e NT, è una piattaforma. Se volete scrivere un'applicazione eseguibile su Windows, dovete usare questa API. Se volete, come ha fatto una volta IBM con OS/2, scrivere un sistema operativo che possa eseguire programmi creati per MSWindows, dovrete implementare l'API Win32 nella sua interezza, perché è quella che le applicazioni Windows si aspettano di poter usare. Allo stesso modo è una piattaforma la CGI, Common Gateway Interface. La specifica CGI permette agli sviluppatori di server Web di scrivere script e programmi che si eseguono al di sotto di un server Web. La CGI è una piattaforma assai più semplice di Win32, e di conseguenza in grado di fare molto meno, ma la sua esistenza è stata cruciale per il mercato dei server Web perché ha permesso agli sviluppatori di applicazioni di scrivere codice portabile, programmi eseguibili sotto qualunque server Web. Una differenza-chiave fra CGI e Win32, a parte alcuni ordini di magnitudine nella complessità, era che nessuno deteneva la proprietà della specifica CGI: essa era semplicemente qualcosa che i principali server Web implementavano per poter eseguire gli script CGI degli altri server. Solo dopo parecchi anni che la CGI era in uso si ritenne fosse il caso di stilarne una specifica informativa in forma di RFC (Request For Comments) presso la IETF (Internet Engineering Task Force). Una piattaforma è quanto definisce un software nella sua essenza: qualunque software, sia esso un browser come Netscape oppure Apache. Le piattaforme permettono di costruire o di usare un pezzo di software sopra un altro e sono dunque essenziali non solo nello spazio Internet, dove piattaforme comuni come HTTP o TCP/IP hanno veramente favorito la crescita esplosiva di Internet, ma stanno diventando di valore sempre più essenziale nell'ambito di qualsiasi ambiente informatico, nel contesto server come in quello dell'utente finale. Nel progetto Apache abbiamo avuto la fortuna di sviluppare molto per tempo un'API interna che ci consentisse di distinguere fra le funzionalità server fondamentali (gestione delle connessioni TCP, del processo-figlio e delle richieste HTTP di base) e quasi tutte le altre funzionalità di più alto livello, come il logging, un modulo per CGI, gli acclusi server-side, la configurazione di sicurezza, ecc. Un'API potente ci ha anche permesso di rinunciare ad altri pezzi ingombranti di funzionalità, come il mod_perl (un modulo Apache che include un interprete Perl in Apache) e il mod_serv (che implementa l'API dei servlet Java), e di formare gruppi di sviluppatori dedicati. Questo ha liberato il gruppo centrale di sviluppo dalla preoccupazione di costruire un "mostro" per supportare questi grandi sforzi, in aggiunta al dover mantenere e migliorare il nucleo del server. Esistono strategie commerciali costruite sul modello di possesso delle piattaforme software. Tali strategie possono richiedere pagamenti per qualsiasi uso di queste piattaforme, sulla base di un'installazione software standard o secondo l'uso (pay-per-use) o magari secondo qualche altro modello. Qualche volta le piattaforme sono gravate da copyright; altre volte offuscate dalla mancanza di una descrizione scritta per l'uso pubblico; altre ancora sono evolute così velocemente, spesso per ragioni non tecniche, che chiunque altro tenti di fornire tali piattaforme non riesce a tenerne il passo e viene quindi percepito dal mercato come "superato", tecnicamente parlando, anche quando la programmazione non c'entra. Un tale modello di strategia commerciale, potenzialmente vantaggioso nel breve termine per la società titolare della piattaforma, lavora contro gli interessi di tutte le altre aziende del settore e contro il livello generale di evoluzione tecnologica. I concorrenti, anche quando dispongano di tecnologia superiore, di migliori servizi o di costi più bassi, non possono sfruttare questi vantaggi perché non hanno accesso alla piattaforma. Il rovescio della medaglia è che i clienti possono diventare dipendenti da una piattaforma e, all'aumentare dei prezzi, trovarsi a dover scegliere se pagare un po' di più al momento per rimanere su quella piattaforma, o spendere molto per passare a una piattaforma diversa, che li farà risparmiare sul lungo periodo. I computer e l'automazione sono oggi una componente talmente essenziale dell'attività quotidiana che un'impresa commerciale accorta non dovrebbe dipendere da un unico produttore per la fornitura di servizi essenziali. Poter scegliere il servizio significa non solo avere libertà di scelta: una scelta deve anche essere economicamente abbordabile. Il costo di un cambiamento di sistema è un aspetto importante in questa libertà di scelta. E questo costo può essere ridotto al minimo se cambiare software non significa dover cambiare piattaforma. È dunque sempre nell'interesse dei clienti pretendere che il software che usano sia basato su piattaforme non proprietarie. È un concetto, questo, che a molti risulta difficile da visualizzare, perché l'economia classica (la legge della domanda e dell'offerta che si insegna a scuola) si basa sulla nozione che i prodotti in vendita abbiano un costo relativamente scalabile e che, per vendere dieci volte tanto un prodotto, il costo delle materie prime per un produttore aumenti, di norma, anche nell'ordine delle dieci volte. Nessuno avrebbe potuto prevedere la spettacolare economia di scala mostrata dal software, la mancanza quasi completa di ogni correlazione diretta fra la quantità di sforzo richiesta da un prodotto software e il numero di persone che possono comprarlo e usarlo. Un corpus di riferimento per il software open source che implementi un protocollo di connessione o un'API è più importante, per la salute a lungo termine di quella piattaforma, anche di due o tre implementazioni indipendenti non-open source. Perché questo? Perché un'implementazione commerciale può in ogni momento venir comprata da un concorrente e rimossa dal mercato in quanto possibile alternativa, distruggendo quindi la nozione che lo standard è indipendente. Può anche servire come quadro di riferimento accademico per comparare implementazioni e comportamenti. Esistono organizzazioni come la IETF e il W3C (World Wide Web Consortium) che si sforzano, con risultati generalmente eccellenti, di mantenere un forum di discussione per lo sviluppo di standard multiparte. Queste organizzazioni riescono, in complesso, nell'intento di produrre architetture d'alta qualità secondo le necessità di Internet. Tuttavia, il successo a lungo termine di un dato standard e la diffusione dello stesso ricadono fuori della loro giurisdizione. Esse non hanno alcun mezzo per costringere i gruppi membri a creare software che implementino i protocolli che loro definiscono con tanta precisione. L'unica soluzione, a volte, è dunque ricorrere a un corpus di riferimento che dimostri perché una certa implementazione sia corretta. Per esempio, nel dicembre del 1996 AOL effettuò una lieve modifica nei server proxy usati dai suoi clienti per accedere ai siti Web. Questo "upgrade" non mancava di un piccolo risvolto politico molto intelligente: quando gli utenti di AOL accedevano a un sito Web che usasse un server Apache 1.2, che all'epoca aveva pochi mesi di vita e che implementava la nuova specifica HTTP/1, trovavano a dar loro il benvenuto il seguente messaggio, altamente informativo: VERSIONE WEB NON SUPPORTATA L'indirizzo Web richiesto non è disponibile in una versione supportata da AOL. Il problema è di pertinenza del sito Web, non di AOL. Il titolare di questo sito usa un linguaggio HTTP non supportato. Se ricevete spesso questo messaggio, potete impostare le vostre preferenze per la grafica Web su COMPRESSED alla keyword: PREFERENCES Allarmato da questo "upgrade", il nucleo centrale di sviluppo di Apache dispose i carri in cerchio e analizzò la situazione. Una richiesta al team tecnico di AOL produsse la seguente delucidazione: I nuovi server Web HTTP/1.1 stanno cominciando a generare risposte HTTP/1.1 a richieste HTTP/1.0, anziché generare solo risposte HTTP/1.0. Era nostra intenzione arginare questi errori perché non proliferassero e diventassero standard de facto, bloccandoli subito. Auspichiamo che gli autori di questi server Web modifichino il loro software affinché generi risposte HTTP/1.1 solo quando viene avanzata una richiesta HTTP/1.1. Sfortunatamente, i progettisti di AOL stavano erroneamente presupponendo che le risposte HTTP/1.1 non fossero retrocompatibili con i client o i proxy HTTP/1.0. Lo sono, invece: HTTP è stato progettato per essere retrocompatibile con le versioni precedenti. Ma la specifica HTTP/1.1 è tanto complessa che una lettura non attenta e completa potesse indurre a credere che non fosse questo il caso, specialmente con il documento HTTP/1.1 circolante alla fine del 1996. Così noi, sviluppatori Apache, dovemmo scegliere: fare dietro front e fornire risposte HTTP/1.0 a richieste HTTP/1.0, o seguire le specifiche. Roy Fielding, il "poliziotto HTTP" del gruppo, riuscì a mostrarci chiaramente che il comportamento del software era corretto e vantaggioso: ci sarebbero stati casi in cui i client HTTP/1.0 avrebbero desiderato aggiornarsi a una conversazione HTTP/1.1 dopo aver scoperto che un server supportava la versione 1.1. Era anche importante rendere noto ai server proxy che, anche se vedevano che la prima richiesta che passavano a un server d'origine era 1.0, il server d'origine poteva supportare anche l'1.1. Si decise che avremmo puntato le pistole contro AOL e chiesto che correggessero il loro software. Sospettavamo che la risposta HTTP/1.1 fosse in realtà causa di un problema col loro software, probabilmente dovuto più all'imprecisione della loro programmazione che a un cattivo progetto del protocollo. Dietro la nostra decisione avevamo la scienza. Quello che più importava era che, a quel punto, Apache girava sul 40% del server Web presente sulla Rete e Apache 1.2 su una consistente porzione degli stessi. AOL dovette pertanto decidere se correggere i propri errori di programmazione o comunicare ai suoi utenti che circa il 20% o più dei siti Web su Internet sarebbero risultati inaccessibili attraverso i suoi proxy. Il 26 dicembre 1996 pubblicammo una pagina Web esponendo la disputa nel dettaglio, e rendendone nota l'esistenza non solo ai nostri utenti ma a molti importanti organi d'informazione, quali C|Net e Wired, per giustificare le nostre azioni. AOL decise di correggere il software. Più o meno nello stesso periodo annunciammo la disponibilità di una patch per i siti che volevano aggirare il problema di AOL finché questo non fosse stato risolto; una patch che degradava a HTTP/1.0 le risposte per AOL. Fummo chiari nel dire che questa sarebbe rimasta una patch non ufficiale e non supportata, e che non avrebbe costituito un setting di default nella distribuzione ufficiale. Si sono verificati molti altri casi in cui produttori di software HTTP (fra gli altri Netscape e Microsoft) hanno rilevato problemi d'interoperabilità con Apache; in molti di questi casi si è imposta una scelta fra correggere il bug o rendere inutilizzabili molti siti. A volte un produttore implementava non correttamente il protocollo, ma conforme ai propri client e server, dando luogo a un'implementazione che funzionava a dovere sui prodotti, ma imperfettamente (a dir poco) su client e server realizzati da altri. La situazione è molto più subdola perfino di quella di AOL, poiché il bug potrà non apparire o non apparire significativo alla maggior parte degli utenti di questo software. Di qui, le ramificazioni a lungo termine di un simile bug (o la nascita di altri bug a complicare la situazione) possono passare inosservate finché non è troppo tardi. Se non ci fosse un server Web di riferimento open source e diffusissimo come Apache, sarebbe del tutto comprensibile che queste leggere incompatibilità fossero cresciute l'una sull'altra e si fossero stratificate, nascoste sotto il biasimo reciproco o sotto trucchetti mentali da Jedi ("Non è riproducibile in laboratorio..."), e dove la risposta al problema: "non riesco a connettere il browser di X al server di Y" sarebbe stata semplicemente "beh, usa il client di Y e andrà tutto a posto". Al termine di questo processo ci saremmo ritrovati due o più World Wide Web, uno costruito sui server di X, l'altro sui server di Y, ciascuno funzionante solo con i client dei rispettivi produttori. Ci sono numerosi precedenti storici per questo tipo di attività anti-standard, una politica ("chiusura") codificata come pratica commerciale fondamentale da molte società di software. Naturalmente, questo avrebbe significato la rovina per tutti gli altri soggetti in causa: fornitori di contenuti, fornitori di servizi, sviluppatori di software e chiunque dovesse usare l'HTTP per comunicare avrebbero dovuto mantenere la propria offerta su due distinti server. A dispetto della pressione degli utenti tecnici per "mettersi d'accordo", la pressione contraria del marketing a "innovare, differenziare, primeggiare nel settore, definire la piattaforma" avrebbe trattenuto entrambe le parti dal tentare di liberare i loro protocolli dagli obblighi del marchio proprietario. Una situazione analoga la vediamo nel caso del JavaScript client-side. Tale era la differenza di comportamento fra i vari browser, e perfino fra diverse versioni beta dello stesso browser, che gli sviluppatori hanno dovuto creare un codice per riconoscere le diverse revisioni e assegnare loro comportamenti diversi: la cosa ha allungato in modo significativo i tempi di sviluppo delle pagine che adoperano il JavaScript. Si è dovuto pertanto attendere che il W3C prendesse una posizione ufficiale e gettasse le basi per un Document Object Model (DOM) perché si potesse vedere un tentativo autentico e serio di creare uno standard multiparte intorno al JavaScript. Esistono forze naturali, nel mondo moderno degli affari, che spingono alla deviazione quando una specifica è implementata da un software chiuso. Anche un errore accidentale di lettura di una specifica comune può causare una deviazione, se non viene corretto all'istante. Per questo dico che costruire servizi o prodotti fondandoli su piattaforme basate su standard è un bene per la stabilità dei processi di business. Il successo di Internet non ha mostrato solo come le piattaforme comuni contribuiscano a facilitare le comunicazioni, ma ha anche forzato le aziende a pensare di più a come creare valore in quanto viene comunicato, piuttosto che cercare di ricavare valore dalla rete in sé.
Analizzare gli
obiettivi per un progetto open source Poniamo che siate una azienda produttrice di database. Vendete un database che funziona su diversi sistemi operativi e, separatamente, anche pacchetti per l'amministrazione tramite interfaccia grafica, strumenti di sviluppo rapido, una libreria di procedure comuni a uso degli utenti, ecc. Fornite assistenza su base annua. Gli upgrade richiedono un nuovo acquisto. Offrite anche corsi. Infine, avete una squadra di consulenza consistente e in crescita che implementa il database per i clienti. Supponiamo che il bilancio delle vostre entrate si presenti più o meno così:
A prima vista, l'idea di distribuire gratuitamente il database suona assurda. Significherebbe buttar via il 40% delle vostre entrate. Se siete una società fortunata sarete in profitto, e se siete ancora più fortunati questo margine di profitto sarà forse del 20%. La rinuncia a quel 40% spazzerebbe via tutto. Ciò, ovviamente, presupponendo che nessun altro fattore dell'equazione cambi. Ma ci sono invece buone probabilità, se giocate bene le vostre carte, che le cose cambino. I database non sono quel genere di applicazione che le aziende prendono da uno scaffale a CompUSA, infilano nel CD drive delle loro macchine e non ci pensano più. Tutte le altre voci d'entrata restano valide e necessarie, senza relazione con il prezzo dell'OS. Infatti, aumentare il prezzo di questi servizi aggiuntivi è adesso possibile più di un tempo, quando il costo del software divorava quasi per intero il prezzo che un consumatore pagava comprando un software di database. Quindi, in parole povere, se la distribuzione a basso prezzo (o addirittura gratuita) del database portasse il database a raddoppiare la sua base di utenti, e se gli utenti fossero motivati quanto lo erano prima ad acquistare dalla vostra società consulenza, assistenza, strumenti di sviluppo, librerie eccetera, si vedrebbe un incremento del 20% nelle entrate complessive. La cosa più probabile è che al vostro software si avvicini quattro o cinque volte il numero dei clienti che già avevate e, mentre le entrate relative ad altri servizi diminuiranno, vuoi perchè molti utenti si accontenteranno della versione gratuita, vuoi perchè alcuni concorrenti offriranno i medesimi servizi per il vostro software, le entrate complessive della vostra azienda saranno quasi certamente aumentate, a patto però che gli introiti legati a tali servizi non diminuiscano eccessivamente. Ancora, a seconda della licenza usata, potreste abbassare il costo di sviluppo del software. Vi capiterà di trovare clienti motivati che correggono da sé i bug, per esempio, e nuove innovazioni da parte di clienti che offrono il loro codice al progetto perché desiderano che venga mantenuto come parte standard della distribuzione complessiva. Nel complesso, i vostri costi di sviluppo dovrebbero diminuire. È anche probabile che, data una miscela prodotto/servizi come quella sopra descritta, il rilascio gratuito del progetto non aiuterà i vostri concorrenti ad essere competitivi nei vostri spazi di reddito. Ci sono probabilmente già dei consulenti che compiono lavoro d'integrazione con i vostri strumenti; autori indipendenti di manuali; librerie di codice realizzati da altre aziende. La disponibilità del codice sorgente aiuterà marginalmente la concorrenza nel fornire assistenza al vostro codice, ma voi, in qualità di sviluppatori originali, avrete nel vostro marchio una risorsa nascosta contro la quale gli altri dovranno confrontarsi. Va da sé che non sono tutte rose e fiori. Questo processo implica dei costi che sarà difficile legare direttamente alle entrate. Per esempio, il costo dell'infrastruttura a supporto di questo sforzo, pur poco significativo di per sé, può gravare sull'amministrazione del sistema e lo staff dell'assistenza. Calcolate anche il costo per le comunicazioni degli sviluppatori con altri sviluppatori esterni all'azienda e le spese generali extra per sviluppare il codice in modo pubblico. Un costo rilevante può essere rappresentato dalla preparazione del codice per un minuzioso esame da parte del pubblico. E dopo tutto questo lavoro, potrà capitare che non ci sia "richiesta di mercato" per il vostro prodotto come freeware. Il resto di questo saggio si propone di affrontare questi punti.
Valutazione
della richiesta di mercato per un prodotto Il primo passo è condurre un'analisi sulla competitività del mercato, per identificare sia i concorrenti commerciali che quelli freeware, non importa quanto piccoli siano. Fate molta attenzione a determinare esattamente quello che il vostro prodotto offre, suddividendo la vostra offerta in componenti, blocchi separabili che possano potenzialmente essere raccolti, venduti o resi Open Source uno per uno. Analogamente, non escludete combinazioni di freeware e software commerciale che offrano le stesse funzionalità. Riprendiamo l'esempio del database, immaginando che il database del produttore si componga di fatto di tre elementi: un server SQL di base; un gestore del logging di backup/transaction; una libreria per sviluppatori. Un tale produttore dovrebbe paragonare l'offerta dei suoi prodotti non solo con quella dei giganti come Oracle e Sybase, non solo con quella dei concorrenti commerciali più piccoli ma in crescita, come Solid e Velocis, ma anche con database freeware come MySQL e Postgres. Tale analisi potrebbe portare alla conclusione che il server SQL di base dell'azienda non fornisca che poche funzioni in più rispetto a MySQL, e in un'area che non è mai stata considerata di vantaggio competitivo ma meramente una caratteristica necessaria a tenere il passo con gli altri produttori di database. Il gestore del logging di backup/transaction non ha rivali freeware e la libreria per sviluppatori è surclassata dalle utility Perl DBI, ma ha poca concorrenza nel comparto Java o C. Quest'azienda potrebbe allora considerare le strategie seguenti:
Personalmente sconsiglierei quest'ultimo approccio nelle circostanze descritte, visto che MySQL parte davvero avvantaggiato, con moltissimi add-on e una base di utenti piuttosto ampia. Tuttavia, di tanto in tanto un progetto open source marca il passo, o perché il team principale di sviluppo non sta sviluppando attivamente, o perché il software s'imbatte in problemi architetturali che gli impediscono di soddisfare richieste nuove, o semplicemente perché l'ambiente in cui una richiesta era nata s'inaridisce o cambia obiettivo. Quando ciò accade, e diventa chiaro che la gente è alla ricerca di alternative, c'è la possibilità d'introdurre un rimpiazzo che attirerà l'attenzione, anche se non rappresenterà immediatamente un progresso significativo dello stato delle cose. L'analisi della domanda è essenziale poiché di solito è la domanda che crea nuovi progetti open source. Apache nacque quando un gruppo di webmaster, che si passavano l'un l'altro patch per il Web server NCSA, a un certo punto decisero che questa specie di scambio delle figurine era una pratica poco efficiente e soggetta a errori, e scelsero dunque di operare una distribuzione separata del server NCSA con le loro patch incorporate. Nessuno dei protagonisti di quei giorni lontani si trovò coinvolto perché voleva vendere un server commerciale con Apache come base, anche se si tratta certo di una ragione validissima. L'analisi della domanda di mercato per un particolare progetto open source implica dunque che si frequentino le mailing list e i forum di discussione pertinenti, che si scandaglino gli archivi dei newsgroup, che chieda a clienti e concorrenti; solo allora sarà possibile stabilire realisticamente se esiste qualcuno disposto a contribuire allo sviluppo del vostro progetto. Tornando agli albori di Apache: quelli fra noi che si scambiavano le patch, le mandavano anche alla NCSA, sperando che sarebbero state incorporate, o almeno che la loro esistenza venisse riconosciuta, per essere rassicurati sul fatto che avremmo potuto compiere l'upgrade senza problemi all'uscita della successiva release. Ma la NCSA aveva ricevuto un duro colpo quando i primi programmatori del server le erano stati portati via da Netscape; i programmatori rimasti non potevano far fronte all'inondazione di email. Costruirci il nostro server fu quindi un risultato dell'istinto di conservazione più che della volontà di creare il futuro grande server Web. È importante avere obiettivi contenuti quando si comincia, perché li si può raggiungere senza troppe difficoltà e non si deve dipendere dal fatto che il progetto arrivi a dominare il mercato per trarre qualche vantaggio dall'approccio.
La posizione
dell'Open Source nello spettro del software Il software open source si è sempre posizionato più verso l'estremità infrastrutturale/ back-end dello spettro del software così rappresentato, e questo per diversi motivi:
Ecco perché vediamo consistenti offerte open source nell'ambito dei sistemi operativi e dei servizi di rete, e molto pochi, invece, nell'ambito delle applicazioni per desktop. Non mancano certamente eccezioni. Esempio illustre è GIMP, o GNU Image Manipulation Program, un programma per X11 paragonabile per ricchezza di funzionalità a Photoshop di Adobe. È vero però che, in un certo senso, anche questo prodotto è uno strumento "infrastrutturale", una piattaforma, dal momento che deve il suo successo alla sua meravigliosa architettura a plug-in e alle dozzine e dozzine di plug-in che sono stati sviluppati e che permettono di importare ed esportare molti diversi formati di file e che implementano centinaia di effetti-filtro. Date un'altra occhiata allo spettro che avete disegnato. A un certo punto, potete osservare la vostra offerta nel contesto di questi concorrenti e tracciare una linea verticale. Questa linea denota la separazione fra il vostro spazio Open Source e quello che decidete di mantenere proprietario. Questa stessa linea rappresenta la vostra vera piattaforma, la vostra interfaccia fra il codice pubblico che state cercando di affermare come standard, a sinistra, e il codice proprietario per il quale volete stimolare la domanda, a destra.
La natura
aborre il vuoto Torniamo all'esempio del database: poniamo che decidiate di rendere pubblico il codice sorgente del vostro server SQL di base (o del codice avanzato che avete posto sopra MySQL), ma anche che abbiate deciso di guadagnare creando un driver commerciale, senza distribuirne i sorgenti, per collegare quel database a un server Web per creare contenuti dinamici. Avete stabilito che il database sarà l'elemento economicamente in perdita del prodotto, bilancerete aumentando i margini di guadagno sulla componente. Dal momento che connettere database ai server Web è cosa assai comune e auspicabile, gli sviluppatori non potranno prescindere da voi oppure dovranno trovare un altro sistema per accedere al database dal sito Web. Ogni sviluppatore sarà motivato dall'idea di risparmiare il denaro che altrimenti dovrebbe pagarvi. Se un numero sufficiente di sviluppatori unisce le forze per ripagarsi del tempo impiegato per questo lavoro, o se capita che un solo capace sviluppatore non possa permettersi il plug-in ma voglia usare quel database, è possibile che un bel mattino, svegliandovi, troviate un concorrente open source alla vostra offerta commerciale, e ciò eliminerà completamente il vantaggio di possedere l'unica soluzione per quel compito. Questa non è che una parte di un quadro più ampio: dipendere, per il proprio guadagno, da codice sorgente proprietario in prodotti strategici, è diventato un'impresa rischiosa. Se siete in grado di trarre profitto supportando la combinazione server Web + plug-in + database, o fornendo un'interfaccia per la gestione complessiva di quel sistema, sarete protetti contro sorprese di questo tipo. Non tutto il software commerciale si presenta così vulnerabile: è una particolare caratteristica di quello che cerca di inserirsi in una nicchia direttamente fra due offerte open source consolidate. Collocare la vostra offerta commerciale come aggiunta al set corrente di offerte open source è una strategia più solida.
Lo regalo o me
lo tengo? C'è una ragione valida che consiglia di approfittare, quando un pacchetto open source in una categoria si sovrappone alla vostra potenziale offerta, donando il vostro codice aggiuntivo o altri miglioramenti al progetto esistente per mirare a un ritorno sotto forma di un codice complessivamente di miglior qualità, di una spinta nell'ambito marketing o dell'istituzione di una piattaforma comune. Nel valutare l'opportunità di una simile strategia bisogna fare attenzione ai termini della licenza:
Far contenti gli sviluppatori è probabilmente la sfida maggiore nel modello open source, una sfida che né l'impegno tecnologico né, a ben vedere, i soldi aiutano più di tanto a vincere. Ogni sviluppatore deve sentire di contribuire in modo positivo al progetto, deve sentirsi ascoltato; i suoi commenti sull'architettura e sulla progettazione devono essere valutati e rispettati, gli sforzi profusi nel codice ricompensati con l'integrazione nella distribuzione o, in caso contrario, con un rifiuto ottimamente argomentato. Sbaglia chi dice: "Il modello open source funziona perché l'intera Internet diventa il vostro dipartimento di ricerca e sviluppo e la vostra assistenza". Di fatto, la quantità di sforzo disponibile per un dato set di compiti da parte di un programmatore di talento è di solito limitata. Così, è di solito nell'interesse di tutti se gli sforzi di sviluppo parallelo non s'intraprendono al solo scopo di evitare dispute semantiche fra sviluppatori. D'altra parte, si ha un'evoluzione più efficiente quando soluzioni alternative sono in gara per aggiudicarsi le risorse. Non sarà quindi un male avere due soluzioni in gioco nella medesima nicchia, se solo il talento in gioco pareggia la massa critica; una soluzione potrebbe contenere un'innovazione non contemplata nell'altra. La concorrenza ha dato prova della sua utilità nel campo dei server SMTP. Il programma "Sendmail" di Eric Allman ha rappresentato a lungo lo standard per i "daemon" STMP presenti su ogni sistema operativo. Sono comparsi poi altri concorrenti open source, come Smail o Zmailer, ma il primo ad aver fatto veramente breccia sugli utenti è stato il pacchetto Qmail di Dan Bernstein. Quando Qmail si è presentato sulla scena, Sendmail aveva vent'anni e cominciava a dimostrarli; per giunta, non era progettato per l'Internet degli anni Novanta, in cui i buffer overflow e la caduta del servizio sono diventati comuni come i temporali a Seattle. Qmail era rivoluzionario sotto diversi aspetti: progetto del programma, amministrazione, perfino la definizione di "comportamento corretto" per un server SMTP. Un'evoluzione del genere sarebbe stata altamente improbabile per il pacchetto Sendmail di Allman, non perché Allman e i suoi non fossero bravi programmatori o perché mancassero contributi di terze parti: è semplicemente che, a volte, ci vuole uno stacco netto per provare qualcosa di veramente nuovo e vedere se funziona. Per ragioni simili, l'IBM ha sovvenzionato lo sviluppo del daemon SMTP "SecureMailer" di Weiste Venema, che nel momento in cui scrivo sembra destinato a una buona popolarità. Lo spazio dei daemon SMTP è abbastanza ben definito e importante da supportare più di un progetto open source; solo il tempo può dire quale sopravviverà.
Bootstrapping Nel cercare di determinare che domanda ci sia per il vostro progetto, vi sarete probabilmente imbattuti in un certo numero di altre società e individui abbastanza interessati da formare un nucleo base di sviluppatori. Una volta decisa una strategia, proponetela con determinazione anche maggiore a questo nucleo, magari avviando a questo scopo una semplice mailing list di discussione, in cui niente sia ancora inciso nel marmo. È molto facile che dal gruppo emergano idee significative per il successo del progetto e una lista delle risorse che potranno contribuirvi. Per i progetti più semplici basterà che il gruppo s'impegni a provare il vostro prodotto e a rimanere nella mailing list di sviluppo. Tuttavia, per progetti più impegnativi, sarebbe bene valutare le dimensioni totali di questa base di risorse. Quanto segue è la mia idea delle risorse minime per un progetto di media complessità, quale potrebbe essere la creazione di un comune plug-in di scelta e acquisto (del tipo "carrello della spesa") per un server Web, o di un nuovo tipo di daemon di rete che implementi un semplice protocollo. È anche compresa una descrizione dei ruoli richiesti e della competenze necessarie a ciascuno. Avvio: 100 ore. Manutenzione: 20 ore alla settimana. Avvio: 40-200 ore (a seconda del tempo richiesto per la sistemazione del codice per l'uso pubblico!). Manutenzione: 20 ore alla settimana. Avvio: il tempo necessario per padroneggiare il codice. Manutenzione: 10-15 ore alla settimana. Avvio: 60 ore (supponendo che la maggior parte del codice sia documentato). Manutenzione: 10 ore alla settimana. Avvio: il tempo di conoscere il progetto. Manutenzione: 20 ore alla settimana. Ci ritroviamo dunque con cinque figure che equivalgono grosso modo a tre impiegati a tempo pieno. In realtà, alcuni di questi ruoli vengono gestiti da gruppi di persone che ne condividono la responsabilità, e alcuni progetti sopravvivono con meno di cinque ore alla settimana spese in media dai partecipanti-chiave, una volta superate le asperità delle prime release. Ma all'inizio del progetto è essenziale che gli sviluppatori gli dedichino lo stesso tempo e concentrazione che impiegherebbero se il progetto fosse una normale impresa di sviluppo di un'azienda. Questi cinque ruoli, inoltre, non coprono alcuna risorsa che potrebbe essere indirizzata a un nuovo sviluppo: si tratta di puro aggiornamento. In conclusione, se non trovate fra colleghi e partner risorse sufficienti per coprire queste basi, più sviluppatori extra per realizzare nuove fondamentali implementazioni (finché non farete nuovi reclutamenti), sarà forse il caso che riconsideriate il tutto.
Quale licenza?
Copyright di tipo BSD Da un punto di vista commerciale, questa licenza è la migliore quando s'interviene su di un progetto preesistente, perché non ci si deve preoccupare di licenze o di restrizioni sull'uso o la ridistribuzione futuri. È possibile miscelare e adattare questo software al vostro codice proprietario e rilasciare solo quello che ritenete possa essere utile al progetto e quindi, di riflesso, a voi. È uno dei motivi per cui l'abbiamo scelta per il gruppo Apache. A differenza di molti progetti software gratuiti, Apache fu avviato in gran parte da webmaster dell'ambito commerciale che cercavano un server Web migliore per le loro esigenze di business. È probabile che nessuno di noi mirasse a creare un server commerciale sopra Apache, ma nessuno sapeva che cosa il futuro avesse in serbo per noi, e limitare le nostre opzioni fin dall'inizio non sarebbe stato intelligente. Questo tipo di licenza è l'ideale per promuovere l'uso di un corpus di codice di riferimento che implementi un protocollo o un servizio comune. È un altro motivo della sua scelta per il gruppo Apache: molti di noi volevano che l'HTTP sopravvivesse e diventasse un vero standard multiparte, e non ci siamo minimamente preoccupati se Microsoft o Netscape avessero deciso di incorporare nei loro prodotti il nostro motore HTTP o qualunque altra componente del nostro codice, se solo ciò avesse contribuito all'intento di mantenere comune l'HTTP. Un tale grado di apertura presenta i suoi rischi. La licenza non fa riferimento ad alcun incentivo alle aziende perché diano in cambio le loro aggiunte al codice del progetto. Si sono in effetti dati casi in cui alcune aziende hanno sviluppato intorno al progetto delle tecnologie che ci sarebbe piaciuto vedere a loro volta offerte al progetto stesso. Ma se avessimo avuto una licenza che prescriveva che il codice aggiuntivo dovesse essere reso disponibile al progetto d'origine, si può pensare che quelle aggiunte non sarebbero nemmeno state fatte. Tutto questo per dire che, strategicamente parlando, il progetto deve mantenere una spinta sufficiente e che i partecipanti realizzano un valore maggiore contribuendo con il loro codice al progetto: perfino il codice che avrebbe avuto un valore se mantenuto proprietario. È un equilibrio complicato da mantenere, specialmente quando un'azienda decide di aumentare considerevolmente il codice scritto su un progetto derivativo, e comincia a dubitare se il possibile ritorno valga lo sforzo del contributo. Insomma, lavoriamo più di tutti gli altri messi insieme, perché dovremmo spartire? Chi scrive non ha la risposta a questa domanda. Quello che posso dire è che quell'azienda non ha probabilmente saputo trovare un modo più persuasivo per ispirare alle terze parti la voglia di contribuire per raggiungere gli obiettivi di progettazione più efficacemente.
La licenza pubblica Mozilla Essa prescrive che le modifiche alla "distribuzione" siano rilasciate sotto lo stesso copyright della MPL, il che la rende di nuovo disponibile al progetto. "Distribuzione" sono definiti i file così come vengono distribuiti nel codice sorgente; è importante perché consente a un'azienda di aggiungere un'interfaccia a una libreria di codice proprietario senza prescrivere che l'altra libreria di codice sia pure sottoposta alla MPL, ma solo l'interfaccia. In questo modo, il software può venir inserito, in grado variabile, entro un ambiente software commerciale. La licenza ha numerose clausole a protezione sia del progetto nella sua interezza sia dei suoi sviluppatori contro questioni di brevetto nel codice aggiunto che potrebbero insorgere. Prescrive che l'azienda o l'individuo che contribuisca con codice al progetto rinunci a ogni possibile pretesa a diritti di brevetto a cui il codice potrebbe dare adito. La seconda clausola è importantissima; al momento in cui scrivo, contiene anche un grave difetto. Preoccuparsi delle questioni di brevetto è Cosa Buona E Giusta. C'è sempre il rischio che, in perfetta buona fede, un'azienda offra codice a un progetto e poi, una volta che il codice sia stato completamente implementato, cerchi di reclamare il pagamento di una qualche concessione di brevetto per il suo uso. Una simile strategia commerciale, oltre a essere di pessimo gusto, è un vero passo falso dal punto di vista delle pubbliche relazioni, ma purtroppo non tutte le aziende arrivano a capirlo. La seconda clausola, dunque, previene il caso di qualcuno che fornisca di nascosto del codice ben sapendo che è brevettato e passibile di causare dei gran mal di testa a tutte le parti in causa. Questo non elimina naturalmente l'eventualità che qualcun altro sia titolare di un brevetto che possa far valere: non esiste strumento legale che forniscono questo tipo di protezione. Per la verità, io farei appello all'Ufficio Federale Brevetti e Commercio (U.S. Patent and Trade Office) perché se ne faccia carico: se ha l'autorità per definire certe idee e algoritmi come proprietà di un soggetto, dunque perché non gli si dovrebbe richiedere di fare l'opposto e di certificare come libero da brevetti il codice che ho presentato, garantendomi protezione da cause per violazione di brevetto? Come ho detto prima, tuttavia, la MPL vigente al dicembre 1998 presenta un difetto. In sostanza, la Sezione 2.2 prescrive (nella sua definizione di "Contributor Version") che chi da il contributo rinunci a reclamare brevetti su qualunque parte di Mozilla, non solo sul codice che ha fornito. Può non sembrare un difetto: sarebbe bello che una quantità di grandi aziende rinunciasse a ogni diritto sull'intero pacchetto. Purtroppo c'è una grande azienda che detiene uno dei più grandi portafogli di brevetti al mondo, che ha un grosso e specifico problema con questo cavillo. Non già perché voglia una volta o l'altra perseguire Mozilla e pretendere royalty, che sarebbe follia. La preoccupa il fatto che alcune parti di Mozilla implementano processi su cui essa detiene dei brevetti grazie ai quali incassa ogni anno moltissimi dollari: e se rinunciasse a far rispettare i brevetti sul codice di Mozilla, quelle altre aziende che pagano migliaia di dollari per quei brevetti, potrebbero semplicemente prendere da Mozilla il codice che li implementa e portarlo nei loro prodotti, eliminando la necessità di comprare la licenza del brevetto detenuto dalla succitata grande azienda. Questo non rappresenterebbe un problema se la Sezione 2.2 della MPL si riferisse semplicemente alle patch oggetto di contributo piuttosto che all'intero browser, quando si viene alla rinuncia ai diritti di brevetto. A parte questo cavillo, la MPL è una licenza straordinariamente solida. Prescrivere che le modifiche debbano tornare al "nucleo" significa che le correzioni di bug essenziali e i miglioramenti della portabilità rifluiranno nel progetto, mentre caratteristiche a valore aggiunto potranno sempre essere sviluppate da entità commerciali. Si tratta forse della licenza da preferire quando si sviluppano applicazioni per l'utente finale, nelle quali i brevetti possono più facilmente diventare un problema e più grande può essere l'impulso a ramificare il progetto. Per contro, la licenza BSD è forse più adatta a progetti destinati a essere "invisibili" o essenzialmente librerie di funzioni, quali un sistema operativo o un server Web.
La Licenza Pubblica GNU Fondamentalmente, la GPL (General Public License) prescrive che gli incrementi, i derivati e perfino il codice che incorpora altro codice sotto GPL vengano rilasciati essi stessi come codice sorgente sotto GPL. Questo comportamento "virale" è stato ampiamente propagandato dagli apologeti dell'Open Source come un modo per assicurare che il codice che nasce free rimanga free: che non ci sia possibilità che un interesse commerciale possa deviare le versioni di sviluppo dal codice disponibile e impegnare risorse che non siano rese pubbliche. Agli occhi di chi licenzia il proprio software sotto GPL, sarebbe meglio non ricevere addirittura contributi che riceverne per poi non poterli usare liberamente. La cosa ha naturalmente un interesse speculativo, e si trovano sostenitori che dichiarano che Linux non sarebbe arrivato dov'è se non avesse avuto una GPL, perché la lusinga della deviazione per ragioni commerciali sarebbe stata troppo forte, impedendo di raggiungere la massa critica dello sforzo di sviluppo unificato. A prima vista, dunque, parrebbe che la GPL non possa coesistere felicemente con un fine commerciale collegato al software open source. I tradizionali modelli di guadagno attraverso l'aggiunta di valore al software non sono qui praticamente possibili. Tuttavia, la GPL potrebbe essere un mezzo efficacissimo per affermare una piattaforma che scoraggi perfino la creazione di piattaforme concorrenti, e per proteggere la rivendicazione di chi voglia essere conosciuto come il "primo" fornitore di prodotti e servizi residenti su questa piattaforma. Ne sono esempi Cygnus e GCC. Cygnus opera un sostanzioso blocco di modifiche ogni anno, portando GCC su diversi tipi di hardware e mantenendo quei porting. La grandissima parte di quel lavoro, secondo il dettato della GPL, va come contributo alla distribuzione di GCC che viene reso gratuitamente disponibile. Cygnus fa pagare lo sforzo insito nel porting e nell'aggiornamento, non il codice in sé. La storia di Cygnus e della sua leadership in questo ambito ne fanno l'azienda di riferimento quando ci si voglia accostare a questo tipo di servizio. Se un concorrente volesse cominciare a competere con Cygnus, sarebbe costretto a distribuire anch'esso le sue modifiche con licenza GPL: in altri termini, non c'è speranza che un concorrente possa trovare una nicchia tecnico commerciale che sia sfruttabile con la struttura GCC senza dare a Cygnus la stessa opportunità di approfittare anche di quella tecnologia. Cygnus ha creato una situazione in cui i concorrenti non possono competere sul piano della diversificazione tecnologica, a meno che non intendano spendere quantità ingenti di tempo e di denaro e usare una piattaforma completamente diversa da GCC. Un'altra maniera in cui si potrebbe usare la GPL per intenti commerciali è sotto forma "tecnologia sentinella", con una versione non-GPL dello stesso codice disponibile per la vendita. Per esempio, poniamo che abbiate un ottimo programma per criptare le connessioni TCP/IP su Internet. Non v'importa che venga usato in modo commerciale o meno: vostro interesse è che chi vuole incorporarlo in un prodotto o ridistribuirlo a pagamento vi paghi per l'autorizzazione a farlo. Se mettete il codice sotto una licenza GPL, questo secondo gruppo di utenti non potrà fare quello che vuole senza mettere per intero sotto GPL il suo prodotto, cosa che molti di loro non sarebbero propensi a fare. Ma se mantenete un ramo del vostro progetto separato, ossia non sotto GPL, potrete licenziare commercialmente il ramo separato di codice come meglio vi aggrada. Bisogna però fare molta attenzione e accertarsi che tutto il codice che vi è stato dato spontaneamente da terze parti sia disponibile per questa ramificazione non-gratuita; potete farlo dichiarando che solo voi (o vostri dipendenti) scriverete codice per questo progetto, oppure che (in aggiunta) otterrete da parte di tutti coloro che hanno contribuito al progetto il permesso esplicito di riversare qualunque loro contributo in una versione commerciale. Per alcune società questo è un modello commerciale sostenibile: un esempio è Transvirtual di Berkeley, che applica questo modello a una Java Virtual Machine leggera e a un progetto di libreria di classi. Si può obiettare che un alto numero di partecipanti a un progetto verrebbe respinto da un simile modello, e che le versioni GPL e non-GPL potrebbero divergere; a mia volta, obietto che se si trattano i partecipanti con lealtà, magari anche offrendo loro denaro o compensi d'altro tipo in cambio dei loro contributi (dopo tutto è in gioco il vostro interesse primario), questo modello potrebbe funzionare. L'ambito della licenza open source evolverà certamente nei prossimi anni quanto più diventerà chiaro che cosa funziona e che cosa no. La verità è che avete la libertà di inventarvi una licenza nuova, che descriva esattamente il punto dello spettro (delimitato da BSD a destra e da GPL a sinistra) in cui vorreste collocarla. Ricordatevi solo che quanto più grande sarà la libertà che accorderete a coloro che usano ed estendono il vostro codice, tanto più essi saranno incentivati a contribuirvi.
Strumenti per il lancio di un progetto Open Source Il più importante è il CVS, o Current Versioning System. Si tratta di una raccolta di programmi che implementano un "repository" di codice condiviso, aggiornando un database di modifiche, ciascuna delle quali porta un nome e una data. È estremamente valido per permettere a diverse persone di essere "autori" simultanei di un programma senza intralciarsi a vicenda. È utile anche nel processo di debugging, poiché si possono ripercorrere a ritroso le modifiche una per una, per scoprire dove esattamente si sia potuto introdurre un certo bug. Poiché sono disponibili client per tutte le principali piattaforme, funziona alla perfezione su linee commutate o attraverso connessioni a lunga distanza. Può anche essere protetto tramite tunneling su una connessione criptata che usi SSH. Il Progetto Apache usa il CVS non solo per tenere aggiornato il software ma anche il file "STATUS" in cui collochiamo tutte le principali questioni in discussione, ciascuna completa di commenti, opinioni e perfino voti. Lo usiamo anche per raccogliere i voti sulle decisioni prese dal gruppo, per tenere aggiornati i documenti del nostro sito Web, per gestire i documenti di sviluppo, ecc. In breve, è la risorsa e il software di gestione delle conoscenze del progetto. La sua semplicità può sembrare un inconveniente, il software in questo campo è di solito costoso e ricco di funzioni, ma la verità è che nel caso di CVS la semplicità è una gran virtù. Tutte le componenti del CVS sono gratuite, sia il server che i client. Altro elemento vitale per un progetto open source è una solida base di forum di discussione per sviluppatori e per utenti. Qui, la scelta del software è lasciata molto al caso: noi usiamo Majordomo, ma anche ezmlm, Smartlist o un altro qualsiasi programma sarebbe potuto andare ugualmente bene. Quello che conta è che ogni sforzo di sviluppo abbia la sua mailing list, così che gli sviluppatori possano selezionare da sé ciò che li interessa e restare ragionevolmente aggiornati sullo sviluppo. Sarà anche saggio creare per ogni progetto liste separate al quale il server CVS invia per email le modifiche che vengono operate nel suo "repository", per consentire una specie di controllo passivo delle modifiche fra colleghi. Questo modello è in effetti molto efficace per mantenere gli standard del codice e per scoprire bug. Può essere anche il caso di predisporre liste diverse per utenti e sviluppatori e magari perfino di distinguere fra tutti gli sviluppatori e un gruppo pilota, se il progetto è di ampio respiro. Infine, è importante che si rendano disponibili pubblicamente gli archivi delle liste, così che i nuovi utenti possano, tramite una ricerca, sapere se un certo problema sia già stato trattato, o come si sia risposto in passato a certe domande. Tener traccia di bug e di problemi è anche essenziale in un progetto ben condotto. Al Progetto Apache usiamo uno strumento GNU chiamato GNATS, che ci è stato molto utile in oltre 3000 segnalazioni di bug. Vi servirà uno strumento che permetta a diverse persone di rispondere alle segnalazioni di bug, di specializzarsi sui bug di una specifica componente del progetto e di leggere e rispondere via email alle segnalazioni, anziché solo tramite un modulo in una pagina Web. L'obiettivo principale per il database dei bug è di essere il più semplice e automatico possibile, sia per gli sviluppatori che rispondono alle segnalazioni di bug (perché è veramente un compito noioso) sia per ricercare se un certo bug sia già stato inserito. In sostanza, il database dei bug diventerà il vostro deposito di conoscenza aneddotica del progetto e delle sue capacità. Perché un certo comportamento è una caratteristica, non un bug? C'è qualcuno al lavoro su un problema segnalato? Ecco le domande a cui un buon database di bug dovrebbe cercare di rispondere. L'approccio open source non è una magia che funzioni per tutti i progetti di sviluppo software. Lanciare un progetto di successo richiede non solo le giuste condizioni ma anche un'enorme quantità di lavoro, perché esso prenda finalmente vita. In più di un senso voi, come sostenitori del nuovo progetto, dovrete agire come il dottor Frankenstein, ora miscelando sostanze chimiche, ora somministrando scosse elettriche, per portare il vostro mostro alla vita. Buona fortuna. The Open Source Definition di Bruce Perens
L'utente tipico di computer possiede una discreta quantità di software che ha comprato nel tempo e che ormai non adopera più. Magari ha aggiornato il computer, o ha cambiato marca, e i vecchi programmi hanno smesso di funzionare. Magari il software è diventato obsoleto. O semplicemente il programma non lo soddisfa. Forse ha comprato due o più computer e non vuole pagare per una seconda copia del software. Quale che sia la ragione, il software per cui ha pagato anni fa non è più adeguato. Tutto questo è inevitabile? Non sarebbe bello avere diritto a un aggiornamento gratuito ogni volta che il software lo richiede? Se, passando da un Mac a un PC, si potesse cambiare la versione del software gratis? Se, quando il software non funziona o non è abbastanza potente, si potesse migliorarlo o perfino ripararlo da soli? Se il software continuasse a essere supportato anche quando l'azienda produttrice abbia cessato l'attività? Non sarebbe bello usare il software sulla stazione di lavoro, sul computer di casa e sul portatile, anziché su un solo computer? È probabile che, in quel caso, si starebbe ancora usando il software pagato anni prima. Questi sono alcuni dei diritti che l'Open Source riconosce. La Open Source Definition è una carta dei diritti dell'utente di computer. Definisce certi diritti che una licenza software deve garantire per poter essere certificata come Open Source. I produttori che non rendono Open Source il loro programmi trovano difficile competere con chi lo fa, dal momento che gli utenti imparano ad apprezzare quei diritti che avrebbero dovuto sempre essere loro. Programmi come il sistema operativo Linux e il browser Web Netscape sono diventati popolarissimi, scalzando altro software sottoposto a licenze più restrittive. Aziende che usano software Open Source godono il vantaggio del suo rapidissimo sviluppo, spesso a opera cooperativa di numerose aziende, e in gran parte fornito da soggetti individuali che operano migliorie sulla base di proprie necessità. I volontari che hanno reso possibili prodotti come Linux ci sono, e le aziende possono cooperare, solo grazie ai diritti che vengono con l'Open Source. Il programmatore medio si sentirebbe stupido nel riversare tanto lavoro in un programma per vedere poi le sue migliorie vendute dal proprietario senza che lui ne riceva alcun ritorno. Quegli stessi programmatori contribuiscono volentieri all'Open Source perché esso assicura loro questi diritti:
Questi diritti sono importanti per coloro che collaborano a un software perché li mantengono tutti al medesimo livello. Chiunque lo voglia è libero di vendere un programma Open Source, così i prezzi rimarranno bassi e sarà rapido lo sviluppo per raggiungere nuovi mercati. Chiunque investa il suo tempo a costruire conoscenza in un programma Open Source lo può supportare, e questo permette agli utenti l'opzione di fornire a loro volta il loro supporto, o l'economia dovuta a un gran numero di fornitori di supporto concorrenti. Qualunque programmatore può adattare un programma Open Source a misura di mercati specifici per raggiungere clienti nuovi. Chi lo fa non è costretto a pagare diritti o concessioni di licenza. La ragione per il successo di una strategia che può suonare alquanto comunista proprio nel momento in cui il fallimento del comunismo stesso è visibile ovunque, è nel fatto che l'economia dell'informazione è sostanzialmente diversa da quella degli altri prodotti. I costi della copia di un'informazione come un programma software è infinitesimo. L'elettricità non costa quasi nulla, l'uso dell'attrezzatura poco di più. È come, per fare un paragone, se si duplicasse una pagnotta usando un solo etto di farina.
La storia La Open Source Definition cominciò la sua vita come un documento di linea di condotta della distribuzione Debian GNU/Linux. Debian, uno dei primi sistemi Linux, tuttora popolare, fu costruito interamente con free software. Tuttavia, dal momento che c'erano altre licenze oltre al copyleft che comportavano la gratuità, Debian ebbe qualche problema nel definire che cosa fosse gratis, e i produttori non resero mai chiara la loro politica di free software al resto del mondo. All'epoca, trovandomi a capo del progetto Debian, affrontai questi problemi proponendo un Contratto Sociale Debian e la Guida Debian del Free Software, nel luglio del 1997. Molti sviluppatori Debian inviarono critiche e miglioramenti che io incorporai nei documenti. Il Contratto Sociale documentava l'intenzione di Debian di costituire il proprio sistema interamente con free software, e la Guida rendeva facilmente possibile la classificazione del software come free software o meno, confrontando la licenza software con la guida stessa. La Guida Debian fu oggetto di molte lodi nella comunità del free software, specialmente fra gli sviluppatori Linux, che a quel tempo stavano preparando la loro propria rivoluzione software sviluppando il primo vero sistema operativo gratuito. Quando Netscape decise di rendere libero il suo browser Web, contattò Eric Raymond. Raymond, la Margaret Mead del free software, è autore di numerosi articoli di taglio antropologico che illustrano il fenomeno del free software e la cultura che vi è cresciuta intorno: scritti che furono i primi di un genere e che hanno messo sotto la luce dei riflettori questo fenomeno fino ad allora oscuro. La dirigenza di Netscape rimase suggestionata in particolare dal saggio di Raymond "La cattedrale e il bazaar", la cronaca di uno sviluppo free software coronato da successo con volontari non pagati, e gli chiese una consulenza, sotto patto di riservatezza, mentre sviluppavano una licenza per il loro free software. Raymond insisté che la licenza di Netscape dovesse adeguarsi alla guida Debian per poter essere presa sul serio come free software. Raymond e io ci eravamo incontrati qualche volta all'Hacker Conference, una raduno su invito di programmatori creativi e non convenzionali. Avevamo corrisposto via email su vari argomenti. Mi contattò nel febbraio del 1997 con l'idea per l'Open Source. Raymond temeva che la mentalità conservatrice dell'ambiente degli affari venisse scoraggiata dal grado di libertà di Stallman, che era al contrario popolarissimo fra i programmatori di mentalità più liberale. Era impressione di Raymond che ciò stesse sclerotizzando lo sviluppo di Linux nel mondo business laddove esso fioriva invece nell'ambiente della ricerca. Raymond ebbe incontri con uomini d'affari nell'industria Linux che stava muovendo solo allora i primi passi; insieme, essi concepirono un programma di marketing del free software indirizzato ai colletti bianchi. Furono coinvolti Larry Augustin di VA Research e Sam Ockman (che abbandonò più tardi VA per formare Penguin Computing), nonché altri non di mia conoscenza. Alcuni mesi prima dell'Open Source, avevo elaborato l'idea dell'Open Hardware, concetto simile rivolto agli strumenti hardware e alle loro interfacce anziché ai programmi software. A tutt'oggi l'Open Hardware non ha avuto il successo dell'Open Source, ma il progetto è ancora attivo; se ne può sapere di più a http://www.openhardware.org. Secondo Raymond, la Guida Debian era il documento più adatto a definire l'Open Source, ma serviva una denominazione più generale e la rimozione dei riferimenti specifici a Debian. Modificai la Guida Debian fino a ricavarne la Open Source Definition. Avevo formato per Debian un ente chiamato Software in the Public Interest, e mi offrii di registrare un marchio per Open Source in modo da poter associare il suo uso alla definizione. Raymond acconsentì, e io registrai una certificazione (una forma speciale di marchio che potesse applicarsi secondo i termini ai prodotti altrui). Circa un mese dopo la registrazione del marchio, apparve chiaro che Software in the Public Interest avrebbe potuto non essere la dimora migliore per il marchio Open Source, e trasferii dunque la proprietà del marchio a Raymond. Raymond e io abbiamo da allora formato la Open Source Initiative, un'organizzazione esclusivamente destinata alla gestione della campagna Open Source e della sua certificazione di marchio. Mentre scrivo, l'iniziativa Open Source è retta da un comitato di sei componenti scelti fra fornitori di free software di chiara fama, e sta cercando di espandere il suo comitato fino a una decina di persone. Al momento del suo concepimento, la campagna Open Source fu oggetto di molte critiche perfino da parte del contingente Linux che già aveva approvato il concetto di free software. Molti rilevarono che il termine Open Source era già in uso nel ramo della raccolta di dati per le campagne politiche. Altri pensarono che il termine Open fosse già usurato. Per altri ancora era preferibile il nome Free Software, già consolidato. Io opinai che l'abuso del termine Open sarebbe stato sempre meglio dell'ambiguità di free nella lingua inglese, in cui sta a significare tanto libero quanto gratuito, la seconda accezione essendo di gran lunga la più comune nel mondo del commercio di computer e di software. Più tardi, Richard Stallman obiettò alla mancanza di enfasi sulla libertà che secondo lui la campagna dimostrava, e al fatto che, mentre l'Open Source acquistava popolarità, il suo ruolo nella genesi del free software, e quello della sua Free Software Foundation, venivano ignorati: si lamentò di essere stato "cassato dalla storia". Peggiorò la situazione la tendenza degli operatori del settore di contrapporre Raymond a Stallman, quasi essi proponessero filosofie concorrenti anziché, sia pur con metodi diversi, propagandare lo stesso concetto. Io stesso contribuii probabilmente a esacerbare gli animi mettendo Stallman e Raymond l'uno contro l'altro in dibattiti pubblici alla Linux Expo e alla Open Source Expo. Caratterizzare i due come avversari diventò un'attività tanto consueta che una discussione via email, non destinata alla pubblicazione, apparve sul periodico on-line Salon. A quel punto, chiesi a Raymond di moderare i toni di un dialogo in cui, per la verità, egli non aveva mai inteso entrare. Quando la Open Source Definition fu scritta, esisteva già un gran numero di prodotti che potevano rientrare nella categoria. Il problema erano quei programmi che non vi rientravano, e che pure gli utenti trovavano irresistibili.
KDE, Qt e Troll Tech KDE fu il primo esperimento di un desktop grafico gratuito per Linux. Le applicazioni KDE erano esse stesse sotto GPL, ma dipendevano da una libreria grafica proprietaria nota come Qt, di Troll Tech. I termini della licenza di Qt ne proibivano la modifica o l'uso con qualunque display software che non fosse il senescente X Window System. Ogni uso diverso richiedeva allo sviluppatore una licenza del costo di 1500 dollari. Troll Tech fornì versioni di Qt per Windows di Microsoft e per Macintosh, e questa fu la sua principale fonte d'entrate. La licenza pseudo-gratuita per i sistemi X intendeva indirizzare i contributi degli sviluppatori Linux verso demo, esempi e accessori per i loro costosi prodotti Windows e Mac. Per quanto i problemi della licenza di Qt apparissero evidenti, la prospettiva di un desktop grafico per Linux era così attraente che molti utenti furono disposti a chiudere un occhio sulla sua natura non-Open Source. I promotori di Open Source trovarono che KDE fosse in difetto perché avevano l'impressione che gli sviluppatori stessero cercando di confondere la definizione di free software allo scopo di includervi elementi solo parzialmente gratuiti, come Qt. Gli sviluppatori KDE replicarono che i loro programmi erano Open Source, anche se non esistevano versioni eseguibili di quei programmi che non richiedessero una libreria non-Open Source. Io e altri sostenemmo che le applicazioni KDE non erano che frammenti Open Source di programmi non-Open Source, e che una versione Open Source di Qt sarebbe stata necessaria prima che ci si potesse riferire a KDE come a un Open Source. Gli sviluppatori KDE tentarono di risolvere parzialmente il problema della licenza di Qt negoziando con Troll Tech un accordo (KDE Free Qt Foundation) in cui Troll e KDE avrebbero congiuntamente controllato i rilasci delle versioni gratuite di Qt, e Troll Tech avrebbe rilasciato Qt sotto una licenza conforme a Open Source nel caso che l'azienda venisse acquisita o cessasse l'attività. Un altro gruppo diede inizio al progetto GNOME, un concorrente interamente Open Source di KDE che mirava a fornire maggiori funzioni e sofisticazioni; un gruppo separato avviò il progetto Harmony per produrre un clone di Qt completamente Open Source che avrebbe supportato KDE. Mentre le dimostrazioni di GNOME avvenivano fra il plauso e Harmony stava per diventare usabile, Troll Tech capì che QT non avrebbe riscosso successo nel mondo Linux se non avesse cambiato licenza. Troll Tech rilasciò dunque una licenza interamente Open Source per Qt, disinnescando il conflitto ed eliminando i motivi alla base del progetto Harmony. Il progetto GNOME continua tuttora, volto adesso a un KDE migliore in termini di funzionalità e di raffinatezza piuttosto che in termini di licenza. Prima di rilasciare la sua nuova licenza Open Source, Troll Tech me ne fece avere copia perché la verificassi, con la preghiera che rimanesse riservata finché non fossero in grado di annunciarla. Nel mio entusiasmo di far pace con il gruppo KDE e in un imbarazzante gesto di autoinganno, preannunciai con otto ore di anticipo la licenza su una mailing list KDE. Quell'email, per il mio rimorso, fu raccolta immediatamente da Slashdot e da altre riviste online. La nuova licenza Troll Tech è notevole perché approfitta di una scappatoia nella Open Source Definition che permette ai file patch di essere trattati diversamente dall'altro software. Vorrei provvedere a chiudere questa scappatoia in una revisione a venire della Open Source Definition, ma il nuovo testo non dovrebbe tuttavia collocare Qt al di fuori dell'Open Source. Al momento in cui scrivo, i promotori di Open Source stanno crescendo in misura esponenziale. I recenti contributi Open Source di IBM e di Ericsson hanno fatto i titoli dei giornali. Due distribuzioni Linux, Yggdrasil e Debian, stanno rilasciando distribuzioni di sistemi Linux completi, ivi incluse molte applicazioni che sono interamente Open Source; e molte altre, fra cui Red Hat, ci sono assai vicine. Quando il sistema GNOME sarà completo, sarà stato realizzato un sistema operativo con desktop GUI Open Source in grado di competere con Microsoft NT.
Analisi della Open Source Definition Alcuni pedanti hanno voluto trovare delle ambiguità di poco conto nella Open Source Definition. Mi sono astenuto da rivederla dal momento che ha poco più d'un anno di vita e vorrei che il pubblico la considerasse stabile. Il futuro imporrà qualche adeguamento lessicale, ma quasi nessuna modifica allo scopo del documento.
La Open Source Definition Si noti che la Open Source Definition non è propriamente una licenza software. È una specifica di quanto è ammesso in una licenza software perché vi si possa riferire come a un'Open Source. La Open Source Definition non è intesa per essere un documento di valore legale. L'inclusione della Open Source Definition nelle licenze software, quale quella proposta per il Progetto di Documentazione di Linux, sembra suggerirmi la stesura di una versione più rigorosa che sia appropriata per quell'uso. Ai fini dell'Open Source, devono applicarsi insieme tutti i termini che seguono, in tutti i casi. Per esempio, devono applicarsi alle versioni derivate di un programma così come al programma originale. Non è sufficiente applicarne alcune e non altre, e non è sufficiente se i termini non vengono applicati sistematicamente. Dopo aver dovuto affrontare delle interpretazioni particolarmente "semplici" della Open Source Definition, sono tentato di aggiungere: sto dicendo a voi!
Analisi delle licenze e loro conformità all'Open
Source
Public Domain Un programma di pubblico dominio è un programma sul quale l'autore abbia rinunciato a tutti di suoi diritti di copyright. Non si può esattamente dire che sia dotato di una licenza; è proprietà personale, per usarlo come meglio si crede. Dal momento che si può trattarlo come personale proprietà, con un programma di pubblico dominio si può fare quello che si vuole. Si può perfino ri-licenziare un programma di pubblico dominio, rimuovendo quella versione dal pubblico dominio, o togliendo il nome del suo autore e trattarlo come opera propria. Se si sta spendendo molto lavoro su un programma di pubblico dominio, si consideri la possibilità di applicarvi il proprio copyright e di rimetterlo sotto licenza. Per esempio, se non si desidera che una terza parte operi delle modifiche che possa poi mantenere riservate, si applichi la GPL o una licenza simile alla propria versione del programma. La versione da cui si è partiti rimarrà nel pubblico dominio, ma la propria versione sarà sotto una licenza che dovrà essere osservata da chi la usa o ne derivi altre. Un programma di pubblico dominio si rende privato facilmente, dichiarando un copyright e applicandovi la propria licenza, oppure semplicemente dichiarando "Tutti i diritti riservati".
Le licenze Free Software in generale È importante notare che un autore non deve necessariamente limitarsi a porre una sola licenza su un programma che pubblica. Un programma può essere posto sotto GPL, e una versione può anche essere venduta con una licenza commerciale, non-Open Source. Proprio di questa strategia si valgono molti che desiderano creare un programma Open Source e allo stesso tempo guadagnarci qualche cosa. Chi non vuole una licenza Open Source può pagare per il privilegio, fornendo all'autore una fonte d'entrate. Tutte le licenze che esamineremo hanno una caratteristica comune: declinano qualunque garanzia. Lo scopo è quello di proteggere il proprietario del software da qualunque responsabilità connessa al programma. Appare una richiesta ragionevole, dato che il programma viene ceduto a costo zero: l'autore non riceve dal programma una fonte d'entrata sufficiente per sostenere un'assicurazione sulle responsabilità ed eventuali spese legali. Se gli autori di free software perdessero il diritto di declinare tutte le garanzie e si trovassero a essere citati in tribunale in base alle prestazioni dei programmi che hanno scritto, smetterebbero di fornire software gratuito al mondo. È nel nostro interesse di utenti aiutare gli autori a proteggere questo diritto.
La GNU General Public License Il testo della. GPL non e a sua volta sotto GPL. La sua licenza è semplice: Chiunque può copiare e distribuire copie esatte di questo documento di licenza, ma non ne sono ammesse modifiche. Un punto importante, qui, è che il testo delle licenze di software Open Source di solito non è Open Source esso stesso. Ovviamente, una. licenza non porrebbe offrire protezione di alcun tipo se a chiunque fosse consentito apportarvi delle modifiche. Le clausole della GPL soddisfano la Open Source Definition. La GPL non richiede alcuna delle clausole consentite dal Paragrafo 4 della Open Source Definition. Integrità del codice sorgente dell'autore. La GPL non permette di mantenere private le modifiche apportate. Le modifiche devono essere distribuite sotto la GPL. In questo modo, l'autore di un programma sotto GPL ha maggiori probabilità di ricevere modifiche da altri, comprese società commerciali che modificano il suo software per i propri scopi. La GPL non ammette l'incorporazione di un programma sotto GPL in un programma proprietario. La definizione di GPL di programma proprietario lo indica come ogni programma con una licenza che non dia tanti diritti quanti la GPL. Esistono alcune scappatoie nella GPL che permettono di usarla in un programma non interamente Open Source. Le librerie software che vengono normalmente distribuite con il compilatore o con il sistema operativo che si usa possono essere collegate a software GPL: ne risulta un programma parzialmente libero. Chi detiene il copyright (di norma l'autore del programma) e la persona che mette il programma sotto GPL e ha il diritto di violare la propria licenza. Questa scappatoia e stata usata dagli autori di KDE per distribuire il loro programma Qt prima che Troll Tech ponesse su Qt una licenza Open Source. Tuttavia, questo diritto non si estende ad alcuna terza parte che ridistribuisca il programma: esse devono seguire tutti i termini della licenza, anche quelli che vengono violati dal detentore del copyright, il che rende problematico ridistribuire un programma che contenga Qt sotto GPL. Gli sviluppatori KDE sembrano inclini a rimediare a questo problema applicando al loro software la LGPL piuttosto che la GPL. La retorica politica presente nella GPL non e gradita a tutti. Non manca chi ha scelto, per il suo software, licenze non altrettanto adatte per semplice avversione alle idee di Richard Stallmann, pur di non aver voluto vederle ripetute nei propri pacchetti software.
La GNU Library Public License Una copia di un programma sotto LGPL può essere convertita in qualunque momento in una sotto GPL. Una volta che ciò succede, quella copia non e più riconvertibile in un programma sotto LGPL, e altrettanto dicasi di qualunque suo derivato. Le rimanenti clausole della LGPL sono simili a quelle della GPL: di fatto essa include la GPL facendovi riferimento.
Le licenze X, BSD e Apache La concessione più importante, assente dalla GPL, e che si può mantenere private le modifiche licenziate sotto licenza X. In altre parole, si può ottenere il codice sorgente di un programma sotto X, modificarlo e poi vendere versioni binarie del programma senza distribuire il codice sorgente delle modifiche e senza applicarvi la licenza X. Tutto ciò rimane comunque Open Source, poiché la Open Source Definicion non richiede che le modifiche debbano sempre ricadere sotto la licenza originale. Molti altri sviluppatori hanno adottato la licenza X e le sue varianti, compresi i progetti BSD (Berkeley System Distribution) e Apache Web server. Un dettaglio molesto della licenza BSD è costituito da una clausola che prescrive che ogni volta si faccia cenno a una caratteristica di un programma sotto BSD in una sua pubblicità, si menzioni (generalmente in una nota a pie di pagina) il fatto che il software è stato sviluppato all'Università della California. Ora, tener traccia di quale software abbia quella licenza in una cosa immensa come una distribuzione Linux, e ricordare quindi di menzionare l'Università della California ogni volta che uno di questi programmi venga citato in una pubblicità, e un vero mal di testa per i gestori commerciali del progetto, Nel momento in cui scrivo, la distribuzione Debian GNU/Linux contiene oltre 2500 pacchetti software, e se anche solo una piccola parte di essi fosse sotto BSD, la pubblicità per un sistema Linux come Debian dovrebbe contenere molte pagine solo di note! Tuttavia, la licenza dell'X Consortium non ha quella clausola della pubblicità. Se si pensa di usare una licenza tipo BSD si usi invece una licenza X.
La Licenza Artistica La. Sezione 5 della Licenza Artistica vieta la vendita del software, ma permette che sia venduta una distribuzione di software aggregato di più di un programma. In questo modo, se raggruppate un programma sotto Licenza Artistica con un Helloworld.c di cinque righe di codice, potete vendere il bundle. Questa caratteristica della Licenza Artistica e stata la sola causa della scappatoia dell'"aggregato" nel primo paragrafo della Open Source Definition. Dal momento che l'uso della Licenza Artistica e in netto declino, stiamo pensando di cogliere quella scappatoia. Ciò renderebbe la Licenza Artistica una licenza non-Open Source. Non è questo un passo che faremo leggermente, e ci vorrà probabilmente più di un anno di riflessione e di dibattito prima che questo accada, La Licenza Artistica richiede che le modifiche siano rese gratuite, ma fornisce poi una scappatoia (nella Sezione 7) che permette di mantenerle private e perfino di porre sotto dominio pubblico parti del programma sotto Licenza Artistica!
La Netscape Public License e la Mozilla Public License Una. caratteristica importante della. NPL è che contiene privilegi speciali che si applicano a Netscape e a nessun altro. Essa da a Netscape il privilegio di rilicenziare le modifiche fatte al suo software. Netscape può mantenere private quelle modifiche, migliorarle, e rifiutarsi di restituire il risultato. Questa clausola si e resa necessaria perché, quando Netscape decise per l'Open Source, aveva contratti con altre aziende che la impegnavano a fornir loro Navigator sotto una licenza non Open Source. Netscape ha. creato la MPL o Mozilla Public License per rimediare a questa situazione. La MPL e molto simile alla NPL, ma non contiene la clausola che permette a Netscape di rimettere le modifiche sotto licenza. La NPL e la MPL consentono di mantenere private le modifiche apportate . Molte aziende hanno adottato per i loro programmi una variante della MPL. Non e una buona cosa, perché la NPL era stata progettata per la particolare situazione contrattuale in cui Netscape si trovava. nel momento in cui la licenza veniva scritta, e non e detto che sia altrettanto adatta a usi diversi. Dovrebbe restare la licenza di Netscape e di Mozilla, e altri dovrebbero usare le licenze GPL o X.
Scegliere una licenza Ci si tenga alla larga dalla. Licenza Artistica, a meno che non si intenda studiarla fondo ed eliminarne le scappatoie. Fatto ciò, è tempo di prendere delle decisioni.
Questa che segue e una tabella comparativa delle licenze pubbliche:
Il Futuro Due promemoria interni della Microsoft, noti sono il nome di Halloween Documents, sono trapelati al pubblico online. Questi promemoria mostrano in modo inequivocabile come Microsoft si senta minacciata da Open Source e da Linux, e che MS lancerà un'offensiva contro di loro per proteggere i suoi mercati. E' chiaro che dobbiamo prepararci a vivere tempi interessanti. Credo che vedremo Microsof usare due principali strategie: interfacce sotto copyright e brevetti. Microsoft esrenderà i protocolli di rete, che contengono caratteristiche proprietarie Microsoft in quelli che non verranno resi disponibili al free software. Essa, con altre aziende, farà ricerca aggressivamente in nuove direzioni dell'informatica e brevetterà tutto quanto potrà prima che noi si possa. sfruttare quelle tecniche nel free software; quindi ci chiuderà fuori con le concessioni sui diritti di brevetto. Sono autore di un saggio per la webzine Linux World su come si possano battere i nemici dell'Open Source sul fronte dei brevetti. La buona notizia e che Microsoft i spaventata! Nel secondo degli Halloween Documents, un membro dello staff Microsoft racconta della sua sensazione d'euforia nel vedere come poteva modificare facilmente parti del sistema Linux perché facesse esattamente quello che voleva, e com'era più facile per un impiegato Microsoft fare questo su Linux di quanto non lo fosse modificare NT. I tentativi di nuocerci provenienti dall'interno sono i più pericolosi. Credo che vedremo altri sforzi per diluire la definizione di Open Source fino a includervi prodotti parzialmente gratuiti, come abbiamo visto avvenire con la libreria Qt in KDE prima che Troll tech vedesse la luce e rilasciasse una licenza Open Source. Microsoft e altri potrebbero danneggiarci rilasciando un sacco di software gratuito quel tanto da attrarre utenti, ma senza avere le piene libertà dell'Open Source. Non è impensabile che essi possano stronca.re lo sviluppo di certe categorie di software Open Source rilasciando soluzioni "abbastanza valide", "abbastanza quasi-gratis". Tuttavia, la forte reazione che si e avuta contro il progetto KDE prima che la libreria Qt divenisse completamente Open Source, non è di buon augurio per imprese analoghe di MS e compagnia. Finora abbiamo scampato i cavalli di Troia. Supponiamo che qualcuno che ci vuol male fornisca del software che contiene un cavallo di Troia un espediente per sconfiggere la protezione in un sistema Linux. Supponiamo, poi, che la medesima persona resti in attesa che il software con il cavallo di Troia sia largamente distribuito e quindi ne pubblicizzi la vulnerabilità agli attacchi alla sicurezza. Il pubblico si sarà per allora accorto che il nostro sistema Open Source può lasciarci più vulnerabili a questa sorta di attacchi che non il sistema chiuso di Microsoft; questo potrebbe ridurre la fiducia generale nel software Open Source. Potremmo obiettare che Microsoft ha la sua parte di bug di sicurezza anche se non lascia possibilità di inserirli a persone esterne e che il modello a codice sorgente aperto dell'Open Source rende più facile scoprire questi bug. Qualunque bug del genere che comparisse in Linux sarebbe riparato il giorno dopo essere stato scoperto, mentre un omologo in Windows o non sarebbe mai scoperto o dovrebbe aspettare il rimedio per anni. Ma dobbiamo rinforzare ancora la nostra difesa contro i cavalli di Troia. Identificare con sicurezza chi contribuisce alla creazione di software e delle modifiche e la difesa migliore di cui disponiamo, dal momento che ci permette di valerci del diritto penale contro chi escogita cavalli di Troia. Quando ero dirigente della distribuzione GNU/Linux di Debian, istituimmo un sistema che consentiva di identificare in modo affidabile tutti i manutentori del software e permetteva loro di partecipare a loro volta a una rete a crittografia a chiave pubblica che ci avrebbe consentito di verificare da chi proveniva il nostro software. Questo tipo di sistema si deve espandere fino a comprendere tutti gli sviluppatori Open Source. Enormi sono i miglioramenti da intraprendere prima che Linux sia davvero alla. portata dell'utente medio. L'interfaccia grafica per gli utenti e chiaramente qualcosa che manca, e a questo sono rivolti i progetti KDE e GNOME. La prossima frontiera è l'amministrazione di sistema linusconf vi sta parzialmente provvedendo, ma si trova ben lungi dall'essere uno strumento completo d'amministrazione di sistema per l'utente sprovveduto. Se il sistema COAS di Caldera avrà successo, potrebbe diventare la base per una soluzione completa al problema dell'amministrazione di sistema. Tuttavia, Caldera ha avuto dei problemi nel mantenere un'allocazione di risorse sufficienti a COAS per terminarne lo sviluppo, e altri sviluppatori hanno abbandonato la partita perché non notavano progressi. La pletora di distribuzioni Linux appare oggi in pieno rivolgimento, con Red Hat percepita come vincitrice e Caldera come seconda. Red Hat ha mostrato finora un solido impegno verso il concetto di Open Source, ma un nuovo presidente e voci di un'offerta pubblica iniziale (Initial Pubblic Offering, IPO) potrebbero significare un indebolimento di quest'impegno, specialmente se concorrenti come Caldera, molto più tiepidi verso l'Open Source, riusciranno a inserirsi nel mercati di Red Hat. Se l'impegno delle distribuzioni Linux commerciali verso l'Open Source diventerà problematico, questo genererà probabilmente uno sforzo per rimpiazzarle con tentativi Open Source simili al GNU/Linux di Debian ma più diretti al mercato commerciale di quanto non sia stata Debian. Malgrado queste sfide, io predico la vittoria dell'Open Source. Linux è divenuto strumento di test per gli studenti d'informatica, che, una volta laureati, porteranno con sé quegli strumenti nei loro posti di lavoro. Molti laboratori di ricerca hanno adottato il modello Open Source in quanto la condivisione delle informazioni è essenziale al metodo scientifico, e l'Open Source consente al software di essere condiviso facilmente. Il mondo business sta adottando il modello Open Source perché consente a gruppi di aziende di collaborare nella risoluzione di un problema senza la minaccia di una causa anti-trust, e per l'impulso di cui gode quando i contributi pubblici di programmazione rendono gratuite le migliorie al software. Alcune gran- di società hanno adottato l'Open Source come strategia per combattere Microsoft e per scongiurare l'avvento di un'altra. Microsoft a dominare il settore informatico. Ma l'indicazione più affidabile sul futuro dell'Open Source viene dal suo passato: in pochi anni, dal niente siamo arrivati ad avere un robusto corpus di software che è in grado di risolvere tanti problemi diversi e che si avvia a raggiungere il milione di utenti. Non c'e ragione di rallentare la corsa. proprio adesso. Hardware, software e infoware di Tim O'Reilly Parlavo recentemente con alcuni amici che non possiedono un computer; stavano pensando, però, di acquistarne uno per usare Amazon.com e comprare libri e CD. Attenzione: non per usare "l'Internet", non per usare "il Web": per usare Amazon.com. Ecco un esempio classico di "killer application": di quel genere che, da sola, basta a convincere qualcuno ad andare a comprarsi il computer. È notevole che una killer application, oggi, non sia più un programma di produttività individuale o anche un software aziendale di back-office, ma un singolo sito Web. Se cominciamo a pensare ai siti Web come applicazioni, ci accorgeremo presto che essi rappresentano una specie del tutto nuova, qualche cosa che potremmo chiamare "applicazione informativa" o anche "infoware". Le applicazioni informative servono per computerizzare compiti ingestibili dal vecchio modello informatico. Solo pochi anni fa, per fare ricerche all'interno di un database composto da un milione di libri ci si sarebbe dovuti rivolgere a un bibliotecario esperto della sintassi arcana degli strumenti informatici di ricerca allora disponibili e che - forse - avrebbe potuto trovare quanto cercato. Per comprare un libro si andava in una libreria e se ne esaminava la scelta, sempre relativamente ridotta. Oggi, ogni giorno, decine di migliaia di persone senza preparazione specifica trovano e comprano online libri in quel database da un milione di record. Il segreto? I computer hanno compiuto un passo decisivo nell'avvicinarsi al modo in cui le persone comunicano fra loro. Le applicazioni residenti su Web costruiscono la loro interfaccia con la lingua corrente - parole e immagini anziché minuti controlli specializzati che assumono un significato solo per chi abbia prima imparato il software. Il software tradizionale integra dosi modiche d'informazione entro una quantità ingente di software; l'infoware integra modiche dosi di software in una quantità ingente d'informazione. Le "azioni" richieste all'utente da un infoware sono di solito abbastanza semplici: fare una scelta, comprare o vendere, inserire qualche dato e ottenerne un risultato personalizzato. Queste azioni sono per lo più eseguite da uno script correlato a un collegamento (link) ipertestuale tramite una specifica d'interfaccia nota come CGI (Common Gateway Interface). La CGI definisce un modo in cui un server Web può richiamare un qualunque programma esterno e restituirne l'output in forma di pagina Web. I programmi CGI possono non essere altro che piccoli script che eseguono semplici calcoli, ovvero possono connettersi a server di database back-end di grandi dimensioni. Ma anche quando un sito cela un motore software complesso, l'interfaccia utente non risulta composta di software tradizionale. Essa consiste infatti di pagine Web non necessariamente create da un programmatore, ma magari da un giornalista, da un redattore o da un grafico. Le interfacce informative sono normalmente dinamiche. Per esempio, la presentazione dei libri in Amazon.com è determinata da classifiche di vendita aggiornate di ora in ora. I clienti possono aggiungere al volo, in tempo reale, commenti e voti, che diventano parte integrante dell'interfaccia ad alto tasso informativo che supporta le decisioni degli acquirenti. Un sito progettato per aiutare l'utente a comprare o a vendere online quote azionarie deve fornire non solo i valori aggiornati delle azioni ma anche le ultime notizie rilevanti, informazioni sulle aziende, consigli di analisti e magari anche gruppi di discussione composti da utenti. L'interfaccia informativa consiste dunque di una variata miscela di documenti generati manualmente, di dati generati da programmi e di collegamenti a server per applicazioni specializzate (email, chat, conferenze online). Le interfacce informative sono meno efficienti delle pure interfacce software nello svolgere compiti ripetitivi, ma sono molto preferibili per compiti eseguiti raramente, oppure ogni volta in maniera diversa. In particolare, sono adatte alle interfacce in cui l'utente è indotto a operare una scelta sulla base di informazioni presentategli. Sia che si acquisti un libro o un CD su Amazon.com, o uno stock d'azioni su E*Trade, l'atto dell'acquisto in sé non è che la parte più banale dell'interazione. È la qualità informativa fornita in supporto alla decisione che forma il cuore dell'applicazione con cui s'interagisce. Il modo in cui il Web sta trasformando l'intero paradigma informatico non mi è mai apparso tanto chiaro quanto nel 1994, prima cioè che la Microsoft si convertisse alla religione Web. Mi trovavo allora in Giappone, in occasione di un evento NTT, a dividere il palcoscenico (via satellite) con il vice-presidente di Microsoft, Craig Mundie. Mundie stava dando dimostrazione della progettata interfaccia del server "Tiger" di Microsoft, che avrebbe dovuto rendere possibile il video-on-demand. L'interfaccia emulava Windows, con menu a tendina in risposta a una sorta di cambiacanali in forma di telecomando virtuale. Risultava abbastanza chiaro a chiunque conoscesse il Web che l'interfaccia giusta per il video-on-demand, se e quando ne fosse venuto il momento, era un'interfaccia informativa in stile Web. Suona ironico che già allora la Microsoft si trovasse per le mani l'interfaccia perfetta del video-on-demand: Cinemania, la sua enciclopedia del cinema su CD-ROM. Quale sistema migliore per scegliere un film che ricercarlo in un elenco per categorie, leggerne qualche recensione, vederne qualche clip e quindi, ultimato il compitino, fare clic su un link ipertestuale e farlo partire? Fuorché l'ultimo passo, Cinemania aveva tutto questo. L'autentica potenza dei prodotti informativi ipertestuali si rivela solo quando essi sono connessi a dei server di rete. Di colpo, l'informazione non è più fine a se stessa, ma è un'interfaccia che permette a chi la usa di controllare uno spazio d'applicazione di gran lunga troppo complesso per un'applicazione software tradizionale (Amazon.com, è chiaro, questo lo sa bene: la loro acquisizione dell'Internet Movie Database, una raccolta di recensioni di utenti e di informazioni assortite sui film, li piazza in pole position non solo per la vendita online di videocassette, ma anche come futura rampa per i servizi di video-on-demand). Le interfacce informative sono ideali per applicazioni di ausilio alle decisioni, ma sono utili anche per compiti occasionali. In un certo senso, un esempio della medesima tendenza sono i "wizard", le procedure interattive per l'installazione del software. Esistono anche applicazioni informative che interagiscono con l'utente attraverso interfacce più semplici e più affini al software, ma che forniscono un risultato informativo dinamico. L'esempio che più mi piace fare è una cosa che solo poco tempo fa sarebbe stata praticamente impensabile come applicazione: ottenere carte e indicazioni geografiche. In maps.yahoo.com, sito dedicato alla carte geografiche, s'inseriscono due località e se ne ottiene una mappa stradale e una serie di indicazioni per andare dall'una all'altra. D'accordo: ma che cosa ha tutto ciò a che fare con il software Open Source? Una possibile risposta è ovvia: la maggior parte delle tecnologie che rendono possibile il Web sono Open Source. Internet stessa - e mi riferisco a funzioni quali il protocollo di rete TCP/IP e a elementi chiave d'infrastruttura come il Domain Name System (DNS) - sono stati sviluppati tramite un processo Open Source. Si potrebbe facilmente osservare che il programma Open Source BIND (Berkeley Internet Name Daemon), che esegue il DNS, è la singola applicazione più vitale per l'Internet. Anche se la maggior parte del browsing su Web è fatto con prodotti proprietari (Navigator di Netscape e Internet Explorer di Microsoft), entrambi provengono dai lombi dell'implementazione Web originale - e Open Source - e dalle specifiche a protocollo aperto di Tim Berners-Lee. Secondo la ricognizione automatica dei server Web compiuta da Netcraft (http://www.netcraft.co.uk/survey), oltre il 50% di tutti i siti Web visibili sono serviti dal server Web Open Source Apache. La maggioranza dei contenuti dinamici su base Web viene generata da linguaggi di scripting Open Source (Perl, Python, Tcl, ecc). Ma queste ovvietà non raccontano l'intera storia. Perché, dopo tutto, sarà il Web, anziché qualche tecnologia proprietaria, la base delle applicazioni informative in rete di domani? Microsoft, di fatto, era avanti a tutti nell'intuire il potenziale della multimedialità online. Nel 1994, anno del decollo del Web, i CD-ROM Microsoft come Encarta, enciclopedia online, e Cinemania, di cui s'è detto, superavano il Web nel fornire documenti online riccamente multimediali, collegati ipertestualmente. Microsoft finì addirittura con l'accorgersi dell'importanza di fornire risorse informative tramite reti online. Uno solo era il problema nella concezione Microsoft del Microsoft Network: altissime barriere all'entrata. I fornitori di contenuti avrebbero dovuto usare strumenti Microsoft, sottoporsi a un esame d'ammissione di Microsoft e pagare per esserci. Di contro, un sito Web poteva essere allestito da chiunque. Il software necessario era gratis. Le specifiche per la creazione di documenti e contenuti dinamici erano semplici, aperte e complete di chiara documentazione. Cosa ancora più importante, tanto la tecnologia che l'etica Internet rendevano legittimo il copiare dai siti altrui. Le pagine HTML (HyperText Markup Language) adoperate nell'implementazione di varie funzioni su un sito Web si potevano tranquillamente salvare e imitare. Anche gli script CGI usati per creare contenuti dinamici erano copiabili. Proprio in virtù della sua accessibilità, Perl diventò il linguaggio d'elezione delle CGI, malgrado la maggiore velocità d'esecuzione di linguaggi tradizionali quali il C. Perl è potente abbastanza per scrivere applicazioni importanti, ma allo stesso tempo un programmatore dilettante può usarlo in piccoli script per compiti specializzati. Soprattutto, visto che Perl non è un linguaggio compilato, gli script in uso sulle pagine Web possono essere visualizzati, copiati e modificati dagli utenti. Si aggiunga che sono stati per tempo allestiti e condivisi fra gli sviluppatori Web degli archivi pieni di utili script Perl. L'agevole clonazione di siti Web costruiti con il trio HTML + CGI + Perl significava che, per la prima volta, la creazione di applicazioni potenti era alla portata di non-programmatori. È interessante, a questo proposito, osservare che i primi tentativi dell'industria del software per migliorare l'interfaccia Web tramite contenuti attivi (tecnologie come gli applet Java dal lato del browser e i controlli ActiveX di Microsoft) fallirono, perché indirizzati a programmatori di professione e non imitabili e implementabili facilmente dai dilettanti che, di fatto, stavano costruendo il Web. I produttori, cioè, vedevano il Web in termini di software, non comprendendo che il Web cambiava non solo la natura delle applicazioni create, ma anche gli strumenti necessari ai loro creatori. Gli analisti dell'industria vanno pronosticando da anni l'eclisse di Perl e CGI a opera di tecnologie software più avanzate. Ma ancora oggi, quando i siti Web più grandi impiegano staff immensi di professionisti della programmazione, e tecnologie nuove come le ASP (Active Server Pages) di Microsoft e le servlet Java di Sun stanno soppiantando le CGI con le loro prestazioni superiori, ancora oggi la popolarità di Perl è in crescita. Perl, così come altri linguaggi di scripting Open Source, quali Python e Tcl, rimane d'importanza centrale in siti Web grandi e piccoli: perché le applicazioni infoware sono essenzialmente diverse da quelle software, e richiedono strumenti diversi. Date un'occhiata a un sito immane come Yahoo!. Vedrete che, dietro le quinte, schiere di amministratori di sistema e di programmatori fanno e disfano senza sosta il prodotto. I contenuti dinamici non sono generati in automatico così semplicemente: vogliono spesso un aggiustamento manuale, di solito fatto con strumenti di scripting veloci e non molto raffinati. "Qui a Yahoo! noi non creiamo contenuti: li assembliamo", dice Jeffrey Friedl, autore del libro "Mastering Regular Expressions" e programmatore Perl a tempo pieno a Yahoo!. "Riceviamo materiali da migliaia di fonti, e ognuna usa un suo formato. Pratichiamo un intensissimo trattamento dei materiali, per ripulirli o per trovare loro la giusta collocazione su Yahoo!". Per esempio, in quotes.yahoo.com, l'area borsistica di Yahoo!, per collegare con un link un servizio a un ticker (banner pubblicitario scorrevole), Friedl ha dovuto scrivere un programma di riconoscimento in grado di ricercare oltre 15.000 nomi di aziende. Ciò è stato reso possibile dalla capacità di Perl di analizzare, attraverso potenti espressioni regolari, del testo non formattato. Perl è anche un componente centrale nell'infrastruttura d'amministrazione di sistema che mantiene il sito vivo e aggiornato. Un enorme numero di script in Perl perlustra in continuazione i server di Yahoo! e i loro link a siti esterni, precettando lo staff ogni qual volta un URL non restituisca il risultato dovuto. Il più noto di questi "crawler" è chiamato "the Grim Reaper", "la Cupa Mietitrice". Se la connessione automatica a un URL fallisce oltre un certo numero di volte, la pagina viene depennata dalla directory di Yahoo!. Anche Amazon.com consuma Perl in quantità industriali. Il suo ambiente di authoring è una dimostrazione della potenza di Perl nel tenere assieme strumenti disparati: è un "linguaggio colla" per eccellenza. Un utente crea un documento nuovo con un modulo che richiama un programma Perl, che genera un documento parziale in SGML e quindi lancia Microsoft Word o GNU Emacs (l'utente lo decide), ma integra anche CVS (Concurrent Versioning System) con gli strumenti proprietari SGML di Amazon.com. Le classi SGML di Amazon.com vengono usate per generare sezioni diverse del sito Web (per esempio, HTML con o senza grafiche) dal medesimo codice sorgente. Un parser basato su Perl traduce lo SGML in HTML per l'approvazione, prima che l'autore invii le modifiche. Perl è stato definito "il nastro adesivo di Internet" e, come il nastro adesivo, viene utile nei modi più inattesi. Come un set cinematografico allestito usando nastro adesivo, un sito Web è spesso montato e smontato nel giro di un giorno, e richiede per questo strumenti leggeri e soluzioni veloci ed efficaci. Il fiasco di Microsoft nel riportare l'infoware a software per mezzo di ActiveX si spiega col modo in cui i paradigmi cambiano nell'industria informatica. Quando un certo segmento di mercato diviene maturo, gli attori in gioco hanno un interesse enorme, per quanto dissimulato, nel mantenere lo status quo. È questo che rende loro difficile abbracciare alcunché di veramente nuovo, e che mette in grado, o meglio, obbliga, i nuovi attori ("i barbari", per dirla con Philippe Kahn) a intervenire per creare nuovi mercati. Il prevalere di Microsoft su IBM nel dettar legge all'industria informatica è un esempio classico di come ciò si sia svolto nel passato recente. IBM ha ceduto il mercato a Microsoft perché non ha colto come il trapasso di potere non fosse solo dalla "casa di vetro" al desktop, ma anche dall'hardware proprietario all'hardware come categoria merceologica, e dall'hardware al software. Allo stesso modo, e a dispetto dei suoi sforzi per mettere il piede in varie imprese collegate all'informazione, Microsoft non si accorge ancora (ma potrebbe accorgersene e continuare a essere Microsoft?) che il software, come essa l'ha sempre conosciuto, non è più l'impulso centrale alla creazione di valore nell'industria informatica. Ai tempi del dominio IBM, l'hardware era re e le barriere per venire ammessi nel business dei computer erano alte. Quasi tutto il software era opera dei costruttori di hardware, o di produttori di software loro satelliti. La disponibilità del PC come piattaforma e non più come marchio di fabbrica (così come lo sviluppo di piattaforme a sistemi aperti come Unix) ha sovvertito le regole. Improvvisamente le barriere si sono abbassate e imprenditori come Mitch Kapor di Lotus e Bill Gates sono entrati in orbita. Se si guarda ai primordi del Web, si può distinguere un'impronta simile. Il monopolio di Microsoft sul software desktop ha reso insostenibilmente alte le barriere d'entrata nel business del software. Di più, le applicazioni software sono diventate sempre più complesse, con Microsoft a erigere deliberatamente ostacoli all'entrata di concorrenti nel mercato. Non esisteva più la possibilità che un programmatore, lavorando in solitudine nel suo garage (o nella sua soffitta), producesse un qualche impatto. È questa forse l'osservazione più significativa a proposito del software Open Source: abbassa le barriere per entrare nel mercato del software. Un prodotto nuovo si può provare gratis, ma non solo, l'utente se lo può personalizzare, sempre gratis. Il codice sorgente è disponibile all'ispezione totale dei concorrenti. Se una caratteristica non piace, la si può togliere o affiancare o reimplementare. Quando una modifica è a sua volta offerta liberamente alla comunità, può venire adottata in modo esteso in men che non si dica. E dal momento che gli sviluppatori (almeno nella fase iniziale) non stanno cercando la competizione nel segmento business, preferendo concentrarsi sulla risoluzione di problemi reali, c'è spazio per la sperimentazione in un ambiente meno punitivo. Com'è anche stato detto, col software Open Source ciascuno "si cucina la minestra che vuole". Grazie al paradigma dello sviluppo distribuito, in cui le nuove funzioni vengono aggiunte dagli utenti, evoluzione e progettazione dei programmi Open Source vanno di pari passo. È facile capire che le forze evolutive del mercato sono più libere di operare secondo la loro natura allorché sono meno gravate da barriere o da strategie di marketing (l'equivalente delle protesi per certi handicap fisici). L'evoluzione non produce un vincitore, ma la diversità. È proprio nella natura idiosincratica di tanti dei programmi Open Source che risiede la loro forza. Una volta di più, il successo di Perl è istruttivo. Larry Wall creò Perl per automatizzare alcuni compiti ripetitivi che gli si presentavano nell'amministrazione di sistema. Dopo aver rilasciato su Internet il software, trovò applicazioni sempre più numerose e il linguaggio crebbe, spesso in direzioni inaspettate. Perl è stato descritto come "un linguaggio lavandino" a causa delle sue caratteristiche, caotiche agli occhi dei creatori di linguaggi più "ortogonali". Ma spesso il caos rivela una struttura più ricca: può addirittura essere indispensabile per imitare quello che è intrinsecamente complesso. I linguaggi umani sono complessi perché riproducono la realtà. Scrive Wall nell'intervento contenuto in questo volume: "La praticità della lingua inglese sta nel suo disordine. Dato che l'Inglese è disordinato, si adatta bene a mappare lo spazio dei problemi, ch'è pure disordinato... Analogamente, Perl fu progettato per essere disordinato (anche se nel modo meno sgradevole possibile)". Il paradigma di sviluppo Open Source è una maniera incredibilmente efficiente di mettere gli sviluppatori al lavoro sulle funzioni che contano davvero. Il nuovo software è sviluppato in stretto feedback circolare con le necessità dei clienti, senza le distorsioni indotte dalle forze del marketing o da decisioni d'acquisto provenienti dall'alto. Lo sviluppo software dal basso è quel che ci vuole per risolvere i problemi che "dal basso" provengono. Adoperando il software Open Source che è al cuore del Web e il suo paradigma semplificato di sviluppo, imprenditori come Jarry Yang e David Filo hanno fatto proprio questo. Non è per caso che Yahoo!, il sito più grande e di maggior successo al mondo, sia costruito attorno a software Open Source disponibile liberamente: il sistema operativo FreeBSD, Apache e Perl. Così come è avvenuto l'ultima volta, la chiave del prossimo stadio dell'industria informatica è infatti nella liberazione dello stadio precedente dai vincoli proprietari. Come ha notato Bob Young di Red Hat, distributore leader di Linux, il suo fine non è di scalzare Microsoft dal trono dei sistemi operativi, ma piuttosto di restringere il valore monetario di quel mercato. Il punto è che il software Open Source non deve proporsi di battere Microsoft facendo il suo gioco, ma invece di cambiare la natura del gioco. Di certo, e malgrado le loro capitalizzazioni astronomiche, i fornitori di applicazioni informative quali Amazon.com e Yahoo! sono ancora piccoli a paragone di Microsoft. Ma la scritta sul muro parla chiaro: la punta avanzata dell'interazione uomo-computer, le opportunità di computerizzare compiti mai computerizzati prima, risiedono non nel software, ma nell'infoware. Nel momento in cui emergono queste nuove "killer application", il ruolo del software appare sempre più quello di agevolare l'infoware. Infinite sono le opportunità commerciali per chi fornisce server Web, back-end per database, server per applicazioni e linguaggi di programmazione di rete come Java, purché questi prodotti sappiano adattarsi al nuovo modello anziché tentare di soppiantarlo. Si noti che in passato, nella migrazione da un'industria informatica hardware-centrica a una software-centrica, l'hardware non è scomparso; l'IBM è tuttora un'azienda fiorente (anche se molti dei suoi concorrenti si sono ridotti, o sono malridotti). Ma altri attori dell'hardware sono emersi che hanno saputo adottare le regole nuove: Dell, Compaq e soprattutto Intel. Intel ha capito che la sua vera opportunità non era vincere la guerra dei sistemi, ma fornire le armi ai combattenti. La sfida autentica, per il software Open Source, non è: rimpiazzerà Microsoft nel predominio sui desktop? ma piuttosto: saprà escogitare una strategia commerciale che gli consenta di diventare l'"Intel Inside" della prossima generazione di applicazioni per computer? Se non vorranno capire questo, i pionieri dell'Open Source saranno spinti brutalmente da parte (come avvenne a Digital Research nel business dei sistemi operativi per PC) da chi avrà intuito precisamente dove stanno le vere occasioni. Comunque vada, il software Open Source ha già creato una biforcazione di percorso. Proprio come i pionieri del microcomputer (hardware e software) allestirono la scena per l'industria odierna, il software Open Source ha allestito la scena per il dramma che va svolgendosi sotto i nostri occhi, e che condurrà a una riforma radicale del paesaggio dell'industria informatica nel corso dei cinque o dieci anni a venire. Liberare il sorgente: la storia di Mozilla di Jim Hamerly e Tom Paquin, con Susan Walton
Il 23 gennaio 1998 Netscape fece due annunci. Questo è il primo, come riportato da C|Net: "Con una mossa senza precedenti, Netscape Communications cederà il suo browser Navigator, confermando le voci delle ultime settimane". Il secondo: "Netscape renderà pubblico anche il codice sorgente per la prossima generazione della sua suite Communicator". La decisione di cedere il browser non arrivò inaspettata, ma il rilascio del codice stupì il settore, arrivò sulle pagine dei giornali di tutto il mondo e colse di sorpresa perfino la comunità Open Source. Mai prima di allora una grande azienda software aveva aperto il proprio codice proprietario. Che intenzioni aveva Netscape? Avevamo deciso di cambiare terreno di gioco, e non per la prima volta. Netscape, nota da sempre per pensare in maniera anticonvenzionale, si stava questa volta impegnando a costruire un’Internet migliore su un nuovo livello. Quando Netscape diede avvio alla distribuzione non vincolata delle prime versioni del suo browser su Internet, nel 1994, vi fu chi disse "sono pazzi!". Lo stesso quando Netscape liberalizzò il codice. Il periodo di discussione che condusse all’annuncio dell’Open Source si mosse come un treno senza conducente. Dopo mesi di riflessioni sull’opportunità di rilasciare o di non rilasciare il codice binario gratis, si raggiunse nell’incredibile spazio di ventiquattr’ore una massa critica in favore della decisione di liberare il sorgente. Per veloce e sorprendente che l’annuncio potesse sembrare sia agli addetti che al pubblico, esso rifletteva molti percorsi di pensiero confluenti. I dirigenti di Netscape stavano discutendo un white paper di Frank Hecker che esprimeva un punto di vista emergente. Nel documento, egli propugnava la liberalizzazione del sorgente da parte di Netscape. Frank aveva fatto bene i suoi compiti, citando il saggio di Eric Raymond "La cattedrale e il bazaar" e discutendo in prima istanza con il personale in tutti i settori dell’organizzazione, dalla progettazione al marketing alla dirigenza. In un saggio di venti pagine che ebbe un’ampia diffusione, perorò il caso che si stava montando: Quando Netscape per la prima volta rese Netscape disponibile al download libero su Internet, molti videro ciò come uno schiaffo alla normale accortezza nel commercio del software e si domandarono come mai pensassimo di guadagnare "dando via" il nostro software. Ora, naturalmente, questa strategia appare in retrospettiva come un'innovazione di successo che è stata un fattore chiave nella rapida crescita di Netscape; e sono rare, oggi, le aziende software che, in un modo o nell'altro, non la emulino. Fra l'altro, questo suscita la domanda seguente: che cosa accadrebbe se lo rifacessimo, questa volta con il codice sorgente? I progettisti sembravano vederla allo stesso modo. Molti impiegati di Netscape avevano esperienza di lavori open source, e dal momento che il codice di Communicator era cosi strettamente integrato con Java e HTML, molti videro affiorare una verità: il salto non era cosi grande. La natura stessa di Java invita a vedute più aperte sulla distribuzione del sorgente. Dal momento che è multipiattaforma e può essere compilato fino a file di classi che risultino eseguibili indipendentemente dalle macchine su cui girano, ogni binario e come una macchina virtuale. Di conseguenza i programmatori possono decompilare l'eseguibile e ritrasformarlo in codice sorgente. Anziché cercare di ostacolare questa pratica, molti in Netscape credevano che si dovesse incoraggiare, facilitare e, se possibile, trarne profitto. Le varie scuole di pensiero di base si incontrarono con inattesa rapidità. Nelle riunioni, le reazioni alla proposta variarono dallo shock totale all'approvazione quasi istantanea. La maggior parte delle discussioni trascorsero velocemente dal "Ma dovremmo proprio?" al "Quando cominciamo?". Era convinzione diffusa che ci si dovesse muovere in fretta, stabilire una data e darsi da fare. In gennaio, Netscape fece alla Rete una promessa: il sorgente di Communicator sarebbe stato rilasciato nel primo quadrimestre del 1998. Netscape prese la promessa dannatamente sul serio e così vide la luce il Project Source 331. Quello era il nome dello sforzo di Netscape per fare uscire il codice sorgente entro il 31 marzo 1998. Non avevamo fatto i conti con la realtà.
Darsi da fare
Ci fu moltissimo da fare per rendere il codice pronto all'esordio pubblico. Man mano che i problemi emergevano, si separavano e si raccoglievano in categorie. I tre mesi seguenti furono dedicati alla risoluzione di problemi al ritmo pazzesco ben familiare ai Netscapisti. Uno dei problemi principali era come disporre dei moduli di terze parti inclusi nel browser. Communicator conteneva nel suo codice più di settantacinque moduli di terze parti: e tutti i proprietari del codice avrebbero dovuto essere contattati. Team interi di progettisti e di evangelisti si organizzarono per visitare e per convincere ognuna di quelle società a unirsi a Netscape sulla strada verso l'Open Source. Tutte avevano avuto notizia dell'annuncio open source di Netscape e ora ciascuna doveva fare una scelta: il loro codice poteva venir tolto o rimpiazzato, consegnato come binario (cioè mantenuto nel suo stato compilato) ovvero consegnato come codice sorgente insieme a Communicator. Per complicare le cose, molti dei contratti con le terze parti erano unici e avevano durate diverse. Non sembrava possibile trovare una soluzione universale. Rispettare i termini fissati per il Project Source 331 era considerato essenziale. Ciò richiedeva di scegliere con assoluta determinazione, specialmente nel caso della partecipazione degli sviluppatori delle terze parti. La regola fu: o entro il 14 di febbraio sarete dentro, o il vostro elemento sarà cancellato dal sorgente. Questo genere di scadenze non è difficile da imporre quando le si prevede per tempo, ma diventano brutali poste all'ultimo momento. Arrivati al punto, parte del codice dovette essere rimosso. Java era un linguaggio proprietario, quindi lo si dovette togliere. A tre progettisti fu affidata la "Javectomia". Il browser dovette essere costruito, compilato ed eseguito senza Java. Dato il modo in cui il codice complessivo era strettamente integrato a Java, non fu impresa da poco. L'obiettivo era di avere il codice sorgente pronto per il 15 marzo, cosi da poter usare le ultime due settimane per il testing. I progettisti si trovarono a dover districare rutto il codice di Java dal browser in un tempo assurdamente breve. Ripulire il codice fu un progetto immenso. All'inizio, molti pensarono che, semplicemente, non avremmo potuto farcela in tempo per la scadenza. Ma mentre la tensione nelle riunioni aumentava, cominciavano anche a formarsi le strategie del caso. Le ruote cominciarono a mettersi in moto. II team di prodotto lasciò perdere tutto il resto (per lo più era al lavoro sulla successiva generazione di browser) e tutti si dedicarono a questo intervento chirurgico. Non bisognava solo risolvere il problema dell'inclusione (o dell'esclusione) di ogni terza parte partecipante, ma bisognava togliere tutti i commenti dal codice. Ogni modulo fu affidato per la ripulitura a uno specifico team. Una delle grandi innovazioni che si mise subito in luce fu la decisione di usare il sistema di segnalazione dei bug intranet come task manager. Scopus, un programma di segnalazione bug con interfaccia HTML fu ribattezzato "Bugsplat". Era ideale come sistema di gestione del flusso di lavoro. Le cose da fare venivano riportate al sistema al momento in cui emergevano, inserite in un semplice modulo HTML. Proprio come quando un bug viene riportato al sistema, furono stabilite le priorità, furono stabiliti i partecipanti adatti e attorno a ogni compito fu costituita una mailing list. Quando il compito, o il bug, veniva risolto, tutte le mailing list e le priorità collassavano e sparivano alla vista. I progettisti potevano tener traccia dei progressi dei loro moduli e sorvegliare lo svolgimento del progetto collegandosi all'intranet. La rimozione dei moduli crittografici fu un altro sforzo doloroso per il team di progetto. Non solo il governo insistette perché venisse rimosso qualunque supporto crittografico, ma ogni ansa di programmazione (hook) che lo richiamasse dovette essere riscritta. Fu compito di un team specifico il tenersi in contatto costante con la NSA e gestire i problemi di conformità.
Creazione della licenza
Un gruppo di leader della comunità Open Source, fra i quali Linus Torvalds, Eric Raymond e Tim 0'Reilly, furono invitati a visitare il campus di Mountain View. Parlarono a un pubblico di dirigenti, avvocati e programmatori della ragione per cui si trovavano lì e s'incontrarono con piccoli gruppi per parlare di alcuni dei problemi che avrebbero probabilmente dovuto affrontare. Trascorsero molto tempo con l'ufficio legale Netscape discutendo le licenze esistenti, i loro punti forti e i problemi che creavano. Questi consulenti agirono anche da cassa di risonanza per le idee. Una squadra si immerse nell'esame degli accordi di licenza esistenti con l'ausilio e la guida dell'ufficio legale Netscape, cercando di determinare se uno di questi potesse funzionare per Mozilla. A cominciare dalla GNU General Public License, la GNU Library General Public License (LGPL) e la licenza BSD, facemmo studi accurati per determinare esattamente quali problemi esse risolvessero e quali creassero. A differenza del codice a cui questi accordi erano nel passato stati applicati, il codice di base esistente di Netscape presentava circostanze uniche. Una delle questioni più spinose erano gli accordi privati di licenza che regolavano gran parte delle componenti di terze parti usate nel codice. La licenza doveva delineare un ambiente in cui questi sviluppatori commerciali e altri nuovi potessero fornire il loro codice a Mozilla proteggendo nello stesso tempo i loro interessi commerciali. La licenza BSD, più permissiva e che richiede solo che si faccia cenno al detentore del copyright in tutte le modifiche del codice, fu giudicata insufficiente allo sviluppo di Mozilla. Avrebbe lasciato gli sviluppatori col rischio che modifiche al loro lavoro non venissero restituite né a loro né al resto della comunità. Questo punto rappresentava di per sé un bel problema, dal momento che era cruciale per la fattibilità a lungo termine degli sforzi di sviluppo Open Source. D'altra parte, i requisiti della GPL la resero indesiderabile in questo progetto. La GPL i "virale"; applicata a un pezzo di codice originale, ogni altro codice assieme a cui l'originale sia compilato deve anch'esso ricadere sotto GPL. Quest'aspetto la rese improponibile per gli sviluppatori di software commerciale. Per esempio, la GPL avrebbe richiesto che le componenti di terze parti compilate in versioni commerciali di Communicator fossero rilasciate anch'esse sotto GPL, il che ricade fuori dal controllo di Netscape, dal momento che Netscape non controlla quelle terze parti. E Netscape stessa usa una porzione del codice di Communicator in altri prodotti (come i server). Dal momento che Netscape non ha piani immediati per rilasciarne il codice sorgente, l'effetto virale della GPL su questi prodotti presenterebbe lo stesso problema a Netscape come ad altre aziende. La LGPL, modifica della GPL più aperta e meno restrittiva, era più vicina alle necessita di Netscape per l'uso con sviluppi commerciali, ma conteneva ancora troppi dei tranelli della GPL. Dopo un mese frenetico di ricerche, discussioni, riunioni con esperti e rappresentanti della comunità del free software, e mentre il pubblico attendeva perplesso, il team concluse che questa situazione unica richiedeva una nuova licenza. La Netscape Public License (NPL) aprì nuovi terreni nel tentare di raggiungere un compromesso Fra la promozione dello sviluppo a sorgente libero da parte di imprese commerciali e la protezione degli sviluppatori di free software. II processo di creazione di una licenza Open Source di nuova generazione richiese oltre un mese. Con un'altra mossa del tutto inusitata, non appena la prima versione della Netscape Public License (NPL) fu completata, venne sottoposta a un betatesting pubblico. Il giorno 5 marzo, una versione fu pubblicata nel newsgroup netscape.public. mozilla.license e fu avanzata una richiesta di commento pubblico, fra lo scherno generale. Fu in particolare una sezione della licenza ad attirarsi le ire più accese: quella che concedeva a Netscape dei diritti speciali sull'uso di codice coperto dalla NPL stessa in altri prodotti Netscape, senza che quei prodotti ricadessero sotto NPL. Consentiva anche a Netscape di pubblicare versioni rivedute della NPL e, questo il dettaglio più controverso, di rilicenziare a terze parti codice coperto da NPL sotto termini diversi dalla NPL. Venne osservato perfino che sarebbe bastato questo solo fatto a rendere inaccettabile la NPL alla comunità Open Source. L'11 marzo apparve su netscape.public.mozilla.license uno stato dei lavori firmato jwz (Jamie Zawinsky). Diceva fra l'altro: "Prima di tutto, GRAZIE per l'incredibile e significativo riscontro che ci avete dato! è stato d'immenso aiuto, e siate certi che ogni opinione è stata presa nella più grande considerazione." La prossima settimana potrete notare come la sezione 5 sia stata radicalmente rielaborata. Non dovrei probabilmente dilungarmi in commenti (non voglio alimentare aspettative mal riposte), ma il messaggio di odio di molti di voi verso quella sezione, così com'è adesso, ci è arrivato forte e chiaro. Il 21 marzo la revisione fu pubblicata, una cosa senza precedenti. La reazione fu incredula: "Ho detto loro che faceva schifo, e mi hanno dato retta! Non riesco a crederci!". La gente si accorse allora che si trattava di un progetto Open Source, genuino, malgrado il suo luogo di nascita poco ortodosso. Le discussioni in corso sui newsgroup aiutavano a dirigere il processo più ancora che fornire commenti sui suoi risultati. I toni della discussione, che continuava, mutarono; il morale era alle stelle. La critica della comunità alla beta della NPL aveva costretto il team che se ne occupava a ritornare alla lavagna in cerca di una soluzione che permettesse a Netscape di bilanciare due obiettivi: impegnare gli sviluppatori di sorgente libero e continuare a perseguire mete di profitto. Ne risultò una seconda licenza che agisse all'interno della NPL, la MozPL (Mozilla Public License). Le due licenze erano identiche, salvo il fatto che la NPL includeva degli emendamenti che garantivano diritti supplementari a Netscape. Tutto il codice pubblicato inizialmente il 31 marzo l998 fu rilasciato sotto NPL, e tutte le modifiche a quel codice devono essere rilasciate sotto NPL. Il nuovo codice sviluppato può essere rilasciato sono MozPL o sotto ogni altra licenza compatibile. Cambiamenti a file contenuti nel codice sorgente sono considerati modifiche e sono coperti da NPL. E, con riguardo alle preoccupazioni espresse da molti su Internet, nuovi file che non contengano alcunché del codice originale o di quello susseguentemente modificato non sono coperti da NPL. Questo codice risultante può essere coperto da qualunque licenza compatibile. La GPL non è compatibile con la Netscape Public License o con la Mozilla Public License. La GPL è per natura incompatibile con ogni altra licenza, dal momento che proibisce l'aggiunta di qualunque restrizione o di ulteriori sconfinamenti. Tutto il codice sviluppato per funzionare in associazione con software GPL deve venire a sua volta coperto da GPL. Un altro punto minore è che la GPL insiste che il codice, quando venga distribuito secondo i suoi termini, sia completo e intero. La NPL non include questa condizione. Le discussioni sui newsgroup avevano posto in grande rilievo un fatto importante: gli sviluppatori avevano bisogno che Netscape acconsentisse a una distinzione fra le correzioni dei bug e il codice nuovo. Chiaramente, una cosa è dire "sto correggendo un bug, una piccola modifica al vostro programma", e tutt'altra "aggiungo al vostro programma una caratteristica nuova". Due sensazioni molto diverse! Per molti andava benissimo dar via una "bug fix", il valore del contributo essendo premio a se stesso. Ma il codice nuovo e tutta un'altra faccenda. Uno sviluppatore che abbia fatto una gran mole di lavoro originale non vorrà vedere un altro che la usa per il proprio guadagno. La NPL e la MozPL erano state progettate per incoraggiare lo sviluppo aperto sulla base del codice di Mozilla, ma fin dall'inizio avevamo in mente anche un altro obbiettivo. Netscape aspirava ad essere la prima grande azienda ad aprire il suo codice proprietario, perché intendeva patrocinare un più ampio interesse delle società nello sviluppo in ambiente Open Source. La cosa più importante era creare un'atmosfera che rendesse possibile a grandi organizzazioni a scopo di lucro di adottare questo modello e partecipare al movimento. L'infrastruttura legale in gran parte delle licenze Open Source è un grave ostacolo alla cooperazione interaziendale. Con Mozilla la licenza era progetto di se stessa. Concedendo il codice per versioni future, speravamo di coinvolgere l'intera comunità della Rete nella creazione di un'innovazione nel mercato dei browser: l'idea che ci sarebbe stato in giro per il mondo un gran numero di dotati programmatori a smanettare sul nostro codice, infondendovi la propria energia creativa, motivava tutti a tener duro.
Mozilla.org
I progetti Open Source fortunati seguono sempre uno schema, non necessariamente stabilito dal progetto. Di solito, una persona o un gruppo cura il coordinamento. I partecipanti lavorano sull'aspetto del codice che più li interessa, seguendo il loro istinto. Alla fine della giornata, si ritrovano con qualcosa che funziona un po' meglio per loro. Ma che cosa succede un mese dopo, quando esce una nuova versione del software? L'impulso è svanito e si ritrovano al punto di partenza: o più indietro ancora, perché il software può essere cambiato. Ne risulta che gli sviluppatori vogliono che le loro patch siano incluse nella distribuzione (nel prodotto) principale. Ma se c'è in giro solo un mucchio di codice sorgente e un po' di gente che ci lavora sopra, alla fine qualcuno si alzerà e dirà: "Tanto vale che raccolga un po' di patch e le rilasci". Quando arriva un altro chiedendosi come includere la sua patch nella prossima release, dirà: "Non so a chi darla, allora la do a quello lì. Sembra che faccia un buon lavoro". Col tempo, quella prima persona diventa il curatore. In questo progetto Open Source i buoni stavano davanti al carro. Mozilla.org era stato concepito e progettato per assumere il ruolo del curatore fin dal principio. Dal momento che il ruolo sarebbe stato coperto in un modo o nell'altro, decidemmo di creare l'infrastruttura per divenire la stanza di compensazione. Nei mesi seguenti, mozilla.org cominciò a costruire un'organizzazione, ottenendo fondi e macchine, istituendo mailing list e sviluppando tutto quando era necessario perché funzionasse. La missione non era altro che mettere in moto l'organizzazione. Era cruciale che ci fosse un deposito centrale operativo non appena il codice fosse rilasciato. E se non fossimo stati pronti, nel giro di sei mesi avremmo visto qualcun altro farlo. Netscape non è nota per restarsene seduta a guardare gli altri che fanno le cose. Cedere il codice significava per Netscape collaborare con la Rete. E c'era un altro concetto cruciale che si doveva accettare: il Netscape Client Product Development Group e mozilla.org non erano la stessa organizzazione. L'obiettivo di mozilla.org è di fungere da coordinatore per tutti coloro che, nel mondo, lavorano sul software. L'intento del Product Development è di consegnare prodotti, prodotti Netscape basati sul codice di Mozilla. Dal momento che entrambi i gruppi lavorano sullo stesso prodotto, gli interessi possono sovrapporsi. Ma il gruppo dietro mozilla.org sapeva che sarebbe stato disastroso che la Rete, considerando l'organizzazione, pensasse: "Questa gente ha a cuore solo gli interessi di Netscape; pensano solo a preparare prodotti Netscape". Questo avrebbe significato per mozilla.org il fallimento dell'obiettivo di essere un buon curatore del progetto. La separazione doveva dunque essere reale e la Rete doveva saperlo.
Dietro il sipario
Dal momento che Mozilla è un codice di base altamente modulare, ogni modulo principale, come la Image Library o il parser XML, ha il suo "titolare" designato. Quella persona conosce meglio di ogni altro il codice ed è arbitro di che cosa possa entrarvi e che cosa no. Molti titolari dei moduli sono progettisti di Netscape, altri sono arrivati a bordo dal mare magnum della Rete. Quando un titolare di modulo effettua una modifica (per esempio, aggiungendo un'API all'Image Library), essa è inviata a mozilla.org per essere inclusa nelle distribuzioni. Se insorge una divergenza fra chi contribuisce e il titolare di modulo, mozilla.org 6.inge da arbitro e sua è l'ultima parola (senza dimenticare mai che, se non sarà equa, verrà ignorata e qualcun altro assumerà l'arbitrato). Mozilla.org ha dovuto combattere con il fatto che sul codice sarebbero stati al lavoro sia gli sviluppatori di Netscape sia sviluppatori indipendenti, via Rete. I metodi usati internamente per lavorare sul codice hanno dovuto adeguarsi al Web e rendersi accessibili su tutte le piattaforme, in tutti i fusi orari. Ciò è stato reso possibile con il "controllo ad albero" (tree control) effettuato dagli strumenti Bonsai e Tinderbox. ."Bonsai" è uno strumento tramite il quale è possibile eseguire ricerche sui contenuti di un archivio. Come al banco di una biblioteca, vi si può "registrare" il codice su cui si è lavorato, o vedere quali altre "registrazioni" siano state effettuate da altri. In background il codice è costantemente eseguito, controllando l'albero del codice. Se l'albero s'interrompe, viene emessa una bandiera rossa, fermando ulteriori registrazioni finché il problema non sia stato identificato. I log possono essere controllati e i problemi fatti risalire a un momento particolare. Già usato da Netscape internamente, è stato trasportato su mozilla.org per essere usato dagli sviluppatori in tutto il mondo e direttamente, via browser, su qualunque piattaforma. Se avete più di dieci sviluppatori insieme al lavoro senza strumenti, ci sarà un'esplosione. Questa è la teoria dietro "Tinderbox", un programma che tiene sotto controllo questa situazione potenzialmente esplosiva. Tinderbox è uno strumento "detective". Permette di vedere che cosa stia succedendo nell'albero del sorgente. Mostra chi ha registrato che cosa (chiedendolo a Bonsai), quali piattaforme abbiano lavorato con successo e quali invece abbiano ceduto, il modo esatto in cui hanno ceduto e lo stato dei file che costituiscono il codice fornito, in modo da poter rintracciare il possibile autore del danno.
Primo aprile 1998
Fu Jamie che, in una riunione, espose il suo piano: affittare un nightclub a San Francisco, invitare il mondo intero e diffondere il tutto sulla Rete. "Intendi dire invitare al party anche dei non dipendenti? Ma non lo abbiamo mai fatto...". In carattere con il resto del progetto e dopo una breve pausa, la reazione fu: perché no.' Quella festa non verrà dimenticata presto. Jamie affittò uno dei nightclub più grandi di San Francisco, The Sound Factory, per la notte del primo aprile. I DJ (Fra i quali Brian Behlendorf, fondatore di Apache) distribuirono migliaia di magliette di mozilla.org, software e gadget di NetObjects, Macromedia, Digital, Be, Wired e unAmerican Activities. All'apertura delle porte del "Mozilla Doti Party", alle otto, c'era già la coda. t. Un'ora e mezza dopo, il locale aveva raggiunto la capienza massima concessa dalle norme di sicurezza, duemila persone, e la coda faceva il giro dell'isolato. La gente veniva ammessa in gruppi di venti man mano che altra gente lasciava il party, e prima che la notte fosse finita oltre 3500 avevano varcato le soglie: fra questi, guru del free software come Brewster Kahle (fondatore di WAIS) e Eric Raymond. Altre centinai;i di persone in tutto il mondo sincronizzarono gli orologi e brindarono a Mozilla. I partecipanti virtuali erano un gruppo di oltre cento dall'Olanda e gruppi sparsi in Norvegia, Montreal, Pensylvania, Carolina del Nord, Wisconsin, Colorado e Alabama. All'interno, tre schermi di proiezione facevano scorrere il codice alla velocità di sessanta righe al secondo (in quel modo, la festa avrebbe dovuto durare più di sette ore per mostrare tutto il milione e mezzo di righe del codice di Mozilla). Nel corso del secondo di due set suonati dalla Kofy Brown Band (ne era membro un progettista Netscape), Eric Raymond, giunto da Filadelfia per l'occasione, salto sul palco e sorprese tutti con un assolo di flauto. Verso la fine della serata, una dozzina di CD del codice sorgente di Mozilla "Signature Edition" (firmati e numerati la sera prima dal Netscape Build Team e da membri di Mozilla.org) furono gettati a qualche fortunato fra la folla. La lucertola era libera! La vendetta degli hacker di Eric S. Raymond
Scrissi la prima versione di "A Brief History of Hackerdom" nel 1996 come risorsa Web. La cultura hacker, considerata proprio come cultura, mi aveva affascinato a lungo, ancor prima che decidessi di scrivere la prima edizione del "The New Hacker's Dictionary" nel 1990. Verso la fine del 1993 molti (me compreso) mi consideravano uno storico ed etnografo specializzato nella cultura hacker e questo ruolo non mi dispiaceva affatto. Allora non potevo nemmeno lontanamente immaginare che il mio interesse "antropologico" a livello amatoriale potesse divenire causa di un importante cambiamento. Credo che nessuno fu più sorpreso di me per ciò che successe. Ma le conseguenze di tali sorprese continuano a plasmare la cultura hacker, il mondo tecnologico e gli affari del giorno d'oggi. In questo contributo passo in rassegna, osservandoli dal mio punto di vista, gli eventi che, nel gennaio 1998, portarono al "colpo udito in tutto il mondo" generato dalla rivoluzione open source. Presenterò alcune riflessioni sulla lunga strada che è stata percorsa da allora, quindi cercherò di formulare alcune proiezioni sul futuro.
Oltre la Legge di Brooks Incontrare Linux fu per me uno shock. Nonostante fossi da anni attivo nella cultura hacker, recavo con me il pregiudizio, peraltro non provato, secondo cui gli hacker amatoriali, per quanto dotati potessero essere, non fossero in grado di chiamare a raccolta le risorse e le abilità necessarie per produrre un sistema operativo multitasking effettivamente utilizzabile. Proprio qui gli sviluppatori HURD avevano accumulato fallimento su fallimento per almeno un decennio. Ma, dove loro non erano riusciti, avevano trionfato Linus Torvalds e i suoi compagni, che non solo erano giunti a soddisfare i requisiti minimi di stabilità e funzionamento delle interfacce Unix, ma avevano persino superato di gran lunga l'obiettivo, con esuberanza e acume, fornendo centinaia di megabyte di programmi, documenti e altre risorse, persino intere suite di strumenti Internet, programmi di desktop publishing, supporto grafico, editor, giochi e così via. Vedere tutto questo stupendo codice muoversi di fronte a me come un vero e proprio sistema funzionante fu per me un'esperienza entusiasmante, molto più che sapere, a livello puramente teorico, che tutti i bit a ciò necessari erano in circolazione. Fu come se, per anni, avessi cercato e selezionato ammassi di componenti automobilistici sconnessi per poi, improvvisamente, trovarmi di fronte agli stessi particolari assemblati in una Ferrari rosso fuoco, con la portiera aperta, la chiave penzolante dal cruscotto e il motore rombante quasi a cantare un inno alla potenza. . . . La tradizione hacker che osservavo da circa due decenni aveva improvvisamente preso vita in nuove sembianze vibranti e vitali. In un certo senso ero già stato reso partecipe di questa comunità perché molti dei miei progetti free software erano entrati a far parte del mix. Ma io volevo andare più a fondo: ogni delizia che vedevo non faceva che aumentare il mio stupore. Tutta la tradizione della progettazione software è dominata dalla Legge di Brooks, secondo cui, aumentando il numero N di programmatori, il lavoro eseguito aumenta in modo direttamente proporzionale a N, ma la complessità e la vulnerabilità ai bug aumenta di N al quadrato, dove N al quadrato è il numero di percorsi di comunicazione (e potenziali interfacce del codice) tra le basi di codice degli sviluppatori. Secondo la Legge di Brooks, un progetto a cui abbiano contribuito migliaia di sviluppatori non può che essere un'accozzaglia di codice instabile e traballante. In qualche modo la comunità di Linux aveva sconfitto questo effetto "N al quadrato" ed era riuscita a produrre un sistema operativo di sorprendente qualità. E io ero determinato a scoprire come ciò fosse stato possibile. Ci misi tre anni a sviluppare una teoria, partecipando e osservando da vicino, e un altro anno per testarla in modo sperimentale. Dopodiché mi decisi a scrivere "The Cathedral and the Bazaar" (CatB) per spiegare ciò di cui ero stato testimone.
Mimesi e mitografia Guardando in retrospettiva, fu proprio la mancanza di teoria e di linguaggio l'ostacolo principale che sollevò contro di noi una duplice opposizione. In primo luogo, non eravamo in grado di pensare sistematicamente a come migliorare le consuetudini seguite. Secondo, non potevamo spiegare né vendere il metodo ad altri. A quell'epoca i nostri pensieri vertevano solo sulla prima conseguenza. Il motivo per cui decisi di scrivere quel documento fu l'intenzione di dare alla cultura hacker un linguaggio proprio, che potesse essere utilizzato internamente per spiegare la cultura a se stessa. Mi decisi quindi a scrivere ciò che avevo visto, impostando il tutto in uno stile narrativo, con vivaci metafore che descrivessero la logica affiorante da tali consuetudini ed esercizi. CatB, in realtà, non fu una scoperta. Nessuno dei metodi descritti nell'opera fu da me inventato. La novità non furono i fatti descritti, ma le metafore utilizzate e lo stile narrativo adottato: una storia semplice e interessante che spingeva il lettore a vedere i fatti in modo completamente nuovo. Stavo cercando di attuare una specie di ingegneria mimetica sui miti generativi della cultura hacker. Divulgai l'intero testo per la prima volta al Linux Kongress, nel mese di maggio 1997 in Baviera. La profonda attenzione e gli incessanti applausi con cui il contributo fu accolto da un'audience che comprendeva pochissime persone di madrelingua inglese dimostrava che ero sulla strada giusta ma, a conti fatti, la pura casualità che mi vide seduto accanto a Tim O'Reilly alla cena del giovedì sera mise in moto una serie di conseguenze ancora più importanti. Da tempo ammiratore dello stile istituzionale di O'Reilly, avevo sempre desiderato incontrarlo. Intavolammo una conversazione a vasto raggio (gran parte della quale riguardava il nostro comune interesse per la fantascienza classica), che sfociò in un invito a presentare CatB alla Perl Conference di Tim più avanti nello stesso anno. Anche qui la relazione fu ben accolta, con applausi e persino una "standing ovation". Tramite la posta elettronica sapevo che, dopo il congresso in Baviera, i messaggi su CatB si erano diffusi a macchia d'olio in Internet. Molti dei presenti avevano già letto l'opera e, più che una novità, il mio discorso fu per loro l'occasione di celebrare il nuovo linguaggio e la nuova consapevolezza che esso diffondeva. La "standing ovation", giustamente, non fu tanto per la mia opera, quanto per la cultura hacker in generale. Pur non rendendomene conto, il mio esperimento in ingegneria mimetica stava per accendere una miccia importante. Alcuni ascoltatori, ai cui orecchi il mio discorso giungeva come una novità, erano della Netscape Communications, Inc. E la Netscape stava navigando in acque difficili. La Netscape, società all'avanguardia nella tecnologia Internet e titolo in rapida ascesa alla borsa di Wall Street, era diventata il bersaglio delle armi offensive messe in campo da Microsoft. Microsoft, giustamente, temeva che gli standard aperti presenti nel browser di Netscape potessero erodere il lucrativo monopolio del gigante di Redmond nel mondo dei PC. Tutto il peso dei miliardi di Microsoft e una tattica ambigua che avrebbe poi dato vita a una causa antitrust furono impiegati contro il browser di Netscape. Per Netscape non si trattava tanto dei proventi legati al futuro del browser (che sono solo una piccola percentuale dell'utile della società), quanto di mantenere un piccolo spazio per la molto più preziosa attività relativa ai server. Se Internet Explorer di Microsoft avesse raggiunto il predominio sul mercato, Microsoft avrebbe potuto deviare i protocolli del Web da standard aperti in canali proprietari, gestibili solo dai server di Microsoft. Alla Netscape fervevano le discussioni sulla migliore controffensiva da adottare per sconfiggere questa minaccia. Una delle prime idee fu quella di aprire il sorgente del browser di Netscape, ma era difficile dimostrare che, così facendo, si sarebbe evitato il predominio di Internet Explorer. Allora non me ne resi conto, ma CatB assunse un ruolo importante in questa azione. Nell'inverno del 1997, mentre stavo lavoravo sul materiale per il mio prossimo articolo, fu preparata la scena che doveva consentire a Netscape di spezzare le regole del gioco commerciale e offrire alla mia comunità un'opportunità senza precedenti.
La strada per Mountain View Questo fu l'evento che, nella stampa commerciale specializzata in informatica, fu dai commentatori definito "il colpo udito in tutto il mondo". E Barksdale aveva fatto di me il suo Thomas Paine, che io lo volessi o no. Per la prima volta nella storia della cultura hacker una società inclusa fra le 500 di Fortune, quotata a Wall Street, aveva puntato il proprio futuro sulla convinzione che la nostra strada fosse quella giusta e, più specificamente, sull'analisi che io avevo formulato e secondo cui la "nostra via" era giusta. È uno shock abbastanza forte da affrontare. Il fatto che CatB avesse modificato l'immagine della cultura hacker non sorprendeva; in fondo era l'obiettivo che avevo da tempo perseguito. Ma le notizie del successo riscosso all'esterno mi stupivano (a dir poco). Nelle prime ore che trascorsero dopo questa notizia riflettei quindi molto attentamente sullo stato di Linux, della comunità hacker, su Netscape, e mi chiesi se, personalmente, fossi armato di tutto ciò che occorreva per compiere il passo successivo. Non ci volle molto per dedurre che, a questo punto, la comunità hacker non poteva far altro che assistere la Netscape nella sua battaglia. Da ciò derivava infatti la sua, e mia, sopravvivenza. Se Netscape avesse perso, noi hacker avremmo probabilmente conosciuto tutto l'obbrobrio di tale fallimento. Saremmo stati screditati per un altro decennio: era semplicemente troppo. A questo punto io facevo parte della cultura hacker, di cui avevo attraversato le varie vicissitudini, da circa venti anni. Venti anni in cui avevo ripetutamente osservato idee brillanti, avvii promettenti e tecnologie stupende sconfitte da scaltre manovre di marketing. In venti anni avevo visto troppo spesso hacker sognare, sudare e costruire per osservare poi la vecchia cattiva IBM o la nuova cattiva Microsoft aggiudicarsi il premio reale. Venti anni di vita trascorsa in un ghetto, anche se un ghetto comodo popolato da amici interessanti, ma pur sempre racchiuso tra lunghe e intangibili mura innalzate dal pregiudizio. L'annuncio di Netscape aveva infranto la barriera, anche se solo per poco; il mondo degli affari era stato scosso bruscamente dalla sua condiscendenza sulle capacità degli hacker. Me gli abiti mentali pigri hanno una forza d'inerzia lunga a esaurirsi. Se la Netscape avesse fallito, o forse anche se avesse riscosso successo, l'esperimento avrebbe potuto essere considerato come un "numero unico", che non vale la pena ritentare. Dopodiché saremmo tornati nello stesso ghetto, con pareti più alte che mai. Per evitare questa prospettiva, Netscape doveva riuscire. Dopo un'attenta riflessione, chiamai la Netscape e mi offrii di aiutarli a formulare la licenza e a studiare i particolari della strategia. A inizio febbraio, su loro richiesta, volai a Mountain View per un incontro con vari gruppi al loro quartier generale e li aiutai a tessere il canovaccio di ciò che doveva diventare la Mozilla Public License e l'organizzazione Mozilla. Lì incontrai molti personaggi chiave di Silicon Valley e della comunità nazionale Linux (questa parte della storia viene narrata in modo più approfondito nella sezione storica del sito Web Opensource). L'aiuto a Netscape era chiaramente una priorità a medio termine, ma tutti si rendevano benissimo conto che occorreva formulare una strategia a lungo termine che facesse seguito alla cessione di Netscape. Era giunto il momento di escogitare la strategia.
Le origini di "Open Source" Ma la vera scoperta a livello concettuale fu ammettere con noi stessi che ciò di cui avevamo effettivamente bisogno era una campagna pubblicitaria e che, per farla funzionare, servivano vere e proprie tecniche di marketing (lancio, costruzione di un'immagine, cambiamento del marchio). Da qui nacque il termine "open source", inventato dai primi partecipanti per ciò che doveva poi diventare la campagna Open Source (e, infine, l'organizzazione Open Source Initiative) in occasione di un incontro tenuto a Mountain View, negli uffici della VA Research, il 3 febbraio. Allora, guardando in retrospettiva, ci appariva chiaro che il termine "free software" aveva danneggiato notevolmente il nostro movimento nel corso degli anni, in parte per l'ambiguità legata al termine "free" considerato sì nel suo significato di libero e gratuito, ma anche di scarsa qualità, in parte e soprattutto per la forte associazione esistente tra il termine "free software" e una presunta ostilità verso i diritti di proprietà intellettuale, tra il termine e il comunismo e altri concetti che difficilmente vengono presi in simpatia da un responsabile CED. Era allora ed è tuttora inutile spiegare che la Free Software Foundation non è ostile alla proprietà intellettuale e che la sua posizione non è esattamente ciò che risponde ai principi del comunismo. Noi lo sapevamo. Ma, sotto la pressione della release di Netscape, capimmo che non contava tanto la posizione effettiva della FSF, quanto piuttosto il mancato successo riscosso dalle sue intenzioni originarie e l'effettiva associazione tra il termine "free software" e questi stereotipi negativi nella stampa commerciale e nel mondo aziendale. Il nostro successo dipendeva quindi dalla capacità di ribaltare questi stereotipi negativi e di associare la FSF a concetti positivi, che suonassero dolci agli orecchi di dirigenti e investitori, che fossero legati a idee di maggiore affidabilità, bassi costi e caratteristiche migliori. Espresso nel gergo del marketing, si trattava di rinnovare marchio al prodotto, di costruire per il prodotto una reputazione tale da attirare gli interessi delle aziende. Linus Torvalds abbracciò questo progetto il giorno successivo al primo incontro ed entro un paio di giorni ci mettemmo all'opera. Bruce Perens fece registrare il dominio opensource.org e la prima versione della pagina Web Opensource entro una settimana. Propose inoltre di modificare le "Debian Free Software Guidelines" in "Open Source Definition" (Definizione di Open Source o OSD), e avviò l'iter necessario per registrare "Open Source" come marchio di certificazione in modo da poter imporre l'uso di "Open Source" ai prodotti conformi alla OSD. Anche le tattiche specifiche necessarie per spingere la strategia apparivano ormai chiare sin dall'inizio e furono infatti discusse nel primo incontro. Ecco le tematiche principali:
Dimenticare la strategia "bottom-up"; puntare sulla
strategia "top-down" Ci appariva ormai chiaro che la strategia storica seguita per Unix, vale a dire la diffusione dei concetti dal basso verso l'alto, partendo cioè dai tecnici per giungere poi a convincere i boss con argomentazioni razionali, si era rivelata un fallimento. Era una procedura ingenua, di gran lunga surclassata da Microsoft. Inoltre, l'innovazione di Netscape non avvenne in quella direzione, ma fu resa possibile proprio perché un importante personaggio di livello strategico, quale Jim Barksdale, aveva avuto l'intuizione e l'aveva imposta ai suoi subordinati.
Linux è il nostro caso più rappresentativo Linux deve essere la nostra spinta propulsiva. Sì, nel mondo open source esiste anche altro a cui la campagna renderà onore, ma Linux è il sistema che ha mosso i primi passi con il miglior riconoscimento, con la più vasta base software e la più ampia comunità di sviluppatori. Se Linux non riesce a consolidare l'innovazione, non ci riuscirà nessun altro.
Catturare le società "Fortune 500" Esistono altri segmenti del mercato disposti a spendere (le piccole e medie aziende, ad esempio), ma sono più diffusi e difficili da raggiungere. Le società Fortune 500 non solo hanno ingenti capitali, ma sono anche più concentrate e più semplici da raggiungere. L'industria del software deve quindi fare ciò che le società Fortune 500 dicono, per cui, per prima cosa, bisogna convincere le società Fortune 500.
Cooptare i mass media di prestigio che si rivolgono alle
società Fortune 500 La scelta di puntare sulle società Fortune 500 implica che dobbiamo catturare l'attenzione dei mass media che formano le opinioni dei top manager e degli investitori, specificamente New York Times, Wall Street Journal, Economist, Forbes e Barron's Magazine.
Istruire gli hacker in tattiche di guerriglia marketing Fu subito chiaro che altrettanto importante era educare la comunità degli hacker. Non bastava avere uno o due ambasciatori che parlassero un linguaggio scelto se poi, alla base, tutti gli altri hacker non seguivano gli stessi principi.
Utilizzare il marchio di certificazione Open Source come
garanzia di genuinità Una delle minacce cui ci trovammo a far fronte fu la possibilità che il termine "open source" venisse "abbracciato ed esteso" da Microsoft o da altri grandi produttori che lo avrebbero corrotto e ne avrebbero stravolto il messaggio. Per questo motivo Bruce Perens ed io decidemmo ben presto di registrarlo come marchio di certificazione e di legarlo alla Open Source Definition (copia delle Debian Free Software Guidelines). In tal modo avremmo potuto intimorire eventuali prevaricatori con la minaccia dell'azione legale.
Un rivoluzionario per caso Sin dall'inizio imparai che la stampa soffoca quasi completamente le astrazioni. Nessuno riporterebbe concetti astratti che non fossero sostenuti da personaggi straordinari. Tutto deve avere una storia, una certa drammaticità, conflittualità, mordente. Altrimenti la maggior parte dei reporter se ne andrebbe a dormire (e, se non lo facessero loro, lo farebbero i loro direttori). Sapevo quindi che, per coinvolgere la stampa nel caso Netscape, occorreva un personaggio con caratteristiche molto particolari. Avevamo bisogno di un agitatore, di un rappresentante, di un acceso sostenitore, di qualcuno che fosse in grado di cantare e gridare dai pulpiti attirando l'attenzione dei reporter, di operare con i dirigenti e colpire la macchina dei media fino a quando, dai suoi ingranaggi, sarebbe uscito il messaggio "Ecco la rivoluzione!" A differenza della maggior parte degli hacker, io sono di carattere abbastanza estroverso e avevo già maturato una profonda esperienza con i mass media. Per quanto mi guardassi attorno, non riuscivo a intravedere nessuno più qualificato di me ad assumersi la parte dell'evangelista. Ma io non volevo questo incarico perché sapevo che mi sarebbe costato la vita per mesi e, forse, anche per anni. La mia privacy sarebbe andata distrutta. Forse sarei divenuto oggetto di caricature da parte della stampa e, peggio ancora, sarei stato additato come traditore o vanaglorioso da gran parte della mia stessa comunità. E peggio ancora di tutte le altre conseguenze messe insieme, non avrei avuto più tempo per essere uno hacker! Mi chiesi: "Sei veramente stufo di stare a guardare la tua comunità rinunciare a fare ciò che serve per vincere?" Decisi che la risposta doveva essere "Sì" e, dopo aver deciso, mi gettai a capofitto nel lavoro, sporco ma necessario, di divenire un personaggio pubblico e una personalità da mass media. Già durante la stesura del "The New Hacker's Dictionary" avevo avuto un po' a che fare con i media ma, questa volta, mi impegnai più a fondo e creai una serie di tattiche mirate a gestire il rapporto con i mass media, dopodiché passai all'atto pratico. Descrivere la teoria in dettaglio sarebbe qui fuori luogo, ma tutto verte sull'uso di ciò che io definisco "dissonanza attrattiva", necessaria per alimentare una curiosità stuzzicante sul personaggio e passare poi a sfruttare l'interesse suscitato per tutto ciò che vale la pena di promuovere sull'idea che si sta cercando di diffondere. Come avevo previsto, sia il marchio "open source" sia l'intenzionale promozione di me stesso quale acceso fautore della teoria portarono con sé conseguenze sia positive che negative. Nei dieci mesi che seguirono all'annuncio di Netscape, l'interesse dei mass media verso Linux e il mondo open source in genere registrò una crescita esponenziale. In questo periodo fui citato direttamente da un terzo degli articoli e indirettamente dagli altri due terzi. Nello stesso periodo una minoranza (ma molto rumorosa) di hacker mi definì un meschino egoista. Riuscii a mantenere un certo buon umore verso entrambi questi esiti, anche se a volte con notevole difficoltà. Sin dall'inizio prevedevo di cedere il ruolo di evangelista a un successore, che avrebbe potuto essere una persona o un'organizzazione. Ci sarà pure un momento in cui il carisma cala e perde efficacia a favore di una più ampia rispettabilità. E questo era ciò che aspettavo. Nel momento in cui scrivo questo contributo, sto cercando di trasferire i miei rapporti personali e la reputazione di cui godo presso la stampa, creata con tanta attenzione, alla Open Source Initiative, un ente non a scopo di lucro creato appositamente per gestire il marchio di fabbrica Open Source. Attualmente ne sono il presidente, ma spero di non restarlo a tempo indeterminato.
Le fasi della campagna Dal 3 febbraio al rilascio effettivo di Netscape, avvenuto il 31 marzo, il nostro obiettivo primario fu quello di convincere. Convincere della validità dell'etichetta "open source". Gli argomenti che presentavamo erano la nostra arma migliore, l'unica con cui potessimo convincere il mondo. Alla fin fine il cambiamento fu assai più semplice del previsto. Scoprimmo che esisteva una richiesta repressa di un messaggio meno dottrinale di quello della Free Software Foundation. Quando i poco più di venti leader presenti al Free Software Summit il 7 marzo decisero di adottare il termine "open source", non fecero che ratificare ufficialmente una tendenza ormai largamente diffusa nel mondo degli sviluppatori. Sei settimane dopo il meeting di Mountain View, gran parte della comunità parlava la nostra lingua. In aprile, dopo il summit e dopo l'effettivo rilascio di Netscape, passammo a reclutare il maggior numero possibile di adepti della prim'ora dell'Open Source, con l'obiettivo di fare apparire la mossa di Netscape meno stravagante e, in fondo, di garantirci una certa sicurezza in caso Netscape desse cattiva prova e mancasse l'obiettivo. Questa fu la fase più difficile. In superficie tutto sembrava rose e fiori; tecnicamente Linux si stava consolidando, il fenomeno open source godeva di una vasta copertura nella stampa finanziaria e iniziavamo ad apparire sotto una luce positiva anche presso la stampa tradizionale. Ciò nonostante, una certa apprensione mi suggeriva che il successo era ancora alquanto fragile. Dopo un'iniziale ventata di contributi, la partecipazione della comunità al progetto Mozilla aveva iniziato a rallentare. Nessuno dei grandi produttori indipendenti di software si era impegnato a supportare Linux. Netscape navigava ancora in solitario e il suo browser continuava a perdere quote di mercato a vantaggio di Internet Explorer. Sarebbe bastato poco per scatenare un amaro crollo nella stampa e nell'opinione pubblica. La nostra prima vera conquista post-Netscape fu messa a segno il 7 maggio, quando la Corel Computer annunciò il lancio di Netwinder, un network computer basato su Linux. Ma non era sufficiente: per sostenere lo slancio, non bastava l'impegno di affamati giocatori di riserva; avevamo bisogno dei leader del settore. E fu proprio a metà luglio, quando Oracle e Informix annunciarono il proprio impegno, che questa fase vulnerabile giunse al termine. Queste società si unirono alla compagnia di Linux tre mesi prima di quanto avessi previsto, e comunque mai troppo presto. Ci chiedevamo quanto questa spinta positiva avrebbe potuto durare senza il sostegno di produttori indipendenti di software, e la risposta ci rendeva sempre più tesi. Dopo che Oracle e Informix annunciarono l'intenzione di supportare Linux, altri sviluppatori indipendenti seguirono la stessa strada, quasi per routine, e a questo punto anche il fallimento di Mozilla sarebbe stato tollerabile. Il periodo che va da metà luglio a inizio novembre fu una fase di consolidamento in cui iniziammo a essere presi in considerazione anche dai media d'élite a cui avevo inizialmente mirato: vari articoli uscirono su The Economist e una cover story su Forbes. Diversi produttori hardware e software condussero sondaggi nella comunità open source e iniziarono a formulare strategie mirate ad avvantaggiarsi di questo nuovo modello. E, internamente, la più grande azienda "close source" iniziò a preoccuparsi seriamente. L'entità della sua preoccupazione emerse chiaramente quando gli ormai famosi "Halloween Documents" trapelarono da Microsoft. Gli "Halloween Documents" erano dinamite. Una testimonianza sonora della validità dello sviluppo "open source", una testimonianza resa dalla società che più aveva da perdere in caso di successo di Linux. E questa testimonianza confermava gli insidiosi sospetti che molti nutrivano sulle tattiche che Microsoft sarebbe stata disposta a mettere in campo pur di fermare questo nuovo sviluppo. Sugli "Halloween Documents" si accese l'interesse della stampa, soprattutto nelle prime settimane di novembre. Le numerose cronache destarono viva curiosità per il fenomeno "open source" e, con sorpresa ma anche con piacere, confermarono le tesi che per mesi avevamo sostenuto. E questi documenti furono l'origine di un invito a tenere una conferenza sullo stato dell'industria del software e sulle prospettive dell'"open source" a un gruppo scelto dei principali investitori di Merrill Lynch. Ecco che Wall Street si stava finalmente muovendo verso di noi.
I fatti in causa Nei dieci mesi che seguirono la cessione di Netscape, Linux continuò rapidamente a crescere e a consolidarsi. Lo sviluppo di un solido supporto SMP e il completamento effettivo della funzionalità a 64 bit contribuirono a porre stabili fondamenta per il futuro. L'impiego di Linux per la renderizzazione delle scene del film Titanic diffuse un salutare sgomento tra i costruttori di costosi motori grafici. Il progetto Beowulf del supercomputer a basso costo dimostrò che Linux poteva avere successo anche nel mondo all'avanguardia dell'informatica scientifica. Non si verificò alcun evento spettacolare tale da portare alla ribalta i concorrenti open source di Linux. Gli Unix proprietari continuavano a perdere quote di mercato; verso metà anno solo NT e Linux, fra le 500 di Fortune, stavano guadagnando quote e, verso fine autunno, Linux era fra i due quello che si muoveva sulla corsia preferenziale. Apache continuava a consolidare la propria posizione di leadership sul mercato dei server Web. Nel mese di novembre il browser di Netscape iniziò a invertire tendenza e a prendere quota a discapito di Internet Explorer.
Il futuro
In primo luogo, alcune sicure previsioni per l'anno prossimo:
Analizzando queste tendenze, emergono alcune previsioni un po' più rischiose per il medio termine (da diciotto a trentadue mesi):
Dopo questi due anni, la sfera di cristallo inizia a offuscarsi un po'. Il futuro che incontreremo dipende da quesiti quali: il Ministero della Giustizia spezzerà le gambe a Microsoft? Forse BeOS o OS/2 o Mac OS/X o qualche altro sistema operativo a sorgenti chiusi o forse ancora qualche altro progetto completamente nuovo riuscirà ad aprirsi e competere ad armi pari con il trentennale progetto Linux I problemi relativi all'anno 2000 getteranno l'economia mondiale in una tale depressione da stra volgere qualsiasi programma? Sono tutti fattori imponderabili. Ma una domanda vale la pena di considerare attentamente. La comunità Linux sarà in grado di fornire un'interfaccia utente veramente user-friendly per l'intero sistema? Personalmente penso che lo scenario più probabile da qui a due anni vedrà il dominio effettivo di Linux su server, centri di elaborazione dati, provider e Internet, men- tre Microsoft manterrà il proprio potere sull'universo desktop. Da li in poi, tutto dipende dallo sviluppo di GNOME, KDE o di qualche altra interfaccia grafica utente (o GUI) basata su Linux (e delle applicazioni create o modificate per farne uso) e dalla loro capzcità di combattere contro Microsoft sul suo terreno. Se si trattasse solo di un problema tecnico, l'esito sarebbe praticamente scontato. Ma non è così. Si tratta piuttosto di un problema di design ergonomico e di psicologia dell'interfaccia; due discipline in cui gli hacker hanno sempre dimostraro lacune. Mentre gli hacker riescono benissimo a progettare interfacce destinate ad altri hacker, non sono altrettanto bravi quando si trtta di modellarle sui processi mentali del restante 95% della popolazione, e di modellarle con una tale abilita da convincere un utente finale medio a spendere soldi per acquistare proprio quell'interfaccia. Il problema di quest'anno sono state le applicazioni. Appare adesso chiaro che ci rivolgeremo a produttori indipendenti per quelle che non riusciremo a scrivere da noi. Ritengo che, per i prossimi due anni, il problema. sarà la nostra capacità di riuscire a soddisfare (e anche superare!) lo standard qualitativo imposto dal Macintosh per le interfacce, combinandolo con le peculiari virtù di Unix. Scherzosamente parliamo di "dominare il mondo", ma l'unico modo per dominare veramente il mondo e quello di servirlo e, quindi, di servire proprio l'utente più comune. Per raggiungere questo obiettivo, bisogna innanzitutto ripensare completamente a ciò che facciamo, riducendo spietatamente al minimo la complessità visibile dell'ambiente. I computer sono strumenti destinati a esseri umani. Alla fin fine, quindi, la progettazione di hardware e software deve essere finalizzata all'essere umano, a tutti gli esseri umani. La strada e lunga. E non e facile. Ma e nostro dovere, verso noi stessi e verso gli altri, percorrerla nel modo giusto. Che "Open Source" sia con voi! Copyright © 1995-1999 Apogeo srl, Milano http://www.apogeonline.com/openpress/libri/545/index.html |