FLOSS nella pubblica amministrazione italiana
di Simone BrunozziCosa impedisce al settore pubblico di adottare soluzioni di Free/Libre Open Source Software? Un professionista del settore racconta la sua esperienza e le sue conclusioni.
Nell'ambito della Pubblica Amministrazione (PA) il 2006 sembrava essere l'anno
del “grande salto avanti” di Linux e in generale dell'Open Source
e del Free Software (che d'ora in avanti chiamerò semplicemente FLOSS,
Free/Libre and Open Source Software.
Migliaia di appassionati, di attivisti, di promotori del FLOSS, tuttavia,
si chiedono come mai ci siano ancora così tante reticenze nell'adozione
di strumenti che, a detta degli esperti, presentano numerosi vantaggi, non soltanto
economici.
La mia recente esperienza professionale all'interno di una pubblica amministrazione
(una università, precisamente), sia come docente che come tecnico, mi ha
permesso di analizzare e finalmente comprendere i motivi di questo “ritardo”
di adozione, la cui conoscenza è di fondamentale importanza per aziende,
professionisti o appassionati che intendano dare il loro contributo alla diffusione
del FLOSS e di soluzioni aperte.
Generalmente parlando, ogni scelta ruota intorno ai seguenti concetti chiave:
1) Diffidenza, 2) Inerzia, 3) Certificazione, 4) Responsabilità, 5) Interazione
sociale, 6) Dati (DICRID). Mi servirò di un esempio di fantasia
per illustrare bene come questi fattori intervengono nel processo decisionale.
Immaginiamo la PA di un comune, che possiede una manciata di server con caratteristiche
hardware diverse, e sistemi operativi diversi (di solito si gira intorno a Windows
2000 server, Windows 2003 server, SuSE, Red Hat, a volte AIX di IBM).
Questi server forniscono servizi interni (paghe, orari e ingressi, ferie, protocollo,
ragioneria, ecc.) ed esterni (gare di appalto, sito web, news, rassegna stampa,
documenti), basandosi spesso su alcuni software proprietari, sviluppati da aziende
locali o nazionali, e solitamente appoggiati su più piattaforme di basi
di dati (Oracle, Microsoft SQL server, DB/2, raramente MySQL o PostgreSQL), spesso
esistenti in più versioni. I tecnici interni solitamente personalizzano
le soluzioni adottate, in base alle competenze possedute. Questi dati, oggi, vanno
inoltre gestiti in tutela della privacy, e vanno regolarmente effettuate copie
di backup, spesso utilizzando hardware dedicato con software proprietario incluso.
In un prossimo futuro andranno inoltre prese misure adeguate per certificare l'intero
sistema informativo e la sua sicurezza, sulle orme delle norme recentemente introdotte
e standardizzate come ISO-27001.
In ambiti come questo alcune grandi aziende italiane e straniere la fanno da
padrone, tagliando fuori piccole e medie imprese o gruppi di professionisti; queste
grandi aziende adottano quasi sempre soluzioni proprietarie, seguendo un modello
di business collaudato e spesso remunerativo.
Vediamo ora come i fattori DICRID (Diffidenza, Inerzia, Certificazione,
Responsabilità, Interazione, Dati; è una sigla coniata al momento)
intervengono nei vari stadi decisionali.
Nella PA ogni scelta di rilievo comporta delle Responsabilità
per le persone al vertice della scala gerarchica, ovvero dirigenti e tecnici “EP”
(Elevate Professionalità), ma anche per tecnici di rango inferiore.
Trovandosi spesso di fronte un sistema informativo già installato e funzionante,
l'eventuale scelta di apportare delle modifiche (adottando ad esempio una piattaforma
FLOSS) viene valutata con Diffidenza, facendo pesare molto la propria responsabilità
in caso di malfunzionamenti. Effettivamente va mossa una critica al mondo FLOSS:
per vari motivi (il principale: mancanza di tessuto aziendale fertile in campo
FLOSS) la qualità dei software FLOSS e le garanzie di assistenza non competono
bene con soluzioni spesso più costose, ma affidabili.
Un dirigente deve garantire dei servizi, e se deve scegliere tra spendere 100
per un servizio che funziona quasi bene, o spendere 70 per un servizio che funziona
un pochino meno bene del primo, sceglierà il servizio più costoso
ma più affidabile. Un dirigente, poi, ha difficoltà nell'accettare
soluzioni proposte senza le solite costose brochure, prive di nomi di rilievo.
Per una piccola/media azienda risulta perciò difficoltoso competere con
i “mostri” sacri che forniscono molti dei software specifici per la
PA, come ad esempio CINECA, che dispone di centinaia di tecnici (spesso di buon
livello), e di contratti esclusivi con i principali partner (Microsoft, Oracle,
IBM). Se non è CINECA, i grandi “player” del settore sono grandi
aziende S.p.a. le quali, con ingenti investimenti, producono dei software destinati
alle PA.
Le grandi aziende di questo tipo forniscono una affidabile Certificazione
di ciò che viene installato, cosa che mette al riparo i funzionari pubblici
da una consistente fetta dei pericoli relativi alla gestione dei dati e alla loro
eventuale perdita. Una piccola azienda non può fornire “assicurazioni”,
nè tantomeno disporre della massa critica per gestire bene situazioni di
emergenza. La eventuale gestione di Certificazione comporta inoltre delle spese
ingenti, non sostenibili da piccole aziende.
L'esistenza di software già esistenti, di hardware già acquistato,
di contratti di assistenza software di durata pluriennale, di personale già
abituato ad una certa interfaccia e ad una certa procedura, fa sì che l'introduzione
di nuove tecnologie possa essere fatta solo con estrema cautela e lentezza, contrastando
con pazienza l'Inerzia del sistema attualmente in uso.
La presenza di software proprietari, che spesso utilizzano formati di dati chiusi,
impedisce di poter fornire una soluzione alternativa parziale. Non è possibile
ad esempio proporre una piccola soluzione per un piccolo settore, dato che tutti
i dati sono fortemente interconnessi, e basati su piattaforme software e DBMS
proprietarie.
I Dati, poi, rappresentano un ulteriore problema: come gestire tutti i
dati esistenti? Come convertirli o migrarli verso una nuova piattaforma? Come
certificare che il trasferimento è avvenuto senza problemi? Come rispondere
ad eventuali violazioni?
I vari funzionari pubblici che vengono coinvolti, a diversi livelli, nelle decisioni,
devono poi tenere conto delle varie Interazioni sociali che intervengono
in un ambiente di lavoro, interazioni spesso sottovalutate in qualsiasi progetto
IT. I funzionari abituati a quella interfaccia o a quella procedura possono ribellarsi
a qualsiasi cambiamento; i tecnici che si devono occupare della gestione dei servizi
informatici possono opporre resistenza a nuove soluzioni tecniche, che comportano
il bisogno di aggiornare le proprie competenze; in generale, qualsiasi innovazione
comporta sempre delle reticenze, che possono essere giustificate solo nel caso
in cui si tratti del “solito software” che necessita di aggiornamento
(e quindi un cambiamento inevitabile, da accettare e basta).
Dal mio ragionamento emerge il fatto che i fattori DICRID (Diffidenza,
Inerzia, Certificazione, Responsabilità, Interazione, Dati) intervengono
e si intersecano in maniera ancora più fitta e intricata. Una azienda,
o un gruppo di professionisti, che desideri proporre una soluzione FLOSS,
deve riuscire a comprendere bene le varie “forze” che ostacolano qualsiasi
soluzione alternativa, prima ancora di preoccuparsi dei dettagli tecnici.
E' bene evidenziare i vantaggi strategici (a lungo termine) delle soluzioni FLOSS,
piuttosto che limitarsi agli aspetti tattici (a corto raggio), altrimenti qualsiasi
confronto è nullo.
Tecnicamente, infatti, le soluzioni FLOSS presentano enormi vantaggi, soprattutto nel caso di distribuzioni Linux non commerciali come Debian o Ubuntu: ciò che manca, semmai, è un vivaio di piccole e medie imprese informatiche in grado di fornire scelte basate su Linux e supportarle negli anni. Sono felice della strada intrapresa da Ubuntu perchè, rispetto a Debian, sta focalizzando l'attenzione sugli aspetti implementativi della vita di tutti i giorni, campo in cui gli sviluppatori Debian, per eccessivo amore della parte puramente “tecnica”, hanno volutamente curato con minori energie.
Come conclusione mi sento di dire questo: tecnologie aperte e software FLOSS sono una grande opportunità per le Pubbliche Amministrazioni, ma solo con una attenta analisi della situazione, e in particolare dei sei fattori da me evidenziati, è possibile formulare offerte e proporre soluzioni in grado di rivaleggiare con quelle esistenti (solitamente proprietarie). Sono altresì convinto che le soluzioni FLOSS rappresentino una nuova opportunità di guadagno, altrettanto invitante; è comunque comprensibile la titubanza dei responsabili di aziende software di fronte a modelli di business FLOSS, ancora poco conosciuti e poco apprezzati in terra nostrana.
Lancio, infine, una proposta (indipendente) per il nascente governo (proposta che difficilmente verrà anche solo letta): impostare una seria politica tecnologica a favore delle tecnologie FLOSS. Con la massa critica di migliaia di PA, uffici, scuole e università, i vantaggi rispetto a soluzioni proprietarie sarebbero enormi: risparmio di costi di licenza, suddivisione delle spese di sviluppo su migliaia di enti utilizzatori, formati di dati aperti per un vero interscambio, gestione remota dei backup, formazione continua condivisa. Se infatti sommiamo le cifre spese in formazione dai dipendenti pubblici, scopriamo facilmente che con la stessa cifra si riesce a produrre qualche film di Hollywood... oppure degli ottimi contenuti formativi condivisi in tutta Italia.
Purtroppo una trattazione approfondita è eccessiva per un articolo come
questo.
Rimango perciò a disposizione per commenti, domande, suggerimenti e critiche.
Licenza “Creative Commons Attribuzione-Non
commerciale-Condividi allo stesso modo 2.5 Italia License” rilasciato da
Simone Brunozzi (www.ubuntu.it
| www.simpler.it | simone.brunozzi
aT gmail.com).
UTILITA' E LINKS CORRELATI:
- Directory:
Open Source
- http://www.ubuntu.it/
- http://simpler.wordpress.com/
- http://www.nonovvio.it/
- http://www.punto-informatico.it/