di Emidio Picariello.
foto: Yohann Legrand
Nell’articolo precedente abbiamo parlato di come la diffusione dell’Open Source nella pubblica amministrazione, per quanto riguardala produttività individuale, trovi ancora degli ostacoli. Quando si parlava di postazioni di lavoro con sistemi operativi mutuati da Linux – Ubuntu su tutti, per esempio – si è notato come ci sia spesso un problema di compatibilità con gli applicativi quotidianamente utilizzati dai dipendenti dell’ente. Per esempio in un Comune ci sono software per la gestione dell’Anagrafe Pubblica o per la gestione delle elezioni o per la gestione dell’emissione di Certificati. Questi software spesso sono compatibili solo con Windows. A volte gli enti si trovano a rinnovare questi software che sono diventati obsoleti e hanno bisogno di una radicale riprogettazione. Con questo articolo cerchiamo di comprendere quali possono essere delle soluzioni di riprograttazione economicamente vantaggiose per l’ente.
Nel caso della necessità di riprogettare un software esistente o di crearne uno per coprire una funzione scoperta, le aziende e gli enti hanno due strade: quella della software selection, ovvero quella della ricerca sul mercato di un prodotto che soddisfi l’esigenza o quella della progettazione interna.
Il primo caso è stato percorso più e più volte. Spesso è necessario aggiudicare – per la portata del progetto – il lavoro con una gara. Come in altri campi, per aggiudicarsi gli enti più interessanti, le aziende fanno offerte che poi faticano a mantenere, sia da un punto di vista economico che tecnologico. Nella migliore delle ipotesi ci si lega molto strettamente a un fonitore, al quale spesso si affida un ganglio vitale della vita dell’ente. Se il software non funziona correttamente diventa impossibile – fisicamente impossibile, al giorno d’oggi – svolgere certe funzioni. Questa pratica, per quanto diffusa, è necessaria soprattutto negli enti piccoli che non hanno le risorse umane per sviluppare internamente i progetti. Migliore invece è la soluzione della software selection fra i software che gli altri enti hanno messo a riuso. Questa soluzione si rivela – quando praticabile – una delle migliori per diversi motivi: il software è testato da un ente che ha esigenze simili, è una delle meno onerose per l’ente che acquisisce il software, favorisce lo scambio di buone pratiche fra gli enti.
Ma questa possibilità, per essere possibile ha a monte una situazione del secondo tipo: un ente ha avuto bisogno di un software, non ne ha trovati che facessero al caso suo e l’ha dovuto progettare. Nel progettarlo ha utilizzato strumenti open source così che adesso può cederlo a un altro ente senza violare nessuna licenza.
Nel progettare un software internamente si dovrebbero sempre utilizzare strumenti aperti: oggi non c’è nessuna scusa per non farlo: il PHP e il Java sono linguaggi di programmazione evouti e completi, che creano applicazioni orientate al web – quindi utilizzabili da tutti i posti di lavoro, con qualunque sistema operativo, tramite browser e anche pronte per esporre servizi direttamente al cittadino – solide e che possono durare nel tempo se progettate adeguatamente.
Ma anche la progettazione interna non è tutta rose e fiori, anche se da questa breve analisi emerge come una delle soluzioni migliori. Innanzi tutto, anche nelle strutture tecnologiche degli enti più grandi, non tutti i dipendenti padroneggiano gli strumenti open source. Mettere insieme un team omogeneo non sempre è facile. La selezione del personale infatti non è così specifica: mentre un’azienda può assumere un programmatore PHP, un ente pubblico può selezionare per concorso un tecnico preparato, ma difficilmente può entrare così a fondo nel dettaglio delle sue conoscenze.
Per poter sviluppare un buon software inoltre, non è sufficiente una buona squadra di analisti e di programmatori, servono anche degli utenti che siano in grado di dare le giuste indicazioni. La progettazione del software ben fatta prevede un periodo di confronto con gli utenti – anche tramite quella che tecnicamente viene chiamata progettazione UML e che corrisponde al disegno tecnico nella costruzione di una infrastruttura, per intendersi – e che ha bisogno di interlocutori che siano in grado di esporre le proprie esigenze in modo chiaro e concludente. Spesso questo passaggio è molto difficile.
Quindi la migliore delle ipotesi è riuscire a progettare internamente un buon software con strumenti open source e metterlo a riuso per gli altri enti, in subordine utilizzare il software messo a riuso è una buona cosa. In mancanza di queste possibilità si può acquistare il software, sempre cercando applicazioni scritte con linguaggi open soure e fruibili via web. L’ipotesi di progettare – o comprare – applicazioni scritte in linguaggi proprietari e/o non utilizzabili con il browser ci pare a oggi francamente strategicamente perdente oltre che anacronistica.iMille.org – Direttore Raoul Minetti
