Sommario: 2.1 – Introduzione ; 2.2 – Considerazioni sugli elementi salienti nell'analisi e valutazione di software open source
2.1 – INTRODUZIONE
Finora l' OSS è stato guardato con gli occhi degli iniziatori dei progetti open source, degli hacker, delle aziende che scelgono la via dell' OSS come proprio core business o parte di esso. Ciò che ora interessa è comprendere quali siano, in sede di scelta di software a servizio del business come gli ERP, i fattori che possano rendere gli OSS un'alternativa preferibile ai software proprietari, con particolare riguardo ai sistemi Enterprise Resource Planning.
2.2 – CONSIDERAZIONI SUGLI ELEMENTI SALIENTI
NELL'ANALISI E VALUTAZIONE DI SOFTWARE OPEN SOURCE
Sommario: 2.2.1 – Vantaggi e barriere di costo ; 2.2.2 – Qualità, affidabilità e sicurezza dei software open source
2.2.1 – Vantaggi e barriere di costo
Sia la FSF che il movimento Open Source hanno minimizzato l'importanza del costo quale motivazione di superiorità e preferibilità dell'OSS ai software proprietari: mentre Stallman sottolinea l'importanza di pensare “free speech” piuttosto che “free beer” quando si fa riferimento al software libero, e i sostenitori dell'Open Source enfatizzano la superiorità qualitativa di tali software piuttosto che fattori legati al costo, è ragionevole ritenere che gli utenti, in generale, possano essere attratti, almeno in prima istanza, dall'assenza di costi di
licenza. A livello di business, poi, svariate indagini condotte presso esperti IT
aziendali hanno confermato come l'elemento di costo sia un parametro di vitale rilievo in sede di valutazione dei software open source (Dedrick et al. 2006, Dedrick e West, 2006). Ciò non significa, tuttavia, che l'assenza di costi di licenza sia l'elemento cardine su cui tutte le aziende soppesano le alternative a loro disposizione (Morgan e Finnegan, 2007), e che essa da sola possa spiegare la diffusione dei software open source: molti software commerciali sono altrettanto gratuitamente scaricabili da internet (Gonzalez-Barahona, 2000). Piuttosto si deve notare come, rispetto a quanto previsto dalle licenze di copyright, nell'ambito di licenze open source non si possano richiedere pagamenti indipendentemente dal numero di download del software effettuati, e che chiunque possa utilizzare il codice corrente per dare vita a nuovi progetti (Gonzalez-Barahona, 2000). Spesso anche gli aggiornamenti e le versioni
successive del software sono gratuite, dunque non v'è necessità di sostenere
alcun costo in tal senso (Dedrick e West, 2006, Murray, 2010). Tutti questi elementi si traducono, in prima approssimazione, in una forte riduzione dei costi da sostenere in fase iniziale (www.accenture.com), cui consegue un ridotto rischio associato all'acquisizione e prova del prodotto; ciò aumenta inoltre le possibilità di rapida diffusione degli OSS presso la categoria-obiettivo di utenti50 (Krishnamurty, 2003).
Alla luce di quanto detto, è evidente che le organizzazioni interessate alla riduzione dei costi di licenza d'uso dei software proprietari, evitando anche eventuali responsabilità legali associate ad un loro utilizzo illegale nonché costi di aggiornamento e di passaggio a versioni premium, possano indubbiamente considerare gli OSS un'alternativa plausibile (Nagy et al., 2010). Ciò può rilevare enormemente qualora l'azienda, di piccole dimensioni, disponga di risorse finanziarie limitate, ma è altrettanto rilevante nell'ambito di organizzazioni di
50 Il carattere di “viralità” dei software open source è, a parere di Krishnamurty, uno dei maggiori punti di forza di questa tipologia di applicativi.
grandi dimensioni, laddove il costo della licenza d'uso sia proporzionale al numero di membri aziendali che diverranno utenti dell'applicazione (Glynn et al., 2005).
Tuttavia, sebbene la maggior parte dei software open source possa essere acquisita senza costi, ad esempio nel caso di download gratuito e diretto da internet, ciò non implica che il costo legato all'acquisizione ed utilizzo degli OSS in un'organizzazione aziendale sia trascurabile (Holck et al., 2004). E' opinione diffusa che, sebbene i costi associati agli OSS possano essere talora consistentemente inferiori rispetto a quelli associati ai software proprietari, i costi di breve periodo possano essere elevati, specialmente qualora ci si accinga non ad adottare una soluzione applicativa ex novo, bensì a sostituire l'applicazione attualmente utilizzata con una open source atta a fornire la medesima tipologia di funzionalità (Waring e Maddocks, 2005 ; Russo et al. 2003, etc.). Ad esempio, aziende che abbiano effettuato sostanziosi investimenti in software proprietari prima dell'emergere delle corrispondenti alternative open source, in caso di passaggio a questi ultimi si trovano a dover trascrivere tali costi tra i costi
“sommersi”, irrecuperabili (Nagy et al., 2010). Inoltre, specialmente per
applicazioni desktop, non è escludibile che il personale possa manifestare ostilità al cambiamento, in grado di ostacolare e rallentare il processo di apprendimento dell'utilizzo del nuovo software, con conseguente riduzione di produttività del capitale umano impegnato nella transizione (Russo et al., 2003). Quando poi in azienda si dispone di un'infrastruttura IT globalmente stabile e coerente, fatta di software proprietari, il passaggio ad elementi in disarmonia con l'architettura esistente potrebbe esser percepito problematico, e dunque sconveniente (Glynn et al., 2005). A tal proposito, ruolo notevole in sede di scelta del software può avere la sua compatibilità e complementarietà con strumenti hardware presenti o meno in azienda; a tal proposito vale la pena osservare, in primis, come colossi della produzione di hardware come IBM, HP e Oracle stiano supportando
attivamente lo sviluppo di software open source ritenuti strategici – Linux e Apache web server su tutti – per penetrare in nuovi mercati ledendo quote di mercato alla Microsoft51 (Fuggetta 2003 ; Waring e Maddocks 2005) e, in secundis, come sovente gli OSS siano progettati per adattarsi a molteplici piattaforme senza richiedere la sostituzione dell'hardware esistente; parlando di OSS ERP, poi, si osserva come la chiave del successo di alcuni di essi risieda nello sfruttamento del cloud computing, che evita alle aziende di doversi dotare di un database fisicamente ubicato presso i locali aziendali e ovviamente dispendioso: una volta scaricati da internet i moduli desiderati, le informazioni che circolano nel sistema vengono immagazzinate nel web cloud52.
Infine, un ostacolo, di tipo individuale e “personale”, all'adozione di software open source è annoverabile nella tendenza – anche inconscia – a giudicare la qualità di un prodotto dal prezzo che si paga per esso, tendenza che porta ovviamente a pensare ai software liberi come prodotti di qualità certamente inferiore rispetto ai concorrenti prodotti commercializzati a prezzi talvolta sostenuti53 (Glynn et al. 2005).
Un'analisi ad ampio spettro dei costi associati alle alternative di investimento in strumenti IT passa certamente attraverso una considerazione ed un tentativo di stima dei costi totali associati ad essi. Se è vero infatti che i costi iniziali di acquisizione di un software open source possono risultare inferiori in virtù del risparmio sui costi di licenza, è altrettanto vero che esistono altre voci di costo –
51 Finanziare lo sviluppo del web server Apache, per esempio, ha come scopo evitare che il web server http della Microsoft divenga leader (se non addirittura monopolista), decretando conseguentemente l'uscita dal mercato di tutti i server non-Intel. Emerge dunque il profondo intreccio tra mercato hardware e software, in cui la compatibilità risulta elemento-chiave per la sopravvivenza delle aziende operanti nel mondo dell'IT.
52 A tal proposito è bene fare due precisazioni: anche vendors di ERP proprietari come Microsoft hanno ampliato ed evoluto la propria offerta sfruttando il cloud computing, per cui ciò non è appannaggio esclusivo degli OSS ERP. Inoltre, Richard Stallman ha espresso forti sospetti per questa tipologia di software, mettendo in guardia gli utenti privati ed aziendali sul rischio associato alla scelta di custodire le proprie informazioni nel cloud. A chi appartengono quelle informazioni? Che cosa impedisce che in futuro, una volta installata una certa base di utenti, avvenga un'inversione di rotta che renda a pagamento l'accesso al cloud?
53 La tematica della qualità dei software open source, elemento di centrale importanza e fonte di un acceso dibattito, sarà oggetto di trattazione approfondita nei paragrafi successivi.
manifestantisi sia nelle fasi iniziali di acquisizione ed implementazione, sia successivamente a queste ultime – suscettibili di gravare molto più sulle finanze aziendali rispetto alla sola licenza d'uso del software. Il Total Cost of
Ownership (TCO) è un metodo di calcolo largamente diffuso presso le aziende,
atto a misurare il costo effettivo associato ad alternative di investimento; con esso si cerca di considerare tutti i costi associati ad un sistema IT lungo tutto il suo ciclo di vita, siano essi tangibili, direttamente riferibili al sistema, o confluenti in voci di costo pluricomprensive (quali i costi amministrativi e generali), o intangibili (Gonzalez-Barahona, 2000). Già nel 2002 uno studio condotto dal Gartner Group evidenziava come solo il 20% del TCO associato all' IT si manifesti nei costi iniziali di acquisizione, a scapito di elevati costi amministrativi successivi (David et al., 2002). In difesa dei propri prodotti commerciali molti vendor, primo tra tutti Microsoft, sostengono che il TCO dei software OS tende ad essere più elevato rispetto a quello dei software da loro distribuiti, in virtù di costi di passaggio e di mantenimento più elevati e della scarsità e/o della superiore onerosità del supporto esterno (Holck et al., 2004). Esaminando sommariamente le fasi del ciclo di vita di un software, la “fase zero” consiste nella preventiva individuazione degli elementi da sottoporre al processo valutativo, e si traduce nella raccolta di informazioni sulle possibili soluzioni disponibili sul mercato. Quando si considerano progetti open source, reperire informazioni sull'esistenza di componenti potenzialmente utili e validi, nonché sul loro grado di completezza e qualità, può risultare compito arduo e dispendioso in termini temporali (Gonzalez-Barahona 2000): le community OSS non hanno le risorse per pubblicizzare i propri progetti attraverso i tradizionali canali di informazione. Conseguentemente, le informazioni sull'esistenza e lo sviluppo di nuovi prodotti OSS si diffondono principalmente attraverso meccanismi di passaparola, perlopiù via internet. E se ciò da un lato si dimostra efficace nella costruzione di consapevolezza presso gli sviluppatori e gli utenti tecnici, dall'altro rende più difficile la diffusione di conoscenza e l'accettazione di
questi prodotti presso una vasta massa di potenziali utenti finali (Krishnamurty, 2003). In ambito aziendale, spesso le organizzazioni non sono neppure a conoscenza dell'esistenza di applicazioni open source di rilievo per la loro attività, per cui ripiegano su soluzioni “tradizionali”: tale esiguità o inesistenza
di marketing a supporto di molti progetti open source si rivela essere una vera
e propria barriera di tipo “cognitivo” alla loro diffusione (Nagy et al., 2010). Spesso non esistono neppure archivi di documenti da cui apprendere informazioni relativamente alle funzionalità e caratteristiche dei software liberi. Tuttavia, la penuria informativa è in qualche misura controbilanciata dal fatto che le informazioni reperite sui progetti open source, per quanto scarse o non organicamente organizzate possano essere, sono più realistiche di quelle con cui vengono pubblicizzati i software proprietari, dal momento che la disponibilità del codice sorgente, la semplicità con cui si possono effettuare dei test sul programma (spesso è possibile scaricare il programma da internet per provarlo) ed il contatto diretto che si può avere con la community dedicata al software sono elementi che riducono sensibilmente il rischio di fenomeni di sopravvalutazione delle potenzialità e sottovalutazione e omissione dei limiti e dei difetti, tipici delle informazioni commerciali (Gonzalez-Barahona 2000; Noyes 2010). Il software prescelto dall'azienda, qualora open source, può essere acquisito gratuitamente, senza sostenere alcuni costi per-copia o per-utente; anche la personalizzazione del software, secondo Gonzalez-Barahona, può avvenire ad un costo inferiore, avvalendosi del supporto della community di programmatori e della possibilità di lavorare in prima persona sul codice sorgente. Le grandi
opportunità di personalizzazione, per adattare il prodotto a specifiche esigenze,
elemento cardine su cui potrebbe basarsi la preferenza verso software open source come gli OSS ERP (Serrano e Sarriegi, 2006; Nagy et al., 2010), oltre a poter porre problematiche di compatibilità con altre piattaforme esistenti (van Wendel de Joode e Egyedi, 2004; Russo et al., 2003) comportano un'aumentata complessità associata all'implementazione dell'applicazione (Gonzalez-Barahona,
2000); inoltre è più che ragionevole aspettarsi che le organizzazioni, nel momento in cui decidano di implementare software complessi e che necessitino di personalizzazioni e/o di essere integrati con piattaforme esistenti – e rientrano palesemente in questa categoria i software gestionali – non possano o non vogliano, per motivi legati a scadenze temporali o alla necessità di un controllo maggiore del processo, affidarsi al solo aiuto dei volontari della community. Un fattore altrettanto influente a tal proposito è la presenza o meno di personale
interno dotato delle competenze necessarie per procedere alla
personalizzazione autonomamente: specialmente quando si parla di sistemi complessi come un ERP, spesso in azienda non si dispone di risorse umane adatte allo scopo a cui affidare l'intero processo di personalizzazione ed implementazione (Glynn et al. 2005 ; Waring e Maddocks, 2005). Coerentemente con quanto appena osservato, una delle preoccupazioni maggiori per gli utenti, specialmente a livello corporate, pare risiedere nell'assenza di un soggetto che
possa esser contattato per risolvere eventuali problemi o ritenuto responsabile per essi (Guth 2006, Waring e Maddocks, 2005). Ecco dunque che
il free software manifesta i primi esborsi per il pagamento di esperti
informatici o società di consulenza designate responsabili per l'ottimale
implementazione ed eventuale personalizzazione del software; talvolta questi soggetti sono difficili da trovare – specialmente quando si chiede un intervento su un software poco diffuso o conosciuto – e dispendiosi per l'azienda. Uno studio condotto dal Gartner Group nel 2004 aveva riscontrato che gli aumenti dei costi per servizi e per la gestione dei software open source spesso eccedono i benefici ottenuti attraverso il risparmio sui costi di licenza; tuttavia, studi di questo genere forniscono risultati assai divergenti tra loro, a seconda della tipologia di software presi in considerazione e delle caratteristiche settoriali ed organizzative delle aziende oggetto di indagine (Waring e Maddocks, 2005). La maggior parte dei confronti tra sistemi aperti e chiusi ha preso in considerazione i capisaldi di successo del baluardo open source, primo tra tutti il sistema operativo Linux
(Akmila F. , 2008). Non tutti i software richiedono elevati costi per servizi e amministrativi, ed esistono programmi i cui costi di licenza pesano per ben più del 20% annoverato da David et al. (2002) come percentuale sul totale dei costi associati al ciclo di vita di strumenti IT, e gli ERP ne forniscono un valido esempio: le licenze d'uso di sistemi ERP distribuiti con copyright comportano costi di licenza che possono superare anche il 30% dei costi totali connessi al progetto (Serrano e Sarriegi, 2006). Sebbene attualmente i tempi d'installazione risultino essere mediamente più contenuti con i software proprietari – probabilmente in virtù di consolidati schemi e strategie d'installazione attuati dai vendor (Gonzalez-Barahona, 2000), nonché del fatto che spesso questi software vengono venduti “out-of-the-box”, senza particolari richieste di customizzazione – altro punto a favore dei software open source è ravvisabile nella sua maggiore
scalabilità (Gonzalez-Barahona, 2000), elemento che diviene importante
qualora si considerano aziende che vogliono implementare un ERP in grado di accompagnarle in prospettiva di una crescita dimensionale.. Altro elemento- chiave risiede nella “compatibilità” del nuovo software con le capacità e conoscenze attualmente possedute dalle risorse umane che dovranno utilizzare il nuovo strumento in azienda (Dedrick e West, 2004): qualora insufficienti o inadeguate, è necessario formare il personale all'utilizzo di tali applicativi, e ciò, ovviamente, rappresenta un ulteriore costo associato all'implementazione del software, costo che sarà più elevato qualora il nuovo software vada a sostituirne uno già inserito in azienda (Russo et al., 2003). Tuttavia, questo vale indipendentemente dal fatto che il nuovo software sia proprietario oppure open source. Un vantaggio – seppur limitato – a favore degli OSS è dato dalla
possibilità di verificare, mediante la lettura del codice sorgente, quegli aspetti su cui la documentazione è esigua. D'altro canto, i produttori di software proprietari tendono a creare processi di formazione su larga scala, documentazione esaustiva e materiale didattico facilmente reperibile per
progetti di creazione di documenti sono iniziati solo pochi anni fa, e in generale non producono ancora documentazione paragonabile, per completezza e qualità, a quanto fatto dai concorrenti “proprietari”. Tuttavia, poiché un numero crescente di aziende sta aderendo al movimento open source, anche questo elemento sta cambiando: numerose società di consulenza informatica (e numerosi consulenti informatici indipendenti) stanno facendo della fornitura di servizi di formazione del personale e supporto in fase di implementazione di tali software il proprio core business o un ramo di esso54 (Serrano e Sarriegi, 2006). Nel lungo periodo, dunque, è difficile pronosticare sostanziali differenze nei costi di formazione del personale tra software open source e closed source. I costi associati al mantenimento e all'utilizzo ordinario del software, una volta conclusa l'installazione, non risultano, alla luce di quanto osservato finora, definibili univocamente più o meno elevati rispetto ai software closed source; Raymond, parafrasando quella che ritiene essere la ratio alla base del modus operandi di Linus Torvalds nella gestione del progetto Linux, osserva:
“Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.”
[The Cathedral and The Bazaar, p. 8]
In altri termini: poiché il codice sorgente è liberamente accessibile a chiunque, è statisticamente molto più probabile che problemi nel codice sorgente vengano individuati e risolti più rapidamente, a differenza di quanto accade per i software proprietari, ai cui codici possono accedere solo un numero molto ristretto di programmatori, alle dipendenze della software house. E, poiché il tempo è denaro, non v'è dubbio che il supporto della community nella risoluzione di bug e
54 Le compagnie produttrici di OSS ERP spesso instaurano una rete di partnership con consulenti e società di consulenza, “certificati” per la fornitura di supporto alle aziende che vogliano implementare i loro prodotti.
problemi con il software possa tradursi in un notevole risparmio di costi.
In sede di calcolo del TCO, la fase di abbandono di una determinata tecnologia o di transizione ad una nuova soluzione viene spesso sottovalutata, poiché l'abbandono di una tecnologia non è, per definizione, parte dell'utilizzo della tecnologia stessa. Tuttavia, questo elemento merita una particolare attenzione nel mondo dell' ICT, dove il progresso tecnologico avviene a ritmo sempre crescente. Aver scelto una soluzione open source può certamente rivelarsi positivo in questa fase, poiché è possibile creare codici sorgente temporanei per facilitare la transizione; gli OSS possono generalmente essere importati e adattati a nuove architetture, e i dati possono essere letti e tradotti in nuovi formati (Gonzalez- Barahona, 2000). E tutto ciò senza trovarsi alla mercé di un unico vendor55, bensì avendo la possibilità di occuparsi autonomamente della transizione, di rivolgersi alla community gratuitamente, o di scegliere consulenti informatici pagati allo scopo (e in quest'ultimo caso, meccanismi economici di base insegnano che, ove c'è concorrenza, i consumatori potranno godere di prezzi più vantaggiosi rispetto a situazioni in cui il potere contrattuale è tutto nelle mani di un fornitore monopolista).
In conclusione, è possibile affermare che il confronto tra i TCO di un software proprietario e di uno open source può avere esiti molto diversi, dipendenti da svariati fattori riguardanti il soggetto che si trova ad effettuare la valutazione (dimensione aziendale, settore, disponibilità di risorse finanziarie etc.) e la tipologia di software presa in considerazione: un ERP presenta, nelle varie fasi del proprio ciclo di vita, costi ben diversi rispetto, ad esempio, a quelli di un sistema operativo. In ogni caso, l'elemento caratterizzante gli OSS – alias l'accesso al codice sorgente – può risultare indubbiamente vantaggioso in sede di
55 Per una disquisizione su alcuni aspetti microeconomici relativi al vendor lock-in, si veda il paragrafo 1.2.3 del presente lavoro.
acquisizione e personalizzazione del software, di risoluzione dei bug e di transizione a nuove soluzioni (Gonzalez-Barahona, 2000). Inoltre, pare che venga considerato elemento ad alto valore aggiunto la libertà di scelta che, in generale, riguarda il software open source: assenza di lock-in con fornitori, libertà di scegliere come portare avanti la personalizzazione ed implementazione (Dedrick e West, 2006)
2.2.2 -‐ Qualità, affidabilità e sicurezza degli Open Source Software
L'affidabilità e la sicurezza sono punti di fondamentale importanza in sede di valutazione di software che diverranno portatori delle informazioni e dell'operatività ai vari livelli aziendali. Quando poi si tratta di scegliere la soluzione applicativa cui affidare l'intero funzionamento – o il funzionamento di operazioni vitali – dell'attività aziendale (come nel caso dell'introduzione di un software ERP), il sistema deve essere strutturato per ridurre al minimo il rischio di bug che comporterebbero, nel migliore dei casi, rallentamenti nell'attività aziendale, nel peggiore dei casi la perdita di dati; inoltre ci si aspetta che il sistema sia progettato per non essere vulnerabile a tentativi esterni di violazione della sicurezza delle informazioni.
Esiste un forte interesse pubblico nel comprendere se l'accessibilità al codice