La PA italiana diffida del software aperto

La PA italiana diffida del software aperto

di S. Brunozzi - Cosa impedisce alla PA di adottare soluzioni libere? Tra resistenze culturali e update tecnologici le imprese del codice aperto devono imparare ad avvicinare la PA nel modo migliore
di S. Brunozzi - Cosa impedisce alla PA di adottare soluzioni libere? Tra resistenze culturali e update tecnologici le imprese del codice aperto devono imparare ad avvicinare la PA nel modo migliore

Roma – Nell’ambito della Pubblica Amministrazione (PA), il 2006 sembrava essere l’anno del “grande salto in 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 intervengano 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à in uso, 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 diverse 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 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.
È 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.

Simone Brunozzi
www.ubuntu.it

(simone.brunozzi aTt gmail.com)

Questo articolo è rilasciato sotto licenza Creative Commons “Creative Commons Attribuzione-StessaLicenza 2.5 Italy License

Nota: Il sito ufficiale di Ubuntu è qui

Link copiato negli appunti

Ti potrebbe interessare

Pubblicato il
17 mag 2006
Link copiato negli appunti