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:

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 :

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
Isaac Newton

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,
MA NON A UN’IDEA IL CUI MOMENTO E' GIUNTO.
Victor Hugo

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
MOLTO PICCOLA IN TEORIA, MA IN PRATICA E' MOLTO GRANDE.
Anonimo

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.
Adam Smith

L’INFORMAZIONE, ANCHE SE COSTOSA DA CREARE, PUO' ESSERE RIPRODOTTA E CONDIVISA A UN COSTO MOLTO BASSO SE NON ADDIRITTURA NULLO.
Thomas Jefferson

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,
TANTO PIU' TALE CIFRA DIVENTA IMPORTANTE.
Lord Kelvin

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.
Thomas Edison

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'.
Anonimo

IL COMMON LAW E' UN CODICE DI LEGGI ACCESSIBILE A TUTTI ALLO STESSO MODO.
Michael Tiemann

È 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
Una volta stabilita la teoria si trattava di metterla in pratica. È alquanto semplice mettere in piedi un’attività di servizi se si sa qualcosa in fatto di business. Purtroppo nessuno dei tre fondatori della Cygnus aveva la benché minima esperienza in fatto di gestione aziendale.

COMMETTERE SEMPRE NUOVI ERRORI.
Esther Dyson

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.
John Gilmore

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
Decidemmo di raggiungere l’effetto dell’economia di scala prima di bruciarci completamente. E, da bravi ingegneri, decidemmo che il modo più rapido per realizzarla fosse concentrarci esclusivamente sul più piccolo gruppo di tecnologie open source che potevamo ragionevolmente vendere quale soluzione utile. Il nostro ragionamento era: più ci concentriamo sul piccolo e più sarà facile realizzare un qualche concetto di economia di scala.

PRIMO: STABILIRE UNA BASE FERMA.
Sun Tzu

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.
Yogi Berra

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:

Strumento	Legge	Scrive
Compiler	ASCII	ASCII
Assembler	ASCII	Binario
Archiver	Binario	Binario
Linker	Binario	Binario
Size	Binario	Binario
Strip	Binario	Binario
Binary	Binario	Binario
Nm	Binario	Binario
Debugger	Binario	-

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.

Data	Nome Versione	Nativa	Integrata	Totale Piattaforme
Mar 1992	p1	2	0	2
Giu1992	p2	5	0	5
Set 1992	p3	5	10	15
Dic 1992	p4	5	20	25
Mar 1993	q1	5	30	35
Giu 1993	q2	5	45	50
Set 1993	q3	7	53	60
Dic 1993	q4	8	67	75
Mar 1994	r1	10	75	85
Giu 1994	r2	10	80	90
Set 1994	r3	10	85	95
Dic 1994	r4	10	90	100

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.

Contratti ($K)	Redditività (%)	Tasso Crescita Annuale Cumulativo
1990: 725	Epsilon	n.a.
1991: 1500	1	106%
1992: 2800	2	96%
1993: 4800	3	87%
1994: 5700	4	67%

WATSON ! VIENI QUI!
Alexander Graham Bell

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
La tabella mostra chiaramente che il nostro tasso di crescita, pur restando impressionante, rallentò nel tempo. Mentre cercavamo di vendere i vantaggi e il valore del software Open Source, gli scettici e i potenziali clienti criticavano il nostro modello in termini di:

Buon senso
      Perché un cliente dovrebbe pagare per un vantaggio concorrenziale?

Economia di scala
      Come può un’attività di servizi godere degli effetti dell’economia di scala?

Durata
      La Cygnus sarà sempre a disposizione quando i clienti ne avranno bisogno?

Profitto
      Come può l’open source essere proficuo?

Gestibilità
      Come si deve gestire l’open source per assicurare sempre la qualità?

Possibilità di investimento
      Come può attrarre gli investitori un’azienda che non dispone
      nemmeno di software IP?

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
La realtà del mondo dei sistemi integrati è l’esistenza di un numero relativamente limitato di aziende produttrici di silicio e di un numero relativamente limitato di Outside Equipment Manufacturer (OEM) che acquistano la maggior parte del silicio per utilizzarlo nei propri prodotti di sistemi integrati. Il resto del mercato è costituito da una gran quantità di pedine di piccola entità che producono roba interessante, ma non lavorano su volumi tali da spingere alla progettazione di nuovi chip o di nuove soluzioni software.

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.
Dr. Seuss

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
Il software open source rientra nell’efficienza intrinseca al mercato libero, ma lo fa in modo organico e imprevedibile. Le aziende di Open Source svolgono il ruolo della "mano invisibile" di Adam Smith, guidano l’Open Source a beneficio del mercato in generale e per il conseguimento dei propri obiettivi microeconomici. Le aziende di Open Source di maggiore successo saranno quelle che gestiranno le tecnologie che generano la maggiore cooperazione da parte della comunità della Rete e risolvono i problemi tecnici ed economici della comunità degli utenti.

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,
MUTANDO LE LEGGI DELLA NATURA.
James Joyce