Open source nella PA: ecco gli utilizzi e gli obiettivi

Nella PA l’open source è ancora considerato una novità, il cui uso è già stata trattato in documenti come le Linee guida Agid su acquisizione e riuso dei software. Standardizzazione, nerworking e soluzioni condivise sono solo alcuni degli obiettivi dell’opensource: aspetti utili da approfondire.

Open source: vi sembra un concetto ormai scontato? Ricredetevi: c’è un posto al mondo in cui pronunciare queste due paroline assieme vi farà ancora apparire incredibilmente pionieristici. La PA (italiana). Alcuni persino, lì dentro, all’udire le due magiche parole vi guarderanno come personaggi di un film di fantascienza.

Già, l’open source nella PA sembra una cosa assolutamente nuova, sebbene sia una tendenza che anche in questo settore si sta sviluppando in tutta Europa.

Se ne è parlato per diversi anni fino ad arrivare al catalogo del riuso presente su Developers Italia e alle Linee Guida su acquisizione e riuso del software nella PA di Agid (che contiene già come allegati tecnici dei moduli da inserire nei bandi di gara: assoluta novità che semplifica il lavoro della PA e dei fornitori nel procurement, creando standard).

Allora, vogliamo finalmente far pace tra open source e pubblica amministrazione italiana? Non è mica fantascienza, no: impariamo come declinare questo concetto nella realtà di tutti i giorni della PA.

Opensource nella quotidianità della PA

Prima di tutto va fatta una distinzione tra acquisizione di un software e commissione di un nuovo software. Nel primo caso si acquista un software esistente, già utilizzato dalla PA, mentre nel secondo caso si commissiona un software nuovo.

L’acquisizione di software

La prima cosa da fare quando si acquisice un software, è vedere se c’è un equivalente nel catalogo del riuso. Se c’è, va verificato se ha i requisiti richiesti: se si, potrebbe essere il prodotto che fa per noi, se no, allora si può procedere all’acquisizione. A questo punto ci si domanda: devo acquisire un software open per legge? Se la risposta fosse si, questo sembrerebbe la killer-app per tutte quelle software house che fanno da fornitori e fanno business con la PA, vendendo la loro suite di gestione (anagrafe, ragioneria, tributi …). Infatti sembra che tutti debbano rendere aperto il loro codice, trasformando anni di investimenti in risorse economiche e non, in un codice aperto e che tutti possono copiare (ma a cui del resto tutti possono contribuire). La preoccupazione è lecita: se oggi rendo il mio codice open, diventa “proprietà della comunità” e quindi altri possono contribuirvi e/o copiarlo (secondo la licenza che viene specifica). In verità non è esattamente così: l’open non è la killer-app. Le software house più grandi fornitrici della PAL hanno impiegato risorse economiche e non per realizzare i loro software e negli ultimi anni sono passati dalla vendita di un prodotto (il software) alla vendita di un servizio (il software è gratuito, ma vanno comprati: installazione, avvio, manutenzione, aggiornamenti, assistenza, etc etc).

Quindi il software open prosegue in parte questo percorso: il valore aggiunto non è più il prodotto, ma il servizio associato. Per cui rendere il proprio codice libero, rende il know how più condivisibile e forse vulnerabile, ma d’altra parte rende comunque necessarie le operazioni di installazione, manutenzione, aggiornamento…di cui si parlava sopra, che è difficile acquistare da altri fornitori. Gare Consip docet: in queste si poteva acquistare l’assistenza su dei prodotto dalla software house A riferiti al software della software house B. Sarei curioso di sapere quanti acquisti ci sono stati, per capire se il modello ha una sua fattibilità oppure no, basandomi sui dati. Per l’esperienza che ho, direi che è un modello difficilmente praticabile. Proseguendo il discorso, in ogni progetto open ci deve essere un regista che decide se la pull request (la richiesta di modifica o aggiunta funzionalità) o la issue (problema o considerazione) vanno valutati, e questa non può che essere la software house realizzativa. Infine, capire un codice aperto da 10 o 100 milioni di linee di codice, non è proprio una cosa immediata, anche se forse fattibile per alcuni colossi che volendo potrebbero affacciarsi al mondo PAL sfruttando questa occasione di apertura dei codici.

Comunque sia, riassumendo, non è l’acquisizione il target del movimento opensource nella PA e chi ha investito diverse migliaia di euro per fare una suite che il mercato ha accettato (ovvero ha diverse decine di clienti) può dormire sonni tranquilli, almeno per il momento. Questo perché tipicamente il software che fa parte dell’area “acquisizione” è un software largamente diffuso e utilizzato da alcune decine o centinaia di enti, quindi un prodotto che segue cicli di sviluppo, stabile e largamente utilizzato. Non si inventa niente di nuovo, semplicemente si prende qualcosa che il mercato ha già riconosciuto come una possibile soluzione ai suoi problemi o come strumento per erogare i suoi servizi. In un’ottica di mercato e senza sprechi economici particolari. La battaglia quindi dei fornitori che forniscono software acquisito ovvero acquistato e non commissionato, rimane sulla qualità della soluzione. Non sull’open o meno.

Commissione di un nuovo software

Qui l’open è padrone. L’obiettivo principale è “evitare di reinventare la ruota”. Mi spiego meglio: l’ente A commissiona il software S1 per la intranet all’azienda X. Dopodichè non lo mette a riuso. L’ente B allora commissiona il software S2 per la intranet all’azienda Y. E non lo mette a riuso. E così via. Alla fine quindi ci troveremo con un gran numero di software di intranet, tutti diversi (nessuna standardizzazione), tutti poco usati (da 1 ente, massimo una decina, magari gli enti vicini geograficamente all’ente che l’ha commissionato; oppure magari un centinaio se il software è commissionato da una provincia o una regione), tutti acquistati con soldi pubblici (quindi con spreco di soldi pubblici che in maniera poco efficiente vengono spesi per costruire lo stesso software e affrontare gli stessi problemi facendo gli stessi errori). Non è detto infine che le 8.000 intranet siano tutte di buona qualità.

Nel nuovo modello open, se voglio commissionare un software prima verifico se c’è a riuso (quindi l’ente B troverà il software dell’ente A), evitando duplicazioni o simili. Se poi non ha tutte le funzionalità di cui ho bisogno, dovrei prima di tutto interrogarmi del perchè ho bisogno di funzionalità che un altro ente non ha e se ne ho davvero bisogno. Se la risposta è si, allora posso motivare il non utilizzo del catalogo del riuso ad Agid e quindi procedere ad un’acquisizione che poi dovrà essere messa in riuso.

Gli obiettivi dell’opensource

Gli scopi quindi dell’opensource sono permettere di:

• Avere un catalogo dove poter cercare soluzioni condivise, senza dover reinventare la ruota. Se cerco una soluzione per il servizio Intranet, posso cercare nel catalogo del riuso. Se lo trovo, posso provare ad usare quel prodotto, facendo riferimento alla PAL che l’ha messo a riuso per chiarimenti su come l’hanno utilizzato e facendo riferimento al contractor (il fornitore) per le fasi di installazione, assistenza, manutenzione, aggiornamenti, etc etc;
• Fare rete. Mano a mano che il catalogo cresce, come PAL, potrò avere una visione completa di quanto è stato commissionato dalla PA come sviluppi, e quindi fare rete con chi usa il mio stesso prodotto, aumentando la condivisione di informazioni, i rapporti ed eventualmente portando a condivisioni di costi per nuove funzionalità o modifiche,con sinergie organizzative ed economiche.
• Standardizzare. Se ogni PAL fa la sua intranet, avremo ad esempio 8.000 intranet una per comune. Se tutti fanno riuso, ne avremo (nel caso migliore) 1 per tutti gli 8.000 enti. Questo crea una standardizzazione degli strumenti (per cui se un dipendente si sposta da un comune all’altro, trova gli stessi strumenti ovvero la stessa intranet).
• Economicità. La PA evita di commissionare più volte gli stessi prodotti. Perlomeno prima di farlo è prevista una riflessione dovuta al CAD .
• Trasparenza. Si forma un catalogo dei software commissionati, che permette anche un monitoraggio dell’operatività delle PA a tutti i livelli.
• Cultura. Inizia un percorso di condivisione di soluzioni, di competenza, di esperienze che è fondamentale si crei nella PA se la PA vuole accelerare il suo percorso di crescita digitale.
• Qualità. Visto che il prodotto diventerà open, potrà essere messo anche a pubblico “ludibrio”. Questo dovrebbe spingere a fare software di maggiore qualità, considerando anche la prospettiva di metterlo nel catalogo del riuso. Ipotizzando ad esempio che la prima intranet messa a riuso sia di bassa qualità e la seconda di alta, è chiaro che tutti sceglieranno la seconda.

Si tratta quindi di un percorso molto interessante intrapreso dalla PA, probabilmente ancora di valore solo per gli early adopter, ma dai numerosi risolvi tecnici, economici e di business che riguardano anche i fornitori.

Come mettere a riuso un software

Le operazioni per chi è programmatore sono semplici:

• si crea un account (ad esempio) github
• si crea un’organizzazione per la PAL, esempio “Comune di Rocca Cannuccia”
• si carica il codice
• si fa un README.md per dire di cosa si trattaq
• si fa un publiccode.yml in modo che i motori del catalogo del riuso possano individuare il codice e metterlo in indice (mediante l’editor messo a disposizione dal Team Digitale)
• si esegue la procedura di onboarding
• si aspetta l’email per confermare l’indicizzazione in 24–48 ore
• il codice dovrebbe essere indicizzato in 24–48 ore

Il contesto normativo

Le leggi che governano questo percorso, per chi volesse approfondire, sono:

• Articolo 68 Cad: in caso di acquisizione di un nuovo software, una PA deve prima verificare se può utilizzare del software in riuso e contemporaneamente fare una valutazione comparativa tra software in riuso (se presente) e software a mercato.
• Articolo 69 Cad: una PA che commissiona un software ha obbligo di rilasciarlo in formato opensource. Tale norma è retroattiva.