Lo scenario

Acquisizione e riuso del software nella PA: dalla direttiva Stanca alle Linee guida Agid

Con la pubblicazione delle Linee guida sul riuso dei software nella PA, Agid ha prodotto un documento importante, dopo decenni di lavori e studi sul tema. Ora le modalità di approvvigionamento del software sono regolate con precisione, favorite anche da un contesto che supporta maggiormente il concetto di riuso

Pubblicato il 19 Giu 2019

Vincenzo Patruno

Data Manager e Open Data Expert - Istat

software

Con la pubblicazione delle “linee guida Agid sull’acquisizione e riuso del software nella Pubblica Amministrazione” si è mosso un passo importante. L’atteso documento offre tutta una serie di indicazioni alle PA sulle modalità con cui regolare l’approvvigionamento di software. Non si tratta del primo intervento normativo in materia, il tema iniziava a venire trattato già vent’anni fa. Lo scenario attuale offre spunti di riflessione sui cambiamenti sopraggiunti nella normativa e nelle tendenze amministrative.

La cultura amministrativa del riuso del software

L’idea che è alla base non è nuova, e si basa essenzialmente sul concetto di riuso del software. La cultura dell’openess ha ben chiaro che è molto più vantaggioso riusare e migliorare quello che già esiste piuttosto che partire ogni volta da un foglio bianco. E questo sia in termini di economicità che di efficienza. Un software necessita di tempo (e quindi del continuo rilascio di versioni successive) prima di raggiungere uno stadio che possiamo definire “maturo”. Poter disporre di un software già funzionante e poter partire da quello per fare manutenzione evolutiva e adattativa è sicuramente un grosso vantaggio.

La storia ci insegna che le PA, quando hanno necessità di avviare un progetto software lo fanno essenzialmente in modo “verticale”. Al fornitore verranno indicate una serie di specifiche e il fornitore provvederà a confezionare il software richiesto secondo il progetto richiesto. Se però andiamo a guardare più in dettaglio è piuttosto inconsueto che le pubbliche amministrazioni abbiamo esigenze molto diverse tra loro. Questo infatti accade piuttosto di rado. Le aree metropolitane,  i grandi comuni, le regioni e gli ambiti di loro competenza, pensiamo ad esempio a sanità e turismo, hanno essenzialmente bisogni piuttosto simili e (purtroppo) cercano spesso di soddisfare questi bisogni ogni volta attraverso software sviluppato “ad hoc”.

Ma una soluzione software sviluppata per una PA (nel momento in cui viene  rilasciata sotto una delle licenze Open disponibili) può benissimo essere riutilizzata da un’altra che ha gli stessi fabbisogni. Il riuso è un concetto sempre esistito nell’industria dei produttori di software.  L’industria del software ha da sempre riutilizzato software. E se in passato le componenti riusabili erano per la maggior parte quelle sviluppate all’interno dell’azienda o relative a software proprietari, al giorno d’oggi le aziende per confezionare nuovo software hanno a disposizione un patrimonio immenso di software open source a cui attingere, spesso contribuendo al loro miglioramento.

La direttiva Stanca

Sono passati quasi vent’anni da quando si è cominciato a parlare di software Open Source all’interno della Pubblica Amministrazione. E ci sono state delle “milestones” che vale la pena di ricordare. Voglio ricordare qui la Commissione Stanca sul software Open Source coordinata dal prof. Angelo Raffaele Meo, uno dei pionieri dell’informatica italiana (e non solo). Siamo  nel 2002 e tanti degli esperti coinvolti sono ancora nomi di primissimo piano all’interno del panorama nazionale dell’Innovazione. I lavori della commissione hanno fatto in modo che l’Italia fosse uno dei primissimi Paesi al mondo a disporre di una direttiva per l’Open Source nella Pubblica Amministrazione.

La direttiva Stanca ovviamente tocca vari punti, ma per la prima volta viene data un’indicazione che stabilisce l’obbligo per la PA  di inserire nei contratti per l’acquisizione di software una serie di clausole per favorirne il riuso. Una pubblica amministrazione prima di decidere di progettare un prodotto software verifica l’esistenza di un prodotto che magari abbia le stesse caratteristiche e sviluppato da un’altra pubblica amministrazione. In questo modo la pubblica amministrazione si dovrebbe far carico esclusivamente delle spese di “customizzazione” e del miglioramento del software esistente in quanto lo sviluppo è già stato pagato dall’amministrazione di provenienza. Quanto contenuto nella direttiva Stanca in termini di software Open Source, riuso e licenze verrà utilizzata come impalcatura per il CAD, il Codice dell’Amministrazione Digitale.

La commissione Nicolais

Qualche anno dopo precisamente nel 2007 è stata la volta della seconda commissione sul software Open Source nella Pubblica Amministrazione questa volta istituita dal ministro Nicolais e con a capo ancora una volta il prof. Meo. Questa volta ho avuto modo di partecipare direttamente ai lavori in quanto ero uno degli esperti membri della Commissione. Tra le varie cose di cui ci siamo occupati c’era ovviamente ancora una volta il tema del riuso del software da parte delle PA. Ora, c’è da dire che all’epoca era molto difficile fare in modo che i fornitori adottassero un approccio Open per il software sviluppato per una Pubblica Amministrazione.

C’era sicuramente un ostacolo di tipo culturale. Le aziende ponevano forti resistenze a seguire un discorso “Open” in quanto i modelli di business utilizzati erano essenzialmente basati sul generare “lock in” tra fornitore e cliente. Le PA  portavano quindi in casa soluzioni software proprietarie che quindi soltanto quel determinato fornitore aveva la possibilità di gestire e manutenere. Erano gli anni in cui erano cresciute in tutto il mondo (e anche in Italia) le comunità che spingevano per il Software Libero (FLOSS) e per il Copyleft e che invece questo modello di business volevano smontare.

A questo si aggiungeva un aspetto più pratico. Le modalità con cui il software veniva progettato e costruito erano poco adatte affinché il codice potesse essere condiviso per il riuso. Rendere disponibile come Open Source il codice di un software custom non concepito per essere condiviso, spesso non pacchettizzato e in cui dentro c’era di tutto, da librerie proprietarie a pezzi di “spaghetti code”  diventava un grosso problema. Di questo ne eravamo consapevoli. Quando durante i lavori della commissione parlavamo di riuso, sapevamo già che nella migliore delle ipotesi si sarebbe trattato del riuso del fornitore, e non del codice. Sono questi i motivi per cui il “Catalogo del Riuso” è stato disatteso.

Lo scenario attuale

Facciamo ora un salto nel tempo e arriviamo ai giorni d’oggi. Il CAD si è ulteriormente evoluto e con le “linee guida Agid sull’acquisizione e riuso del software nella Pubblica Amministrazione” vengono apportate ulteriori migliorie all’impianto normativo. Ma a mio avviso, la parte più interessante è che il contesto tecnologico è completamente diverso e oggi è sicuramente molto più favorevole al riuso del software.

Nelle aziende e tra gli sviluppatori di software è diventata prassi comune condividere il codice. I software sono diventati in generale più complessi, c’è un’abbondanza di framework e librerie Open per lo sviluppo di codice, si lavora in team “fluidi” di sviluppo spesso fisicamente distanti con modalità di lavoro “smart”. Piattaforme come GitHub, GitLab, Bitbucket sono dei repository di codice e fanno esattamente questo. L’effetto è simile a quello che si avrebbe nel momento in cui faccio venire degli ospiti a casa. Se sono disordinato mi preoccupo di rimettere in ordine prima che qualcuno entri. Quando si dà la possibilità a qualcuno di visionare il codice sviluppato allora lo si scrive meglio. Un codice di qualità diventa un codice che può essere condiviso, raccolta da altri, riusato e manutenuto. Per questo, la novità più interessante, oltre all’evoluzione dell’impianto normativo, è l’utilizzo di developers.italia.it  come piattaforma di riferimento per il software della PA. Un altro scalino, un altro pezzetto viene aggiunto al lungo percorso che si sta facendo sull’introduzione della cultura Open e di quella del riuso del software nella Pubblica Amministrazione. Mi auguro che su questo nuovo gradino possiamo salirci in tanti.

Valuta la qualità di questo articolo

La tua opinione è importante per noi!

EU Stories - La coesione innova l'Italia

Tutti
Iniziative
Video
Analisi
Iniziative
Parte la campagna di comunicazione COINS
Interviste
Marco De Giorgi (PCM): “Come comunicare le politiche di coesione”
Analisi
La politica di coesione europea: motore della transizione digitale in Italia
Politiche UE
Il dibattito sul futuro della Politica di Coesione
Mobilità Sostenibile
L’impatto dei fondi di coesione sul territorio: un’esperienza di monitoraggio civico
Iniziative
Digital transformation, l’Emilia-Romagna rilancia sulle comunità tematiche
Politiche ue
Fondi Coesione 2021-27: la “capacitazione amministrativa” aiuta a spenderli bene
Finanziamenti
Da BEI e Banca Sella 200 milioni di euro per sostenere l’innovazione di PMI e Mid-cap italiane
Analisi
Politiche di coesione Ue, il bilancio: cosa ci dice la relazione 2024
Politiche UE
Innovazione locale con i fondi di coesione: progetti di successo in Italia
Iniziative
Parte la campagna di comunicazione COINS
Interviste
Marco De Giorgi (PCM): “Come comunicare le politiche di coesione”
Analisi
La politica di coesione europea: motore della transizione digitale in Italia
Politiche UE
Il dibattito sul futuro della Politica di Coesione
Mobilità Sostenibile
L’impatto dei fondi di coesione sul territorio: un’esperienza di monitoraggio civico
Iniziative
Digital transformation, l’Emilia-Romagna rilancia sulle comunità tematiche
Politiche ue
Fondi Coesione 2021-27: la “capacitazione amministrativa” aiuta a spenderli bene
Finanziamenti
Da BEI e Banca Sella 200 milioni di euro per sostenere l’innovazione di PMI e Mid-cap italiane
Analisi
Politiche di coesione Ue, il bilancio: cosa ci dice la relazione 2024
Politiche UE
Innovazione locale con i fondi di coesione: progetti di successo in Italia

Articoli correlati