Il Free, Libre, Open Source Software In Emilia-romagna - 2008

3 eross

EMILIA-ROMAGNA OPEN SOURCE SURVEY

PIANO , TELEMATICO DELL EMILIA-ROMAGNA

IL FREE, LIBRE, OPEN SOURCE SOFTWARE IN REGIONE EMILIA-ROMAGNA

EROSS - Emilia-Romagna Open Source Survey IL FREE, LIBRE, OPEN SOURCE SOFTWARE IN REGIONE EMILIA-ROMAGNA

La redazione è stata curata da: Dimitri Tartari Si ringraziano per la collaborazione: Sandra Lotti, Francesco Rentocchini, Nicola Grassano, Roberto Zarro, Chiara Mancini, Fabio Bucciarelli, Alessandro Landi, Marco Rossi, Stefano Dalli, Paolo Patrono, Sandro Mazzotti, Luca Fusaro, tutti coloro che hanno volontariamente contribuito rispondendo al questionario EROSS 2008 nonché responsabili dei progetti del PiTER che hanno condiviso informazioni nell’ambito dell’indagine EROSS-PITER 2008. Avvertenza: gli autori del presente documento sono consapevoli della perfettibilità dell’opera ed a tal fine ne rendono disponibile una versione modificabile su http://www.regionedigitale.net/osservando/eross.htm affinché chiunque possa contribuire a migliorarne contenuto e/o forma. Completato in novembre 2008 Pubblicato in dicembre 2008 Copia del documento in formato digitale è disponibile all’indirizzo: http://www.regionedigitale.net/osservando Quest’opera è stata rilasciata sotto la licenza Creative Commons Attribuzione-Non commerciale-Condividi allo stesso modo 2.5 Italia. Fanno eccezione le sezioni che descrivono esperienze e casi d’uso che sono da ritenere non modificabili in quanto espressione dell’opinione personale degli autori. Per leggere una copia della licenza visita il sito Web http://creativecommons.org/licenses/by-nc-sa/2.5/it/ o spedisci una lettera a Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

PIANO , TELEMATICO DELL EMILIA-ROMAGNA

eross

, PIANO TELEMATICO DELL EMILIA-ROMAGNA

IL FREE, LIBRE, OPEN SOURCE SOFTWARE IN REGIONE EMILIA-ROMAGNA

Centro Regionale di Competenza per l'e-government e la società dell'informazione dell'Emilia-Romagna

Assessorato Attività produttive. Sviluppo economico. Piano Telematico Direzione generale centrale Organizzazione, Personale, Sistemi Informativi e Telematica [email protected]

Premessa.................................................................................................................................................................2

Indice

0

Capitolo 0: nozioni elementari ...................................................................................4 Le ragioni per l’adozione di FLOSS nella Pubblica Amministrazione............................6

1

Capitolo 1: il FLOSS nelle PA emiliano-romagnole................................................10 Metodologia di indagine e struttura del campione ..........................................................10 Analisi descrittiva............................................................................................................................14 Analisi avanzata ...............................................................................................................................41

2

Capitolo 2: Il FLOSS nei progetti del Piano telematico dell’Emilia-Romagna (PiTER) ......................................................................................42 Metodologia di indagine ..............................................................................................................42 Analisi descrittiva............................................................................................................................42

3

Capitolo 3: esperienze e casi d’uso ...........................................................................51 Regione Emilia-Romagna – DG Centrale Organizzazione, Personale, Sistemi informativi e Telematica ..............................................................................................51 Azienda Unità Sanitaria Locale di Reggio Emilia ................................................................55 Agenzia regionale di protezione civile dell’Emilia-Romagna ........................................60 Agenzia regionale per la prevenzione e l’ambiente dell’Emilia-Romagna ...............66 Provincia di Forlì-Cesena ..............................................................................................................69 Comune di Imola ..............................................................................................................................74

4

Capitolo 4: considerazioni conclusive e raccomandazioni.................................78 Bibliografia ..................................................................................................................81 Note ...............................................................................................................................84

1

Premessa Il presente dossier rappresenta uno dei risultati del progetto EROSS (Emilia-Romagna Open Source Survey) e fa seguito al precedente, pubblicato nell’ottobre del 2007, nell’ottica di rispondere alle indicazioni contenute nel Piano Telematico dell’Emilia-Romagna 2007-2009, che identifica, tra gli altri, l’obiettivo di “realizzare studi per valutare le opportunità connesse ai diversi modelli di licenza [open souce]”1. La Regione Emilia-Romagna si dichiara decisa ad “agire con il ruolo di facilitatore di processi di valutazione ed adozione del software open source nelle Pubbliche Amministrazioni locali” e con il progetto EROSS mira a realizzare nel triennio 2007-2009: • azioni informative, finalizzate a rendere maggiormente consapevoli gli EELL delle implicazioni sottostanti l’adozione, sviluppo e rilascio di free, libre, open source software (seminari/convegni in-formativi); • rilevazioni finalizzate a misurare la diffusione del free, libre, open source software nei Comuni e nelle Province della regione; • case study e best practice, che possano essere condivisi e tornare utili agli EELL che si interessano di free, libre, open source software per la prima volta; • collaborazioni con progetti e organizzazioni italiane ed europee.

source. Il CAPITOLO 2 descrive, quindi, le principali evidenze emerse offrendo spunti di riflessione. Nel CAPITOLO 3, in analogia con quanto fatto nel primo dossier EROSS, sono presentate esperienze concrete e casi d’uso di free, libre, open source software realizzate da organizzazioni di medie e grandi dimensioni (Regione Emilia-Romagna, AUSL Reggio Emilia, Agenzia Regionale di Protezione Civile, ARPA Emilia-Romagna, Provincia di Forlì-Cesena, Comune di Imola). La presentazione di tali situazioni, vantaggi e problematiche reali completa in modo opportuno l’informazione quantitativa e statistica esposta nei capitoli precedenti. Le considerazioni generali e alcune raccomandazioni sono infine riportate nell’ultimo capitolo, CAPITOLO 4.

Se il primo dossier aveva l’obiettivo di fornire le informazioni di base sul tema del software libero e a codice sorgente aperto, predisponendo una sorta di cronistoria dalle origini ad oggi ed offrendo qualche dato “sperimentale” sulla sua diffusione e uso, questa seconda pubblicazione si sofferma con maggiore dettaglio e perizia sugli aspetti quantitativi. Il dossier si articola in quattro capitoli. Nel primo, il CAPITOLO 0, vengono riprese alcune elementari nozioni indispensabili alla comprensione dei contenuti e sono altresì indicate le più diffuse ragioni portate a sostegno dell’impiego di free, libre, open source software nella Pubblica Amministrazione. Nel CAPITOLO 1 si entra nel vivo dei risultati dell’indagine EROSS realizzata nel 2008 grazie alla collaborazione dei Comuni dell’Emilia-Romagna. Sono presentati e descritti metodologia, risultati e analisi operando confronti con gli indicatori ottenuti da EROSS nel 2006 e da ISTAT nel 2007. In risposta ad una esplicita richiesta dell’Assemblea Legislativa Regionale si è promosso un approfondimento che ha avuto per oggetto i progetti del Piano telematico dell’Emilia-Romagna 2007-2009 e che ha mirato a misurare l’acquisizione e sviluppo di componenti software free, libre, open

2

3

0 Capitolo 0: nozioni elementari Di seguito si definiscono alcuni concetti chiave, la cui conoscenza è indispensabile per apprezzare pienamente il contenuto del documento. Si ripropongono, inoltre, quelle che sono le principali ragioni a supporto dell’adozione di free, libre, open source software (FLOSS) nelle Pubbliche Amministrazioni già individuate e definite nel Dossier del 2007 al quale si rimanda per ottenere informazioni più dettagliate sulle origini e le caratteristiche del software libero e a sorgente aperta.

Software Il termine software indica un programma (istruzioni codificate) o un insieme di programmi, in grado di far eseguire specifici compiti ad un elaboratore/computer.

Diritto d’autore (copyright) Il diritto d’autore è un istituto che attribuisce all’autore di un'opera dell'ingegno a carattere creativo un insieme di facoltà, dirette soprattutto a riservargli lo sfruttamento economico dell'opera. In Italia è disciplinato dalla legge 22 aprile 1941, n. 633. Gli artt. 1-5 forniscono gli elementi per individuare le opere protette dal diritto d'autore. Nella tutela rientrano tutte le opere dell'ingegno aventi carattere creativo, qualunque ne sia il modo o la forma di espressione. La legge definisce le categorie di opere sottoposte al diritto di autore: letteratura, musica, arti figurative, architettura, teatro, cinematografia. Inoltre, sono protette anche le cosiddette "elaborazioni di carattere creativo", come ad esempio le traduzioni in un'altra lingua, le trasposizioni da una forma letteraria o artistica in un'altra, gli adattamenti, le riduzioni, ecc. A seguito del recepimento delle direttive comunitarie 96/9/CE e 91/250/EEC, inoltre, sono ora compresi nell'elenco i programmi per elaboratore (software) e le banche di dati.

Codice sorgente Il codice sorgente (spesso abbreviato con sorgente) è un insieme di istruzioni, con caratteristiche variabili a seconda del linguaggio di programmazione utilizzato, la cui struttura risulta comprensibile ed interpretabile dall’uomo. Il fine ultimo delle istruzioni che compongono il codice sorgente è quello di costituirsi in un programma informatico, che faccia compiere al computer azioni specifiche. Affinché l’elaboratore sia in grado di comprendere e quindi compia tali operazioni, il codice sorgente deve essere trasformato nel cosiddetto codice oggetto o binario (di cui si fornisce una definizione di seguito).

Codice oggetto (binario) Il codice oggetto, o binario, è la traduzione del codice sorgente in linguaggio macchina (ovvero in 0 e 1), comprensibile solo all'elaboratore. Il codice oggetto è generato automaticamente da un apposito programma, detto compilatore, che compie un vero e proprio processo di traduzione (da codice sorgente a codice binario). Volendo fare un paragone, mentre il codice sorgente corrisponde al progetto di una casa, il codice oggetto corrisponde alla casa vera e propria. Tuttavia, a differenza dell’utilizzatore della casa, che dal prodotto può tutto sommato arrivare a ricostruirne il progetto, chi detiene il file oggetto può solo utilizzarlo generalmente, senza che da questo gli sia possibile risalire al codice sorgente che lo ha generato..

4

Il diritto nasce al momento della creazione dell'opera. Quindi, è dall'atto creativo che incondizionatamente si origina; non vi è pertanto alcun obbligo di deposito, di registrazione o di pubblicazione dell'opera. Il diritto d'autore, come disciplinato dalla relativa legge, include le seguenti facoltà inerenti l'opera: pubblicarla, riprodurla, trascriverla, eseguirla, rappresentarla o recitarla in pubblico, comunicarla al pubblico, diffonderla tramite mezzi di diffusione a distanza (telegrafo, telefono, radiodiffusione, televisione e mezzi analoghi, tra cui il satellite, il cavo e Internet), compresa la sua messa a disposizione del pubblico in maniera che ciascuno possa avervi accesso nel luogo e nel momento scelti individualmente (le cosiddette fruizioni on demand), distribuirla, tradurla e/o elaborarla, venderla, noleggiarla e darla in prestito. Tutti i diritti elencati sono indipendenti l'uno dall'altro, il che significa che l'esercizio di uno non include l'esercizio di tutti gli altri. Inoltre, tali diritti si applicano sia all'opera nel suo insieme, che a ciascuna delle sue parti.

Il diritto consiste di due elementi fondamentali: in primo luogo, il diritto alla nominalità dell'opera (anche detto diritto morale), per il quale ciò che è stato creato dall'autore deve essere riferito all'autore medesimo, evitando che altre persone possano gloriarsi di quanto da lui fatto. Secondariamente, il diritto contiene la facoltà di sfruttamento economico. Il primo è strettamente legato alla persona dell'autore e, salvo casi particolari, tale rimane, mentre il secondo è originariamente dell'autore, il quale può cederlo dietro compenso (ma

5

anche gratuitamente) ad un acquirente (licenziatario), il quale a sua volta può nuovamente cederlo nei limiti del contratto di cessione e della legge applicabile.

Licenza (informatica) La licenza in ambito informatico è il contratto che solitamente accompagna un prodotto software. Tale contratto specifica le modalità con cui l’utente può usare il prodotto, garantendo diritti ed imponendo obblighi. La licenza è imposta da chi detiene il diritto di autore (copyright) sul prodotto software, il solo che può far rispettare in ogni sede la licenza stessa.

Software proprietario Con il termine software proprietario, si indica quel software che ha restrizioni sul suo utilizzo, sulla sua modifica, riproduzione o redistribuzione, solitamente imposti da un proprietario. Queste restrizioni vengono ottenute tramite mezzi tecnici o giuridici. Nel primo caso si agisce rendendo pubblico solo il codice binario del software, e trattenendone il codice sorgente (in questi casi la modifica del software risulta molto difficile); nel secondo si elaborano specifiche licenze che regolano l’uso e la disponibilità del software (prevedendo divieti di modifica del codice, o limiti nel suo utilizzo).

Free, libre, open source software [FLOSS] Con il termine ibrido free, libre, open source software (FLOSS), si indica quel software che, rilasciato attraverso una licenza free o open source, permette, anziché impedire, agli utenti di studiarne le caratteristiche, modificare forma e contenuto e ridistribuirne una o più copie liberamente. Il tutto è possibile in quanto vengono abbattute volontariamente, da parte del proprietario del diritto di autore, quelle barriere restrittive (tecniche e giuridiche) che caratterizzano invece il software proprietario. Maggiori dettagli sulle differenze tra software libero e software open source nonché una più dettagliata definizione sono riportati nel Dossier EROSS 20072.

Le ragioni per l’adozione di FLOSS nella Pubblica Amministrazione Sulla base delle valutazioni operate da quei governi che si sono espressi a favore del FLOSS è possibile individuare tra le conseguenze positive “direttamente” connesse all’utilizzo di FLOSS da parte delle Pubbliche Amministrazioni:

6

risparmio economico: si realizza principalmente attraverso l’annullamento dei costi di acquisizione del software (principalmente dovuti alla sostanziale mancanza di oneri di licenza), l’incremento della longevità dell’hardware in uso (molti prodotti FLOSS sono, infatti, ottimizzati per essere eseguiti su calcolatori anche non molto potenti o di recente produzione3 ), e l’indipendenza dell’organizzazione pubblica da specifici fornitori e dalle loro politiche di prezzo; riuso sostanziale del software: molto spesso i software sviluppati o fatti sviluppare da una specifica PA rispondono a esigenze e requisiti comuni a molte altre amministrazioni deputate a funzioni similari. Ciò significa che, se dotati di una delle licenze FLOSS, tali prodotti possono essere resi (legittimamente) disponibili a qualunque altra organizzazione che li voglia utilizzare, modificare o migliorare. Rendendo, inoltre, possibile la nascita di comunità di utilizzatori/sviluppatori che condividono, minimizzandoli, gli eventuali oneri di manutenzione e implementazione del prodotto; diretta gestione dei livelli di sicurezza: la disponibilità del codice sorgente rende valutabili (ovviamente a personale esperto preposto a tale compito) le eventuali vulnerabilità del codice, eliminando pericolosi margini di incertezza. Il software viene inoltre spesso utilizzato nella PA per gestire dati sensibili o informazioni riservate, che non devono essere accessibili a terzi, e che devono poter essere protette nel migliore dei modi; incremento nelle competenze e dell’indipendenza operativa del personale: l’utilizzo di FLOSS permette all’amministrazione di poter formare o acquisire personale con competenze tecniche specifiche, in grado di operare modifiche e implementazioni al software in uso (senza il coinvolgimento di fornitori esterni). Così facendo, verrebbero valorizzate le capacità degli addetti interni: questi potrebbero progredire nell’acquisizione di conoscenza e professionalità, grazie alla facoltà di intervenire liberamente sul codice; effettiva interoperabilità: l’uso di FLOSS garantisce la disponibilità delle specifiche utili a realizzare l’interscambio di dati tra sistemi diversi. Superando, in tal modo, le difficoltà di integrazione che spesso persistono fra prodotti “proprietari” di fornitori concorrenti. L’interoperabilità tra banche dati e programmi gestionali all’interno delle diverse organizzazioni pubbliche è uno dei fattori abilitanti per realizzare una efficace politica di e-government e fornire servizi pubblici a effettivo valore aggiunto;

7

integrità e disponibilità dei dati nel tempo: anche in questo caso, l’utilizzo di FLOSS garantisce alla PA di tutelarsi da eventuali rischi connessi alla sopravvivenza di un produttore/prodotto software. Infatti, l’uso di formati aperti di archiviazione dei dati garantisce all’ente la disponibilità delle proprie informazioni e la possibilità di migrare in autonomia (e quindi senza la necessità di richiedere supporto al fornitore specifico) ad altri prodotti software. L’utilizzo di questo genere di formati tutela anche l’utente della PA. In questo modo, infatti, è libero di scegliere quale prodotto utilizzare per interagire con l’Amministrazione Pubblica, in una logica di pluralismo informatico;

diffusione di una cultura della conoscenza libera e condivisa: l’uso di FLOSS renderebbe possibile estenderne la filosofia di base (Free, Libre e Open) anche ad ambiti estranei al software, come la conoscenza in generale e quindi la cultura. Verrebbero così favoriti fenomeni di cooperazione e condivisione delle informazioni e dei dati (come Wikipedia, Creative Commons, ecc.); inclusione sociale e digitale: opportune modifiche al software (libere nel caso del FLOSS) possono renderlo proficuamente utilizzabile da utenti diversamente6 abili, o soggetti che usano una lingua differente da quella impostata.

elevata disponibilità di prodotti aggiornati allo stato dell’arte: gli aggiornamenti sono come lo stesso software FLOSS, ossia liberamente acquisibili e ridistribuibili.Si può così fare in modo che tutti gli operatori dispongano della medesima versione (la più aggiornata), evitando che alguni gruppi di utenti continuino ad utilizzare i software meno aggiornati (con conseguenti migliorie nella gestione dei documenti); Diversamente, possono essere definiti esiti “indiretti” della diffusa adozione di FLOSS nella Pubblica Amministrazione: incremento nel livello di indipendenza e consistenza del settore ICT nazionale (o regionale): avendo la PA un ruolo consistente nel consumo di ICT, un suo orientamento verso il FLOSS può favorire l’evoluzione di un modello economico competitivo e pluralistico, con il conseguente sostegno allo sviluppo di realtà produttive locali. Così si potrebbe anche rompere il monopolio sulla conoscenza pregressa che caratterizza il mercato del software attuale. Va tenuto conto che la produzione e distribuzione di software che fanno uso di licenze FLOSS rappresenta oggi, in termini economici, una percentuale rilevante del settore ICT, e assume sempre maggiore importanza mano a mano che il numero e le esigenze degli utilizzatori aumentano4. riduzione dei fenomeni di pirateria: la diffusione del FLOSS eliminerebbe il problema della gestione amministrativa delle licenze, ponendo fine a ogni fenomeno di pirateria, e inducendo comportamenti analoghi nella società civile e nel mondo delle imprese che oggi, in Italia5, fanno largo uso di software non regolarmente acquisiti;

8

9

1

Nella convinzione che sia impossibile definire una strategia di azione senza conoscere l’ambito nel quale si intende intervenire, la Regione Emilia-Romagna, per il tramite del suo Centro Regionale di Competenza per l’e-government e la società dell’informazione, ha sperimentato per la prima volta nel 2006 una metodologia di indagine finalizzata a misurare l’intensità con cui i Comuni dell’Emilia-Romagna ricorrono a software free, libre e open source. I risultati così raccolti permisero allora di descrivere con indicatori inediti il contesto regionale, peccando però di una non rigorosa rappresentatività statistica dell’universo di riferimento. A distanza di due anni da quella prima esperienza, basata principalmente sulla volontarietà dei rispondenti, si è ripetuta la rilevazione, migliorando e rivedendo in parte la metodologia, ottenendo informazioni puntuali e dettagliate su 269 dei 341 Comuni dell’Emilia-Romagna. Il questionario EROSS 2008 è stato composto tenendo conto dei risultati ottenuti nell’edizione precedente, nonché delle esperienze in tal senso già realizzate a livello nazionale e internazionale (in particolare l’indagine ISTAT “Le ICT nelle Amministrazioni Locali”7 e quanto realizzato dal progetto della Commissione europea FLOSSPOLS8). Le domande sono state predisposte affinché fosse possibile costruire un indicatore quantitativo che descrivesse la reale “intensità di utilizzo” di FLOSS: non solo, quindi, l’informazione legata a un generico uso/non uso. Con l’obiettivo di rendere il questionario snello e sintetico, si è inoltre operato affinché fosse possibile riutilizzare, in fase di analisi, una gamma di informazioni statistiche già in possesso della Regione e frutto, in buona parte, dell’attività di indagine e benchmarking della società dell’informazione emiliano-romagnola9.

Metodologia di indagine e struttura del campione I dati della rilevazione EROSS 2008 sono stati raccolti nel periodo dicembre 2007 – marzo 2008, attraverso un questionario inviato ai 341 Comuni (unità di analisi) della regione Emilia Romagna. In una prima fase l’invio è stato realizzato via posta elettronica, offrendo la possibilità di procedere alla compilazione nella classica forma cartacea oppure direttamente on line. In un secondo momento si è proceduto ad effettuare dei richiami telefonici mirati, per sollecitare la compilazione da parte dei Comuni mancanti. Scopo del contatto telefonico è stato quello di raggiungere il numero minimo di risposte previsto dal piano di campionamento stratificato, elaborato tenendo conto della dimensione (numero di abi-

10

tanti) e della localizzazione (provincia di appartenenza) delle unità della popolazione di riferimento. I Comuni per i quali è stata raccolta una risposta valida sono stati 269, pari al 78,89 % del totale dei Comuni della regione. Gli obiettivi di campionamento sono stati ampiamente raggiunti per ogni fascia dimensionale e per ogni territorio provinciale, ottenendo quindi un campione statisticamente rappresentativo dell’universo. In Figura 1 e Figura 2 sono specificati nel dettaglio i livelli di risposta ottenuti con attenzione sia per la classe di popolazione che per la provincia di appartenenza. FIGURA 1 - RISPONDENTI EROSS 2008: CLASSE DI POPOLAZIONE

140 120 100 Comuni

Capitolo 1: il FLOSS nelle PA emiliano-romagnole

80 60 40 71

55

101 42

20 0 meno di 3.000 ab.

tra 3.000 e 5.000 ab.

Risposte valide

Non risposte

tra 5.000 e 15.000 ab.

oltre 15.000 ab

Fonte: EROSS 2008

Da un punto di vista dimensionale (Figura 1), la percentuale di rispondenti più elevata è stata registrata nei Comuni con più di 15.000 abitanti (89,36%), mentre per le altre fasce di popolazioni i valori sono molto simili e di poco inferiori alla media regionale (78,89%). E’ evidente l’elevato numero di Comuni di piccole o piccolissime dimensioni che hanno contribuito all’indagine, in questi casi, più che negli altri, sono risultati indispensabili l’interazione telefonica ed il contributo di più referenti. Spesso infatti, specie nelle piccole realtà, la gestione delle attrezzature informatiche è in parte o totalmente esternalizzata a società private, o più spesso a strutture pubbliche (Comunità Montane, Associazioni Intercomunali o Unioni di Comuni) a cui è demandata la gestione associata dei servizi informatici.

11

Per quel che riguarda la territorialità delle risposte collezionate (Figura 2 - in basso), le province meno rappresentate sono Piacenza e Parma, che superano di poco il 70%, mentre la provincia che ha segnato il più alto tasso di risposte è stata quella di Ravenna (94%). Sono da registrare risultati al di sopra della media regionale anche per le province di Bologna, Ferrara, Modena e Rimini. Se poi si analizzano i valori assoluti della distribuzione territoriale dei rispondenti (Figura 2 - in alto), è evidente come i Comuni della provincia di Bologna siano i più numerosi (50, pari al 19% del campione), seguiti dai Comuni della provincia di Modena (39, pari al 14% del campione). I tassi di risposta ottenuti garantiscono la piena rappresentatività dei dati sia per territorio provinciale che per fascia dimensionale del Comune. Gli indicatori che si presentano, frutto delle analisi, sono quindi espressione della realtà del territorio regionale e non di una minoranza10.

FIGURA 2 - RISPONDENTI EROSS 2008: TERRITORIO PROVINCIALE DI APPARTENENZA BO

50

FC

22

FE

22

MO

39

PC

34

PR

34

RA

17

RE

34

RN

17 0

10

L’indagine EROSS si è soffermata in modo particolare su due tipologie di software: quelli client/desktop (installati tipicamente sulle postazioni degli operatori della PA), e quelli server. Più nel dettaglio, attraverso il questionario, è stato richiesto ai Comuni di specificare il numero di installazioni ed il nome dei software utilizzati nei diversi ambiti applicativi.

20

30

BO

85%

FC

76%

FE

94%

MO

72%

PC

71%

PR

83%

RA

85%

RE

73%

RN

83% 0%

10%

20%

Risposte valide

30%

40%

40

50

60

Per quel che riguarda i software client/desktop, le informazioni raccolte hanno riguardato: • sistema operativo per il desktop; • software di posta elettronica; • browser Internet; • suite office automation; • sistemi SIT/GIS. Per i software server, l’indagine si è concentrata invece su: • Web server11; • application server12; • mail server13; • file server14; • server di desktop remoto15; • data base management system (DBMS)16; • printer server17.

50%

60%

70%

80%

90%

100%

Non risposte

Fonte: EROSS 2008 12

13

La scelta di queste specifiche classi di programmi informatici è frutto dei risultati ottenuti nel 2006 e della logica di voler misurare e mettere a confronto l’utilizzo di software che, negli EELL, fanno parte della “dotazione standard” e quindi per i quali è plausibile attendersi un elevato livello di confrontabilità. I dati ottenuti hanno permesso di calcolare un indice di intensità di utilizzo FLOSS (iuFLOSS), pari al rapporto tra il numero di installazioni di tipo FLOSS ed il totale di tutte le installazioni. Tale indice è stato dapprima calcolato per ogni tipologia di software, per poi comporre un indice complessivo per i software client/desktop e per i software server (entrambi ottenuti come media semplice dei valori di iuFLOSS per i singoli ambiti applicativi facenti parte delle due categorie18). Un indice di intensità di utilizzo FLOSS generale è stato infine calcolato come media semplice dell’iuFLOSS client/desktop e dell’iuFLOSS server. Tale valore di sintesi offre quindi, assegnando eguale peso alle due tipologie di software, una indicazione sull’effettivo utilizzo di FLOSS.

Amministrazioni fanno uso di FLOSS senza saperlo, in modo per così dire “inconsapevole”. Tale risultato, peraltro già emerso nella rilevazione EROSS 2006 e nell’indagine europea FLOSSPOLS realizzata da UNU-MERIT (in quel caso la percentuale era del 30% e faceva riferimento all’anno 2005)21, sottolinea come persista un problema di ridotta conoscenza del tema da parte di un numero considerevole di Comuni. Da sottolineare inoltre come tale mancanza di conoscenza non interessi solo gli EELL di piccole dimensioni, ma in egual misura enti di piccole dimensioni e enti medi e grandi. Complessivamente dunque, la percentuale di Comuni che utilizza consapevolmente o inconsapevolmente FLOSS in Emilia-Romagna sale al 77%. Questo dato sottolinea da un lato l’elevato interesse che il settore pubblico mostra nei confronti del FLOSS, e dall’altro giustifica e motiva l’esistenza stessa del progetto EROSS.

FIGURA 3 - COMUNI UTILIZZATORI DI FLOSS (CONSAPEVOLI ED INCONSAPEVOLI)

Utilizzando l’iuFLOSS (di qui in avanti, ove non diversamente specificato, ci si riferirà sempre all’iuFLOSS generale quando si farà riferimento all’indice di intensità di utilizzo FLOSS), è stato possibile distinguere tra gli Enti Locali che effettivamente hanno scelto di utilizzare FLOSS in modo diffuso. In questa logica i Comuni sono stati distinti in tre categorie di utilizzatori, permettendo così di delineare l’identikit dei Comuni che fanno “intenso”, “moderato” o “nessuno” utilizzo di FLOSS.

22% non utilizzatori di floss

14% 1% non sa/non risponde

utilizzatori inconsapevoli di floss

77%

Analisi descrittiva Il primo dato sul quale soffermarsi è quello generale relativo a quanti Comuni abbiano esplicitamente dichiarato di utilizzare FLOSS (Figura 3). Sulla base delle risposte raccolte da EROSS 2008, due Comuni emilianoromagnoli su tre (il 63%) dichiarano di utilizzare FLOSS. Il risultato, direttamente confrontabile con quello ISTAT 200719, è di molto sopra la media nazionale, che si assesta al 34,4%, e superiore in modo sostanziale al valore medio dell’area geografica Nord-est (50,8%), a cui l’Emilia-Romagna appartiene. La media europea, il dato disponibile fa riferimento all’anno 200520, è invece del 50,1%. Sostanzialmente questa prima informazione evidenzia come il territorio regionale abbia maturato una tendenza ed una propensione all’uso di soluzioni software FLOSS più di quanto abbiano fatto le corrispondenti Amministrazioni italiane ed europee. A conferma del fatto che l’adozione e l’uso di FLOSS non sono limitati a pochi, attraverso la metodologia EROSS 2008 è stato possibile identificare anche un 14% di Comuni che, pur avendo dichiarato di non utilizzare FLOSS, presentano un iuFLOSS maggiore di zero. Ciò significa che queste

14

utilizzatori di floss

63% utilizzatori consapevoli di floss

Fonte: EROSS 2008

Nella precedente indagine EROSS 2006, la percentuale complessiva stimata di Comuni utilizzatori di FLOSS era del 70%. Tale dato, alla luce del 77% della presente rilevazione, si dimostra meno viziato da dinamiche di autoselezione di quanto si fosse pensato al tempo22.

15

TABELLA 1 - COMUNI DOTATI DI UN ATTO DI INDIRIZZO STRATEGICO O AMMINISTRATIVO

Classi dimensionali e localizzazione territoriale

AVENTE AD OGGETTO L'ADOZIONE DI FLOSS

La quantità e l’elevato numero delle risposte raccolte hanno permesso di elaborare indicatori di adozione ed utilizzo del FLOSS che descrivono e confrontano i risultati per territorio provinciale di appartenenza e per dimensione dell’ente (in termini di popolazione di pertinenza). Osservando i due grafici di Figura 4, è facile notare come sussistano marcate differenze tra i valori medi di iuFLOSS: in particolare si osserva come siano i piccolissimi ed i grandi Comuni a presentare iuFLOSS media più elevata.

(

Comuni Fascia dimensionale Più di 15.000 ab.

Argenta, Bologna, Correggio, Faenza,

% su totale comuni (valore assoluto)

)

32% (15/47)

Ferrara, Forlì, Imola, Lugo, Modena, Pianoro, Ravenna, Riccione, Rimini, San Lazzaro Di Savena, Zola Predosa 5.000 - 15.000 ab.

Albinea, Argelato, Castello D'argile,

14% (18/129)

Castelnovo Di Sotto, Castiglione

FIGURA 4 – INTENSITÀ MEDIA DI UTILIZZO GENERALE, CLIENT/DESKTOP E SERVER (FASCE DIMENSIONALI E TERRITORI PROVINCIALI)

Dei Pepoli, Colorno, Fusignano, Fornovo Val

50%

Di Taro, Galliera, Luzzara, Mesola, Misano Adriatico, Morciano Di Romagna, Oz-

45%

zano Dell'Emilia, Pieve Di Cento, Poviglio, San Giorgio In Piano, San Pietro

40%

In Casale

35% 3.000 - 5.000 ab.

Bentivoglio, Casalgrande, Castel Guelfo Di

8% (6/72)

30%

Bologna, Coli, Jolanda Di Savoia, Soragna

25% meno di 3.000 ab.

Bagnara Di Romagna, Borghi, Coli,

4% (4/93)

Sant'agata Sul Santerno

20%

Fonte: Understand 2005 e EROSS 2008

15% 10%

La Tabella 3 riporta quali e quanti sono i Comuni dell’Emilia-Romagna che hanno dichiarato di aver adottato un atto di indirizzo strategico o amministrativo avente ad oggetto l’adozione di software FLOSS. Come si vede sono prevalentemente interessati i Comuni di grandi dimensioni. Come prevedibile, sulla base dei dati EROSS 2008, è possibile stabilire che i Comuni che fanno uso intensivo di FLOSS sono quelli che con più ricorrenza si sono dotati di forme di indirizzo aventi per oggetto il FLOSS. Esiste però una quota significativa di Comuni (l’8% in EROSS 2008), che pur presentando iuFLOSS pari a zero, si sono dotati di un atto di indirizzo in materia FLOSS. Questa “anomalia” potrebbe riguardare da un lato enti che hanno intenzione di sperimentare in tempi brevi il software libero o a codice sorgente aperto, o in alternativa potrebbe essere espressione dell’utilizzo di FLOSS in ambiti non censiti dall’indagine EROSS (come ad esempio quello dei software per il Web o di tipo gestionale).

5% 0% meno di 3.000 ab.

tra 3.000 e 5.000 ab.

tra 5.000 e 15.000 ab.

oltre 15.000 ab.

iuFLOSS Client/Desktop (retta tratteggiata = media regionale) iuFLOSS Server (retta tratteggiata = media regionale) iuFLOSS generale (retta tratteggiata = media regionale)

Fonte: EROSS 2008

16

17

50% FIGURA 5 - INTENSITÀ MEDIA DI UTILIZZO SW CLIENT/DESKTOP (FASCE DIMENSIONALI

45%

E TERRITORI PROVINCIALI)

40%

30%

35%

25%

30% 20% 25% 15% 20% 10% 15% 5% 10% 0%

5%

oltre 15.000 ab.

tra 5.000 e 15.000 ab.

tra 3.000 e 5.000 ab.

meno di 3.000 ab.

Regione

0% FC

PC

RE

PR

BO

RA

RN

FE

iuFLOSS Sistema Operativo iuFLOSS Posta elettronica

MO

iuFLOSS Browser Internet iuFLOSS Suite Office

iuFLOSS Client/Desktop (retta tratteggiata = media regionale)

30% iuFLOSS Server (retta tratteggiata = media regionale) iuFLOSS generale (retta tratteggiata = media regionale)

25% 20%

Sono i Comuni compresi nelle fasce con popolazione fra 3.000 e 15.000 abitanti che paiono fare un uso del FLOSS meno intenso; da notare inoltre come nel caso dei valori specifici per Client/Desktop e per Server si possono notare alcune piccole differenze. Questa dinamica sicuramente subisce gli effetti diretti della disponibilità di risorse umane ed economiche, della complessità della gestione dell’installato che aumenta con l’aumentare del numero dei dipendenti dell’ente e con fenomeni di esternalizzazione dell’attività di gestione e manutenzione che nel caso di Comuni medi significa spesso demandare ai fornitori le scelte su quali software adottare. Ancor più accentuate sono le differenze che si evidenziano, Figura 4 secondo grafico, tra i territori provinciali. E’ sostanzialmente chiaro che il FLOSS non rappresenta qualcosa di oscuro e nuovo per i Comuni modenesi, ferraresi e del riminese, che ne fanno un uso intenso e diffuso (seppure con differenze anche sostanziali negli aspetti applicativi – client/desktop o server). Approfondendo sui singoli software, è possibile descrivere in modo ancor più dettagliato le preferenze di utilizzo ed adozione delle singole classi dimensionali di Comuni e dei singoli territori provinciali di competenza.

18

15% 10% 5% 0% BO

FC

FE

MO

iuFLOSS Sistema Operativo iuFLOSS Posta elettronica

PC

PR

RA

RE

RN

Regione

iuFLOSS Browser Internet iuFLOSS Suite Office

I grafici inclusi in Figura 5 offrono un dettaglio che permette di apprezzare differenze in alcuni casi sostanziali nell’utilizzo di software FLOSS nei client/desktop degli operatori dei Comuni emiliano-romagnoli.

Fonte: EROSS 2008 19

In particolare spiccano come valori sopra la media regionale quelli dei Comuni di: • Rimini e Bologna nell’utilizzo di sofware di produttività personale (Suite Office); • Modena e Bologna nell’utilizzo di software per navigare in Internet (Browser). Da notare come i Comuni con dimensione superiore a 5.000 ab. presentino per tutte le tipologie di sw client/desktop valori superiori o prossimi alla media regionale.

FIGURA 7 - INTENSITÀ DI UTILIZZO SOFTWARE CLIENT/DESKTOP (&COMUNI)

FIGURA 6 - INTENSITÀ MEDIA DI UTILIZZO SW SERVER (FASCE DIMENSIONALI)

100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% oltre 15.000 ab.

tra 5.000 e 15.000 ab.

iuFLOSS Web Server iuFLOSS Application Ser iuFLOSS Mail Server iuFLOSS File Server

tra 3.000 e 5.000 ab.

meno di 3.000 ab.

Fonte: EROSS 2008 Regione

iuFLOSS Printer Server iuFLOSS Server di Desktop Remoto iuFLOSS Data Base Management Systems (DBMS)

Fonte: EROSS 2008

Quelle appena descritte sono quindi le principali differenze che sussistono tra Comuni di territori provinciali e fasce dimensionali diverse, in termini di valori medi di intensità di utilizzo di FLOSS. Nei paragrafi che seguono, si analizzerà invece l’intensità di utilizzo FLOSS di ogni Comune, nel dettaglio dei singoli software.

Analoghe considerazioni possono essere fatte per quanto rappresentato in Figura 6 e Figura 7, dalle quali emergono con una certa evidenza risultati sopra la media regionale che interessano principalmente,e in modo generalizzato, i grandi Comuni (sopra quota 15.000 ab.), e nello specifico di alcune tipologie di software Server, i piccolissimi Comuni (inferiori a 3.000 ab.). Le differenze tra i territori provinciali vedono i Comuni del riminese primeggiare in tutti i diversi ambiti applicativi; risultati sopra la media per singoli software sono evidenti anche per ravennate, modenese e ferrarese.

20

21

Intensità nell’utilizzo di FLOSS per i client/desktop Descritte le dinamiche dei risultati rispetto all'universo di riferimento (in termini di localizzazione geografica e dimensione dei singoli Comuni), si analizzano ora le singole tipologie di software, iniziando da quelli per la produttività personale. I risultati fanno riferimento alla dotazione standard in capo ai singoli operatori pubblici, quella definita, gestita e mantenuta operativa dalla struttura interna (o da fornitori esteri con contratti di gestione e manutenzione). In Figura 8 sono rappresentati gli indici di intensità di utilizzo calcolati per ciascuno dei cinque ambiti di software client/desktop indagati. I dati, come detto, sono pienamente rappresentativi, e quindi la percentuale, unità di misura orizzontale, è da applicare al totale dei 341 Comuni dell'Emilia-Romagna. FIGURA 8 - INTENSITÀ DI UTILIZZO SOFTWARE CLIENT/DESKTOP (% COMUNI) sistema operativo posta elettronica browser internet office automation sit/gis*

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Comuni Intensità di utilizzo (iuFLOSS)

100% FLOSS 76-99% 51-75% 50% 31-49% 11-30% < 10% 0% FLOSS non sa/non risponde Webmail

Fonte: EROSS 2008 Nota: I dati raccolti per i software SIT/GIS sono stati raccolti in modo sperimentale e non sono stati inclusi nel calcolo dei valori sintetici di iuFLOSS.

22

Come risulta evidente, la diffusione di FLOSS nel settore dei software client/desktop è piuttosto limitata. Ciò risulta particolarmente vero nell’ambito dei sistemi operativi, ove più del 75% dei Comuni (tre su quattro) presentano un iuFLOSS pari a zero. I Comuni che hanno installato Gnu/Linux (o altro sistema operativo FLOSS) su più del 30% dei propri client/desktop sono appena due. Complessivamente, nei Comuni indagati, le installazioni di sistemi operativi FLOSS ammontano a 315 su oltre 26.000 censite (pari all’1,2%). Questo risultato sottolinea, specie se confrontato con quelli che seguiranno, il ridotto interesse che le Pubbliche Amministrazioni rivolgono, allo stato attuale, alle alternative FLOSS di Microsoft Windows, che nelle sue varie versioni resta la piattaforma di lavoro della stragrande maggioranza degli operatori dei Comuni emilianoromagnoli. Per quanto riguarda la gestione della posta elettronica, si nota come anche qui l’adozione di FLOSS sia limitata a pochi Comuni, nei quali però se ne fa un utilizzo intenso e non trascurabile. Sono 8 gli enti che utilizzano client mail free o open source in maniera esclusiva (iuFLOSS = 100%). Numerosi sono anche i Comuni che hanno scelto soluzioni per la gestione delle mail che prescindono da installazioni sui client/desktop, e che sfruttano l’uso del protocollo http e quindi di un comune browser Internet (Webmail). Sul fronte della navigazione del Web, si rileva il più alto livello di preferenza riservato alle alternative FLOSS di prodotti consolidati e largamente diffusi come il leader di mercato MS Internet Explorer. Il 23,5% delle installazioni standard che interessano le postazioni degli operatori dei Comuni della regione sono dotate di prodotti free o open source (come Firefox, Mozilla, ecc…) come browser Internet. Così, circa il 13% di Comuni presenta un iuFLOSS maggiore o uguale al 50%, e in quattro enti sono utilizzati esclusivamente browser FLOSS. Numeri molto simili e altrettanto significativi sono riscontrabili nell’ambito dell’office automation (produttività personale), in cui il 45% circa dei Comuni ha una o più installazioni FLOSS (nella fattispecie openoffice.org); di questi una quota significativa il 7% presenta un iuFLOSS maggiore o uguale al 50%, e in quattro Comuni si fa uso esclusivo del prodotto non proprietario. Questi due risultati meritano particolare attenzione, perché si tratta degli strumenti con cui ogni giorno gli operatori della PA si trovano a lavorare. È quindi molto facile comprendere le criticità legate alla sostituzione di prodotti consolidati e molto completi (come Microsoft Office). Rispetto ai risultati ottenuti sui software SIT/GIS, prodotti di tipo specialistico destinati a specifici settori degli EELL (programmazione territoriale, edilizia, ecc…), un primo macro dato riguarda la percentuale elevata di non risposte. Questo fa supporre che vi sia una gestione diretta dei sin-

23

goli settori per quanto riguarda le scelte di acquisizione e spesa su software non destinati ad un uso generalizzato. I dati raccolti sembrano comunque indicare una scarsa diffusione di FLOSS in questo ambito; ciononostante, vi sono almeno tre Comuni in cui l’unico software installato risulta essere FLOSS (nello specifico Quantum Gis).

nell’adozione di sistemi automatici per la gestione dei contenuti Web dei siti dei Comuni. Come si apprezza in Figura 9, la maggior parte degli utilizzatori di CMS, che hanno risposto ai quesiti EROSS-RACER, opta per soluzioni proprietarie. Solo un 18% ha scelto CMS free o open source (come Joomla, Plone, eZ Publish, Xoops, ecc…). FIGURA 9 - L'UTILIZZO DI FLOSS PER LA GESTIONE DEI CONTENUTI DEL SITO WEB ISTITUZIO-

Gruppo di lavoro regionale openoffice.org Consapevole delle difficoltà che spesso incontrano le amministrazioni pubbliche che decidono di migrare a sistemi FLOSS, il progetto EROSS, su stimolo di alcuni EELL del territorio regionale, ha costituito un gruppo di lavoro degli utilizzatori di openoffice.org. Il numero di installazioni censite con EROSS 2008 è di oltre 6500, e quindi il fenomeno è rilevante. Il gruppo di lavoro è allo stato attuale composto da rappresentanti di Comuni, Province e della Regione Emilia-Romagna, e potrà essere aperto ad altri soggetti che nel tempo si riterrà utile coinvolgere. Gli obiettivi che si prefigge il gruppo (ovviamente ampliabili) sono: (1) condividere le esperienze acquisite, le soluzioni individuate e le strategie di migrazione adottate; (2) realizzare un vademecum o linee guida all'utilizzo di openoffice.org nella PA, destinato agli EELL che hanno deciso di utilizzare il prodotto open source; (3) stabilire una sorta di comunità stabile degli utilizzatori di openoffice.org della PA regionale. Il primo incontro si è svolto a inizio dicembre 2008. Maggiori informazioni possono essere richieste via e-mail all’indirizzo [email protected].

Software per la gestione dei contenuti Web (CMS) L’esperienza accumulata dal progetto EROSS con la rilevazione 2006, l’esigenza conoscitiva specifica del progetto RACER (Rete per l’ACcessibilità in Emilia-Romagna) e lo spirito di cooperazione e collaborazione che caratterizza la programmazione regionale in materia di società dell’informazione, il Piano telematico dell’Emilia-Romagna, hanno portato alla realizzazione di un supplemento sperimentale di indagine riguardante i sistemi di gestione dei contenuti Web (CMS – content management system). I risultati raccolti, seppur limitati nel numero, offrono un ulteriore tassello informativo che aiuta a comprendere la diffusione e l’utilizzo di FLOSS nelle Pubbliche Amministrazioni emiliano-romagnole. Sono 98 i Comuni che hanno risposto ai quesiti EROSS-RACER, e di questi il 59% hanno dichiarato di fare già uso di CMS (il 3% ne sta valutando l’adozione). Questa tipologia di software è quindi relativamente poco diffusa se si considera che tutti i Comuni dell’Emilia-Romagna sono dotati di un sito Web istituzionale, e in alcuni casi anche di ulteriori portali tematici. È quindi presumibile attendersi un’espansione

24

NALE (N. COMUNI) *

2 8

33 37

61

18 non utilizza CMS utilizza CMS non sa / non risponde sw sviluppato dall’ente in economia sw rilasciati con licenza proprietaria sw rilasciati con licenza libera o a codice sorgente aperto Fonte: EROSS-RACER (agosto) 2008. * Nota: I dati sono stati raccolti con un questionario on line a risposta volontaria; per questa ragione i risultati hanno solo valore informativo e non rappresentatività statistica.

Intensità nell’utilizzo di FLOSS per i server I “serventi” sono l’altra grande categoria di software di cui un buon numero di Pubbliche Amministrazione si è dovuta dotare negli anni per gestire la propria LAN (local area network), su cui fornire servizi distribuiti (condivisione e gestione di risorse come spazio di archiviazione, stampanti, ecc…) e per sviluppare e gestire applicazioni e servizi da utilizzare sulle reti Intranet e Internet (siti Web, posta elettronica, sistemi gestionali, ecc…). Il livello di efficienza ed efficacia dei software utilizzati sui server ha riflesso diretto sulla produttività e sulla capacità di lavoro dell’intera amministrazione pubblica, e per questa ragione molto spesso la loro gestione (e quindi anche la scelta su quale software utilizzare) è demandata a soggetti esterni specializzati in questo campo.

25

FIGURA 10 - INTENSITÀ DI UTILIZZO SOFTWARE SERVER (% COMUNI)

Comuni

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

web server application server mail server file server server di desktop remoto data base management systems printer server

FIGURA 11 - INTENSITÀ DI UTILIZZO FLOSS (CLIENT/DESKTOP VS. SERVER)

100% FLOSS 76-99% 51-75% 50% 31-49% 11-30% < 10% 0% FLOSS legacy* non gestito internamente non sa/non risponde

Fonte: EROSS 2008 Nota: nella categoria printer server è stata introdotta la dicitura “legacy” per indicare il caso dell'impiego di stampanti di rete autonome (che non necessitano di un server di stampa esterno).

Prima di tutto è quindi interessante notare (Figura 10) come un elevato numero di Comuni non gestisca internamente i server, fatta eccezione per i file server e i Database Management System (DBMS)23. A differenza di quanto visto per i software client/desktop, sul lato server il numero di Comuni che utilizzano in modo esclusivo FLOSS è molto elevato. Sul totale dei 341 Comuni emiliano-romagnoli, sono “100% FLOSS” rispettivamente il 7% per i Web server, l’11% per i mail server e addirittura il 25% per gli application server. Tale evidenza conferma implicitamente che, come peraltro noto a livello mondiale (FLOSS come Apache, Tomcat, Jboss, Postfix, ecc… sono leader o importanti players del loro mercato), esistono prodotti FLOSS per i server stabili ed affidabili che possono rispondere in modo completo e pieno alle esigenze

Intensità di utilizzo FLOSS lato Server

100%

Intensità di utilizzo (iuFLOSS)

26

delle Pubbliche Amministrazioni. L’elevata adozione e l’alta intensità di utilizzo di FLOSS in ambito server ha ovviamente un impatto limitato sui singoli operatori della PA, che con ogni probabilità, a parità di continuità del servizio, non percepiscono differenze. La scelta di adottare FLOSS è quindi pienamente in capo al responsabile informatico dell’ente e, in questo caso, impatta in modo quasi esclusivo sulla sua struttura. L’ambito applicativo con il maggior utilizzo di FLOSS (indipendentemente dall’intensità) è quello dei software di DBMS, dove si raggiunge un 30% di iuFLOSS>0, seguito a breve distanza da application server (28%) e Web server (25%).

A C

50% D

B 0% 0%

50%

100%

Intensità di utilizzo FLOSS lato Client/Desktop Fonte: EROSS 2008.

In Figura 11 vengono messi a confronto i risultati di intensità di adozione media di FLOSS in ambito client/desktop e server per ognuno dei 269 Comuni indagati. Posizionando tutte le osservazioni sul piano cartesiano, è possibile riconoscere e distinguere gruppi di EELL che si comportano in modo analogo, nonché individuare quello che può essere definito come “il sentiero di avvicinamento al FLOSS”. Una prima macro evidenza è rappresentata dal fatto che nessun Comune si posiziona nel quadrante basso di destra, che corrisponde ad elevata intensità nell’utilizzo di FLOSS per i client/desktop e bassa per i server.

27

Questo risultato suggerisce che il percorso seguito dai Comuni nell’adozione di livelli significativi di FLOSS lato client/desktop deve passare necessariamente da un primo progressivo e sempre più consistente utilizzo lato server. L’ipotesi di fondo, sostenuta anche dai dati sin qui illustrati, è che il passaggio verso il software free e open source debba prima avvenire lato server, coinvolgendo le strutture tecniche che per l’ente si occupano della gestione delle ICT, per poi muoversi verso una sperimentazione lato client/desktop, solo in quel momento considerabile come preludio per una vera e propria adozione o migrazione che coinvolga tutte le postazioni degli operatori del Comune.

TABELLA 2 – GRUPPI DI COMUNI CHE TENGONO COMPORTAMENTI ANALOGHI NELL’UTILIZZO DI FLOSS

(

Utilizzo FLOSS A B C D

Full server Only client/desktop Only server Both client/desktop & server

Comuni (n.) 12 18 64 7

Media (ab.)

Max (ab.)

Min. (ab.)

5.600 12.000 13.500 41.400

20.000 96.000 142.000 175.000

700 1.900 900 2.800

)

Fonte: EROSS 2008

In Tabella 2 i Comuni rappresentati in Figura 11 sono stati raggruppati secondo criteri selettivi in gruppi omogenei che possono essere descritti nei seguenti modi:

Non essendo stati fatti interventi di alcun tipo lato server, è probabile che le motivazioni alla base dell’adozione di FLOSS siano di tipo economico/politico e non tecnico; C. Only server, il sentiero di avvicinamento al FLOSS passa in modo molto stretto da una prima azione esclusivamente indirizzata all’adozione di software libero o a codice sorgente aperto sui server. Le dimensioni dei Comuni sono medie (13.500 ab.) e analoghe a quelle del gruppo precedente. La scelta di utilizzo di FLOSS lato server è molto probabilmente frutto di una decisione tecnica operata dal responsabile dei sistemi informativi/informatici. Non vi sono interventi significativi sulle postazioni client/desktop che presupporrebbero il coinvolgimento e la collaborazione di tutti i dipendenti e l’approvazione/supporto di tutti i livelli decisionali/politici; D. Both client/desktop & server, si tratta di enti che gestiscono almeno la metà dei propri server con FLOSS e che contemporaneamente hanno installazioni diffuse di software liberi o a codice sorgente aperto sulle singole postazioni degli operatori pubblici. Le dimensioni medie dei Comuni sono medio-grandi (41.400 ab.) ed è quindi probabile che le risorse umane (in termini di numero e competenze) non manchino. In questi enti la scelta di adottare FLOSS in entrambi gli ambiti applicativi ha dovuto coinvolgere sia i responsabili tecnici che gli organi decisionali/politici del Comune, imponendo una riflessione generale sui rischi e le opportunità dell’adozione intensa di free e open source software. Questo gruppo rappresenta la testa di quei Comuni che compongono la nuvola di punti alla loro sinistra, e per i quali ci si può attendere una progressiva crescita nell’intensità di utilizzo FLOSS sia server che client/desktop.

Identikit dei Comuni utilizzatori di FLOSS A. Full server, presentano tutti il massimo grado di intensità di utilizzo di FLOSS lato server, e si distanziano da tutti gli altri come ad evidenziare l’importanza sostanziale di una scelta simile (che a quanto pare non è per tutti facile o praticabile). Questi Comuni sono di medie-piccole dimensioni (5.600 ab.), e probabilmente, proprio forti della loro ridotta complessità e delle scarse risorse economiche a disposizione, hanno scelto di affidare la gestione dei propri server elusivamente a software FLOSS; B. Only client/desktop, tutti questi Comuni si sono dotati di software client/desktop FLOSS ed hanno probabilmente iniziato un processo di “migrazione” o “affiancamento” di prodotti FLOSS a quelli proprietari già in uso. Questi enti hanno una dimensione media doppia (12.000 ab.) rispetto a quella dei precedenti, e quindi, presumibilmente, possono contare su personale dedicato e strutture interne o esterne che si occupano di gestione e manutenzione del software installato.

28

Provando a dettagliare le caratteristiche dei Comuni del campione, si è operata una divisione in categorie basata sul valore complessivo di iuFLOSS24. Sono stati così definiti tre gruppi: • nessun utilizzo di FLOSS, iuFLOSS pari a zero; • moderato utilizzo di FLOSS, 0%< iuFLOSS < 20%; • elevato utilizzo di FLOSS, iuFLOSS > 20%. La soglia del 20% è stata fissata tenendo conto del valore medio del campione e delle scelte operate nell’analisi del 2006. In ultima approssimazione quindi, il 20% rappresenta un valore critico per distinguere tra quanti usano in modo “moderato” (inferiore alla media) FLOSS e quanti ne fanno invece un uso “elevato” (superiore alla media). La Tabella 3 fornisce per le diverse classi di utilizzatori una sorta di identikit. È possibile notare infatti che le dimensioni del Comune, intese come

29

nitida. Il numero di fornitori cresce nel passaggio dalla classe di non utilizzatori (2,8) a quella degli utilizzatori moderati (4,4), ma decresce, seppur leggermente, (4) nel passaggio alla classe di utilizzatori successiva.

TABELLA 3 - IDENTIKIT COMUNI UTILIZZATORI DI FLOSS

( Dimensione media del Comune (abitanti) Dimensione mediana del Comune (abitanti) % del totale dei Comuni Adozione di un atto di indirizzo sul FLOSS Presenza di un addetto all’ICT# Strategia ICT# Strategia di e-government# Connessione a banda larga (>2Mbps)# Il Comune realizza o commissiona attività di sviluppo software Numero medio di fornitori ICT** Spesa media in licenze software per addetto* Parere favorevole a politiche della P.A. a favore del FLOSS

ELEVATO

MODERATO

NESSUN

UTILIZZO

UTILIZZO

UTILIZZO

DI FLOSS

DI FLOSS DI FLOSS (IUFLOSS>20%) (IUFLOSS<20%) (IUFLOSS=0%)

18.749 7.222 31% 15% 65% 29% 32% 77%

15.403 6.273 40% 12% 59% 26% 31% 79%

4.151 3.472 29% 8% 27% 9% 21% 74%

21% 4,0 201 €

8% 4,4 316 €

4% 2,8 348 €

86%

80%

79%

)

Fonte: EROSS 2008, # Rilevazione ICT PA Emilia-Romagna 2007. La Finanza del territorio. Note: * valore calcolato come rapporto tra il numero di addetti del 2006 e la spesa media in licenze software nel periodo 2004-2006, ** valore calcolato sui soli 79 Comuni che hanno risposto a questa domanda

numero (medio e mediano) di abitanti, influenzano l’intensità di utilizzo del FLOSS. Lo scenario che sembra emergere fa immaginare che più grande è un Comune, maggiore sarà la probabilità che adotti soluzioni FLOSS, con un’intensità di utilizzo che aumenta all’aumentare delle dimensioni del Comune. In definitiva “le dimensioni contano”, anche se tuttavia occorre sottolineare come sembrino influire principalmente sulla possibilità di adottare o non adottare FLOSS piuttosto che sull’intensità di utilizzo. In altri termini, la maggior parte dei Comuni medio-grandi scelgono di sperimentare soluzioni FLOSS, ma la scelta di farne un uso diffuso ed intenso dipende da altri fattori. In generale quindi, i Comuni con un valore dell’iuFLOSS > 0% sono il 71%, mentre il restante 29% ha un valore iuFLOSS pari a zero25. Il dato sul numero medio di fornitori di servizi ICT legati al software di cui ogni ente si avvale è abbastanza interessante. La tendenza emersa chiaramente a riguardo nel 2006, che vedeva un numero di fornitori crescente all’aumentare dell’intensità di utilizzo di FLOSS, risulta ora meno

30

Il dato della spesa media in licenze software per addetto per l’anno 2006, calcolata come rapporto tra il numero di addetti del Comune e la spesa media per licenze software degli ultimi 3 anni (dal 2004 al 2006), presenta dei valori decrescenti all’aumentare dell’intensità dell’utilizzo di FLOSS. Nello specifico, nella classe di elevati utilizzatori di FLOSS il valore è di 201 € per addetto, 316 € per addetto per gli utilizzatori moderati e 348 € per addetto per i non utilizzatori. Questo dato da un lato non sorprende, perché è plausibile ipotizzare un rapporto inverso tra uso medio di FLOSS e spesa media in licenze software per addetto, dall’altro è una prima importante conferma del risparmio reale che l’utilizzo di FLOSS può generare per i Comuni. Da sottolineare è anche l’evidenza di un consenso abbastanza generalizzato, e sostanzialmente trasversale alle tre classi di utilizzatori FLOSS, riguardo all’eventualità che la PA rivesta un ruolo attivo nella promozione e diffusione di software libero (free) e a codice sorgente aperto (open source). Su questo si tornerà in modo dettagliato nelle pagine successive. Tra i Comuni con un elevato utilizzo di FLOSS, il 21% ha sviluppato o ha fatto sviluppare software (FLOSS e non) proficuamente riutilizzabile da altre amministrazioni (Tabella 3). Al calare dell’intensità di utilizzo, tale

TABELLA 4 - SVILUPPO SOFTWARE (FLOSS E NON) DA PARTE O PER CONTO DEL COMUNE

( Il Comune detiene la proprietà del software sviluppato#

ELEVATO

MODERATO

NESSUN

UTILIZZO

UTILIZZO

UTILIZZO

TOTALE %

DI FLOSS

DI FLOSS DI FLOSS (IUFLOSS>20%) (IUFLOSS<20%) (IUFLOSS=0%)

89%

Tipologia software sviluppati (n.)* 10 Sw “Sw general pourpose” 8 Sw “specializzato” 6 Sw “dedicato”

67%

0%

73%

4 1 4

1 1 2

15 10 12

)

Fonte: EROSS 2008, Note: # La % è calcolata sul totale Comuni che hanno sviluppato o fatto sviluppare software. * erano possibili più risposte

31

percentuale si riduce drasticamente, arrivando all’8% per i Comuni che fanno moderato uso di FLOSS ed al 4% per i non utilizzatori. In Tabella 4 sono forniti alcuni approfondimenti sul tema dello sviluppo di software da parte dei Comuni. Nel 73% dei casi i Comuni che hanno fatto sviluppare software ne detengono la proprietà, la percentuale è dell’89% nel caso degli EELL che fanno elevato utilizzo di FLOSS, e scende allo 0% per i Comuni con iuFLOSS pari a zero. Tale differenza può essere un riflesso di diversi fattori. In primo luogo è rivelatrice di un diverso livello di competenze in materia di software, disparità che si può ritenere esista tra Comuni che utilizzano o non utilizzano FLOSS. In secondo luogo, tra gli altri fattori alla base della diversità osservata, è ipotizzabile che le dimensioni mediamente minori dei Comuni non utilizzatori di FLOSS abbiano un qualche peso26. In ogni caso, il numero di Comuni che hanno sviluppato software all’interno di questa classe di utilizzatori è talmente esiguo da rendere azzardata e difficilmente generalizzabile ogni altra considerazione. I software sviluppati, infine, si dividono abbastanza equamente tra software “general pourpose” utilizzato per finalità generali27, software “specializzato” destinato ad usi specifici28 ,e software “dedicato” usato per eseguire funzioni tipiche dell'Ente29, con una leggera prevalenza della prima tipologia.

In Tabella 5 sono descritti i risultati ottenuti al quesito che richiedeva quale fosse la figura ad avere il peso maggiore nella scelta di quali software (FLOSS e non) acquisire, adottare o acquistare. In termini generali è il responsabile settore ICT ad avere maggior peso (42,5%), seguito da utenti/dipendenti (28,4%) e consulenti esterni (12,3%). Se guardiamo i dati per classi di utilizzatori, mentre nei Comuni che hanno un moderato ed un elevato utilizzo di FLOSS questo schema generale (pur se con diverse percentuali) viene mantenuto, nella classe dei non utilizzatori il peso maggiore nelle scelte riguardanti i software da acquistare e utilizzare spetta ad utenti/dipendenti (33,3%), seguiti da consulenti esterni (23,1%) ed infine dal responsabile del settore ICT (21,8%). Questo dato potrebbe spiegarsi considerando che nei Comuni non utilizzatori, che sono tipicamente Comuni di piccole dimensioni, da un lato non è sempre presente una vera e propria figura di responsabile dei servizi ICT, dall’altro si tratta di Comuni che fanno frequentemente ricorso a servizi esterni di consulenza, il che ovviamente si riflette sul peso relativo nelle scelte in materia di software. La mancanza in molti casi di una figura unica di responsabile ICT in questa classe di Comuni è indirettamente confermata dall’elevato valore della categoria “Altri” (17,9%). Guardando alle specifiche espresse da quanti hanno indicato “Altri” , infatti, si scopre che nella maggior parte dei casi si tratta di “Responsabili dei singoli settori”. In questi casi è quindi il responsabile di ogni settore (ragioneria, anagrafe, ufficio tecnico, ecc…), ad operare la scelta su quali software acquisire ed utilizzare nel proprio ambito di competenza.

TABELLA 5 - FIGURA DI MAGGIOR PESO NELLA SCELTA DI QUALI SOFTWARE (FLOSS E NON) ACQUISIRE O UTILIZZARE NEL COMUNE

TABELLA 6 - ELEMENTI DI OSTACOLO AL CAMBIAMENTO DEL FORNITORE DI SERVIZI ICT DEL COMUNE

( Responsabile settore ICT Utenti/Dipendenti Ragioneria Consulenti esterni Altri

Fonte: EROSS 2008

ELEVATO

MODERATO

NESSUN

UTILIZZO

UTILIZZO

UTILIZZO

TOTALE %

DI FLOSS

DI FLOSS DI FLOSS (IUFLOSS>20%) (IUFLOSS<20%) (IUFLOSS=0%)

48,8% 28,6% 6,0% 7,1% 9,5%

57,0% 23,4% 4,7% 6,5% 8,4%

21,8% 33,3% 3,8% 23,1% 17,9%

42,5% 28,4% 4,8% 12,3% 12,0%

)

(

ELEVATO

MODERATO

NESSUN

UTILIZZO

UTILIZZO

UTILIZZO

OSTACOLI NEL CAMBIO DI FORNITORE

DI FLOSS DI FLOSS DI FLOSS (IUFLOSS>20%) (IUFLOSS<20%) (IUFLOSS=0%)

Nessuno Migrazione archivi/dati Mancanza di altri fornitori competenti sul territorio Knowhow acquisito da personale Vincoli contrattuali Altro Non sa/non risponde

11,90% 75,70%

11,20% 71,70%

15,40% 77,30%

14,30% 81,40% 18,60% 8,60% 4,80%

15,20% 67,40% 17,40% 6,50% 2,80%

15,20% 69,70% 10,60% 6,10% 0,00%

)

Fonte: EROSS 2008. Note: erano possibili risposte multiple.

32

33

In Tabella 6 sono riportati i dati relativi ai principali ostacoli indicati dai Comuni nel caso volessero cambiare i propri fornitori di servizi ICT. Appare evidente che gli ostacoli maggiori per tutti i Comuni, indipendentemente dalla categoria di utilizzatori di FLOSS in cui ricadono, sono rappresentati dalla migrazione di archivi/dati e dal knowhow acquisito dal personale. Questo risultato stupisce in quanto l’adozione di FLOSS dovrebbe accompagnarsi ad una sostanziale riduzione della dipendenza dai fornitori, offrendo nella maggior parte dei casi software che utilizzano standard aperti, facilitando appunto la migrazione degli archivi/dati. Si approfondiscono ora (Tabella 7) alcuni dati più di tipo qualitativo, che descrivono il favore o la contrarietà dei referenti dei Comuni interpellati circa l’opportunità di azioni della PA a favore della diffusione ed adozione di software libero e a codice sorgente aperto nel settore pubblico e privato. TABELLA 7 - AZIONI DELLA PUBBLICA AMMINISTRAZIONE A FAVORE DEL FLOSS (FAVOREVOLI

di una questione “di principio”, per i Comuni che non usano FLOSS la rilevanza relativa dell’aspetto tecnico ed economico è maggiore. La Figura 12 e la Figura 13 registrano i pareri circa alcuni possibili interventi della PA a sostegno del FLOSS, in ambito sia pubblico sia privato. Tutte le azioni che hanno quale destinatario la Pubblica Amministrazione (Figura 12) registrano un consenso positivo superiore al 60% (“assolutamente d’accordo” e “abbastanza d’accorto”). L’attività su cui i pareri favorevoli sono stati maggiori (> 90%) è quella di tipo informativo, mentre l’opzione dell’obbligo di legge è quella relativamente meno “gradita”. Le azioni intraprese dalla PA a favore del FLOSS nel settore privato (Figura 13) ricevono invece un supporto più scarso. Tra tutte le azioni proposte, i sussidi ai privati , fanno registrare sia il più basso tasso di pareri favorevoli (inferiore al 50%), sia il più alto tasso di pareri nettamente contrari (15%). L’analisi delle risposte fornite dai differenti gruppi di Comuni che più o meno intensamente utilizzano FLOSS non presentano differenze sostanziali e significative rispetto alle dinamiche generali.

VS CONTRARI) FIGURA 12 – ESPRESSIONE DI FAVORE/SFAVORE NEI CONFRONTI DI AZIONI A SOSTEGNO DELL’ADOZIONE DEL FLOSS NEL SETTORE PUBBLICO

(

LA PUBBLICA AMMINISTRAZIONE DOVREBBE

ELEVATO

MODERATO

NESSUN

FARSI PROMOTRICE DI AZIONI A FAVORE

UTILIZZO

UTILIZZO

UTILIZZO

DEL FLOSS?

DI FLOSS

DI FLOSS

DI FLOSS

TOTALE %

(IUFLOSS>20%) (IUFLOSS<20%) (IUFLOSS=0%)

)

100%

80% No Sì, in quanto i principi alla base del FLOSS, quale la libera circolazione della conoscenza, sono da ritenersi prioritari nell'agenda della PA Sì, in quanto il FLOSS è tecnicamente superiore ed economicamente vantaggioso Non risponde

9,5%

16,8%

16,7%

14,5%

60%

63,1%

67,3%

46,2%

59,9%

22,6% 4,8%

13,1% 2,8%

33,3% 3,8%

21,9% 3,7%

80%

20%

0% OBBLIGO DI LEGGE

Fonte: EROSS 2008

Se da un lato, come già detto, si registra un consenso generalizzato e sostanzialmente trasversale alle tre classi di utilizzatori riguardo l’eventualità di un ruolo attivo della PA nella promozione e diffusione di FLOSS, c’è una certa differenza nella motivazione alla base di tale assenso. Se per i Comuni con elevato e moderato utilizzo di FLOSS si tratta principalmente

34

REGOLE GENERALI VALIDE PER TUTTE LE PA

ASSOLUTAMENTE FAVOREVOLE ABBASTANZA FAVOREVOLE ABBASTANZA CONTRARIO ASSOLUTAMENTE CONTRARIO NON SA, NON RISPONDE

REGOLE AMMINISTRATIVE E LINEE GUIDA INTERNE DEFINITE DALLE SINGOLE PA

ATTIVITÀ ED INIZIATIVE INFORMATIVE

Fonte: EROSS 2008

35

FIGURA 13 - ESPRESSIONE DI FAVORE/SFAVORE NEI CONFRONTI DI AZIONI A SOSTEGNO

Per concludere questa descrizione dei dati raccolti, si riportano in Tabella 8, per tutte le tipologie di software censite, l’elenco dei prodotti FLOSS utilizzati ed il numero di Comuni che ne fanno un uso esclusivo. Se supponiamo di accettare l’idea che “maggiore è il numero di utilizzatori esclusivi, migliore la qualità del software”, allora i FLOSS giudicabili qualitativamente migliori sono quelli utilizzati per i server, e nello specifico gli application server (che in 63 Comuni sono esclusivamente free o open source). A questa valutazione occorre però affiancare un’altro principio operativo che influisce sull’adozione (specie se esclusiva di FLOSS) e cioè che “più si influenza il lavoro quotidiano dell’utilizzatore finale più sono gli ostacoli al passaggio al FLOSS”. Quest’ultima considerazione spiega o almeno motiva il basso numero Comuni che utilizzano in modo esclusivo FLOSS lato client/desktop.

DELL’ADOZIONE DEL FLOSS NEL SETTORE PRIVATO

100%

80%

60%

40%

20%

0% ATTIVITÀ DI FORMAZIONE FINALIZZATE ALL'ADDESTRAMENTO DI SVILUPPATORI/TECNICI COMPETENTI

COORDINAMENTO E PROMOZIONE DI PROGETTI FLOSS

ASSOLUTAMENTE FAVOREVOLE ABBASTANZA FAVOREVOLE

SUSSIDI E FINANZIAMENTI

COINVOLGIMENTO DIRETTO ALLO SVILUPPO E ALLA FORNITURA DI SOLUZIONI FLOSS

ABBASTANZA CONTRARIO ASSOLUTAMENTE CONTRARIO NON SA, NON RISPONDE

Fonte: EROSS 2008

Considerazioni generali sui risultati dell’analisi descrittiva Le modalità di indagine scelte (questionario on line e contatti telefonici, campionamento ed elevata rappresentatività) e la metodologia EROSS (elaborazione dell’indice di intensità di utilizzo, focus su software client/desktop e server, integrazione tra basi dati diverse, ecc…) hanno permesso di giungere ad una chiara e veritiera descrizione delle scelte in campo software operate dai Comuni emiliano-romagnoli. In sintesi quindi:

TABELLA 8 - SOFTWARE FLOSS IN USO NEI COMUNI DELL'EMILIA-ROMAGNA

(

AMBITO DI UTILIZZO

FLOSS IN USO NEI COMUNI EMILIANO-ROMAGNOLI

Sistema operativo per il desktop Gnu-Linux Mozilla Thunderbird, Evolution Software di Gestione di posta Mail, Netscape Messenger elettronica Mozilla Firefox, Netscape Navigator, Mozilla, Flock Browser Internet OpenOffice, Scribus Office Automation Quantum Gis, MapServer Sit/Gis Apache Web Server Apache Tomcat, PHP, Jboss, Zope, Xaraya, Perl Application Server Postfix, Cyrus IMAP server, Qmail, Send Mail, Open-Xchange, Exim, HMailServer, Dovecot Mail Server Samba, FreeNAS File Server VNC, PuTTY, Open SSH, Xorg X11 Server di desktop remoto Data base management systems MySQL, PostgreSQL, In gres Linux/CUPS, LPRng Printer server

COMUNI CHE USANO ESCLUSIVAMENTE FLOSS 0% 2% 1% 1% 1% 6% 20%

9% 4% 4% 3% 1%

)

• il 63% dei Comuni dell’Emilia-Romagna ha esplicitamente dichiarato di usare free, libre, open source software (34,4% è la media nazionale); • un ulteriore 14% di Comuni della regione, pur essendosi dichiarati non utilizzatori, risultano invece avere installazioni di FLOSS e si configurano come utilizzatori inconsapevoli (e quindi portatori di un gap di conoscenza). • in totale, quindi, il 77% dei Comuni (quasi quattro su cinque) utilizza FLOSS negli ambiti applicativi indagati (client/desktop e server); • oltre un Comune su dieci ha adottato un atto di indirizzo strategico o amministrativo avente ad oggetto l’adozione di software free, libre, open source. Dimostrazione che l’attenzione per il FLOSS travalica anche i confini settoriali dei sistemi informativi per diventare oggetto di riflessioni ampie e trasversali all’ente; • l’intensità di utilizzo di FLOSS (iuFLOSS) è più elevata nelle fasce dimensionali di Comuni che stanno agli estremi (Comuni molto piccoli - <3.000 ab. e Comuni grandi - >15.000 ab.); • le differenze tra territori provinciali sono evidenti sia dal punto di vista generale che sugli aspetti specifici e quindi sull’intensità di utilizzo FLOSS riferita ai singoli ambiti applicativi del software;

Fonte: EROSS 2008 36

37

• l’indice di intensità di utilizzo è pari a zero nel 29% dei Comuni (che non fanno alcun uso di FLOSS), compreso tra zero e 20% nel 39,8% dei casi (a dimostrazione di un moderato utilizzo di software libero o a codice sorgente aperto), e superiore a 20% nel 31,2% degli enti osservati (che dimostrano di fare elevato utilizzo di free, libre, open source software); • l’intensità di utilizzo dei software client/desktop dei Comuni dell’EmiliaRomagna mostraì come il sistema operativo FLOSS GNU/Linux non sia ad oggi pensato ed utilizzato quale alternativa vera al leader di mercato proprietario. Molto differenti sono, invece i risultati relativi ai navigatori per il Web e ai pacchetti per la produttività personale per i quali si riscontrano elevati livelli di iuFLOSS ed un numero considerevole di Comuni che ne fanno un uso esclusivo. In generale, nonostante gli evidenti distinguo, le postazioni client/desktop degli operatori della PA sono ancora dominate da sistemi software proprietari; • l’intensità di utilizzo dei software server sottolinea come il FLOSS sia oramai un prodotto maturo e molto diffuso in questo ambito. Gli application server e i DBMS (data base management system) presentano prevalenza di software free, libre, open source che in molti casi risultano utilizzati in modo esclusivo; • il numero di installazioni FLOSS è in valore assoluto maggiore nel lato client, ma l’utilizzo è certamente più intenso sul lato server; • ad aver maggior peso nella scelta di quale software (FLOSS e non) acquisire e utilizzare sono nell’ordine il responsabile del settore ICT, gli utenti/dipendenti e i consulenti esterni; • c’è un generale accordo, tra i rispondenti, sull’opportunità di politiche attive dalla PA a favore del FLOSS, con le ragioni di “principio” che prevalgono su quelle tecnico-economiche; • tra le possibili azioni i maggiori consensi vanno alle “attività e iniziative formative”, mentre i minori ai “sussidi a favore di privati che operano in campo FLOSS”.

Analisi avanzata Come già fu fatto in occasione della rilevazione EROSS 2006, anche in quella del 2008 sono state effettuate una serie di analisi avanzate volte, da un lato, a verificare i risultati raggiunti nell'edizione precedente30 e, dall'altro, ad approfondire tali risultati. In particolare si è proceduto a: • testare un primo modello econometrico lineare, ove un indicatore del livello di interattività dei servizi on line offerti dalle pubbliche amministrazioni emiliano-romagnole è stato fatto dipendere da una serie di variabili ritenute rilevanti;

38

• testare un secondo modello econometrico, questa volta a carattere non lineare, introdotto per individuare i fattori atti a spiegare l'adozione di software a codice sorgente aperto da parte delle stesse pubbliche amministrazioni; • integrare i due modelli in una specificazione che prendesse in considerazione entrambe le caratteristiche, lineare e non, in modo da dar conto della probabile presenza di endogeneità31.

Modello I Il primo modello, in linea con quello proposto nel 2006, ha cercato di mettere in luce quali siano i fattori atti a spiegare il livello di interattività dei servizi on line offerti dai Comuni emiliano-romagnoli (variabile dipendente). Si è provveduto quindi a testare due diverse specificazioni del modello teorico, rispettivamente specificazione [a] e specificazione [b] in Tabella 9, contenenti una serie di fattori (variabili indipendenti). TABELLA 9 - MODELLO I – FATTORI CHE INFLUENZANO IL LIVELLO DI INTERATTIVITÀ DEI SERVIZI OFFERTI ON LINE

(

Specificazione [a]

Specificazione [b]

VARIABILE DIPENDENTE Interattività servizi on line

VARIABILE DIPENDENTE Interattività servizi on line

VARIABILI INDIPENDENTI • spesa totale in software e hardware • numero di dipendenti nella divisione ICT • spesa in formazione ICT per il personale • numero di dipendenti della PA • adozione di software a codice sorgente aperto • esistenza di una strategia di e-government • disponibilità di accesso alla rete in banda larga • presenza di una carica politica con delega all'informatica/telematica • esistenza di una strategia di ICT

VARIABILI INDIPENDENTI • spesa totale in software e hardware • numero di dipendenti nella divisione ICT • spesa in formazione ICT per il personale • numero di dipendenti della PA • esistenza di un atto di indirizzo rivolto all'adozione di software a codice sorgente aperto • esistenza di una strategia di e-government • disponibilità di accesso alla rete in banda larga • presenza di una carica politica con delega all'informatica/telematica • esistenza di una strategia di ICT

)

Fonte: EROSS 2008

Il risultati sono pressoché identici per ambedue le specificazioni, salvo che per la significatività della variabile evidenziata. In particolare, il livello di interattività è spiegato principalmente dalla dimensione del Comune e dalla spesa in formazione in ICT effettuata da quest’ultimo. Inoltre, mentre

39

l'adozione di software a codice sorgente aperto (FLOSS) non risulta significativa nello spiegare il livello di interattività, l'esistenza di un atto di indirizzo formale in questa direzione è altamente significativa e quantitativamente importante (di entità pari alla dimensione della PA).

Modello II Sulla base dei risultati ottenuti con il primo modello circa l'importanza di un atto di indirizzo formale nello spiegare il livello di interattività dei servizi on line, il secondo modello è stato a tal fine articolato su due specificazioni alternative, volte a investigare più nel dettaglio i fattori (variabili indipendenti) che: (1) spiegano la probabilità di adozione di software libero o a codice sorgente aperto (specificazione [a] in Tabella 10); (2) spiegano la probabilità per il soggetto di adottare un atto di indirizzo formale nei confronti del software a codice sorgente aperto (specificazione [b] in Tabella 10).

I risultati indicano chiaramente come la presenza di una carica politica con delega all'informatica e/o alla telematica sia una variabile significativa nello spiegare sia la probabilità di adozione di FLOSS che la presenza di un atto formale di indirizzo verso il FLOSS. Ma mentre la prima probabilità è influenzata in modo marginale dalla presenza di un assessore, la seconda risulta fortemente influenzata dalla presenza dello stesso32.

Considerazioni generali risultati sui risultati dell’analisi avanzata Da quanto detto finora si può quindi asserire che i risultati principali ottenuti dall'analisi condotta nel 2006 sono validi anche con i nuovi dati (che permettono di superare uno dei punti deboli della precedente analisi, ovvero il livello di rappresentatività dell’universo di osservazione). Non si ottiene solo la conferma dei risultati precedentemente ottenuti, ma anche un arricchimento dell'analisi precedente che fornisce anche nuovi spunti per studi futuri. Questa la sintesi dei risultati ottenuti:

TABELLA 10 - MODELLO II - FATTORI CHE INFLUENZANO L'ADOZIONE DI FLOSS, SPECIFICAZIONE [A], E L'ESISTENZA DI UN ATTO DI INDIRIZZO VERSO IL FLOSS, SPECIFICAZIONE [B].

(

Specificazione [a]

Specificazione [b]

VARIABILE DIPENDENTE Adozione di software a codice sorgente aperto

VARIABILE DIPENDENTE Esistenza di un atto di indirizzo rivolto all'adozione di software a codice sorgente aperto

VARIABILI INDIPENDENTI • spesa in licenze software • necessità di personalizzazione delle applicazioni software • dipendenza dai fornitori • numero di dipendenti nella divisione ICT • numero di dipendenti della PA • disponibilità di accesso alla rete in banda larga • presenza di una carica politica con delega all'informatica/telematica • esistenza di una strategia di ICT • esistenza di una strategia di e-government • figura interna che decide sull'acquisto del software

VARIABILI INDIPENDENTI • spesa in licenze software • necessità di personalizzazione delle applicazioni software • dipendenza dai fornitori • numero di dipendenti nella divisione ICT • numero di dipendenti della PA • disponibilità di accesso alla rete in banda larga • presenza di una carica politica con delega all'informatica/telematica • esistenza di una strategia di ICT • esistenza di una strategia di e-government • figura interna che decide sull'acquisto del software

)

• esiste una relazione positiva tra il livello di interattività dei servizi online e l'adozione di FLOSS da parte dei Comuni emiliano-romagnoli (EROSS 2006 e EROSS 2008); • tale relazione è rilevante solo se il Comune ha posto in essere un atto di indirizzo teso a favorire l'adozione di FLOSS (EROSS 2008); • la scelta di utilizzare FLOSS da parte dei Comuni emiliano-romagnoli matura in maniera autonoma e sulla base di competenze specifiche sviluppate dall'ente (EROSS 2006 e EROSS 2008); • l'unico fattore in grado di spostare gli equilibri in favore dell'adozione di FLOSS è la presenza di una figura all'interno dell'ente che abbia competenze specifiche nel campo e con un potere decisionale forte (EROSS 2008). Concludendo, la presenza di un atto formale a favore del FLOSS e la presenza di una persona che abbia sufficiente potere decisionale per proporre e supportare nel tempo tale decisione sono condizioni necessarie, ma non sufficienti, per incentivare il livello di interattività dei servizi online dei Comuni emiliano-romagnoli e per aumentare la probabilità di adozione del FLOSS all'interno degli stessi. Questo risultato conferma, dal lato empirico, ciò che fino ad ora è sempre stato proposto da un punto di vista teorico, ovvero che, per avere una diffusione capillare del FLOSS e perché questa dia dei frutti in termini di servizi ai cittadini, è necessaria una scelta strategica formalizzata e supportata adeguatamente.

Fonte: EROSS 2008

40

41

2 Capitolo 2: il FLOSS nei progetti del Piano telematico dell’Emilia-Romagna (PiTER) Nel maggio del 2007, l’Assemblea regionale ha approvato a maggioranza l’Atto di indirizzo politico n.2297/1. L’atto invita la Giunta Regionale, nell'ambito dell’attuazione del Piano telematico dell’Emilia-Romagna (PiTER) 2007-200933, e nello specifico della strategia FLOSS, a individuare alcuni progetti di particolare valore che possano essere di utile esempio per le altre amministrazioni, e sappiano coinvolgere la cittadinanza e gli altri portatori di interesse (scuola, enti di ricerca, società civile, associazioni di categorie, imprese, ecc.) per la loro realizzazione e partecipazione. In risposta a tale richiesta, il progetto EROSS ha quindi prodotto un quadro informativo che dà conto dell’uso e della diffusione di software libero e a codice sorgente aperto tra i 72 progetti del Programma Operativo 2008 del PiTER. Il Piano telematico dell’Emilia-Romagna 2007-2009 si differenzia dalle programmazioni precedenti in quanto agisce sull’intero territorio regionale, coinvolgendo tutte le Amministrazioni Pubbliche (Regione, Province, Comuni e loro forme di aggregazione) e riconoscendo elevato valore alle dinamiche di cooperazione e collaborazione tra enti, nonché alle pratiche di “riuso” di soluzioni tecniche e tecnologiche, come pure di competenze e conoscenza.

Metodologia di indagine I quesiti che sono stati utilizzati per la rilevazione sono stati elaborati e rivisti con il contributo di alcuni capi progetto, al fine di aderire nel migliore dei modi alle differenti caratteristiche degli interventi previsti nel PiTER ed allo scopo di eliminare eventuali ambiguità. Una scelta metodologica di fondo è stata quella di non operate differenziazioni tra progetti di tipo infrastrutturale, applicativo o di tipo altro genere e di prediligere la forma “chiusa” come opzione di risposta. Lo strumento scelto per raccogliere i dati è stato, quindi, quello del questionario online che, sottoposto ai capi progetto nel periodo giugno-luglio 2008, ha portato ad ottimi risultati con un tasso di risposta del 95% (delle 3 risposte mancanti, due riguardano progetti in rimodulazione in quanto strettamente connessi all’erogazione di fondi nazionali bloccati).

Analisi descrittiva La maggior parte dei progetti del PiTER, Figura 14 [a], prevede l’acquisizione o sviluppo di software (quasi il 70%). Restano escluse quelle azioni

42

prettamente infrastrutturali (reti fisiche) e quelle che mirano all’inclusione, misurazione di scenario e monitoraggio34. Riportando il medesimo risultato ri-parametrizzato sulla base del valore economico dei progetti, Figura 14 [b], il rapporto muta presentando un sostanziale equilibrio tra i progetti che si occupano di software e non (49% e 51%). FIGURA 14 – ACQUISIZIONE E/O LO SVILUPPO DI SOFTWARE NEI PROGETTI DEL PITER

[a] n. Progetti PiTER

[b] valore economico Progetti PiTER

28¤ M¤ 12% 6¤ M¤ 3%

13% 17% 26%

70%

43%

51%

40% 4%

82¤ M¤ 36% 6%

Il progetto prevede l’acquisizione e/o lo sviluppo di software: Non risponde No Sì, prevalentemente proprietario Sì, prevalentemente free, libre o open source Sì, prevalentemente di proprietà della PA Fonte: EROSS-PITER 2008

Il criterio della “prevalenza” adottato per le risposte affermative (riportate in Figura 14) è stato scelto nella consapevolezza che, con rare eccezioni, nella realizzazione di progetti complessi si prevede l’acquisizione e/o sviluppo di software sia proprietario che free, libre o open source che di proprietà della PA. La prevalenza dovrebbe in questo senso dar maggior peso e quindi far emergere la scelta strategica operata dal capo progetto. Nell’ambito dei progetti del PiTER che prevedono l’acquisizione o lo sviluppo di software è possibile notare come la maggior parte di questi preveda la prevalenza di software di proprietà della PA. In tal senso i capi progetto garantiscono, anche in coerenza con quanto indicato all’art.69 del Codice dell’Amministrazione Digitale35, la massima disponibilità del software che potrà essere distribuito ad altre amministrazioni o riutilizzato senza l’obbligo di pagare licenze d’uso proprietari, e al quale potrebbe essere propriamente apposta una licenza free o open source (qualora si volessero cogliere i vantaggi di uno sviluppo collaborativo tra settore pubblico e privato).

43

Ulteriore aspetto che emerge evidente in Figura 14 è che se in termini numerici i progetti che impiegano prevalentemente FLOSS (17%) sono più di quelli che dichiarano di utilizzare in prevalenza software proprietario (13%), tale rapporto varia e di molto (3% FLOSS e 12% proprietario) se ci si focalizza sul valore economico degli stessi progetti.

FIGURA 15 – PROGETTI CHE PREVEDONO ACQUISIZIONE E/O LO SVILUPPO DI SOFTWARE DISTINTI SULLA BASE DELLA PREVALENZA DELLA TIPOLOGIA DI SOFTWARE

[a] Percentuale del budget del progetto destinata all’acquisizione e/o sviluppo di software

100%

Approfondendo quest’ultimo aspetto, Figura 15, si può notare come le scelte dei capi progetto varino in funzione dell’aumentare del valore generale del progetto ed anche in rapporto all’aumentare della percentuale di budget di progetto destinata all’acquisizione e/o sviluppo di software. In generale, oltre il 45% dei progetti che compongono il primo percentile della Figura 15 [b] utilizzano soluzioni FLOSS; mano a mano però che il valore dei progetti sale, questa opzione viene completamente abbandonata a favore dei software di proprietà della PA e proprietari. Di fronte a progetti il cui budget è molto rilevante, e in cui è particolarmente significativo il peso della componente software, il capo progetto del PiTER opta per soluzioni di cui detiene o prevede di acquisire la proprietà. Nonostante il software libero e a codice sorgente aperto non rappresenti l’opzione software prevalente nella realizzazione dei progetti del PiTER, alcuni tra i più famosi prodotti FLOSS sono diffusamente utilizzati in una elevata percentuale di interventi. Come si nota in Figura 16, sistemi per i server come Apache, MySQL, PostgreSQL, Jboss, Tomacat e Linux sono tutti utilizzati in oltre un progetto su quattro, ed in alcuni casi in più della metà. Questo risultato evidenzia e conferma come tali prodotti siano da considerare qualitativamente affidabili e maturi.

90% 80% 70% 60% 50% 40% 30% 20% 10% 0% A. meno del 5%

B. tra il 6% e il 15%

C. tra il 16% e il 50%

D. oltre il 50%

[b] Valore economico del progetto (percentili*)

100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Percentile 1

Percentile 2

Percentile 3

Percentile 4

Software proprietario Software free, libre o open source Software di proprietà della PA Fonte: EROSS-PITER 2008. * Nota: i percentili del grafico [b] sono calcolati su base 0,25 e quindi distinguono i progetti in quattro gruppi composti dallo stesso numero (o quasi) di osservazioni ordinate secondo il valore economico del progetto.

44

45

Sono 42 i progetti che dichiarano di sviluppare software che potrebbe essere proficuamente riusato da altre amministrazioni (si tratta dell’84% dei progetti che prevedono acquisizione e/o sviluppo di software). La maggior parte di questo software è di tipo “specializzato”, destinato ad usi specifici (sicurezza, gestione e manutenzione server, CMS, Intranet, ecc.), e/o “dedicato”, cioè usato per eseguire funzioni tipiche della Pubblica Amministrazione (protocollo informatico, posta elettronica certificata, firma digitale, ecc...). Dal punto di vista della proprietà del codice, sono tre i progetti che non la detengono e che quindi non possono attuare forme di “riuso”; 25 ne sono proprietari e perciò possono legittimamente cedere o trasferire il diritto all’utilizzo del software; e 14 (uno su tre) ammettono di non sapere con esattezza di chi sia la proprietà del programma informatico.

FIGURA 16 – SOFTWARE FREE O OPEN SOURCE UTILIZZATI NEI PROGETTI DEL PITER (% PROGETTI CHE PREVEDONO ACQUISIZIONE E/O LO SVILUPPO DI SOFTWARE)

60% 50% 40%

30% 20% 10%

FIGURA 17 - RAGIONI/VALUTAZIONI CHE GUIDANO LA SCELTA DEL CAPO PROGETTO CIRCA LA TIPOLOGIA DI SOFTWARE DA ACQUISIRE E/O SVILUPPARE

0% Linux

Apache

MySQL/PostgreSQL

Tomcat

JBoss

Progetti che utilizzano in prevalenza software di proprietà della PA Progetti che utilizzano in prevalenza software free, libre o open source Progetti che utilizzano in prevalenza software proprietario

[a] Percentuale del budget del progetto destinata all’acquisizione e/o sviluppo di software

100% 90%

Fonte: EROSS-PITER 2008

80% 70%

Le principali ragioni/valutazioni che guidano la scelta sulla tipologia di software possono aiutare a comprendere il perché della predilezione per quello di proprietà della Pubblica Amministrazione. In modo forse sorprendente, come si apprezza dai grafici di Figura 17 [a] e [b], esiste una sorta di equilibrio fra coloro che guidano le proprie scelte sulla base di motivazioni legate alle funzioni/prestazioni, e coloro che pongono particolare attenzione agli aspetti di costi/benefici. Praticamente nessun capo progetto, invece, si affida all’esperienza e alle motivazioni di tipo personale o alla consistenza dei costi di acquisizione, aspetto questo che evidenzia l’approccio analitico con cui le scelte vengono realizzate. Differenze interessanti possono comunque essere rilevate per quei progetti che prevedono un ridotto impatto della componente software sul budget totale di progetto, e per i quali è sostanzialmente dominante il criterio della valutazione delle funzioni/prestazioni potenziali e future. Da notare inoltre come i progetti del primo percentile (Figura 17 [b]), per i quali quasi la metà dei capi progetto hanno scelto FLOSS (Figura 15), pongono più attenzione degli altri agli aspetti funzionali e prestazionali attuali del software. 46

60% 50% 40% 30% 20% 10% 0% A. meno del 5%

B. tra il 6% e il 15%

C. tra il 16% e il 50%

D. oltre il 50%

funzioni/prestazioni attuali del software funzioni/prestazioni potenziali e future del software esperienza e a motivazioni personali costi di acquisizione costi/benefici pluriennali

47

[b] Valore economico del progetto (percentili*)

FIGURA 18 - ESPRESSIONE DI FAVORE/SFAVORE NEI CONFRONTI DI AZIONI A SOSTEGNO DELL’ADOZIONE DEL FLOSS

100 90

[a] settore pubblico

80

100%

70 60 75% 50 40 50% 30 20 25%

10 0 Percentile 1

Percentile 2

Percentile 3

Percentile 4

0% funzioni/prestazioni attuali del software funzioni/prestazioni potenziali e future del software esperienza e motivazioni personali costi di acquisizione costi/benefici pluriennali

OBBLIGO DI LEGGE

REGOLE GENERALI VALIDE PER TUTTE LE PA

REGOLE AMMINISTRATIVE E LINEE GUIDA INTERNE DEFINITE

ATTIVITÀ ED INIZIATIVE INFORMATIVE

COORDINAMENTO E PROMOZIONE DI PROGETTI FLOSS

SUSSIDI E FINANZIAMENTI

COINVOLGIMENTO DIRETTO ALLO SVILUPPO E ALLA FORNITURA DI SOLUZIONI FLOSS

[b] settore privato

100% Fonte: EROSS-PITER 2008. * Nota: i percentili del grafico [b] sono calcolati su base 0,25 e quindi distinguono i progetti in quattro gruppi composti dallo stesso numero (o quasi) di osservazioni ordinate secondo il valore economico del progetto.

La mancanza di una chiara informazione su chi detiene i diritti di un prodotto software che “potrebbe proficuamente essere riusato da altre amministrazioni” esprime una carenza nella gestione prospettica dei prodotti di progetto giustificata però dalla complessità che, in alcuni casi, li caratterizza. Spesso infatti, l’utilizzo contemporaneo di componenti proprietarie, free o open source ed autentiche di proprietà della PA porta alla creazione di soluzioni software ibride, per le quali non è chiaro (e non viene chiarito) il livello di trasferibilità e legittimo riuso. Per concludere, in Figura 18 sono rappresentate le opinioni dei capi progetto del PiTER circa l’opportunità di interventi della PA a favore del FLOSS nel settore pubblico e privato (i quesiti sono i medesimi proposti ai Comuni e descritti in Figura 12 e Figura 13). Come si nota, Figura 18 [a], vi è elevato favore verso l’ipotesi che la PA si impegni in attività ed iniziative informative e nella definizione di regole generali valide per tutta la PA. Sono invece meno sostenute le altre opzioni di intervento proposte. Sul fronte del settore privato, Figura 18 [b], si riscontra un minor favore, specie per ipotesi di sussidi e finanziamenti, che però raggiunge livelli molto elevati nel caso di coordinamento e promozione di progetti FLOSS. 48

75%

50%

25%

0% ATTIVITÀ DI FORMAZIONE FINALIZZATE ALL'ADDESTRAMENTO DI SVILUPPATORI/ TECNICI COMPETENTI

assolutamente favorevole abbastanza favorevole

abbastanza contrario assolutamente contrario non sa, non risponde

Fonte: EROSS-PITER 2008.

49

3 Considerazioni generali L’analisi dei dati raccolti da EROSS circa l’acquisizione e lo sviluppo di software nei progetti del Piano telematico dell’Emilia-Romagna 20072009 pone in evidenza che: • i project manager prediligono componenti informatiche di proprietà della Pubblica Amministrazione e quindi, nonostante il free, libre, open source software sia largamente diffuso ed utilizzato (ma non prevalentemente), i prodotti software acquisiti e/o sviluppati nel PiTER saranno per lo più di proprietà pubblica; • il FLOSS è utilizzato in modo prevalente in quei progetti che hanno un valore relativamente basso e/o in cui l’attività di acquisizione e/o sviluppo software influisce marginalmente sul budget di progetto; • l’84% dei progetti che acquisisce e/o sviluppa software ritiene di produrre codice che potrebbe proficuamente essere riutilizzato da altre amministrazioni ma un numero non irrilevante non ha chiarezza su chi ne sia il legittimo proprietario; • esiste un sostanziale favore per azioni di supporto all’adozione del FLOSS nel settore pubblico (in particolare per attività di tipo informativo) e in quello privato (nel coordinamento e promozione di progetti FLOSS); • i progetti del PiTER, pur detenendo nella maggior parte dei casi la proprietà del software acquisito e/o sviluppato, non hanno previsto azioni che chiariscano nel dettaglio quali componenti del codice siano sottoposti a licenza (proprietaria o FLOSS) e quali invece possano essere “licenziati” (magari FLOSS) dalla PA in modo da favorire politiche di riuso e standardizzazione.

50

Capitolo 3: esperienze e casi d’uso Il software libero a codice sorgente aperto è frequentemente utilizzato nei Comuni e negli altri EELL dell’Emilia-Romagna, e spesso elementi FLOSS sono alla base dei sistemi informativi che vengono progettati e realizzati nell’ambito di importanti e impegnativi progetti di e-government. Di seguito sono riportate alcune significative esperienze che hanno interessato Pubbliche Amministrazioni emiliano-romagnole.

Regione Emilia-Romagna DG Centrale Organizzazione, Personale, Sistemi informativi e Telematica Fabio Bucciarelli e Alessandro Landi Servizio Sistema informativo-informatico regionale

Sono alcuni anni che la Regione Emilia-Romagna sta valutando l’uso del software free e/o open source sia nell'area client che nell'area server, ancor più da quando le linee guida del CNIPA e il Codice dell’Amministrazione Digitale prescrivono che nella scelta di un nuovo software devono essere considerati in primis prodotti appunto open source. Per quel che riguarda l'area server quindi, già da diversi anni sono presenti alcuni server Linux che gestiscono applicazioni Web attraverso Apache, PHP/Perl e MySQL. Nel corso del 2006 e del 2007, il numero di server che utilizzavano FLOSS è andato via via aumentando. Ad esempio è stato scelto di installare come server regionale FTP sicuro un server Linux basato su Linux Red Hat e Proftpd. La flessibilità del software free o open source ha permesso di crittografare tutte le comunicazioni FTP e, tramite alcuni prodotti software e al sistema di autenticazione di Linux altamente configurabile, è stato possibile integrare l'autenticazione degli utenti con i domini di autenticazione regionali sia interno che esterno (basati su tecnologia Microsoft Active Directory). È stata infine creata un'applicazione Web basata su Apache e PHP per facilitare l'amministrazione del server FTP. Nel corso del 2007 quindi, si era già raggiunto un buon livello di maturità che ha reso praticabile l’inserimento di una filiera FLOSS, tra quelle appli-

51

cative supportate dal CED regionale. Si è quindi proceduto ad uno studio di fattibilità al fine di individuare i prodotti software da includere in tale filiera. Pur non avendo intenzione di abbandonare la cosiddetta filiera LAMP (da Linux, Apache, MySql, PHP/Perl/Python), sulla quale vi erano già buone competenze ma che non si ritiene adatta per applicazioni di tipo “enterprise”, è stato deciso di concentrarsi su una filiera compatibile con le specifiche Java Enterprise (J2EE) da affiancare alla corrispettiva filiera commerciale già supportata e realizzata con i software MS Windows, Oracle e IBM WebSphere. Si è trattato quindi di valutare la fattibilità dell'introduzione di FLOSS per le seguenti categorie di software: (a) sistema operativo, (b) application server compatibile J2EE, (c) data base management system relazionale (DBMS), e di scegliere per ogni categoria il prodotto più adeguato. I criteri di scelta adottati hanno tenuto in considerazione, oltre al confronto di tutti gli aspetti tecnico/funzionali, anche i rischi derivanti da un'eventuale adozione per gestire processi critici. Occorreva quindi tenere conto di fattori quali: il livello di maturità della soluzione software, la qualità e quantità di documentazione, l'attività, consistenza e indipendenza del team di sviluppo, i servizi di supporto, e così via. Al fine di ridurre il livello di soggettività nella scelta, è stata ricercata una metodologia già collaudata nella valutazione di FLOSS. Sorprendentemente, sono molte le metodologie elaborate e disponibili. Tra queste, quella che si è ritenuto facesse più al caso è stata la QSOS - Qualification and Selection of Open source Software36, metodologia a sua volta open source che adotta un approccio pratico e soprattutto mantiene al suo interno una comunità attiva, fornendo anche numerosi strumenti a supporto di chi vuole valutare software free o open source. In breve, questo metodo prevede quattro fasi che possono anche essere ripetute ciclicamente, ogni volta con un dettaglio maggiore, predisponendo delle griglie multi-livello di valutazione contenenti criteri di valutazione sia generali che specifici per ciascuna categoria di software, assegnando poi per ogni voce punteggi e pesi, fino ad operare la scelta finale. Lo studio effettuato ha portato a concludere che per quanto riguarda sistema operativo e java application server i prodotti FLOSS sono maturi e non inferiori ai corrispettivi prodotti proprietari: per tali categorie sono stati scelti Linux Red Hat e Jboss Application Server. Per quanto riguarda invece i database relazionali, pur non mancando soluzioni valide e affidabili, la valutazione realizzata ha evidenziato che le funzionalità non sono ancora al livello delle principali soluzioni proprietarie. Difficoltosa è stata la scelta tra MySql e PostgreSql, in quanto i punteggi ottenuti dai due prodotti con il metodo QSOS sono stati molto simili. La preferenza è caduta su PostgreSql.

52

In seguito a questo studio di fattibilità, per il 2008 la filiera Java Open Source scelta (oltre a quella LAMP) è entrata “ufficialmente” a far parte delle “Linee guida per la governance del sistema informatico regionale”. Nelle quali sono ora individuate tre filiere supportate per applicazioni e siti Web basate su architetture a tre livelli: • filiera A: applicazioni basate su tecnologia JAVA; • filiera B: applicazioni basate su tecnologia Microsoft; • filiera C: applicazioni basate su tecnologia open source. Nell'ambito della filiera A sono supportati tre stack tecnologici: quello basato su piattaforma Microsoft (Windows 2003, Microsoft IIS, IBM WebSphere, Oracle), quello basato su piattaforma Linux (Linux Red Hat, Apache, Jboss, PostgreSql) e quello basato su piattaforma RISC/AIX (IBM AIX, IBM WebSphere, Oracle). Per quanto riguarda la filiera applicativa C, lo stack tecnologico è implementato su piattaforma Linux (Linux RedHat, Apache, PHP, MySQL o PostgreSql). Da rilevare che, nel corso dell’ultimo anno, si è assistito ad un graduale incremento delle applicazioni rese disponibili su tale ambiente. Dal punto di vista pratico l’obiettivo per il 2008, al fine di razionalizzare i sistemi, è la predisposizione di un ambiente di test in alta affidabilità costituito da un cluster di server virtuali Vmware Virtual Infrastructure con sistema operativo Red Hat e Application Server Jboss e da un ambiente di produzione anch'esso in alta affidabilità costituito però da nodi fisici. Per ora rimane comunque la possibilità, per le applicazioni che utilizzano questa filiera, di usare Oracle come DBMS. Per quel che riguarda l'adozione di PostgreSQL, sempre per il 2008 si prevede di mettere in produzione un cluster a disposizione del Sistema Informativo della Protezione Civile (il supporto ai database territoriali è infatti uno dei punti di forza di PostgreSQL). Sempre tra gli obiettivi del 2008, inoltre, ci sono la scelta di un prodotto di groupware open source da utilizzare all'interno della Regione e da parte delle Comunità Territoriali, e di un prodotto FLOSS per la gestione dei contenuti di siti e applicazioni Web. Inoltre tutti i nuovi tipi di progetti multiregionali per l'e-government supportati dal CNIPA, già avviati e che avranno un forte sviluppo nei prossimi anni, quali Sigmater, Sistema Informativo Lavoro, interoperabilità delle applicazioni (porta di dominio) sono fortemente basati su tecnologie open source e open standard (almeno per quanto concerne lo stack tecnologico legato all’applicazione; non è sempre così sul fronte database).

53

Complessivamente, dopo un anno di supporto ai progetti di e-goverment promossi dal CNIPA e di applicazione delle linee guida nel rispetto delle tre filiere, si è verificata una decisa crescita verso lo sviluppo di applicazioni “open standard” compatibili con la filiera applicativa A su piattaforma Linux. Per il futuro si prevede un progressivo percorso di convergenza, per tutte le applicazioni J2EE, verso la filiera applicativa A su piattaforma Linux RedHat (application server JBOSS). Ciò vale sia per le applicazioni non critiche per l’Ente Regione che per le applicazioni che costituiscono (e costituiranno) l’ossatura del sistema informativo regionale. Per quel che riguarda l'area client, è stato avviato un percorso che prevede lo studio di fattibilità per l'adozione di Open Office come strumento di produttività individuale. A tale scopo verrà predisposto un cluster di server su cui verranno ospitate macchine virtuali a disposizione di sistemisti ed utenti per sperimentare il prodotto. La Regione Emilia-Romagna è inoltre nel gruppo di lavoro openofficie.org, promosso dal progetto EROSS. L’esperienza maturata ha fatto intuire che il FLOSS in ambito server permette al personale IT un maggior controllo sui servizi offerti, in quanto si tratta di software maggiormente adattabile e non dipende da un fornitore specifico (con economie legate anche al risparmio sui costi di licenza). D'altra parte però, l’utilizzo di FLOSS richiede al personale ITC maggiori capacità di integrazione e configurazione, in quanto non è possibile acquisire soluzioni free o open source “chiavi in mano”. Si ritiene invece che per alcune categorie di software il livello di maturità raggiunto e le funzionalità a disposizione non siano ancora paragonabili a quelle dei corrispettivi prodotti proprietari. Sulla base dell’orientamento a livello europeo e delle raccomandazioni a livello nazionale37, si prevede di incrementare quelle che sono le competenze interne sulle tecnologie FLOSS, al fine di promuoverne lo sviluppo, la diffusione e la conoscenza, soprattutto nell’ottica di favorire il pluralismo informatico, così come previsto dalla Legge regionale 11/2004.

54

Azienda Unità Sanitaria Locale di Reggio Emilia

Marco Rossi Vice Responsabile dello Staff Tecnologie dell’Informazione dell’Azienda Unità Sanitaria Locale di Reggio Emilia

La narrazione che segue racconta la storia di una “fata” che tentò di fare una magia che non le riuscì completamente, ma che le permise di trasformare comunque un rospo in principe. C’era una volta… Marco Rossi, Vice Responsabile dello Staff Tecnologie dell’Informazione della AUSL di Reggio Emilia (Servizio diretto da Luciano Sologni), esperto di reti dal lontano 1991. La sua specializzazione sono da sempre state le LAN (local area network), i primi cablaggi strutturati destinati ai “diffidenti” uffici tecnici, ed ora il VoIP (voice over Internet protocol), inizialmente mal digerito e divenuto oramai una costante per l’installazione anche di un singolo apparato telefonico. A partire dal 1995, con l’unificazione provinciale delle 6 USL e la realizzazione di una rete dati molto articolata (60 sedi collegate e utilizzo di fibra ottica per la metà dei collegamenti), il processo di convergenza “fonia-dati-immagini” ha rappresentato il filo conduttore delle azioni e degli interventi ICT messi in campo nell’Azienda. In tempi più recenti, grazie alla rete a larga banda LEPIDA, è stato quindi realizzato un Sistema di archiviazione e trasmissione di immagini (PACS) centralizzato. È ora disponibile, per cinque ospedali, un solo sistema computerizzato per l'archiviazione digitale e la diagnostica delle immagini radiologiche, che permette la loro trasmissione e visualizzazione mediante rete informatica. Il PACS, in via di federazione con l’analogo sistema dell’Azienda Ospedaliera di Reggio Emilia, si basa sull’uso costante e corretto della rete su cui navigano “vascelli” che devono con certezza raggiungere i porti di destinazione. A fronte quindi di una situazione variegata e composita, si è presentata

55

la necessità di uno strumento di management della rete che consentisse interventi proattivi, tali da mantenere in massima efficienza l’infrastruttura. Operata una valutazione dei prodotti di mercato, e considerati i relativi alti costi di acquisizione, fu scelto di verificare anche quali potessero essere le alternative open source. Prodotti proprietari e open, pur presentando interessanti funzionalità, non soddisfacevano a pieno le esigenze dell’AUSL e pertanto Marco Rossi pensò si potesse fare un “merge” delle caratteristiche più valide, creando un prodotto che rispondesse in tutto e per tutto ai bisogni specifici dell’AUSL. Per operare in tal senso, fu quindi coinvolto un esperto in materia dell’Università di Bologna, Dipartimento di Informatica, il Prof. Renzo Davoli, che definì quali regole: lo sviluppo di un prodotto ex novo e il rilascio dello stesso sotto General Public License (GPL). La squadra di lavoro individuata comprendeva quattro sviluppatori (cinque in fase finale) affiancati da una società esperta degli aspetti sistemistici di rete nonché, in qualità di debugger e co-fruitore della sperimentazione, la Regione Emilia-Romagna, rappresentata dalle Dott.sse Cristina Scarani e Michela Mazzini. L’avventura è durata più di tre anni ed ha visto il gruppo di lavoro riunirsi con cadenza mensile per fare il punto della situazione. Le criticità non sono comunque mancate: • L’assenza di formale convenzione con l’Università di Bologna, che avrebbe consentito al Prof. Davoli di operare in nome e per conto della stessa, è stata uno dei problemi maggiori, in quanto ha, per un certo verso, “decapitato” la squadra di lavoro. Venendo meno il responsabile scientifico (che in modo ufficioso non ha mai fatto mancare la sua presenza) infatti, si è sentita maggiormente la pesantezza di un progetto forse partito con un po’ troppa ambizione; • gli sviluppatori (freelance universitari o parauniversitari), nonostante fosse prevista una retribuzione della loro attività, hanno sempre tenuto un atteggiamento inadeguato all’espletamento di una commessa (adottando un approccio “accademico”), con difficoltà nel recepire le necessità di una committenza e nel rispettare i tempi di consegna. Le caratteristiche peculiari del progetto che avevano portato a pensarne la realizzazione ex novo erano la creazione di moduli con funzioni specifiche, tali da poter distribuire la raccolta dei dati. In altri termini, un modulo di Monitoring, uno di Gathering ed uno di Rendering, che hanno dato vita all’acronimo MORGANA - Monitor Render Gather Network Advisoring (ispirato dal Dott. Andrea Zobbi). MORGANA, fatti i primi passi nel lontano 2005, non è poi mai più riuscita a fare le magie che si prefiggeva sino a quando uno degli sviluppatori de-

56

cise di abbandonare il progetto. Diretta conseguenza fu l’inserimento nel gruppo di lavoro di un nuovo elemento che valutato lo stato dell’arte ed in considerazione di nuovi sviluppi del mercato FLOSS convinse la “ciurma” a spostare la prua del progetto verso un prodotto realizzato da una software house americana, rilasciato con licenza open source GPL. Dall’originale idea di operare un “merge”, vennero uniti il prodotto software americano e MORGANA: nacque così Zenoss MORGANA, ove la “fata” rimase quasi ed elusivamente nel titolo. L’applicativo core del progetto divenne quindi Zenoss a cui, come per “magia“ e in un’ottica tipicamente e splendidamente open source, gli add on MORGANA sono stati inglobati. L’esperienza del progetto MORGANA ha insegnato che partire da zero con un progetto Open Source non è la migliore delle idee. Ove possibile, ha più senso aderire ad un pre-esistente progetto magari maturo e possibilmente con alle spalle della community una software house che risponda anche a logiche di mercato, e che soprattutto abbia ben chiaro quale deve essere il rapporto cliente-fornitore ed abbia consuetudine a rispettare una commessa. Inoltre si è verificato che, in un progetto open source, la componente universitaria può essere molto importante nella parte progettuale, ma diversamente nell’attività di sviluppo occorre affidarsi a società o professionisti abituati ad operare in una logica di mercato. In questo senso sarebbe opportuno facilitare il percorso di convenzionamento o di attivazione di collaborazioni tra la Pubblica Amministrazione e le Università, in quanto troppo spesso la burocrazia uccide ogni spinta innovativa e di collaborazione con il mondo accademico. Da ultima si è realizzata la trasformazione da “rospo” a “principe” che è avvenuta quando grazie a MORGANA, una esperienza vissuta, Marco Rossi è stato incaricato di far parte della Commissione Open Source del Ministero per le Riforme e l’Innovazione nella PA. In questo ruolo e grazie al confronto con i colleghi della Commissione, a volte anche molto acceso, Marco Rossi ha maturato convinzioni che sono andate a far parte della proposta di documento finale. In particolare, nelle componenti che hanno visto il suo contributo, questi sono i suggerimenti ai quali dovrebbe attenersi sempre la Pubblica Amministrazione: “La commissione definisce che l’analisi delle soluzioni informatiche nella PA debba avvenire mettendo sullo stesso piano soluzioni open source con soluzioni proprietarie o miste, effettuando confronti comparativi che non discrimino a priori le soluzioni valutate. Le valutazioni comparative partono da una serie di considerazioni di natura generale che vedono i sei punti seguenti come importanti elementi di valutazione:

57

• TCO (costo totale di possesso) della singola soluzione (il TCO deve essere calcolato su di un arco temporale ampio, affinché possa essere fatta un’adeguata valutazione del rapporto tra gli investimenti fatti ed il ritorno degli stessi); • costo di uscita dalla soluzione (occorre che venga valutato il costo di uscita da una soluzione in termini sia tecnologici che di formazione degli utilizzatori); • valorizzazione delle competenze tecniche possedute dall’amministrazione (valutazione di come la soluzione aumenta le competenze interne); • interoperabilità intesa per la PA nel suo complesso (utilizzo di formati aperti e standard, piattaforme multiple); • valutazione dell’interesse di altre amministrazioni al riuso dell’applicazione da realizzare e/o acquistare (attenzione al riuso e quindi, in caso di sviluppo di nuove soluzioni, indicazione di caratteristiche atte alla portabilità e alla fruibilità da parte di altri utilizzatori); • valore sociale della soluzione (analisi di quanto la soluzione porta eventuali benefici alla comunità in termini di attività orientata all’erogazione di servizi). Nella individuazione delle soluzioni da adottare, facendo particolare riferimento alla riusabilità di SW esistente alla quale tutte le PA centrali e locali devono tendere, occorre che la rispondenza alle proprie esigenze venga effettuata attraverso un’analisi delle possibili soluzioni tra le seguenti possibilità e secondo l’ordine indicato: • riuso di programmi informatici sviluppati ad hoc per altre amministrazioni con verifica sul sito del CNIPA della presenza di programmi idonei; • sviluppo di programmi informatici ad hoc, sulla scorta dei requisiti indicati dalla stessa amministrazione committente, facendosi rilasciare il prodotto con codice sorgente aperto nella modalità GPL, L-GPL, altro che ne consenta la messa a disposizione pubblica dei sorgenti; • acquisizione di programmi informatici a codice sorgente aperto; • acquisizione di programmi informatici di tipo proprietario mediante ricorso a licenza d'uso; • acquisizione mediante combinazione delle modalità di cui alle lettere precedenti.

sitory, ai quali vengono resi disponibili i link di collegamento. L’individuazione di best pratice può favorire un incentivo alle PA nelle loro componenti politiche e tecniche, per adottare soluzioni che possano essere prese a riferimento da altre amministrazioni per qualità ed economicità, evitando il proliferare di soluzioni duplicate e che richiedono investimenti ex novo per la soluzione di problemi già risolti altrove.“ La AUSL di Reggio Emilia oggi utilizza con soddisfazione Zenoss MORGANA per gestire la propria rete; il software è disponibile sia nel repository CNIPA38 che in Sourceforge39. Si sta ora attivando un software per la realizzazione dell’archivio delle bio-immagini e la Federazione dei PACS aziendali tra la AUSL e l’Azienda Ospedaliera di Reggio Emilia, derivando gli elementi applicativi dal progetto open source MARIS40, pubblicato anch’esso sul sito del CNIPA e su Sourceforge. Sempre attingendo dal repository CNIPA, si sta altresì adottando il software open source IntranetDPS41 per la gestione del documento per la sicurezza. Morgana: regina dell’isola di Avalon, sorellastra e amante di re Artù, allieva del mago Merlino. Fata, Dea celtica, ninfa ed anche un miraggio. La magia di Morgana è forse la più potente che sia mai esistita. E forse è proprio tutto vero!

Pertanto assume un ruolo fondamentale il catalogo del CNIPA come riferimento per le PA, fungendo da elemento catalizzatore delle soluzioni adottate dalle PA centrali e locali, oltre alle proposte che il mercato può offrire. Attraverso il catalogo possono essere messe a disposizione best pratice ed i sorgenti software che non debbono essere necessariamente depositati sul sito del CNIPA, ma possono fare riferimento ad altri repo-

58

59

Agenzia regionale di protezione civile dell’Emilia-Romagna Stefano Dalli Servizio pianificazione e gestione emergenze

La Protezione Civile è una macchina complessa. Da vari punti di vista e per tanti motivi. Una specie di tetraedro con “stampigliati” su ciascuna delle quattro facce i fondamenti: prevenzione, previsione, emergenza, interventi. Da qualsiasi parte lo si giri, il tetraedro è sempre uguale a se stesso; non si può pensare che una faccia sia indipendente dalle altre, ma, nel contempo, ciascuna faccia gode di una sua intrinseca autonomia. Dentro al tetraedro poi, c’è una matassa di fili, a prima vista inestricabile, che connettono le facce con percorsi di volta in volta diversi. Progettare e realizzare un Sistema Informativo che tenga conto di tutto ciò non è quindi affar semplice, complesso sì, ma non complicato. Se lo fosse, complicato si intende, meglio lasciar perdere: si dovrebbero disegnare processi talmente articolati che trasposti, a livello di interfaccia, trasmetterebbero agli utilizzatori una sensazione più di “marchingegno” che di strumento di supporto. La sfida, quindi, si gioca tutta sul piano della facilità, dell’immediatezza, della chiarezza, dell’integrazione, del supporto e, non ultima, anche dell’estetica. Certo, esistono molti altri problemi “dietro”: l’infrastruttura, l’accessibilità, l’interoperabilità, la riusabilità, l’ingegnerizzazione. Tutte questioni che all’utente finale però non interessano in quanto risulta molto più sensibile ad altri argomenti, come: disporre tempestivamente di dati, informazioni e indicatori sul comportamento degli eventi per poterli interpretare e confrontare con pre-individuati scenari di riferimento, e per produrre le necessarie valutazioni in ordine agli effetti attesi; riconoscere tendenze e/o prevedere l’evoluzione dei fenomeni; fare analisi “ad hoc” o formulare ipotesi per cercare di comprendere l’evoluzione e il mutamento dei fenomeni; conoscere il contesto di riferimento entro cui i fenomeni si manifestano; coordinare e “mappare” le attività delle funzioni e dei ruoli individuati nei modelli d’intervento; produrre, comunicare e divulgare rapidamente informazioni di varia natura con diversi gradi di sintesi; realizzare analisi di tipo multidimensionale in forma assistita. Ora, se queste sono le esigenze degli utenti, non possono essere dimen-

60

ticate anche le necessità dei progettisti che hanno il compito di architettare e realizzare il sistema informativo. Risulta quindi necessario, per garantire un risultato conforme ai “desiderata”, postulare, a priori, alcuni rigorosi principi generali, del tipo: definizioni e classificazioni costituiscono il lessico comune per tutti i sotto-sistemi settoriali; dati di tipo generale utilizzati da diversi settori specialistici sono univoci e condivisi; la struttura dei dati non è dipendente dalle applicazioni settoriali che li utilizzano; il risultato delle elaborazioni prodotte da un sotto-sistema settoriale può essere utilizzato come dato in ingresso da altri sotto-sistemi settoriali; tutto il patrimonio informativo è certamente localizzabile, rintracciabile e storicizzato, nonché validato e certificato; il sistema deve essere potenzialmente utilizzabile da chiunque, ovunque egli si trovi. A partire dalla metà del 2005, perciò, la Protezione Civile regionale ha avviato un processo di avvicinamento al concetto di “Sistema Informativo Integrato di supporto alle Decisioni”. Fino a quel momento, infatti, circa un centinaio di dataset, per lo più di tipo cartografico, forniti prevalentemente da Servizi regionali (Servizio Sistemi Informativi Geografici e Servizio Geologico, Sismico e dei Suoli) e da ARPA (Servizio Idro-MeteoClimatico), costituiva il patrimonio informativo residente negli hard disk degli utilizzatori. Dati che venivano principalmente impiegati per la Pianificazione dell’Emergenza, per la predisposizione del Programma Regionale di Previsione e Prevenzione, per la predisposizione di Scenari in corso di evento a supporto del Presidente della Giunta e della Direzione per l’adozione delle misure urgenti di mitigazione e di risposta alle emergenze in atto e inserite in appositi Piani d’intervento. Gli strumenti e le applicazioni software proprietarie di tipo generalista utilizzate, poco adatte ad inserirsi in una infrastruttura che di per sé, invece, è orientata a fruire i dati e le informazioni secondo un approccio Client/Server, comportavano che i medesimi (dati e informazioni) risultassero distribuiti presso le postazioni locali dei singoli utilizzatori deprimendo così i benefici della centralizzazione condivisa ed aumentando i costi conseguenti alla proliferazione delle licenze d’uso dei diversi applicativi software. Ne derivava una riduzione dell’efficienza dell’intero Sistema della Protezione Civile Regionale che, in riferimento alla normativa vigente, è composto da vari enti e strutture operative chiamate a rispondere alle emergenze in modo coordinato per poter assicurare l’efficacia dell’intervento. Ciò è tanto più vero per quanto attiene l’effettiva applicazione di indirizzi normativi (ad esempio, la legge in materia di lotta attiva agli incendi di bosco) che impongono l’attivazione di Sale Operative Unificate, anche in modalità virtuale, con la presenza contestuale di operatori della Regione, del Corpo dei Vigili del Fuoco , del Corpo

61

Forestale dello Stato, del volontariato, ecc…; tali operatori necessiterebbero, infatti, di interagire fra loro con riferimento a piattaforme informative condivise. Non è stato facile, e non lo è in parte tuttora, “sbrogliare la matassa” ma, nonostante le evidenti difficoltà, alcuni concetti di base che guidano l’impianto logico e tecnologico sono stati definiti. Le gambe del tavolo sono state, per così dire, dimensionate in modo corretto! Si è quindi proceduto dotandosi di un Modello Unico dei Dati Spazio-Temporale, ciascun oggetto registrato nel dataset è ora caratterizzato dalle sue coordinate spazio-temporali e da metadati, è stato superato il concetto di cartografia con quello di Modello Terrestre di Riferimento (MTR), sono stati progettati e realizzati moduli software con tecnologia Web based basati sugli standard regionali con il massimo impiego di Web services e quindi garanzia di interoperabilità, sono state tenute in considerazione accessibilità, sicurezza e rispetto della privacy, i moduli software, i dati e le informazioni sono stati collocati sui server del CED Regionale ed eseguibili da consolle di comando o di regia da qualunque postazione Intranet/Internet dotata di un semplice browser Internet, sono stati progettati e realizzati componenti software automatici che riconoscono il superamento di soglie pre-individuate a seconda delle diverse tipologie di evento (idraulico-idrogeologico, sismico, ecc) e che provvedono alla compilazione e pubblicazione automatica di pagine Web e reportistica a diversi livelli di dettaglio, nonchè operano notificazioni automatiche agli utenti. Il lavoro preparatorio è stato enorme; tutto è stato toccato da questo nuovo approccio: normalizzazione e standardizzazione dei dati, assegnazione di coordinate spazio-temporali agli oggetti; recepimento di standard internazionali, nazionali e regionali; enucleazione dai dataset originali di terminologie, definizioni e classificazioni per costruire i dizionari e i glossari; predisposizione dell’infrastruttura hardware e software di base; documentazione; redazione di specifiche; analisi con gli utenti delle esigenze; verifica con i colleghi del CED Regionale ed accordo su nuovi meccanismi e protocolli; partecipazione a incontri e riunioni; realizzazione di prototipi applicativi di test e così via… Verso la fine del 2006, un primo impianto di dati e di applicazioni di consultazione via Web in ambiente Microsoft Windows Server 2003 è stato conseguito; fra dati e documenti, sono stati “guardati” e “messi a sistema” circa 120 Gbyte. Il 2007 è stato l’anno della svolta. Se fino a quel momento l’enorme mole di lavoro svolta aveva conseguito importanti obiettivi, rimaneva ancora aperta la questione cruciale: quale ambiente o filiera software utilizzare?

62

La Regione offriva opzioni sia proprietarie che open source. Scegliere la prima pareva essere la più semplice mentre la seconda appariva sotto dimensionata. Vari dubbi sono sorti al riguardo: selezionare la piattaforma proprietaria significava essere ospitati su una filiera esistente oppure “apparecchiare” una nuova infrastruttura. Ma la questione vera era un’altra; l’attività di analisi e di omogeneizzazione dei dati aveva nitidamente messo in evidenza come pensare in termini di Sistema muoveva verso due fronti: quello dell’allineamento nei confronti di un mondo rispetto al quale eravamo rimasti un po’ indietro, e quello dell’innovazione o, comunque, connotato da caratteri fortemente innovativi. Inoltre, non va minimizzato che tutto ciò è stato ed è frutto di una sorta di movimento che viene dal nostro interno. E poi, si deve anche dire che buttando lo sguardo all’esterno, e valutata l’offerta del mercato, questa è tutto sommato deludente e, in ogni caso, si ha a che fare con soluzioni settoriali scarsamente integrabili, interoperabili e personalizzabili. Insomma, non era così semplice selezionare la filiera più adeguata alle nostre esigenze. Il primo pensiero è stato quello dell’economicità di scala. In altri termini la domanda di fondo è stata: per quale ragione il costo di sviluppo delle applicazioni software deve risultare così fortemente appesantito dall’ambiente di base proprietario (sistema operativo, database, librerie, strumenti di sviluppo, ecc…)? La nostra risposta, che a parere di alcuni potrebbe apparire semplicistica, è stata: se questi costi fossero zero o vicino allo zero, si potrebbero liberare risorse importanti da destinare alle intelligenze e allo sviluppo. Il software open source a nostro giudizio è una realtà con la quale fare i conti (anche economici). Un risparmio “secco” dell’ordine dei 250.000 euro è possibile dal momento in cui si mette in piedi un’infrastruttura di 5/6 server bi/quadri processore. Il vantaggio economico sottolineato è ancora più rilevante in termini prospettici (e cioè nel lungo e medio periodo), infatti: • l'utilizzo di piattaforme proprietarie comporta costi di aggiornamento e migrazione rilevanti, costi cui è impossibile sottrarsi per restare al passo con l'evoluzione tecnologia, mantenendo al contempo il patrimonio del codice sviluppato; • la tempistica di aggiornamento tecnologico è spesso favorevole alle snelle organizzazioni open source rispetto alle complesse macchine produttive dell'industria del software; nel campo degli Application Server; ad esempio, JEE JBoss si è rivelato rapidissimo nel supportare le più aggiornate versioni di Java e nel recepire le più recenti specifiche; per contro il sensibile ritardo dei fornitori di costosi Application Server (IBM Websphere per citare un esempio) costringe chi lo adotta ad utilizzare versioni già superate di Java e dei componenti JEE;

63

• l'estrema reattività tecnologica delle comunità open source si concretizza in minori tempi di sviluppo e migliore qualità del software a disposizione degli utilizzatori; • la formazione di competenze, sugli ormai numerosissimi prodotti e componenti open source, nei team di sviluppo accresce la tempestività nel rispondere alle esigenze degli utenti finali, in quanto vengono praticamente azzerati i tempi di individuazione del fornitore e di contrattazione commerciale; • l'eterogeneità della domanda di software specialistico costringe i produttori ad allargare la copertura funzionale dei loro prodotti: essi risultano quindi sovradimensionati e scarsamente modulari con costi non accettabili se rapportati alle esigenze talvolta limitate e più spesso altamente specifiche degli utenti finali. Per contro, il codice open source è per definizione personalizzabile rispetto a particolari esigenze degli utenti (anche se non sempre il gap qualitativo rispetto al software proprietario è facilmente colmabile e le competenze necessarie facilmente reperibili). Per quanto riguarda poi i contratti di manutenzione ed assistenza, pare utile osservare che chi acquista software proprietario si sente garantito rispetto a malfunzionamenti per la possibilità di usufruire dell'assistenza tecnica del fornitore; tuttavia, l'utilizzo su scala planetaria di molti prodotti open source e la presenza sul Web di numerosi forum e comunità di sviluppatori e utilizzatori rendono estremamente agevole il problem solving. È in tal senso importante indirizzare la scelta dei prodotti open source verso quelli assunti come standard de facto dalla comunità internazionale open source. Non va inoltre dimenticato un punto cruciale di fondamentale importanza, che è quello delle rappresentazioni geografiche, siano esse nella classica forma cartografica bidimensionale, che in quella più sofisticata tridimensionale di tipo scenografica e pseudo-realistica; in questo caso, oramai, una importante quota delle applicazioni Web di questo tipo sono basate su motori open source. Calandoci nella realtà della Protezione Civile, e ritornando alla metafora del tetraedro, va sinceramente detto che il disegno complessivo del Sistema Informativo non è così completo e non è così semplice: le interazioni fra le diverse componenti della Protezione Civile possono essere le più varie e impreviste; ciò si può trasformare in richieste specifiche o personalizzazioni; a quel punto, se non si ha il pieno governo dell’ambiente e dell’infrastruttura, il rischio di implementare soluzioni non integrate risulta molto elevato.

taforma Linux RedHat AS 5, WS Apache, AS JBoss, DB PostgreSQL, con estensione PostGIS, MapServer (funzionalità di map rendering), libreria pgRouting (funzionalità di gestione dei grafici), libreria R + SPATSTAT (funzionalità di statistica e grafici)42. Spostando ora l’attenzione sulle applicazioni, due sono stati i momenti di meditazione e discussione: il primo, sull’ambiente di sviluppo; il secondo sull’interfaccia utente. Gli strumenti e i linguaggi individuati per lo sviluppo delle applicazioni sono Eclipse, il Java Enterprise Wide Framework SPAGO, Javascript, l’Application Server JBoss. Particolare attenzione viene posta nei confronti dello sviluppo dei componenti ,ogniqualvolta si ravvisa la necessità che questi vadano ad implementare le librerie. L’interfaccia utente è organizzata a menu e pannelli informativi e risulta flessibile anche in configurazione “multi screen”, potendo inviare i pannelli a diversi client/monitor. La disposizione e numerosità dei pannelli è configurabile sia dalla tipologia dell’applicazione che dall’utente. È inoltre predisposta per l’emergente interfaccia “multi touch screen”.

Le considerazioni esposte ed un periodo di test e prove che ha occupato il secondo semestre del 2007 hanno fatto propendere la scelta per la Piat-

64

65

ARPA Agenzia regionale prevenzione e ambiente dell’Emilia-Romagna Servizio Idro-Meteo-Clima (SIMC) Paolo Patruno Area Modellistica e Radarmeteorologia Il servizio meteorologico di ARPA Emilia-Romagna ha iniziato le prime sperimentazioni con GNU/Linux nel 1997; da allora l'utilizzo di software libero o open source si è diffuso ai vari settori dell'attività del Servizio. Di seguito verranno citati e descritti solo i principali. Nell’ambito dei sistemi operativi per workstation, distribuzioni e integrazione con software scientifico, sono al momento utilizzate negli uffici e sale operative circa 25 installazioni di Linux Fedora 8 (ognuna locale ma con condivisione di area utenti e di alcuni software tramite dischi di rete). La distribuzione originale del sistema operativo è stata arricchita di circa 75 pacchetti aggiuntivi e personalizzati43. Le postazioni vengono utilizzate per: • funzioni standard quali posta elettronica, navigazione e videoscrittura, tramite gli applicativi liberi messi a disposizione dalla distribuzione del sistema operativo FLOSS; • l'esecuzione di applicativi specifici per la geofisica quali modelli, grafica e statistica (sono disponibili numerosi FLOSS articolati e completi spesso sviluppati da altri centri con simili competenze o da università); • lo sviluppo di nuove applicazioni, prodotto della ricerca operativa (sono stati adottati come compilatori quelli della suite GNU che comprende C, C++ e Fortran90, insieme ad autoconf e automake che insieme ad altre utilità forniscono un ambiente di sviluppo completo). Per questo tipo di utilizzo siamo alla ricerca del giusto compromesso tra la ricerca di software allo stato dell'arte e la stabilità dello stesso, in un ambiente in cui la sicurezza viene delegata ad altri sistemi appositamente configurati. Questa impostazione permette di sfruttare le risorse hardware dei singoli computer e la totale interscambiabilità delle postazioni di lavoro; possibilità di veloci aggiornamenti, gestione delle dipendenze o eventuali conflitti, salvataggi certi e centralizzati. A svantaggio è l'impegno richiesto nell'aggiornamento delle versioni maggiori della distribuzione che solitamente vengono effettuale a cadenze poco più che annuali.

66

Per quanto riguarda i cluster ed il calcolo parallelo, a partire dal 2003, parte delle attività per la produzione di previsioni numeriche operative tramite modelli parallelizzati con MPI44, tradizionalmente svolte su sistemi di calcolo parallelo proprietari presso centri di supercalcolo, sono state duplicate, a fini di backup e di sperimentazione, su sistemi di calcolo parallelo a basso costo ospitati presso il SIMC. Ciò è stato possibile grazie al progresso, al basso costo dell'hardware di uso comune (processori e connessioni di rete) e alla completezza e stabilità raggiunta dal sistema operativo libero GNU/Linux, che è totalmente compatibile con i sistemi Unix su cui tradizionalmente “girano” le applicazioni scientifiche di calcolo parallelo. Determinante è stata la disponibilità di librerie MPI open source per il calcolo parallelo. La flessibilità di Linux ha permesso di personalizzare il sistema, adattandolo alle esigenze (di calcolo, comunicazione di rete, Input/Output) delle applicazioni specifiche a cui era mirato, impiegando anche tecnologie originali sviluppate internamente, quali i nodi di calcolo diskless, che hanno permesso un risparmio sui costi di acquisto e manutenzione.

MODELLI E PREVISIONI OPERATIVE. Compito della modellistica è sviluppare gli strumenti matematici numerici (modelli) a fini previsionali operativi e svolgere attività di ricerca applicata. Lo Stato del Mare, ossia la proprietà delle onde, può essere ottenuto mediante modelli numerici. A questo proposito ci si avvale operativamente del modello numerico SWAN45, che, supportato dal Ministero dei Trasporti, dei Lavori Pubblici e dalla Gestione Acque dei Paesi Bassi, è stato sviluppato ed è continuamente aggiornato dal Dipartimento di Meccanica dei Fluidi della Facoltà di Ingegneria Civile e Scienze Geologiche della Delft University of Technology. Gli sviluppatori di SWAN, unitamente al codice sorgente con licenza GPL, mettono a disposizione strumenti di cooperazione (come forum e mail) per raccogliere segnalazioni e contributi. A contorno il codice è corredato di un'ottima manualistica e di aziende private che offrono servizi e consulenze specifiche. L’area Meteorologia Ambientale si occupa di tutti gli aspetti meteorologici connessi alla previsione e valutazione della qualità dell’aria, e utilizza regolarmente dal 2005 il modello di chimica e trasporto Chimere. Si tratta di un codice Fortran90 parallelo, sviluppato dagli istituti INERIS e LMD e distribuito sotto licenza GNU. Il modello è attualmente utilizzato in modo operativo da una decina di istituti in diversi Paesi europei, e la comunità di utenti comprende anche diverse università e istituti di ricerca. INERIS gestisce inoltre un servizio gratuito di distribuzione delle condizioni al contorno per le previsioni di qualità dell’aria a scala locale e una mailing list degli utilizzatori. L’implementazione di Chimere presso ARPA ha ri-

67

chiesto diverse modifiche al programma (interfaccia con i dati meteorologici e di emissione, archiviazione e rappresentazione grafica dei risultati). Di fondamentale importanza è stato quindi avere accesso al codice sorgente e poterlo modificare liberamente.

Provincia di Forlì-Cesena Sandro Mazzotti Dirigente del Servizio Sistema Informativo della Provincia di Forlì-Cesena

SVILUPPO DI SOFTWARE SCIENTIFICO AL SIMC E LA COMUNITÀ INTERNAZIONALE. Il servizio meteorologico di ARPA Emilia-Romagna ha sviluppato negli anni alcuni software ad uso scientifico dettati da proprie esigenze interne. Per tale sviluppo ci si avvale esclusivamente di strumenti FLOSS. I software sviluppati più significativi sono distribuiti con licenza GPL; questo in quanto si è ritenuto di mettere a disposizione il lavoro fatto alla collettività ed in particolare ad altre amministrazioni pubbliche; dalla diffusione di tale utilizzo si ritiene possa tornarne un valore aggiunto (in termini di bug report e/o contributi software) tale da motivare l'investimento per rendere tale software distribuibile. Alcune commesse riguardanti software e con un investimento a carico del servizio sono state realizzate richiedendo software libero o open source; tale software riguarda la gestione di dati osservati e previsti su punti stazione e sistemi di archiviazione di tutti i messaggi meteorologici definiti a livello mondiale. Questo tipo di sviluppo ha permesso: • agevole integrazione con altro FLOSS; • sviluppo personalizzato e collaborativo (continuo confronto col personale interno committente e utente del software stesso), che ha permesso di operare specifiche di dettaglio ben superiori a quelle possibili in una classica commessa software; • ottima integrazione tramite librerie software (API) con gli applicativi sviluppati dal personale interno; • buon livello di documentazione e portabilità del codice; • limitata dipendenza nella manutenzione del codice dalla ditta assegnataria; • utilizzo di formati dati standard e open. Aspetti negativi possono essere considerati: • l'alto livello di competenze e di impegno richiesto al committente (lo sviluppo di software è un'attività altamente professionale e richiede competenze per appropriarsi degli strumenti messi a disposizione); • limitati ritorni legati alla distribuzione del software a soggetti terzi, nonostante le risorse dedicate per la diffusione; • numero ridotto di aziende competenti in ambito FLOSS.

68

L’esperienza che la Provincia di Forlì-Cesena ha maturato sul tema dell'evoluzione degli ambienti di produttività personale dalla piattaforma Microsoft Office ad ambienti “open” ha avuto il suo avvio nel 2005. Di seguito si schematizzano in modo sintetico le principali tappe che hanno connotato l’azione nell’Amministrazione provinciale. Nel 2005 la Giunta Provinciale, con delibera (Prot. 42392 del 07/06/2005), chiede una risposta strategica e politica circa l'adozione di prodotti office alternativi a quelli in uso (sottoposti a licenza d’uso a pagamento e di tipo proprietario). Diretta conseguenza fu l’autorizzazione a svolgere uno studio approfondito, mirato ad individuare un ambiente informatico alternativo concretamente utilizzabile nell’Amministrazione. Le principali motivazioni alla base dell’intervento della Giunta furono di natura economica e quindi tese ad abbattere i costi di acquisizione dei software di tipo MS Office. Primo passo, operato dal Servizio Sistema Informativo, fu quello di verificare ed analizzare approfonditamente, anche col contributo di aziende (NOVELL, SUN Microsystem, ecc), le alternative “open” più complete e simili al pacchetto MS Office. L’esigenza di scegliere un prodotto simile a quello in uso era finalizzata a minimizzare gli impatti sugli utenti finali. In parallelo, nell'anno 2006 – per motivi organizzativi e di criticità nella manutenzione utente – è stato sostituito l'ambiente di posta elettronica “client” Outlook (componente del pacchetto Office di Microsoft), con il prodotto “non free” ma a bassissimo costo totalmente in tecnologia Web, denominato “MDAEMON”; la modifica ha coinvolto oltre il 90% dei client dell'ente; questa sostituzione, oltre a risolvere alcuni problemi che appesantivano notevolmente l'assistenza tecnica in Help Desk, ha di fatto contribuito a rimuovere un componente fondamentale presente, e legato strettamente all'ambiente tecnologico dominante. La Conferenza dei Dirigenti, sentito il parere del Sistema Informativo, ha autorizzato l'avvio di una sperimentazione del prodotto individuato (OpenOffice.org v.ne 2.1) coinvolgendo circa 30 utenti appartenenti a ser-

69

vizi diversi, utenti con un livello di conoscenza dell'ambiente office Microsoft mediamente “medio-alto”; La sperimentazione ha avuto una durata di 5 mesi (fino al settembre 2007) ed è stata supportata da una azienda locale specializzata in ambienti “open”, che ha svolto i corsi di formazione iniziali e ha prestato un servizio di Help-Desk di secondo livello, mentre quello di primo livello è stato garantito dal Servizio Sistema Informativo interno. Per misurare meglio in itinere l'andamento della sperimentazione, è stato realizzato un applicativo Web nel quale gli utenti dovevano tracciare le attività svolte, indicando le problematiche riscontrate, allegando i documenti coinvolti per le successive analisi da parte del personale di Help-Desk. Nell'ottobre 2007 è stato presentato alla Giunta il risultato della sperimentazione e, visti gli esiti sostanzialmente positivi, si è avuto il mandato di procedere con le attività necessarie alla massima diffusione del nuovo ambiente. La condizione considerata basilare per permettere un dispiegamento “indolore” del nuovo ambiente è la disponibilità dei sw applicativi gestionali utilizzati nell'ente (gestione documentale e protocollo, gestione contabilità, ecc.) compatibili con il prodotto OpenOffice.org. È stata appaltata quindi ai fornitori dei vari SW utilizzati (principalmente per gli applicativi di maggiore diffusione) la modifica degli stessi con il rilascio delle nuove release indipendenti dal prodotto office utilizzato. Questa modifica è stata anche cofinanziata dai fornitori stessi, ed è stato realizzato con essi un accordo che prevede il rilascio gratuito della release SW per tutti gli Enti locali della Provincia. Al fine di raggiungere un completo affrancamento dall’obbligo di adeguare le postazioni utenti alle presenti e future release di MS Office con costi di licenza e problemi di adeguamento hw, si è disposto (già dal 2006) che tutti i SW acquistati o prodotti internamente dalla struttura di Sviluppo dovessero essere indipendenti dall'ambiente office. Al fine di fare coesistere comunque una gestione ibrida tra gli ambienti MS Office e open, è stata inoltre riprogettata tutta la modulistica dell'ente non solo in standard con quanto definito nel manuale di qualità dell'ente (la Provincia ha acquisito la certificazione di Qualità ISO9001:2000 dal 2006), ma soprattutto la modulistica è stata definita in modo indipendente dall'ambiente office utilizzato a garanzia della corretta lettura e trattamento; È stata inoltre formalizzata e comunicata a tutti gli utenti interni la modalità ottimale di gestione dei documenti imponendo: • l'utilizzo obbligatorio dei documenti in formato pdf negli allegati delle pagine Web dell'ente; • l'utilizzo (raccomandato) dei documenti in formato pdf anche nelle co-

70

municazioni informali (via mail), soprattutto se trattasi di documenti “finiti” e non di lavoro. A fine Giugno 2008 sono state rilasciate dai fornitori le varie release dei SW coinvolti (SW del Protocollo informatico e il SW per la gestione dei buoni d'ordine e delle liquidazioni) e ad oggi si sta testando la funzionalità complessiva prima del dispiegamento massiccio. Entro la fine di settembre 2008 saranno individuati tutti gli utenti utilizzatori che potranno passare all'ambiente OpenOffice.org (si ipotizza oltre l'80% ), e successivamente si procederà alla formazione di gruppi di utenti per la successiva attivazione del prodotto. Si ipotizza il passaggio completo degli utenti individuati non oltre marzo 2009. Per facilitare la compatibilità degli ambienti MS Office e OpenOffice.org e ridurre al minimo le problematiche nell'uso e nello scambio dei documenti, sono stati impostati alcuni parametri per tutti gli utilizzatori; in particolare il più importante è l'utilizzo del formato di salvataggio (.doc) e non il formato nativo di OpenOffice.org. Al momento si è scartato il formato libero RFT come “standard” per il salvataggio dei documenti, in quanto il formato RTF ha delle limitazioni rispetto al .doc, ma questo non esclude che l'RFT possa essere preso in considerazione per il futuro. Considerato che per motivi legati alle attività lavorative svolte non si riuscirà a sostituire (almeno per alcuni anni) la totalità delle postazioni MS Office, per ragioni di interscambio di documenti ancora in lavorazione all'interno dell'ente e fra enti, è necessario rimanere su formati sostanzialmente compatibili e il formato nativo OpenOffice.org non lo è. Il problema maggiore è rappresentato infatti dai documenti che arrivano dall'esterno, che talvolta hanno “macro” e funzionalità tali da renderne difficile l'apertura e l'utilizzo con OpenOffice.org. Il progetto è stato presentato come un passo strategico e di forte discontinuità non solo per le implicazioni economiche dell'ente Provincia, ma anche per le ricadute di efficienza e risparmio per i piccoli e medi enti (e per le scuole) del territorio. Questa responsabilizzazione, unita al fatto che gli utenti individuati nella sperimentazione erano tendenzialmente evoluti, ha determinato mediamente un approccio molto collaborativo. L'utilizzo dell'ambiente OpenOffice.org da parte dei trenta sperimentatori è stato massiccio (per la parte testo, foglio di calcolo e presentazioni). È stata invece esclusa dalla sperimentazione la componente “data base”. In totale, quindi, la sperimentazione ha trattato ben oltre 2.000 documenti. Di fatto non si sono registrati atteggiamenti né dubbiosi né astiosi

71

da parte degli sperimentatori. L'impressione finale manifestata da tutti è che, pur con alcune limitazioni su funzionalità prevalentemente di tipo “avanzato”: • la compatibilità tra i due pacchetti office è molto alta; • la facilità d'uso è tale da non richiedere specifici corsi di formazione, ma semplicemente approfondimenti sulle differenze tra i due ambienti; • esistono funzioni aggiuntive rispetto al prodotto MS Office (ad esempio il convertitore pdf integrato), che rendono molto pregevole l’utilizzo di OpenOffice.org sia per efficienza che per costi. Nel futuro, allargando il numero degli utenti coinvolti, ci aspettiamo alcune criticità, come ad esempio: • resistenza al cambiamento da parte di utenti, soprattutto da parte di quelli meno esperti: sarà, quindi, necessario un accompagnamento minimo con formazione mirata; • difficoltà di adattamento all'uso di alcune funzioni “avanzate”, casomai più efficienti (e più chiare) nell'ambiente MS Office. Per ovviare a questa problematica è necessario un lavoro di studio e formazione su come eseguire le stesse funzioni sull'ambiente OpenOffice.org ed eventualmente modificare certi documenti in modo tale da renderli maggiormente compatibili. In parallelo il Consorzio che segue lo sviluppo di OpenOffice.org dovrebbe migliorare certe funzionalità (come ad es. la stampa di etichette), che sono sicuramente meno efficienti rispetto all'ambiente MS Office; • problemi con la condivisione di documenti complessi, soprattutto se trattasi di condivisione tra enti (in particolare i fogli di calcolo). Per ovviare a questo inconveniente sarebbe necessario stabilire, almeno a livello regionale, degli standard per la condivisione dei documenti e lo scambio dei dati. Ogni ente dovrebbe quindi rifiutare documenti che non rispettano gli standard che sono stati concordati.

tuno, che potrebbe contribuire ad uniformare i formati in uso in direzione di opzioni “aperte” e quindi non discriminanti, potrebbe essere realizzato dagli enti locali di livello superiore (a partire dalla Regione Emilia-Romagna). Adottando ad esempio standard di interscambio dati basati su formati non penalizzanti per tutti gli utilizzatori di ambienti diversi da quello MS Office, come ad esempio il formato XML. Un elemento ulteriore che certamente potrebbe fare accelerare ulteriormente verso l'adozione dell'ambiente OpenOffice.org da parte degli enti potrebbe essere l'attivazione di un punto di supporto (via FAQ) unificato a livello Provinciale, ma ancor meglio se Regionale; il costo di gestione sarebbe più contenuto e il supporto sarebbe più completo e tempestivo. Infine, se molti enti Emiliano-Romagnoli decidessero di adottare l'ambiente OpenOffice.org, si potrebbero avere maggiori garanzie di evoluzioni rapide del prodotto, soprattutto in alcune componenti funzionali ritenute “penalizzanti” nell'uso rispetto all'ambiente MS Office, se si accompagnassero le richieste rivolte al Consorzio OpenOffice.org, anche con sottoscrizioni di piccole ma significative somme di denaro.

Il progetto di allargamento al nuovo ambiente potrà avere successo completo solo se si potrà contare sul totale appoggio al cambiamento da parte della dirigenza dell'ente. Siamo altresì convinti che un reale dispiegamento di questo ambiente di produttività personale alternativo a MS Office in enti medio grandi sarà un fattore decisivo e determinante per una rapida estensione dell'esperienza anche ad altri enti locali più piccoli (effetto domino). Un elemento di criticità indipendente dalla volontà dell'ente è rappresentato dal formato di interscambio dei “dati” tra enti. Attualmente è consuetudine che tale scambio si basi su formati proprietari non aperti Microsoft (specie per i fogli di calcolo e i data base). Un intervento oppor-

72

73

Comune di Imola Luca Fusaro Responsabile Sistemi Informativi del Comune di Imola

Il Comune di Imola, come già recentemente avvenuto per altri enti della nostra regione, ha intrapreso e sviluppato il tema del software libero e open source per la gestione e l'erogazione dei propri servizi informatici. Già dai primi anni del 2000, il personale tecnico dei Sistemi Informativi, nell'ottica di modernizzare e ampliare i servizi di rete, ha guardato dapprima con curiosità, poi con cresciuto interesse, alle soluzioni disponibili in ambito open source e free software. L’attenzione è stata dapprima rivolta al consolidamento dei servizi di rete essenziali come Firewall, DHCP e DNS. È stato realizzato un server proxy con filtraggio dei contenuti per la navigazione in Internet degli utenti. A seguito dell'ottimo riscontro avuto con la messa a regime del nuovo sistema, si è deciso di approfondire ampliando l'attenzione, finora orientata verso un puro risparmio economico, verso uno sguardo più amplio dato dalle opportunità offerte dal nuovo modo di operare proprio della comunità open source. Dietro ad un programma liberamente utilizzabile, vi è un radicale cambiamento nella progettazione, nello sviluppo e nel mantenimento dei progetti posti in essere: il personale coinvolto ha, infatti, la concreta percezione di essere attore della gestione e del miglioramento del servizio, ponendo interesse e accrescimento professionale nelle attività svolte. Questo ha portato l’ente verso l’investimento in risorse umane con il coinvolgimento e l’assunzione di personale tecnico qualificato anche in ambito FLOSS. Il passo successivo è stata la migrazione del sistema di autenticazione di utenti e calcolatori da tecnologia proprietaria a tecnologia Samba integrata con OpenLDAP. Si è quindi proseguito realizzando un nuovo servizio di posta elettronica basato su server qmail e relegando l’utilizzo di Microsoft Exchange per la sola posta interna dell'ente. Nel 2006 si è proceduto ad unificare i servizi di posta elettronica adottando OpenXchange, che ha introdotto anche funzionalità di groupware avanzate. Inoltre, è stato incrementato l’impiego di database che utilizzano tecnologia FLOSS (MySQL, PostgreSQL) per lo sviluppo di applicazioni costruite internamente.

74

Dal 2005 le postazioni di lavoro consegnate ai dipendenti sono equipaggiate con una serie di software FLOSS in ambito Windows sullo stile di TheOpenCD. Nel dettaglio i calcolatori elettronici in uso nell’ente hanno preinstallato: 7-zip, OpenOffice.org, Firefox, Thunderbird , Filezilla, PDF Creator, The Gimp, Inkscape, vlc, relavnc. Questo ha permesso agli utenti di abituarsi all'uso di nuovi strumenti senza creare il disagio di abbandonare le vecchie modalità di lavoro, consentendo di soddisfare la ‘curiosità’ per il nuovo ambiente senza pesare sul servizio con costi aggiuntivi. La strategia scelta ha dato buoni risultati, permettendo di creare isole di attenzione e coinvolgimento sul tema FLOSS; i colleghi già a conoscenza dell'argomento hanno così potuto approfondire e sviluppare il loro interesse: in alcuni casi è stato richiesta la possibilità di lavorare in ambiente open predisponendo postazioni desktop linux. Per quanto concerne i servizi alla cittadinanza, sono state installate diverse postazioni Internet al pubblico completamente gestite tramite software libero con un sistema di autenticazione sviluppato internamente al nostro Ente. La diversa architettura e sicurezza di Linux ci ha permesso di abbattere i costi hardware e di manutenzione dei calcolatori, a volte esposti alla imperizia degli utenti e al codice malevolo presente sul Web. Si sono registrati circa 20.000 accessi alle postazioni all'anno, indice di un alto gradimento dal parte dell'utenza. Sul fronte istituzionale il primo avvallo alla tecnologia FLOSS risale al 2005 quando viene discusso in Consiglio Comunale un “Ordine del giorno sul software libero”. Il 12 dicembre 2007 la Giunta Comunale, con delibera n. 475, approva il “Piano di sviluppo dell’open source software all’interno dei servizi comunali”, che getta le basi per i progetti futuri. In particolare si sottolinea la strategia di utilizzo di formati di dati aperti per i documenti prodotti dall'ente, garantendone così la consistenza, l’indipendenza dalla piattaforma e l'interoperabilità nel tempo. Nel mese di aprile 2008, a seguito delle nuove elezioni, il sindaco nomina un assessore con delega specifica all'informatizzazione, affermando una nuova sensibilità per le tematiche del software libero, segno di un ulteriore rafforzamento strategico in questo senso da parte del nostro ente. Attualmente si sta lavorando alla migrazione dalla suite di produzione individuale proprietaria all'equivalente open source OpenOffice.org. Stiamo stendendo un progetto di fattibilità, sui tempi e sui modi, seguendo le orme di altri enti che ci hanno preceduti su questo aspetto. Ci sono diverse criticità da sistemare prima di poter portare a compimento il progetto: tra queste, la maggiore è la forte integrazione e dipendenza di diversi applicativi verticali in uso presso il nostro ente con la suite Mi-

75

crosoft Office: l'adeguamento dei software alle nuove esigenze comporta un grosso sforzo condiviso tra il Comune e i fornitori delle procedure. Attualmente siamo in contatto con il Comune di Forlì e di Ozzano dell'Emilia per collaborare alla stesura e alla richiesta delle specifiche da adottare con le nuove versioni dei programmi che vedono coinvolti fornitori comuni. Si prevede, quindi, di procedere gradualmente alla migrazione della suite di office automation partendo dai settori meno critici, via via procedendo ulteriormente in funzione delle nuove soluzioni adottate: questo tipo di strategia consente di avere un impatto meno drastico sulle attività dell’ente, e quindi di essere accettato più di buon grado da dipendenti ed operatori. Sarà inoltre importante condividere col personale le motivazioni delle scelte fatte, e organizzare una adeguata formazione operativa sui nuovi strumenti. Fare innovazione rompendo vecchi schemi di lavoro è forse il punto più critico per una realtà come la Pubblica Amministrazione, avendo sempre come obiettivo quello di mettere i nostri colleghi nella situazione di poter svolgere al meglio i loro compiti. La strategia di condivisione dell’innovazione (non dell’imposizione), di contro, richiede maggiore sforzo da parte dei sistemi informativi e i tempi di completamento del progetto si dimostrano più lunghi.

La speranza è quella di poter portare il modello di sviluppo open source, basato sulla creazione di una comunità di sviluppatori, nelle Pubbliche Amministrazioni, al fine di veder nascere e crescere un tessuto di esperienze e progetti comuni a giovamento della collettività.

L’adozione di FLOSS nell’ente non può fermarsi all’aspetto lavorativo e organizzativo interno: la scelta di strumenti free o open source implica una “filosofia” sociale che coinvolge diversi soggetti della realtà in cui si opera, sia dal punto di vista culturale che produttivo: è in fase di avvio una collaborazione con gli istituti scolastici della città per coinvolgere gli studenti nello sviluppo di software a sorgente aperto e strumenti di sviluppo liberi. Questo rapporto sinergico aiuterà gli studenti nello sperimentare soluzioni a problemi reali, utilizzando strumenti didattici completamente trasparenti, avendo quindi pieno accesso e padronanza delle nuove tecnologie. È stato inoltre stabilito un contatto con ImoLUG (Imola Linux User Group), associazione di Imola per la diffusione delle nuove tecnologie telematiche ed informatiche legate al mondo del software libero. Sono in essere collaborazioni anche con realtà commerciali locali, in modo da coinvolgere il tessuto imprenditoriale del nostro territorio. In conclusione, il Comune di Imola è sempre più coinvolto nella strategia di adozione del software libero e open source, e ne rafforza sempre più il suo utilizzo, cercando di sfruttare al meglio le possibilità offerte per trarne vantaggi economici e organizzativi. Non manca, nel contempo, l’attenzione alle nuove idee che l’adozione di FLOSS porta con se e che si cerca di condividere e diffondere sia all’interno dell’ente che nella realtà territoriale.

76

77

4 Capitolo 4: considerazioni conclusive e raccomandazioni Le attività di indagine e misurazione realizzate da EROSS [CAPITOLO 1 e 2] e le esperienze ed i casi d’uso descritti dagli EELL e dalle organizzazioni pubbliche che operano in regione [CAPITOLO 3] hanno permesso di descrivere in modo molto dettagliato quelli che sono i livelli di uso e le caratteristiche degli utilizzatori di free, libre, open source software in Emilia-Romagna. Trovano così conferma molte delle considerazioni fatte nel precedente dossier EROSS. In particolare si può ribadire , senza alcun timore di smentita, che per la Pubblica Amministrazione emiliano-romagnola, come per il resto del mondo, il FLOSS non è qualcosa di passeggero (“di moda”) ma al contrario una modalità di sviluppo ed acquisizione del software in evoluzione ed espansione. Così sono quasi otto Comuni su 10 quelli che utilizzano FLOSS e un terzo del totale quelli che ne fanno utilizzo con intensità elevata. Resta comunque un 14% di Enti comunali che operano come utilizzatori “inconsapevoli” a riprova del bisogno persistente di azioni informative sul tema. È ormai opinione largamente condivisa che i fondamenti per lo sviluppo di un moderno mercato (regionale) del software [FLOSS e proprietario] per la Pubblica Amministrazione sono gli standard ed i formati aperti. L’attuazione di interventi in tal senso, oltre a dare risposta ai principi contenuti nella L.R. 11/200446 e nel Codice dell’Amministrazione Digitale47 e sostenere la realizzazione concreta dell’e-government, permetterebbero lo sviluppo ed il consolidamento di imprese locali di servizi e prodotti informatici ad elevato contenuto di conoscenza ed innovazione. Come evidenziato da studi della commissione europea48, infatti, la competizione nel settore ICT può trarre rilevanti benefici dalla diffusione ed uso di FLOSS, standard e formati aperti che spostano l’oggetto del confronto/scontro tra imprese dal prezzo del prodotto [licenza] alla qualità del servizio [competenze]. È proprio in un ambiente come questo, regolamentato ma privo di barriere artificiose e di vincoli, che i vantaggi del software free, libre, open source potranno trovare piena e totale espressione. Sono così, quindi, i numerosi Comuni e Province che hanno scelto di sperimentare o, in alcuni casi, utilizzare in modo esclusivo software libero o a codice sorgente aperto (sulle postazioni client/desktop come sui ser-

78

ver) che pongono il sistema della Pubblica Amministrazione regionale di fronte all’esigenza di dotarsi di regole e prassi che non discriminino nessun software [FLOSS o proprietario]. Tanto la tutela della pluralità informatica e del libero accesso alle informazioni quanto l’esigenza di realizzare sistemi informativi interoperabili (obiettivi espliciti ed impliciti del Piano telematico dell’Emilia-Romagna 2007-2009) possono realizzarsi solo attraverso una cooperazione tra EELL che sia basata su standard e formati liberi. Sono in tal caso indispensabili azioni informative, diffuse sul territorio, che dotino tutti i decisori (ma anche tutti gli operatori) delle competenze e delle conoscenze utili a comprendere e condividere le opportunità offerte dall’uso di standard e formati aperti e non ultimo di software e licenze free, libre, open source. Il Piano telematico dell’Emilia-Romagna e la Community Network dell’Emilia-Romagna49, il nuovo strumento di governance delle azioni in campo e-government e società dell’informazione di tutti i Comuni, Province e Regione, offrono il quadro operativo all’interno del quale avviare azioni di supporto e sostegno degli EELL: • nella gestione e mantenimento di standard [Centro regionale di competenza per il riuso50] che devono essere e restare aperti; • nell’adozione diffusa di formati aperti; • nell’acquisizione e sviluppo di software che la PA, una volta commissionato e remunerato, renda disponibili per il tramite di una o più licenze free o open source. Il progetto EROSS, nel corso del 2008 e per tutto il 2009, ha avviato e darà seguito ad interventi concreti che coinvolgono gli EELL e mirano a circuitare informazioni e conoscenza in una logica di condivisione e cooperazione: • gruppo di lavoro OpenOffice.org, gli EELL della regione che hanno scelto di utilizzare con elevata intensità il prodotto free, libre, open source per la produttività personale dei propri operatori si pongono a confronto per condividere approcci, soluzioni, successi e fallimenti; • gruppo di lavoro Centri regionali e provinciali di competenza Open Source, EROSS promuove incontri e collaborazioni con le strutture che operano su altri territori regionali o provinciali (Piemonte, Trento, Bolzano, Friuli Venezia Giulia, Toscana, Umbria) al fine di condividere esperienze e competenze; • approfondimento sulle problematiche tecniche e legali connesse alle licenze software [FLOSS e proprietarie], alla luce dell’evidenza empirica che mostra come sia prevalente il software di proprietà della PA tra

79

quelli acquisiti e sviluppati nell’ambito del Piano telematico dell’EmiliaRomagna 2007-2009 [CAPITOLO 2] saranno analizzati diritti e doveri, opportunità e rischi connessi al licenziamento del codice nonché gli aspetti di compatibilità tra licenze esistenti. Attività di questo genere dovrebbero uscire dalla dimensione temporanea di progetto per consolidarsi in qualcosa di maggiormente strutturato e consolidato che possa rispondere in modo continuativo e competente alle esigenze del territorio.

Bibliografia I documenti che seguono sono stati utili alla redazione del presente Dossier, e possono essere considerati come validi riferimenti per approfondire i temi trattati. Molto materiale è inoltre reperibile on line sui siti ufficiali della Free Software Fundation, della Open Source Initiative, di GNU Project, del programma europeo IDABC e su Wikipedia. Un elenco più dettagliato è disponibile all’indirizzo: http://www.regionedigitale.net/osservando/eross.htm. van Ark B., Inklaar R., and McGuckin R. H., (2003). "ICT and Productivity in Europe and the United States Where Do the Differences Come From?". CESifo Economic Studies, Vol. 49, 3/2003, 295–318. Berra M., Meo A. E., (2006). “Libertà di software, hardware e conoscenza – Informatica solidale 2”. Bollati Boringhieri. Berry, D. & Moss, G. (2006), “Free And Open-Source Software: Opening And Democratising E-Government”S Black Box”, Information Polity 11(1), 21-34. Cassell, M. (2008), “Why Governments Innovate: Adoption and Implementation of Open Source Software by Four European Cities”, International Public Management Journal 11(2), 193--213. Cobano M., Monti C., Piancastelli G., (2005). “Valutazione del grado di maturità di soluzioni software open source”. Progetto OITOS. Colli Franzone P., Madotto P., Marzano F., (2006). “La spesa in licenze d”uso per sistemi operativi client e office automation nella Pubblica Amministrazione locale italiana”. Deliverable Netics s.r.l. Comino S., Vanenti F. M., (2005). “Government Policies Supporting Open Source Software for the Mass Market”. Review of Industrial Organization, 26:217-240. European Commission, DG Enterprise, (2001). “Study into the use of Open Source software in the Public Sector”, An IDA Study, Interchange of Data between Administrations. Feller J., Fitzgerald B., Hissam S. A., and Lakhani K. R., (2005). “Perspectives on Free and Open Source Software”. The MIT Press. Fuggetta A., (2006). “Prospettive “aperte” per il futuro”. Beltel, building people dal 1995.

80

81

Ghosh, R. & Glott, R. (2005), “Free / Libre and Open Source Software Policy Support (FLOSSPOLS): Results and Policy Paper from Survey of Government Authorities”, Technical report, MERIT, University of Maastricht. Ghosh R. A., (2006). “Study on the: Economic impact of open source software on innovation and the competitiveness of the Information and Communication Technologies (ICT) sector in the EU”. MERIT, University of Maastricht.

Raymond E. S., (2000). “The Cathedral and the Bazaar” versione 3.0. Paperback edition. Regione Emilia-Romagna, (2007). “Linee Guida al Piano telematico regionale 2007-2009”. Materiale riservato non ancora disponibile.

Glott R., Ghosh R. A., (2005). “Usage of and Attitudes towards Free / Libre and Open Source Software in European Governments”. MERIT, University of Maastricht.

F. Rentocchini & D. Tartari, Open Source Software in the Public Sector: Results from the Emilia-Romagna Open Source Survey (EROSS),in Belbaly N. (Eds.) Successful Oss Project Design and Implementation: Requirements Tools Social Designs Reward Structures and Co-ordination Methods, Ashgate Publishing, Limited, forthcoming (2009)

Hahn, R. W. (2002), Government Policy toward Open Source Software, AEI-Brookings Joint Center for Regulatory Studies.

Shapiro C., Varian H. R., (2003). “Linux Adoption in the Public Sector: An Economic Analysis”. University of California at Berkeley working paper.

Hwang S., (2005). “Adopting open source and open standards in the public sector: five decisive factors behind the movement”. Michigan Journal of Public Affairs, Vol. 2. The Gerald R. Ford School of Public Policy. The University of Michigan, Ann Arbor.

Schmidt, K. M. & Schnitzer, M. (2003), “Public Subsidies for Open Source? Some Economic Policy Issues of the Software Market”(3793), Technical report, C.E.P.R. Discussion Papers, Available at http://ideas.repec.org/p/cpr/ceprdp/3793.htmlhttp://ideas.repec.org/p/cpr/cepr dp/3793.html.

Kovács, G.; Drozdik, S.; Zuliani, P. & Succi, G. (2004), “Open Source Software for the Public Administration”, Proceedings of the 6th Gomputer Science and Information Technologies (GSIT), Budapest, Hungary. Lee, J. (2006), “Government Policy toward Open Source Software: The Puzzles of Neutrality and Competition”, Knowledge, Technology, and Policy 18(4), 113--141. Lee, J. (2006), “New Perspectives on Public Goods Production: Policy Implications of Open Source Software”, Vanderbilt Journal of Entertainment and Technology Law 9.

Tartari D., Rentocchini F. & Lotti S., (2007). Emilia-Romagna Open Source Survey (EROSS): L'Intensita ´ di Utilizzo di Software Libero e a Codice Sorgente Aperto nei Comuni Emiliano-Romagnoli, in Marchesi M. (eds.), Finalmente Libero: Software Libero e Standard Aperti per le Pubbliche Amministrazioni, McGraw-Hill. Wong K., (2004). “Free/Open Source Software: Government Policy”, Asia-Pacific Development Information Programme.

Lewis, J. (2004), “Global Policies on Open Source Software”, Technical report, Center for Strategic and International Studies (CSIS). Lewis, J. (2006), “Global Policies on Open Source Software”, Technical report, Center for Strategic and Internationl Studies (CSIS). Lewis, J. (2007), “Global Policies on Open Source Software”, Technical report, Center for Strategic and Internationl Studies (CSIS). Lewis, J. (2008), “Global Policies on Open Source Software”, Technical report, Center for Strategic and Internationl Studies (CSIS).

82

83

Romagna”. I numerosi rapporti frutto dell’attività sono disponibili all’URL: http://www.regionedigitale.net/wcm/erdigitale/pagine/pagina_benchmarking.htm

Note

L’utilizzo di alcuni prodotti “proprietari” (come ad esempio il sistema operativo di Microsoft: Windows Vista), impone (necessitando di elevate prestazioni) nuove acquisizioni di apparati tecnici, o quantomeno il potenziamento di alcune componenti dell’hardware già in uso (come ad esempio scheda grafica e momoria RAM). La necessità di hardware ad elevate prestazioni è perciò spesso una scelta realizzata dal produttore del software, obbliga di fatto il consumatore, nel momento in cui decide di acquistare un suo prodotto, a dotarsi di un sistema adeguato alle esigenze del prodotto stesso.

La rappresentatività del campione, ovvero la capacità delle pubbliche amministrazioni effettivamente rispondenti al questionario di rappresentare il comportamento generale della popolazione di tutte le PA emiliano-romagnole, è stata presa in considerazione tramite due procedure: (1) prima della fase di rilevazione, si è provveduto ad effettuare una procedura di campionamento stratificato per classe dimensionale e provincia di appartenenza. In questo modo ci si è preventivamente posti al riparo da forti squilibri nei tassi di risposta. Nella fattispecie, grazie alla tipologia di campionamento adottata, si sono potuti prefissare obiettivi per singola cella (ove la cella conteneva un numero di PA per provincia e classe dimensionale) composti da un numero minimo di unità da intervistare; (2) successivamente alla fase di rilevazione, i dati raccolti sono stati sottoposti a test statistici volti a controllare l'esistenza di differenze significative tra rispondenti e non rispondenti per quanto riguarda la classe dimensionale e la provincia di appartenenza. Tutti i test hanno dato esito positivo, evidenziando quindi la capacità, del campione così costruito, di dare conto del comportamento della popolazione di tutte le PA emiliano-romagnole nel loro complesso.

11

Ghosh R. A., (2006). "Economic impact of FLOSS on innovation and competitiveness of the EU ICT sector". MERIT, University of Maastricht.

Programma che si occupa di fornire, su richiesta del browser, una pagina web. Fonte e maggiori informazioni all’URL: http://it.wikipedia.org/wiki/Web_server

12

Secondo la Business software alliance (Bsa), l’associazione di produttori di software, nella Pubblica Amministrazione italiana il fenomeno dell’uso non corretto di licenze interessa tre computer su dieci. Si veda l’articolo apparso l’11 giugno 2007 su Il Sole 24 Ore “Licenze d’uso gestite con disinvoltura – Nella Pa irregolari tre computer su 10”, di Rita Fatiguso.

Software che fornisce l'infrastruttura e le funzionalità di supporto, sviluppo ed esecuzione di applicazioni e componenti server in un contesto distribuito. Si tratta di un complesso di servizi orientati alla realizzazione di applicazioni per il web, multilivello ed enterprise, con alto grado di complessità. Fonte e maggiori dettagli all’URL http://it.wikipedia.org/wiki/Application_server

13

La libertà, per chiunque ne abbia interesse, di modificare il codice per personalizzare il software alle esigenze delle singole categorie di disabili, ed eventualmente alle specifiche necessità del singolo individuo, permette di fornire un più esteso servizio (e quindi favorisce l’inclusione sociale e digitale) sia dal punto di vista qualitativo che quantitativo.

Programma che si occupa dello smistamento da un computer a un altro della posta elettronica. Normalmente un mail server risiede su un sistema dedicato ma può essere eseguito su computer ove risiedano altri server o che vengano utilizzati anche per altri scopi. Fonte e maggiori informazioni all’URL http://it.wikipedia.org/wiki/Mail_server

14

“Le tecnologie dell’informazione e della comunicazione nelle amministrazioni locali 2007”, i principali risultati dell’indagine e le tabelle con i dati quantitativi sono disponibili all’URL: http://www.istat.it/salastampa/comunicati/non_calendario/20080307_00/

Programma usato per mettere a disposizione degli utilizzatori di una rete di computer dello spazio su un disco (disco singolo o composto da più dischi) nel quale sia possibile salvare, leggere, modificare, creare file e cartelle condivise. Fonte e maggiori informazioni all’URL http://it.wikipedia.org/wiki/File_server

15

Sistema software che permette di controllare un computer da un terminale che si trova altrove. La tecnologia di desktop remoto è molto utilizzata da produttori di hardware e software per fornire assistenza in modalità remota ai computer client in caso di problemi tecnici. Fonte (traduzione libera) e maggiori informazioni all’URL http://en.wikipedia.org/wiki/Remote_desktop_software

16

Sistema software progettato per consentire la creazione e manipolazione efficiente di database (ovvero di collezioni di dati strutturati), solitamente da

http://www.regionedigitale.net/wcm/erdigitale/pagine/pagina_piano_ telematico.htm Piano Telematico dell’Emilia-Romagna – Linee Guida 2007/2009, pag.57.

2

Primo dossier del progetto EROSS (Emilia-Romagna Open Source Survey): “Il free, libre, open source software nella pubblica amministrazione” (2007). Copia digitale all’URL: http://www.regionedigitale.net/wcm/osservando/pagine/eross.htm

3

4

5

6

7

84

10 1

8

Lo studio è stato finanziato dalla Commissione Europea e condotto dal Maastricht Economic and social Research and training centre on Innovation and Technology. Glott R., Ghosh R. A., (2005). “Usage of and Attitudes towards Free / Libre and Open Source Software in European Governments”. MERIT, University of Maastricht.

9

Regione Emilia-Romagna. “Benchmarking della società dell'informazione in Emilia-

85

parte di più utenti. Fonte e maggiori informazioni all’URL http://it.wikipedia.org/wiki/DBMS 17

Dispositivo di rete in grado di fornire agli utenti della stessa l'accesso e l'utilizzo ad una o più stampanti, in modo da permetterne l'impiego da parte di client diversi, sempre che questi abbiano le autorizzazioni necessarie per utilizzarle. Diversi tipi di autorizzazioni possono definire se l'utente ha i diritti per cancellare le code di stampa (l'elenco dei processi di stampa in attesa di essere stampati), o effettuare altre operazioni quali mettere in pausa una stampa per avviarla successivamente. Fonte e maggiori informazioni all’URL http://it.wikipedia.org/wiki/Print_server

18

Nel calcolo dell’iuFLOSS client/desktop non si è tenuto conto dell’iuFLOSS per i sistemi SIT/GIS, poiché la domanda su tale tipo di software è stata inserita nel questionario 2008 in via sperimentale.

19

Si veda la Tavola 9a dell’indagine ISTAT 2007 “L’ICT nelle Amministrazioni Locali”. Valori e un report di sintesi descrittivo dei dati raccolti sono disponibili all’URL: http://www.istat.it/salastampa/comunicati/non_calendario/20080307_00/

20

86

FLOSSPOLS Government survey, UNU MERIT Maastricht, in particolare il dato è tratto dalla tabella di figura 11 del rapporto FLOSSIMPACT, reperibile all’URL: http://www.flossimpact.eu

21

Maggiori dettagli sul progetto e sui risultati ottenuti dalla rilevazione all’URL: http://flosspols.org/

22

Il numero non esteso di Comuni facenti parte del campione 2006 avrebbe potuto far pensare a fenomeni di autoselezione, con conseguenti problemi di sovrastima degli indicatori. La vicinanza con il dato 2008, frutto di un’analisi su un campione sensibilmente più esteso e sicuramente rappresentativo, è una conferma ex-post della bontà delle stime e dei dati presentati nel report 2006.

25

191 Comuni rappresentano il 71% del campione, un dato leggermente diverso dal 77% (208 Comuni) ottenuto come somma di utilizzatori consapevoli e inconsapevoli di FLOSS. I 17 Comuni di differenza si spiegano considerando che la rilevazione attuale non costituisce una mappatura completa di tutti gli ambiti di utilizzo e relativi software presenti nei Comuni della regione. L’indagine si è concentra su alcuni (i principali) ambiti applicativi, rilevando i software utilizzati in tali settori. Quindi è probabile che Comuni che hanno dichiarato esplicitamente di utilizzare FLOSS lo facciano in settori che non sono stati oggetto della presente rilevazione. Ecco spiegata la differenza tra Comuni utilizzatori (consapevoli e non) e Comuni con iuFLOSS>0.

26

Dimensioni ridotte possono ad esempio voler dire ridotto potere contrattuale in negoziazioni con eventuali sviluppatori esterni all’Ente in tema di proprietà del software oggetto della trattativa.

27

Per “finalità generali” si intendono, ad esempio, software per le applicazioni da ufficio.

28

Per “usi specifici” si intendono, ad esempio ,software per: sicurezza, gestione e manutenzione server, CMS, Intranet, ecc.

29

Per “funzioni tipiche dell’ente” si intendono, ad esempio, software per: protocollo informatico, posta elettronica certificata, firma digitale, ecc.

30

Per una descrizione dei risultati ottenuti da EROSS 2006 si faccia riferimento al rapporto su “il free/libre open source software nella pubblica amministrazione”, consultabile al sito web http://www.regionedigitale.net/wcm/osservando/pagine/eross.htm

31

Per endogeneità qui si intende il concetto formale proprio della teoria econometrica che prevede la presenza di un legame (correlazione) tra le variabili utilizzate nel modello di analisi (variabili indipendenti) e la parte non spiegata dal modello (termine di errore).

23

Chi si occupa di informatica all’interno dei Comuni, anche se il servizio non è gestito internamente, sarebbe comunque in grado di indicare quale scelta software ha fatto il proprio fornitore. Ai fini della presente indagine tale informazione non è però rilevante, in quanto ciò che interessa è l’impatto dell’uso di FLOSS sul complesso dei software che i Comuni gestiscono in modo diretto.

32

In aggiunta ai modelli I e II, si è provveduto a testare un terzo modello che tenesse in considerazione la simultaneità caratterizzante i fattori presi in esame. L'esito di questo terzo tentativo ha dato indicazioni perfettamente in linea con quelle descritte per i modelli presi singolarmente. Per ragioni di chiarezza espositiva, non è stato incluso nel presente Dossier.

24

Come già anticipato, l’indice di intensità di utilizzo è stato ottenuto come media semplice dei due indici di intensità di utilizzo calcolati per i client/desktop e per i server. A loro volta questi indici sono stati elaborati come media semplice dei valori dell’indice di intensità di utilizzo registrati per le singole tipologie di software censite (eccezion fatta per i software di tipo SIT/GIS).

33

Le Linee Guida al Piano telematico regionale (PiTER) 2007-2009 rispondono ai principi e alle indicazioni contenute nella Legge Regionale n.11/2004 “Sviluppo regionale della società dell’informazione”, che definisce in modo formale obiettivi e modalità di attuazione degli interventi e delle iniziative realizzate dalla PA regionale, in materia di società dell’informazione. La LR fa riferimento indiretto al FLOSS all’art. 3 e all’art. 5, elencando tra gli obiettivi da perseguire “l'interoperabilità attraverso l'uso di formati di dati e protocolli di comunicazione conformi a standard liberi e/o aperti”, e tra i principi da tutelare quello del “pluralismo informatico”.

87

34

35

88

In particolare hanno risposto in questo modo i seguenti progetti: Rete LEPIDA, LEPIDA MAN: LEPIDA Metropolitan Area Network, Prosecuzione CENTER, Rilevazione sulla società dell’informazione regionale, EROSS, Laboratorio ICT per la PA, Riduzione Digital Divide, OPTA, e-citizen, Extranet della Community Network dell'Emilia-Romagna, Servizi innovativi di telefonia VOIP, Servizi di Videocomunicazione, Servizi di Data Center, LEPIDA SCUOLA, Video e multimedia per la didattica, e-learning per il recupero del debito formativo, LEPIDA SANITA', ComunicAzione, Co-desing dei servizi on line.

44

Maggiori dettagli su MPI all’indirizzo Web: http://en.wikipedia.org/wiki/Message_Passing_Interface.

45

SWAN è un “wave action model” di terza generazione ed ha un’implementazione fisica ed algoritmi di calcolo numerico sviluppati e studiati appositamente per superare le tradizionali difficoltà incontrate nell’applicazione di un modello d’onda in zone costiere caratterizzate da basse profondità. Maggiori dettagli su: http://vlm089.citg.tudelft.nl/swan/index.htm.

Il Codice dell'Amministrazione Digitale è stato emanato con Decreto legislativo del 7 marzo 2005, n. 82, pubblicato sulla Gazzetta ufficiale n. 111 del 16 maggio 2005, a seguito della delega al Governo contenuta all'articolo 10 della Legge 29 luglio 2003, n. 229 (Legge di semplificazione 2001). Il Codice è entrato in vigore il 1 gennaio 2006. Esso ha lo scopo di assicurare e regolare la disponibilità, la gestione, l’accesso, la trasmissione, la conservazione e la fruibilità dell’informazione in modalità digitale utilizzando con le modalità più appropriate le tecnologie dell’informazione e della comunicazione all'interno della pubblica amministrazione, nei rapporti tra amministrazione e privati; in alcuni limitati casi, disciplina anche l'uso del documento informatico nei documenti tra privati.

46

Il testo completo della L.R. 11/2004 della Regione Emilia-Romagna e maggiori dettagli sono disponibili all’indirizzo Web: http://www.regionedigitale.net/wcm/erdigitale/pagine/pagina_normativa/leg gi_regionali.htm

47

Maggiori dettagli sul Decreto Legislativo all’URL: http://it.wikipedia.org/wiki/Codice_dell%27Amministrazione_Digitale

48

Si veda Ghosh R. A., (2006). “Study on the: Economic impact of open source software on innovation and the competitiveness of the Information and Communication Technologies (ICT) sector in the EU”. MERIT, University of Maastricht. Copia del documento è disponibile all’URL: http://www.flossimpact.eu/

49

Maggiori dettagli all’URL: http://www.regionedigitale.net/wcm/erdigitale/pagine/pagina_community_network.htm

50

Si veda il progetto specifico a pag. 102 del Programma Operativo del PiTER 2008, copia disponibile in formato digitale all’URL: http://www.regionedigitale.net/wcm/erdigitale/pagine/pagina_piano_telematico.htm

36

Maggiori dettagli all’URL: www.qsos.org

37

Si veda il Capitolo 2 del Dossier EROSS 2007 disponibile all’URL: http://www.regionedigitale.net/wcm/osservando/pagine/eross.htm

38

http://cde.osspa.cnipa.it/projects/morgana

39

http://sourceforge.net/projects/morgana/

40

MARIS http://sourceforge.net/project/showfiles.php?group_id=37982&package_id=195374, MARIS XDS Registry http://cde.osspa.cnipa.it/projects/xds-registry/ e MARIS XDS Repository http://cde.osspa.cnipa.it/projects/xds-repository/

41

Per maggiori dettagli si faccia riferimento all’URL: http://cde.osspa.cnipa.it/projects/intranetdps/

42

Maggiori dettagli su tutti i componenti ai seguenti URL: DB: PostgreSQL: http://www.postgresql.org/, PostGIS: http://postgis.refractions.net/, Map Server: http://mapserver.gis.umn.edu/, Routing: http://pgrouting.postlbs.org/, Statistica: R http://www.r-project.org/, SPATSTAT: http://www.spatstat.org/spatstat/

43

Tramite rpm vengono generati i pacchetti necessari alle attività, le workstation vengono aggiornate con procedure automatizzate che utilizzano Yum come applicativo standard per la gestione dei pacchetti, attingendo anche da un deposito locale. Il file server viene salvato quotidianamente con procedura automatica, utilizzando il software di backup Amanda.

89

3 eross

EMILIA-ROMAGNA OPEN SOURCE SURVEY

PIANO , TELEMATICO DELL EMILIA-ROMAGNA

IL FREE, LIBRE, OPEN SOURCE SOFTWARE IN REGIONE EMILIA-ROMAGNA

EROSS - Emilia-Romagna Open Source Survey IL FREE, LIBRE, OPEN SOURCE SOFTWARE IN REGIONE EMILIA-ROMAGNA