Open Software e Pubblica Amministrazione: online le linee guida sull’acquisizione e il riuso del software

Le norme italiane sono tra le più avanzate d’Europa in materia di open source. Lavoriamo per farle funzionare.

This post is available also in English

Oggi è un momento importante per noi: sono disponibili per la consultazione pubblica le nuove “Linee Guida sull’Acquisizione e Riuso del Software”, frutto di una stretta e proficua collaborazione tra il Team per la Trasformazione Digitale e l’Agenzia per l’Italia Digitale (AgID).

È un documento in cui delineiamo i nuovi processi che, a norma di legge, tutte le pubbliche amministrazioni dovranno seguire quando si apprestano ad acquisire o commissionare lo sviluppo di un software e successivamente per metterlo a disposizione di altre amministrazioni in modo gratuito, tramite il meccanismo di pubblicazione in open source.

Iker Urteaga su Unsplash

Una legge avanzata sul riuso del software

A dispetto della scarsa diffusione del riuso del software, in Italia abbiamo oggi una delle leggi più avanzate d’Europa in materia di open source all’interno della Pubblica Amministrazione, finalizzata alla condivisione del software e al risparmio della spesa pubblica.

Come Team Digitale abbiamo infatti lavorato con il Ministero della Funzione Pubblica per migliorare il Codice per l’Amministrazione Digitale, un processo durato mesi e che si è concluso con l’approvazione finale del Consiglio dei Ministri lo scorso dicembre. All’interno di questa operazione siamo anche intervenuti sugli articoli che regolano le modalità con cui le amministrazioni acquisiscono il software e lo mettono a disposizione tra loro.

Tutte le amministrazioni erano da tempo obbligate a rilasciare tutto il codice di loro proprietà sotto una licenza libera, mettendolo gratuitamente a disposizione di altre amministrazioni che avessero voluto personalizzarlo e utilizzarlo. Infatti, già dal 2005, l’articolo 69 del Codice per l’Amministrazione Digitale, al comma 2, indicava in modo chiaro l’obbligo di “rendere disponibile il […] codice sorgente, completo della documentazione e rilasciato in repertorio pubblico sotto licenza aperta, in uso gratuito ad altre pubbliche amministrazioni o ai soggetti giuridici che intendano adattarli alle proprie esigenze”.

Di fatto, però, la norma era inapplicata, poiché mancavano le procedure e gli strumenti. Era necessario innanzitutto creare un documento che spiegasse nel dettaglio i processi da seguire: le Linee Guida appunto, che pubblichiamo assieme ad AgID oggi per la prima volta, sollecitando commenti e miglioramenti da parte di tutta la community di Developers Italia ma anche di coloro che hanno a cuore questa materia.

Inoltre, nell’ambito delle stesse Linee Guida, abbiamo anche disciplinato il processo di valutazione comparativa che le amministrazioni devono svolgere prima di acquisire un software, semplificando le precedenti indicazioni e ribadendo la priorità all’adozione ed evoluzione di software a riuso.

Vediamo quindi il contesto in cui stiamo operando oggi e perché pensiamo che questo possa essere davvero un punto di svolta.

La spesa per il software pubblico

La Pubblica Amministrazione italiana spende centinaia di milioni di euro per l’esecuzione di progetti legati al mondo del software. Sebbene sia difficile estrarre un dato preciso, per citare un esempio, la rilevazione compiuta da AgID, nell’ambito del lavoro fatto per il Piano Triennale, ha censito 621 milioni di euro di spesa nel triennio 2013–2015 effettuata da una ventina di grosse amministrazioni centrali (ministeri ed enti)*.

Questo costo è in larga parte speso per la creazione di nuovi progetti software, che vengono realizzati ogni volta da zero. Sebbene alcuni applicativi, per loro stessa natura, rappresentino un unicum nel panorama nazionale (si pensi per esempio all’anagrafe centrale ANPR, o al sistema fiscale dell’Agenzia delle Entrate), è facile immaginare quali ingenti risparmi si possano ottenere cercando di “fare sistema” tra più amministrazioni, condividendo gli sforzi e gli investimenti fatti. Invece le amministrazioni tra loro comunicano poco e in maniera non strutturata, e difficilmente due grandi città arrivano a scambiarsi il software che hanno acquisito.

Il “riuso del software” (così viene chiamato il meccanismo di condivisione del software dentro la pubblica amministrazione) è a oggi praticamente nullo.

Open source come processo virtuoso

Il mondo dell’industria si è invece da tempo allineato sull’utilizzo dell’open source come meccanismo per costruire un valore incrementale del software. Invece che cominciare ogni volta a scrivere un programma da zero, tutti i grossi nomi del software mondiale attingono a piene mani dalla vastissima scelta di componenti e semi-lavorati disponibili su piattaforme quali GitHub, e ne rilasciano a loro volta in grandi quantità, in modo che lo sviluppo su di essi possa essere portato avanti in modo collaborativo, beneficiando reciprocamente dei miglioramenti.

Markus Spiske su Unsplash

È il modello che abbiamo scelto in Developers Italia e che vi abbiamo già raccontato: creare e pubblicare sotto licenza aperta componenti già pronti, nel nostro caso per aiutare nell’integrazione delle piattaforme abilitanti del Sistema Operativo del Paese quali SPID e PagoPA; un processo in cui chiunque può contribuire, come successo durante Hack.Developers. Durante questo hackathon, da noi organizzato lo scorso settembre, più di 800 sviluppatori si sono riuniti e hanno creato codice che già oggi viene utilizzato dalle software house per realizzare servizi pubblici di nuova generazione.

Con le Linee Guida in consultazione allarghiamo questo modello: le amministrazioni potranno (e dovranno) pubblicare in Developers Italia tutto il software di loro proprietà acquisito negli anni passati e che acquisiranno d’ora in avanti, scegliere una licenza aperta tra quelle certificate da Open Source Initiative, e seguire le Guide Tecniche contenenti tutti i dettagli sulle procedure che abbiamo allegato alle Linee Guida e che verranno aggiornate con regolarità.

Per tutti i nuovi appalti per la realizzazione di software, le Linee Guida ribadiscono alle amministrazioni di acquisire sempre la piena titolarità del software che viene sviluppato, di allegare le Guide Tecniche ai capitolati di gara, incaricando così il fornitore stesso, nell’ambito dell’appalto, di effettuare il rilascio e il mantenimento in open source. In caso di appalto, viene quindi ribaltato sul fornitore l’onere di seguire nel dettaglio tutto il processo tecnico per pubblicare e mantenere in open source il software in modo impeccabile, mettendolo pienamente a disposizione delle altre amministrazioni.

I vantaggi di riutilizzare il software tramite l’open source

Pensate a tutti i vantaggi della creazione di un vero e proprio patrimonio di software open source della pubblica amministrazione.

• Risparmio: ripetiamolo, perché spendere due volte per fare la stessa cosa?
• Miglioramento incrementale: invece che iniziare da zero, le amministrazioni potranno (e dovranno) valutare prima un software open source esistente, e valutare se sia sufficiente personalizzarlo ed evolverlo per adattarlo alle proprie esigenze. In questo modo, il patrimonio pubblico di software verrà costantemente aggiornato e ampliato.
• Condivisione della spesa: se tante amministrazioni condividono il medesimo software, perché non accordarsi e dividersi per esempio i costi di manutenzione? O magari armonizzare le richieste di nuove funzionalità, in modo da realizzarle in modo che siano utili a tutti. Tutto questo sarà finalmente possibile.
• Accountability del fornitore: l’amministrazione potrà ispezionare il codice sorgente del software mentre viene scritto, potendo fare così un auditing sulla qualità del lavoro svolto.
• Trasparenza verso i cittadini: secondo i principi di Open Government, tutti potranno vedere il software che è stato sviluppato e studiarne il funzionamento. I tecnici potranno fare segnalazioni su anomalie e malfunzionamenti, o addirittura aiutare, per esempio, il proprio comune, intervenendo con un miglioramento in modo volontario.
• Formazione: studenti di università e licei potranno studiare il codice sorgente che crea i servizi che usano tutti i giorni, imparando “sul campo” le tecnologie più usate e acquisendo importanti competenze digitali nella Pubblica Amministrazione. Gli atenei potranno offrire progetti di tesi sul codice pubblico, collaborando in modo diretto a migliorare la vita di tutti i cittadini.
• Sicurezza: fermo restando che anche un sistema proprietario può offrire idonee garanzie di sicurezza, grazie all’uso dell’open source, sarà più facile ed economico fare degli importanti auditing sui problemi di sicurezza, potendo anche effettuare scansioni massive di tutto il software pubblico. Si pensi per esempio a tutti i centri di ricerca universitari che potranno aiutare nel segnalare criticità potenziali o effettive come esito dei loro studi.
• Creazione di un mercato di servizi per le PMI: il software open source non sarà certo pronto all’uso, perché come tutti i software scritti su misura, avrà sempre bisogno di personalizzazione, installazioni, formazione. Ma poiché il software è libero, chiunque potrà studiarlo, approfondirne la conoscenza, e mettersi a disposizione delle amministrazioni con i propri servizi. Per facilitare l’incrocio di domanda e offerta, stiamo valutando di integrare Developers Italia con il MEPA di Consip (la piattaforma principale per gli acquisti della Pubblica Amministrazione).

Aiutaci a realizzare questa visione

Se sei un amministratore pubblico e ti occupi di software e ICT, abbiamo bisogno del tuo aiuto per fare in modo che queste Linee Guida siano davvero utili e ti aiutino nel tuo lavoro senza ostacolarti. È questo il momento giusto per dirci se e dove abbiamo sbagliato: leggi il testo e scrivi cosa ne pensi sulla sezione dedicata nel Forum Italia.

Se sei un addetto ai lavori come un professionista o un imprenditore del mondo del software, i tuoi consigli saranno preziosi per migliorare il testo delle Linee Guida; leggi anche con attenzione gli allegati tecnici, nei quali descriviamo con precisione gli interventi da fare sul codice sorgente e sulla documentazione.

Se sei un cittadino appassionato di questo tema, e quanto abbiamo scritto ti ha colpito e vorresti fare in modo che possa tutto diventare vero, abbiamo bisogno anche del tuo aiuto. Leggi anche tu le Linee Guida. Ti ci vorrà un po’ di tempo: sono circa 50 pagine, e se non sei già familiare con il mondo della Pubblica Amministrazione qualche passaggio potrà risultarti più difficile. Se riesci, trova il tempo per leggerle con calma e attenzione, rifletti sui passaggi, e facci avere anche la tua opinione.

Qualche nota tecnica

La visione che ci ha guidato è stata quella di rendere l’ecosistema software della pubblica amministrazione quanto più vicino possibile a quello di una community open source: un ecosistema di piccole e grandi imprese e una community di hacker pubblici che finalmente possono cooperare per innovare il paese, a partire dalle sue fondamenta digitali. A beneficio di questi lettori più tecnici, offriamo un assaggio di ciò che è contenuto nelle Linee Guida in consultazione, allo scopo di incuriosirvi e incentivare suggerimenti e contributi.

Per realizzare i nostri obiettivi, il primo strumento essenziale è la scelta della licenza, che incoraggi contributi e riutilizzo. Pur decidendo di lasciare le amministrazioni libere di scegliere una qualunque licenza (purché certificata da OSI come licenza open-source), abbiamo voluto anche preparare un albero di scelta consigliato, per aiutare nella scelta le amministrazioni convergendo su poche licenze, semplificando così il riuso. Abbiamo scelto EUPL e AGPLv3 per tutti i software di tipo applicativo, BSD per librerie e SDK, e CC-BY per documentazione ed esempi di codice. Crediamo che questo sia il modo migliore per garantire a tutti i cittadini che il software commissionato dalle Pubbliche Amministrazioni rimanga aperto e a beneficio di tutti.

Una buona licenza senza strumenti e modelli di collaborazione sarebbe però inutile alla costruzione di un vero ecosistema di sviluppo aperto. Ogni pubblica amministrazione dovrà perciò eleggere (e rendere indicizzabile) la propria piattaforma di code hosting, scegliendola tra quelle che già possiedono caratteristiche tali da consentire lo sviluppo collaborativo e aperto di un software. In altre parole, le piattaforme più note, e rigorosamente con registrazione pubblica, quindi: GitHub, Gitlab, BitBucket, Phabricator, Gitea, Gogs, …

Ogni repository sarà censito e indicizzato attraverso un file YAML di metadati: publiccode.yml (formato in sviluppo nell’ambito di una comunità europea di addetti ai lavori), che qualunque progetto open source potrà adottare, e permetterà di creare un motore di ricerca di tutto il software a riuso delle pubbliche amministrazioni. Un motore di ricerca, sviluppato come parte di Developers Italia, si occuperà di ricercare ed indicizzare questi file, offrendo così un catalogo di software a riuso disponibile per le amministrazioni, semplice da consultare, ed esposto in open data con API documentate per chiunque vorrà effettuare analisi e studi.

Abbiamo anche dato alcune indicazioni di dettaglio per favorire un sistema di collaborazione per evolvere in modo condiviso la base di codice:

• Tutti i software dovranno contenere istruzioni tecniche per l’installazione e la configurazione chiare, ove possibile fornendo strumenti di deploy automatizzati: ad esempio Makefile, Dockerfile, playbook Ansible o CMakeLists.txt, in modo che sia semplice provare e valutare un software.
• La documentazione dovrà essere distribuita in formato aperto e tracciabile nella sua evoluzione, utilizzando sistemi come Doxygen, Readthedocs, Markdown o LaTeX.
• Tramite una guida pronta all’uso, da allegare per esempio ai capitolati di gara, le amministrazioni indicheranno alle software house come effettuare una manutenzione che includa anche il ruolo di maintainer Open Source di un software: rispondere alle segnalazioni e valutare i miglioramenti e le evoluzioni tecnologiche (pull request) che arrivano da altre amministrazioni (o da terzi).
• Sempre tramite una guida allegabile ai capitolati di gara, le amministrazioni indicheranno alle software house come modificare un software aperto di terze parti, cercando per quanto possibile di allinearsi alla versione principale e contribuendo le modifiche al ramo di sviluppo principale (ovvero senza creare fork).

Così come abbiamo descritto nelle migliori pratiche, anche lo sviluppo sulle linee guida in consultazione è aperto. I sorgenti sono infatti su GitHub: Aiuta a migliorare il testo definitivo con interventi sul forum e, perché no, magari invia anche una pull request ;-)

Per i più tecnici tra voi che vogliano approfondire, vi consigliamo di guardare il nostro talk a FOSDEM 2018

Note

*Il dato riguarda l’aggregato dei costi sostenuti per i progetti censiti nelle tipologie “Infrastrutture Immateriali” e “Ecosistemi”, che si riferiscono a progetti afferenti la sfera del “software”.

Lavora con noi | Seguici su Twitter e LinkedIn | Visita il nostro sito | GitHub