Gnu, il libero sistema Unix “Gnu is Not Unix”, è nato nel 1983. Il progetto Java è partito nel 1991. Dai tempi di Richard Stallman e James Gosling, i due rispettivi “padri”, le Comunità Open Source Software (Oss) si sono moltiplicate; nel “radar” delle tecnologie nascenti ne appaiono costantemente di nuove; schiere di “artigiani” e di “fornitori” si radunano attorno ai Common asset. Ricerche Forrester e Gartner alla mano, viene definito ormai maturo il tempo per l’utenza aziendale di guardare seriamente al trend da parte dell’offerta (l’ecosistema fornitore Comunità, vendor, Isv, Service Provider) di progressivo “unbundling dal software” dei servizi indotti dal software stesso.
La proposta di valore delle componenti Oss è ormai maturata attraverso varie fasi. Non tutta la domanda (l’ecosistema fruitore) ha preso coscienza di un equilibrio dinamico di mercato in cui il software open guadagna terreno su quello proprietario, quantomeno nelle aree più basse dello stack software, in particolare laddove risuona più frequentemente la parola “commoditizzazione”. Quando parliamo di open ci riferiamo all’intero sviluppo software, requirement compresi, non al solo sorgente, implicando che la produzione è un “perpetuo beta” cui si aggiungono nuove funzionalità quando richieste e testate.
Vero tutto questo, è giunto il momento, per gli utenti, di definire una consapevole economia di approvvigionamento fra i due modelli di business per il software, quello basato su licenze e servizi (software proprietario) e quello basato sui soli servizi (software open). Serve darsi criteri e best practice di adozione differenziata e controllata, prevedendo di acquisire anche codice open source, piuttosto che subirne una inconsapevole quanto inesorabile “infiltrazione”, evitando sorprese e infortuni. Vedremo una vittima illustre, su tutti: Cisco, anno 2003.
Le fasi di maturazione dell’ecosistema fornitore
Ci sembra utile partire con una retrospettiva sul fronte dell’offerta. Una carrellata che articoliamo in quattro fasi ponendoci, in questo inizio 2010, a un certo punto della terza fase. La prima fase è stata di contrapposizione radicale fra le libere Comunità, fatte esclusivamente di “artigiani” che si venivano raccogliendo intorno ai primi Common e i vendor schierati a difesa della proprietà intellettuale e del modello di business commerciale.
La seconda fase parte a metà anni ’90 con la comunità Java: Sun apre la strada ai vendor che si associano alle Comunità per collaborare ai Common. La tendenza si rafforza agli inizi del 2000 con sponsorizzazioni sempre più importanti alla comunità Linux. Si crea una contrapposizione fra vendor di sole licenze proprietarie (Microsoft) e vendor alleati con Comunità che puntano a un business ibrido fra i due modelli “close” e open source (Sun in testa, Ibm, Novell).
Chi più chi meno, i vendor sono spinti verso l’attuale terza fase in cui l’ambiente It diventa sempre più un ambiente misto. L’obiettivo è “esserci nelle sfide”: Cloud Computing e Dynamic Data Centre (tutti), interoperabilità (Microsoft), stack integrato (Oracle). Per non essere tagliati fuori dall’ambiente misto, i vendor “non possono non avere una proposizione Oss”, magari solo opportunistica.
Gartner (vedi figura 1) prevede una quarta fase (nel 2015) in cui i Megavendor (Ibm, Oracle/Sun, Microsoft/Hp, Sap) alzeranno il tiro strategicamente su uno sviluppo congiunto con le Comunità, integrazione e interoperabilità, componenti Oss in portafoglio, commercializzazione diretta.
Figura 1. Le strategie dei megavendor in ambito apen source.
Cliccare sull'immagine per visualizzarla correttamente.
Il valore di un componente open source
Sul versante della domanda, quali possono essere allora i criteri di valutazione di un componente Oss? Flessibilità, qualità, innovazione, economicità, comunicazione: Forrester snocciola questi cinque fattori cruciali, ciascuno col suo “controargomento” in termini di limiti e rischi indotti da controllare. Certo “davanti ai fornitori di software e di servizi indotti da Oss c’è tuttora una grossa sfida di comunicazione del valore del modello di business open source”.
– La flessibilità: un componente Oss è subito disponibile, zero è il tempo per negoziarne l’acquisizione. Contento lo sviluppo, che mette velocemente in linea un prototipo, contento il business per il time to market. Partita la produzione non c’è che l’imbarazzo della scelta fra service provider che competono fra loro per “adattare il supporto ai bisogni” (l’unbundling dell’Oss affranca dal comprare servizi che non servono). E la maggior parte delle componenti Oss è costruita su paradigmi mainstream come Java e Sql, conformi a standard. Controargomento: la “business continuity” dei service provider, che deve reggersi su un fatturato secondario (servizi indotti) e non sul primario (licenze). Ci sono i margini rispetto agli investimenti per fornire le risorse ad alto skill per supporto e manutenzione al cliente e per finanziare un R&D che garantisca la sopravvivenza a lungo termine? Tutte domande per i service provider Oss, che in più devono offrire adeguata formazione e presentarsi con partner locali.
– La qualità: per un componente Oss la qualità non dipende dal livello di ingegnerizzazione che si mette nelle risorse di un prodotto software (nelle Comunità Oss non c’è organizzazione commerciale che trae valore dal lavoro di ingegnerizzazione e di distribuzione di servizi; c’è il rischio di affidarsi alla “buona volontà” della Comunità). Ma è pur vero che dipende dalla popolarità: prodotti Oss con grandi numeri di utenti e contributori godono di una comunità open source attiva e sono sostenuti da un vendor affidabile. Negli Application Server, per esempio, il supporto convenzionale non è necessariamente migliore di quello Oss: gli utenti delle product line di Jboss (ormai di Redhat) hanno livelli di soddisfazione del tutto simili a quelli di piattaforme commerciali come Websphere e Weblogic (Forrester). Semmai è un’idea puntare alla “seconda ondata” di un componente Oss, quando la “popolarità” è affermata; anche in licenze commerciali l’affidabilità del supporto di un vendor è legata al raggiungimento di una sufficiente economia di scala. In più, i componenti Oss hanno rilasci legati alle funzionalità (soddisfacente livello di test), senza pressioni commerciali tipiche in un software a licenza, esposto a obiettivi trimestrali, che a volte ne “drogano” il release management.
– L’innovazione: più che essere motore di innovazione, l’Oss tende a produrre soluzioni in segmenti in via di commoditizzazione, tipicamente nei livelli più bassi dello stack, quale alternativa (vincente) alle soluzioni commerciali di grandi fornitori. Eppure l’innovazione basata sull’Oss fiorisce proprio là dove i progetti Oss dominano: nell’Integrated development environment (Ide) open di Eclipse, preferito dal 60% degli sviluppatori, proprio la market share dominante ha favorito una seconda ondata di innovazione, ben oltre lo scopo originario di un Open Ide. E la maggioranza delle università realizza le idee in forma di Oss. Spunta in conclusione l’ambiente It misto che si fonda su un ibrido di modelli commerciali e licenze open source: “vendor di suite di prodotti scopriranno che, a seconda della maturità della suite, alcune parti sono commoditizzabili, mentre altre restano in ambiente commerciale competitivo” (Forrester). È quasi una profezia: il 27 gennaio 2010 Larry Ellison, Ceo di Oracle, scandisce dal palco che “c’è un database molto popolare, non in competizione alla superfortezza Oracle Db, ma ad esso complementare: MySql”.
– L’economicità: a prima vista si direbbe che non c’è partita, Forrester invece è cauta: “L’economia di un componente Oss deve essere provata caso per caso”. Il Capex inizialmente nullo, lo stesso Capex e il Tco certamente bassi sull’arco della vita del prodotto, manutenzione e supporto simili una volta in produzione, assenza di lock-in con il fornitore non sono però tutto. Tra i controargomenti, Forrester segnala: il costo delle operazioni It, su cui pesano le risorse umane al 47%; casi frequenti di insufficienti skill per gestire infrastrutture open, con costi operativi più alti con prodotti Oss che con prodotti commerciali; non ultimo, il lock-in, evitato col fornitore, rispunta col service provider per infrastrutture oltre una data soglia di complessità. Insomma, non c’è che prendere bene le misure prima di scegliere: “il diavolo è nel dettaglio”.
– La comunicazione: alla fine va esorcizzato l’incubo del Cio di mettersi alla mercé di una sconosciuta Comunità Oss. Come influenzarla coi propri requirement per la prossima release? Quale incentivo hanno gli “artigiani” a lavorare per un dato cliente? Un approccio legittimo può essere, per esempio, reinvestire parte di quanto risparmiato sui costi di licenza, nell’assumere un bravo “artigiano” della Comunità. Si influenza così una Comunità con una leva anche più efficace di quanto si riesca a condizionare un megavendor con grossi contratti di manutenzione. In ogni caso è cruciale la comunicazione chiara e convincente da parte del vendor di com’è fatto il suo modello e come gli utenti possono influenzarlo.
Un'adozione solo tattica?
Il 2009, anno di recessione globale, ha imposto ai Cio di esplorare a fondo ogni strategia che tagli i costi e migliori la capacità di integrazione senza sacrificare la capacità di innovare. Lo dice un’indagine Forrester, conclusasi a febbraio 2009 (1.147 decisori sullo sviluppo software in aziende Usa ed Ue, grandi e Pmi fino a due o più dipendenti It). Il peso complessivo, da critico ad importante, che le risposte danno a questi tre obiettivi (costo, integrazione, innovazione) è del 94%. Un peso superiore a tutti gli altri, compreso l’obiettivo dichiarato di espandere l’uso dell’Open Source software che è solo all’8° posto, con un 63%.
Ma se allo stesso gruppo si chiedono le tecnologie software su cui si punta (a questo punto “si è puntato”) nel 2009, l’Open source software è primo: il 46% ha almeno un pilota, oppure l’ha implementato o lo sta espandendo, vedi figura 2.
Figura 2. Teconologie sulle quali gli utenti puntano.
Cliccare sull'immagine per visualizzarla correttamente.
Che cosa significa questo disallineamento tra obiettivi e scelte tecnologiche, insieme al fatto che ben il 33% dei rispondenti “non ha una policy formale di adozione dell’Oss”? Forrester lo legge come un segnale di un approccio pragmatico all’Oss: un componente Oss viene adottato non per sua validità intrinseca, ma se ritenuto utile ai fini di uno dei tre obiettivi dominanti (costo, integrazione, innovazione).
La maggioranza delle aziende sembra più interessata alla “gratuità” che alla “libertà” dell’opzione Open source. L’Oss è insomma una scelta tattica di basso livello, non una decisione strategica presa da executive informati e consapevoli. Il che preoccupa, perché se a una decisione tattica non sfuggono i vantaggi in termini di minor Capex, rischiano invece di sfuggire altri benefici meno immediati, ma soprattutto i rischi potenziali e i cambi strutturali richiesti per sfruttare l’Oss appieno. Serve dunque definire una “concisa” policy open source, e di conseguenza reingegnerizzare il processo di acquisizione del software per la parte Oss.
Adozione tattica e i rischi della non consapevolezza
Ma da dove si infiltra, senza policy, nei team di sviluppo questo Oss adottato tatticamente e forse distrattamente? Primo, gli stessi Isv incorporano nei loro prodotti componenti Oss licenziate da Open source initiative (Osi). Jbuilder e Ibm Rational Application Developer usano Eclipse; Adobe LiveCycle Enterprise Suite incorpora Alfresco per l’Enterprise content management.
Secondo, vari systems integrator, Accenture, Bull, CapGemini, Engineering Italia, Unisys, nell’ambito di una loro dichiarata strategia di go-to-market, importano e supportano componenti Oss nei progetti on premise. Sicché il dipartimento It con un nuovo progetto si trova a mantenere una molteplicità di componenti Oss.
Ma in terzo luogo, gli stessi sviluppatori scaricano dal web. Ed è una valanga di componenti Oss, da cui alla fine nasce il lego di molti team di sviluppo. Fra gli strumenti di sviluppo: Apache Ant, NetBean di Sun, Eclipse, Hudson, CruiseControl, Subversion. E ai toolkit o piattaforme di sviluppo Oss che si possono scegliere (Hibernate, Protoype, Zend Framework) si accoda perfino Microsoft con Silverlight 2.0 e una “Microsoft Permissive License (Mspl).
Un’adozione solo tattica dell’Oss va corretta. Se non governata da policy e best practice mirate all’Oss, “porterà prima o poi a scoprire di ignorare l’estensione dell’uso di componenti Oss e di non riuscire di conseguenza a valutare il rischio potenziale cui si è esposti”. Forrester cita l’odissea in cui si trova tuttora (dal 2003) Cisco Systems col suo router Linksys Wrtg54: a rilascio avvenuto, Cisco scopre che componenti Linux sono stati inavvertitamente incorporati da un fornitore; si vede costretta a rilasciare l’intero firmware del router come Oss; il prodotto è molto popolare in rete, ma Cisco è ancor oggi in ballo con una causa di violazione della General Public Licence (Gpl) intentatale dalla Free Software Foundation.
Adozione strategica: capisaldi di una policy “concisa”
Il primo passo è allora identificare le condizioni alle quali l’uso dei componenti Oss è consentito nella propria azienda (siano esse considerate desiderabili o inevitabili) e specificarle in un Documento di Open Source Software Policy. Ecco le caratteristiche raccomandate da Forrester per la Policy: che copra le necessità di tutti gli attori coinvolti nei cambiamenti (tecnici o di business) indotti dall’Oss in un ambiente di sviluppo; ma che si focalizzi sugli sviluppatori, i più probabili importatori di componenti Oss; che dia loro direttive chiare e di base (per esempio tipi di licenze consentite, processi di approvazione, e in caso di violazioni come riportarle); che sia concisa e pratica.
In particolare serve classificare i componenti Oss per tipo di licenza open (non certo tutte le 72 licenze open source approvate dall’Osi, bastano tre-quattro tra le più frequenti, vedi figura 3) e per uso previsto. Per esempio, includere licenze tipo Gpl in un’applicazione potrebbe essere accettabile durante i test, ma rischioso in produzione. Perché? Perché Gpl è una licenza “virale”: si può distribuire se il software che la incorpora è reso disponibile sotto la stessa licenza. Per cui “rende Gpl” anche eventuali applicazioni inavvertitamente collegate, che magari sono proprietà intellettuale aziendale (e con effetti a scoppio ritardato, per esempio se l’applicazione era pensata per processi interni, ma tre anni dopo viene riciclata su un servizio esterno), che è poi l’infortunio capitato a Cisco. L’importante dunque è che la Policy trasmetta la consapevolezza dei rischi potenziali che si corrono con componenti Oss.
Figura 3. Le più comuni licenze open.
Cliccare sull'immagine per visualizzarla correttamente.
Reingegnerizzazione del processo di acquisizione del software
Il secondo passo è reingegnerizzare il processo di acquisizione del software prevedendo un percorso “differenziato” per l’acquisizione di componenti Oss o di prodotti commerciali. Beninteso serve anzitutto partire da una “casella n. 1” in cui il documento di Policy avrà sancito che il team di progetto valuti sia soluzioni basate su componenti Oss sia equivalenti opzioni commerciali. Primo elemento di valutazione il Tco in entrambi i casi, ovviamente su un periodo di più anni, idealmente sul ciclo di vita previsto, includendo tutti i costi annuali fissi o eventualmente variabili, obbligatori od opzionali, di licenza, supporto, training, e upgrade, comprendendo tutte le opzioni o i corequisiti.
Sempre alla casella n.1 converrà in secondo luogo confrontare il grado di copertura di scalabilità, accessibilità, affidabilità, mantenibilità, estensibilità, portabilità e sicurezza. Ogni copertura a 360° ha un prezzo, e per una data applicazione, se per esempio non è mission critical, può convenire una componente Oss che sia “good enough”. Ma per il resto della valutazione, tra soluzione commerciale e soluzione basata su componenti Oss, bisogna riconciliare tempi tra loro diversi di definizione dei requirement, verifica e validazione della soluzione acquisita (l’Acquisition requirement management o Arm). Per la soluzione commerciale, dati i tempi (settimane o anche mesi) di una licenza di valutazione serve un tipico “waterfall”, con l’Agreement management che parte alla fine del processo, vedi figura 4.
Figura 4. Processo tradizionale di acquisizione del software.
Cliccare sull'immagine per visualizzarla correttamente.
Per la soluzione Oss serve invece che il processo di acquisizione sia subito affiancato da un Arm, vedi figura 5.
Investire in questo processo di acquisizione differenziato è anche una mossa vincente nei confronti dei fornitori. I quali sanno quanto sia difficile per un ambiente di sviluppo abituato a negoziare solo software commerciale svincolarsene per convertirsi a Oss. Ma una volta organizzato un processo di acquisizione differenziato, ci si può attendere che diventino molto più flessibili gli accordi di pricing, specie se si è in grado di quantificare “quanto un’alternativa Oss è ‘good enough’ in termini di performance e time-to-market”.
Figura 5. Processo ideale di acquisizione di software open source.
Cliccare sull'immagine per visualizzarla correttamente.
