Visualizzazione post con etichetta applicazioni. Mostra tutti i post
Visualizzazione post con etichetta applicazioni. Mostra tutti i post

Il software open source: opportunità, rischi e possibili approcci

digital dreams Da anni assistiamo ormai ad un incessante dibattito sul mondo dell'open source, sui vantaggi concreti e le opportunità che esso presenta, non soltanto per le aziende, ma anche per i singoli utilizzatori finali.

La questione non interessa soltanto i soggetti privati, tanto che il Centro Nazionale per l'Informatica nella Pubblica Amministrazione (CNIPA) ha allestito un osservatorio che, nelle intenzioni dichiarate, è destinato a svolgere la funzione di catalizzatore della conoscenza e delle best practice in materia di open source nella P.A.

La stessa crisi economica mondiale rischia di riportare la problematica al centro della discussione: le caratteristiche di libertà, trasparenza e gratuità del codice a sorgente aperto sembrano infatti idonee a perseguire l'efficienza e la riduzione di costi che, generalmente, diventano un obiettivo proritario in tempi di ristrettezze economiche, senza che questo comporti una rinuncia all'utilizzo delle tecnologie dell'informazione e della comunicazione che, secondo l'opinione prevalente, rappresentano invece una delle principali soluzioni per risollevare l'economia dalla stagnazione.

Messa in questi termini sembra che la questione sull'opportunità di adottare il software libero non possa che risolversi positivamente ma in realtà, prima di giungere a questa conclusione, è opportuno fare una valutazione complessiva non soltanto dei possibili vantaggi, ma anche dei rischi potenziali e degli approcci adottabili.

Cerchiamo allora di fare chiarezza su questi aspetti.

Vantaggi nell'adozione di software open source

I benefici per una infrastruttura informatica aziendale sono riconducibili a:

  • risparmio sui costi della licenza e degli aggiornamenti;
  • interoperabilità con gli standard di settore;
  • eliminazione di ogni forma di dipendenza da un determinato fornitore che, a volte, si traduce in posizioni di debolezza contrattuale;
  • disponibilità del codice sorgente con conseguente possibilità di analizzarlo e modificarlo secondo le proprie esigenze (a patto di avere internamente delle risorse munite delle necessarie competenze);
  • qualità e sicurezza, soprattutto nei progetti supportati da un ampia comunità di sviluppatori in grado di correggere difetti (bug) o di migliorare continuamente il prodotto;

In aggiunta le software house possono trarre degli ulteriori specifici vantaggi dall'inclusione di software aperto all'interno del loro modello di business:

  • riduzione degli oneri economici di acquisto e gestione del software ed incremento degli utili connessi con la fornitura di consulenza e servizi connessi (installazione, manutenzione, formazione, personalizzazione, ecc...);
  • ricadute positive in termini di visibilità e prestigio;
  • libertà nel disporre del codice sorgente, di riadattarlo e modificarlo in modo da derivarne altri prodotti;
  • possibilità di avvantaggiarsi della spinta verso una veloce diffusione ed adozione di nuovi prodotti e caratteristiche che le licenze open generano;

Rischi o svantaggi

  • le licenze open non offrono le stesse garanzie di protezione degli utenti finali di quelle proprietarie: questa carenza intrinseca, se non bilanciata dalla previsione contrattuale di un apposito indennizzo, può esporre al rischio di violazione dei diritti di proprietà intellettuale o industriale di terze parti;
  • la mancanza di un supporto tecnico completo può riflettersi negativamente sull'affidabilità, la robustezza e la sicurezza complessive del prodotto, specie nei progetti non supportati da un ampia comunità;
  • alcuni tipi di licenza possono indurre il rischio cd. da contaminazione da OSS che si verifica quando, all'interno di un software che si vorrebbe mantenere proprietario (closed source), vengono incluse porzioni di codice libero soggette ad una licenza (es. la GPL) che costringe a rilasciare il prodotto derivato esattamente negli stessi termini di quello originario;
  • il risparmio sui costi della licenza è solo una delle voci che concorrono a definire il cd. TCO (Total Cost of Ownership) nel quale vanno, invece, comprese tutte le spese e gli oneri legati all'utilizzo presente e futuro del software (installazione, manutenzione, adeguamento dei sistemi, formazione del personale, personalizzazioni, ecc...);

Possibili approcci e rimedi

La cattiva notizia è che non esiste un approccio unico valido per tutti: per alcuni i vantaggi derivanti dall'open source possono essere superiori ai rischi e viceversa.

La buona notizia è che si possono adottare delle policies che prendono in considerazione gli scenari tipici e sviluppare delle procedure per gestire i rischi connessi.

Le aziende potenzialmente interessate all'adozione di software libero dovrebbero condurre un assessment tecnico-legale per ridurre i rischi connessi ad una violazione dei diritti di proprietà intellettuale ed industriale.

L'opportunità legata allo sfruttamento del modello di business dell'open source si pone, invece, soprattutto per le software house che realizzano proventi dalla fornitura di consulenza e servizi connessi, piuttosto che dalla realizzazione e commercializzazione di software.

In tutti i casi, però, una attenzione particolare deve essere riservata all'individuazione del tipo di licenza ed alla valutazione delle sue condizioni, tenendo presente che, se per il primo aspetto può essere vantaggioso ricorrere a software automatizzati, per il secondo è spesso consigliabile richiedere un adeguato supporto legale.

Photo courtesy: flaivoloka

Lo sviluppo del software: rischi e fattori che ne influenzano il successo

software development center La creazione di software è una attività complessa che si articola in più fasi ed abbraccia non soltanto aspetti tecnici ma anche organizzativi, come quelli relativi alla pianificazione e gestione delle risorse, di comunicazione e legali.

L'attività coinvolge almeno due parti - la software house (o il singolo sviluppatore) e il cliente - portatrici di interessi contrapposti che, volendo generalizzare, si riducono rispettivamente a:

  • massimizzare il profitto;
  • acquisire un prodotto che soddisfa le proprie esigenze, affidabile e sicuro, pagando il minor prezzo possibile;

Un aspetto, a volte sottovalutato, è che lo sviluppo del software, come del resto qualsiasi altra attività imprenditoriale, presenta dei rischi tipici che devono essere opportunamente bilanciati, anche in sede contrattuale, per non incidere negativamente sull'intero business.

Tutte le fasi più importanti di cui si compone il processo finiscono infatti per incidere, in modo più o meno rilevante, sui diritti e le aspettative delle singole parti e possono quindi avere un qualche impatto dal punto di vista legale.

Esistono però dei fattori in grado di inflluenzare negativamente il risultato o la qualità del prodotto finale, cui è bene prestare la massima attenzione:

  • specifiche poco chiare: il progetto è avviato sulla base di specifiche vaghe o prive di dettagli che generano fraintendimenti o false aspettative per una o entrambe le parti;
  • mancato coinvolgimento degli utenti finali: se l'interfaccia di comunicazione del committente, di regola costituita dal management, ha una idea soltanto vaga di ciò che effettivamente occorre all'utenza finale rischia di trasmettere delle informazioni erronee o non complete;
  • rischi di natura tecnica soprattutto nei progetti più grandi e complessi;
  • tariffe troppo basse o scarsa pianificazione: nell'intento di acquisire la commessa i dipartimenti commerciali delle software house partono, a volte, da considerazioni poco realistiche sui tempi e sui costi necessari per completare il progetto, con inevitabili conflitti nel momento in cui vengono prospettati costi aggiuntivi non previsti inizialmente;
  • carenza di controlli e/o di monitoraggio: il progetto viene condotto in totale assenza di verifiche periodiche, salvo poi dimostrarsi un completo fallimento quando si viene al dunque;
  • assenza di adeguate strategie di gestione del cambiamento (change management): il progetto evolve lasciando però le richieste di cambiamento non documentate, con conseguente confusione ed incertezza su ciò che deve essere implementato e sui tempi di consegna;
  • salari bassi ed elevato turnover: possono influire in modo sensibile sui tempi di realizzazione e sulla qualità complessiva del prodotto finale;

Che fare allora ? E' utile ignorare questi aspetti e fare finta che non esistano sperando che tutto vada bene ? Certamente no, mentre può essere adeguata una strategia basata su:

  1. una valutazione dei rischi tecnici, organizzativi, economici e legali che il progetto comporta per ciascuna delle parti, da condurre prima della negoziazione e della stipula del contratto ;
  2. un adeguato supporto legale e contrattuale fondato su clausole chiare e specifiche in grado di compensare i rischi percepiti nell'ottica di un equo bilanciamento degli interessi contrapposti delle parti;
  3. un monitoraggio continuo del progetto e delle sue fasi per individuare prontamente gli eventuali problemi o le questioni che possono insorgere;
  4. una gestione efficace della documentazione e dei cambiamenti;

Insomma, come accade in moltissime altre attività, è spesso sufficiente un minimo di pianificazione e controllo per evitare l'insorgere di problemi ben più seri !

Photo courtesy: a_kartha

Vincolare l'esecuzione di programmi

Spesso vi può essere l'esigenza di limitare gli effetti o le interazioni derivanti, a livello di sistema operativo, dalla esecuzione di programmi di dubbia provenienza/funzionalità o di applicazioni che, pur provenendo da una fonte abbastanza attendibile, interagiscono con ambienti caratterizzati da un certo livello di rischio (vedasi browser, email client, ecc...).

In questi casi una delle possibili soluzioni consiste nel creare degli ambienti vincolati all'interno dei quali circoscrivere l'esecuzione dell'applicativo/i.

Al riguardo esistono approcci differenti: alcuni limitano le interazioni dell'applicativo con le varie componenti del sistema operativo, sulla base di policies predefinite o comunque elaborate dall'utente finale. Generalmente questo è il principio di funzionamento dei cd. "behaviour blockers o HIPS (Host Intrusion Prevention System)".
A seconda del software vi può essere o meno una elevata granularità nel livello di definizione delle policies ma, comunque, occorre che l'utente abbia una consapevolezza sull'entità dei possibili rischi derivanti dalla esecuzione di codice sospetto.
Questo vuol dire che, se ad un applicativo viene erronamente attribuita una eccessiva capacità di interazione con il sistema, quest'ultimo ne può risultare irrimediabilmente compromesso.

Altre soluzioni, invece, cd. sandbox, permettono al programma la più ampia interazione con l'ambiente sottostante ma rendono inefficace qualsiasi modifica apportata al sistema preservando dunque l'integrità di quest'ultimo.

In quest'ultima categoria si colloca una soluzione software particolarmente leggera e gratuita chiamata Sandboxie.

Il funzionamento del software è molto semplice e si basa sull'interposizione di un'area di memoria transitoria tra il processo/i, eseguito/i nel contesto della sandbox, ed il filesystem sottostante così da rendere vane tutte quelle operazioni che comportano la modifica in scrittura del sistema.
Il programma si presta, in particolare, ad alcuni utilizzi specifici come l'analisi dinamica del malware oppure la predisposizione di un ulteriore "layer" di protezione relativamente alla navigazione su Internet, all'utilizzo della posta elettronica ed all'instant messaging.