Scegliere l’Open

120

Comprendere le dinamiche di creazione ed evoluzione di un progetto Open Source è fondamentale per valutare se l’investimento sia sostenibile

L’acquisto di soluzioni informatiche di norma avviene tramite un processo di procurement più o meno formale, che si basa sulle caratteristiche funzionali dei prodotti in commercio, spesso ottenute direttamente dal materiale promozionale del vendor o rese disponibili su report di benchmarking. L’offerta Open Source si sta espandendo a ritmi esponenziali – come risulta da una ricerca pubblicata alla fine del 2008 che mostra come ogni 14 mesi raddoppi il numero di programmi liberamente disponibili – ma solo un numero molto limitato di progetti ha dietro aziende in grado di fornire supporto e servizi di classe enterprise. Non deve stupire quindi che gran parte dell’offerta Open Source – che tanto interesse suscita in questi tempi di crisi – sia carente di fondi e quindi non possa permettersi le necessarie azioni marketing. In mancanza di informazioni già disponibili (whitepapers, brochure, ecc.) i potenziali utenti devono effettuare delle analisi in proprio, in modo da stabilire se un dato progetto presenti caratteristiche di maturità del codice, se la comunità che lo sviluppa sia solida e stabile, se sia facile contribuire o influenzare la roadmap. Comprendere le dinamiche che sottintendono il processo di creazione ed evoluzione di un progetto Open Source è fondamentale per poter valutare se investire nell’adozione di una determinata tecnologia open sia una scelta sostenibile. Se è vero che al momento del download tutti i progetti open sono “uguali” (gratuiti), un istante dopo quando si inizia ad investire risorse per valutarli, installarli, integrarli con applicazioni terze o estenderli, la scelta effettuata a monte sarà determinante ai fini del costo e del tempo necessari per adattarli alle nostre specifiche esigenze. Ma l’analisi di progetti Open Source si scontra con l’abbondanza e la sovrapposizione di forge che ne ospitano lo sviluppo (alcune migliaia, e non di rado un progetto viene spostato da un forge all’altro, rendendo difficile ricostruirne la storia con precisione), e con la difficoltà di aggregare e correlare informazioni disperse su strumenti di sviluppo, mailing-list e sistemi di bug-tracking. Per poter sfruttare l’intero panorama dell’offerta Open Source, occorre un metodo efficiente ed efficace per individuare programmi Open Source che siano robusti (codice maturo supportato da una community sostenibile), supportati (da un vendor o una comunità reattiva ed affidabile) e che possano evolvere (codice commentato e manutenibile).

Metodologie, repository e strumenti
Da oltre sette anni numerosi sono stati i tentativi di individuare risposte al problema della qualificazione e selezione di software Open Source, prima tra tutte quella elaborata da David Wheeler con la sua lista di programmi maturi e sicuri (GRAM/S, Generally Recognized As Mature/Safe). La lista, che conserva un carattere storico e non mostra i segni del tempo visto che tutti i programmi elencati sono ancora oggi utilizzati e manutenuti (Apache, Linux, OpenOffice.org, PHP, Samba ed altri ancora), ma purtroppo né l’ente che ne aveva sponsorizzato la creazione (MITRE) né altri organismi hanno deciso di mantenerla ed arricchirla, e quindi ad eccezione dei 41 programmi iniziali non ne sono stati più aggiunti. Successivamente fu introdotto l’Open Source Maturity Model (OSMM) elaborato da Cap Gemini nel 2003 e in un’altra forma da Navica nel 2004. Entrambi i metodi risultavano fortemente limitati dalla soggettività dell’analisi, che richiedeva appunto personale specializzato, e non ebbero molto successo. Seguì nel 2005 una iniziativa più formale, nota come OpenBRR, risultato della collaborazione tra l’università Carnegie Mellon, l’editore O’Reilly, Intel e la società SpikeSource, che non ebbe miglior fortuna probabilmente per l’onerosità del metodo, totalmente manuale. Nel 2006 Athos Origin elaborò un modello più completo, che alla data risulta l’unico di cui si ha evidenza pubblica del suo utilizzo. Benché tale modello offra plug-in e servizi web in grado di rappresentare le schede di valutazione e compararle anche grazie a tool grafici, occorre sottolineare come il metodo sia carente di tool che semplifichino la corretta attribuzione delle misure richieste. Tali metodiche inoltre differiscono significativamente non solo proceduralmente, ma anche nello scopo dell’analisi. Infatti laddove alcune si focalizzano sul codice realizzato e sugli aspetti organizzativi legati alla sua produzione, altre coprono estensivamente aspetti tecnici e funzionali. Per quanto le ultime prestino maggiore attenzione nel fornire indicazioni utili a qualificare i diversi indicatori, tali metodologie richiedono molto tempo per essere applicate, non sempre forniscono indicazioni univoche su come assegnare i valori agli specifici indicatori. Allo scopo di individuare il maggior numero possibile di “candidati” occorre effettuare un’attività cosiddetta di pre-selezione, identificando tra le piattaforme Open Source esistenti quelle che funzionalmente si ritiene possano rispondere alle proprie esigenze. Purtroppo soltanto SourceForge, il più vasto repository di codice Open Source al mondo, suddivide i programmi in base a determinate categorie software, mentre di solito per individuare i programmi occorre conoscere il loro nome. Esistono poi directory specializzati, come ad esempio Enterprise Open Source Directory che raccoglie esclusivamente programmi di classe “enterprise” o OSALT che elenca programmi Open Source alternativi a quelli proprietari, principalmente di tipo consumer. Purtroppo questi elenchi sono manutenuti da un ristretto numero di specialisti di settore, e quindi il numero di programmi elencati rappresenta solo una frazione di quelli esistenti. In tema di repository meritano una menzione CodePlex, per la sua vocazione open rivolta ad applicazioni e servizi in grado di funzionare su piattaforme Microsoft, Google Code per la vastità e la qualità dell’offerta, nonché le più importanti e famose fondazioni (Apache, Eclipse, ecc.).
Una volta identificati i candidati occorre recuperare almeno le seguenti informazioni:

Decidere la finalità d’uso del programma, in quanto l’utilizzo in ambito mission-critical o per la prototipazione determina filtri più o meno selettivi. Anche il tipo di utente finale (interno all’organizzazione, clienti, ecc.), le modalità di sviluppo (outsourcing, sviluppo interno, ecc.) e aspetti riguardanti la proprietà intellettuale (necessità di “brandizzare” il programma, distribuirlo con una licenza proprietaria, ecc.).

Verificare la notorietà, l’esistenza di libri e riferimenti a casi d’uso. Soprattutto in ambito enterprise è importante sapere se la tecnologia che si sta valutando sia attualmente utilizzata da sperimentatori (early adopters) o sia già utilizzata dalla maggioranza (early majority). Mentre l’esistenza di libri comprova una significativa maturità del prodotto, per i riferimenti ai casi d’uso occorre distinguere tra quelli prodotti dal vendor (o suoi incaricati) e quelli autonomamente realizzati da terzi indipendenti (utilizzatori, system integrator, ecc). Si osservi come anche articoli, studi ed altre fonti, nonché il numero di richieste effettuate su motori di ricerca siano un’importante misura del livello di notorietà raggiunto.
 

Qualificare la community ed i relativi processi. Verificare quanti sviluppatori partecipino alla community, quale sia il modello di governo adottato (aziendale, comunitario o basato su regole dettate da una fondazione), misurare la rapidità nella risoluzione dei bachi e quali siano i processi da seguire per la contribuzione di codice (contribution agreement, l’esistenza di tool per lo sviluppo, ecc.).
 

Verificare linguaggi utilizzati, commenti nel codice e licenza d’uso. Ogni programma richiede personalizzazioni o integrazioni con altre applicazioni, e quindi la scelta dovrebbe ricadere su applicazioni realizzate in linguaggi o framework noti, ben commentati e distribuiti con licenze d’uso compatibili con quelle delle applicazioni con cui si vuole integrare il programma.

 

Strumenti utili alla misurazione di metriche relative al software Open Source ne esistono molti. Da un’analisi dei tool prodotti o recensiti dai progetti finanziati dalla comunità europea in materia di qualificazione e selezione di software Open Source (EDOS, FLOSSMetrics, FLOSSMole, Mancoosi, Qualoss, QSOS, QualiPSo, SQO-OSS) risulta che ne esistono più di 60. Purtroppo nessuno di questi strumenti è pensato per costituire la risposta ultima alle esigenze di chi vuole utilizzare uno strumento pratico e veloce. La maggior parte degli strumenti infatti riguarda solo una determinata fase del ciclo di vita del software, anche se più recentemente si sono visti alcuni tentativi di realizzare un sistema in grado di aggregare i risultati provenienti dai diversi tool sono stati fatti (GlueTheos, Alithelia, Melquiades). Una volta qualificati i programmi, in maniera manuale o avvalendosi dei diversi strumenti disponibili, è possibile procedere con la selezione, concentrando gli sforzi relativi alla valutazione tecnico-funzionale – estremamente onerosa e indipendente dal fatto che il programma sia o meno Open Source – solo su quelli che presentano un adeguato grado di maturità, sostenibilità ed industrialità. Per selezionare i programmi in base ai criteri è possibile “filtrare” i risultati dell’analisi condotta utilizzando ad esempio strumenti come O3S, che consentono di specificare il peso dei diversi parametri e comparano in maniera grafica i risultati, facilitando la selezione.