Home
Regalato!

19 Febbraio 2003

Regalato!

di

Come Red Hat Software si trovò fra le mani un nuovo modello economico e contribuì a migliorare un'industria di Bob 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?

Agli albori del sistema operativo Linux (1993) eravamo una piccola società di distribuzione di software. Offrivamo applicazioni Unix, manuali e CD-ROM a basso prezzo di produttori come Walnut Creek e Infomagic. In aggiunta alle offerte Unix tradizionali, questi produttori cominciavano allora a presentare una linea nuova: CD-ROM Linux. I CD Linux sarebbero diventati un nostro bestseller. Quando chiedevamo di sapere qualcosa di più su questo Linux ottenevamo risposte del tipo: “È fatto dai programmatori, secondo le loro capacità, per gli utenti, secondo i loro bisogni”.

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?

Questa domanda presuppone che sia facile, o almeno più facile, guadagnare vendendo software proprietario col solo codice binario (binary-only).

È 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

Se non possediamo proprietà intellettuale così come l’hanno quasi tutte le società di software, oggi, e se queste società insistono nel dire che la loro risorsa di maggior valore è la proprietà intellettuale rappresentata dal codice sorgente del software che possiedono, è lecito concludere che Red Hat non è nel business del software. Red Hat non vende licenze sulla proprietà intellettuale di cui è titolare. Non è questo il modello economico che supporterà i nostri clienti, i nostri dipendenti e i nostri azionisti. La domanda, allora, è: in quale business ci collochiamo?

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

Tanta gestione del marchio si riduce poi al posizionamento di mercato. Considerate le sfide che un nuovo sistema operativo affronta quando cerca di conquistare una quota di mercato significativa. Il mercato odierno degli OS (Operating System, Sistemi Operativi) è affollato e dominato decisamente da un beniamino del mercato, risultato di una brillante organizzazione di marketing. Posizionare correttamente un prodotto in competizione è cruciale al successo competitivo.

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

Il vantaggio vero di Linux non è l’alta affidabilità, la facilità d’uso, la robustezza o gli strumenti inclusi nel sistema operativo. È il vantaggio del controllo, che risulta dalle due caratteristiche distintive di questo OS: cioè, che arriva completo del codice sorgente e che si può usare questo codice sorgente per qualunque scopo, senza nemmeno chiedere il nostro permesso.

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 General Public License (GPL) concepita dalla Free Software Foundation è nello spirito dell’Open Source e, dal momento che assicura che le modifiche e i migloramenti fatti all’OS rimangano pubblici, è di grande efficienza nella gestione di un progetto di sviluppo cooperativo.

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

Le interessanti storie sull’origine di Linux aiutano a illustrare il modello economico forte che guida lo sviluppo di questo OS.

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

È facile confondere caratteristiche e vantaggi. Il modello Open Source in genere e Linux in particolare possiedono caratteristiche uniche e saremmo tentati di dire che queste sono le ragioni per cui il mondo sta adottando Linux con tanto entusiasmo. Come centinaia di manager MIS mi hanno detto, “Ma perché mai uno dovrebbe volere il sorgente del suo OS?”. Il punto è che nessuno vuole il codice sorgente. A nessuno serve una licenza free software. Queste sono semplici caratteristiche dell’OS. Ma una caratteristica non è necessariamente un vantaggio. Qual è dunque il vantaggio associato a quella caratteristica?

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

Il migliore esempio disponibile per illustrare come il modello di Linux sia un approccio radicalmente diverso alla costruzione di un OS, è esaminare quanto molti pensano sarà il risultato finale di questo sforzo a un OS: cioè, che Linux si balcanizzerà così come è successo a tutti gli Unix. Pare che circolino oggi trenta versioni di Unix, largamente incompatibili.

Ma le forze della deriva degli Unix sono le stesse che unificheranno i Linux.

La differenza principale fra Unix e Linux non è il kernel o il server Apache o qualunque altro insieme di caratteristiche. La differenza principale fra i due è che Unix non è che un altro OS proprietario binary-only o sotto IP. Il problema con un OS proprietario binary-only disponibile presso diversi fornitori sorge dal fatto che quei fornitori subiscono dal marketing delle pressioni a breve termine per tener segrete le innovazioni all’OS a vantaggio esclusivo dei loro clienti. Nel tempo, queste “innovazioni proprietarie” a ciascuna versione di Unix hanno portato i vari Unix a differire sostanzialmente fra loro. Questo avviene quando gli altri produttori non hanno accesso al codice sorgente dell’innovazione e la licenza usata dai produttori Unix inibisce l’uso di quell’innovazione anche qualora tutto il mondo Unix volesse usarla.

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

Ogni volta che una nuova, rivoluzionaria prassi fa la sua comparsa, alcuni scettici predicono il suo inevitabile fallimento, mettendo in risalto tutti gli ostacoli che il nuovo modello deve superare prima di poter cantare vittoria. Ci sono anche gli ideologi che insistono sul fatto che solo le implementazioni più pure del modello potranno avere successo. C’è poi il resto di noi, che semplicemente prova e riprova, mediante test e innovazioni, e usa il nuovo modello tecnologico in quelle applicazioni in cui esso funziona meglio del vecchio.

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.

Vuoi rimanere aggiornato?
Iscriviti alla nostra newletter

Novità, promozioni e approfondimenti per imparare sempre qualcosa di nuovo

Gli argomenti che mi interessano:
Iscrivendomi dichiaro di aver preso visione dell’Informativa fornita ai sensi dell'art. 13 e 14 del Regolamento Europeo EU 679/2016.