Open Source e Standard

I progetti di sviluppo Open Source si fondano sul concetto di  sviluppo collaborativo  del sw.
Chi sviluppa, è chi è realmente interessato alle funzionalità implementate e per questa ragione tende a rispettare i tempi del proprio bisogno e a costruire attorno a sé una community di sviluppatori che ne condividano le necessità.
Come conseguenza di ciò, in un contesto di enorme dinamismo nelle esigenze di piattaforme infrastrutturali, un consorzio in cui siano fornite specifiche condivise (standard de-facto) tra tutti gli stakeholders di un bisogno (fornitori di servizi , fornitori di infrastruttura abilitante, vendor di sw e hw) non può che essere il contesto ideale per uno sviluppo dinamico e completo di queste piattaforme.

 

1 - Introduzione

Non c’è competizione interna: singolarmente nessuno degli stakeholders potrebbe garantire un completo sviluppo della piattaforma a misura del servizio e  l’adozione di specifiche standardizzate  consente la collaborazione e indirizza l’esigenza di clienti che, partecipando alla community, possono esercitare una funzione di controllo e di re-indirizzamento.
Un attento uso delle licenze permette di costruire meccanismi di  business validi per i vendor,  basati sulla fornitura di supporto, training, customizzazione per i singoli clienti, ma tutto nel contesto di un approccio WIN–WIN.
I grandi enti di standardizzazione come ETSI,  se ne sono accorti e vedono in queste community OS (Open Source) il luogo ideale dove avere implementate le proprie specifiche.  In certi casi si pongono addirittura nella condizione di costruire una community di sviluppatori OS loro stessi, attorno a specifici progetti critici.
Fondamentale però è la qualità del sw sviluppato,  le sua usabilità che devono essere garantite fin dall’inizio e i  processi  di assurance del sw, in modo da garantirne un suo immediato utilizzo in esercizio.

 

2 - Il sw Open Source come movimento di pensiero

Quando si parla di software “Open Source” si tende spesso ad associarlo al concetto di “Software Libero” (in inglese Free Software) e quindi a pensare a veri e propri simboli di quel movimento come Richard Stallman, o Linus Torvald.
In verità i due concetti, per quanto simili,  si basano su principi diversi.
Il software libero è un movimento sociale che si impernia una sorta di “imperativo etico” fondamentale: l’utente  deve essere “padrone” del sw, padrone  di eseguire il programma, di studiare il programma e di ridistribuirne delle copie con o senza modifiche.
Al contrario l'”Open Source” è fondamentalmente una metodologia di sviluppo; si focalizza su come "migliorare" il software con un approccio molto pratico che arriva alla conclusione che il software non libero non è una soluzione non ottimale.
Le ragioni che hanno portato Stallman a codificare la filosofia del “Free Software“ sono molto pratiche, essendo lui entrato in contrasto con i Copyright che negli anni  ‘80 del secolo scorso si andavano sempre più diffondendo per proteggere i produttori di sw e che impedivano di apportare utili migliorie a pacchetti, che lui doveva usare  (nel suo caso si trattava di codice per la gestione di stampanti).
Stallman considerò un “crimine contro l’umanità” queste restrizioni: non tanto il  voler far pagare per il sw, ma il negare agli utenti certe libertà considerate fondamentali, quali:

  • libertà di eseguire il programma come si desidera, per qualsiasi scopo (libertà 0);
  • libertà di studiare come funziona il programma e di modificarlo in modo da adattarlo alle proprie necessità (libertà 1). L'accesso al codice sorgente ne è un prerequisito;
  • libertà di ridistribuire copie in modo da aiutare il prossimo (libertà 2);
  • libertà di migliorare il programma e distribuirne pubblicamente i miglioramenti da voi apportati (e le vostre versioni modificate in genere), in modo tale che tutta la comunità ne tragga beneficio (libertà 3). L'accesso al codice sorgente ne è un prerequisito.

Invece, il software Open Source, si appoggia sulla definizione poi codificata dalla “Open Source Initiative” [nota 1] dove si afferma che il Software OS  è software che può essere liberamente usato, cambiato o diffuso (avendolo modificato o meno) da chiunque. Tutti possono sviluppare e distribuire sw OS, ma con delle licenze in accordo con alcuni criteri fondamentali:

  • distribuzione Libera del sw : la licenza non deve pretendere diritti d’autore o altri compensi per la vendita;
  • il codice sorgente deve sempre accompagnare gli applicativi ;
  • la licenza deve consentire di effettuare modifiche al codice e di distribuire i lavori derivati in accordo alla licenza del sw originale;
  • integrità del codice originale dell’autore: la licenza può porre dei vincoli alla distribuzione del codice originale modificato, ma deve consente di rilasciare delle patch che lo modifichino in fase di Build: si vuole preservare l’integrità del codice originale, senza impedirne la modifica attraverso componenti aggiuntive;
  • non ci deve essere discriminazione contro  gruppi o persone;
  • non ci devono essere discriminazioni di settori o imprese (ad non deve limitarne l’uso per fini commerciali o di ricerca);
  • distribuzione delle licenze: i diritti associati ad un programma si devono poter applicare a tutti;
  • la ridistribuzione del sw non deve limitare l’efficacia delle licenza originale;
  • il far parte di una distribuzione non limita l’efficacia della licenza: se il sw è preso separatamente, comunque i principi originali delle licenza continuano a valere;
  • la licenza di un pacchetto non può estendersi ad altri pacchetti distribuiti contestualmente;
  • la licenza deve essere indipendente dalla tecnologia nel senso che una particolare tecnologia (ad esempio l’obbligo di dare un assenso con il mouse in un box) non può limitarne la distribuzione

2.1 - OSS & IPR: contradizione? Il mondo delle licenze

La legge sul Coyright  viene usata di solito da un autore, detentore quindi della proprietà intellettuale sull’artefatto, per impedire  che un qualsiasi acquirente del bene possa riprodurre, modificare o ridistribuire il bene.
Tutto questo, come dicevamo, contrasta con il pensiero di Stallman che non nega il diritto ad avere dei ricavi dallo sviluppo di software, ma che fortemente sostiene il diritto di poter intervenire sul sorgente di un pacchetto acquistato per poterlo adattare alle proprie esigenze.  Si è diffuso quindi nel mondo Open Source il concetto di CopyLeft. Giocando sul significato dei termini, esso vuole sancire il diritto dell’autore a rinunciare al diritto di occultare il codice per garantire a tutti il permesso di riprodurlo, adattarlo e ridistribuirlo però, con la condizione che tutte le copie così ottenute siano legate alla licenza originale.
Nasce quindi il concetto di  “viralità” della licenza nel senso che se un pacchetto sviluppato ingloba componenti rilasciate sotto licenze “CopyLeft”,  se non si vuole incorrere in problemi legali, tutto il pacchetto deve ereditare quella licenza. Esempio la GNU GPL (General Public License) con cui sono distribuiti sw come lo stesso Linux o  Drupal un diffusissimo CMS o uno dei più famosi DB Open Source MySQL.
È possibile usare questo tipo di licenze virali in un contesto di Business?  Se l’obbiettivo è quello di fornire supporto all’installazione, configurazione, esercizio del pacchetto non ci sono problemi, ma nel momento in cui occorra intervenire con customizzazioni deve essere ben chiaro che lo sviluppo delle stesse per quanto retribuito, sarà  comunque soggetto alla stessa licenza e quindi il  sorgente dovrà essere reso disponibile.
Esistono licenze che però consentono una maggiore protezione del bene prodotto.  Forse il più famoso di questi esempi è la licenza Apache, che in sostanza consente intervenire sul codice, modificarlo e ridistribuirlo e poi includerlo in progetti chiusi. Chi non conosce il Web Server di Apache o  OpenStack, e ancora il nuovo OPnfv,? Tutti rilasciati sotto licenza Apache 2.0.

 

E’ chiaro che questa consente, oltre che quanto già indicato, anche di sviluppare codice che diventa proprietario ed è protetto.
Ad esempio si potrebbe voler sviluppare funzionalità che caratterizzano un servizio specifico sopra una piattaforma Open Source. E’ chiaro che rilasciare il sorgente, darebbe la possibilità a concorrenti di sfruttare lo sforzo implementativo  a costo zero per i propri servizi.
Comunque la valutazione della corretta licenza è strettamente legata al tipo di business che si vuole costruire, per cui l’aspetto fondamentale è la conoscenza esatta dei vincoli imposti dalle licenze che coprono i prodotti usati. Il tutto complicato dal fatto che in ambienti complessi,  spesso si devono integrare  componenti con diverse licenze che non necessariamente sono compatibili tra loro. Data la complessità della problematica, è sorto un business sulla validazione di pacchetti contenenti OSS. Un esempio è la BlackDuck [nota 2] che fornisce supporto a pagamento, ma anche una grande mole di informazioni del tutto gratuite.

2.2 - OSS e standardizzazione: fattore abilitante per il business

Un aspetto che non può essere trascurato al giorno d’oggi è l tempo di obsolescenza delle tecnologie, sia hardware che software. Questo ha come effetto la necessità di un continuo aggiornamento, con tempi che non possono che adeguarsi alle esigenze del mercato. Nel campo delle telecomunicazioni stiamo assistendo alla “softwarizzazione delle rete” e in generale alla nascita di un contesto in cui si vogliono sviluppare servizi digitali sempre più complessi dove collaborano  tanti partner, ciascuno per le proprie competenze specifiche e che portano alla erogazione di servizi E2E (in tempi brevissimi, in accordo con le esigenze di un mercato contingente e frenetico.
Non c’è più tempo di aspettare grandi Sw Vendor che con un flusso tradizionale sviluppino pacchetti a supporto dei servizi. Né è tempo di grossi investimenti per soluzioni che magari diventano obsolete prima di andare in esercizio. Occorrono metodologie nuove (Agili, DevOps ad es.) che contraggano i tempi di sviluppo. Ma quando si tratta di tecnologie radicalmente nuove, dove necessitano piattaforme articolate (il Cloud o la virtualizzazione della rete)  ecco che occorre sfruttare al massimo le sinergie, l’esistente, per rispettare i tempi imposti dallo sviluppo.
Il sw chiuso impone all’azienda di fare tutto da sola, ma il vecchio business non regge più.
Ecco allora che Salesforce rilascia soluzioni CRM contenenti pacchetti OS (Phoenix, Aura) e la stessa Microsoft porta .NET su GitHub (una Forge di sw  dove sono ospitati progetti e che mette a disposizione tutti gli strumenti per sviluppare codice in forma collaborative).

 

Il fatto di lavorare in un ambiente collaborativo di per sé non significa standardizzazione, ma quando i maggiori clienti di una determinata soluzione si mettono insieme per definire i requisiti di una piattaforma e i maggiori vendor di software e di hardware si uniscono per implementarla  (in Opestack ad esempio troviamo AT&T, HP, Oracle,  IBM, NEC, Huawei,  Cisco, EMC2, …),  è chiaro che verrà sviluppato uno standard di fatto,  che poi inevitabilmente ricadrà negli enti di standardizzazione che ne prenderanno atto.
Ma non solo le aziende, anche la politica ne prende velocemente atto, tanto che la Comunità Europea da anni st monitorando il fenomeno e ha sviluppato una strategia di adozione del sw OSS per il periodo 2014-2017 [nota 3].
Non è un caso che ETSI stia pensando a come affrontare le opportunità offerte dal SW OS,  caldeggiando la formazione di un progetto Open Source finalizzato a realizzare una piattaforma per la virtualizzazione delle funzionalità di rete  in linea con le specifiche sviluppate nello Study Group ETSI/NFV, ma dall’altro pensando a realizzare essa stessa un progetto che ospiti codice sviluppato per il progetto ONEM2M.  Ma anche altri enti, OMA ad esempio, sostengono lo sviluppo delle proprie interfacce in ambienti OS.

 

Figura 1 - La strategia della UE in tema di sw OSS

2.3 - Necessità di criteri di assurance per il sw OS

Uno dei problemi più critici nell’adozione di componenti OS  per soluzioni di Business critiche, sta nella possibilità di garantire un adeguato supporto all’esercizio.  Il sw deve essere di qualità, con un’adeguata community alle spalle, viva,  che sia in grado di implementare eventuali nuove esigenze e/o mantenere adeguatamente il codice esistente.
Occorre che i pacchetti di sw Open Source abbiano una sorta di “etichetta” che ne certifichi la conformità con certe specifiche che assicurino l’utilizzatore finale.
In quest’ottica ci si è mossi in ambito accademico dove era stato avviato un progetto OpenBRR    (BRR - Business Readiness Ratings) che ha pubblicato un WhitePaper [nota 4] con le indicazioni per un assessment del sw Open Source fatto sulla base di parametri che si sono evidenziati come importanti per la valutazione di un pacchetto Sw OS.
Questo progetto che comunque si fondava su precedenti esperienze, è stato poi inserito in un ambito più ampio: nel WG 2.13 di IFIP.
IFIP  è un organismo internazionale con una partnership consultiva con l’UNESCO, che rappresenta le comunità IT di 56 paesi. Riunisce più di 3500 ricercatori dell’Accademia e dell’Industria, organizzati in più di  100 Working Groups che riportano a 13 comitati tecnici.
Uno di questi WG il 2.13  nato nel 2004, è focalizzato sul sw OS e vuole investigare sulle tecnologie, le pratiche operative, di sviluppo di rilascio di questo software oltre che sulle dinamiche delle comunità di sviluppatori e sulle opportunità offerte alle Industrie e alla Pubblica Amministrazione nell’adozione di questo sw.
In generale però questo gruppo di lavoro, così come il Progetto OpenBRR possono dare indicazioni, linee guida, che consentano un assessment di un pacchetto OS, non è il loro ruolo quello di definire degli standard o dei “marchi di qualità”. Questo , d’altro canto, può essere fatto da quegli stessi enti,  come ETSI, che ne stanno comprendendo le potenzialità.
E’ quindi auspicabile una collaborazione che possa unire l’esperienza e le competenze in ambito accademico con la capacità ed il ruolo istituzionale di enti chiamati a definire degli standard a garanzia del consumatore sia esso un privato, una Industria o la Pubblica Amministrazione.

 

Conclusioni

In Telecom Italia non siamo rimasti a guardare: già dal 2000 era stato sviluppato dai colleghi di Tilab JADE (Java Agent DEvelopment Framework) - ,un pacchetto di middleware per lo sviluppo di  applicazioni ad agenti in accordo alle specifiche FIPA per sistemi intelligenti interoperabili.  Il pacchetto si propone di semplificare lo sviluppo di questi agenti e di garantirne l’adesione agli standard. Rilasciata con licenza LGPL, la piattaforma  è alla base di due altri pacchetti  WADE (aggiunge classi per supportare l’esecuzione di task a partire da workflow definiti) e  AMUSE (che si focalizza sullo sviluppo di applicazioni “sociali” dove vari utenti collaborano per raggiungere uno scopo comune – focalizzato sul on-line gaming multi-user ).
JADE  è stata utilizzata per sviluppare applicativi attualmente in esercizio: WANTS per l’attivazione di servizi ADSL  e Wizard per la gestione della forza lavoro dei tecnici Telecom Italia.
Qualche anno fa inoltre, era stata fatta un’indagine sull’utilizzo di sw OS all’interno dei nostri sistemi di gestione: erano stati censiti più di 700 componenti Open Source principalmente con licenza Apache (circa il 43 %),  ma erano anche presenti componenti  con licenza BSD (16%) e con licenza GPL e LGPL (ca 14%). Insomma un uso intensivo.

 

Figura 2 - Schema di JADE del sw Open Source

Oggi l’interesse per queste tecnologie è comunque vivo soprattutto nell’ambito del Cloud, dove si usa OpenStack e pacchetti associati; nel DWH è diffuso Hadoop di fatto il pacchetto di riferimento quando si parla di analisi di BigData. Hadoop è anche inglobato nella soluzione architetturale complessiva di Netezza di IBM. Infine una particolare attenzione va riservata la nuovo progetto Open Source  OPnfv, che vuole porsi come infrastruttura di riferimento per la NFV integrando tutti i pacchetti esistenti  in piena compliance con le specifiche ETSI.
Insomma il mondo Open Source è un mondo vivo, vibrante, che propone un nuovo approccio allo sviluppo di sw  e a cui le grandi aziende possono guardare come un’opportunità.
Su come poi sfruttare tali opportunità, adottando  in esercizio le soluzioni, le opzioni sono svariate.
Ci si può dotare di un forte dipartimento di sviluppo che prenda in carico  del tutto l’installazione, la configurazione, il supporto all’esercizio, e la customizzazione dei pacchetti Open Source. Questi gruppi diventano a tutti gli effetti degli esperti che possono anche collaborare attivamente allo sviluppo nella comunità.
Oppure ci si può appoggiare a terzi che svolgano queste mansioni,  magari qualche grosso sviluppatore all’interno della community OpenSource, attraverso cui si possono comunque veicolare esigenze specifiche.
In ogni caso non ci sarà più il timore  di  un lock-in sul vendor come era in passato sulle soluzioni proprietarie.

 


comments powered by Disqus