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
crcosservatorio@regione.emilia-romagna.it
 Premessa.................................................................................................................................................................2

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

Indice 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 source. Il CAPITOLO 2 descrive, quindi, le principali evidenze emerse of-
frendo spunti di riflessione.
Il presente dossier rappresenta uno dei risultati del progetto EROSS (Emi-
lia-Romagna Open Source Survey) e fa seguito al precedente, pubblicato Nel CAPITOLO 3, in analogia con quanto fatto nel primo dossier EROSS,
nell’ottobre del 2007, nell’ottica di rispondere alle indicazioni contenute sono presentate esperienze concrete e casi d’uso di free, libre, open
nel Piano Telematico dell’Emilia-Romagna 2007-2009, che identifica, tra source software realizzate da organizzazioni di medie e grandi dimen-
gli altri, l’obiettivo di “realizzare studi per valutare le opportunità con- sioni (Regione Emilia-Romagna, AUSL Reggio Emilia, Agenzia Regionale
nesse ai diversi modelli di licenza [open souce]”1. La Regione Emilia-Ro- di Protezione Civile, ARPA Emilia-Romagna, Provincia di Forlì-Cesena, Co-
magna si dichiara decisa ad “agire con il ruolo di facilitatore di processi mune di Imola). La presentazione di tali situazioni, vantaggi e problema-
di valutazione ed adozione del software open source nelle Pubbliche Am- tiche reali completa in modo opportuno l’informazione quantitativa e
ministrazioni locali” e con il progetto EROSS mira a realizzare nel triennio statistica esposta nei capitoli precedenti.
2007-2009:
Le considerazioni generali e alcune raccomandazioni sono infine ripor-
• azioni informative, finalizzate a rendere maggiormente consapevoli gli tate nell’ultimo capitolo, CAPITOLO 4.
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.

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 “spe-
rimentale” 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 Ammini-
strazione. Nel CAPITOLO 1 si entra nel vivo dei risultati dell’indagine
EROSS realizzata nel 2008 grazie alla collaborazione dei Comuni dell’Emi-
lia-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 mi-
surare 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 è in-
dispensabile per apprezzare pienamente il contenuto del documento.
Si ripropongono, inoltre, quelle che sono le principali ragioni a sup-
porto 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.
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 compon-
gono il codice sorgente è quello di costituirsi in un programma infor-
matico, che faccia compiere al computer azioni specifiche. Affinché
l’elaboratore sia in grado di comprendere e quindi compia tali opera-
zioni, 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 lin-
guaggio macchina (ovvero in 0 e 1), comprensibile solo all'elaboratore.
Il codice oggetto è generato automaticamente da un apposito pro-
gramma, detto compilatore, che compie un vero e proprio processo di
traduzione (da codice sorgente a codice binario). Volendo fare un pa-
ragone, mentre il codice sorgente corrisponde al progetto di una casa,
il codice oggetto corrisponde alla casa vera e propria. Tuttavia, a dif-
ferenza dell’utilizzatore della casa, che dal prodotto può tutto som-
mato arrivare a ricostruirne il progetto, chi detiene il file oggetto può
solo utilizzarlo generalmente, senza che da questo gli sia possibile ri-
salire al codice sorgente che lo ha generato..
4 5
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 soprat-
tutto a riservargli lo sfruttamento economico dell'opera. In Italia è di-
sciplinato 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, mu-
sica, 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 ridu-
zioni, ecc. A seguito del recepimento delle direttive comunitarie
96/9/CE e 91/250/EEC, inoltre, sono ora compresi nell'elenco i pro-
grammi per elaboratore (software) e le banche di dati.
Il diritto nasce al momento della creazione dell'opera. Quindi, è dal-
l'atto creativo che incondizionatamente si origina; non vi è pertanto
alcun obbligo di deposito, di registrazione o di pubblicazione del-
l'opera.
Il diritto d'autore, come disciplinato dalla relativa legge, include le se-
guenti facoltà inerenti l'opera: pubblicarla, riprodurla, trascriverla,
eseguirla, rappresentarla o recitarla in pubblico, comunicarla al pub-
blico, diffonderla tramite mezzi di diffusione a distanza (telegrafo, te-
lefono, 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 cia-
scuna delle sue parti.
Il diritto consiste di due elementi fondamentali: in primo luogo, il di-
ritto 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 sfrutta-
mento economico. Il primo è strettamente legato alla persona dell'au-
tore e, salvo casi particolari, tale rimane, mentre il secondo è
originariamente dell'autore, il quale può cederlo dietro compenso (ma
 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 accom-
pagna 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 (copy-
right) 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 redistri-
buzione, 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 tratte-
nendone il codice sorgente (in questi casi la modifica del software ri-
sulta 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 in-
dica quel software che, rilasciato attraverso una licenza free o open
source, permette, anziché impedire, agli utenti di studiarne le caratte-
ristiche, modificare forma e contenuto e ridistribuirne una o più copie
liberamente. Il tutto è possibile in quanto vengono abbattute volon-
tariamente, da parte del proprietario del diritto di autore, quelle bar-
riere 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 Dos-
sier 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 7
risparmio economico: si realizza principalmente attraverso l’annulla-
mento dei costi di acquisizione del software (principalmente dovuti
alla sostanziale mancanza di oneri di licenza), l’incremento della lon-
gevità dell’hardware in uso (molti prodotti FLOSS sono, infatti, otti-
mizzati per essere eseguiti su calcolatori anche non molto potenti o
di recente produzione3 ), e l’indipendenza dell’organizzazione pub-
blica 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 pos-
sono essere resi (legittimamente) disponibili a qualunque altra orga-
nizzazione 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 sor-
gente rende valutabili (ovviamente a personale esperto preposto a
tale compito) le eventuali vulnerabilità del codice, eliminando perico-
losi margini di incertezza. Il software viene inoltre spesso utilizzato
nella PA per gestire dati sensibili o informazioni riservate, che non de-
vono essere accessibili a terzi, e che devono poter essere protette nel
migliore dei modi;
incremento nelle competenze e dell’indipendenza operativa del per-
sonale: l’utilizzo di FLOSS permette all’amministrazione di poter for-
mare 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 pro-
gredire 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 di-
versi. Superando, in tal modo, le difficoltà di integrazione che spesso
persistono fra prodotti “proprietari” di fornitori concorrenti. L’intero-
perabilità tra banche dati e programmi gestionali all’interno delle di-
verse organizzazioni pubbliche è uno dei fattori abilitanti per
realizzare una efficace politica di e-government e fornire servizi pub-
blici a effettivo valore aggiunto;
 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. In-
fatti, l’uso di formati aperti di archiviazione dei dati garantisce al-
l’ente la disponibilità delle proprie informazioni e la possibilità di
migrare in autonomia (e quindi senza la necessità di richiedere sup-
porto 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 inte-
ragire con l’Amministrazione Pubblica, in una logica di pluralismo in-
formatico;
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 cono-
scenza in generale e quindi la cultura. Verrebbero così favoriti feno-
meni 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 libera-
mente 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 soft-
ware 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 con-
sumo di ICT, un suo orientamento verso il FLOSS può favorire l’evolu-
zione 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 elimine-

rebbe il problema della gestione amministrativa delle licenze, po-
nendo 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
Capitolo 1: il FLOSS nelle PA
emiliano-romagnole
Nella convinzione che sia impossibile definire una strategia di azione
senza conoscere l’ambito nel quale si intende intervenire, la Regione Emi-
lia-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 de-
scrivere 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, miglio-
rando e rivedendo in parte la metodologia, ottenendo informazioni pun-
tuali e dettagliate su 269 dei 341 Comuni dell’Emilia-Romagna.
tanti) e della localizzazione (provincia di appartenenza) delle unità della
popolazione di riferimento. I Comuni per i quali è stata raccolta una ri-
sposta 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 Fi-
gura 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 ap-
partenenza.
FIGURA 1 - RISPONDENTI EROSS 2008: CLASSE DI POPOLAZIONE
140
120
100
80

Comuni
Il questionario EROSS 2008 è stato composto tenendo conto dei risultati 60
ottenuti nell’edizione precedente, nonché delle esperienze in tal senso
40
già realizzate a livello nazionale e internazionale (in particolare l’inda- 71 55 101
gine ISTAT “Le ICT nelle Amministrazioni Locali”7 e quanto realizzato dal 20 42
progetto della Commissione europea FLOSSPOLS8). Le domande sono
0
state predisposte affinché fosse possibile costruire un indicatore quan- meno di 3.000 ab. tra 3.000 e 5.000 ab. tra 5.000 e 15.000 ab. oltre 15.000 ab
titativo che descrivesse la reale “intensità di utilizzo” di FLOSS: non solo,
quindi, l’informazione legata a un generico uso/non uso. Con l’obiettivo Risposte valide Non risposte
di rendere il questionario snello e sintetico, si è inoltre operato affinché
fosse possibile riutilizzare, in fase di analisi, una gamma di informazioni Fonte: EROSS 2008
statistiche già in possesso della Regione e frutto, in buona parte, dell’at-
tività di indagine e benchmarking della società dell’informazione emi-
liano-romagnola9.
Da un punto di vista dimensionale (Figura 1), la percentuale di rispon-
Metodologia di indagine e struttura del campione denti più elevata è stata registrata nei Comuni con più di 15.000 abitanti
I dati della rilevazione EROSS 2008 sono stati raccolti nel periodo dicem- (89,36%), mentre per le altre fasce di popolazioni i valori sono molto simili
bre 2007 – marzo 2008, attraverso un questionario inviato ai 341 Comuni e di poco inferiori alla media regionale (78,89%). E’ evidente l’elevato nu-
(unità di analisi) della regione Emilia Romagna. In una prima fase l’invio mero di Comuni di piccole o piccolissime dimensioni che hanno contri-
è stato realizzato via posta elettronica, offrendo la possibilità di proce- buito all’indagine, in questi casi, più che negli altri, sono risultati
dere alla compilazione nella classica forma cartacea oppure diretta- indispensabili l’interazione telefonica ed il contributo di più referenti.
mente on line. In un secondo momento si è proceduto ad effettuare dei Spesso infatti, specie nelle piccole realtà, la gestione delle attrezzature
richiami telefonici mirati, per sollecitare la compilazione da parte dei Co- informatiche è in parte o totalmente esternalizzata a società private, o
muni mancanti. Scopo del contatto telefonico è stato quello di raggiun- più spesso a strutture pubbliche (Comunità Montane, Associazioni Inter-
gere il numero minimo di risposte previsto dal piano di campionamento comunali o Unioni di Comuni) a cui è demandata la gestione associata
stratificato, elaborato tenendo conto della dimensione (numero di abi- dei servizi informatici.

10 11
 FIGURA 2 - RISPONDENTI EROSS 2008: TERRITORIO PROVINCIALE DI APPARTENENZA Per quel che riguarda la territorialità delle risposte collezionate (Figura
2 - in basso), le province meno rappresentate sono Piacenza e Parma, che
BO 50 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 risul-
FC 22 tati al di sopra della media regionale anche per le province di Bologna,
Ferrara, Modena e Rimini. Se poi si analizzano i valori assoluti della di-
FE 22 stribuzione 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
MO 39
14% del campione).
I tassi di risposta ottenuti garantiscono la piena rappresentatività dei
PC 34 dati sia per territorio provinciale che per fascia dimensionale del Co-
mune. Gli indicatori che si presentano, frutto delle analisi, sono quindi
PR 34 espressione della realtà del territorio regionale e non di una minoranza10.

RA 17 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
RE 34
questionario, è stato richiesto ai Comuni di specificare il numero di in-
stallazioni ed il nome dei software utilizzati nei diversi ambiti applicativi.
RN 17
Per quel che riguarda i software client/desktop, le informazioni raccolte
0 10 20 30 40 50 60 hanno riguardato:
• sistema operativo per il desktop;
BO 85% • software di posta elettronica;
• browser Internet;
FC 76% • suite office automation;
• sistemi SIT/GIS.
FE 94%

MO 72% Per i software server, l’indagine si è concentrata invece su:

• Web server11;
PC 71% • application server12;
• mail server13;
83%
• file server14;
PR

RA 85% • server di desktop remoto15;

• data base management system (DBMS)16;
RE 73% • printer server17.
RN 83%

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

Risposte valide Non risposte

Fonte: EROSS 2008

12 13
 La scelta di queste specifiche classi di programmi informatici è frutto dei Amministrazioni fanno uso di FLOSS senza saperlo, in modo per così dire
risultati ottenuti nel 2006 e della logica di voler misurare e mettere a con- “inconsapevole”. Tale risultato, peraltro già emerso nella rilevazione
fronto l’utilizzo di software che, negli EELL, fanno parte della “dotazione EROSS 2006 e nell’indagine europea FLOSSPOLS realizzata da UNU-MERIT
standard” e quindi per i quali è plausibile attendersi un elevato livello di (in quel caso la percentuale era del 30% e faceva riferimento all’anno
confrontabilità. 2005)21, sottolinea come persista un problema di ridotta conoscenza del
tema da parte di un numero considerevole di Comuni. Da sottolineare
I dati ottenuti hanno permesso di calcolare un indice di intensità di uti- inoltre come tale mancanza di conoscenza non interessi solo gli EELL di
lizzo FLOSS (iuFLOSS), pari al rapporto tra il numero di installazioni di piccole dimensioni, ma in egual misura enti di piccole dimensioni e enti
tipo FLOSS ed il totale di tutte le installazioni. Tale indice è stato dap- medi e grandi.
prima calcolato per ogni tipologia di software, per poi comporre un in-
dice complessivo per i software client/desktop e per i software server Complessivamente dunque, la percentuale di Comuni che utilizza consa-
(entrambi ottenuti come media semplice dei valori di iuFLOSS per i singoli pevolmente o inconsapevolmente FLOSS in Emilia-Romagna sale al 77%.
ambiti applicativi facenti parte delle due categorie18). Un indice di inten- Questo dato sottolinea da un lato l’elevato interesse che il settore pub-
sità di utilizzo FLOSS generale è stato infine calcolato come media sem- blico mostra nei confronti del FLOSS, e dall’altro giustifica e motiva l’esi-
plice dell’iuFLOSS client/desktop e dell’iuFLOSS server. Tale valore di stenza stessa del progetto EROSS.
sintesi offre quindi, assegnando eguale peso alle due tipologie di soft-
ware, una indicazione sull’effettivo utilizzo di FLOSS.
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’in-
dice di intensità di utilizzo FLOSS), è stato possibile distinguere tra gli 22%
non
Enti Locali che effettivamente hanno scelto di utilizzare FLOSS in modo utilizzatori
di floss
diffuso. In questa logica i Comuni sono stati distinti in tre categorie di
14%
utilizzatori, permettendo così di delineare l’identikit dei Comuni che utilizzatori
fanno “intenso”, “moderato” o “nessuno” utilizzo di FLOSS. 1% inconsapevoli
di floss
non sa/non
risponde 77%
Analisi descrittiva utilizzatori
di floss
Il primo dato sul quale soffermarsi è quello generale relativo a quanti Co-
63%
muni abbiano esplicitamente dichiarato di utilizzare FLOSS (Figura 3). utilizzatori
consapevoli
Sulla base delle risposte raccolte da EROSS 2008, due Comuni emiliano- di floss
romagnoli su tre (il 63%) dichiarano di utilizzare FLOSS. Il risultato, diret-
tamente confrontabile con quello ISTAT 200719, è di molto sopra la media
nazionale, che si assesta al 34,4%, e superiore in modo sostanziale al va-
lore medio dell’area geografica Nord-est (50,8%), a cui l’Emilia-Romagna
appartiene. La media europea, il dato disponibile fa riferimento all’anno Fonte: EROSS 2008
200520, è invece del 50,1%. Sostanzialmente questa prima informazione
evidenzia come il territorio regionale abbia maturato una tendenza ed Nella precedente indagine EROSS 2006, la percentuale complessiva sti-
una propensione all’uso di soluzioni software FLOSS più di quanto ab- mata di Comuni utilizzatori di FLOSS era del 70%. Tale dato, alla luce del
biano fatto le corrispondenti Amministrazioni italiane ed europee. 77% della presente rilevazione, si dimostra meno viziato da dinamiche
A conferma del fatto che l’adozione e l’uso di FLOSS non sono limitati a di autoselezione di quanto si fosse pensato al tempo22.
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 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
(
Fascia
dimensionale
Comuni

Più di 15.000 ab. Argenta, Bologna, Correggio, Faenza,

% su totale comuni
(valore assoluto)
32% (15/47)
) dimensione dell’ente (in termini di popolazione di pertinenza). Osser-
vando i due grafici di Figura 4, è facile notare come sussistano marcate
Ferrara, Forlì, Imola, Lugo, Modena, differenze tra i valori medi di iuFLOSS: in particolare si osserva come
Pianoro, Ravenna, Riccione, Rimini, siano i piccolissimi ed i grandi Comuni a presentare iuFLOSS media più
San Lazzaro Di Savena, Zola Predosa elevata.

5.000 - 15.000 ab. Albinea, Argelato, Castello D'argile, 14% (18/129) FIGURA 4 – INTENSITÀ MEDIA DI UTILIZZO GENERALE, CLIENT/DESKTOP E SERVER
Castelnovo Di Sotto, Castiglione (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 5%
hanno dichiarato di aver adottato un atto di indirizzo strategico o ammi-
nistrativo avente ad oggetto l’adozione di software FLOSS. Come si vede 0%
sono prevalentemente interessati i Comuni di grandi dimensioni. Come meno di 3.000 ab. tra 3.000 e 5.000 ab. tra 5.000 e 15.000 ab. oltre 15.000 ab.
prevedibile, sulla base dei dati EROSS 2008, è possibile stabilire che i Co-
muni 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ò iuFLOSS Client/Desktop (retta tratteggiata = media regionale)
una quota significativa di Comuni (l’8% in EROSS 2008), che pur presen- iuFLOSS Server (retta tratteggiata = media regionale)
iuFLOSS generale (retta tratteggiata = media regionale)
tando 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’uti-
lizzo di FLOSS in ambiti non censiti dall’indagine EROSS (come ad esem-
pio quello dei software per il Web o di tipo gestionale).
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%

5% 0%
oltre tra 5.000 e tra 3.000 e meno di Regione
15.000 ab. 15.000 ab. 5.000 ab. 3.000 ab.
0%
FC PC RE PR BO RA RN FE MO iuFLOSS Sistema Operativo iuFLOSS Browser Internet
iuFLOSS Posta elettronica 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 15%
come nel caso dei valori specifici per Client/Desktop e per Server si pos-
sono notare alcune piccole differenze. Questa dinamica sicuramente su- 10%
bisce gli effetti diretti della disponibilità di risorse umane ed
economiche, della complessità della gestione dell’installato che aumenta 5%
con l’aumentare del numero dei dipendenti dell’ente e con fenomeni di
esternalizzazione dell’attività di gestione e manutenzione che nel caso di 0%
Comuni medi significa spesso demandare ai fornitori le scelte su quali BO FC FE MO PC PR RA RE RN Regione

software adottare. Ancor più accentuate sono le differenze che si eviden- iuFLOSS Sistema Operativo iuFLOSS Browser Internet
ziano, Figura 4 secondo grafico, tra i territori provinciali. E’ sostanzial- iuFLOSS Posta elettronica iuFLOSS Suite Office
mente chiaro che il FLOSS non rappresenta qualcosa di oscuro e nuovo
per i Comuni modenesi, ferraresi e del riminese, che ne fanno un uso in- I grafici inclusi in Figura 5 offrono un dettaglio che permette di apprez-
tenso e diffuso (seppure con differenze anche sostanziali negli aspetti zare differenze in alcuni casi sostanziali nell’utilizzo di software FLOSS
applicativi – client/desktop o server). nei client/desktop degli operatori dei Comuni emiliano-romagnoli.
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.
Fonte: EROSS 2008

18 19
 In particolare spiccano come valori sopra la media regionale quelli dei FIGURA 7 - INTENSITÀ DI UTILIZZO SOFTWARE CLIENT/DESKTOP (&COMUNI)
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. presen-
tino per tutte le tipologie di sw client/desktop valori superiori o prossimi
alla media regionale.

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

100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0% Fonte: EROSS 2008
oltre 15.000 ab. tra 5.000 e 15.000 ab. tra 3.000 e 5.000 ab. meno di 3.000 ab. Regione

iuFLOSS Web Server iuFLOSS Printer Server

iuFLOSS Application Ser iuFLOSS Server di Desktop Remoto
iuFLOSS Mail Server iuFLOSS Data Base Quelle appena descritte sono quindi le principali differenze che sussi-
iuFLOSS File Server Management Systems (DBMS) stono tra Comuni di territori provinciali e fasce dimensionali diverse, in
termini di valori medi di intensità di utilizzo di FLOSS. Nei paragrafi che
Fonte: EROSS 2008
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 risul-
tati 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 ri-
minese 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 Come risulta evidente, la diffusione di FLOSS nel settore dei software
Descritte le dinamiche dei risultati rispetto all'universo di riferimento (in client/desktop è piuttosto limitata. Ciò risulta particolarmente vero
termini di localizzazione geografica e dimensione dei singoli Comuni), si nell’ambito dei sistemi operativi, ove più del 75% dei Comuni (tre su quat-
analizzano ora le singole tipologie di software, iniziando da quelli per la tro) presentano un iuFLOSS pari a zero. I Comuni che hanno installato
produttività personale. I risultati fanno riferimento alla dotazione stan- Gnu/Linux (o altro sistema operativo FLOSS) su più del 30% dei propri
dard in capo ai singoli operatori pubblici, quella definita, gestita e man- client/desktop sono appena due. Complessivamente, nei Comuni inda-
tenuta operativa dalla struttura interna (o da fornitori esteri con gati, le installazioni di sistemi operativi FLOSS ammontano a 315 su oltre
contratti di gestione e manutenzione). 26.000 censite (pari all’1,2%). Questo risultato sottolinea, specie se con-
In Figura 8 sono rappresentati gli indici di intensità di utilizzo calcolati frontato con quelli che seguiranno, il ridotto interesse che le Pubbliche
per ciascuno dei cinque ambiti di software client/desktop indagati. I dati, Amministrazioni rivolgono, allo stato attuale, alle alternative FLOSS di
come detto, sono pienamente rappresentativi, e quindi la percentuale, Microsoft Windows, che nelle sue varie versioni resta la piattaforma di la-
unità di misura orizzontale, è da applicare al totale dei 341 Comuni del- voro della stragrande maggioranza degli operatori dei Comuni emiliano-
l'Emilia-Romagna. romagnoli.
Per quanto riguarda la gestione della posta elettronica, si nota come
FIGURA 8 - INTENSITÀ DI UTILIZZO SOFTWARE CLIENT/DESKTOP (% COMUNI) 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 utiliz-
sistema zano client mail free o open source in maniera esclusiva (iuFLOSS = 100%).
operativo
Numerosi sono anche i Comuni che hanno scelto soluzioni per la gestione
posta delle mail che prescindono da installazioni sui client/desktop, e che sfrut-
elettronica
tano l’uso del protocollo http e quindi di un comune browser Internet
browser (Webmail).
internet
Sul fronte della navigazione del Web, si rileva il più alto livello di prefe-
office renza riservato alle alternative FLOSS di prodotti consolidati e larga-
automation mente diffusi come il leader di mercato MS Internet Explorer. Il 23,5%
delle installazioni standard che interessano le postazioni degli operatori
sit/gis*
dei Comuni della regione sono dotate di prodotti free o open source
(come Firefox, Mozilla, ecc…) come browser Internet. Così, circa il 13% di
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Comuni presenta un iuFLOSS maggiore o uguale al 50%, e in quattro enti
Comuni sono utilizzati esclusivamente browser FLOSS.
Numeri molto simili e altrettanto significativi sono riscontrabili nell’am-
Intensità 100% FLOSS
di utilizzo bito dell’office automation (produttività personale), in cui il 45% circa dei
76-99%
(iuFLOSS) Comuni ha una o più installazioni FLOSS (nella fattispecie
51-75%
50%
openoffice.org); di questi una quota significativa il 7% presenta un iu-
31-49% FLOSS maggiore o uguale al 50%, e in quattro Comuni si fa uso esclusivo
11-30% del prodotto non proprietario. Questi due risultati meritano particolare
< 10% attenzione, perché si tratta degli strumenti con cui ogni giorno gli opera-
0% FLOSS tori della PA si trovano a lavorare. È quindi molto facile comprendere le
non sa/non risponde criticità legate alla sostituzione di prodotti consolidati e molto completi
Webmail (come Microsoft Office).
Rispetto ai risultati ottenuti sui software SIT/GIS, prodotti di tipo specia-
listico destinati a specifici settori degli EELL (programmazione territo-
Fonte: EROSS 2008
Nota: I dati raccolti per i software SIT/GIS sono stati raccolti in modo sperimentale e non sono
riale, edilizia, ecc…), un primo macro dato riguarda la percentuale elevata
stati inclusi nel calcolo dei valori sintetici di iuFLOSS. di non risposte. Questo fa supporre che vi sia una gestione diretta dei sin-

22 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 in-
dicare 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).
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 cen-
site con EROSS 2008 è di oltre 6500, e quindi il fenomeno è rilevante. Il
gruppo di lavoro è allo stato attuale composto da rappresentanti di Co-
muni, 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 espe-
rienze acquisite, le soluzioni individuate e le strategie di migrazione adot-
tate; (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
eross@regione.emilia-romagna.it.
Software per la gestione dei contenuti Web (CMS)
L’esperienza accumulata dal progetto EROSS con la rilevazione 2006, l’esi-
genza conoscitiva specifica del progetto RACER (Rete per l’ACcessibilità in
Emilia-Romagna) e lo spirito di cooperazione e collaborazione che caratte-
rizza 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 Ammi-
nistrazioni emiliano-romagnole. Sono 98 i Comuni che hanno risposto ai que-
siti 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 re-
lativamente poco diffusa se si considera che tutti i Comuni dell’Emilia-Ro-
magna sono dotati di un sito Web istituzionale, e in alcuni casi anche di
ulteriori portali tematici. È quindi presumibile attendersi un’espansione
24
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 pro-
prietarie. 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-
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 nu-
mero di Pubbliche Amministrazione si è dovuta dotare negli anni per ge-
stire la propria LAN (local area network), su cui fornire servizi distribuiti
(condivisione e gestione di risorse come spazio di archiviazione, stam-
panti, ecc…) e per sviluppare e gestire applicazioni e servizi da utilizzare
sulle reti Intranet e Internet (siti Web, posta elettronica, sistemi gestio-
nali, ecc…). Il livello di efficienza ed efficacia dei software utilizzati sui
server ha riflesso diretto sulla produttività e sulla capacità di lavoro del-
l’intera amministrazione pubblica, e per questa ragione molto spesso la
loro gestione (e quindi anche la scelta su quale software utilizzare) è de-
mandata a soggetti esterni specializzati in questo campo.
25
 FIGURA 10 - INTENSITÀ DI UTILIZZO SOFTWARE SERVER (% COMUNI) delle Pubbliche Amministrazioni. L’elevata adozione e l’alta intensità di uti-
Comuni lizzo di FLOSS in ambito server ha ovviamente un impatto limitato sui singoli
operatori della PA, che con ogni probabilità, a parità di continuità del servi-
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% zio, non percepiscono differenze. La scelta di adottare FLOSS è quindi pie-
web namente in capo al responsabile informatico dell’ente e, in questo caso,
server
impatta in modo quasi esclusivo sulla sua struttura.
application
server
L’ambito applicativo con il maggior utilizzo di FLOSS (indipendentemente
dall’intensità) è quello dei software di DBMS, dove si raggiunge un 30% di
mail
server iuFLOSS>0, seguito a breve distanza da application server (28%) e Web
file
server (25%).
server
server di FIGURA 11 - INTENSITÀ DI UTILIZZO FLOSS (CLIENT/DESKTOP VS. SERVER)
desktop
remoto
data base
management 100%
systems
printer

Intensità di utilizzo FLOSS lato Server

A
server

Intensità 100% FLOSS C

di utilizzo 76-99%
(iuFLOSS)
51-75%
50%
31-49% 50%
11-30% D
< 10%
0% FLOSS
legacy*
non gestito internamente
non sa/non risponde

Fonte: EROSS 2008 B

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 nu-
mero 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 Co-
muni 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 ser-
ver. Tale evidenza conferma implicitamente che, come peraltro noto a livello
mondiale (FLOSS come Apache, Tomcat, Jboss, Postfix, ecc… sono leader o im-
portanti players del loro mercato), esistono prodotti FLOSS per i server stabili
ed affidabili che possono rispondere in modo completo e pieno alle esigenze
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 Co-
muni 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 è rap-
presentata 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.

26 27
 Questo risultato suggerisce che il percorso seguito dai Comuni nell’ado- Non essendo stati fatti interventi di alcun tipo lato server, è probabile
zione di livelli significativi di FLOSS lato client/desktop deve passare ne- che le motivazioni alla base dell’adozione di FLOSS siano di tipo econo-
cessariamente da un primo progressivo e sempre più consistente utilizzo mico/politico e non tecnico;
lato server. L’ipotesi di fondo, sostenuta anche dai dati sin qui illustrati, C. Only server, il sentiero di avvicinamento al FLOSS passa in modo molto
è che il passaggio verso il software free e open source debba prima avve- stretto da una prima azione esclusivamente indirizzata all’adozione di
nire lato server, coinvolgendo le strutture tecniche che per l’ente si oc- software libero o a codice sorgente aperto sui server. Le dimensioni dei
cupano della gestione delle ICT, per poi muoversi verso una Comuni sono medie (13.500 ab.) e analoghe a quelle del gruppo prece-
sperimentazione lato client/desktop, solo in quel momento considera- dente. La scelta di utilizzo di FLOSS lato server è molto probabilmente
bile come preludio per una vera e propria adozione o migrazione che frutto di una decisione tecnica operata dal responsabile dei sistemi in-
coinvolga tutte le postazioni degli operatori del Comune. formativi/informatici. Non vi sono interventi significativi sulle postazioni
client/desktop che presupporrebbero il coinvolgimento e la collabora-
zione di tutti i dipendenti e l’approvazione/supporto di tutti i livelli deci-
TABELLA 2 – GRUPPI DI COMUNI CHE TENGONO COMPORTAMENTI ANALOGHI NELL’UTILIZZO sionali/politici;
DI FLOSS D. Both client/desktop & server, si tratta di enti che gestiscono almeno la
metà dei propri server con FLOSS e che contemporaneamente hanno in-
stallazioni diffuse di software liberi o a codice sorgente aperto sulle sin-
(
Utilizzo
FLOSS
A Full server
Comuni
(n.)
12
Media
(ab.)
5.600
Max
(ab.)
20.000
Min.
(ab.)
700
) gole 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
B Only client/desktop 18 12.000 96.000 1.900
C Only server 64 13.500 142.000 900 scelta di adottare FLOSS in entrambi gli ambiti applicativi ha dovuto coin-
D Both client/desktop & server 7 41.400 175.000 2.800 volgere sia i responsabili tecnici che gli organi decisionali/politici del Co-
Fonte: EROSS 2008
mune, imponendo una riflessione generale sui rischi e le opportunità
dell’adozione intensa di free e open source software. Questo gruppo rap-
presenta la testa di quei Comuni che compongono la nuvola di punti alla
In Tabella 2 i Comuni rappresentati in Figura 11 sono stati raggruppati loro sinistra, e per i quali ci si può attendere una progressiva crescita nel-
secondo criteri selettivi in gruppi omogenei che possono essere descritti l’intensità di utilizzo FLOSS sia server che client/desktop.
nei seguenti modi:
Identikit dei Comuni utilizzatori di FLOSS
A. Full server, presentano tutti il massimo grado di intensità di utilizzo di Provando a dettagliare le caratteristiche dei Comuni del campione, si è
FLOSS lato server, e si distanziano da tutti gli altri come ad evidenziare operata una divisione in categorie basata sul valore complessivo di iu-
l’importanza sostanziale di una scelta simile (che a quanto pare non è FLOSS24. Sono stati così definiti tre gruppi:
per tutti facile o praticabile). Questi Comuni sono di medie-piccole di-
mensioni (5.600 ab.), e probabilmente, proprio forti della loro ridotta • nessun utilizzo di FLOSS, iuFLOSS pari a zero;
complessità e delle scarse risorse economiche a disposizione, hanno • moderato utilizzo di FLOSS, 0%< iuFLOSS < 20%;
scelto di affidare la gestione dei propri server elusivamente a software • elevato utilizzo di FLOSS, iuFLOSS > 20%.
FLOSS;
B. Only client/desktop, tutti questi Comuni si sono dotati di software La soglia del 20% è stata fissata tenendo conto del valore medio del cam-
client/desktop FLOSS ed hanno probabilmente iniziato un processo di pione e delle scelte operate nell’analisi del 2006. In ultima approssima-
“migrazione” o “affiancamento” di prodotti FLOSS a quelli proprietari zione quindi, il 20% rappresenta un valore critico per distinguere tra
già in uso. Questi enti hanno una dimensione media doppia (12.000 ab.) quanti usano in modo “moderato” (inferiore alla media) FLOSS e quanti
rispetto a quella dei precedenti, e quindi, presumibilmente, possono ne fanno invece un uso “elevato” (superiore alla media).
contare su personale dedicato e strutture interne o esterne che si oc- La Tabella 3 fornisce per le diverse classi di utilizzatori una sorta di iden-
cupano di gestione e manutenzione del software installato. tikit. È possibile notare infatti che le dimensioni del Comune, intese come

28 29
 TABELLA 3 - IDENTIKIT COMUNI UTILIZZATORI DI FLOSS nitida. Il numero di fornitori cresce nel passaggio dalla classe di non uti-
lizzatori (2,8) a quella degli utilizzatori moderati (4,4), ma decresce, seppur
leggermente, (4) nel passaggio alla classe di utilizzatori successiva.
ELEVATO MODERATO NESSUN

(Dimensione media del Comune (abitanti)

UTILIZZO
DI FLOSS

18.749
UTILIZZO
DI FLOSS

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

4.151
) 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.
Dimensione mediana del Comune (abitanti) 7.222 6.273 3.472
% del totale dei Comuni 31% 40% 29% Nello specifico, nella classe di elevati utilizzatori di FLOSS il valore è di
Adozione di un atto di indirizzo sul FLOSS 15% 12% 8% 201 € per addetto, 316 € per addetto per gli utilizzatori moderati e 348 €
Presenza di un addetto all’ICT# 65% 59% 27% per addetto per i non utilizzatori. Questo dato da un lato non sorprende,
Strategia ICT# 29% 26% 9% perché è plausibile ipotizzare un rapporto inverso tra uso medio di FLOSS
Strategia di e-government# 32% 31% 21% e spesa media in licenze software per addetto, dall’altro è una prima im-
Connessione a banda larga (>2Mbps)# 77% 79% 74% portante conferma del risparmio reale che l’utilizzo di FLOSS può gene-
Il Comune realizza o commissiona attività
rare per i Comuni.
di sviluppo software 21% 8% 4%
Numero medio di fornitori ICT** 4,0 4,4 2,8
Spesa media in licenze software per addetto* 201 € 316 € 348 €
Da sottolineare è anche l’evidenza di un consenso abbastanza generaliz-
Parere favorevole a politiche della P.A. zato, e sostanzialmente trasversale alle tre classi di utilizzatori FLOSS, ri-
a favore del FLOSS 86% 80% 79% guardo 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.
Fonte: EROSS 2008,
# Rilevazione ICT PA Emilia-Romagna 2007. La Finanza del territorio. Tra i Comuni con un elevato utilizzo di FLOSS, il 21% ha sviluppato o ha
Note: * valore calcolato come rapporto tra il numero di addetti del 2006 e la spesa media fatto sviluppare software (FLOSS e non) proficuamente riutilizzabile da
in licenze software nel periodo 2004-2006, ** valore calcolato sui soli 79 Comuni che hanno altre amministrazioni (Tabella 3). Al calare dell’intensità di utilizzo, tale
risposto a questa domanda

numero (medio e mediano) di abitanti, influenzano l’intensità di utilizzo TABELLA 4 - SVILUPPO SOFTWARE (FLOSS E NON) DA PARTE O PER CONTO DEL COMUNE
del FLOSS. Lo scenario che sembra emergere fa immaginare che più
grande è un Comune, maggiore sarà la probabilità che adotti soluzioni
ELEVATO MODERATO NESSUN TOTALE
FLOSS, con un’intensità di utilizzo che aumenta all’aumentare delle di-
mensioni del Comune. In definitiva “le dimensioni contano”, anche se tut-
tavia 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 scel-
(Il Comune detiene la proprietà
UTILIZZO
DI FLOSS
UTILIZZO
DI FLOSS
UTILIZZO
DI FLOSS
(IUFLOSS>20%) (IUFLOSS<20%) (IUFLOSS=0%)
%

)
del software sviluppato# 89% 67% 0% 73%
gono 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 Tipologia software sviluppati (n.)*
valore dell’iuFLOSS > 0% sono il 71%, mentre il restante 29% ha un valore Sw “Sw general pourpose” 10 4 1 15
iuFLOSS pari a zero25. Sw “specializzato” 8 1 1 10
Sw “dedicato” 6 4 2 12
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 cre- Fonte: EROSS 2008,
Note: # La % è calcolata sul totale Comuni che hanno sviluppato o fatto sviluppare software.
scente all’aumentare dell’intensità di utilizzo di FLOSS, risulta ora meno * erano possibili più risposte

30 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 svilup-
pare 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 compe-
tenze in materia di software, disparità che si può ritenere esista tra Co-
muni 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 considera-
zione.
I software sviluppati, infine, si dividono abbastanza equamente tra soft-
ware “general pourpose” utilizzato per finalità generali27, software “spe-
cializzato” 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 soft-
ware (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 tipica-
mente 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 consu-
lenza, 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 tec-
nico, 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

ELEVATO MODERATO NESSUN TOTALE

(Responsabile settore ICT

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

48,8% 57,0% 21,8%

%

42,5%
) (
OSTACOLI NEL CAMBIO DI FORNITORE
ELEVATO
UTILIZZO
DI FLOSS
MODERATO
UTILIZZO
DI FLOSS
NESSUN
UTILIZZO
DI FLOSS
(IUFLOSS>20%) (IUFLOSS<20%) (IUFLOSS=0%) )
Utenti/Dipendenti 28,6% 23,4% 33,3% 28,4% Nessuno 11,90% 11,20% 15,40%
Ragioneria 6,0% 4,7% 3,8% 4,8% Migrazione archivi/dati 75,70% 71,70% 77,30%
Consulenti esterni 7,1% 6,5% 23,1% 12,3% Mancanza di altri fornitori competenti
Altri 9,5% 8,4% 17,9% 12,0% sul territorio 14,30% 15,20% 15,20%
Knowhow acquisito da personale 81,40% 67,40% 69,70%
Vincoli contrattuali 18,60% 17,40% 10,60%
Fonte: EROSS 2008
Altro 8,60% 6,50% 6,10%
Non sa/non risponde 4,80% 2,80% 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. Ap-
pare evidente che gli ostacoli maggiori per tutti i Comuni, indipendente-
mente 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 utiliz-
zano 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 pri-
vato.
TABELLA 7 - AZIONI DELLA PUBBLICA AMMINISTRAZIONE A FAVORE DEL FLOSS (FAVOREVOLI
VS CONTRARI)
LA PUBBLICA AMMINISTRAZIONE DOVREBBE ELEVATO MODERATO NESSUN
di una questione “di principio”, per i Comuni che non usano FLOSS la rile-
vanza relativa dell’aspetto tecnico ed economico è maggiore.
La Figura 12 e la Figura 13 registrano i pareri circa alcuni possibili inter-
venti 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% (“assoluta-
mente d’accordo” e “abbastanza d’accorto”). L’attività su cui i pareri favo-
revoli 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 favore-
voli (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.
FIGURA 12 – ESPRESSIONE DI FAVORE/SFAVORE NEI CONFRONTI DI AZIONI A SOSTEGNO
DELL’ADOZIONE DEL FLOSS NEL SETTORE PUBBLICO
TOTALE

( FARSI PROMOTRICE DI AZIONI A FAVORE

DEL FLOSS?

No
UTILIZZO
DI FLOSS

9,5%
UTILIZZO
DI FLOSS

16,8%
UTILIZZO
DI FLOSS
(IUFLOSS>20%) (IUFLOSS<20%) (IUFLOSS=0%)

16,7%
%

14,5%
) 100%

80%
Sì, in quanto i principi alla base del
FLOSS, quale la libera circolazione 60%
della conoscenza, sono
da ritenersi prioritari nell'agenda
della PA 63,1% 67,3% 46,2% 59,9%
80%
Sì, in quanto il FLOSS è
tecnicamente superiore ed 20%
economicamente vantaggioso 22,6% 13,1% 33,3% 21,9%
Non risponde 4,8% 2,8% 3,8% 3,7%
0%
OBBLIGO DI LEGGE REGOLE GENERALI REGOLE ATTIVITÀ ED INIZIATIVE
VALIDE PER TUTTE AMMINISTRATIVE INFORMATIVE
Fonte: EROSS 2008 LE PA E LINEE GUIDA
INTERNE DEFINITE
ASSOLUTAMENTE FAVOREVOLE DALLE SINGOLE PA

ABBASTANZA FAVOREVOLE
Se da un lato, come già detto, si registra un consenso generalizzato e so- ABBASTANZA CONTRARIO
ASSOLUTAMENTE CONTRARIO
stanzialmente trasversale alle tre classi di utilizzatori riguardo l’eventua-
NON SA, NON RISPONDE
lità 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 Fonte: EROSS 2008

34 35
 FIGURA 13 - ESPRESSIONE DI FAVORE/SFAVORE NEI CONFRONTI DI AZIONI A SOSTEGNO
DELL’ADOZIONE DEL FLOSS NEL SETTORE PRIVATO Per concludere questa descrizione dei dati raccolti, si riportano in Tabella
100% 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 sup-
poniamo di accettare l’idea che “maggiore è il numero di utilizzatori
80%
esclusivi, migliore la qualità del software”, allora i FLOSS giudicabili qua-
litativamente migliori sono quelli utilizzati per i server, e nello specifico
60% gli application server (che in 63 Comuni sono esclusivamente free o open
source). A questa valutazione occorre però affiancare un’altro principio
40% 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
20% almeno motiva il basso numero Comuni che utilizzano in modo esclusivo
FLOSS lato client/desktop.
0%
ATTIVITÀ DI FORMAZIONE COORDINAMENTO SUSSIDI E COINVOLGIMENTO
FINALIZZATE E PROMOZIONE FINANZIAMENTI DIRETTO ALLO SVILUPPO Considerazioni generali sui risultati
ALL'ADDESTRAMENTO
DI SVILUPPATORI/TECNICI
DI PROGETTI FLOSS E ALLA FORNITURA
DI SOLUZIONI FLOSS
dell’analisi descrittiva
COMPETENTI Le modalità di indagine scelte (questionario on line e contatti telefonici,
ASSOLUTAMENTE FAVOREVOLE ABBASTANZA CONTRARIO campionamento ed elevata rappresentatività) e la metodologia EROSS (ela-
ABBASTANZA FAVOREVOLE ASSOLUTAMENTE CONTRARIO borazione dell’indice di intensità di utilizzo, focus su software client/de-
NON SA, NON RISPONDE sktop e server, integrazione tra basi dati diverse, ecc…) hanno permesso di
Fonte: EROSS 2008 giungere ad una chiara e veritiera descrizione delle scelte in campo soft-
ware operate dai Comuni emiliano-romagnoli. In sintesi quindi:
TABELLA 8 - SOFTWARE FLOSS IN USO NEI COMUNI DELL'EMILIA-ROMAGNA
• il 63% dei Comuni dell’Emilia-Romagna ha esplicitamente dichiarato di
usare free, libre, open source software (34,4% è la media nazionale);

(AMBITO DI UTILIZZO FLOSS IN USO NEI COMUNI

EMILIANO-ROMAGNOLI

Sistema operativo per il desktop Gnu-Linux

COMUNI CHE USANO
ESCLUSIVAMENTE FLOSS

0%
) • un ulteriore 14% di Comuni della regione, pur essendosi dichiarati non uti-
lizzatori, risultano invece avere installazioni di FLOSS e si configurano
come utilizzatori inconsapevoli (e quindi portatori di un gap di cono-
Software di Gestione di posta Mozilla Thunderbird, Evolution scenza).
elettronica Mail, Netscape Messenger 2% • in totale, quindi, il 77% dei Comuni (quasi quattro su cinque) utilizza FLOSS
Mozilla Firefox, Netscape Naviga- negli ambiti applicativi indagati (client/desktop e server);
Browser Internet tor, Mozilla, Flock 1%
• oltre un Comune su dieci ha adottato un atto di indirizzo strategico o am-
Office Automation OpenOffice, Scribus 1%
ministrativo avente ad oggetto l’adozione di software free, libre, open
Sit/Gis Quantum Gis, MapServer 1%
Web Server Apache 6%
source. Dimostrazione che l’attenzione per il FLOSS travalica anche i con-
Apache Tomcat, PHP, Jboss, Zope, fini settoriali dei sistemi informativi per diventare oggetto di riflessioni
Application Server Xaraya, Perl 20% ampie e trasversali all’ente;
Postfix, Cyrus IMAP server, Qmail, • l’intensità di utilizzo di FLOSS (iuFLOSS) è più elevata nelle fasce dimensio-
Send Mail, Open-Xchange, Exim, nali di Comuni che stanno agli estremi (Comuni molto piccoli - <3.000 ab. -
Mail Server HMailServer, Dovecot 9% e Comuni grandi - >15.000 ab.);
File Server Samba, FreeNAS 4% • le differenze tra territori provinciali sono evidenti sia dal punto di vista ge-
Server di desktop remoto VNC, PuTTY, Open SSH, Xorg X11 4% nerale che sugli aspetti specifici e quindi sull’intensità di utilizzo FLOSS ri-
Data base management systems MySQL, PostgreSQL, In gres 3%
ferita ai singoli ambiti applicativi del software;
Printer server Linux/CUPS, LPRng 1%

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 di-
mostrazione 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’Emilia-
Romagna mostraì come il sistema operativo FLOSS GNU/Linux non sia ad
oggi pensato ed utilizzato quale alternativa vera al leader di mercato pro-
prietario. 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 ora-
mai 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/dipen-
• testare un secondo modello econometrico, questa volta a carattere non li-
neare, introdotto per individuare i fattori atti a spiegare l'adozione di soft-
ware a codice sorgente aperto da parte delle stesse pubbliche
amministrazioni;
• integrare i due modelli in una specificazione che prendesse in considera-
zione 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, conte-
nenti una serie di fattori (variabili indipendenti).
TABELLA 9 - MODELLO I – FATTORI CHE INFLUENZANO IL LIVELLO DI INTERATTIVITÀ
DEI SERVIZI OFFERTI ON LINE
( Specificazione [a]

VARIABILE DIPENDENTE
Specificazione [b]

VARIABILE DIPENDENTE
)
Interattività servizi on line Interattività servizi on line
denti e i consulenti esterni;
• c’è un generale accordo, tra i rispondenti, sull’opportunità di politiche attive VARIABILI INDIPENDENTI VARIABILI INDIPENDENTI
dalla PA a favore del FLOSS, con le ragioni di “principio” che prevalgono su • spesa totale in software e hardware • spesa totale in software e hardware
quelle tecnico-economiche; • numero di dipendenti nella divisione ICT • numero di dipendenti nella divisione ICT
• tra le possibili azioni i maggiori consensi vanno alle “attività e iniziative for- • spesa in formazione ICT per il personale • spesa in formazione ICT per il personale
mative”, mentre i minori ai “sussidi a favore di privati che operano in campo • numero di dipendenti della PA • numero di dipendenti della PA
FLOSS”. • adozione di software a codice sorgente • esistenza di un atto di indirizzo rivolto al-
aperto l'adozione di software a codice sorgente
Analisi avanzata • esistenza di una strategia di e-government aperto
• disponibilità di accesso alla rete in banda • esistenza di una strategia di e-government
Come già fu fatto in occasione della rilevazione EROSS 2006, anche in quella
larga • disponibilità di accesso alla rete in banda
del 2008 sono state effettuate una serie di analisi avanzate volte, da un lato,
• presenza di una carica politica con delega larga
a verificare i risultati raggiunti nell'edizione precedente30 e, dall'altro, ad ap- all'informatica/telematica • presenza di una carica politica con delega
profondire tali risultati. In particolare si è proceduto a: • esistenza di una strategia di ICT all'informatica/telematica
• esistenza di una strategia di ICT
• testare un primo modello econometrico lineare, ove un indicatore del li-
Fonte: EROSS 2008
vello di interattività dei servizi on line offerti dalle pubbliche amministra-
zioni emiliano-romagnole è stato fatto dipendere da una serie di variabili Il risultati sono pressoché identici per ambedue le specificazioni, salvo che
ritenute rilevanti; 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

38 39
 l'adozione di software a codice sorgente aperto (FLOSS) non risulta signifi-
cativa nello spiegare il livello di interattività, l'esistenza di un atto di indi-
rizzo 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 ser-
vizi on line, il secondo modello è stato a tal fine articolato su due speci-
ficazioni alternative, volte a investigare più nel dettaglio i fattori
(variabili indipendenti) che: (1) spiegano la probabilità di adozione di soft-
ware 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 (specifica-
zione [b] in Tabella 10).
TABELLA 10 - MODELLO II - FATTORI CHE INFLUENZANO L'ADOZIONE DI FLOSS, SPECIFICA-
ZIONE [A], E L'ESISTENZA DI UN ATTO DI INDIRIZZO VERSO IL FLOSS, SPECIFICAZIONE [B].
( Specificazione [a]
I risultati indicano chiaramente come la presenza di una carica politica
con delega all'informatica e/o alla telematica sia una variabile significa-
tiva 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 proba-
bilità è 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 ot-
tenuti dall'analisi condotta nel 2006 sono validi anche con i nuovi dati
(che permettono di superare uno dei punti deboli della precedente ana-
lisi, 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:
• esiste una relazione positiva tra il livello di interattività dei servizi on-
line e l'adozione di FLOSS da parte dei Comuni emiliano-romagnoli
(EROSS 2006 e EROSS 2008);

VARIABILE DIPENDENTE
Specificazione [b]

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
Fonte: EROSS 2008
VARIABILE DIPENDENTE
) • tale relazione è rilevante solo se il Comune ha posto in essere un atto di
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
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 svi-
luppate 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 com-
petenze specifiche nel campo e con un potere decisionale forte (EROSS
2008).
Concludendo, la presenza di un atto formale a favore del FLOSS e la pre-
senza di una persona che abbia sufficiente potere decisionale per pro-
porre e supportare nel tempo tale decisione sono condizioni necessarie,
ma non sufficienti, per incentivare il livello di interattività dei servizi on-
line 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, è ne-
cessaria una scelta strategica formalizzata e supportata adeguatamente.

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, nel-
l'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, associa-
zioni di categorie, imprese, ecc.) per la loro realizzazione e partecipa-
zione. 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 Opera-
tivo 2008 del PiTER.
Il Piano telematico dell’Emilia-Romagna 2007-2009 si differenzia dalle pro-
grammazioni precedenti in quanto agisce sull’intero territorio regionale,
coinvolgendo tutte le Amministrazioni Pubbliche (Regione, Province, Co-
muni e loro forme di aggregazione) e riconoscendo elevato valore alle di-
namiche 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 mi-
gliore dei modi alle differenti caratteristiche degli interventi previsti nel
PiTER ed allo scopo di eliminare eventuali ambiguità. Una scelta meto-
dologica di fondo è stata quella di non operate differenziazioni tra pro-
getti 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 on-
line che, sottoposto ai capi progetto nel periodo giugno-luglio 2008, ha
portato ad ottimi risultati con un tasso di risposta del 95% (delle 3 rispo-
ste mancanti, due riguardano progetti in rimodulazione in quanto stret-
tamente connessi all’erogazione di fondi nazionali bloccati).
Analisi descrittiva
La maggior parte dei progetti del PiTER, Figura 14 [a], prevede l’acquisi-
zione o sviluppo di software (quasi il 70%). Restano escluse quelle azioni
42
prettamente infrastrutturali (reti fisiche) e quelle che mirano all’inclu-
sione, 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¤
13%
12%
6¤ M¤
17%
3%
26% 70% 43% 51%
40% 82¤ M¤
4% 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 pro-
getti del PiTER che prevedono l’acquisizione o lo sviluppo di software è pos-
sibile 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’Amministra-
zione Digitale35, la massima disponibilità del software che potrà essere di-
stribuito 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
 FIGURA 15 – PROGETTI CHE PREVEDONO ACQUISIZIONE E/O LO SVILUPPO DI SOFTWARE
Ulteriore aspetto che emerge evidente in Figura 14 è che se in termini nu-
DISTINTI SULLA BASE DELLA PREVALENZA DELLA TIPOLOGIA DI SOFTWARE
merici i progetti che impiegano prevalentemente FLOSS (17%) sono più di
quelli che dichiarano di utilizzare in prevalenza software proprietario
[a] Percentuale del budget del progetto destinata all’acquisizione
(13%), tale rapporto varia e di molto (3% FLOSS e 12% proprietario) se ci si
e/o sviluppo di software
focalizza sul valore economico degli stessi progetti.
100%
Approfondendo quest’ultimo aspetto, Figura 15, si può notare come le 90%
scelte dei capi progetto varino in funzione dell’aumentare del valore ge- 80%
nerale del progetto ed anche in rapporto all’aumentare della percentuale
70%
di budget di progetto destinata all’acquisizione e/o sviluppo di software.
In generale, oltre il 45% dei progetti che compongono il primo percentile 60%
della Figura 15 [b] utilizzano soluzioni FLOSS; mano a mano però che il 50%
valore dei progetti sale, questa opzione viene completamente abbando- 40%
nata a favore dei software di proprietà della PA e proprietari. Di fronte a
progetti il cui budget è molto rilevante, e in cui è particolarmente signi- 30%
ficativo il peso della componente software, il capo progetto del PiTER 20%
opta per soluzioni di cui detiene o prevede di acquisire la proprietà. 10%
Nonostante il software libero e a codice sorgente aperto non rappresenti
0%
l’opzione software prevalente nella realizzazione dei progetti del PiTER, A. B. C. D.
meno del 5% tra il 6% tra il 16% oltre il 50%
alcuni tra i più famosi prodotti FLOSS sono diffusamente utilizzati in una e il 15% e il 50%
elevata percentuale di interventi. Come si nota in Figura 16, sistemi per i
[b] Valore economico del progetto (percentili*)
server come Apache, MySQL, PostgreSQL, Jboss, Tomacat e Linux sono
100%
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 90%
considerare qualitativamente affidabili e maturi. 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 va-
lore economico del progetto.

44 45
 Sono 42 i progetti che dichiarano di sviluppare software che potrebbe essere
FIGURA 16 – SOFTWARE FREE O OPEN SOURCE UTILIZZATI NEI PROGETTI DEL PITER
proficuamente riusato da altre amministrazioni (si tratta dell’84% dei pro-
(% PROGETTI CHE PREVEDONO ACQUISIZIONE E/O LO SVILUPPO DI SOFTWARE)
getti che prevedono acquisizione e/o sviluppo di software). La maggior
60% parte di questo software è di tipo “specializzato”, destinato ad usi speci-
fici (sicurezza, gestione e manutenzione server, CMS, Intranet, ecc.), e/o
50% “dedicato”, cioè usato per eseguire funzioni tipiche della Pubblica Ammi-
nistrazione (protocollo informatico, posta elettronica certificata, firma
40% digitale, ecc...).
Dal punto di vista della proprietà del codice, sono tre i progetti che non
30% la detengono e che quindi non possono attuare forme di “riuso”; 25 ne
sono proprietari e perciò possono legittimamente cedere o trasferire il di-
ritto all’utilizzo del software; e 14 (uno su tre) ammettono di non sapere
20%
con esattezza di chi sia la proprietà del programma informatico.
10%
FIGURA 17 - RAGIONI/VALUTAZIONI CHE GUIDANO LA SCELTA DEL CAPO PROGETTO CIRCA

0% LA TIPOLOGIA DI SOFTWARE DA ACQUISIRE E/O SVILUPPARE

Linux Apache MySQL/PostgreSQL Tomcat JBoss

[a] Percentuale del budget del progetto destinata all’acquisizione e/o sviluppo
Progetti che utilizzano in prevalenza software di proprietà della PA
di software
Progetti che utilizzano in prevalenza software free, libre o open source
Progetti che utilizzano in prevalenza software proprietario 100%
90%

Fonte: EROSS-PITER 2008 80%

70%
Le principali ragioni/valutazioni che guidano la scelta sulla tipologia di soft- 60%
ware possono aiutare a comprendere il perché della predilezione per quello
50%
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 40%
fra coloro che guidano le proprie scelte sulla base di motivazioni legate alle 30%
funzioni/prestazioni, e coloro che pongono particolare attenzione agli
20%
aspetti di costi/benefici.
Praticamente nessun capo progetto, invece, si affida all’esperienza e alle mo- 10%
tivazioni di tipo personale o alla consistenza dei costi di acquisizione, 0%
A. meno del 5% B. tra il 6% e il 15% C. tra il 16% e il 50% D. oltre il 50%
aspetto questo che evidenzia l’approccio analitico con cui le scelte vengono
realizzate. funzioni/prestazioni attuali del software
Differenze interessanti possono comunque essere rilevate per quei progetti funzioni/prestazioni potenziali e future del software
che prevedono un ridotto impatto della componente software sul budget esperienza e a motivazioni personali
totale di progetto, e per i quali è sostanzialmente dominante il criterio della costi di acquisizione
valutazione delle funzioni/prestazioni potenziali e future. costi/benefici pluriennali
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), pon-
gono più attenzione degli altri agli aspetti funzionali e prestazionali attuali
del software.

46 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
10 25%

0
Percentile 1 Percentile 2 Percentile 3 Percentile 4
0%
OBBLIGO DI LEGGE REGOLE GENERALI REGOLE ATTIVITÀ ED
funzioni/prestazioni attuali del software VALIDE PER TUTTE LE PA AMMINISTRATIVE INIZIATIVE
funzioni/prestazioni potenziali e future del software E LINEE GUIDA INFORMATIVE
INTERNE DEFINITE
esperienza e motivazioni personali
costi di acquisizione
[b] settore privato
costi/benefici pluriennali
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 va-
lore economico del progetto. 75%

La mancanza di una chiara informazione su chi detiene i diritti di un pro-

dotto software che “potrebbe proficuamente essere riusato da altre ammi- 50%
nistrazioni” 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 25%
open source ed autentiche di proprietà della PA porta alla creazione di solu-
zioni software ibride, per le quali non è chiaro (e non viene chiarito) il livello
0%
di trasferibilità e legittimo riuso. Per concludere, in Figura 18 sono rappre- ATTIVITÀ DI COORDINAMENTO SUSSIDI E COINVOLGIMENTO
sentate le opinioni dei capi progetto del PiTER circa l’opportunità di inter- FORMAZIONE
FINALIZZATE
E PROMOZIONE
DI PROGETTI FLOSS
FINANZIAMENTI DIRETTO ALLO
SVILUPPO E ALLA
venti della PA a favore del FLOSS nel settore pubblico e privato (i quesiti sono ALL'ADDESTRAMENTO FORNITURA
DI SVILUPPATORI/ DI SOLUZIONI FLOSS
i medesimi proposti ai Comuni e descritti in Figura 12 e Figura 13). Come si TECNICI COMPETENTI
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 assolutamente favorevole abbastanza contrario
per tutta la PA. Sono invece meno sostenute le altre opzioni di intervento abbastanza favorevole assolutamente contrario
proposte. Sul fronte del settore privato, Figura 18 [b], si riscontra un minor non sa, non risponde
favore, specie per ipotesi di sussidi e finanziamenti, che però raggiunge livelli
molto elevati nel caso di coordinamento e promozione di progetti FLOSS. Fonte: EROSS-PITER 2008.

48 49
 3
Considerazioni generali Capitolo 3: esperienze e casi d’uso
L’analisi dei dati raccolti da EROSS circa l’acquisizione e lo sviluppo di
software nei progetti del Piano telematico dell’Emilia-Romagna 2007-
Il software libero a codice sorgente aperto è frequentemente utilizzato
2009 pone in evidenza che:
nei Comuni e negli altri EELL dell’Emilia-Romagna, e spesso elementi
• i project manager prediligono componenti informatiche di proprietà
FLOSS sono alla base dei sistemi informativi che vengono progettati e
della Pubblica Amministrazione e quindi, nonostante il free, libre, open
realizzati nell’ambito di importanti e impegnativi progetti di e-gover-
source software sia largamente diffuso ed utilizzato (ma non prevalen-
nment. Di seguito sono riportate alcune significative esperienze che
temente), i prodotti software acquisiti e/o sviluppati nel PiTER saranno
hanno interessato Pubbliche Amministrazioni emiliano-romagnole.
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 svi-
luppo software influisce marginalmente sul budget di progetto;
• l’84% dei progetti che acquisisce e/o sviluppa software ritiene di pro-
Regione Emilia-Romagna
durre codice che potrebbe proficuamente essere riutilizzato da altre
DG Centrale Organizzazione, Personale,
amministrazioni ma un numero non irrilevante non ha chiarezza su chi
Sistemi informativi e Telematica
ne sia il legittimo proprietario;
• esiste un sostanziale favore per azioni di supporto all’adozione del
Fabio Bucciarelli e Alessandro Landi
FLOSS nel settore pubblico (in particolare per attività di tipo informa-
Servizio Sistema informativo-informatico
tivo) e in quello privato (nel coordinamento e promozione di progetti
regionale
FLOSS);
• i progetti del PiTER, pur detenendo nella maggior parte dei casi la pro-
prietà del software acquisito e/o sviluppato, non hanno previsto azioni
che chiariscano nel dettaglio quali componenti del codice siano sotto-
Sono alcuni anni che la Regione Emilia-Romagna sta valutando l’uso del
posti a licenza (proprietaria o FLOSS) e quali invece possano essere “li-
software free e/o open source sia nell'area client che nell'area server,
cenziati” (magari FLOSS) dalla PA in modo da favorire politiche di riuso
ancor più da quando le linee guida del CNIPA e il Codice dell’Amministra-
e standardizzazione.
zione 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 pre-
senti alcuni server Linux che gestiscono applicazioni Web attraverso Apa-
che, 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 ba-
sato 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 alta-
mente 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'amministra-
zione 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-

50 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 fi-
liera commerciale già supportata e realizzata con i software MS Win-
dows, Oracle e IBM WebSphere. Si è trattato quindi di valutare la
fattibilità dell'introduzione di FLOSS per le seguenti categorie di soft-
ware: (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 con-
fronto di tutti gli aspetti tecnico/funzionali, anche i rischi derivanti da
un'eventuale adozione per gestire processi critici. Occorreva quindi te-
nere conto di fattori quali: il livello di maturità della soluzione software,
la qualità e quantità di documentazione, l'attività, consistenza e indipen-
denza del team di sviluppo, i servizi di supporto, e così via. Al fine di ri-
durre il livello di soggettività nella scelta, è stata ricercata una
metodologia già collaudata nella valutazione di FLOSS. Sorprendente-
mente, 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 in-
terno una comunità attiva, fornendo anche numerosi strumenti a sup-
porto 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, predispo-
nendo delle griglie multi-livello di valutazione contenenti criteri di valu-
tazione sia generali che specifici per ciascuna categoria di software,
assegnando poi per ogni voce punteggi e pesi, fino ad operare la scelta fi-
nale.
Lo studio effettuato ha portato a concludere che per quanto riguarda si-
stema 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 affida-
bili, 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 è ca-
duta 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 Web-
Sphere, Oracle), quello basato su piattaforma Linux (Linux Red Hat, Apa-
che, 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 di-
sponibili 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à co-
stituito 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 pre-
vede di mettere in produzione un cluster a disposizione del Sistema Infor-
mativo 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 uti-
lizzare 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-govern-
ment supportati dal CNIPA, già avviati e che avranno un forte sviluppo
nei prossimi anni, quali Sigmater, Sistema Informativo Lavoro, interope-
rabilità 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 applica-
zioni “open standard” compatibili con la filiera applicativa A su piatta-
forma 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 regio-
nale.
Per quel che riguarda l'area client, è stato avviato un percorso che pre-
vede 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 siste-
misti 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 per-
mette al personale IT un maggior controllo sui servizi offerti, in quanto si
tratta di software maggiormente adattabile e non dipende da un forni-
tore specifico (con economie legate anche al risparmio sui costi di li-
cenza). D'altra parte però, l’utilizzo di FLOSS richiede al personale ITC
maggiori capacità di integrazione e configurazione, in quanto non è pos-
sibile acquisire soluzioni free o open source “chiavi in mano”. Si ritiene in-
vece 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 compe-
tenze interne sulle tecnologie FLOSS, al fine di promuoverne lo sviluppo,
la diffusione e la conoscenza, soprattutto nell’ottica di favorire il plura-
lismo 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 trasfor-
mare 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 com-
puterizzato per l'archiviazione digitale e la diagnostica delle immagini
radiologiche, che permette la loro trasmissione e visualizzazione me-
diante rete informatica. Il PACS, in via di federazione con l’analogo si-
stema 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’infrastrut-
tura. Operata una valutazione dei prodotti di mercato, e considerati i re-
lativi 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 rispon-
desse in tutto e per tutto ai bisogni specifici dell’AUSL.
Per operare in tal senso, fu quindi coinvolto un esperto in materia del-
l’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 indi-
viduata comprendeva quattro sviluppatori (cinque in fase finale) affian-
cati da una società esperta degli aspetti sistemistici di rete nonché, in
qualità di debugger e co-fruitore della sperimentazione, la Regione Emi-
lia-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 pre-
senza) 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 (adot-
tando un approccio “accademico”), con difficoltà nel recepire le neces-
sità 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 speci-
fiche, tali da poter distribuire la raccolta dei dati. In altri termini, un mo-
dulo di Monitoring, uno di Gathering ed uno di Rendering, che hanno
dato vita all’acronimo MORGANA - Monitor Render Gather Network Advi-
soring (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 soft-
ware 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 possibil-
mente 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 rispet-
tare 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 affi-
darsi a società o professionisti abituati ad operare in una logica di mer-
cato. In questo senso sarebbe opportuno facilitare il percorso di
convenzionamento o di attivazione di collaborazioni tra la Pubblica Am-
ministrazione e le Università, in quanto troppo spesso la burocrazia uc-
cide 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 ac-
ceso, 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 do-
vrebbe 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 na-
tura 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 sitory, ai quali vengono resi disponibili i link di collegamento.
calcolato su di un arco temporale ampio, affinché possa essere fatta L’individuazione di best pratice può favorire un incentivo alle PA nelle
un’adeguata valutazione del rapporto tra gli investimenti fatti ed il ri- loro componenti politiche e tecniche, per adottare soluzioni che possano
torno degli stessi); essere prese a riferimento da altre amministrazioni per qualità ed eco-
• costo di uscita dalla soluzione (occorre che venga valutato il costo di nomicità, evitando il proliferare di soluzioni duplicate e che richiedono
uscita da una soluzione in termini sia tecnologici che di formazione investimenti ex novo per la soluzione di problemi già risolti altrove.“
degli utilizzatori);
• valorizzazione delle competenze tecniche possedute dall’amministra- La AUSL di Reggio Emilia oggi utilizza con soddisfazione Zenoss MOR-
zione (valutazione di come la soluzione aumenta le competenze in- GANA per gestire la propria rete; il software è disponibile sia nel reposi-
terne); tory CNIPA38 che in Sourceforge39.
• interoperabilità intesa per la PA nel suo complesso (utilizzo di formati
aperti e standard, piattaforme multiple); Si sta ora attivando un software per la realizzazione dell’archivio delle
• valutazione dell’interesse di altre amministrazioni al riuso dell’applica- bio-immagini e la Federazione dei PACS aziendali tra la AUSL e l’Azienda
zione da realizzare e/o acquistare (attenzione al riuso e quindi, in caso Ospedaliera di Reggio Emilia, derivando gli elementi applicativi dal pro-
di sviluppo di nuove soluzioni, indicazione di caratteristiche atte alla getto open source MARIS40, pubblicato anch’esso sul sito del CNIPA e su
portabilità e alla fruibilità da parte di altri utilizzatori); Sourceforge. Sempre attingendo dal repository CNIPA, si sta altresì adot-
• valore sociale della soluzione (analisi di quanto la soluzione porta even- tando il software open source IntranetDPS41 per la gestione del docu-
tuali benefici alla comunità in termini di attività orientata all’eroga- mento per la sicurezza.
zione di servizi).
Morgana: regina dell’isola di Avalon, sorellastra e amante di re Artù, al-
Nella individuazione delle soluzioni da adottare, facendo particolare ri- lieva del mago Merlino. Fata, Dea celtica, ninfa ed anche un miraggio. La
ferimento alla riusabilità di SW esistente alla quale tutte le PA centrali e magia di Morgana è forse la più potente che sia mai esistita. E forse è pro-
locali devono tendere, occorre che la rispondenza alle proprie esigenze prio tutto vero!
venga effettuata attraverso un’analisi delle possibili soluzioni tra le se-
guenti possibilità e secondo l’ordine indicato:
• riuso di programmi informatici sviluppati ad hoc per altre amministra-
zioni con verifica sul sito del CNIPA della presenza di programmi idonei;
• sviluppo di programmi informatici ad hoc, sulla scorta dei requisiti indi-
cati 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 ri-
corso a licenza d'uso;
• acquisizione mediante combinazione delle modalità di cui alle lettere
precedenti.

Pertanto assume un ruolo fondamentale il catalogo del CNIPA come rife-

rimento 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, in-
terventi. 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, com-
plicato si intende, meglio lasciar perdere: si dovrebbero disegnare pro-
cessi 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 del-
l’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 po-
terli interpretare e confrontare con pre-individuati scenari di riferimento,
e per produrre le necessarie valutazioni in ordine agli effetti attesi; rico-
noscere 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 fun-
zioni e dei ruoli individuati nei modelli d’intervento; produrre, comuni-
care e divulgare rapidamente informazioni di varia natura con diversi
gradi di sintesi; realizzare analisi di tipo multidimensionale in forma as-
sistita.
Ora, se queste sono le esigenze degli utenti, non possono essere dimen-
60
ticate anche le necessità dei progettisti che hanno il compito di architet-
tare e realizzare il sistema informativo. Risulta quindi necessario, per ga-
rantire un risultato conforme ai “desiderata”, postulare, a priori, alcuni
rigorosi principi generali, del tipo: definizioni e classificazioni costitui-
scono il lessico comune per tutti i sotto-sistemi settoriali; dati di tipo ge-
nerale 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-si-
stemi settoriali; tutto il patrimonio informativo è certamente localizza-
bile, 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 av-
viato 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 prevalen-
temente da Servizi regionali (Servizio Sistemi Informativi Geografici e
Servizio Geologico, Sismico e dei Suoli) e da ARPA (Servizio Idro-Meteo-
Climatico), costituiva il patrimonio informativo residente negli hard disk
degli utilizzatori. Dati che venivano principalmente impiegati per la Pia-
nificazione dell’Emergenza, per la predisposizione del Programma Regio-
nale 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 emer-
genze 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é, in-
vece, è orientata a fruire i dati e le informazioni secondo un approccio
Client/Server, comportavano che i medesimi (dati e informazioni) risul-
tassero distribuiti presso le postazioni locali dei singoli utilizzatori de-
primendo così i benefici della centralizzazione condivisa ed aumentando
i costi conseguenti alla proliferazione delle licenze d’uso dei diversi ap-
plicativi software. Ne derivava una riduzione dell’efficienza dell’intero
Sistema della Protezione Civile Regionale che, in riferimento alla norma-
tiva vigente, è composto da vari enti e strutture operative chiamate a ri-
spondere alle emergenze in modo coordinato per poter assicurare
l’efficacia dell’intervento. Ciò è tanto più vero per quanto attiene l’effet-
tiva 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 conte-
stuale di operatori della Regione, del Corpo dei Vigili del Fuoco , del Corpo
61
 Forestale dello Stato, del volontariato, ecc…; tali operatori necessitereb-
bero, infatti, di interagire fra loro con riferimento a piattaforme informa-
tive 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’im-
pianto 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 og-
getto registrato nel dataset è ora caratterizzato dalle sue coordinate spa-
zio-temporali e da metadati, è stato superato il concetto di cartografia
con quello di Modello Terrestre di Riferimento (MTR), sono stati proget-
tati e realizzati moduli software con tecnologia Web based basati sugli
standard regionali con il massimo impiego di Web services e quindi ga-
ranzia di interoperabilità, sono state tenute in considerazione accessibi-
lità, sicurezza e rispetto della privacy, i moduli software, i dati e le
informazioni sono stati collocati sui server del CED Regionale ed esegui-
bili da consolle di comando o di regia da qualunque postazione
Intranet/Internet dotata di un semplice browser Internet, sono stati pro-
gettati 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, assegna-
zione di coordinate spazio-temporali agli oggetti; recepimento di stan-
dard internazionali, nazionali e regionali; enucleazione dai dataset
originali di terminologie, definizioni e classificazioni per costruire i di-
zionari e i glossari; predisposizione dell’infrastruttura hardware e soft-
ware 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 con-
sultazione via Web in ambiente Microsoft Windows Server 2003 è stato
conseguito; fra dati e documenti, sono stati “guardati” e “messi a si-
stema” 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 di-
mensionata. 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’al-
tra; 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, co-
munque, 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 som-
mato 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ì forte-
mente 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 mo-
mento 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 patrimo-
nio 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 Ser-
ver; 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 concre- taforma Linux RedHat AS 5, WS Apache, AS JBoss, DB PostgreSQL, con
tizza in minori tempi di sviluppo e migliore qualità del software a dispo- estensione PostGIS, MapServer (funzionalità di map rendering), libreria
sizione degli utilizzatori; pgRouting (funzionalità di gestione dei grafici), libreria R + SPATSTAT (fun-
• la formazione di competenze, sugli ormai numerosissimi prodotti e zionalità di statistica e grafici)42.
componenti open source, nei team di sviluppo accresce la tempestività Spostando ora l’attenzione sulle applicazioni, due sono stati i momenti
nel rispondere alle esigenze degli utenti finali, in quanto vengono pra- di meditazione e discussione: il primo, sull’ambiente di sviluppo; il se-
ticamente azzerati i tempi di individuazione del fornitore e di contrat- condo sull’interfaccia utente.
tazione commerciale; Gli strumenti e i linguaggi individuati per lo sviluppo delle applicazioni
• l'eterogeneità della domanda di software specialistico costringe i pro- sono Eclipse, il Java Enterprise Wide Framework SPAGO, Javascript, l’Ap-
duttori ad allargare la copertura funzionale dei loro prodotti: essi risul- plication Server JBoss. Particolare attenzione viene posta nei confronti
tano quindi sovradimensionati e scarsamente modulari con costi non dello sviluppo dei componenti ,ogniqualvolta si ravvisa la necessità che
accettabili se rapportati alle esigenze talvolta limitate e più spesso al- questi vadano ad implementare le librerie.
tamente specifiche degli utenti finali. Per contro, il codice open source
è per definizione personalizzabile rispetto a particolari esigenze degli L’interfaccia utente è organizzata a menu e pannelli informativi e risulta
utenti (anche se non sempre il gap qualitativo rispetto al software pro- flessibile anche in configurazione “multi screen”, potendo inviare i pan-
prietario è facilmente colmabile e le competenze necessarie facilmente nelli a diversi client/monitor. La disposizione e numerosità dei pannelli è
reperibili). configurabile sia dalla tipologia dell’applicazione che dall’utente. È inol-
Per quanto riguarda poi i contratti di manutenzione ed assistenza, pare tre predisposta per l’emergente interfaccia “multi touch screen”.
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 pro-
dotti open source e la presenza sul Web di numerosi forum e comunità di
sviluppatori e utilizzatori rendono estremamente agevole il problem sol-
ving. È in tal senso importante indirizzare la scelta dei prodotti open
source verso quelli assunti come standard de facto dalla comunità inter-
nazionale open source.
Non va inoltre dimenticato un punto cruciale di fondamentale impor-
tanza, 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 Si-
stema Informativo non è così completo e non è così semplice: le intera-
zioni fra le diverse componenti della Protezione Civile possono essere le
più varie e impreviste; ciò si può trasformare in richieste specifiche o per-
sonalizzazioni; 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.

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 integra-
zione 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 utiliz-
zate 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 am-
biente 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 la-
voro; possibilità di veloci aggiornamenti, gestione delle dipendenze o even-
tuali 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 si-
stemi di calcolo parallelo proprietari presso centri di supercalcolo, sono
state duplicate, a fini di backup e di sperimentazione, su sistemi di cal-
colo parallelo a basso costo ospitati presso il SIMC. Ciò è stato possibile
grazie al progresso, al basso costo dell'hardware di uso comune (proces-
sori e connessioni di rete) e alla completezza e stabilità raggiunta dal si-
stema 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, comu-
nicazione di rete, Input/Output) delle applicazioni specifiche a cui era mi-
rato, 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 nume-
rici (modelli) a fini previsionali operativi e svolgere attività di ricerca ap-
plicata. Lo Stato del Mare, ossia la proprietà delle onde, può essere
ottenuto mediante modelli numerici. A questo proposito ci si avvale ope-
rativamente del modello numerico SWAN45, che, supportato dal Mini-
stero dei Trasporti, dei Lavori Pubblici e dalla Gestione Acque dei Paesi
Bassi, è stato sviluppato ed è continuamente aggiornato dal Diparti-
mento 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 segnala-
zioni e contributi. A contorno il codice è corredato di un'ottima manuali-
stica e di aziende private che offrono servizi e consulenze specifiche.
L’area Meteorologia Ambientale si occupa di tutti gli aspetti meteorolo-
gici 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 meteoro-
logici e di emissione, archiviazione e rappresentazione grafica dei risul-
tati). Di fondamentale importanza è stato quindi avere accesso al codice
sorgente e poterlo modificare liberamente.
SVILUPPO DI SOFTWARE SCIENTIFICO AL SIMC E LA COMUNITÀ IN-
TERNAZIONALE.
Il servizio meteorologico di ARPA Emilia-Romagna ha sviluppato negli
anni alcuni software ad uso scientifico dettati da proprie esigenze in-
terne. Per tale sviluppo ci si avvale esclusivamente di strumenti FLOSS. I
software sviluppati più significativi sono distribuiti con licenza GPL; que-
sto 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'investi-
mento 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 perso-
nale interno committente e utente del software stesso), che ha per-
messo 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 assegna-
taria;
• 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, no-
nostante le risorse dedicate per la diffusione;
• numero ridotto di aziende competenti in ambito FLOSS.
68
Provincia di Forlì-Cesena
Sandro Mazzotti
Dirigente del Servizio Sistema Informativo
della Provincia di Forlì-Cesena
L’esperienza che la Provincia di Forlì-Cesena ha maturato sul tema del-
l'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 al-
ternativo concretamente utilizzabile nell’Amministrazione. Le principali
motivazioni alla base dell’intervento della Giunta furono di natura eco-
nomica 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 contri-
buto 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 ap-
pesantivano 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 Mi-
crosoft 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 am-
bienti “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 speri-
mentazione 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 dispie-
gamento “indolore” del nuovo ambiente è la disponibilità dei sw applica-
tivi 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 ri-
lascio 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 re-
lease SW per tutti gli Enti locali della Provincia.
Al fine di raggiungere un completo affrancamento dall’obbligo di ade-
guare 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 Svi-
luppo 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 del-
l'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 cor-
retta lettura e trattamento;
È stata inoltre formalizzata e comunicata a tutti gli utenti interni la mo-
dalità 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 “fi-
niti” 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 funziona-
lità complessiva prima del dispiegamento massiccio.
Entro la fine di settembre 2008 saranno individuati tutti gli utenti utiliz-
zatori 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 docu-
menti, 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. Con-
siderato 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'in-
terno dell'ente e fra enti, è necessario rimanere su formati sostanzial-
mente 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 discon-
tinuità 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 sperimenta-
tori è 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 docu-
menti. Di fatto non si sono registrati atteggiamenti né dubbiosi né astiosi
71
 da parte degli sperimentatori. tuno, che potrebbe contribuire ad uniformare i formati in uso in dire-
L'impressione finale manifestata da tutti è che, pur con alcune limitazioni zione di opzioni “aperte” e quindi non discriminanti, potrebbe essere
su funzionalità prevalentemente di tipo “avanzato”: realizzato dagli enti locali di livello superiore (a partire dalla Regione Emi-
• la compatibilità tra i due pacchetti office è molto alta; lia-Romagna). Adottando ad esempio standard di interscambio dati ba-
• la facilità d'uso è tale da non richiedere specifici corsi di formazione, sati su formati non penalizzanti per tutti gli utilizzatori di ambienti
ma semplicemente approfondimenti sulle differenze tra i due ambienti; diversi da quello MS Office, come ad esempio il formato XML.
• esistono funzioni aggiuntive rispetto al prodotto MS Office (ad esempio
il convertitore pdf integrato), che rendono molto pregevole l’utilizzo di Un elemento ulteriore che certamente potrebbe fare accelerare ulterior-
OpenOffice.org sia per efficienza che per costi. mente verso l'adozione dell'ambiente OpenOffice.org da parte degli enti
potrebbe essere l'attivazione di un punto di supporto (via FAQ) unificato
Nel futuro, allargando il numero degli utenti coinvolti, ci aspettiamo al- a livello Provinciale, ma ancor meglio se Regionale; il costo di gestione
cune criticità, come ad esempio: sarebbe più contenuto e il supporto sarebbe più completo e tempestivo.
• resistenza al cambiamento da parte di utenti, soprattutto da parte di
quelli meno esperti: sarà, quindi, necessario un accompagnamento mi- Infine, se molti enti Emiliano-Romagnoli decidessero di adottare l'am-
nimo con formazione mirata; biente OpenOffice.org, si potrebbero avere maggiori garanzie di evolu-
• difficoltà di adattamento all'uso di alcune funzioni “avanzate”, casomai zioni rapide del prodotto, soprattutto in alcune componenti funzionali
più efficienti (e più chiare) nell'ambiente MS Office. Per ovviare a questa ritenute “penalizzanti” nell'uso rispetto all'ambiente MS Office, se si ac-
problematica è necessario un lavoro di studio e formazione su come compagnassero le richieste rivolte al Consorzio OpenOffice.org, anche
eseguire le stesse funzioni sull'ambiente OpenOffice.org ed eventual- con sottoscrizioni di piccole ma significative somme di denaro.
mente modificare certi documenti in modo tale da renderli maggior-
mente 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 al-
l'ambiente MS Office;
• problemi con la condivisione di documenti complessi, soprattutto se
trattasi di condivisione tra enti (in particolare i fogli di calcolo). Per ov-
viare a questo inconveniente sarebbe necessario stabilire, almeno a li-
vello 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.

Il progetto di allargamento al nuovo ambiente potrà avere successo com-

pleto solo se si potrà contare sul totale appoggio al cambiamento da
parte della dirigenza dell'ente. Siamo altresì convinti che un reale dispie-
gamento 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 è rappre-

sentato 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 dap-
prima 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 si-
stema, si è deciso di approfondire ampliando l'attenzione, finora orien-
tata 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, in-
fatti, la concreta percezione di essere attore della gestione e del miglio-
ramento del servizio, ponendo interesse e accrescimento professionale
nelle attività svolte. Questo ha portato l’ente verso l’investimento in ri-
sorse 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 in-
tegrata con OpenLDAP. Si è quindi proseguito realizzando un nuovo ser-
vizio di posta elettronica basato su server qmail e relegando l’utilizzo di
Microsoft Exchange per la sola posta interna dell'ente. Nel 2006 si è pro-
ceduto ad unificare i servizi di posta elettronica adottando Open-
Xchange, che ha introdotto anche funzionalità di groupware avanzate.
Inoltre, è stato incrementato l’impiego di database che utilizzano tecno-
logia FLOSS (MySQL, PostgreSQL) per lo sviluppo di applicazioni costruite
internamente.
74
Dal 2005 le postazioni di lavoro consegnate ai dipendenti sono equipag-
giate 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 abbando-
nare le vecchie modalità di lavoro, consentendo di soddisfare la ‘curio-
sità’ 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 inte-
resse: 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 di-
verse postazioni Internet al pubblico completamente gestite tramite
software libero con un sistema di autenticazione sviluppato interna-
mente al nostro Ente. La diversa architettura e sicurezza di Linux ci ha
permesso di abbattere i costi hardware e di manutenzione dei calcola-
tori, a volte esposti alla imperizia degli utenti e al codice malevolo pre-
sente 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 docu-
menti prodotti dall'ente, garantendone così la consistenza, l’indipen-
denza 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, se-
guendo 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 La speranza è quella di poter portare il modello di sviluppo open source,
un grosso sforzo condiviso tra il Comune e i fornitori delle procedure. At- basato sulla creazione di una comunità di sviluppatori, nelle Pubbliche
tualmente siamo in contatto con il Comune di Forlì e di Ozzano dell'Emi- Amministrazioni, al fine di veder nascere e crescere un tessuto di espe-
lia per collaborare alla stesura e alla richiesta delle specifiche da adottare rienze e progetti comuni a giovamento della collettività.
con le nuove versioni dei programmi che vedono coinvolti fornitori co-
muni. 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 dipen-
denti 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 Am-
ministrazione, avendo sempre come obiettivo quello di mettere i nostri
colleghi nella situazione di poter svolgere al meglio i loro compiti. La stra-
tegia 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.

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 spe-
rimentare soluzioni a problemi reali, utilizzando strumenti didattici com-
pletamente 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 li-
bero. 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 de-
scrivere in modo molto dettagliato quelli che sono i livelli di uso e le ca-
ratteristiche 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 smen-
tita, 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 evo-
luzione ed espansione. Così sono quasi otto Comuni su 10 quelli che uti-
lizzano 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 con-
tenuti 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 competi-
zione nel settore ICT può trarre rilevanti benefici dalla diffusione ed uso
di FLOSS, standard e formati aperti che spostano l’oggetto del con-
fronto/scontro tra imprese dal prezzo del prodotto [licenza] alla qualità
del servizio [competenze]. È proprio in un ambiente come questo, rego-
lamentato ma privo di barriere artificiose e di vincoli, che i vantaggi del
software free, libre, open source potranno trovare piena e totale espres-
sione.
Sono così, quindi, i numerosi Comuni e Province che hanno scelto di spe-
rimentare 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 nes-
sun software [FLOSS o proprietario]. Tanto la tutela della pluralità infor-
matica 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 op-
portunità 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 del-
l’Emilia-Romagna49, il nuovo strumento di governance delle azioni in
campo e-government e società dell’informazione di tutti i Comuni, Pro-
vince 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 com-
petenza 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 commissio-
nato 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 circui-
tare informazioni e conoscenza in una logica di condivisione e coopera-
zione:
• 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, Bol-
zano, Friuli Venezia Giulia, Toscana, Umbria) al fine di condividere espe-
rienze 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’Emilia-
Romagna 2007-2009 [CAPITOLO 2] saranno analizzati diritti e doveri, op-
portunità e rischi connessi al licenziamento del codice nonché gli aspetti
di compatibilità tra licenze esistenti.
Attività di questo genere dovrebbero uscire dalla dimensione tempora-
nea di progetto per consolidarsi in qualcosa di maggiormente strutturato
e consolidato che possa rispondere in modo continuativo e competente
alle esigenze del territorio.
80
Bibliografia
I documenti che seguono sono stati utili alla redazione del presente Dossier, e
possono essere considerati come validi riferimenti per approfondire i temi trat-
tati. Molto materiale è inoltre reperibile on line sui siti ufficiali della Free Soft-
ware Fundation, della Open Source Initiative, di GNU Project, del programma
europeo IDABC e su Wikipedia. Un elenco più dettagliato è disponibile all’indi-
rizzo: 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 – Infor-
matica solidale 2”. Bollati Boringhieri.
Berry, D. & Moss, G. (2006), “Free And Open-Source Software: Opening And Demo-
cratising 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 Manage-
ment 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 si-
stemi operativi client e office automation nella Pubblica Amministrazione lo-
cale 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 Admi-
nistrations.
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.
81
 Ghosh, R. & Glott, R. (2005), “Free / Libre and Open Source Software Policy Sup-
port (FLOSSPOLS): Results and Policy Paper from Survey of Government Authori-
ties”, 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 Te-
chnologies (ICT) sector in the EU”. MERIT, University of Maastricht.
Glott R., Ghosh R. A., (2005). “Usage of and Attitudes towards Free / Libre and
Open Source Software in European Governments”. MERIT, University of Maa-
stricht.
Hahn, R. W. (2002), Government Policy toward Open Source Software, AEI-Broo-
kings Joint Center for Regulatory Studies.
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.
Kovács, G.; Drozdik, S.; Zuliani, P. & Succi, G. (2004), “Open Source Software for the
Public Administration”, Proceedings of the 6th Gomputer Science and Informa-
tion 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.
Lewis, J. (2004), “Global Policies on Open Source Software”, Technical report, Cen-
ter for Strategic and International Studies (CSIS).
Lewis, J. (2006), “Global Policies on Open Source Software”, Technical report, Cen-
ter for Strategic and Internationl Studies (CSIS).
Lewis, J. (2007), “Global Policies on Open Source Software”, Technical report, Cen-
ter for Strategic and Internationl Studies (CSIS).
Lewis, J. (2008), “Global Policies on Open Source Software”, Technical report, Cen-
ter for Strategic and Internationl Studies (CSIS).
82
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.
F. Rentocchini & D. Tartari, Open Source Software in the Public Sector: Results
from the Emilia-Romagna Open Source Survey (EROSS),in Belbaly N. (Eds.) Suc-
cessful Oss Project Design and Implementation: Requirements Tools Social De-
signs Reward Structures and Co-ordination Methods, Ashgate Publishing,
Limited, forthcoming (2009)
Shapiro C., Varian H. R., (2003). “Linux Adoption in the Public Sector: An Economic
Analysis”. University of California at Berkeley working paper.
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.
Tartari D., Rentocchini F. & Lotti S., (2007). Emilia-Romagna Open Source Survey
(EROSS): L'Intensitá 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.
83
 Romagna”. I numerosi rapporti frutto dell’attività sono disponibili all’URL:
Note http://www.regionedigitale.net/wcm/erdigitale/pagine/pagina_benchmarking.htm

10
La rappresentatività del campione, ovvero la capacità delle pubbliche ammini-
1
http://www.regionedigitale.net/wcm/erdigitale/pagine/pagina_piano_ strazioni effettivamente rispondenti al questionario di rappresentare il com-
telematico.htm Piano Telematico dell’Emilia-Romagna – Linee Guida 2007/2009, portamento generale della popolazione di tutte le PA emiliano-romagnole, è
pag.57. stata presa in considerazione tramite due procedure: (1) prima della fase di ri-
levazione, si è provveduto ad effettuare una procedura di campionamento
2 stratificato per classe dimensionale e provincia di appartenenza. In questo
Primo dossier del progetto EROSS (Emilia-Romagna Open Source Survey): “Il
modo ci si è preventivamente posti al riparo da forti squilibri nei tassi di rispo-
free, libre, open source software nella pubblica amministrazione” (2007). Copia
sta. Nella fattispecie, grazie alla tipologia di campionamento adottata, si sono
digitale all’URL:
potuti prefissare obiettivi per singola cella (ove la cella conteneva un numero
http://www.regionedigitale.net/wcm/osservando/pagine/eross.htm
di PA per provincia e classe dimensionale) composti da un numero minimo di
3 unità da intervistare; (2) successivamente alla fase di rilevazione, i dati raccolti
L’utilizzo di alcuni prodotti “proprietari” (come ad esempio il sistema operativo
sono stati sottoposti a test statistici volti a controllare l'esistenza di diffe-
di Microsoft: Windows Vista), impone (necessitando di elevate prestazioni)
renze significative tra rispondenti e non rispondenti per quanto riguarda la
nuove acquisizioni di apparati tecnici, o quantomeno il potenziamento di al-
classe dimensionale e la provincia di appartenenza. Tutti i test hanno dato
cune componenti dell’hardware già in uso (come ad esempio scheda grafica e
esito positivo, evidenziando quindi la capacità, del campione così costruito, di
momoria RAM). La necessità di hardware ad elevate prestazioni è perciò spesso
dare conto del comportamento della popolazione di tutte le PA emiliano-roma-
una scelta realizzata dal produttore del software, obbliga di fatto il consuma-
gnole nel loro complesso.
tore, nel momento in cui decide di acquistare un suo prodotto, a dotarsi di un
sistema adeguato alle esigenze del prodotto stesso. 11
Programma che si occupa di fornire, su richiesta del browser, una pagina web.
4 Fonte e maggiori informazioni all’URL: http://it.wikipedia.org/wiki/Web_server
Ghosh R. A., (2006). "Economic impact of FLOSS on innovation and competitive-
ness of the EU ICT sector". MERIT, University of Maastricht. 12
Software che fornisce l'infrastruttura e le funzionalità di supporto, sviluppo ed
5 esecuzione di applicazioni e componenti server in un contesto distribuito. Si
Secondo la Business software alliance (Bsa), l’associazione di produttori di soft-
tratta di un complesso di servizi orientati alla realizzazione di applicazioni per
ware, nella Pubblica Amministrazione italiana il fenomeno dell’uso non cor-
il web, multilivello ed enterprise, con alto grado di complessità. Fonte e mag-
retto di licenze interessa tre computer su dieci. Si veda l’articolo apparso l’11
giori dettagli all’URL http://it.wikipedia.org/wiki/Application_server
giugno 2007 su Il Sole 24 Ore “Licenze d’uso gestite con disinvoltura – Nella Pa
irregolari tre computer su 10”, di Rita Fatiguso. 13
Programma che si occupa dello smistamento da un computer a un altro della
6 posta elettronica. Normalmente un mail server risiede su un sistema dedicato
La libertà, per chiunque ne abbia interesse, di modificare il codice per persona-
ma può essere eseguito su computer ove risiedano altri server o che vengano
lizzare il software alle esigenze delle singole categorie di disabili, ed eventual-
utilizzati anche per altri scopi. Fonte e maggiori informazioni all’URL
mente alle specifiche necessità del singolo individuo, permette di fornire un
http://it.wikipedia.org/wiki/Mail_server
più esteso servizio (e quindi favorisce l’inclusione sociale e digitale) sia dal
punto di vista qualitativo che quantitativo. 14
Programma usato per mettere a disposizione degli utilizzatori di una rete di
7 computer dello spazio su un disco (disco singolo o composto da più dischi) nel
“Le tecnologie dell’informazione e della comunicazione nelle amministrazioni
quale sia possibile salvare, leggere, modificare, creare file e cartelle condivise.
locali 2007”, i principali risultati dell’indagine e le tabelle con i dati quantitativi
Fonte e maggiori informazioni all’URL http://it.wikipedia.org/wiki/File_server
sono disponibili all’URL: http://www.istat.it/salastampa/comunicati/non_ca-
lendario/20080307_00/ 15
Sistema software che permette di controllare un computer da un terminale
8 che si trova altrove. La tecnologia di desktop remoto è molto utilizzata da pro-
Lo studio è stato finanziato dalla Commissione Europea e condotto dal Maa-
duttori di hardware e software per fornire assistenza in modalità remota ai
stricht Economic and social Research and training centre on Innovation and Te-
computer client in caso di problemi tecnici. Fonte (traduzione libera) e mag-
chnology. Glott R., Ghosh R. A., (2005). “Usage of and Attitudes towards Free /
giori informazioni all’URL http://en.wikipedia.org/wiki/Remote_desktop_soft-
Libre and Open Source Software in European Governments”. MERIT, University
ware
of Maastricht.
16
9 Sistema software progettato per consentire la creazione e manipolazione effi-
Regione Emilia-Romagna. “Benchmarking della società dell'informazione in Emilia-
ciente di database (ovvero di collezioni di dati strutturati), solitamente da

84 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'uti-
lizzo ad una o più stampanti, in modo da permetterne l'impiego da parte di
client diversi, sempre che questi abbiano le autorizzazioni necessarie per uti-
lizzarle. 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 es-
sere 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 Lo-
cali”. Valori e un report di sintesi descrittivo dei dati raccolti sono disponibili
all’URL: http://www.istat.it/salastampa/comunicati/non_calenda-
rio/20080307_00/
20
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 po-
tuto far pensare a fenomeni di autoselezione, con conseguenti problemi di so-
vrastima 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.
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 infor-
mazione 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.
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/de-
sktop 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 ti-
pologie di software censite (eccezion fatta per i software di tipo SIT/GIS).
86
25
191 Comuni rappresentano il 71% del campione, un dato leggermente diverso
dal 77% (208 Comuni) ottenuto come somma di utilizzatori consapevoli e in-
consapevoli di FLOSS. I 17 Comuni di differenza si spiegano considerando che
la rilevazione attuale non costituisce una mappatura completa di tutti gli am-
biti 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 og-
getto della presente rilevazione. Ecco spiegata la differenza tra Comuni utiliz-
zatori (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: proto-
collo 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 amministra-
zione”, consultabile al sito web http://www.regionedigitale.net/wcm/osser-
vando/pagine/eross.htm
31
Per endogeneità qui si intende il concetto formale proprio della teoria econo-
metrica che prevede la presenza di un legame (correlazione) tra le variabili uti-
lizzate nel modello di analisi (variabili indipendenti) e la parte non spiegata dal
modello (termine di errore).
32
In aggiunta ai modelli I e II, si è provveduto a testare un terzo modello che te-
nesse 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 chia-
rezza espositiva, non è stato incluso nel presente Dossier.
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 comunica-
zione conformi a standard liberi e/o aperti”, e tra i principi da tutelare quello
del “pluralismo informatico”.
87
 34
In particolare hanno risposto in questo modo i seguenti progetti: Rete LEPIDA,
LEPIDA MAN: LEPIDA Metropolitan Area Network, Prosecuzione CENTER, Rile-
vazione sulla società dell’informazione regionale, EROSS, Laboratorio ICT per
45
la PA, Riduzione Digital Divide, OPTA, e-citizen, Extranet della Community Net-
work dell'Emilia-Romagna, Servizi innovativi di telefonia VOIP, Servizi di Video-
comunicazione, Servizi di Data Center, LEPIDA SCUOLA, Video e multimedia per
la didattica, e-learning per il recupero del debito formativo, LEPIDA SANITA', Co-
municAzione, Co-desing dei servizi on line.
44
Maggiori dettagli su MPI all’indirizzo Web: http://en.wikipedia.org/wiki/Mes-
sage_Passing_Interface.
SWAN è un “wave action model” di terza generazione ed ha un’implementa-
zione fisica ed algoritmi di calcolo numerico sviluppati e studiati apposita-
mente 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.

35
Il Codice dell'Amministrazione Digitale è stato emanato con Decreto legisla-
tivo 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 disponi-
bilità, la gestione, l’accesso, la trasmissione, la conservazione e la fruibilità del-
l’informazione in modalità digitale utilizzando con le modalità più appropriate
le tecnologie dell’informazione e della comunicazione all'interno della pub-
blica amministrazione, nei rapporti tra amministrazione e privati; in alcuni li-
mitati casi, disciplina anche l'uso del documento informatico nei documenti
tra privati.
36
Maggiori dettagli all’URL: www.qsos.org
37
Si veda il Capitolo 2 del Dossier EROSS 2007 disponibile all’URL: http://www.re-
gionedigitale.net/wcm/osservando/pagine/eross.htm
38
http://cde.osspa.cnipa.it/projects/morgana
39
http://sourceforge.net/projects/morgana/
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 soft-
ware on innovation and the competitiveness of the Information and Commu-
nication 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/pa-
gine/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.regionedigi-
tale.net/wcm/erdigitale/pagine/pagina_piano_telematico.htm

40
MARIS http://sourceforge.net/project/showfiles.php?group_id=37982&pac-
kage_id=195374, MARIS XDS Registry http://cde.osspa.cnipa.it/projects/xds-re-
gistry/ 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 Ser-
ver: http://mapserver.gis.umn.edu/, Routing: http://pgrouting.postlbs.org/, Sta-
tistica: R http://www.r-project.org/, SPATSTAT:
http://www.spatstat.org/spatstat/

43
Tramite rpm vengono generati i pacchetti necessari alle attività, le worksta-
tion 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.

88 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