Dott.Rabellino, lei fa parte da diverso tempo della Apache Software Foundation. Qual'è la sua visione sul panorama OS attuale? L'Open Source ha ormai raggiunto una dimensione pervasiva, e ha radicalmente cambiato il mondo del software. Gli analisti sono concordi nel definire l'Open Source un fenomeno di lunga durata e, a suo modo, di portata epocale. Personalmente ritengo che l'Open Source abbia avuto il successo che stiamo riscontrando in quanto rappresenta e cattura alcune peculiarità proprie del mondo del software, un mondo che è nato sulle basi della cooperazione e che è caratterizzato da valori non tanto legati alla ricerca (si potrebbe affermare che gli algoritmi sono già stati tutti scritti, o quasi), quanto nei servizi che lo circondano. Oggi un software è "migliore" perché è più semplice da usare e gestire, perché aggrega le migliori tecnologie, perché è meglio supportato o perché è più stabile, non perché la tecnologia di base è più avanzata: l'evoluzione verso il cosiddetto "software as a service" non fa che confermare come l'Open Source rappresenti oggi la soluzione più sensata per lo sviluppo di soluzioni che costituiscano la base tecnologica, sviluppate cooperativamente, sulle quali creare valore. E' lecito aspettarsi che questa tendenza sia destinata a crescere nel tempo, creando un mercato in cui le regole del gioco saranno sempre più legate al servizio e meno al prodotto.
La pervasività dell'Open Source comporta peraltro una serie di problemi. Innanzitutto bisogna capire che stiamo parlando di una definizione assolutamente orizzontale e trasversale, che cattura soltanto le modalità di distribuzione del software. Open Source in sé, quindi, non può rappresentare maggiore qualità o sicurezza del software, e il fatto che una certa soluzione sia distribuita mediante Open Source non la rende intrinsecamente migliore, dal punto di vista tecnologico, rispetto a una soluzione proprietaria. Quello che si può tranquillamente affermare è che l'Open Source pone le basi per una maggiore qualità, grazie alle caratteristiche che tutti conosciamo di libertà di modifica del codice, maggiore scrutinio da parte delle comunità e flessibilità nella distribuzione. Tutto questo però non può sostituire un processo concreto di valutazione delle singole soluzioni che verifichi la qualità e l'utilità di un dato software: la buona notizia è che questo processo, nell'Open Source, può essere in parte dedotto da fattori come la diffusione del software, la dimensione della comunità e la continuità nel tempo (tutti fattori facilmente verificabili), non dimenticando comunque che il codice sorgente resta disponibile e che la soluzione è tipicamente più semplice da valutare per chi possiede le necessarie competenze tecniche e di dominio.
Oltre la licenza, che garantisce l'apertura del software, occorre guardare con attenzione alla community alla base dello specifico progetto OS? Assolutamente. Oggi come oggi, viste le dimensioni del fenomeno Open Source, è sempre più evidente la necessità di creare categorie e tassonomie per definire meglio di cosa si sta parlando: non c'è un solo Open Source, esistono diversi modi di intendere il software aperto ai quali associare diverse caratteristiche.
Se intendiamo l'Open Source come da sua definizione letterale, ossia come modello di distribuzione del software, perdiamo molto del valore e dei vantaggi dell'approccio aperto. Un software senza sviluppo cooperativo, semplicemente "buttato al di là del muro" come dicono all'estero, ha tutto sommato una rilevanza molto relativa, in quanto non raggiunge quegli importanti obiettivi che vanno oltre al costo della licenza: scrutinio da parte della comunità, longevità del progetto, diminuzione della dipendenza da un singolo fornitore e possibilità di partecipare al processo di sviluppo.
Le community sono fondamentali, e sono il più prezioso strumento a disposizione di chi vuole adottare e misurare l'Open Source. Una chiara tendenza che sta prendendo forma è quella di chi parla di "Open Development" come meccanismo di produzione del software, proprio per distinguere all'interno della grande famiglia del software aperto quei progetti che sono sviluppati cooperativamente da quelli che si limitano a una mera "distribuzione open".
Spesso le Pubbliche Amministrazioni (PA) si trovano ad avere in casa diversi sistemi proprietari per risolvere altrettante esigenze. Nell'ottica di una maggiore integrazione ed efficienza dei sistemi informativi la PA potrebbe costituire delle community su tematiche specifiche, apportando un'elevata conoscenza sui requisiti e demandare ad altri soggetti la realizzazione tecnica delle componenti software. Il tutto adottando un "processo" OS. Alla luce della sua esperienza, quali sono le sue considerazioni su questo approccio? Lo ritiene ipotizzabile? Negli ultimi tempi si sta verificando una notevole proliferazione di soluzioni Open Source dedicate alla PA. Il problema che spesso si riscontra, però, è quello di una inutile duplicazione di sforzi e di un riuso praticamente nullo. Tipicamente ogni amministrazione realizza una gara, i partecipanti usano la parola magica "open source" per designare qualcosa che verrà realizzato appositamente per la gara in questione, alla fine dei lavori il codice viene depositato su un repository pubblico, ma di fatto non viene adottato da altre PA a causa della sua scarsa "duttilità". Di fatto quello che si verifica è la presenza di tanto codice, ma poca collaborazione.
Trovare una soluzione a questo problema non è semplice. Va innanzitutto considerato che quando si parla di software per la PA si entra in una logica di mercato e altamente competitiva, nonché di soluzioni specifiche spesso difficilmente riutilizzabili. La concorrenza sul mercato, poi, fa si' che non sia facile che aziende differenti collaborino tra di loro per sviluppare una base di codice comune. Questa non è altro che una riprova di come l'Open Source non accompagnato dall'Open Development rischi di essere svuotato di significato: uno degli assunti dell'Open Development è quello di avere una terza parte, neutrale, che gestisca l'evoluzione del codice. La presenza di una entità terza permette di mettere da parte molti dei problemi di competizione: si pensi a come giganti come Sun e IBM riescano a collaborare sui progetti della Apache Software Foundation pur lottando quotidianamente sui mercati.
In questo senso le soluzioni possibili vanno nella direzione di promuovere non solo e non tanto l'open source, ma anche l'open development e, per quanto è possibile, gli open standard. Questi sono i tre pilastri sui quali si può fondare una strategia Open Source per la pubblica amministrazione. In questo senso alcune possibili azioni potrebbero essere:
- realizzazione di una entità neutrale che non faccia solo da "osservatorio" o da "repository" ma per raggiungere risultati più significativi si proponga come parte attiva, aperta alla partecipazione dell'industria su basi paritetiche, e come proprietario della soluzione, in modo da sterilizzare il processo di sviluppo dagli interessi commerciali e dai problemi di competizione;
- diffusione di linee guida nella stesura di bandi di gara che premino non solo e non tanto l'Open Source ma anche e soprattutto il riutilizzo di soluzioni esistenti. Per quanto difficile da realizzare, un possibile plus potrebbe derivare dal fatto che sia una terza parte, diversa da chi ha per primo realizzato il software, a proporre la soluzione;
- creazione di una struttura aperta e collaborativa di definizione degli standard sulla base dei quali realizzare le soluzioni. Questa struttura intanto dovrebbe essere aperta a tutti gli interessati e operare secondo criteri estremamente pratici. Un processo che si è visto funzionare è quello del Java Community Process (www.jcp.org). Uno dei motivi alla base del suo successo, a mio avviso, è l'approccio pragmatico: gli standard che vengono pubblicati sono costituiti non solo da un documento di specifica (spesso opaco e sempre ambiguo) ma anche e soprattutto da un Test Compatibility Kit (TCK) e da una Reference Implementation (RI) tipicamente realizzata in Open Source. Il primo permette di certificare una determinata implementazione della specifica, mentre la seconda garantisce non solo la disponibilità di una soluzione, sia pure a livello di prova concettuale, ma anche una fondamentale fonte di disambiguazione rispetto alla specifica.
Come dicevo prima, il percorso non è semplice, ma la creazione di una struttura di questo tipo potrebbe essere estremamente efficace per la creazione di un marketplace per il software nella PA, basato sulle logiche "win-win" che caratterizzano l'Open Source.