piano telematico emilia-romagna dell il free,...

PIANO TELEMATICODELL

,EMILIA-ROMAGNA

IL FREE, LIBRE, OPENSOURCE SOFTWARE INREGIONE EMILIA-ROMAGNA

EROSS - Emilia-Romagna Open Source Survey

IL FREE, LIBRE, OPEN SOURCE SOFTWARE

IN REGIONE EMILIA-ROMAGNA

3 erossEMILIA-ROMAGNAOPEN SOURCE SURVEY

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 chesono da ritenere non modificabili in quanto espressione dell’opinionepersonale degli autori. Per leggere una copia della licenza visita il sitoWeb http://creativecommons.org/licenses/by-nc-sa/2.5/it/ o spedisciuna lettera a Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

erossPIANO TELEMATICODELL

,EMILIA-ROMAGNA

PIANO TELEMATICO DELL,EMILIA-ROMAGNA

IL FREE, LIBRE, OPEN SOURCE SOFTWAREIN REGIONE EMILIA-ROMAGNA

Assessorato Attività produttive.

Sviluppo economico. Piano Telematico

Direzione generale centrale Organizzazione,

Personale, Sistemi Informativi e Telematica

[email protected]

Centro Regionale di Competenza per l'e-government

e la società dell'informazione dell'Emilia-Romagna

1

Indice

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

Capitolo 0: nozioni elementari ...................................................................................4

Le ragioni per l’adozione di FLOSS nella Pubblica Amministrazione............................6

Capitolo 1: il FLOSS nelle PA emiliano-romagnole................................................10

Metodologia di indagine e struttura del campione ..........................................................10

Analisi descrittiva............................................................................................................................14

Analisi avanzata ...............................................................................................................................41

Capitolo 2: Il FLOSS nei progetti del Piano telematico

dell’Emilia-Romagna (PiTER) ......................................................................................42

Metodologia di indagine ..............................................................................................................42

Analisi descrittiva............................................................................................................................42

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

Capitolo 4: considerazioni conclusive e raccomandazioni.................................78

Bibliografia ..................................................................................................................81

Note ...............................................................................................................................84

0

1

2

3

4

32

source. Il CAPITOLO 2 descrive, quindi, le principali evidenze emerse of-frendo spunti di riflessione.

Nel CAPITOLO 3, in analogia con quanto fatto nel primo dossier EROSS,sono presentate esperienze concrete e casi d’uso di free, libre, opensource software realizzate da organizzazioni di medie e grandi dimen-sioni (Regione Emilia-Romagna, AUSL Reggio Emilia, Agenzia Regionaledi Protezione Civile, ARPA Emilia-Romagna, Provincia di Forlì-Cesena, Co-mune di Imola). La presentazione di tali situazioni, vantaggi e problema-tiche reali completa in modo opportuno l’informazione quantitativa estatistica esposta nei capitoli precedenti.

Le considerazioni generali e alcune raccomandazioni sono infine ripor-tate nell’ultimo capitolo, CAPITOLO 4.

Premessa

Il presente dossier rappresenta uno dei risultati del progetto EROSS (Emi-lia-Romagna Open Source Survey) e fa seguito al precedente, pubblicatonell’ottobre del 2007, nell’ottica di rispondere alle indicazioni contenutenel Piano Telematico dell’Emilia-Romagna 2007-2009, che identifica, tragli altri, l’obiettivo di “realizzare studi per valutare le opportunità con-nesse ai diversi modelli di licenza [open souce]”1. La Regione Emilia-Ro-magna si dichiara decisa ad “agire con il ruolo di facilitatore di processidi valutazione ed adozione del software open source nelle Pubbliche Am-ministrazioni locali” e con il progetto EROSS mira a realizzare nel triennio2007-2009:

• azioni informative, finalizzate a rendere maggiormente consapevoli gliEELL 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, opensource software nei Comuni e nelle Province della regione;

• case study e best practice, che possano essere condivisi e tornare utiliagli EELL che si interessano di free, libre, open source software per laprima volta;

• collaborazioni con progetti e organizzazioni italiane ed europee.

Se il primo dossier aveva l’obiettivo di fornire le informazioni di base sultema del software libero e a codice sorgente aperto, predisponendo unasorta di cronistoria dalle origini ad oggi ed offrendo qualche dato “spe-rimentale” sulla sua diffusione e uso, questa seconda pubblicazione sisofferma con maggiore dettaglio e perizia sugli aspetti quantitativi.

Il dossier si articola in quattro capitoli. Nel primo, il CAPITOLO 0, vengonoriprese alcune elementari nozioni indispensabili alla comprensione deicontenuti e sono altresì indicate le più diffuse ragioni portate a sostegnodell’impiego di free, libre, open source software nella Pubblica Ammini-strazione. Nel CAPITOLO 1 si entra nel vivo dei risultati dell’indagineEROSS realizzata nel 2008 grazie alla collaborazione dei Comuni dell’Emi-lia-Romagna. Sono presentati e descritti metodologia, risultati e analisioperando confronti con gli indicatori ottenuti da EROSS nel 2006 e daISTAT nel 2007.

In risposta ad una esplicita richiesta dell’Assemblea Legislativa Regionalesi è promosso un approfondimento che ha avuto per oggetto i progettidel Piano telematico dell’Emilia-Romagna 2007-2009 e che ha mirato a mi-surare l’acquisizione e sviluppo di componenti software free, libre, open

54

Diritto d’autore (copyright)

Il diritto d’autore è un istituto che attribuisce all’autore di un'operadell'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 glielementi per individuare le opere protette dal diritto d'autore. Nellatutela rientrano tutte le opere dell'ingegno aventi carattere creativo,qualunque ne sia il modo o la forma di espressione. La legge definiscele categorie di opere sottoposte al diritto di autore: letteratura, mu-sica, arti figurative, architettura, teatro, cinematografia. Inoltre, sonoprotette anche le cosiddette "elaborazioni di carattere creativo",come ad esempio le traduzioni in un'altra lingua, le trasposizioni dauna forma letteraria o artistica in un'altra, gli adattamenti, le ridu-zioni, ecc. A seguito del recepimento delle direttive comunitarie96/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 è pertantoalcun 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 ilsatellite, il cavo e Internet), compresa la sua messa a disposizione delpubblico in maniera che ciascuno possa avervi accesso nel luogo e nelmomento scelti individualmente (le cosiddette fruizioni on demand),distribuirla, tradurla e/o elaborarla, venderla, noleggiarla e darla inprestito. Tutti i diritti elencati sono indipendenti l'uno dall'altro, il chesignifica 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 ilquale ciò che è stato creato dall'autore deve essere riferito all'autoremedesimo, evitando che altre persone possano gloriarsi di quanto dalui 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

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) nellePubbliche Amministrazioni già individuate e definite nel Dossier del2007 al quale si rimanda per ottenere informazioni più dettagliatesulle origini e le caratteristiche del software libero e a sorgenteaperta.

Software

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

Codice sorgente

Il codice sorgente (spesso abbreviato con sorgente) è un insieme diistruzioni, con caratteristiche variabili a seconda del linguaggio diprogrammazione utilizzato, la cui struttura risulta comprensibile edinterpretabile 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 codiceoggetto 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 ditraduzione (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..

0

risparmio economico: si realizza principalmente attraverso l’annulla-mento dei costi di acquisizione del software (principalmente dovutialla 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 odi 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 ofatti sviluppare da una specifica PA rispondono a esigenze e requisiticomuni 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/sviluppatoriche condividono, minimizzandoli, gli eventuali oneri di manutenzionee implementazione del prodotto;

diretta gestione dei livelli di sicurezza: la disponibilità del codice sor-gente rende valutabili (ovviamente a personale esperto preposto atale compito) le eventuali vulnerabilità del codice, eliminando perico-losi margini di incertezza. Il software viene inoltre spesso utilizzatonella PA per gestire dati sensibili o informazioni riservate, che non de-vono essere accessibili a terzi, e che devono poter essere protette nelmigliore 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, ingrado di operare modifiche e implementazioni al software in uso(senza il coinvolgimento di fornitori esterni). Così facendo, verrebberovalorizzate le capacità degli addetti interni: questi potrebbero pro-gredire nell’acquisizione di conoscenza e professionalità, grazie allafacoltà 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 spessopersistono 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 perrealizzare una efficace politica di e-government e fornire servizi pub-blici a effettivo valore aggiunto;

7

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

Licenza (informatica)

La licenza in ambito informatico è il contratto che solitamente accom-pagna un prodotto software. Tale contratto specifica le modalità concui l’utente può usare il prodotto, garantendo diritti ed imponendoobblighi. La licenza è imposta da chi detiene il diritto di autore (copy-right) sul prodotto software, il solo che può far rispettare in ogni sedela licenza stessa.

Software proprietario

Con il termine software proprietario, si indica quel software che harestrizioni sul suo utilizzo, sulla sua modifica, riproduzione o redistri-buzione, solitamente imposti da un proprietario. Queste restrizionivengono ottenute tramite mezzi tecnici o giuridici. Nel primo caso siagisce 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 cheregolano l’uso e la disponibilità del software (prevedendo divieti dimodifica 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 opensource, permette, anziché impedire, agli utenti di studiarne le caratte-ristiche, modificare forma e contenuto e ridistribuirne una o più copieliberamente. 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 ilsoftware proprietario.Maggiori dettagli sulle differenze tra software libero e software opensource 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 sonoespressi a favore del FLOSS è possibile individuare tra le conseguenzepositive “direttamente” connesse all’utilizzo di FLOSS da parte dellePubbliche Amministrazioni:

6

98

diffusione di una cultura della conoscenza libera e condivisa: l’usodi 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 (liberenel caso del FLOSS) possono renderlo proficuamente utilizzabile dautenti diversamente6 abili, o soggetti che usano una lingua differenteda quella impostata.

integrità e disponibilità dei dati nel tempo: anche in questo caso,l’utilizzo di FLOSS garantisce alla PA di tutelarsi da eventuali rischiconnessi 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à dimigrare in autonomia (e quindi senza la necessità di richiedere sup-porto al fornitore specifico) ad altri prodotti software. L’utilizzo diquesto genere di formati tutela anche l’utente della PA. In questomodo, infatti, è libero di scegliere quale prodotto utilizzare per inte-ragire con l’Amministrazione Pubblica, in una logica di pluralismo in-formatico;

elevata disponibilità di prodotti aggiornati allo stato dell’arte: gliaggiornamenti sono come lo stesso software FLOSS, ossia libera-mente acquisibili e ridistribuibili.Si può così fare in modo che tutti glioperatori 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 deidocumenti);

Diversamente, possono essere definiti esiti “indiretti” della diffusaadozione di FLOSS nella Pubblica Amministrazione:

incremento nel livello di indipendenza e consistenza del settore ICTnazionale (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 ilconseguente sostegno allo sviluppo di realtà produttive locali. Così sipotrebbe anche rompere il monopolio sulla conoscenza pregressa checaratterizza il mercato del software attuale. Va tenuto conto che laproduzione e distribuzione di software che fanno uso di licenze FLOSSrappresenta oggi, in termini economici, una percentuale rilevante delsettore ICT, e assume sempre maggiore importanza mano a mano cheil 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 comportamentianaloghi nella società civile e nel mondo delle imprese che oggi, inItalia5, fanno largo uso di software non regolarmente acquisiti;

tanti) e della localizzazione (provincia di appartenenza) delle unità dellapopolazione di riferimento. I Comuni per i quali è stata raccolta una ri-sposta valida sono stati 269, pari al 78,89 % del totale dei Comuni dellaregione. Gli obiettivi di campionamento sono stati ampiamente raggiuntiper ogni fascia dimensionale e per ogni territorio provinciale, ottenendoquindi un campione statisticamente rappresentativo dell’universo. In Fi-gura 1 e Figura 2 sono specificati nel dettaglio i livelli di risposta ottenuticon attenzione sia per la classe di popolazione che per la provincia di ap-partenenza.

Da un punto di vista dimensionale (Figura 1), la percentuale di rispon-denti più elevata è stata registrata nei Comuni con più di 15.000 abitanti(89,36%), mentre per le altre fasce di popolazioni i valori sono molto similie di poco inferiori alla media regionale (78,89%). E’ evidente l’elevato nu-mero di Comuni di piccole o piccolissime dimensioni che hanno contri-buito all’indagine, in questi casi, più che negli altri, sono risultatiindispensabili l’interazione telefonica ed il contributo di più referenti.Spesso infatti, specie nelle piccole realtà, la gestione delle attrezzatureinformatiche è in parte o totalmente esternalizzata a società private, opiù spesso a strutture pubbliche (Comunità Montane, Associazioni Inter-comunali o Unioni di Comuni) a cui è demandata la gestione associatadei servizi informatici.

11

Capitolo 1: il FLOSS nelle PA

emiliano-romagnole

Nella convinzione che sia impossibile definire una strategia di azionesenza conoscere l’ambito nel quale si intende intervenire, la Regione Emi-lia-Romagna, per il tramite del suo Centro Regionale di Competenza perl’e-government e la società dell’informazione, ha sperimentato per laprima volta nel 2006 una metodologia di indagine finalizzata a misurarel’intensità con cui i Comuni dell’Emilia-Romagna ricorrono a softwarefree, libre e open source. I risultati così raccolti permisero allora di de-scrivere con indicatori inediti il contesto regionale, peccando però di unanon rigorosa rappresentatività statistica dell’universo di riferimento. Adistanza di due anni da quella prima esperienza, basata principalmentesulla 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.

Il questionario EROSS 2008 è stato composto tenendo conto dei risultatiottenuti nell’edizione precedente, nonché delle esperienze in tal sensogià realizzate a livello nazionale e internazionale (in particolare l’inda-gine ISTAT “Le ICT nelle Amministrazioni Locali”7 e quanto realizzato dalprogetto della Commissione europea FLOSSPOLS8). Le domande sonostate predisposte affinché fosse possibile costruire un indicatore quan-titativo che descrivesse la reale “intensità di utilizzo” di FLOSS: non solo,quindi, l’informazione legata a un generico uso/non uso. Con l’obiettivodi rendere il questionario snello e sintetico, si è inoltre operato affinchéfosse possibile riutilizzare, in fase di analisi, una gamma di informazionistatistiche già in possesso della Regione e frutto, in buona parte, dell’at-tività di indagine e benchmarking della società dell’informazione emi-liano-romagnola9.

Metodologia di indagine e struttura del campione

I dati della rilevazione EROSS 2008 sono stati raccolti nel periodo dicem-bre 2007 – marzo 2008, attraverso un questionario inviato ai 341 Comuni(unità di analisi) della regione Emilia Romagna. In una prima fase l’invioè stato realizzato via posta elettronica, offrendo la possibilità di proce-dere alla compilazione nella classica forma cartacea oppure diretta-mente on line. In un secondo momento si è proceduto ad effettuare deirichiami telefonici mirati, per sollecitare la compilazione da parte dei Co-muni mancanti. Scopo del contatto telefonico è stato quello di raggiun-gere il numero minimo di risposte previsto dal piano di campionamentostratificato, elaborato tenendo conto della dimensione (numero di abi-

10

1

meno di 3.000 ab. tra 3.000 e 5.000 ab. tra 5.000 e 15.000 ab. oltre 15.000 ab

0

20

40

60

80

100

120

140

Non risposteRisposte valide

71 55 101

42

Co

mu

ni

Fonte: EROSS 2008

FIGURA 1 - RISPONDENTI EROSS 2008: CLASSE DI POPOLAZIONE

1312

Per quel che riguarda la territorialità delle risposte collezionate (Figura2 - in basso), le province meno rappresentate sono Piacenza e Parma, chesuperano di poco il 70%, mentre la provincia che ha segnato il più altotasso di risposte è stata quella di Ravenna (94%). Sono da registrare risul-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-stribuzione territoriale dei rispondenti (Figura 2 - in alto), è evidente comei Comuni della provincia di Bologna siano i più numerosi (50, pari al 19%del campione), seguiti dai Comuni della provincia di Modena (39, pari al14% del campione). I tassi di risposta ottenuti garantiscono la piena rappresentatività deidati sia per territorio provinciale che per fascia dimensionale del Co-mune. Gli indicatori che si presentano, frutto delle analisi, sono quindiespressione della realtà del territorio regionale e non di una minoranza10.

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

Per quel che riguarda i software client/desktop, le informazioni raccoltehanno riguardato: • sistema operativo per il desktop; • software di posta elettronica; • browser Internet; • suite office automation; • sistemi SIT/GIS.

Per i software server, l’indagine si è concentrata invece su:• Web server11;• application server12;• mail server13;• file server14;• server di desktop remoto15;• data base management system (DBMS)16;• printer server17.

BO

FC

FE

MO

PC

PR

RA

RE

RN

0 10 20 30 40 50 60

17

34

17

34

34

39

22

22

50

Fonte: EROSS 2008

FIGURA 2 - RISPONDENTI EROSS 2008: TERRITORIO PROVINCIALE DI APPARTENENZA

Non risposteRisposte valide

BO

FC

FE

MO

PC

PR

RA

RE

RN

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

83%

73%

85%

83%

71%

72%

94%

76%

85%

Amministrazioni fanno uso di FLOSS senza saperlo, in modo per così dire“inconsapevole”. Tale risultato, peraltro già emerso nella rilevazioneEROSS 2006 e nell’indagine europea FLOSSPOLS realizzata da UNU-MERIT(in quel caso la percentuale era del 30% e faceva riferimento all’anno2005)21, sottolinea come persista un problema di ridotta conoscenza deltema da parte di un numero considerevole di Comuni. Da sottolineareinoltre come tale mancanza di conoscenza non interessi solo gli EELL dipiccole dimensioni, ma in egual misura enti di piccole dimensioni e entimedi e grandi.

Complessivamente dunque, la percentuale di Comuni che utilizza consa-pevolmente o inconsapevolmente FLOSS in Emilia-Romagna sale al 77%.Questo dato sottolinea da un lato l’elevato interesse che il settore pub-blico mostra nei confronti del FLOSS, e dall’altro giustifica e motiva l’esi-stenza stessa del progetto EROSS.

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

1514

La scelta di queste specifiche classi di programmi informatici è frutto deirisultati ottenuti nel 2006 e della logica di voler misurare e mettere a con-fronto l’utilizzo di software che, negli EELL, fanno parte della “dotazionestandard” e quindi per i quali è plausibile attendersi un elevato livello diconfrontabilità.

I dati ottenuti hanno permesso di calcolare un indice di intensità di uti-lizzo FLOSS (iuFLOSS), pari al rapporto tra il numero di installazioni ditipo FLOSS ed il totale di tutte le installazioni. Tale indice è stato dap-prima calcolato per ogni tipologia di software, per poi comporre un in-dice complessivo per i software client/desktop e per i software server(entrambi ottenuti come media semplice dei valori di iuFLOSS per i singoliambiti applicativi facenti parte delle due categorie18). Un indice di inten-sità di utilizzo FLOSS generale è stato infine calcolato come media sem-plice dell’iuFLOSS client/desktop e dell’iuFLOSS server. Tale valore disintesi offre quindi, assegnando eguale peso alle due tipologie di soft-ware, una indicazione sull’effettivo utilizzo di FLOSS.

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 gliEnti Locali che effettivamente hanno scelto di utilizzare FLOSS in mododiffuso. In questa logica i Comuni sono stati distinti in tre categorie diutilizzatori, permettendo così di delineare l’identikit dei Comuni chefanno “intenso”, “moderato” o “nessuno” utilizzo di FLOSS.

Analisi descrittiva

Il primo dato sul quale soffermarsi è quello generale relativo a quanti Co-muni abbiano esplicitamente dichiarato di utilizzare FLOSS (Figura 3).Sulla base delle risposte raccolte da EROSS 2008, due Comuni emiliano-romagnoli su tre (il 63%) dichiarano di utilizzare FLOSS. Il risultato, diret-tamente confrontabile con quello ISTAT 200719, è di molto sopra la medianazionale, 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-Romagnaappartiene. La media europea, il dato disponibile fa riferimento all’anno200520, è invece del 50,1%. Sostanzialmente questa prima informazioneevidenzia come il territorio regionale abbia maturato una tendenza eduna propensione all’uso di soluzioni software FLOSS più di quanto ab-biano fatto le corrispondenti Amministrazioni italiane ed europee.A conferma del fatto che l’adozione e l’uso di FLOSS non sono limitati apochi, attraverso la metodologia EROSS 2008 è stato possibile identificareanche un 14% di Comuni che, pur avendo dichiarato di non utilizzareFLOSS, presentano un iuFLOSS maggiore di zero. Ciò significa che queste

22%non

utilizzatori

di floss

14%utilizzatori

inconsapevoli

di floss

63%utilizzatori

consapevoli

di floss

77%utilizzatori

di floss

1%non sa/non

risponde

Fonte: EROSS 2008

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

17

La Tabella 3 riporta quali e quanti sono i Comuni dell’Emilia-Romagna chehanno dichiarato di aver adottato un atto di indirizzo strategico o ammi-nistrativo avente ad oggetto l’adozione di software FLOSS. Come si vedesono prevalentemente interessati i Comuni di grandi dimensioni. Comeprevedibile, sulla base dei dati EROSS 2008, è possibile stabilire che i Co-muni che fanno uso intensivo di FLOSS sono quelli che con più ricorrenzasi sono dotati di forme di indirizzo aventi per oggetto il FLOSS. Esiste peròuna quota significativa di Comuni (l’8% in EROSS 2008), che pur presen-tando iuFLOSS pari a zero, si sono dotati di un atto di indirizzo in materiaFLOSS. Questa “anomalia” potrebbe riguardare da un lato enti che hannointenzione di sperimentare in tempi brevi il software libero o a codicesorgente 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).

16

Classi dimensionali e localizzazione territoriale

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

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

AVENTE AD OGGETTO L'ADOZIONE DI FLOSS

( )Fascia

dimensionale

Più di 15.000 ab.

5.000 - 15.000 ab.

3.000 - 5.000 ab.

meno di 3.000 ab.

Comuni

Argenta, Bologna, Correggio, Faenza,

Ferrara, Forlì, Imola, Lugo, Modena,

Pianoro, Ravenna, Riccione, Rimini,

San Lazzaro Di Savena, Zola Predosa

Albinea, Argelato, Castello D'argile,

Castelnovo Di Sotto, Castiglione

Dei Pepoli, Colorno, Fusignano, Fornovo Val

Di Taro, Galliera, Luzzara, Mesola,

Misano Adriatico, Morciano Di Romagna, Oz-

zano Dell'Emilia, Pieve Di Cento,

Poviglio, San Giorgio In Piano, San Pietro

In Casale

Bentivoglio, Casalgrande, Castel Guelfo Di

Bologna, Coli, Jolanda Di Savoia, Soragna

Bagnara Di Romagna, Borghi, Coli,

Sant'agata Sul Santerno

% su totale comuni

(valore assoluto)

32% (15/47)

14% (18/129)

8% (6/72)

4% (4/93)

Fonte: Understand 2005 e EROSS 2008

iuFLOSS Client/Desktop (retta tratteggiata = media regionale)

iuFLOSS Server (retta tratteggiata = media regionale)

iuFLOSS generale (retta tratteggiata = media regionale)

meno di 3.000 ab. tra 3.000 e 5.000 ab. tra 5.000 e 15.000 ab. oltre 15.000 ab.

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

50%

Fonte: EROSS 2008

FIGURA 4 – INTENSITÀ MEDIA DI UTILIZZO GENERALE, CLIENT/DESKTOP E SERVER

(FASCE DIMENSIONALI E TERRITORI PROVINCIALI)

1918

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

Sono i Comuni compresi nelle fasce con popolazione fra 3.000 e 15.000abitanti che paiono fare un uso del FLOSS meno intenso; da notare inoltrecome nel caso dei valori specifici per Client/Desktop e per Server si pos-sono notare alcune piccole differenze. Questa dinamica sicuramente su-bisce gli effetti diretti della disponibilità di risorse umane edeconomiche, della complessità della gestione dell’installato che aumentacon l’aumentare del numero dei dipendenti dell’ente e con fenomeni diesternalizzazione dell’attività di gestione e manutenzione che nel caso diComuni medi significa spesso demandare ai fornitori le scelte su qualisoftware adottare. Ancor più accentuate sono le differenze che si eviden-ziano, Figura 4 secondo grafico, tra i territori provinciali. E’ sostanzial-mente chiaro che il FLOSS non rappresenta qualcosa di oscuro e nuovoper i Comuni modenesi, ferraresi e del riminese, che ne fanno un uso in-tenso e diffuso (seppure con differenze anche sostanziali negli aspettiapplicativi – client/desktop o server).Approfondendo sui singoli software, è possibile descrivere in modo ancorpiù dettagliato le preferenze di utilizzo ed adozione delle singole classidimensionali di Comuni e dei singoli territori provinciali di competenza.

BO FC FE MO PC PR RA RE RN Regione

0%

5%

10%

15%

20%

25%

30%

iuFLOSS Posta elettronica

iuFLOSS Sistema Operativo

iuFLOSS Suite Office

iuFLOSS Browser Internet

Fonte: EROSS 2008

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

E TERRITORI PROVINCIALI)

0%

5%

10%

15%

20%

25%

30%

iuFLOSS Posta elettronica

iuFLOSS Sistema Operativo

iuFLOSS Suite Office

iuFLOSS Browser Internet

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 Client/Desktop (retta tratteggiata = media regionale)

iuFLOSS Server (retta tratteggiata = media regionale)

iuFLOSS generale (retta tratteggiata = media regionale)

FC PC RE PR BO RA RN FE MO

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

50%

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

21

In particolare spiccano come valori sopra la media regionale quelli deiComuni 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 prossimialla media regionale.

Analoghe considerazioni possono essere fatte per quanto rappresentatoin Figura 6 e Figura 7, dalle quali emergono con una certa evidenza risul-tati sopra la media regionale che interessano principalmente,e in modogeneralizzato, i grandi Comuni (sopra quota 15.000 ab.), e nello specificodi alcune tipologie di software Server, i piccolissimi Comuni (inferiori a3.000 ab.). Le differenze tra i territori provinciali vedono i Comuni del ri-minese primeggiare in tutti i diversi ambiti applicativi; risultati sopra lamedia per singoli software sono evidenti anche per ravennate, modenesee ferrarese.

20

oltre 15.000 ab. tra 5.000 e 15.000 ab. Regione

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

tra 3.000 e 5.000 ab. meno di 3.000 ab.

Fonte: EROSS 2008

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

Fonte: EROSS 2008

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

iuFLOSS Data Base

Management Systems (DBMS)

iuFLOSS Server di Desktop Remoto

iuFLOSS Printer Server

iuFLOSS File Server

iuFLOSS Mail Server

iuFLOSS Application Ser

iuFLOSS Web Server

Come risulta evidente, la diffusione di FLOSS nel settore dei softwareclient/desktop è piuttosto limitata. Ciò risulta particolarmente veronell’ambito dei sistemi operativi, ove più del 75% dei Comuni (tre su quat-tro) presentano un iuFLOSS pari a zero. I Comuni che hanno installatoGnu/Linux (o altro sistema operativo FLOSS) su più del 30% dei propriclient/desktop sono appena due. Complessivamente, nei Comuni inda-gati, le installazioni di sistemi operativi FLOSS ammontano a 315 su oltre26.000 censite (pari all’1,2%). Questo risultato sottolinea, specie se con-frontato con quelli che seguiranno, il ridotto interesse che le PubblicheAmministrazioni rivolgono, allo stato attuale, alle alternative FLOSS diMicrosoft Windows, che nelle sue varie versioni resta la piattaforma di la-voro della stragrande maggioranza degli operatori dei Comuni emiliano-romagnoli.Per quanto riguarda la gestione della posta elettronica, si nota comeanche 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-zano client mail free o open source in maniera esclusiva (iuFLOSS = 100%).Numerosi sono anche i Comuni che hanno scelto soluzioni per la gestionedelle mail che prescindono da installazioni sui client/desktop, e che sfrut-tano l’uso del protocollo http e quindi di un comune browser Internet(Webmail).Sul fronte della navigazione del Web, si rileva il più alto livello di prefe-renza riservato alle alternative FLOSS di prodotti consolidati e larga-mente diffusi come il leader di mercato MS Internet Explorer. Il 23,5%delle installazioni standard che interessano le postazioni degli operatoridei Comuni della regione sono dotate di prodotti free o open source(come Firefox, Mozilla, ecc…) come browser Internet. Così, circa il 13% diComuni presenta un iuFLOSS maggiore o uguale al 50%, e in quattro entisono utilizzati esclusivamente browser FLOSS.Numeri molto simili e altrettanto significativi sono riscontrabili nell’am-bito dell’office automation (produttività personale), in cui il 45% circa deiComuni ha una o più installazioni FLOSS (nella fattispecieopenoffice.org); di questi una quota significativa il 7% presenta un iu-FLOSS maggiore o uguale al 50%, e in quattro Comuni si fa uso esclusivodel prodotto non proprietario. Questi due risultati meritano particolareattenzione, perché si tratta degli strumenti con cui ogni giorno gli opera-tori della PA si trovano a lavorare. È quindi molto facile comprendere lecriticità legate alla sostituzione di prodotti consolidati e molto completi(come Microsoft Office).Rispetto ai risultati ottenuti sui software SIT/GIS, prodotti di tipo specia-listico destinati a specifici settori degli EELL (programmazione territo-riale, edilizia, ecc…), un primo macro dato riguarda la percentuale elevatadi non risposte. Questo fa supporre che vi sia una gestione diretta dei sin-

23

Intensità nell’utilizzo di FLOSS per i client/desktop

Descritte le dinamiche dei risultati rispetto all'universo di riferimento (intermini di localizzazione geografica e dimensione dei singoli Comuni), sianalizzano ora le singole tipologie di software, iniziando da quelli per laproduttività personale. I risultati fanno riferimento alla dotazione stan-dard in capo ai singoli operatori pubblici, quella definita, gestita e man-tenuta operativa dalla struttura interna (o da fornitori esteri concontratti di gestione e manutenzione).In Figura 8 sono rappresentati gli indici di intensità di utilizzo calcolatiper ciascuno dei cinque ambiti di software client/desktop indagati. I dati,come detto, sono pienamente rappresentativi, e quindi la percentuale,unità di misura orizzontale, è da applicare al totale dei 341 Comuni del-l'Emilia-Romagna.

22

sistema

operativo

posta

elettronica

browser

internet

office

automation

sit/gis*

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

31-49%

50%

51-75%

76-99%

100% FLOSS

0% FLOSS

11-30%

Webmail

non sa/non risponde

< 10%

Intensità

di utilizzo

(iuFLOSS)

Comuni

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

FIGURA 8 - INTENSITÀ DI UTILIZZO SOFTWARE CLIENT/DESKTOP (% COMUNI)

nell’adozione di sistemi automatici per la gestione dei contenuti Web dei sitidei Comuni. Come si apprezza in Figura 9, la maggior parte degli utilizzatoridi 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…).

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 utilizzaresulle reti Intranet e Internet (siti Web, posta elettronica, sistemi gestio-nali, ecc…). Il livello di efficienza ed efficacia dei software utilizzati suiserver ha riflesso diretto sulla produttività e sulla capacità di lavoro del-l’intera amministrazione pubblica, e per questa ragione molto spesso laloro gestione (e quindi anche la scelta su quale software utilizzare) è de-mandata a soggetti esterni specializzati in questo campo.

25

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

Gruppo di lavoro regionale openoffice.orgConsapevole delle difficoltà che spesso incontrano le amministrazionipubbliche che decidono di migrare a sistemi FLOSS, il progetto EROSS, sustimolo di alcuni EELL del territorio regionale, ha costituito un gruppo dilavoro degli utilizzatori di openoffice.org. Il numero di installazioni cen-site con EROSS 2008 è di oltre 6500, e quindi il fenomeno è rilevante. Ilgruppo di lavoro è allo stato attuale composto da rappresentanti di Co-muni, Province e della Regione Emilia-Romagna, e potrà essere aperto adaltri soggetti che nel tempo si riterrà utile coinvolgere. Gli obiettivi che siprefigge 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 diopenoffice.org nella PA, destinato agli EELL che hanno deciso di utilizzareil prodotto open source; (3) stabilire una sorta di comunità stabile degliutilizzatori di openoffice.org della PA regionale. Il primo incontro si èsvolto a inizio dicembre 2008. Maggiori informazioni possono essere richieste via e-mail all’[email protected].

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à inEmilia-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 diun supplemento sperimentale di indagine riguardante i sistemi di gestionedei contenuti Web (CMS – content management system). I risultati raccolti,seppur limitati nel numero, offrono un ulteriore tassello informativo cheaiuta 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 diulteriori portali tematici. È quindi presumibile attendersi un’espansione

24

37 61

2

8

33

18

Fonte: EROSS-RACER (agosto) 2008. * Nota: I dati sono stati raccolti con un questionario on line a risposta volontaria; per questaragione i risultati hanno solo valore informativo e non rappresentatività statistica.

FIGURA 9 - L'UTILIZZO DI FLOSS PER LA GESTIONE DEI CONTENUTI DEL SITO WEB ISTITUZIO-

NALE (N. COMUNI) *

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

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

In Figura 11 vengono messi a confronto i risultati di intensità di adozionemedia 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 inmodo 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 quadrantebasso di destra, che corrisponde ad elevata intensità nell’utilizzo diFLOSS per i client/desktop e bassa per i server.

27

Prima di tutto è quindi interessante notare (Figura 10) come un elevato nu-mero di Comuni non gestisca internamente i server, fatta eccezione per i fileserver e i Database Management System (DBMS)23. A differenza di quantovisto per i software client/desktop, sul lato server il numero di Comuni cheutilizzano in modo esclusivo FLOSS è molto elevato. Sul totale dei 341 Co-muni emiliano-romagnoli, sono “100% FLOSS” rispettivamente il 7% per iWeb 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 livellomondiale (FLOSS come Apache, Tomcat, Jboss, Postfix, ecc… sono leader o im-portanti players del loro mercato), esistono prodotti FLOSS per i server stabilied affidabili che possono rispondere in modo completo e pieno alle esigenze

26

web

server

application

server

mail

server

file

server

server di

desktop

remoto

data base

management

systems

printer

server

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

31-49%

50%

51-75%

76-99%

100% FLOSS

0% FLOSS

11-30%

non gestito internamente

legacy*

< 10%

non sa/non risponde

Comuni

Intensità

di utilizzo

(iuFLOSS)

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

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

100%

0%

0% 50% 100%

A

C

50%

B

D

In

te

ns

it

à d

i u

til

iz

zo

FL

OS

S l

at

o S

er

ve

r

Intensità di utilizzo FLOSS lato Client/Desktop

Fonte: EROSS 2008.

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

Non essendo stati fatti interventi di alcun tipo lato server, è probabileche le motivazioni alla base dell’adozione di FLOSS siano di tipo econo-mico/politico e non tecnico;

C. Only server, il sentiero di avvicinamento al FLOSS passa in modo moltostretto da una prima azione esclusivamente indirizzata all’adozione disoftware libero o a codice sorgente aperto sui server. Le dimensioni deiComuni sono medie (13.500 ab.) e analoghe a quelle del gruppo prece-dente. La scelta di utilizzo di FLOSS lato server è molto probabilmentefrutto di una decisione tecnica operata dal responsabile dei sistemi in-formativi/informatici. Non vi sono interventi significativi sulle postazioniclient/desktop che presupporrebbero il coinvolgimento e la collabora-zione di tutti i dipendenti e l’approvazione/supporto di tutti i livelli deci-sionali/politici;

D. Both client/desktop & server, si tratta di enti che gestiscono almeno lametà dei propri server con FLOSS e che contemporaneamente hanno in-stallazioni diffuse di software liberi o a codice sorgente aperto sulle sin-gole postazioni degli operatori pubblici. Le dimensioni medie dei Comunisono medio-grandi (41.400 ab.) ed è quindi probabile che le risorse umane(in termini di numero e competenze) non manchino. In questi enti lascelta di adottare FLOSS in entrambi gli ambiti applicativi ha dovuto coin-volgere sia i responsabili tecnici che gli organi decisionali/politici del Co-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 allaloro sinistra, e per i quali ci si può attendere una progressiva crescita nel-l’intensità di utilizzo FLOSS sia server che client/desktop.

Identikit dei Comuni utilizzatori di FLOSS

Provando a dettagliare le caratteristiche dei Comuni del campione, si èoperata una divisione in categorie basata sul valore complessivo di iu-FLOSS24. Sono stati così definiti tre gruppi:

• nessun utilizzo di FLOSS, iuFLOSS pari a zero;• moderato utilizzo di FLOSS, 0%< iuFLOSS < 20%;• elevato utilizzo di FLOSS, iuFLOSS > 20%.

La soglia del 20% è stata fissata tenendo conto del valore medio del cam-pione e delle scelte operate nell’analisi del 2006. In ultima approssima-zione quindi, il 20% rappresenta un valore critico per distinguere traquanti usano in modo “moderato” (inferiore alla media) FLOSS e quantine fanno invece un uso “elevato” (superiore alla media).La Tabella 3 fornisce per le diverse classi di utilizzatori una sorta di iden-tikit. È possibile notare infatti che le dimensioni del Comune, intese come

29

Questo risultato suggerisce che il percorso seguito dai Comuni nell’ado-zione di livelli significativi di FLOSS lato client/desktop deve passare ne-cessariamente da un primo progressivo e sempre più consistente utilizzolato server. L’ipotesi di fondo, sostenuta anche dai dati sin qui illustrati,è che il passaggio verso il software free e open source debba prima avve-nire lato server, coinvolgendo le strutture tecniche che per l’ente si oc-cupano della gestione delle ICT, per poi muoversi verso unasperimentazione lato client/desktop, solo in quel momento considera-bile come preludio per una vera e propria adozione o migrazione checoinvolga tutte le postazioni degli operatori del Comune.

In Tabella 2 i Comuni rappresentati in Figura 11 sono stati raggruppatisecondo criteri selettivi in gruppi omogenei che possono essere descrittinei seguenti modi:

A. Full server, presentano tutti il massimo grado di intensità di utilizzo diFLOSS lato server, e si distanziano da tutti gli altri come ad evidenziarel’importanza sostanziale di una scelta simile (che a quanto pare non èper tutti facile o praticabile). Questi Comuni sono di medie-piccole di-mensioni (5.600 ab.), e probabilmente, proprio forti della loro ridottacomplessità e delle scarse risorse economiche a disposizione, hannoscelto di affidare la gestione dei propri server elusivamente a softwareFLOSS;

B. Only client/desktop, tutti questi Comuni si sono dotati di softwareclient/desktop FLOSS ed hanno probabilmente iniziato un processo di“migrazione” o “affiancamento” di prodotti FLOSS a quelli proprietarigià in uso. Questi enti hanno una dimensione media doppia (12.000 ab.)rispetto a quella dei precedenti, e quindi, presumibilmente, possonocontare su personale dedicato e strutture interne o esterne che si oc-cupano di gestione e manutenzione del software installato.

28

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

DI FLOSS

( )Utilizzo

FLOSS

A Full server

B Only client/desktop

C Only server

D Both client/desktop & server

Comuni

(n.)

12

18

64

7

Media

(ab.)

5.600

12.000

13.500

41.400

Max

(ab.)

20.000

96.000

142.000

175.000

Min.

(ab.)

700

1.900

900

2.800

Fonte: EROSS 2008

( )

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, seppurleggermente, (4) nel passaggio alla classe di utilizzatori successiva.

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 spesamedia per licenze software degli ultimi 3 anni (dal 2004 al 2006), presentadei valori decrescenti all’aumentare dell’intensità dell’utilizzo di FLOSS.Nello specifico, nella classe di elevati utilizzatori di FLOSS il valore è di201 € per addetto, 316 € per addetto per gli utilizzatori moderati e 348 €per addetto per i non utilizzatori. Questo dato da un lato non sorprende,perché è plausibile ipotizzare un rapporto inverso tra uso medio di FLOSSe spesa media in licenze software per addetto, dall’altro è una prima im-portante conferma del risparmio reale che l’utilizzo di FLOSS può gene-rare per i Comuni.

Da sottolineare è anche l’evidenza di un consenso abbastanza generaliz-zato, e sostanzialmente trasversale alle tre classi di utilizzatori FLOSS, ri-guardo all’eventualità che la PA rivesta un ruolo attivo nella promozionee diffusione di software libero (free) e a codice sorgente aperto (opensource). Su questo si tornerà in modo dettagliato nelle pagine successive.Tra i Comuni con un elevato utilizzo di FLOSS, il 21% ha sviluppato o hafatto sviluppare software (FLOSS e non) proficuamente riutilizzabile daaltre amministrazioni (Tabella 3). Al calare dell’intensità di utilizzo, tale

31

numero (medio e mediano) di abitanti, influenzano l’intensità di utilizzodel FLOSS. Lo scenario che sembra emergere fa immaginare che piùgrande è un Comune, maggiore sarà la probabilità che adotti soluzioniFLOSS, 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 sullapossibilità di adottare o non adottare FLOSS piuttosto che sull’intensitàdi utilizzo. In altri termini, la maggior parte dei Comuni medio-grandi scel-gono di sperimentare soluzioni FLOSS, ma la scelta di farne un uso diffusoed intenso dipende da altri fattori. In generale quindi, i Comuni con unvalore dell’iuFLOSS > 0% sono il 71%, mentre il restante 29% ha un valoreiuFLOSS pari a zero25.

Il dato sul numero medio di fornitori di servizi ICT legati al software dicui ogni ente si avvale è abbastanza interessante. La tendenza emersachiaramente a riguardo nel 2006, che vedeva un numero di fornitori cre-scente all’aumentare dell’intensità di utilizzo di FLOSS, risulta ora meno

30

TABELLA 3 - IDENTIKIT COMUNI UTILIZZATORI DI FLOSS

( )Dimensione media del Comune (abitanti)

Dimensione mediana del Comune (abitanti)

% del totale dei Comuni

Adozione di un atto di indirizzo sul FLOSS

Presenza di un addetto all’ICT#

Strategia ICT#

Strategia di e-government#

Connessione a banda larga (>2Mbps)#

Il Comune realizza o commissiona attività

di sviluppo software

Numero medio di fornitori ICT**

Spesa media in licenze software per addetto*

Parere favorevole a politiche della P.A.

a favore del FLOSS

ELEVATO

UTILIZZO

DI FLOSS (IUFLOSS>20%)

18.749

7.222

31%

15%

65%

29%

32%

77%

21%

4,0

201 €

86%

MODERATO

UTILIZZO

DI FLOSS (IUFLOSS<20%)

15.403

6.273

40%

12%

59%

26%

31%

79%

8%

4,4

316 €

80%

NESSUN

UTILIZZO

DI FLOSS (IUFLOSS=0%)

4.151

3.472

29%

8%

27%

9%

21%

74%

4%

2,8

348 €

79%

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

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

Il Comune detiene la proprietà

del software sviluppato#

Tipologia software sviluppati (n.)*

Sw “Sw general pourpose”

Sw “specializzato”

Sw “dedicato”

ELEVATO

UTILIZZO


89%

10

8

6

MODERATO

UTILIZZO


67%

4

1

4

NESSUN

UTILIZZO


0%

1

1

2

TOTALE

%

73%

15

10

12

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

( )

percentuale si riduce drasticamente, arrivando all’8% per i Comuni chefanno moderato uso di FLOSS ed al 4% per i non utilizzatori. In Tabella 4sono forniti alcuni approfondimenti sul tema dello sviluppo di softwareda parte dei Comuni. Nel 73% dei casi i Comuni che hanno fatto svilup-pare software ne detengono la proprietà, la percentuale è dell’89% nelcaso degli EELL che fanno elevato utilizzo di FLOSS, e scende allo 0% peri Comuni con iuFLOSS pari a zero. Tale differenza può essere un riflesso didiversi 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 altrifattori alla base della diversità osservata, è ipotizzabile che le dimensionimediamente minori dei Comuni non utilizzatori di FLOSS abbiano unqualche peso26. In ogni caso, il numero di Comuni che hanno sviluppatosoftware all’interno di questa classe di utilizzatori è talmente esiguo darendere 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 pereseguire funzioni tipiche dell'Ente29, con una leggera prevalenza dellaprima tipologia.

( )Responsabile settore ICT

Utenti/Dipendenti

Ragioneria

Consulenti esterni

Altri

ELEVATO

UTILIZZO


48,8%

28,6%

6,0%

7,1%

9,5%

MODERATO

UTILIZZO


57,0%

23,4%

4,7%

6,5%

8,4%

NESSUN

UTILIZZO


21,8%

33,3%

3,8%

23,1%

17,9%

TOTALE

%

42,5%

28,4%

4,8%

12,3%

12,0%

In Tabella 5 sono descritti i risultati ottenuti al quesito che richiedevaquale 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 dautenti/dipendenti (28,4%) e consulenti esterni (12,3%). Se guardiamo i datiper classi di utilizzatori, mentre nei Comuni che hanno un moderato edun elevato utilizzo di FLOSS questo schema generale (pur se con diversepercentuali) viene mantenuto, nella classe dei non utilizzatori il pesomaggiore nelle scelte riguardanti i software da acquistare e utilizzarespetta ad utenti/dipendenti (33,3%), seguiti da consulenti esterni (23,1%)ed infine dal responsabile del settore ICT (21,8%). Questo dato potrebbespiegarsi considerando che nei Comuni non utilizzatori, che sono tipica-mente Comuni di piccole dimensioni, da un lato non è sempre presenteuna vera e propria figura di responsabile dei servizi ICT, dall’altro si trattadi Comuni che fanno frequentemente ricorso a servizi esterni di consu-lenza, il che ovviamente si riflette sul peso relativo nelle scelte in materiadi software. La mancanza in molti casi di una figura unica di responsabileICT in questa classe di Comuni è indirettamente confermata dall’elevatovalore della categoria “Altri” (17,9%). Guardando alle specifiche espresseda quanti hanno indicato “Altri” , infatti, si scopre che nella maggior partedei 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 utilizzarenel proprio ambito di competenza.

3332

TABELLA 5 - FIGURA DI MAGGIOR PESO NELLA SCELTA DI QUALI SOFTWARE (FLOSS E NON)

ACQUISIRE O UTILIZZARE NEL COMUNE

Fonte: EROSS 2008

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

DEL COMUNE

OSTACOLI NEL CAMBIO DI FORNITORE

Nessuno

Migrazione archivi/dati

Mancanza di altri fornitori competenti

sul territorio

Knowhow acquisito da personale

Vincoli contrattuali

Altro

Non sa/non risponde

ELEVATO

UTILIZZO


11,90%

75,70%

14,30%

81,40%

18,60%

8,60%

4,80%

MODERATO

UTILIZZO


11,20%

71,70%

15,20%

67,40%

17,40%

6,50%

2,80%

NESSUN

UTILIZZO


15,40%

77,30%

15,20%

69,70%

10,60%

6,10%

0,00%

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

In Tabella 6 sono riportati i dati relativi ai principali ostacoli indicati daiComuni 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, sonorappresentati dalla migrazione di archivi/dati e dal knowhow acquisitodal personale. Questo risultato stupisce in quanto l’adozione di FLOSSdovrebbe accompagnarsi ad una sostanziale riduzione della dipendenzadai fornitori, offrendo nella maggior parte dei casi software che utiliz-zano standard aperti, facilitando appunto la migrazione degliarchivi/dati.Si approfondiscono ora (Tabella 7) alcuni dati più di tipo qualitativo, chedescrivono il favore o la contrarietà dei referenti dei Comuni interpellaticirca l’opportunità di azioni della PA a favore della diffusione ed adozionedi software libero e a codice sorgente aperto nel settore pubblico e pri-vato.

Se da un lato, come già detto, si registra un consenso generalizzato e so-stanzialmente trasversale alle tre classi di utilizzatori riguardo l’eventua-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 iComuni con elevato e moderato utilizzo di FLOSS si tratta principalmente

( )LA PUBBLICA AMMINISTRAZIONE DOVREBBE

FARSI PROMOTRICE DI AZIONI A FAVORE

DEL FLOSS?

No

Sì, in quanto i principi alla base del

FLOSS, quale la libera circolazione

della conoscenza, sono

da ritenersi prioritari nell'agenda

della PA

Sì, in quanto il FLOSS è

tecnicamente superiore ed

economicamente vantaggioso

Non risponde

ELEVATO

UTILIZZO


9,5%

63,1%

22,6%

4,8%

MODERATO

UTILIZZO


16,8%

67,3%

13,1%

2,8%

NESSUN

UTILIZZO


16,7%

46,2%

33,3%

3,8%

TOTALE

%

14,5%

59,9%

21,9%

3,7%

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, mentrel’opzione dell’obbligo di legge è quella relativamente meno “gradita”. Leazioni intraprese dalla PA a favore del FLOSS nel settore privato (Figura13) 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 chepiù o meno intensamente utilizzano FLOSS non presentano differenzesostanziali e significative rispetto alle dinamiche generali.

3534

TABELLA 7 - AZIONI DELLA PUBBLICA AMMINISTRAZIONE A FAVORE DEL FLOSS (FAVOREVOLI

VS CONTRARI)

Fonte: EROSS 2008

OBBLIGO DI LEGGE REGOLE GENERALI

VALIDE PER TUTTE

LE PA

REGOLE

AMMINISTRATIVE

E LINEE GUIDA

INTERNE DEFINITE

DALLE SINGOLE PA

ATTIVITÀ ED INIZIATIVE

INFORMATIVE

0%

20%

80%

60%

80%

100%

Fonte: EROSS 2008

FIGURA 12 – ESPRESSIONE DI FAVORE/SFAVORE NEI CONFRONTI DI AZIONI A SOSTEGNO

DELL’ADOZIONE DEL FLOSS NEL SETTORE PUBBLICO

NON SA, NON RISPONDE

ASSOLUTAMENTE CONTRARIO

ABBASTANZA CONTRARIO

ABBASTANZA FAVOREVOLE

ASSOLUTAMENTE FAVOREVOLE

Per concludere questa descrizione dei dati raccolti, si riportano in Tabella8, per tutte le tipologie di software censite, l’elenco dei prodotti FLOSSutilizzati ed il numero di Comuni che ne fanno un uso esclusivo. Se sup-poniamo di accettare l’idea che “maggiore è il numero di utilizzatoriesclusivi, migliore la qualità del software”, allora i FLOSS giudicabili qua-litativamente migliori sono quelli utilizzati per i server, e nello specificogli application server (che in 63 Comuni sono esclusivamente free o opensource). A questa valutazione occorre però affiancare un’altro principiooperativo che influisce sull’adozione (specie se esclusiva di FLOSS) e cioèche “più si influenza il lavoro quotidiano dell’utilizzatore finale più sonogli ostacoli al passaggio al FLOSS”. Quest’ultima considerazione spiega oalmeno motiva il basso numero Comuni che utilizzano in modo esclusivoFLOSS lato client/desktop.

Considerazioni generali sui risultati

dell’analisi descrittiva

Le modalità di indagine scelte (questionario on line e contatti telefonici,campionamento ed elevata rappresentatività) e la metodologia EROSS (ela-borazione dell’indice di intensità di utilizzo, focus su software client/de-sktop e server, integrazione tra basi dati diverse, ecc…) hanno permesso digiungere ad una chiara e veritiera descrizione delle scelte in campo soft-ware operate dai Comuni emiliano-romagnoli. In sintesi quindi:

• il 63% dei Comuni dell’Emilia-Romagna ha esplicitamente dichiarato diusare free, libre, open source software (34,4% è la media nazionale);

• un ulteriore 14% di Comuni della regione, pur essendosi dichiarati non uti-lizzatori, risultano invece avere installazioni di FLOSS e si configuranocome utilizzatori inconsapevoli (e quindi portatori di un gap di cono-scenza).

• in totale, quindi, il 77% dei Comuni (quasi quattro su cinque) utilizza FLOSSnegli ambiti applicativi indagati (client/desktop e server);

• oltre un Comune su dieci ha adottato un atto di indirizzo strategico o am-ministrativo avente ad oggetto l’adozione di software free, libre, opensource. Dimostrazione che l’attenzione per il FLOSS travalica anche i con-fini settoriali dei sistemi informativi per diventare oggetto di riflessioniampie e trasversali all’ente;

• l’intensità di utilizzo di FLOSS (iuFLOSS) è più elevata nelle fasce dimensio-nali di Comuni che stanno agli estremi (Comuni molto piccoli - <3.000 ab. -e Comuni grandi - >15.000 ab.);

• le differenze tra territori provinciali sono evidenti sia dal punto di vista ge-nerale che sugli aspetti specifici e quindi sull’intensità di utilizzo FLOSS ri-ferita ai singoli ambiti applicativi del software;

3736

ATTIVITÀ DI FORMAZIONE

FINALIZZATE

ALL'ADDESTRAMENTO

DI SVILUPPATORI/TECNICI

COMPETENTI

COORDINAMENTO

E PROMOZIONE

DI PROGETTI FLOSS

SUSSIDI E

FINANZIAMENTI

COINVOLGIMENTO

DIRETTO ALLO SVILUPPO

E ALLA FORNITURA

DI SOLUZIONI FLOSS

0%

20%

40%

60%

80%

100%

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

DELL’ADOZIONE DEL FLOSS NEL SETTORE PRIVATO

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

( )AMBITO DI UTILIZZO

Sistema operativo per il desktop

Software di Gestione di posta

elettronica

Browser Internet

Office Automation

Sit/Gis

Web Server

Application Server

Mail Server

File Server

Server di desktop remoto

Data base management systems

Printer server

FLOSS IN USO NEI COMUNI

EMILIANO-ROMAGNOLI

Gnu-Linux

Mozilla Thunderbird, Evolution

Mail, Netscape Messenger

Mozilla Firefox, Netscape Naviga-

tor, Mozilla, Flock

OpenOffice, Scribus

Quantum Gis, MapServer

Apache

Apache Tomcat, PHP, Jboss, Zope,

Xaraya, Perl

Postfix, Cyrus IMAP server, Qmail,

Send Mail, Open-Xchange, Exim,

HMailServer, Dovecot

Samba, FreeNAS

VNC, PuTTY, Open SSH, Xorg X11

MySQL, PostgreSQL, In gres

Linux/CUPS, LPRng

COMUNI CHE USANO

ESCLUSIVAMENTE FLOSS

0%

2%

1%

1%

1%

6%

20%

9%

4%

4%

3%

1%

Fonte: EROSS 2008

ABBASTANZA FAVOREVOLE

ASSOLUTAMENTE FAVOREVOLE

NON SA, NON RISPONDE

ASSOLUTAMENTE CONTRARIO

ABBASTANZA CONTRARIO

Fonte: EROSS 2008

• 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 pubblicheamministrazioni;

• integrare i due modelli in una specificazione che prendesse in considera-zione entrambe le caratteristiche, lineare e non, in modo da dar conto dellaprobabile presenza di endogeneità31.

Modello I

Il primo modello, in linea con quello proposto nel 2006, ha cercato di metterein luce quali siano i fattori atti a spiegare il livello di interattività dei servizion 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).

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

39

• l’indice di intensità di utilizzo è pari a zero nel 29% dei Comuni (che nonfanno 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 sorgenteaperto), e superiore a 20% nel 31,2% degli enti osservati (che dimostrano difare 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 adoggi pensato ed utilizzato quale alternativa vera al leader di mercato pro-prietario. Molto differenti sono, invece i risultati relativi ai navigatori per ilWeb e ai pacchetti per la produttività personale per i quali si riscontranoelevati livelli di iuFLOSS ed un numero considerevole di Comuni che nefanno un uso esclusivo. In generale, nonostante gli evidenti distinguo, lepostazioni client/desktop degli operatori della PA sono ancora dominateda 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 applicationserver e i DBMS (data base management system) presentano prevalenza disoftware free, libre, open source che in molti casi risultano utilizzati inmodo esclusivo;

• il numero di installazioni FLOSS è in valore assoluto maggiore nel latoclient, ma l’utilizzo è certamente più intenso sul lato server;

• ad aver maggior peso nella scelta di quale software (FLOSS e non) acquisiree utilizzare sono nell’ordine il responsabile del settore ICT, gli utenti/dipen-denti e i consulenti esterni;

• c’è un generale accordo, tra i rispondenti, sull’opportunità di politiche attivedalla PA a favore del FLOSS, con le ragioni di “principio” che prevalgono suquelle tecnico-economiche;

• tra le possibili azioni i maggiori consensi vanno alle “attività e iniziative for-mative”, mentre i minori ai “sussidi a favore di privati che operano in campoFLOSS”.

Analisi avanzata

Come già fu fatto in occasione della rilevazione EROSS 2006, anche in quelladel 2008 sono state effettuate una serie di analisi avanzate volte, da un lato,a verificare i risultati raggiunti nell'edizione precedente30 e, dall'altro, ad ap-profondire tali risultati. In particolare si è proceduto a:

• testare un primo modello econometrico lineare, ove un indicatore del li-vello di interattività dei servizi on line offerti dalle pubbliche amministra-zioni emiliano-romagnole è stato fatto dipendere da una serie di variabiliritenute rilevanti;

38

TABELLA 9 - MODELLO I – FATTORI CHE INFLUENZANO IL LIVELLO DI INTERATTIVITÀ

DEI SERVIZI OFFERTI ON LINE

( )Specificazione [a]

VARIABILE DIPENDENTE

Interattività servizi on line

VARIABILI INDIPENDENTI

• spesa totale in software e hardware

• numero di dipendenti nella divisione ICT

• spesa in formazione ICT per il personale

• numero di dipendenti della PA

• adozione di software a codice sorgente

aperto

• esistenza di una strategia di e-government

• disponibilità di accesso alla rete in banda

larga

• presenza di una carica politica con delega

all'informatica/telematica

• esistenza di una strategia di ICT

Specificazione [b]


Interattività servizi on line


• spesa totale in software e hardware


• spesa in formazione ICT per il personale


• esistenza di un atto di indirizzo rivolto al-

l'adozione di software a codice sorgente

aperto



larga




Fonte: EROSS 2008

I risultati indicano chiaramente come la presenza di una carica politicacon delega all'informatica e/o alla telematica sia una variabile significa-tiva nello spiegare sia la probabilità di adozione di FLOSS che la presenzadi un atto formale di indirizzo verso il FLOSS. Ma mentre la prima proba-bilità è influenzata in modo marginale dalla presenza di un assessore, laseconda 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 anchenuovi 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);

• tale relazione è rilevante solo se il Comune ha posto in essere un atto diindirizzo teso a favorire l'adozione di FLOSS (EROSS 2008);

• la scelta di utilizzare FLOSS da parte dei Comuni emiliano-romagnolimatura 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'adozionedi FLOSS è la presenza di una figura all'interno dell'ente che abbia com-petenze specifiche nel campo e con un potere decisionale forte (EROSS2008).

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à diadozione del FLOSS all'interno degli stessi. Questo risultato conferma,dal lato empirico, ciò che fino ad ora è sempre stato proposto da unpunto di vista teorico, ovvero che, per avere una diffusione capillare delFLOSS e perché questa dia dei frutti in termini di servizi ai cittadini, è ne-cessaria una scelta strategica formalizzata e supportata adeguatamente.

41

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 equantitativamente importante (di entità pari alla dimensione della PA).

Modello II

Sulla base dei risultati ottenuti con il primo modello circa l'importanza diun 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 indirizzoformale nei confronti del software a codice sorgente aperto (specifica-zione [b] in Tabella 10).

40

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]


Adozione di software a codice sorgente

aperto


• spesa in licenze software

• necessità di personalizzazione

delle applicazioni software

• dipendenza dai fornitori




larga





• figura interna che decide sull'acquisto del

software

Specificazione [b]


Esistenza di un atto di indirizzo rivolto

all'adozione di software a codice sorgente

aperto


• spesa in licenze software

• necessità di personalizzazione

delle applicazioni software

• dipendenza dai fornitori




larga





• figura interna che decide sull'acquisto del

software

Fonte: EROSS 2008

prettamente infrastrutturali (reti fisiche) e quelle che mirano all’inclu-sione, misurazione di scenario e monitoraggio34. Riportando il medesimorisultato ri-parametrizzato sulla base del valore economico dei progetti,Figura 14 [b], il rapporto muta presentando un sostanziale equilibrio trai progetti che si occupano di software e non (49% e 51%).

Il criterio della “prevalenza” adottato per le risposte affermative (riportate inFigura 14) è stato scelto nella consapevolezza che, con rare eccezioni, nellarealizzazione di progetti complessi si prevede l’acquisizione e/o sviluppo disoftware sia proprietario che free, libre o open source che di proprietà dellaPA. La prevalenza dovrebbe in questo senso dar maggior peso e quindi faremergere 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 disoftware 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 pagarelicenze d’uso proprietari, e al quale potrebbe essere propriamente appostauna licenza free o open source (qualora si volessero cogliere i vantaggi diuno sviluppo collaborativo tra settore pubblico e privato).

43

Capitolo 2: il FLOSS nei progetti del

Piano telematico dell’Emilia-Romagna

(PiTER)

Nel maggio del 2007, l’Assemblea regionale ha approvato a maggioranzal’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 esempioper le altre amministrazioni, e sappiano coinvolgere la cittadinanza e glialtri 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 unquadro informativo che dà conto dell’uso e della diffusione di softwarelibero 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 pratichedi “riuso” di soluzioni tecniche e tecnologiche, come pure di competenzee conoscenza.

Metodologia di indagine

I quesiti che sono stati utilizzati per la rilevazione sono stati elaborati erivisti con il contributo di alcuni capi progetto, al fine di aderire nel mi-gliore dei modi alle differenti caratteristiche degli interventi previsti nelPiTER 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 diprediligere la forma “chiusa” come opzione di risposta. Lo strumentoscelto per raccogliere i dati è stato, quindi, quello del questionario on-line che, sottoposto ai capi progetto nel periodo giugno-luglio 2008, haportato 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

2

70%26%

4%

13%

17%

40%

51%43%

6%

12%

3%

36%

28¤ M¤

6¤ M¤

82¤ M¤

Fonte: EROSS-PITER 2008

FIGURA 14 – ACQUISIZIONE E/O LO SVILUPPO DI SOFTWARE NEI PROGETTI DEL PITER

[a] n. Progetti PiTER [b] valore economico Progetti PiTER

Non risponde

No

Sì, prevalentemente proprietario

Sì, prevalentemente free, libre o open source

Sì, prevalentemente di proprietà della PA

Il progetto prevede l’acquisizione e/o lo sviluppo di software:

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

Approfondendo quest’ultimo aspetto, Figura 15, si può notare come lescelte dei capi progetto varino in funzione dell’aumentare del valore ge-nerale del progetto ed anche in rapporto all’aumentare della percentualedi budget di progetto destinata all’acquisizione e/o sviluppo di software.In generale, oltre il 45% dei progetti che compongono il primo percentiledella Figura 15 [b] utilizzano soluzioni FLOSS; mano a mano però che ilvalore dei progetti sale, questa opzione viene completamente abbando-nata a favore dei software di proprietà della PA e proprietari. Di fronte aprogetti il cui budget è molto rilevante, e in cui è particolarmente signi-ficativo il peso della componente software, il capo progetto del PiTERopta per soluzioni di cui detiene o prevede di acquisire la proprietà.Nonostante il software libero e a codice sorgente aperto non rappresentil’opzione software prevalente nella realizzazione dei progetti del PiTER,alcuni tra i più famosi prodotti FLOSS sono diffusamente utilizzati in unaelevata percentuale di interventi. Come si nota in Figura 16, sistemi per iserver come Apache, MySQL, PostgreSQL, Jboss, Tomacat e Linux sonotutti utilizzati in oltre un progetto su quattro, ed in alcuni casi in più dellametà. Questo risultato evidenzia e conferma come tali prodotti siano daconsiderare qualitativamente affidabili e maturi.

4544

A.

meno del 5%

B.

tra il 6%

e il 15%

C.

tra il 16%

e il 50%

D.

oltre il 50%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

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

FIGURA 15 – PROGETTI CHE PREVEDONO ACQUISIZIONE E/O LO SVILUPPO DI SOFTWARE

DISTINTI SULLA BASE DELLA PREVALENZA DELLA TIPOLOGIA DI SOFTWARE

[a] Percentuale del budget del progetto destinata all’acquisizione

e/o sviluppo di software

[b] Valore economico del progetto (percentili*)

Percentile 1 Percentile 2 Percentile 3 Percentile 4

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Software proprietario

Software free, libre o open source

Software di proprietà della PA

Sono 42 i progetti che dichiarano di sviluppare software che potrebbe essereproficuamente riusato da altre amministrazioni (si tratta dell’84% dei pro-getti che prevedono acquisizione e/o sviluppo di software). La maggiorparte di questo software è di tipo “specializzato”, destinato ad usi speci-fici (sicurezza, gestione e manutenzione server, CMS, Intranet, ecc.), e/o“dedicato”, cioè usato per eseguire funzioni tipiche della Pubblica Ammi-nistrazione (protocollo informatico, posta elettronica certificata, firmadigitale, ecc...).Dal punto di vista della proprietà del codice, sono tre i progetti che nonla detengono e che quindi non possono attuare forme di “riuso”; 25 nesono proprietari e perciò possono legittimamente cedere o trasferire il di-ritto all’utilizzo del software; e 14 (uno su tre) ammettono di non saperecon esattezza di chi sia la proprietà del programma informatico.

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

4746

Progetti che utilizzano in prevalenza software proprietario

Progetti che utilizzano in prevalenza software di proprietà della PA

Progetti che utilizzano in prevalenza software free, libre o open source

Linux Apache MySQL/PostgreSQL Tomcat JBoss

0%

10%

20%

30%

40%

50%

60%

Fonte: EROSS-PITER 2008

FIGURA 16 – SOFTWARE FREE O OPEN SOURCE UTILIZZATI NEI PROGETTI DEL PITER

(% PROGETTI CHE PREVEDONO ACQUISIZIONE E/O LO SVILUPPO DI SOFTWARE)

A. meno del 5% B. tra il 6% e il 15% C. tra il 16% e il 50% D. oltre il 50%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

FIGURA 17 - RAGIONI/VALUTAZIONI CHE GUIDANO LA SCELTA DEL CAPO PROGETTO CIRCA

LA TIPOLOGIA DI SOFTWARE DA ACQUISIRE E/O SVILUPPARE

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

di software

costi di acquisizione

costi/benefici pluriennali

esperienza e a motivazioni personali

funzioni/prestazioni attuali del software

funzioni/prestazioni potenziali e future del software

4948 49

La mancanza di una chiara informazione su chi detiene i diritti di un pro-dotto software che “potrebbe proficuamente essere riusato da altre ammi-nistrazioni” esprime una carenza nella gestione prospettica dei prodotti diprogetto giustificata però dalla complessità che, in alcuni casi, li caratterizza.Spesso infatti, l’utilizzo contemporaneo di componenti proprietarie, free oopen 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 livellodi trasferibilità e legittimo riuso. Per concludere, in Figura 18 sono rappre-sentate le opinioni dei capi progetto del PiTER circa l’opportunità di inter-venti della PA a favore del FLOSS nel settore pubblico e privato (i quesiti sonoi medesimi proposti ai Comuni e descritti in Figura 12 e Figura 13). Come sinota, Figura 18 [a], vi è elevato favore verso l’ipotesi che la PA si impegni inattività ed iniziative informative e nella definizione di regole generali valideper tutta la PA. Sono invece meno sostenute le altre opzioni di interventoproposte. Sul fronte del settore privato, Figura 18 [b], si riscontra un minorfavore, specie per ipotesi di sussidi e finanziamenti, che però raggiunge livellimolto elevati nel caso di coordinamento e promozione di progetti FLOSS.

48

OBBLIGO DI LEGGE REGOLE GENERALI

VALIDE PER TUTTE LE PA

REGOLE

AMMINISTRATIVE

E LINEE GUIDA

INTERNE DEFINITE

ATTIVITÀ ED

INIZIATIVE

INFORMATIVE

0%

25%

50%

75%

100%

ATTIVITÀ DI

FORMAZIONE

FINALIZZATE

ALL'ADDESTRAMENTO

DI SVILUPPATORI/

TECNICI COMPETENTI

COORDINAMENTO

E PROMOZIONE

DI PROGETTI FLOSS

SUSSIDI E

FINANZIAMENTI

COINVOLGIMENTO

DIRETTO ALLO

SVILUPPO E ALLA

FORNITURA

DI SOLUZIONI FLOSS

0%

25%

50%

75%

100%

abbastanza favorevole

assolutamente favorevole

non sa, non risponde

assolutamente contrario

abbastanza contrario

Fonte: EROSS-PITER 2008.

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

DELL’ADOZIONE DEL FLOSS

[a] settore pubblico

[b] settore privato

Percentile 1 Percentile 2 Percentile 3 Percentile 4

0

10

20

30

40

50

60

70

80

90

100

funzioni/prestazioni potenziali e future del software

funzioni/prestazioni attuali del software

esperienza e motivazioni personali

costi/benefici pluriennali

costi di acquisizione

[b] Valore economico del progetto (percentili*)

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

5150

Capitolo 3: esperienze e casi d’uso

Il software libero a codice sorgente aperto è frequentemente utilizzatonei Comuni e negli altri EELL dell’Emilia-Romagna, e spesso elementiFLOSS sono alla base dei sistemi informativi che vengono progettati erealizzati nell’ambito di importanti e impegnativi progetti di e-gover-nment. Di seguito sono riportate alcune significative esperienze chehanno interessato Pubbliche Amministrazioni emiliano-romagnole.

Regione Emilia-Romagna

DG Centrale Organizzazione, Personale, Sistemi informativi e Telematica

Fabio Bucciarelli e Alessandro LandiServizio Sistema informativo-informatico regionale

Sono alcuni anni che la Regione Emilia-Romagna sta valutando l’uso delsoftware free e/o open source sia nell'area client che nell'area server,ancor più da quando le linee guida del CNIPA e il Codice dell’Amministra-zione Digitale prescrivono che nella scelta di un nuovo software devonoessere 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 serverche utilizzavano FLOSS è andato via via aumentando. Ad esempio è statoscelto di installare come server regionale FTP sicuro un server Linux ba-sato su Linux Red Hat e Proftpd. La flessibilità del software free o opensource ha permesso di crittografare tutte le comunicazioni FTP e, tramitealcuni prodotti software e al sistema di autenticazione di Linux alta-mente configurabile, è stato possibile integrare l'autenticazione degliutenti con i domini di autenticazione regionali sia interno che esterno(basati su tecnologia Microsoft Active Directory). È stata infine creataun'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-

51

Considerazioni generali

L’analisi dei dati raccolti da EROSS circa l’acquisizione e lo sviluppo disoftware nei progetti del Piano telematico dell’Emilia-Romagna 2007-2009 pone in evidenza che:• i project manager prediligono componenti informatiche di proprietà

della Pubblica Amministrazione e quindi, nonostante il free, libre, opensource software sia largamente diffuso ed utilizzato (ma non prevalen-temente), i prodotti software acquisiti e/o sviluppati nel PiTER sarannoper lo più di proprietà pubblica;

• il FLOSS è utilizzato in modo prevalente in quei progetti che hanno unvalore 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-durre codice che potrebbe proficuamente essere riutilizzato da altreamministrazioni ma un numero non irrilevante non ha chiarezza su chine sia il legittimo proprietario;

• esiste un sostanziale favore per azioni di supporto all’adozione delFLOSS nel settore pubblico (in particolare per attività di tipo informa-tivo) e in quello privato (nel coordinamento e promozione di progettiFLOSS);

• i progetti del PiTER, pur detenendo nella maggior parte dei casi la pro-prietà del software acquisito e/o sviluppato, non hanno previsto azioniche chiariscano nel dettaglio quali componenti del codice siano sotto-posti a licenza (proprietaria o FLOSS) e quali invece possano essere “li-cenziati” (magari FLOSS) dalla PA in modo da favorire politiche di riusoe standardizzazione.

50

3

In seguito a questo studio di fattibilità, per il 2008 la filiera Java OpenSource scelta (oltre a quella LAMP) è entrata “ufficialmente” a far partedelle “Linee guida per la governance del sistema informatico regionale”.Nelle quali sono ora individuate tre filiere supportate per applicazioni esiti 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: quellobasato 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, lostack tecnologico è implementato su piattaforma Linux (Linux RedHat,Apache, PHP, MySQL o PostgreSql). Da rilevare che, nel corso dell’ultimoanno, 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 isistemi, è la predisposizione di un ambiente di test in alta affidabilità co-stituito da un cluster di server virtuali Vmware Virtual Infrastructure consistema operativo Red Hat e Application Server Jboss e da un ambiente diproduzione anch'esso in alta affidabilità costituito però da nodi fisici.Per ora rimane comunque la possibilità, per le applicazioni che utilizzanoquesta 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 è infattiuno 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, edi un prodotto FLOSS per la gestione dei contenuti di siti e applicazioniWeb. Inoltre tutti i nuovi tipi di progetti multiregionali per l'e-govern-ment supportati dal CNIPA, già avviati e che avranno un forte svilupponei prossimi anni, quali Sigmater, Sistema Informativo Lavoro, interope-rabilità delle applicazioni (porta di dominio) sono fortemente basati sutecnologie open source e open standard (almeno per quanto concernelo stack tecnologico legato all’applicazione; non è sempre così sul frontedatabase).

53

cative supportate dal CED regionale. Si è quindi proceduto ad uno studiodi fattibilità al fine di individuare i prodotti software da includere in talefiliera. Pur non avendo intenzione di abbandonare la cosiddetta filieraLAMP (da Linux, Apache, MySql, PHP/Perl/Python), sulla quale vi eranogià buone competenze ma che non si ritiene adatta per applicazioni ditipo “enterprise”, è stato deciso di concentrarsi su una filiera compatibilecon 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 lafattibilità 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 ognicategoria 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 daun'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 unametodologia 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 - Qualificationand Selection of Open source Software36, metodologia a sua volta opensource 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 essereripetute 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 enon inferiori ai corrispettivi prodotti proprietari: per tali categorie sonostati scelti Linux Red Hat e Jboss Application Server. Per quanto riguardainvece i database relazionali, pur non mancando soluzioni valide e affida-bili, la valutazione realizzata ha evidenziato che le funzionalità non sonoancora al livello delle principali soluzioni proprietarie. Difficoltosa è statala scelta tra MySql e PostgreSql, in quanto i punteggi ottenuti dai dueprodotti con il metodo QSOS sono stati molto simili. La preferenza è ca-duta su PostgreSql.

52

Azienda Unità Sanitaria Locale di Reggio Emilia

Marco RossiVice 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 fareuna 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 Tecnologiedell’Informazione della AUSL di Reggio Emilia (Servizio diretto da LucianoSologni), esperto di reti dal lontano 1991. La sua specializzazione sonoda sempre state le LAN (local area network), i primi cablaggi strutturatidestinati ai “diffidenti” uffici tecnici, ed ora il VoIP (voice over Internetprotocol), inizialmente mal digerito e divenuto oramai una costante perl’installazione anche di un singolo apparato telefonico. A partire dal 1995,con l’unificazione provinciale delle 6 USL e la realizzazione di una retedati molto articolata (60 sedi collegate e utilizzo di fibra ottica per lametà dei collegamenti), il processo di convergenza “fonia-dati-immagini”ha rappresentato il filo conduttore delle azioni e degli interventi ICTmessi in campo nell’Azienda.

In tempi più recenti, grazie alla rete a larga banda LEPIDA, è stato quindirealizzato 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 immaginiradiologiche, 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 costantee corretto della rete su cui navigano “vascelli” che devono con certezzaraggiungere i porti di destinazione.A fronte quindi di una situazione variegata e composita, si è presentata

55

Complessivamente, dopo un anno di supporto ai progetti di e-govermentpromossi dal CNIPA e di applicazione delle linee guida nel rispetto delletre 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 diconvergenza, per tutte le applicazioni J2EE, verso la filiera applicativa Asu piattaforma Linux RedHat (application server JBOSS). Ciò vale sia perle applicazioni non critiche per l’Ente Regione che per le applicazioni checostituiscono (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 strumentodi produttività individuale. A tale scopo verrà predisposto un cluster diserver 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 progettoEROSS.

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 sitratta 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 ITCmaggiori 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à raggiuntoe le funzionalità a disposizione non siano ancora paragonabili a quelledei corrispettivi prodotti proprietari.Sulla base dell’orientamento a livello europeo e delle raccomandazioni alivello 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

cise di abbandonare il progetto. Diretta conseguenza fu l’inserimento nelgruppo di lavoro di un nuovo elemento che valutato lo stato dell’arte edin considerazione di nuovi sviluppi del mercato FLOSS convinse la“ciurma” a spostare la prua del progetto verso un prodotto realizzato dauna 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 progettodivenne quindi Zenoss a cui, come per “magia“ e in un’ottica tipicamentee splendidamente open source, gli add on MORGANA sono stati inglobati. L’esperienza del progetto MORGANA ha insegnato che partire da zero conun progetto Open Source non è la migliore delle idee. Ove possibile, hapiù senso aderire ad un pre-esistente progetto magari maturo e possibil-mente con alle spalle della community una software house che rispondaanche a logiche di mercato, e che soprattutto abbia ben chiaro qualedeve essere il rapporto cliente-fornitore ed abbia consuetudine a rispet-tare una commessa. Inoltre si è verificato che, in un progetto opensource, la componente universitaria può essere molto importante nellaparte 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 diconvenzionamento 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, MarcoRossi è stato incaricato di far parte della Commissione Open Source delMinistero per le Riforme e l’Innovazione nella PA. In questo ruolo e grazieal confronto con i colleghi della Commissione, a volte anche molto ac-ceso, Marco Rossi ha maturato convinzioni che sono andate a far partedella proposta di documento finale. In particolare, nelle componenti chehanno 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 nellaPA debba avvenire mettendo sullo stesso piano soluzioni open sourcecon soluzioni proprietarie o miste, effettuando confronti comparativi chenon 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 elementidi valutazione:

57

la necessità di uno strumento di management della rete che consentisseinterventi 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 qualipotessero essere le alternative open source. Prodotti proprietari e open,pur presentando interessanti funzionalità, non soddisfacevano a pienole 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 rilasciodello 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é, inqualità di debugger e co-fruitore della sperimentazione, la Regione Emi-lia-Romagna, rappresentata dalle Dott.sse Cristina Scarani e MichelaMazzini.L’avventura è durata più di tre anni ed ha visto il gruppo di lavoro riunirsicon 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 dellastessa, è stata uno dei problemi maggiori, in quanto ha, per un certoverso, “decapitato” la squadra di lavoro. Venendo meno il responsabilescientifico (che in modo ufficioso non ha mai fatto mancare la sua pre-senza) infatti, si è sentita maggiormente la pesantezza di un progettoforse partito con un po’ troppa ambizione;

• gli sviluppatori (freelance universitari o parauniversitari), nonostantefosse prevista una retribuzione della loro attività, hanno sempre tenutoun 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 pensarnela 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 hannodato 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ù riuscitaa fare le magie che si prefiggeva sino a quando uno degli sviluppatori de-

56

sitory, ai quali vengono resi disponibili i link di collegamento.L’individuazione di best pratice può favorire un incentivo alle PA nelleloro componenti politiche e tecniche, per adottare soluzioni che possanoessere prese a riferimento da altre amministrazioni per qualità ed eco-nomicità, evitando il proliferare di soluzioni duplicate e che richiedonoinvestimenti ex novo per la soluzione di problemi già risolti altrove.“

La AUSL di Reggio Emilia oggi utilizza con soddisfazione Zenoss MOR-GANA per gestire la propria rete; il software è disponibile sia nel reposi-tory CNIPA38 che in Sourceforge39.

Si sta ora attivando un software per la realizzazione dell’archivio dellebio-immagini e la Federazione dei PACS aziendali tra la AUSL e l’AziendaOspedaliera di Reggio Emilia, derivando gli elementi applicativi dal pro-getto open source MARIS40, pubblicato anch’esso sul sito del CNIPA e suSourceforge. Sempre attingendo dal repository CNIPA, si sta altresì adot-tando il software open source IntranetDPS41 per la gestione del docu-mento per la sicurezza.

Morgana: regina dell’isola di Avalon, sorellastra e amante di re Artù, al-lieva del mago Merlino. Fata, Dea celtica, ninfa ed anche un miraggio. Lamagia di Morgana è forse la più potente che sia mai esistita. E forse è pro-prio tutto vero!

59

• TCO (costo totale di possesso) della singola soluzione (il TCO deve esserecalcolato su di un arco temporale ampio, affinché possa essere fattaun’adeguata valutazione del rapporto tra gli investimenti fatti ed il ri-torno degli stessi);

• costo di uscita dalla soluzione (occorre che venga valutato il costo diuscita da una soluzione in termini sia tecnologici che di formazionedegli utilizzatori);

• valorizzazione delle competenze tecniche possedute dall’amministra-zione (valutazione di come la soluzione aumenta le competenze in-terne);

• interoperabilità intesa per la PA nel suo complesso (utilizzo di formatiaperti e standard, piattaforme multiple);

• valutazione dell’interesse di altre amministrazioni al riuso dell’applica-zione da realizzare e/o acquistare (attenzione al riuso e quindi, in casodi sviluppo di nuove soluzioni, indicazione di caratteristiche atte allaportabilità e alla fruibilità da parte di altri utilizzatori);

• valore sociale della soluzione (analisi di quanto la soluzione porta even-tuali benefici alla comunità in termini di attività orientata all’eroga-zione di servizi).

Nella individuazione delle soluzioni da adottare, facendo particolare ri-ferimento alla riusabilità di SW esistente alla quale tutte le PA centrali elocali devono tendere, occorre che la rispondenza alle proprie esigenzevenga 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 ilprodotto con codice sorgente aperto nella modalità GPL, L-GPL, altroche 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 soluzioniadottate dalle PA centrali e locali, oltre alle proposte che il mercato puòoffrire. Attraverso il catalogo possono essere messe a disposizione bestpratice ed i sorgenti software che non debbono essere necessariamentedepositati sul sito del CNIPA, ma possono fare riferimento ad altri repo-

58

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, alcunirigorosi 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 liutilizzano; il risultato delle elaborazioni prodotte da un sotto-sistemasettoriale 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 sistemadeve essere potenzialmente utilizzabile da chiunque, ovunque egli sitrovi.

A partire dalla metà del 2005, perciò, la Protezione Civile regionale ha av-viato un processo di avvicinamento al concetto di “Sistema InformativoIntegrato di supporto alle Decisioni”. Fino a quel momento, infatti, circaun centinaio di dataset, per lo più di tipo cartografico, forniti prevalen-temente da Servizi regionali (Servizio Sistemi Informativi Geografici eServizio Geologico, Sismico e dei Suoli) e da ARPA (Servizio Idro-Meteo-Climatico), costituiva il patrimonio informativo residente negli hard diskdegli 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 incorso di evento a supporto del Presidente della Giunta e della Direzioneper 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 generalistautilizzate, poco adatte ad inserirsi in una infrastruttura che di per sé, in-vece, è orientata a fruire i dati e le informazioni secondo un approccioClient/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 aumentandoi costi conseguenti alla proliferazione delle licenze d’uso dei diversi ap-plicativi software. Ne derivava una riduzione dell’efficienza dell’interoSistema 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 assicurarel’efficacia dell’intervento. Ciò è tanto più vero per quanto attiene l’effet-tiva applicazione di indirizzi normativi (ad esempio, la legge in materia dilotta attiva agli incendi di bosco) che impongono l’attivazione di SaleOperative Unificate, anche in modalità virtuale, con la presenza conte-stuale di operatori della Regione, del Corpo dei Vigili del Fuoco , del Corpo

61

Agenzia regionale di protezione

civile dell’Emilia-Romagna

Stefano DalliServizio pianificazione e gestione emergenze

La Protezione Civile è una macchina complessa. Da vari punti di vista eper tanti motivi. Una specie di tetraedro con “stampigliati” su ciascunadelle quattro facce i fondamenti: prevenzione, previsione, emergenza, in-terventi. Da qualsiasi parte lo si giri, il tetraedro è sempre uguale a sestesso; 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. Progettaree 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. Tuttequestioni che all’utente finale però non interessano in quanto risultamolto più sensibile ad altri argomenti, come: disporre tempestivamentedi 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 ilmutamento dei fenomeni; conoscere il contesto di riferimento entro cuii 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 diversigradi di sintesi; realizzare analisi di tipo multidimensionale in forma as-sistita.Ora, se queste sono le esigenze degli utenti, non possono essere dimen-

60

La Regione offriva opzioni sia proprietarie che open source. Scegliere laprima pareva essere la più semplice mentre la seconda appariva sotto di-mensionata. Vari dubbi sono sorti al riguardo: selezionare la piattaformaproprietaria 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 nitidamentemesso in evidenza come pensare in termini di Sistema muoveva versodue fronti: quello dell’allineamento nei confronti di un mondo rispetto alquale eravamo rimasti un po’ indietro, e quello dell’innovazione o, co-munque, connotato da caratteri fortemente innovativi. Inoltre, non vaminimizzato che tutto ciò è stato ed è frutto di una sorta di movimentoche viene dal nostro interno. E poi, si deve anche dire che buttando losguardo all’esterno, e valutata l’offerta del mercato, questa è tutto som-mato deludente e, in ogni caso, si ha a che fare con soluzioni settorialiscarsamente integrabili, interoperabili e personalizzabili.

Insomma, non era così semplice selezionare la filiera più adeguata allenostre esigenze. Il primo pensiero è stato quello dell’economicità discala. In altri termini la domanda di fondo è stata: per quale ragione ilcosto 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 aparere di alcuni potrebbe apparire semplicistica, è stata: se questi costifossero zero o vicino allo zero, si potrebbero liberare risorse importantida destinare alle intelligenze e allo sviluppo. Il software open source anostro 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/quadriprocessore. Il vantaggio economico sottolineato è ancora più rilevante intermini 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 alpasso con l'evoluzione tecnologia, mantenendo al contempo il patrimo-nio del codice sviluppato;

• la tempistica di aggiornamento tecnologico è spesso favorevole allesnelle organizzazioni open source rispetto alle complesse macchineproduttive 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; percontro il sensibile ritardo dei fornitori di costosi Application Server (IBMWebsphere per citare un esempio) costringe chi lo adotta ad utilizzareversioni già superate di Java e dei componenti JEE;

63

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 sonostate, per così dire, dimensionate in modo corretto! Si è quindi procedutodotandosi 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 cartografiacon quello di Modello Terrestre di Riferimento (MTR), sono stati proget-tati e realizzati moduli software con tecnologia Web based basati suglistandard 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 leinformazioni sono stati collocati sui server del CED Regionale ed esegui-bili da consolle di comando o di regia da qualunque postazioneIntranet/Internet dotata di un semplice browser Internet, sono stati pro-gettati e realizzati componenti software automatici che riconoscono ilsuperamento di soglie pre-individuate a seconda delle diverse tipologiedi evento (idraulico-idrogeologico, sismico, ecc) e che provvedono allacompilazione e pubblicazione automatica di pagine Web e reportistica adiversi livelli di dettaglio, nonchè operano notificazioni automatiche agliutenti.

Il lavoro preparatorio è stato enorme; tutto è stato toccato da questonuovo approccio: normalizzazione e standardizzazione dei dati, assegna-zione di coordinate spazio-temporali agli oggetti; recepimento di stan-dard internazionali, nazionali e regionali; enucleazione dai datasetoriginali 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 gliutenti delle esigenze; verifica con i colleghi del CED Regionale ed accordosu 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 è statoconseguito; 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 moledi lavoro svolta aveva conseguito importanti obiettivi, rimaneva ancoraaperta la questione cruciale: quale ambiente o filiera software utilizzare?

62

taforma Linux RedHat AS 5, WS Apache, AS JBoss, DB PostgreSQL, conestensione PostGIS, MapServer (funzionalità di map rendering), libreriapgRouting (funzionalità di gestione dei grafici), libreria R + SPATSTAT (fun-zionalità di statistica e grafici)42.Spostando ora l’attenzione sulle applicazioni, due sono stati i momentidi meditazione e discussione: il primo, sull’ambiente di sviluppo; il se-condo sull’interfaccia utente.Gli strumenti e i linguaggi individuati per lo sviluppo delle applicazionisono Eclipse, il Java Enterprise Wide Framework SPAGO, Javascript, l’Ap-plication Server JBoss. Particolare attenzione viene posta nei confrontidello sviluppo dei componenti ,ogniqualvolta si ravvisa la necessità chequesti vadano ad implementare le librerie.

L’interfaccia utente è organizzata a menu e pannelli informativi e risultaflessibile anche in configurazione “multi screen”, potendo inviare i pan-nelli a diversi client/monitor. La disposizione e numerosità dei pannelli èconfigurabile sia dalla tipologia dell’applicazione che dall’utente. È inol-tre predisposta per l’emergente interfaccia “multi touch screen”.

65

• l'estrema reattività tecnologica delle comunità open source si concre-tizza in minori tempi di sviluppo e migliore qualità del software a dispo-sizione degli utilizzatori;

• la formazione di competenze, sugli ormai numerosissimi prodotti ecomponenti open source, nei team di sviluppo accresce la tempestivitànel rispondere alle esigenze degli utenti finali, in quanto vengono pra-ticamente azzerati i tempi di individuazione del fornitore e di contrat-tazione commerciale;

• l'eterogeneità della domanda di software specialistico costringe i pro-duttori ad allargare la copertura funzionale dei loro prodotti: essi risul-tano quindi sovradimensionati e scarsamente modulari con costi nonaccettabili se rapportati alle esigenze talvolta limitate e più spesso al-tamente specifiche degli utenti finali. Per contro, il codice open sourceè per definizione personalizzabile rispetto a particolari esigenze degliutenti (anche se non sempre il gap qualitativo rispetto al software pro-prietario è facilmente colmabile e le competenze necessarie facilmentereperibili).

Per quanto riguarda poi i contratti di manutenzione ed assistenza, pareutile osservare che chi acquista software proprietario si sente garantitorispetto a malfunzionamenti per la possibilità di usufruire dell'assistenzatecnica del fornitore; tuttavia, l'utilizzo su scala planetaria di molti pro-dotti open source e la presenza sul Web di numerosi forum e comunità disviluppatori e utilizzatori rendono estremamente agevole il problem sol-ving. È in tal senso importante indirizzare la scelta dei prodotti opensource 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 nellaclassica forma cartografica bidimensionale, che in quella più sofisticatatridimensionale di tipo scenografica e pseudo-realistica; in questo caso,oramai, una importante quota delle applicazioni Web di questo tipo sonobasate su motori open source.Calandoci nella realtà della Protezione Civile, e ritornando alla metaforadel 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 lepiù varie e impreviste; ciò si può trasformare in richieste specifiche o per-sonalizzazioni; a quel punto, se non si ha il pieno governo dell’ambientee dell’infrastruttura, il rischio di implementare soluzioni non integraterisulta molto elevato.

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

64

Per quanto riguarda i cluster ed il calcolo parallelo, a partire dal 2003,parte delle attività per la produzione di previsioni numeriche operativetramite modelli parallelizzati con MPI44, tradizionalmente svolte su si-stemi di calcolo parallelo proprietari presso centri di supercalcolo, sonostate duplicate, a fini di backup e di sperimentazione, su sistemi di cal-colo parallelo a basso costo ospitati presso il SIMC. Ciò è stato possibilegrazie 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 isistemi Unix su cui tradizionalmente “girano” le applicazioni scientifichedi calcolo parallelo. Determinante è stata la disponibilità di librerie MPIopen source per il calcolo parallelo. La flessibilità di Linux ha permessodi 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 costidi 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ò essereottenuto 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 PaesiBassi, è stato sviluppato ed è continuamente aggiornato dal Diparti-mento di Meccanica dei Fluidi della Facoltà di Ingegneria Civile e ScienzeGeologiche della Delft University of Technology. Gli sviluppatori di SWAN,unitamente al codice sorgente con licenza GPL, mettono a disposizionestrumenti 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 utilizzaregolarmente dal 2005 il modello di chimica e trasporto Chimere. Si trattadi un codice Fortran90 parallelo, sviluppato dagli istituti INERIS e LMD edistribuito sotto licenza GNU. Il modello è attualmente utilizzato in modooperativo da una decina di istituti in diversi Paesi europei, e la comunitàdi utenti comprende anche diverse università e istituti di ricerca. INERISgestisce inoltre un servizio gratuito di distribuzione delle condizioni alcontorno per le previsioni di qualità dell’aria a scala locale e una mailinglist degli utilizzatori. L’implementazione di Chimere presso ARPA ha ri-

67

ARPA

Agenzia regionale

prevenzione e ambiente

dell’Emilia-Romagna

Servizio Idro-Meteo-Clima (SIMC)

Paolo PatrunoArea Modellistica e Radarmeteorologia

Il servizio meteorologico di ARPA Emilia-Romagna ha iniziato le primesperimentazioni con GNU/Linux nel 1997; da allora l'utilizzo di softwarelibero 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 esale operative circa 25 installazioni di Linux Fedora 8 (ognuna locale macon condivisione di area utenti e di alcuni software tramite dischi di rete).La distribuzione originale del sistema operativo è stata arricchita di circa75 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 delsistema operativo FLOSS;

• l'esecuzione di applicativi specifici per la geofisica quali modelli, graficae statistica (sono disponibili numerosi FLOSS articolati e completispesso sviluppati da altri centri con simili competenze o da università);

• lo sviluppo di nuove applicazioni, prodotto della ricerca operativa (sonostati adottati come compilatori quelli della suite GNU che comprende C,C++ e Fortran90, insieme ad autoconf e automake che insieme ad altreutilità forniscono un ambiente di sviluppo completo).

Per questo tipo di utilizzo siamo alla ricerca del giusto compromesso tra laricerca di software allo stato dell'arte e la stabilità dello stesso, in un am-biente in cui la sicurezza viene delegata ad altri sistemi appositamenteconfigurati. Questa impostazione permette di sfruttare le risorse hardwaredei 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'impegnorichiesto nell'aggiornamento delle versioni maggiori della distribuzioneche solitamente vengono effettuale a cadenze poco più che annuali.

66

Provincia di Forlì-Cesena

Sandro MazzottiDirigente del Servizio Sistema Informativodella 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 piattaformaMicrosoft Office ad ambienti “open” ha avuto il suo avvio nel 2005.

Di seguito si schematizzano in modo sintetico le principali tappe chehanno 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 officealternativi a quelli in uso (sottoposti a licenza d’uso a pagamento e ditipo proprietario). Diretta conseguenza fu l’autorizzazione a svolgere unostudio approfondito, mirato ad individuare un ambiente informatico al-ternativo concretamente utilizzabile nell’Amministrazione. Le principalimotivazioni alla base dell’intervento della Giunta furono di natura eco-nomica e quindi tese ad abbattere i costi di acquisizione dei software ditipo MS Office. Primo passo, operato dal Servizio Sistema Informativo, fuquello 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 unprodotto simile a quello in uso era finalizzata a minimizzare gli impattisugli utenti finali.In parallelo, nell'anno 2006 – per motivi organizzativi e di criticità nellamanutenzione utente – è stato sostituito l'ambiente di posta elettronica“client” Outlook (componente del pacchetto Office di Microsoft), con ilprodotto “non free” ma a bassissimo costo totalmente in tecnologia Web,denominato “MDAEMON”; la modifica ha coinvolto oltre il 90% dei clientdell'ente; questa sostituzione, oltre a risolvere alcuni problemi che ap-pesantivano notevolmente l'assistenza tecnica in Help Desk, ha di fattocontribuito a rimuovere un componente fondamentale presente, e legatostrettamente all'ambiente tecnologico dominante. La Conferenza dei Dirigenti, sentito il parere del Sistema Informativo, haautorizzato l'avvio di una sperimentazione del prodotto individuato(OpenOffice.org v.ne 2.1) coinvolgendo circa 30 utenti appartenenti a ser-

69

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 codicesorgente e poterlo modificare liberamente.

SVILUPPO DI SOFTWARE SCIENTIFICO AL SIMC E LA COMUNITÀ IN-TERNAZIONALE.Il servizio meteorologico di ARPA Emilia-Romagna ha sviluppato neglianni alcuni software ad uso scientifico dettati da proprie esigenze in-terne. Per tale sviluppo ci si avvale esclusivamente di strumenti FLOSS. Isoftware sviluppati più significativi sono distribuiti con licenza GPL; que-sto in quanto si è ritenuto di mettere a disposizione il lavoro fatto allacollettività ed in particolare ad altre amministrazioni pubbliche; dalladiffusione di tale utilizzo si ritiene possa tornarne un valore aggiunto (intermini 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 caricodel servizio sono state realizzate richiedendo software libero o opensource; tale software riguarda la gestione di dati osservati e previsti supunti stazione e sistemi di archiviazione di tutti i messaggi meteorologicidefiniti 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 possibiliin una classica commessa software;

• ottima integrazione tramite librerie software (API) con gli applicativisviluppati 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 richiedecompetenze 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

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 deiSW coinvolti (SW del Protocollo informatico e il SW per la gestione deibuoni 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 oltrel'80% ), e successivamente si procederà alla formazione di gruppi di utentiper la successiva attivazione del prodotto.Si ipotizza il passaggio completo degli utenti individuati non oltre marzo2009.

Per facilitare la compatibilità degli ambienti MS Office e OpenOffice.orge ridurre al minimo le problematiche nell'uso e nello scambio dei docu-menti, sono stati impostati alcuni parametri per tutti gli utilizzatori; inparticolare il più importante è l'utilizzo del formato di salvataggio (.doc)e non il formato nativo di OpenOffice.org. Al momento si è scartato ilformato libero RFT come “standard” per il salvataggio dei documenti, inquanto il formato RTF ha delle limitazioni rispetto al .doc, ma questo nonesclude 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 è. Ilproblema maggiore è rappresentato infatti dai documenti che arrivanodall'esterno, che talvolta hanno “macro” e funzionalità tali da rendernedifficile 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, maanche per le ricadute di efficienza e risparmio per i piccoli e medi enti (eper le scuole) del territorio. Questa responsabilizzazione, unita al fattoche gli utenti individuati nella sperimentazione erano tendenzialmenteevoluti, 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

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 settembre2007) ed è stata supportata da una azienda locale specializzata in am-bienti “open”, che ha svolto i corsi di formazione iniziali e ha prestato unservizio di Help-Desk di secondo livello, mentre quello di primo livello èstato garantito dal Servizio Sistema Informativo interno. Per misuraremeglio in itinere l'andamento della sperimentazione, è stato realizzatoun applicativo Web nel quale gli utenti dovevano tracciare le attivitàsvolte, indicando le problematiche riscontrate, allegando i documenticoinvolti 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 mandatodi procedere con le attività necessarie alla massima diffusione del nuovoambiente. 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 (principalmenteper 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 è statorealizzato 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 concosti 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 ambientiMS 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 inmodo 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

tuno, che potrebbe contribuire ad uniformare i formati in uso in dire-zione di opzioni “aperte” e quindi non discriminanti, potrebbe essererealizzato dagli enti locali di livello superiore (a partire dalla Regione Emi-lia-Romagna). Adottando ad esempio standard di interscambio dati ba-sati su formati non penalizzanti per tutti gli utilizzatori di ambientidiversi da quello MS Office, come ad esempio il formato XML.

Un elemento ulteriore che certamente potrebbe fare accelerare ulterior-mente verso l'adozione dell'ambiente OpenOffice.org da parte degli entipotrebbe essere l'attivazione di un punto di supporto (via FAQ) unificatoa livello Provinciale, ma ancor meglio se Regionale; il costo di gestionesarebbe più contenuto e il supporto sarebbe più completo e tempestivo.

Infine, se molti enti Emiliano-Romagnoli decidessero di adottare l'am-biente OpenOffice.org, si potrebbero avere maggiori garanzie di evolu-zioni rapide del prodotto, soprattutto in alcune componenti funzionaliritenute “penalizzanti” nell'uso rispetto all'ambiente MS Office, se si ac-compagnassero le richieste rivolte al Consorzio OpenOffice.org, anchecon sottoscrizioni di piccole ma significative somme di denaro.

73

da parte degli sperimentatori. L'impressione finale manifestata da tutti è che, pur con alcune limitazionisu funzionalità prevalentemente di tipo “avanzato”:• la compatibilità tra i due pacchetti office è molto alta;• la facilità d'uso è tale da non richiedere specifici corsi di formazione,

ma semplicemente approfondimenti sulle differenze tra i due ambienti;• esistono funzioni aggiuntive rispetto al prodotto MS Office (ad esempio

il convertitore pdf integrato), che rendono molto pregevole l’utilizzo diOpenOffice.org sia per efficienza che per costi.

Nel futuro, allargando il numero degli utenti coinvolti, ci aspettiamo al-cune criticità, come ad esempio:• resistenza al cambiamento da parte di utenti, soprattutto da parte di

quelli meno esperti: sarà, quindi, necessario un accompagnamento mi-nimo con formazione mirata;

• difficoltà di adattamento all'uso di alcune funzioni “avanzate”, casomaipiù efficienti (e più chiare) nell'ambiente MS Office. Per ovviare a questaproblematica è necessario un lavoro di studio e formazione su comeeseguire le stesse funzioni sull'ambiente OpenOffice.org ed eventual-mente modificare certi documenti in modo tale da renderli maggior-mente compatibili. In parallelo il Consorzio che segue lo sviluppo diOpenOffice.org dovrebbe migliorare certe funzionalità (come ad es. lastampa di etichette), che sono sicuramente meno efficienti rispetto al-l'ambiente MS Office;

• problemi con la condivisione di documenti complessi, soprattutto setrattasi 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 loscambio dei dati. Ogni ente dovrebbe quindi rifiutare documenti chenon 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 daparte della dirigenza dell'ente. Siamo altresì convinti che un reale dispie-gamento di questo ambiente di produttività personale alternativo a MSOffice in enti medio grandi sarà un fattore decisivo e determinante peruna 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 apertiMicrosoft (specie per i fogli di calcolo e i data base). Un intervento oppor-

72

Dal 2005 le postazioni di lavoro consegnate ai dipendenti sono equipag-giate con una serie di software FLOSS in ambito Windows sullo stile diTheOpenCD. Nel dettaglio i calcolatori elettronici in uso nell’ente hannopreinstallato: 7-zip, OpenOffice.org, Firefox, Thunderbird , Filezilla, PDFCreator, The Gimp, Inkscape, vlc, relavnc. Questo ha permesso agli utentidi 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 diattenzione e coinvolgimento sul tema FLOSS; i colleghi già a conoscenzadell'argomento hanno così potuto approfondire e sviluppare il loro inte-resse: in alcuni casi è stato richiesta la possibilità di lavorare in ambienteopen predisponendo postazioni desktop linux.

Per quanto concerne i servizi alla cittadinanza, sono state installate di-verse postazioni Internet al pubblico completamente gestite tramitesoftware libero con un sistema di autenticazione sviluppato interna-mente al nostro Ente. La diversa architettura e sicurezza di Linux ci hapermesso 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 postazioniall'anno, indice di un alto gradimento dal parte dell'utenza.

Sul fronte istituzionale il primo avvallo alla tecnologia FLOSS risale al2005 quando viene discusso in Consiglio Comunale un “Ordine del giornosul software libero”. Il 12 dicembre 2007 la Giunta Comunale, con deliberan. 475, approva il “Piano di sviluppo dell’open source software all’internodei servizi comunali”, che getta le basi per i progetti futuri. In particolaresi 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 aprile2008, a seguito delle nuove elezioni, il sindaco nomina un assessore condelega specifica all'informatizzazione, affermando una nuova sensibilitàper le tematiche del software libero, segno di un ulteriore rafforzamentostrategico in questo senso da parte del nostro ente.

Attualmente si sta lavorando alla migrazione dalla suite di produzioneindividuale 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. Cisono diverse criticità da sistemare prima di poter portare a compimentoil progetto: tra queste, la maggiore è la forte integrazione e dipendenzadi diversi applicativi verticali in uso presso il nostro ente con la suite Mi-

75

Comune di Imola

Luca FusaroResponsabile Sistemi Informativi del Comunedi Imola

Il Comune di Imola, come già recentemente avvenuto per altri enti dellanostra regione, ha intrapreso e sviluppato il tema del software libero eopen 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 disponibiliin ambito open source e free software.

L’attenzione è stata dapprima rivolta al consolidamento dei servizi di reteessenziali come Firewall, DHCP e DNS. È stato realizzato un server proxycon filtraggio dei contenuti per la navigazione in Internet degli utenti. Aseguito 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ù ampliodato dalle opportunità offerte dal nuovo modo di operare proprio dellacomunità open source. Dietro ad un programma liberamente utilizzabile,vi è un radicale cambiamento nella progettazione, nello sviluppo e nelmantenimento 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 professionalenelle attività svolte. Questo ha portato l’ente verso l’investimento in ri-sorse umane con il coinvolgimento e l’assunzione di personale tecnicoqualificato anche in ambito FLOSS.Il passo successivo è stata la migrazione del sistema di autenticazionedi 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 diMicrosoft 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 costruiteinternamente.

74

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

77

crosoft Office: l'adeguamento dei software alle nuove esigenze comportaun grosso sforzo condiviso tra il Comune e i fornitori delle procedure. At-tualmente siamo in contatto con il Comune di Forlì e di Ozzano dell'Emi-lia per collaborare alla stesura e alla richiesta delle specifiche da adottarecon le nuove versioni dei programmi che vedono coinvolti fornitori co-muni. Si prevede, quindi, di procedere gradualmente alla migrazionedella suite di office automation partendo dai settori meno critici, via viaprocedendo ulteriormente in funzione delle nuove soluzioni adottate:questo tipo di strategia consente di avere un impatto meno drastico sulleattività dell’ente, e quindi di essere accettato più di buon grado da dipen-denti ed operatori. Sarà inoltre importante condividere col personale lemotivazioni delle scelte fatte, e organizzare una adeguata formazioneoperativa sui nuovi strumenti. Fare innovazione rompendo vecchi schemidi lavoro è forse il punto più critico per una realtà come la Pubblica Am-ministrazione, avendo sempre come obiettivo quello di mettere i nostricolleghi 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 dicompletamento del progetto si dimostrano più lunghi.

L’adozione di FLOSS nell’ente non può fermarsi all’aspetto lavorativo eorganizzativo interno: la scelta di strumenti free o open source implicauna “filosofia” sociale che coinvolge diversi soggetti della realtà in cui siopera, sia dal punto di vista culturale che produttivo: è in fase di avviouna collaborazione con gli istituti scolastici della città per coinvolgeregli studenti nello sviluppo di software a sorgente aperto e strumenti disviluppo 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 dellenuove tecnologie. È stato inoltre stabilito un contatto con ImoLUG (ImolaLinux User Group), associazione di Imola per la diffusione delle nuovetecnologie 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 strategiadi adozione del software libero e open source, e ne rafforza sempre piùil suo utilizzo, cercando di sfruttare al meglio le possibilità offerte pertrarne vantaggi economici e organizzativi. Non manca, nel contempo,l’attenzione alle nuove idee che l’adozione di FLOSS porta con se e che sicerca di condividere e diffondere sia all’interno dell’ente che nella realtàterritoriale.

76

7978

ver) che pongono il sistema della Pubblica Amministrazione regionale difronte 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 direalizzare sistemi informativi interoperabili (obiettivi espliciti ed implicitidel Piano telematico dell’Emilia-Romagna 2007-2009) possono realizzarsisolo attraverso una cooperazione tra EELL che sia basata su standard eformati liberi. Sono in tal caso indispensabili azioni informative, diffusesul territorio, che dotino tutti i decisori (ma anche tutti gli operatori) dellecompetenze e delle conoscenze utili a comprendere e condividere le op-portunità offerte dall’uso di standard e formati aperti e non ultimo disoftware 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 incampo e-government e società dell’informazione di tutti i Comuni, Pro-vince e Regione, offrono il quadro operativo all’interno del quale avviareazioni 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ù licenzefree 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 hannoscelto di utilizzare con elevata intensità il prodotto free, libre, opensource per la produttività personale dei propri operatori si pongono aconfronto per condividere approcci, soluzioni, successi e fallimenti;

• gruppo di lavoro Centri regionali e provinciali di competenza OpenSource, EROSS promuove incontri e collaborazioni con le strutture cheoperano 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 allelicenze software [FLOSS e proprietarie], alla luce dell’evidenza empiricache mostra come sia prevalente il software di proprietà della PA tra

Capitolo 4: considerazioni conclusive

e raccomandazioni

Le attività di indagine e misurazione realizzate da EROSS [CAPITOLO 1 e2] e le esperienze ed i casi d’uso descritti dagli EELL e dalle organizzazionipubbliche 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 inEmilia-Romagna.

Trovano così conferma molte delle considerazioni fatte nel precedentedossier EROSS. In particolare si può ribadire , senza alcun timore di smen-tita, che per la Pubblica Amministrazione emiliano-romagnola, come peril resto del mondo, il FLOSS non è qualcosa di passeggero (“di moda”) maal 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 conintensità elevata. Resta comunque un 14% di Enti comunali che operanocome utilizzatori “inconsapevoli” a riprova del bisogno persistente diazioni informative sul tema.

È ormai opinione largamente condivisa che i fondamenti per lo sviluppodi 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 esostenere la realizzazione concreta dell’e-government, permetterebberolo sviluppo ed il consolidamento di imprese locali di servizi e prodottiinformatici ad elevato contenuto di conoscenza ed innovazione. Comeevidenziato da studi della commissione europea48, infatti, la competi-zione nel settore ICT può trarre rilevanti benefici dalla diffusione ed usodi 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 delsoftware 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 oa codice sorgente aperto (sulle postazioni client/desktop come sui ser-

4

8180

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.

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 aspettidi compatibilità tra licenze esistenti.Attività di questo genere dovrebbero uscire dalla dimensione tempora-nea di progetto per consolidarsi in qualcosa di maggiormente strutturatoe consolidato che possa rispondere in modo continuativo e competentealle esigenze del territorio.

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'Intensita di Utilizzo di Software Libero e a Codice Sorgente Aperto nei

Comuni Emiliano-Romagnoli, in Marchesi M. (eds.), Finalmente Libero: Software

Libero e Standard Aperti per le Pubbliche Amministrazioni, McGraw-Hill.

Wong K., (2004). “Free/Open Source Software: Government Policy”, Asia-Pacific

Development Information Programme.

83

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).


ter for Strategic and Internationl Studies (CSIS).





82

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

10 La rappresentatività del campione, ovvero la capacità delle pubbliche ammini-strazioni effettivamente rispondenti al questionario di rappresentare il com-portamento generale della popolazione di tutte le PA emiliano-romagnole, èstata presa in considerazione tramite due procedure: (1) prima della fase di ri-levazione, si è provveduto ad effettuare una procedura di campionamentostratificato per classe dimensionale e provincia di appartenenza. In questomodo ci si è preventivamente posti al riparo da forti squilibri nei tassi di rispo-sta. Nella fattispecie, grazie alla tipologia di campionamento adottata, si sonopotuti prefissare obiettivi per singola cella (ove la cella conteneva un numerodi PA per provincia e classe dimensionale) composti da un numero minimo diunità da intervistare; (2) successivamente alla fase di rilevazione, i dati raccoltisono stati sottoposti a test statistici volti a controllare l'esistenza di diffe-renze significative tra rispondenti e non rispondenti per quanto riguarda laclasse dimensionale e la provincia di appartenenza. Tutti i test hanno datoesito positivo, evidenziando quindi la capacità, del campione così costruito, didare conto del comportamento della popolazione di tutte le PA emiliano-roma-gnole nel loro complesso.

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

12 Software che fornisce l'infrastruttura e le funzionalità di supporto, sviluppo edesecuzione di applicazioni e componenti server in un contesto distribuito. Sitratta di un complesso di servizi orientati alla realizzazione di applicazioni peril web, multilivello ed enterprise, con alto grado di complessità. Fonte e mag-giori dettagli all’URL http://it.wikipedia.org/wiki/Application_server

13 Programma che si occupa dello smistamento da un computer a un altro dellaposta elettronica. Normalmente un mail server risiede su un sistema dedicatoma può essere eseguito su computer ove risiedano altri server o che venganoutilizzati anche per altri scopi. Fonte e maggiori informazioni all’URLhttp://it.wikipedia.org/wiki/Mail_server

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

15 Sistema software che permette di controllare un computer da un terminaleche si trova altrove. La tecnologia di desktop remoto è molto utilizzata da pro-duttori di hardware e software per fornire assistenza in modalità remota aicomputer client in caso di problemi tecnici. Fonte (traduzione libera) e mag-giori informazioni all’URL http://en.wikipedia.org/wiki/Remote_desktop_soft-ware

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

85

Note

1 http://www.regionedigitale.net/wcm/erdigitale/pagine/pagina_piano_

telematico.htm Piano Telematico dell’Emilia-Romagna – Linee Guida 2007/2009,

pag.57.

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

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

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

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

6 La libertà, per chiunque ne abbia interesse, di modificare il codice per persona-lizzare il software alle esigenze delle singole categorie di disabili, ed eventual-mente alle specifiche necessità del singolo individuo, permette di fornire unpiù esteso servizio (e quindi favorisce l’inclusione sociale e digitale) sia dalpunto di vista qualitativo che quantitativo.

7 “Le tecnologie dell’informazione e della comunicazione nelle amministrazionilocali 2007”, i principali risultati dell’indagine e le tabelle con i dati quantitativisono disponibili all’URL: http://www.istat.it/salastampa/comunicati/non_ca-lendario/20080307_00/

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

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

84

25 191 Comuni rappresentano il 71% del campione, un dato leggermente diversodal 77% (208 Comuni) ottenuto come somma di utilizzatori consapevoli e in-consapevoli di FLOSS. I 17 Comuni di differenza si spiegano considerando chela rilevazione attuale non costituisce una mappatura completa di tutti gli am-biti di utilizzo e relativi software presenti nei Comuni della regione. L’indaginesi è concentra su alcuni (i principali) ambiti applicativi, rilevando i softwareutilizzati in tali settori. Quindi è probabile che Comuni che hanno dichiaratoesplicitamente 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 contrattualein 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 applicazionida ufficio.

28 Per “usi specifici” si intendono, ad esempio ,software per: sicurezza, gestione emanutenzione 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 alrapporto 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 dalmodello (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 inesame. L'esito di questo terzo tentativo ha dato indicazioni perfettamente inlinea 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 aiprincipi e alle indicazioni contenute nella Legge Regionale n.11/2004 “Svilupporegionale della società dell’informazione”, che definisce in modo formaleobiettivi e modalità di attuazione degli interventi e delle iniziative realizzatedalla PA regionale, in materia di società dell’informazione. La LR fa riferimentoindiretto 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 quellodel “pluralismo informatico”.

87

parte di più utenti. Fonte e maggiori informazioni all’URLhttp://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 diclient diversi, sempre che questi abbiano le autorizzazioni necessarie per uti-lizzarle. Diversi tipi di autorizzazioni possono definire se l'utente ha i dirittiper 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 unastampa 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 isistemi SIT/GIS, poiché la domanda su tale tipo di software è stata inserita nelquestionario 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 disponibiliall’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 suun campione sensibilmente più esteso e sicuramente rappresentativo, è unaconferma 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 sceltasoftware ha fatto il proprio fornitore. Ai fini della presente indagine tale infor-mazione non è però rilevante, in quanto ciò che interessa è l’impatto dell’usodi FLOSS sul complesso dei software che i Comuni gestiscono in modo diretto.

24 Come già anticipato, l’indice di intensità di utilizzo è stato ottenuto comemedia 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 mediasemplice 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

44 Maggiori dettagli su MPI all’indirizzo Web: http://en.wikipedia.org/wiki/Mes-sage_Passing_Interface.

45 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 unmodello d’onda in zone costiere caratterizzate da basse profondità. Maggioridettagli su: http://vlm089.citg.tudelft.nl/swan/index.htm.

46 Il testo completo della L.R. 11/2004 della Regione Emilia-Romagna e maggioridettagli sono disponibili all’indirizzo Web:http://www.regionedigitale.net/wcm/erdigitale/pagine/pagina_normativa/leggi_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 PiTER2008, copia disponibile in formato digitale all’URL: http://www.regionedigi-tale.net/wcm/erdigitale/pagine/pagina_piano_telematico.htm

89

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 perla 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 perla didattica, e-learning per il recupero del debito formativo, LEPIDA SANITA', Co-municAzione, Co-desing dei servizi on line.

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 16maggio 2005, a seguito della delega al Governo contenuta all'articolo 10 dellaLegge 29 luglio 2003, n. 229 (Legge di semplificazione 2001). Il Codice è entratoin 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ù appropriatele 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 documentitra 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/

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 Repositoryhttp://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 Yumcome applicativo standard per la gestione dei pacchetti, attingendo anche daun deposito locale. Il file server viene salvato quotidianamente con proceduraautomatica, utilizzando il software di backup Amanda.

88

PIANO TELEMATICODELL

,EMILIA-ROMAGNA

IL FREE, LIBRE, OPENSOURCE SOFTWARE INREGIONE EMILIA-ROMAGNA

EROSS - Emilia-Romagna Open Source Survey

IL FREE, LIBRE, OPEN SOURCE SOFTWARE

IN REGIONE EMILIA-ROMAGNA

3 erossEMILIA-ROMAGNAOPEN SOURCE SURVEY

piano telematico emilia-romagna dell il free,...

Documents