giovedì 20 maggio 2010

L'Open Source che avanza

Siamo abituati a parlare di software Open Source installato sui classici pc, ma il perimetro di applicazione è molto più ampio e oggi ne porteremo due esempi.

Il primo è l'utilizzo di software libero a codice aperto negli smartphone.
Android, software Open Source di Google, è ormai un sistema operativo consolidato e in continua evoluzione come dimostrano i dati pubblicati proprio ieri da Gartner.
Infatti, se da un lato è vero che Google ha deciso di stoppare la vendita in proprio dello smartphone Nexus One, dall'altro la quota di mercato dei telefonini Android negli Stati Uniti ha superato per la prima volta quella degli iPhone di Apple.
Tralasciando i numeri, mi pare che la notizia sia una positiva conferma della bontà della filosofia.

Il secondo è il sodalizio che si sta creando tra due mondi che paiono molto distanti, ma così non sono: il mondo del software Open Source e il mondo dell'automobile.
Tutto questo grazie a Fiat brasiliana e ad un progetto denominato Mio.
Il progetto Mio infatti, rilasciato sotto licenza Creative Commons, è in pieno stile web 2.0 perché apre completamente le porte alla comunità on line per realizzare una concept car che si chiamerà appunto Fiat Mio e che sarà poi presentata al Salone dell'Auto di San Paolo nel prossimo ottobre.
Cosa uscirà fuori da tutto questo delirio è presto per dirlo perché il sito è piuttosto complicato e aperto a tutte le idee, dalle più folli alle più concrete, ma se l'esperimento andrà a buon fine darà vita ad una nuova concezione di auto.

venerdì 16 aprile 2010

Legge regionale n. 9 del 26 marzo 2009

Torniamo a commentare la Legge regionale n. 9 del 26 marzo 2009 approvata dal consiglio regionale della regione Piemonte.

Poco più d'un anno fa il Consiglio della Regione Piemonte approvava una Legge che stabiliva: "... la Regione nella scelta dei programmi per elaboratore elettronico, privilegia i programmi appartenenti alla categoria del software libero e i programmi il cui codice è ispezionabile dal titolare della licenza." (art. 6 co. 2°).

Se da un lato la scelta veniva accolta con entusiasmo dai sostenitori del software libero, dall'altro la Presidenza del Consiglio dei Ministri, non avendo problemi più gravi ed urgenti di cui occuparsi, impugnava questa norma chiedendo alla Corte Costituzionale di dichiararla illegittima.

Se da un lato la Corte Costituzionale ha ritenuto, a ragione, illegittimo l'articolo 1 comma 3 di cui ho espresso il mio giudizio nel post precedente, ha altresì ribadito che la preferenza per il software libero è legittima e rispetta il principio della libertà di concorrenza.

In sostanza, secondo la Corte, preferire Software Libero non viola la libertà di concorrenza, in quanto la libertà del software è una caratteristica giuridica generale e non una caratteristica tecnologica legata a uno specifico prodotto o marchio: questa sentenza mette a nudo l'inconsistenza degli argomenti di quanti, fino ad oggi, si sono opposti all'adozione di norme che favoriscono il software libero argomentando che confliggono con il principio di "neutralità tecnologica".

Si potrebbe addirittura considerare questa sentenza come una sentenza storica in Italia nel suo genere.

Un'ulteriore riflessione deve essere rivolta al fatto che per sancire un diritto di scelta sia stata necessaria una sentenza della Corte costituzionale in risposta alle critiche di illegittimità del Consiglio dei Ministri.
Tali critiche risultano essere ancora più gravi se si considera il fatto che si sarebbero voluti imporre software proprietari e con costi elevati.


A corredo i link alla legge regionale e alla sentenza della Corte Costituzionale:






martedì 13 aprile 2010

Sviste e Sentenze

La Corte Costituzionale ha dichiarato illegittimo l'articolo 1 della legge regionale n. 9 emanata dal Piemonte il 26 marzo 2009, tale disposizione riguarda l'adozione e la diffusione del software libero e la portabilità dei documenti informatici nella pubblica amministrazione e, seppur affermando di voler garantire la diffusione del software libero, ne "dimentica" le caratteristiche.

All'articolo 1, comma 3, della legge bocciata si legge che "alla cessione di software libero non si applicano le disposizioni di cui all'articolo 171-bis della legge 22 aprile 1941, n. 633".
Un insieme articolato e incomprensibili di numeri, leggi e commi per stabilire che non si sarebbero dovute applicare le disposizioni della normativa nazionale a protezione del diritto d'autore.

E' grave, sopratutto per chi si interessa dell'argomento e vi legifera, confondere il software libero con un'assenza di diritti da parte dell'autore, arrivando a ritenere che una ridefinizione delle regole del gioco della proprietà intellettuale come quella effettuata dalle licenze open corrispondesse ad un'assenza di regole.

Le licenze Open Source non sono state quindi considerate vere e proprie licenze dimenticando e non riconoscendo, in pratica, il valore del fattore virale delle licenze di software libero, caratteristica che gli permette di rimanere tale anche nelle sue successive modifiche imponendo l'obbligo di ri-diffusione sotto la medesima licenza, e le altre disposizioni stabilite a sua tutela.

Eppure le controversie che chiamano in causa licenze Open Source crescono in numero esponenziale anche se spesso si concludono con un accordo tra le parti.
Altre volte assistiamo ad una condanna per la controparte che viola tali licenze (riconosciute quindi tali a pieno diritto).


Un caso concreto ed attuale è la condanna dell'azienda francese Edu4, condannata da una corte d'appello per violazione della licenza GNU GPL.

Nel 2000, infatti, Edu4 aveva equipaggiato diversi PC utilizzando una versione derivata di Virtual Network Computing (VNC) per consentire agli educatori di amministrare a distanza le macchine.

Tuttavia l'azienda non aveva rilasciato il codice sorgente del software modificati, come invece è previsto dalla GPL e come richiesto espressamente dall'associazione.
Nel 2002, inoltre, avrebbe messo a disposizione del codice che non corrispondeva alla versione installata nel 2001 e inoltre, secondo l'accusa, avrebbe modificato la licenza del programma cancellando il riferimento alla GPL e attribuendosi la paternità delle tecnologie libere VNC.

Questa sentenza riconosce la concretezza e la viralità delle licenze Open Source stabilendo inoltre che l'autore di un software libero non è l'unico ad avere il diritto di far valere il rispetto del diritto d'autore, soprattutto se di mezzo vi sono clausole di una licenza, che oltre al diritto d'autore chiama in causa le due parti, licenziante e licenziatario.

giovedì 25 febbraio 2010

Stati canaglia

La maggior parte delle persone, utilizzando esclusivamente il buon senso, pensa che il software open source sia una cosa buona.

Se non altro è un'opzione percorribile per chi non ha le risorse necessarie per entrare nel normale mercato commerciale.

Ci sono individui, però, che ritengono la filosofia open un problema. Un grosso problema, almeno per il business.

Andres Guadamus, appartenente alla facoltà di Legge dell'Università di Edinburgo, ha condotto una ricerca sull'argomento e ha scoperto che una potente lobby di industriali sta chiedendo al governo Usa di considerare l'open source come la pirateria, se non peggio.

La lobby in questione è la International Intellectual Property Alliance (IIPA), un gruppo di organizzazione che comprende anche la Motion Picture Association of America (MPAA) e Recording Industry Association of America (RIAA). Ebbene, la IIPA ha chiesto alla US Trade Representative di includere Paesi come Brasile, Indonesia e India nella "Special 301 watchlist". Per quale motivo? Perché suddetti Paesi usano software open source.

Per chi si chiedesse cos'è la "Special 301 watchlist" ecco una spiegazione per sommi capi: si tratta di un report che esamina "l'adequatezza e l'effettività dei diritti riguardanti la proprietà intellettuale" nel mondo. In altre parole, una lista di nazioni che il governo considera come "nemici del capitalismo".

La questione è, onestamente, inquietante. Ma c'è di più.
La IIPA motiva la richiesta di inclusione dell'Indonesia nella watchlist con le seguenti ragioni: "La decisione del Governo Indonesiano…semplicemente indebolisce l'industria del software e minaccia la sua consolidata competitività creando una preferenza per quelle società che offrono software e servizi open, anche se ciò nega l'accesso di aziende "legittime" al mercato rappresentato dagli enti pubblici.
Piuttosto che sostenere un sistema che premi la soluzione migliore, a prescindere dal modello di sviluppo, si incoraggia un punto di vista che non paga la dovuta considerazione al valore delle creazioni intellettuali.
In questo modo, il sistema non sprona il rispetto dei diritti riguardanti le proprietà intellettuali e, in più, limita la capacità del Governo e del settore pubblico di scegliere la soluzione migliore".

Se l'inclusione dell'Indonesia nella watchlist sulla base di queste argomentazioni vi sembra improbabile, ripensateci. L'IIPA è infatti riuscita a includere perfino il Canada.

E cosa dire della situazione italiana?
Il 16 febbraio è stato presentato alla camera dei deputati dal deputato Rocco Girlanda (PdL) un'interrogazione parlamentare che si propone di fare chiarezza sulle misure messe in atto dal governo ed in particolare dal ministro Brunetta riguardo all'open source e la pubblica amministrazione.

Si legge nell'interrogazione "[…] il Ministero della Pubblica Amministrazione e dell'Innovazione ha sempre avuto tra i suoi obiettivi l'aumento dell'efficienza della pubblica amministrazione e dell'aumento della fruibilità da parte degli utenti; questo presupposto passa attraverso la funzionalità dei sistemi informatici e digitali con i quali la pubblica amministrazione si trova ad operare"
"per raggiungere questi obiettivi è necessario valutare l'opportunità di adottare nella pubblica amministrazione software rispondenti ai principi di funzionalità, sicurezza, alleggerimento dei sistemi informatici, resistenza agli attacchi virali e cibernetici, riduzione della spesa per il costo delle licenze".
"[…] diverse istituzioni del nostro Paese hanno discusso e approvato la possibilità di migrare ad altro tipo di software salvo poi sperimentare e confermare questa linea di indirizzo, tra cui i comuni di Firenze (gennaio 2001), Lodi (marzo 2002), Roma (febbraio 2004), la provincia di Bolzano (prima nelle scuole e poi nella pubblica amministrazione, con un risparmio solo sulle licenze di oltre 1 milione di euro), decine di comuni in tutta la penisola nonché diverse regioni o enti come l'Istat"

A questi importanti esempi nostrani possono essere aggiunti esempi di migrazione conclusisi in maniera positiva come quelli di Svizzera (9.000 computer nelle scuole dal settembre 2008 e tutti i server governativi entro il 2010), Danimarca (diversi comuni dal febbraio 2002), Germania e Francia (Ministero degli esteri e parlamento dal novembre 2008), dell'Inghilterra.
Non vanno poi dimenticati il Governo del Brasile, della Russia o lo stato del Massachussets.

Tutto questo ci insegna che un cambiamento etico è davvero possibile sospinto dalla consapevolezza di un importante risparmio economico.

venerdì 29 gennaio 2010

Progetti: educazione scolastica e comunitaria

I prossimi post sono riferiti a progetti da proporre alle pubbliche amministrazioni per favorire lo sviluppo delle tematiche e dell'utilizzo dell'open source a beneficio della comunità.
Vorrei partire con una serie di proposte rivolte all'educazione scolastica e comunitaria.
  1. Fornire le scuole di computer dotati di software FLOSS o installarlo sulle postazioni già esistenti.
  2. Promuovere il mondo FLOSS presso le scuole organizzando corsi dopo scuola in cui i ragazzi possano utilizzare il computer per studiare e per fare i compiti.
  3. Organizzare concorsi rivolti ai ragazzi per stimolare l'utilizzo del software FLOSS e per raccogliere idee per nuovi progetti.
  4. Organizzare corsi e dibattiti per avvicinare la comunità al mondo FLOSS mostrando come si possano ottenere gli stessi risultati di produttività legalmente e con una spesa decisamente inferiore.
  5. Organizzare fiere, manifestazioni, tavole rotonde e raduni sul tema.

mercoledì 27 gennaio 2010

Metodologia di una migrazione

Ad esclusivo titolo d'esempio si prende in esame uno specifico problema di introduzione di sistemi FLOSS all'interno della PA: la sostituzione di una soluzione di Office Automation proprietaria con una soluzione interamente OS quale Open Office (OO).

Lo studio di una metodologia di introduzione di OO all’interno di un’Amministrazione pubblica è stata oggetto di parecchie ricerche e proposte; la struttura metodologica che segue prende spunto dall’ottimo lavoro svolto dalle Università di Bolzano e Genova.

L’Open Source offre nuove potenzialità ed è sicuramente un’opportunità da prendere seriamente in considerazione; ma la migrazione ai sistemi aperti è un processo complesso che deve essere effettuato con uno studio interdisciplinare e con molta attenzione e professionalità. La stessa letteratura rileva l’inefficacia di approcci “brutali” che si basano su una migrazione immediata su postazioni.

Ecco quindi che interviene la necessità di una metodologia studiata, chiara, e soprattutto non invasiva, che possa in un arco ragionevole di tempo portare a dati su cui ragionare in maniera consapevole per un’eventuale migrazione verso soluzioni aperte.

Scopo della metodologia è la realizzazione di un'analisi dei costi/benefici nel passaggio tra i sistemi proprietari e i sistemi aperti nella PA.

Il costo del passaggio non è calcolato solo in termini di costi diretti (licenze, formazione ed assistenza) ma anche in termini di costi indiretti (nuovo hardware, conversione dei vecchi formati, ecc.). Raccolti poi i vari dati si procederà al confronto tra la nuova (OS) e la precedente (Proprietaria) soluzione.

I dati sono raccolti durante 3 fasi individuabili della migrazione: la pre-migrazione, la migrazione e la fase di post-migrazione. I dati saranno estratti da interviste/questionari presentati a cadenze prefissate e attraverso strumenti di monitoraggio software delle macchine coinvolte nella sperimentazione.

Immaginando che lo scenario sia quello (molto plausibile) di tentativo di migrazione della soluzione proprietaria di Office Automation, basata su MS Office, verso una soluzione di tipo aperto basato su OO, in una fase preliminare si prevede l’organizzazione e la progettazione dello studio.

In particolare si dovrà:
  • produrre il piano esecutivo comprendente la definizione degli obiettivi, degli strumenti, delle metriche e la pianificazione delle attività;
  • determinare profili e quantità delle professionalità necessarie;
  • identificare un insieme di utenti adatti alla sperimentazione;
  • produrre il materiale informativo e didattico.
Fasi della migrazione
Nella fase di pre-migrazione verrà installato il software di monitoraggio sulle macchine del gruppo in modo tale da conosce le reali quantità di file prodotti e scambiati nonché le funzioni di MS Word più utilizzate. Sarà inoltre necessario realizzare interviste, questionari e osservazioni dirette del lavoro per fotografare la situazione nel gruppo di sperimentazione in termini di predisposizione alla migrazione e alla loro conoscenza dell’editor di testo. I dati raccolti in questa fase verranno poi messi a confronto con i dati finali delle altre due fasi per verificare se e in quale percentuale la produzione è diminuita o aumentata. La fase di pre-migrazione è di fondamentale importanza per la corretta analisi finale del sistema. In questa fase, infatti, è cruciale capire, anche grazie al software di monitoraggio installato sulle postazioni pilota, se il gruppo prescelto è un campione significativo dell’Ente, con probematiche mediamente rapportabili a quelle riscontrabili sul resto dell’utenza dell’Ente.

Nella fase di migrazione sarà necessario organizzare degli incontri per presentare l’iniziativa al gruppo prescelto nonché mostrare loro la similitudine di Open Office con MS Office. Nel contempo si dovrà provvedere all’installazione di Open Office sulle macchine del gruppo di sperimentazione.
All’inizio della vera e propria sperimentazione su ogni macchina sarà installato sia Open Office che MS Office. L’utente utilizzerà Open Office soltanto per sua volontà. Dopo qualche tempo si provvederà a far diventare l’editor di testo principale Open Office ma rimarrà facoltà dell’utente aprire i documenti in MS Office. Soltanto a tre quarti del tempo previsto di durata delle sperimentazione e solo per metà del gruppo verrà del tutto disinstallato Office. In periodi prefissati sono previsti questionari, interviste e incontri per analizzare l’impatto sociologico della migrazione e conoscere le impressioni degli utenti sperimentatori. Il software di analisi continuerà a monitorare le attività delle macchine.

Nella fase di post-migrazione, tutti i dati raccolti sia dal software che attraverso le interviste verranno analizzati e presentati i risultati. In particolare si andranno a calcolare i costi diretti e indiretti, i rischi e la produttività registrata. Al termine di questa fase sarà possibile capire se la migrazione che si vuole realizzare è un’attività che può essere portata a termine e con quali costi.

lunedì 11 gennaio 2010

Analisi di una migrazione

In questo capitolo si vuole affrontare il tema della migrazione da un software proprietario ad un FLOSS applicando la teoria del TCO.

Formalmente il Total Cost of Ownership si definisce come la somma di tutte le spese ed i costi associati all’acquisto ed all’uso di equipaggiamenti, materiali e servizi.

Generalmente il Total Cost of Ownership viene utilizzato a livello decisionale per valutazioni e confronti fra i costi che le possibili opzioni implicano, come strumento di budgeting per una mirata allocazione delle risorse e più in generale per stabilire strategie di prezzo e di mercato.

Di seguito si analizzano le macrovoci di cui tener conto in previsione di un investimento software in qualsiasi azienda e/o PA.

Pianificazione
L'avvio di un progetto comporta un periodo di pianificazione nel quale si stimano tempi, risorse necessarie, strumenti e costi.
Il personale interno all'azienda è generalmente affiancato da consulenti esterni, nella maggior parte dei casi appartenenti alle società che poi forniranno il software.
Questa prima attività comporta dunque costi connessi prevalentemente alle risorse umane impiegate.

Adeguamento dei sistemi
L'installazione di un nuovo software può prevedere modifiche al sistema esistente a livello hardware (moduli RAM aggiuntivi, dischi fissi più capienti, processori più veloci, ecc...), a livello di infrastrutture, a livello di software, dovendo aggiungere eventualmente programmi a supporto della nuova applicazione.
I costi dovuti a tali modifiche possono interessare il corpo centrale del sistema (server), ma anche tutte le unità degli utenti sparsi per l'azienda, con un aumento rilevante dell'esborso.

Efficienza operativa
Una scarsa efficienza operativa è fonte di elevati costi, si pensi al tempo perso per bugs del software, alla necessaria migrazione di files dal precedente standard al nuovo in caso di incompatibilità per i dati usati, a software con interfacce scarsamente intuitive o eccessivamente complesse, a tutte le procedure da reimpostare.
Una volta installato un software necessita dunque di una lunga fase di testing e rewriting, con conseguente utilizzo di risorse umane e hardware.

Training
Tutto ciò che riguarda costi di aggiornamento per utenti o insegnanti ex-novo, redazione di nuovi manuali d'uso e procedure per un corretto ed efficiente utilizzo dello strumento informatico.

Servizi
Riguardano la manutenzione del software da parte dell'azienda fornitrice con aggiornamenti ed interventi in caso di errori gravi o crash del sistema (quest'ultimo aspetto è importantissimo: un'azienda può perdere intere mattinate di produttività ed è quindi essenziale un servizio di ripristino quasi immediato).
In genere nel pacchetto software tali servizi sono garantiti, ma comunque a pagamento.

Aggiornamento del software
Qualsiasi prodotto software per quanto testato contiene errori o comunque necessità di perfezionamenti nel corso del suo utilizzo.
Anche questi aggiornamenti fanno in genere parte del pacchetto completo acquistato dal fornitore, ma sono a pagamento e talvolta il quadro dei costi può subire grosse modifiche a causa di questi interventi che possono anche essere molto frequenti, ma necessari.

Costi incidentali
Sono costi non direttamente imputabili all'installazione di un nuovo software ma agli utenti che ne fanno uso. Il fattore umano è quindi il cost driver di quei costi.
Un software fa parte di un sistema decisamente complesso come quello dell'azienda ed in esso operano tutti gli utenti connessi: si pensi a dati accidentalmente cancellati a causa di un utilizzo non consono del software o ad una semplice svista, oppure si pensi a macchinari che pur eseguendo in maniera corretta le istruzioni dettate dal software che li governa, commettono un danno materiale dovuto ad un suo errato posizionamento.