oPen source: mIto o realtà?

Orazio Viele

Direttore della direzione centrale Ricerca & Innovazione del gruppo Engineering.

13

FerentinoVII_06.indd 13 12/01/2009 11.01.55

FerentinoVII_06.indd 14 12/01/2009 11.01.55

QuadernI dI ferentIno n. 7

15

Introduzione

Ripercorrendo a ritroso gli ultimi trent’anni del mercato dell’Ict un elemen-to emerge con chiarezza: l’Ict è un mercato fortemente suscettibile alla forza evocativa delle parole. La mera apparizione di un nuovo termine o acronimo crea sommovimenti sul mercato che, ad un osservatore attento, sembrano pro-vocati da una forza quasi trascendentale, trascinando folle di fedeli abbacinati dal nuovo verbo.

Chi opera nel settore dell’Ict si ritrova molto spesso in presenza di nuovi termini che evocano straordinarie evoluzioni: ESB, BPM, SOA, Web 2.0, So-cial Network per enunciarne solo una minima parte sono i termini di ultima generazione.

In questo l’Ict assomiglia molto al settore della Finanza nel quale, negli ulti-mi anni, nostro malgrado, abbiamo imparato a conoscere la forza evocativa (e distruttiva) delle parole: mutui subprime, futures, hedge fund.

La similitudine tra il settore della finanza e il settore dell’Ict regge an-che se andiamo ad analizzare gli effetti che i termini evocativi producono sul mercato: grandi aspettative al loro apparire, qualche rapidissimo arric-chimento e poi una generale disillusione. In apparenza può sembrare che l’infatuazione verso una moda Ict lasci meno disastri dietro di sé rispetto al crollo delle chimere finanziarie. Ma se andassimo a scavare con attenzione nei bilanci di molte aziende ci imbatteremmo in zombie (sotto forma di costi che non hanno portato ritorni) che, sia pure sotto le fattezze disfatte dalla decomposizione, lasciano trasparire la bellezza di un termine che anni prima aveva fatto furore.

Il mio lavoro intende illustrare la nascita, l’evoluzione e il futuro di un fe-nomeno che sta suscitando un grandissimo interesse nell’ambito Ict: l’open source software. Dopo questa premessa il lettore è legittimato a sospettare che si tratti di nuova chimera e che l’autore di questo articolo sia un altro predicatore o incantatore impegnato a raccontare come l’open source software rappresenti la prossima (anzi l’attuale) rivoluzione dell’Ict.

Cercherò di fugare il sospetto, descrivendo le caratteristiche del fenomeno e le implicazioni sul mercato, facendo uso soltanto di fatti e iniziando subito con enunciarne due fondamentali:

l’open source software non si vende• l’open source software non è una nuova tecnologia, né un nuovo modello • architetturale, né una nuova metodologia, né un nuovo servizio.

FerentinoVII_06.indd 15 12/01/2009 11.01.55

16

orazIo vIele

Tutto quello che siamo abituati a vedere dietro un nuovo termine dell’Ict sembra non essere associabile al fenomeno dell’open source software e allora che cosa contraddistingue questo fenomeno fino al punto di farlo percepire come una nuova possibile rivoluzione nel mercato del software?

Proviamo a rispondere nei capitoli che seguono.

Genesi del fenomeno open source

L’Ict è un settore che contempla diversi segmenti: hardware, software, te-lecomunicazioni, per citarne alcuni. Il fenomeno dell’open source software pertiene al segmento software: se rappresentassimo su un diagramma l’evolu-zione del software potremmo osservare che nel succedersi delle innovazioni si incontrano degli improvvisi punti di discontinuità. Tra i punti di discontinuità che hanno maggiormente influenzato il mercato del software ricordiamo:

l’unbundling tra software di base e hardware che ha aperto la strada alla • differenziazione dei produttori tra costruttori di hardware e fornitori di softwarela definizione ed implementazione del protocollo IP che ha gettato le basi • per la nascita di Internet quasi trent’anni dopo.

Ho voluto citare questi due esempi perché sono connotati da caratteristiche comuni a tutti i punti di discontinuità che potremmo rilevare sull’immaginario diagramma dell’evoluzione del software:

spesso le discontinuità non sono frutto di straordinarie invenzioni ma, 1. mi si perdoni la semplificazione, derivano dall’uso intelligente di una soluzione già esistentela discontinuità è caratterizzata da innovazioni meramente tecnologiche2. le possiamo considerare discontinuità per gli effetti che provocano sul 3. mercato, mentre dal punto di vista puramente tecnico-scientifico l’evolu-zione del software non appare avere soluzione di continuità.

Osservando da vicino il fenomeno dell’open source sofware vedremo che non presenta né la prima né la seconda caratteristica, mentre in esso è esaltata la terza caratteristica.

Questa è un’altra stranezza che si va ad aggiungere a quanto abbiamo già detto nella conclusione della premessa: non si vende, non è una nuova tecno-logia.

FerentinoVII_06.indd 16 12/01/2009 11.01.55

QuadernI dI ferentIno n. 7

17

Ma tutte queste stranezze da dove nascono? È necessario illustrare breve-mente la genesi del fenomeno open source software per spiegarlo. A mio pare-re è nei cromosomi delle cellule che hanno generato il fenomeno open source che era iscritta la capacità di approfittare del cambiamento dell’habitat e di diventare organismo vincente.

Nel software, oltre alle parole, esistono date, eventi e personaggi che segna-

no l’inizio di un fenomeno; per l’open source software l’anno e il personaggio sono rispettivamente 1985 e Richard Stallman.

Nel 1985, Richard Stallman fonda la Free Software Foundation. Il principio costitutivo della FSF è che il software deve essere libero. La definizione di software libero proposta dalla FSF recita testualmente: “L’espressione <sof-tware libero> si riferisce alla libertà dell’utente di eseguire, copiare, distribu-ire, studiare, cambiare e migliorare il software. Più precisamente, si hanno quattro libertà per gli utenti del software:

libertà di eseguire il programma, per qualsiasi scopo1. libertà di studiare come funziona il programma e adattarlo alle proprie 2. necessitàlibertà di ridistribuire copie in modo da aiutare il prossimo3. libertà di migliorare il programma e distribuirne pubblicamente i miglio-4. ramenti, in modo tale che tutta la comunità ne tragga beneficio.”

Si noti che il termine open source non compare mai nelle libertà enunciate, infatti Stallman è considerato il padre del free software e ne è testimonian-za anche la denominazione della fondazione. Stallman ama paragonare il software all’aria che respiriamo: così come tutti gli esseri umani hanno il diritto di respirare, allo stesso modo hanno diritto di poter usare liberamente il software.

Spiegando la portata rivoluzionaria di queste affermazioni arriveremo a capire perché tutto ciò può essere considerato l’inizio dell’open source sof-tware.

Il mercato del software è da sempre dominato dal cosiddetto modello pro-prietario, così caratterizzato:

le imprese realizzano programmi che i clienti acquistano• i programmi sono scritti in linguaggi specializzati di programmazione e • il contenuto leggibile di un programma è denominato codice sorgente

FerentinoVII_06.indd 17 12/01/2009 11.01.55

18

orazIo vIele

il codice sorgente è la risorsa intellettuale di più alto valore per le aziende • software ed è protetto attraverso barriere fisiche: al cliente viene ceduto il codice cosiddetto eseguibile cioè in una forma non leggibile; e attraverso le barriere legali delle leggi sul copyright e in alcuni paesi attraverso la legge che regola i brevetti.

Da quanto detto emerge chiaramente come i principi stabiliti dalla FSF siano in completa contrapposizione a tutto ciò che regola il software proprietario.

L’accesso al codice sorgente è un prerequisito fondamentale per studiare e mi-gliorare un programma, senza la disponibilità del codice sorgente le libertà 1 e 3 risulterebbero ingannevoli. Questo spiega perché Stallman e la FSF possono esse-re considerati gli iniziatori del fenomeno open source software, poiché il fatto che il codice sorgente (source) sia aperto (open) è una condizione necessaria affinché le libertà stabilite da FSF siano fruibili.

Nello stesso tempo, l’accesso al codice sorgente nel modello proprietario è fisi-camente impedito poiché tale impedimento costituisce una delle protezioni della proprietà intellettuale.

Le libertà 1 e 2 infrangono le norme sul copyright e sui brevetti poste a sal-vaguardia della proprietà intellettuale nel modello proprietario; ciò implica che nel modello free software non si applichino le norme sul copyright, né quelle sui brevetti.

Per amore di verità bisogna dire che la distribuzione del codice sorgente non era una novità: già prima delle enunciazioni di Stallman il software veniva scambiato liberamente tra i laboratori di diverse istituzioni di ricerca, ma nes-suno aveva pensato di codificare dei comandamenti a cui doveva rispondere un determinato tipo di software.

Pur trattandosi di principi rivoluzionari la rivoluzione non avvenne, l’open source software rimase un epifenomeno a cui si interessavano pochi adepti.

D’altronde se riandiamo con la memoria a cosa era il mercato del software a metà degli anni Ottanta, cioè all’epoca in cui furono promulgati i principi del-la FSF, potremmo definire quel periodo, per analogia con la storia dell’uma-nità, l’epoca dell’impero.

Era nel pieno fulgore un impero: IBM dominava il mercato sia nel segmento software che hardware, alle frontiere cominciava a premere qualche popola-zione barbara (Microsoft nasce nel 1978), i regni che avevano sfidato l’impero ne erano usciti sconfitti (Sperry, Digital) ed erano in declino.

Più importante di tutto ciò però era il fatto che l’Ict in generale e il software

FerentinoVII_06.indd 18 12/01/2009 11.01.55

QuadernI dI ferentIno n. 7

19

in particolare erano ancora fenomeni di nicchia. L’Ict non veniva percepita come un settore portante dell’economia e interessava una ristretta cerchia di addetti ai lavori.

In questa breve storia della genesi del fenomeno open source software non può mancare un altro evento e un’altra data: 1991, nasce Linux. Un giovane univer-sitario finlandese, Linus Torvalds scrive il kernel di un nuovo sistema operativo che verrà battezzato “Linux”. In tutto questo non vi era nulla di rivoluzionario dal punto di vista tecnico, ma la novità consisteva nel fatto che si formò una comunità di sviluppatori che contribuiva in forma volontaristica ad estendere il kernel andando così a creare un sistema operativo sempre più completo. Nell’ul-tima frase compaiono due termini (comunità e contribuire) che assurgeranno ad un’importanza fondamentale nell’affermazione del fenomeno open source sof-tware. La comunità è un’aggregazione di individui che si associano liberamente per perseguire uno scopo, la contribuzione volontaristica presuppone che non vi sia un tornaconto economico a fronte della contribuzione stessa.

Possiamo dire che al manifesto originale dell’open source software che sta-biliva le caratteristiche del software (si concentrava sul prodotto), con l’av-vento di linux venivano aggiunte le regole del metodo di lavoro e si andavano definendo due caratteristiche essenziali del processo di sviluppo dell’open source software: comunità e contribuzione volontaria.

Queste regole mettevano in discussione i principi cardine nel modello pro-prietario:

nel modello proprietario chi sviluppa il software lo fa principalmente per • un tornaconto economico (viene pagato per farlo); la contribuzione vo-lontaria senza tornaconto che ha dato origine a Linux contraddice questo assuntonel modello proprietario il prodotto sviluppato risponde alle necessità • percepite del mercato potenziale e dal profitto che se ne può ricavare; la comunità che immagina, sviluppa ed implementa un prodotto non si preoccupa né che ciò serva a qualcuno e men che meno che se ne possa trarre un profitto, lo fa per il solo gusto di farlo e ciò contraddice l’assun-to del modello proprietario.

A questo punto della storia i semi della pianta “open source software” erano stati gettati, ma neppure una piccola pianticella era germogliata. Il mercato del software procedeva con qualche sussulto ma senza accorgersi minimamente dell’esistenza dell’open source software.

FerentinoVII_06.indd 19 12/01/2009 11.01.55

20

orazIo vIele

Potremmo dire, mantenendo l’analogia botanica e osservando quello che è successo dopo, che il terreno non era pronto e il clima non era favorevole. A sconvolgere le condizioni dell’habitat e creare l’humus per far germogliare una pianta vigorosa arrivò un’eruzione vulcanica.

Nel 1994 Tim Berners Lee pubblica su Communications Of ACM un ar-ticolo in cui descrive quello che si chiamerà World Wide Web, ciò che poi è diventato il Web e più in generale ha fatto esplodere il fenomeno Internet.

Anche in questo caso nulla lasciava presagire che da questo articolo sarebbe scaturita una colata lavica che avrebbe abbattuto e sepolto il vecchio mercato del software e fatto nascerne un altro. Gli effetti di questa eruzione si sareb-bero visti nel breve lasso di tempo di un lustro. Descrivere le cause di questo evento esula dagli scopi di mio lavoro, il cui obiettivo è evidenziare come e perché l’esplosione di Internet abbia fatto crescere la pianta dell’open source software fino a farla diventare un fenomeno che mette in discussione i futuri assetti del mercato del software.

Il web ha allargato enormemente la platea dei potenziali partecipanti alle co-munità che alimentano i diversi progetti di soluzioni open source. Si è incre-mentato a dismisura sia il numero degli sviluppatori sia il numero di utilizzatori delle soluzioni.

Ciò ha dato vita a un fenomeno del tutto nuovo nello sviluppo del software: sviluppatori e utilizzatori dislocati in varie parti del mondo che cooperano nella progettazione, sviluppo, testing e manutenzione di soluzioni software. Si potrebbe obiettare che anche nelle grandi multinazionali che sviluppano software già si operava attraverso laboratori distribuiti che cooperavano uti-lizzando reti private. Ebbene le differenze sono sostanziali:

la partecipazione alle comunità di sviluppo aziendali non è certamente su • base volontaristica ma prescritta dagli obblighi contrattuali che ciascun dipendente ha con la propria aziendail software prodotto dalle comunità di sviluppo aziendali è soggetto prin-• cipalmente alle verifiche di qualità interne e molto raramente gli utilizza-tori vengono coinvolti nella comunità; quando ciò accade si tratta sempre di utilizzatori selezionati, soggetti a precisi vincoli.

Le prime comunità che sviluppavano soluzioni open source, formatesi grazie a Internet, erano caratterizzate dall’esatto duale di quanto appena elencato:

partecipazione senza prescrizioni o costrizioni•

FerentinoVII_06.indd 20 12/01/2009 11.01.55

QuadernI dI ferentIno n. 7

21

contribuzione libera in tutte le fasi del processo di sviluppo• il software prodotto è sottoposto alle più variegate e impreviste verifiche • poiché raggiunge una platea di utenti le cui caratteristiche sono ignote a priorila disponibilità del codice sorgente permette a qualsiasi utente che abbia • il know-how specifico di valutare non solo cosa fa una soluzione, ma come è stata costruita, in sintesi di verificarne la qualità intrinseca.

Con l’avvento di Internet si conclude l’epoca pionieristica dell’open source software: la pianta i cui semi erano stati gettati tempo prima mostrava tutte le sue fronde e i suoi rigogliosi frutti.

L’ultima puntata di questa storia porta la data del 1998, Christine Peterson e Eric Raymond inventano il termine “open source” ed elaborano un insieme di linee guida rispettando le quali è possibile definire una soluzione informatica open source software. Di seguito ne diamo un sintetico elenco:

libertà di redistribuzione• libertà di rendere disponibile il codice sorgente senza alcun aggravio• possibilità di modifica o di creazione di opere derivate, con la garanzia di • poterle distribuire con la licenza del software originariosalvaguardia dell’integrità del codice sorgente originario• nessuna discriminazione contro persone o gruppi• nessuna discriminazione degli ambiti o delle finalità di impiego• perpetuazione della licenza in modo che gli utenti finali non debbano • accettare un nuovo accordo quando ricevono il software da un soggetto diverso dall’autoreassenza di prerequisiti fra programma e prodotti specifici, hardware e/o • softwareassenza di contagio delle licenze di altri programmi non open source • sulla distribuzione di soluzioni open source.

Le linee guida sopra elencate hanno un sapore meno ideologico (oserei dire meno dogmatico) rispetto alle libertà di Stallman. Ci si potrebbe avventurare in un ginepraio di inutili distinguo bizantini tra quanto stabiliscono le linee guida e quanto stabiliscono le libertà di Stallman: la sostanza, a mio parere, non cambia: l’open source software diviene una realtà del mercato del softwa-re con cui da adesso in poi bisogna fare i conti.

FerentinoVII_06.indd 21 12/01/2009 11.01.55

22

orazIo vIele

Caratteristiche del software open source

Nel descrivere la genesi del fenomeno open source software si sono evidenziati di volta in volta gli aspetti che lo contraddistinguono rispetto al software cosiddet-to proprietario. In questo paragrafo illustreremo questi aspetti più in dettaglio.

Le differenze sostanziali fra software proprietario e software open source si pos-sono raggruppare in tre ambiti: l’organizzazione dello sviluppo, il licensing e le modalità di distribuzione.

Le modalità di sviluppo di una soluzione open source si sono definite via via, tanto da divenire un modello organizzativo oggetto di studio per essere esportate anche nelle aziende.

Per l’avvio di un progetto open source bastano poche righe di codice e l’espo-sizione dell’idea. L’evoluzione della soluzione è frutto di un’attività fortemente collaborativa: al nucleo iniziale si aggregano tutti gli interessati sulla rete contri-buendo al raffinamento dell’idea e sviluppando parti di codice.

I partecipanti alla comunità interagiscono a distanza e quasi esclusivamente sen-za incontri face-to-face, la rete è il principale mezzo di comunicazione.

I partecipanti alla comunità operano ad intervalli temporali non codificati a prio-ri e lavorano sostanzialmente per obiettivi non vincolati dal tempo.

Il processo di sviluppo è scarsamente codificato ma la qualità di quanto prodotto è continuamente esaminata dalla comunità.

Nel momento in cui una soluzione assume una certa rilevanza e la comunità di supporto diviene stabile, ad alcuni partecipanti vengono assegnati ruoli ben defi-niti: un gruppo si occupa di proporre nuove funzionalità; un secondo di valutare e accettare le proposte, un terzo gruppo di decidere cosa deve far parte dei rilasci ufficiali. Ma pur in presenza di ruoli definiti non viene mai meno la possibilità da parte di altri soggetti di partecipare, contribuendo con proposte di miglioramento e eventuali componenti software. Le comunità di sviluppo delle soluzioni open source sono sempre gruppi aperti.

È percezione diffusa tra gli osservatori meno attenti (e in qualche caso in malafede) che il vantaggio principale dell’adozione di soluzioni open source è l’azzeramento dei costi di licenza.

Non a caso diversi produttori di soluzioni commerciali proprio nell’intento di contrastare questa presunta peculiarità “visibile” del software open source hanno reso disponibili versioni dei loro prodotti senza costi di licenza. L’az-zeramento dei costi di licenza è soltanto il vantaggio più immediatamente percebile, ma non l’unico e soprattutto non il più importante. Osservando con

FerentinoVII_06.indd 22 12/01/2009 11.01.55

QuadernI dI ferentIno n. 7

23

più attenzione il fenomeno open source si possono evidenziare chiaramente i vantaggi più importanti che scaturiscono dall’adozione di tali soluzioni.

Una soluzione software proprietaria lascia scarsissimi margini all’adatta-mento ed all’estensione; al contrario la possibilità di accedere al codice sor-gente delle soluzioni open source permette di operare liberamente nella perso-nalizzazione ed adattamento alle proprie esigenze.

L’evoluzione di una soluzione software open source potenzialmente non si interrompe mai. La possibilità di accedere liberamente sia al codice sorgente che alla documentazione tecnica di una soluzione open source, protegge l’uti-lizzatore da eventi piuttosto frequenti nel mercato delle soluzioni proprietarie: cambiamento di release, dismissione di versioni, acquisizione del vendor con conseguente cambiamento di strategia.

Per far fronte a questi episodi non esistono contromisure poco costose: o si accetta di seguire quanto impone il produttore, oppure si deve investire nella sostituzione della soluzione. Si noti che tutto ciò non è dettato da necessità proprie, ma è imposto da eventi e strategie su cui non si hanno mezzi per inter-venire. L’adozione di una soluzione open source a codice sorgente aperto con-sente la facile sostituibilità del fornitore e anche in presenza di un’eventuale chiusura della comunità di supporto, altri attori possono intervenire e prendere in carico l’evoluzione della soluzione.

Il meccanismo della risoluzione dei bugs nell’ambito dei prodotti proprietari segue un iter articolato: sottomissione del bug, verifica a più livelli dell’effettiva presenza del bug, suo accodamento per la risoluzione. Questa gabbia rigida è motivata dal fatto che i laboratori deputati a questa attività sono comunque in nu-mero limitato perché rappresentano un costo e non un centro di profitto. L’utente non può intervenire in alcun modo nel processo e spesso, prima di sottomettere il bug al produttore, è costretto a diverse verifiche perché senza il codice sorgen-te non si può determinare in modo inequivocabile l’origine dell’errore: errato utilizzo del software o al contrario deficienza intrinseca dello stesso.

Il processo di risoluzione dei bugs nell’ambito delle soluzioni open source è molto più rapido per diversi motivi: la disponibilità del codice sorgente permette quasi immediatamente, in presenza di un malfunzionamento, di de-terminare se dipenda da una deficienza della soluzione o da un errato uti-lizzo. Quanto più vasta è la comunità di utilizzatori, tanto più rapidamente verrà effettuata la correzione; non vi sono limiti sulle risorse impiegabili e potenzialmente tutta la comunità può cooperare per la risoluzione del bug.

FerentinoVII_06.indd 23 12/01/2009 11.01.56

24

orazIo vIele

Il controllo di qualità sulle componenti software rilasciate nell’ambito del software proprietario è demandato a unità specializzate, facenti parte dell’or-ganizzazione del produttore, l’utente non ha alcun mezzo per intervenire.

Nell’ambito del processo di produzione delle soluzioni open source il con-trollo di qualità è pressoché continuo. Ad ogni nuovo rilascio gli utenti, che hanno il know how tecnico, verificano la soluzione, analizzandone non solo le funzionalità esterne ma anche il codice che implementa le stesse. L’utente finale che non avesse il know-how tecnico necessario per eseguire verifiche ispettive del codice può richiedere queste attività a terze parti, che possono operare liberamente disponendo del codice sorgente e potendo interagire con la comunità degli sviluppatori.

I vantaggi che abbiamo appena descritto derivano dalle specifiche modalità con cui viene sviluppato il software open source, tali modalità sono caratte-rizzate dalla cooperazione paritetica tra sviluppatore ed utilizzatore e dalla illimitata libertà di intervento sulla soluzione, concetti che stanno facendo breccia anche nelle organizzazioni che producono software proprietario.

In linea generale non è corretto affermare che l’utilizzo del software open source non è soggetto a vincoli: a ciascun software open source è associata una licenza che definisce i vincoli a cui deve sottostare l’utilizzo di quella soluzione. A prima vista può sembrare una contradditio in terminis vincolare l’utilizzo di una soluzione open source che per sua natura non deve porre vin-coli. Ebbene anche in questo caso è utile fare una riflessione: se non fossero posti dei vincoli, in che modo si potrebbe impedire a qualcuno di utilizzare una soluzione open source per rivenderla, proteggendo l’accesso al codice sorgente e rendendolo così non accessibile?

Sia le libertà stabilite dalla FSF che le linee guida definite da Raymond e Pe-tersen stabiliscono che cosa si può fare, ma se lette con attenzione implicano anche che cosa non si può fare con il software open source. Per rendere ancora più chiaro il concetto, sia FSF che altre organizzazioni hanno stabilito regole dettagliate per l’uso delle soluzioni open source, ma è intuitivo che l’insieme di queste regole assume la forma di una licenza associata alla soluzione.

Il tema del licensing nell’ambito del software open source è molto dibat-tuto e non è questa la sede per dar conto in modo esaustivo dei termini del dibattito. Ci concentreremo sulle caratteristiche generali delle diverse tipo-logie di licenze che attualmente si possono ritrovare associate a soluzioni open source.

FerentinoVII_06.indd 24 12/01/2009 11.01.56

QuadernI dI ferentIno n. 7

25

L’organizzazione Open Source Initiative (OSI) ha stabilito le condizioni base di una licenza affinché un software possa dirsi open source:

dare all’utente il diritto di utilizzare il software per qualsiasi scopo1. dare all’utente il diritto di copiare il software per qualsiasi scopo2. dare all’utente il diritto di accedere o modificare il codice sorgente per 3. qualsiasi scopodare all’utente il diritto senza pagamento di royalties o fee di distribuire 4. copie del software o di opere da esso derivate con gli stessi termini di licenza del software originale.

Tutte le tipologie di licenze sono certificate da Open Source Initiative e come tali hanno una serie di caratteristiche comuni. Esistono delle differenze importanti riguardo la distribuzione dei sorgenti e del codice binario. In gene-rale le licenze OSI-compliant sono suddivise in due categorie:

Attribution-style licences (BSD/MIT/Apache, EPL, CPL)Queste licenze consentono agli sviluppatori di utilizzare una parte o tutto il

codice sorgente di una soluzione e riusarlo per crearne un’altra. Il copyright e la struttura della licenza devono essere mantenuti inalterati e un attribution statement (riconoscimento all’autore della soluzione da cui si è partiti per re-alizzare l’opera derivata) deve essere aggiunto all’opera derivata. L’opera de-rivata può essere rilasciata con qualsiasi tipo di licenza, anche con una licenza di tipo proprietario.

Share o share alike licences (GNU GPL/LGPL)Le licenze di questo tipo impongono che tutte le modifiche, opere derivate e

ridistribuzioni del software originale, devono essere disponibili liberamente e non possono essere protette da licenze di tipo più restrittivo dei diritti per gli utenti e gli sviluppatori.

Negli ultimi anni si è assistito ad una proliferazione di licenze che appa-re ingiustificata e foriera di confusione e remore nell’utilizzo delle soluzioni open source.

La diffusione del software open source è stata enormemente agevolata da Internet. Attraverso Internet, il software open source viene pubblicizzato, distribuito e soprattutto è attraverso Internet che una soluzione open source si costruisce la propria immagine e credibilità: ciò che viene chiamato net-effect. Clay Shirky all’Aula Point of View di Helsinki nel giugno del 2006

FerentinoVII_06.indd 25 12/01/2009 11.01.56

26

orazIo vIele

affermò:“Su SourceForge ci sono 120.000 progetti. Le soluzioni di successo, esami-

nando i dati sul download, sono una decina. Se la soluzione non ha successo, il fallimento è pagato dai singoli contributori, mentre l’eventuale successo viene condiviso da tutti”.

SourceForge è un sito che accoglie qualsiasi progetto open source.

Dall’acuta osservazione di Shirky deduciamo che nell’ambito del software open source vale la legge darwiniana della selezione naturale: gli organismi più resistenti rimangono in vita e si riproducono, quelli più deboli si estinguo-no.

Anche in questo caso si potrebbe obiettare che questa è la legge naturale di tutti i mercati, ma analizzando da vicino quali caratteristiche rendono resi-stente un organismo (una soluzione open source), le differenze saltano subito all’occhio:

per sviluppare e mettere sul mercato una soluzione open source servono • pochissimi capitali finanziari, ma un elevato capitale di volontà e crea-tivitàuna soluzione open source non si promuove con le strategie di marke-• ting classiche (pubblicità, reti di vendita, partnership), bensì sfruttando il cosiddetto net-effect che, in parole semplici, consiste nell’essere visibile sul Web, nella reputazione acquisita nelle comunità di utilizzatori, in re-gole chiare per le contribuzioni e soprattutto nell’essere una soluzione di alta qualitàla valutazione della qualità di una soluzione open source è assolutamente • oggettiva poiché qualunque utilizzatore può effettuare benchmark per valutarne efficienza e affidabilità; il codice sorgente può essere analizza-to in tutte le sue parti evidenziando errori logici e bug di sicurezza; si può affermare che l’ampiezza del net-effect è direttamente proporzionale alla qualità della soluzione proposta.

In definitiva, mentre per le soluzioni software proprietarie il marchio e le strategie di marketing hanno un ruolo determinante per il loro successo, per le soluzioni open source la qualità è un fattore decisivo accompagnato da una chiara strategia per il coinvolgimento delle comunità di utilizzatori e svilup-patori. Pertanto gli organismi che resistono sono certamente qualitativamente i più forti.

FerentinoVII_06.indd 26 12/01/2009 11.01.56

QuadernI dI ferentIno n. 7

27

Impatto sul mercato

Nell’introduzione ho evidenziato come le parole abbiano un forte potere di condizionamento sul mercato dell’Ict, lasciando molto spesso strascichi nega-tivi quando l’onda del successo di quel termine si placa. Ci siamo posti anche l’obiettivo di verificare se e come il fenomeno open source si discosti da que-sta legge: soltanto analizzando gli effetti prodotti sul mercato e la loro portata nel tempo effetti potremo dimostrare la nostra tesi .

È necessaria un’ulteriore premessa prima di addentrarci nell’analisi. Più di un osservatore fa rientrare il software open source in un più vasto movimento che, rispolverando una sorta di archeologia terminologica, potremmo definire libertario-partecipativo. Questo movimento ha implicazioni socio-politiche, motivazionali-psicologiche, filosofiche e c’è un’ampia letteratura che ha pro-vato ad analizzarle.

Per inquadrare gli effetti che ha avuto e potrà avere il software open source sul mercato è necessario soffermarsi brevemente sulle caratteristiche dell’at-tuale mercato del software, divenuto negli anni molto variegato e segmenta-bile, a grandi linee, in quattro aree principali: software di base, middleware, software applicativo o custom, packages.

La conformazione del mercato del software può essere paragonata a quella degli idrocarburi.

Esistono i produttori di greggio che nel caso del mercato del software sono i produttori di software di base. Il numero di player nel software di base si è progressivamente ridotto: oggi sono rimasti Microsoft, IBM e Oracle, con posizioni ampiamente dominanti e volendo proseguire con la metafora degli idrocarburi questi protagonisti sono molto meno numerosi dei paesi produttori di gas e petrolio.

I produttori di middleware, cioè software che si appoggia sul software di base ma che è comunque software di sistema, ad esempio: DBMS, Appli-cation Server, Web Server, Message Server, possono essere assimilati a chi gestisce la prima trasformazione del greggio e lo trasporta poi agli erogatori. Ebbene anche in questo segmento si è assistito negli anni ad una drastica ra-zionalizzazione del mercato: IBM ha acquisito diversi player medi, Oracle ha fatto lo stesso.

Il prodotto finito, cioè le applicazioni software destinate gli utenti finali, appartiene a due segmenti, quello del software applicativo e quello dei packa-ges, che possono paragonarsi al carburante che viene raffinato e poi distribuito da diversi operatori. Nel segmento dei packages primeggia SAP, insidiata da

FerentinoVII_06.indd 27 12/01/2009 11.01.56

28

orazIo vIele

Oracle; gli altri player si sono estinti negli anni. Il segmento del software applicativo è l’unico in cui vi è ancora una presenza significativa di diversi player grandi e medi, spesso con un forte radicamento nazionale. Il software applicativo viene costruito sulle esigenze del cliente. Per alcuni segmenti di clientela come la pubblica amministrazione, la costruzione di software perso-nalizzato sulle proprie esigenze è spesso una necessità: le differenze normati-ve e socio-culturali tra i diversi paesi non consentono di costruire un package adatto a tutte le pubbliche amministrazioni. Le dinamiche politico-legislative provocano mutamenti anche radicali nei processi operativi che si riflettono nei sistemi informatici di supporto alle attività amministrative. Per i package è molto difficile offrire gradi di libertà e flessibilità capaci di far fronte ai mutamenti.

Il software applicativo è l’ultimo anello della catena, il suo sviluppo non prescinde dall’uso di middleware e software di base, segmenti che, come ab-biamo visto, sono praticamente in mano a tre produttori. Questo condiziona-mento si riflette sulle scelte dei clienti, costretti a seguire necessariamente le roadmap evolutive che i produttori di software di base e middleware impon-gono: in gergo questo condizionamento viene chiamato lock-in. Continuando nella similitudine con il mercato degli idrocarburi, se, per assurdo, tutti i pro-duttori decidessero di cambiare la composizione del carburante, tutti i motori delle automobili andrebbero cambiati. Mentre nel mercato degli idrocarburi questo pericolo appare teorico, nel mercato del software è molto più reale, perché il potere di condizionamento è in mano a pochissimi player e poco per-cepito: a molti clienti sembra quasi naturale passare da Windows XP a Vista e fra un anno passare a Windows 7, senza rendersi conto che il passaggio non è indotto da proprie esigenze, ma è una costrizione provocata dalle strategie commerciali del produttore. Si fa poca attenzione al fatto che questo cam-biamento indotto comporta notevoli investimenti finanziari, marginalmente finalizzati a migliorare delle prestazioni e dei servizi.

Possiamo dire di essere arrivati al nocciolo dell’analisi degli effetti sul mer-cato: l’avvento del software open source sta progressivamente erodendo il potere di condizionamento dei produttori di software.

Il software open source sta lentamente, ma costantemente, conquistando quote di mercato proprio nei segmenti del software di base e del middleware: Apache, Linux, JBoss, solo per fare alcuni nomi, sono divenute valide alter-native a prodotti proprietari e altre soluzioni open source si stanno progressi-vamente affermando.

FerentinoVII_06.indd 28 12/01/2009 11.01.56

QuadernI dI ferentIno n. 7

29

Le caratteristiche cromosomiche del software open source già illustrate han-no fatto sì che esso diventasse lo strumento per porre un freno al trend oligo-polistico a cui sembrava destinato il mercato del software.

L’avvento del software open source ha fatto emergere nuovi player di mer-cato che operano principalmente nei servizi a corredo del software: manuten-zione, garanzia e supporto. Red Hat è l’esempio più significativo: un’azienda che basa tutto il proprio business sul supporto di soluzioni open source.

È significativo che Red Hat sia riuscita a battere la concorrenza di Oracle nell’acquisizione JBoss, il più diffuso J2EE application server open source. Sono segnali importanti anche l’acquisizione da parte di Novell di Suse, azien-da distributrice di una versione di Linux e gli investimenti di IBM su Linux.

I fatti analizzati portano a due conclusioni: il fenomeno open source sof-tware ha creato nuove opportunità sul segmento del software di base e mid-dleware e nascono nuove aziende; i più importanti player di mercato, come Oracle e IBM, cominciano ad interessarsi al fenomeno, attuando una propria strategia supportata da massicci investimenti. Bisogna sempre chiedersi, per mantenere alta la guardia verso il potere evocativo delle parole, se questi in-vestimenti siano il frutto di un ponderato esame del trend e rispondano allora ad una vera e propria logica di business, oppure se siano di copertura per poter affermare “anche noi facciamo software open source e non ci opponiamo a questo fenomeno”.

Rispondere a questa domanda ha lo stesso valore definitorio di un’interpre-tazione di una macchia Rohschak: ciascuno darà la propria interpretazione e tutte sono valide. Certo è che alcuni contorni e alcune zone della macchia ap-paiono chiare e potrebbero avere un’interpretazione statisticamente quasi uni-voca e in quanto detto sopra abbiamo cercato di evidenziare contorni e zone.

Le conclusioni ci indicano che il fenomeno open source ha certamente avuto impatti sul mercato dal lato dei fornitori del software di base. Per completare la dimostrazione della nostra ipotesi iniziale è necessario verificare se anche nel segmento dei fornitori di software applicativo e dal lato dei clienti si regi-strino impatti significativi che possono essere considerati duraturi.

Dal lato dei produttori di software applicativo (generalmente denominati system o business integrator) hanno come core business lo sviluppo di sof-tware personalizzato sulle esigenze del cliente corredato da eventuali servizi consulenziali.

FerentinoVII_06.indd 29 12/01/2009 11.01.56

30

orazIo vIele

Qualsiasi software custom non può essere realizzato e non può essere messo in esercizio senza una infrastruttura di tecnologie di base: sussiste quindi una relazione di dipendenza stretta tra il software custom e il software di base. Questa relazione può essere alquanto mitigata utilizzando interfacce standard per far dialogare il software custom con il software di base. In questo modo la tecnologia di base è intercambiabile. Questo rappresenta un indubbio van-taggio per il cliente che può mettere in concorrenza più fornitori di tecnologia di base, ma, fatte salve tutte le considerazioni relative alla qualità di quanto prodotto, in stretti termini economici non incide positivamente sui profitti del system integrator; anzi, in alcuni casi, sviluppare in modo indipendente dal software di base può richiedere maggiori sforzi e quindi incrementare i costi a detrimento dei margini.

Il system integrator è, soprattutto nei progetti medio-grandi, contrattualmen-te responsabile dell’intera soluzione realizzata e quindi anche della tecnologia di base scelta che viene vista dal cliente come parte integrante della soluzione stessa.

Si viene a creare così una forte discrasia tra la responsabilità e le leve che il system integrator ha a disposizione per ridurre i rischi insiti in questa re-sponsabilità impropria. Un bug nel software di base che metta in discussione la stabilità della soluzione applicativa realizzata, è responsabilità contrattuale del system integrator che non ha alcuna leva diretta per porvi rimedio se non quella di fare pressioni sul fornitore della tecnologia stessa.

Anche l’eventuale manutenzione evolutiva della soluzione applicativa deve fare i conti con l’evoluzione delle tecnologie di base utilizzate, le cui roadmap rispondono ai legittimi interessi di business dei produttori e molto difficilmen-te coincidono nei tempi e nei modi con quelli del system integrator.

C’è poi da considerare un fenomeno preoccupante. Da alcuni anni, in un in-sieme di paesi tra cui l’Italia, la spesa complessiva in software è stazionaria o addirittura in decrescita, ma la parte dedicata all’acquisto di licenze aumenta. Con la conseguenza che le già limitate risorse finanziarie del mercato poten-ziale del system integrator sono soggette ad una continua erosione da parte del segmento del software proprietario.

In definitiva, la spesa in software proprietario nel segmento middleware e software di base drena risorse economiche.

Il system integrator non può fornire servizi a valore aggiunto su queste tec-nologie (manutenzione, assistenza) con profitti significativi: il differenziale di know-how tra il produttore della tecnologia di base e il system integrator che intende fornire questi servizi, è troppo elevato per rendere competitiva la

FerentinoVII_06.indd 30 12/01/2009 11.01.56

QuadernI dI ferentIno n. 7

31

posizione di quest’ultimo. In definitiva, sui segmenti software di base e mid-dleware un system integrator gioca oggi un ruolo marginale, sia in termini di profitti che di possibile acquisizione di quote di mercato.

Sic stantibus rebus, un system integrator deve accontentarsi di puntare ad allargare la sua quota di attività ai servizi nella aree in cui è in grado di realiz-zare o governare i sistemi informativi: la piattaforma tecnologica è terreno di caccia di altri con cui bisogna scendere a patti e avere buoni rapporti.

Nulla di strano in tutto ciò, in tutti i mercati esistono relazioni di dipendenza stretta fra produttori: senza petrolio non si produce energia, senza acciaio non si costruiscono macchinari, senza cargo non si trasportano le merci. Coprire l’intera supply chain di un qualsiasi settore merceologico è utopistico e nella stragrande maggioranza dei casi risulta scarsamente profittevole.

L’irrompere sullo scena del software open source apre notevoli possibilità ai system integrator:

il software open source non incide sul costo totale della soluzione appli-• cativa e libera una parte delle risorse finanziarie che il mercato avrebbe dovuto destinare all’acquisto di licenze software e manutenzioni correlate. Questo non basta ad affermare che le risorse si trasferiscano direttamente sulla quota destinata al software applicativo e ai servizi, ma almeno in pre-senza di una stagnazione degli investimenti complessivi le risorse finanzia-rie disponibili non vengono drenate dal software proprietariol’utilizzo del software di base open source apre al system integrator spazi • nell’ambito dei servizi di manutenzione e di assistenza sulla piattaforma tecnologica fino ad oggi quasi totalmente preclusi e appannaggio dei for-nitori delle tecnologie di base. Ciò non significa che si possa impostare un modello di business integralmente basato su questi servizi, i tentativi fatti finora hanno avuto esiti negativi. Ma un system integrator ha già un porta-foglio d’offerta consolidato ed i nuovi spazi di offerta allargano le aree di intervento dei servizi. Inoltre, il system integrator può utilizzare una leva significativa per sfruttare questa opportunità: ha già dovuto instaurare una relazione di fiducia col cliente nel momento in cui ha preso in carico la realizzazione di un sistema applicativo mission critical e può far uso della credibilità acquisita per allargare il raggio d’azione ad altri ambiti l’utilizzo del software open source attenua notevolmente la dipendenza • stretta tra manutenzione evolutiva e correttiva del software custom e ma-nutenzione del software di base. Qualunque bug riscontrato nel software di base che condizioni le caratteristiche del software custom può essere

FerentinoVII_06.indd 31 12/01/2009 11.01.56

32

orazIo vIele

potenzialmente rilevato velocemente e corretto dal system integrator che dispone del codice sorgente. È evidente che la rapidità e la capacità di intervento sono direttamente proporzionali al know-how che il system integrator possiede sul software di base utilizzato. Ma questo è vero an-che quando si utilizza software di base non open source: non è possibile definire ed implementare architetture applicative complesse senza cono-scere le caratteristiche tecniche della infrastruttura tecnologica su cui si opera. I fornitori di tecnologie di base non open source offrono servizi di formazione e certificazione finalizzati a diffondere il know how tecnico sulle proprie piattaforme e a fornire ai clienti un criterio di selezione dei system integrator. Pertanto, un system integrator deve comunque fare un investimento nell’acquisire competenze su piattaforme tecnologiche di base, siano esse open source o no.

Ci avviamo alla conclusione. È nei fatti che il fenomeno open source sof-tware allarghi lo spettro delle opportunità per i system integrator e ogni ipotesi di minaccia è scomparsa. Vero è che per cogliere le opportunità un system integrator deve investire in know-how: gli skill necessari per governare in-tegralmente soluzioni basate su componenti open source sono di elevato li-vello e questi skill possono costruirsi solo innestandoli su una cultura di base informatica solida. L’improvvisazione può trasformare l’opportunità in una catastrofe poiché la dimostrata incompetenza sulle piattaforme proposte può mettere in discussione anche la fiducia accordata sullo sviluppo delle soluzio-ni applicative che rappresenta il core business del system integrator.

Tutte queste opportunità hanno già prodotto effetti sul segmento dei system integrator? È difficile determinarlo oggettivamente poiché le opportunità che abbiamo illustrato non producono effetti misurabili direttamente: nei bilanci dei system integrator il fatturato ricavato dai servizi non viene distinto tra ser-vizi erogati su piattaforme proprietarie e servizi erogati su piattaforme open source. È possibile, però , far ricorso ad un’induzione, utilizzando come base del ragionamento i risultati di un survey condotto da Gartner nel 20071 su aziende clienti in Europa e in Nord America. L’inchiesta di Gartner si è con-centrata nell’analizzare quale quota di mercato attuale e potenziale il software open source stia erodendo alle soluzioni proprietarie.

1 “User Survey Analysis: Open-Source Software, North America and Europe, 1H07”, Gartner Group

FerentinoVII_06.indd 32 12/01/2009 11.01.56

QuadernI dI ferentIno n. 7

33

L’inchiesta ha determinato che vi sono tre effetti principali provocati dal software open source sul mercato tradizionale del software:

la spesa in software open source è incrementale rispetto alla spesa com-• plessiva nel software: l’universo software si espande e l’adozione del software open source non è un gioco a somma zerola spesa in software open source sta erodendo la spesa in software proprie-• tario e nel prossimo quinquennio l’erosione si attesterà tra il 5% e il 15%il fatturato del software open source deriverà principalmente dai servizi • professionali.

In sintesi, l’adozione del software open source crea un valore aggiuntivo co-stituito sia da quote erose al software proprietario, ma anche da nuovi investi-menti e la maggior parte di questo valore è indirizzata ai servizi professionali, area in cui tipicamente operano i system integrator.

A conferma del fatto che sta emergendo un trend nel settore del software stimolato dal fenomeno open source, è apparso da qualche tempo un nuovo termine (non poteva mancare…) che sta divenendo sempre più in voga, pro-fessional open source, che sta ad indicare aziende che generano ricavi for-nendo servizi complementari correlati ai prodotti open source distribuiti. Le aziende professional open source controllano lo sviluppo e l’evoluzione della soluzione e possono sfruttare questa conoscenza degli internals per offrire ser-vizi di più alta qualità.

Anche dal lato dei system integrator gli effetti del fenomeno open source cominciano ad avvertirsi e appaiono essere duraturi.

Ci resta da considerare a questo punto quali sono stati e quali potranno esse-re gli effetti sui clienti del fenomeno open source software.

Possiamo ricorrere ad una seconda inchiesta di Gartner, “Open Source in Europe, 2008” che dimostra come l’adozione del software open source in Eu-ropa sia significativamente cresciuta, soprattutto nell’area del software infra-strutturale, middleware e software di base.

Dall’inchiesta emerge che nei paesi dell’Europa Orientale vi è stata una notevole diffusione dell’utilizzo del software open source (circa l’80% delle organizzazioni intervistate ne fanno uso, rispetto al 50% delle organizzazioni dell’Europa Occidentale). Ciò implica che il costo delle licenze del software proprietario, confrontato con il costo di staff con competenze specifiche, è ritenuto troppo elevato nelle economie emergenti, nelle quali in sostanza si

FerentinoVII_06.indd 33 12/01/2009 11.01.56

34

orazIo vIele

privilegia l’investimento in capitale umano e conoscenza, piuttosto che in li-cenza di software chiusi.

Dall’inchiesta emerge che il 49,7 % delle aziende coinvolte utilizza il sof-tware open source in soluzioni mission critical.

Alcune settimane fa il commissario europeo alla concorrenza Neelie Kroes ha affermato in una conferenza stampa riportata dai maggiori organi di infor-mazioni2: ««So riconoscere una scelta imprenditoriale intelligente e preferire programmi open source è una di queste» e ha proseguito «Nessuna azienda o cittadino dovrebbe essere costretto ad adottare una tecnologia chiusa».

Il commissario ha citato esempi definiti intelligenti di utilizzo di software open source: il comune di Monaco, che da settembre ha adottato il sistema operativo Linux al posto di Windows e l’Olanda, dove il Parlamento ha votato una legge che impegna tutte le pubbliche amministrazioni a privilegiare sistematicamente l’utilizzo di software open source e l’adozione di formati aperti. La decisione del Parlamento olandese ha suscitato scalpore, soprattutto perché non si tratta di una norma di indirizzo ma impositiva e le regole sono rigide: ciascuna pubblica amministrazione olandese a partire da aprile 2008 dovrà giustificare l’eventuale scelta di un software proprietario rispetto ad uno open source e viene istituito un ispettorato di controllo che verificherà l’applicazione di queste norme.

Le dichiarazioni del commissario europeo hanno un loro valore visto l’au-torevolezza del ruolo rivestito da chi le ha fatte, ma è importante evidenziare come queste dichiarazioni confermano una consapevolezza: il software open source è divenuto una realtà per la clientela.

I risultati dell’inchiesta e il pronunciamento del commissario europeo alla concorrenza testimoniano che il fenomeno open source software ha un note-vole impatto sulla clientela e non potrà non lasciare un’eredità duratura, vista la proporzione e l’importanza dell’impatto.

Per chiudere potremmo affermare con Gartner3 che:In many cases, the question is “when” to focus on open-source alternatives

to traditional closed-source solutions, not “if” you should focus on them.

2 http://www.ilsole24ore.com/art/SoleOnLine4/Tecnologia%20e%20Business/2008/06/ue-open-source.html

3 Gartner Hype Cycle for Open-Source Software, 2005.

FerentinoVII_06.indd 34 12/01/2009 11.01.56

QuadernI dI ferentIno n. 7

35

Vorrei concludere questo lavoro con alcune considerazioni che guardano avanti.

Il fenomeno open source software viene spesso ammantato di un’aura di movimento rivoluzionario di controcultura che, a mio parere, può provoca-re solo effetti negativi. Le rivoluzioni comportano rivolgimenti radicali dello status quo e questo suscita una reazione pavloviana in chi teme di essere spaz-zato. Allora prevalgono i preconcetti e non si vedono le opportunità. Le pre-sunte rivoluzioni non durano in eterno, ma prima o poi devono mantenere le promesse: quando ciò non avviene subentra la delusione dei rivoluzionari e la derisione dei controrivoluzionari, e tutti gli effetti positivi vengono sradicati, con il “fastidioso” corollario di ghigliottine e purghe.

Vorrei che questa pericolosa aura venisse soffiata via e si considerasse il fenomeno open source software per quello che veramente è. Mi è venuto in aiuto in questo compito un recente articolo apparso su Communications ACM4 nel quale gli autori per definire il fenomeno open source software fanno ri-corso all’ossimoro motore di distruzione creativa, che il grande economista Schumpeter utilizzò per descrivere la creazione di nuove imprese nel suo ce-leberrimo lavoro Capitalism, Socialism, and Democracy.

Schumpeter afferma che gli imprenditori immaginano nuovi prodotti, nuovi modi di produrre e distribuire, nuove strutture organizzative. Sarà il mercato a decretarne il successo, basandosi sulla percezione del valore. Ebbene questo è il propellente di un motore di distruzione (distrugge il vecchio modo di pro-durre e distribuire) creativa (crea nuovi prodotti, nuovi modi di produrre).

Si parva licet componere magnis gli autori dell’articolo affermano che open source software “appears to be creative destruction in action”, proprio come teorizzato da Schumpeter, poiché tutte le componenti che costituiscono il car-burante per il fuoco che distrugge e crea sono presenti.

Ad alcuni sacerdoti dell’ala movimentista dell’open source risulterà certa-mente blasfemo citare Schumpeter, profeta del capitalismo in continua espan-sione e dell’elitismo democratico, per definire il fenomeno open source sof-tware.

A mio parere il fenomeno open source software può a pieno titolo fregiarsi dell’ossimoro schumpeteriano.

Nascono continuamente nuove comunità e si accrescono quelle esistenti che producono nuove soluzioni open source o fanno evolvere quelle esistenti.

4 Richard T. Watson, Marie-Claude Boudreau, Paul T. York, Martina E. Greiner, and Donald Wynn, Jr. – The Business of Open Source, April 2008, Vol. 51 No. 4.

FerentinoVII_06.indd 35 12/01/2009 11.01.56

36

orazIo vIele

Le comunità open source sono gli imprenditori schumpeteriani: immaginano nuovi prodotti e li costruiscono.

Il modello di licensing a costo zero di molte soluzioni open source è una novità assoluta nel mercato dell’Ict e ha aperto la strada all’adozione di diversi prodotti in diversi mercati precedentemente preclusi. Ritornando a Schumpe-ter: si è ideato un nuovo modo di vendere.

Internet ha messo a disposizione uno straordinario mezzo per cambiare ra-dicalmente il modo di distribuzione dei prodotti e l’open source software lo ha sfruttato appieno. Questo nuovo mezzo ha azzerato i costi di distribuzione e eliminato le barriere poste dalla distanza fra fornitore e cliente. Anche qui si conferma la validità dell’ossimoro schumpeteriano applicato al fenomeno open source software: si è inventato un nuovo modo di distribuire.

Le comunità open source hanno messo in atto un nuovo modo di produ-zione: nell’immaginare, disegnare e realizzare una soluzione si coopera tra persone, che vivono e lavorano in luoghi geografici diversi, la comunità si allarga continuamente ad altri attori che compartecipano nella definizione e realizzazione e molti di coloro che partecipano non percepiscono un ritorno economico per il lavoro che svolgono. È innegabile che questa è una novità assoluta nella produzione di beni non solo nel settore dell’Ict.

Se consideriamo il fenomeno open source un motore di distruzione creativa i suoi effetti vengono collocati nel loro ambito naturale: sta “semplicemente” nascendo un nuovo modo di fare business nel mercato del software.

Orazio Viele

FerentinoVII_06.indd 36 12/01/2009 11.01.56