Una licenza Open Source garantisce i quattro diritti sul codice — eseguirlo, studiarlo, modificarlo, ridistribuirlo — ma non garantisce che qualcuno lo mantenga negli anni. È una distinzione ovvia per chi sviluppa, e la pubblica amministrazione la incontra nel momento esatto in cui passa dalla decisione di principio alla gestione quotidiana di un sistema.

Contesto

In Italia il quadro normativo è esplicito dal 2005. Il Codice dell’Amministrazione Digitale (D.Lgs. 7 marzo 2005, n. 82), in vigore dal 1° gennaio 2006, all’articolo 68 obbliga le amministrazioni a una valutazione comparativa fra le soluzioni disponibili prima di acquisire software: nel paniere rientrano il riuso di programmi già sviluppati da altre PA e il software libero o a codice sorgente aperto. Il legislatore dichiara il motivo: l’accesso al sorgente è la condizione per il riuso e per l’indipendenza dal singolo fornitore.

A livello europeo la cornice è il programma IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens), che ha prodotto fra l’altro la piattaforma OSOR.eu (Open Source Observatory and Repository): un registro e un ambiente collaborativo per il software prodotto da o per il settore pubblico. A inizio 2010 OSOR ospita oltre 135 progetti pubblicati da amministrazioni che li rendono riutilizzabili. IDABC si è chiuso il 31 dicembre 2009 e gli subentra ISA (Interoperability Solutions for European Public Administrations).

Scrivo dalla Toscana. T-OSSLab nasce nel febbraio 2008 da un protocollo fra Università di Pisa, Provincia di Pisa e Polo Tecnologico di Navacchio, come centro di competenza sul software libero. In questi mesi ha condotto un’indagine sull’uso dell’Open Source nei comuni toscani e ha avviato un catalogo dei prodotti che gli enti usano davvero.

Il problema

L’errore ricorrente è trattare l’adozione come un evento puntuale: si sceglie un applicativo libero, lo si installa, la pratica si chiude. Ma il software è un oggetto vivo. Le versioni delle dipendenze cambiano, escono aggiornamenti di sicurezza, l’ente modifica un processo e gli serve un campo in più, una nuova legge impone un tracciato di esportazione diverso.

Il diritto di modificare il codice, da solo, non risolve nessuno di questi casi. Li risolve chi sa leggere quel codice, applicare la patch, ricompilare, provare la regressione e rimettere in produzione senza interrompere il servizio. In un comune medio o piccolo questa competenza interna non c’è, e non c’è ragione perché ci sia: non è il suo mestiere.

Si apre così una distinzione che la sola etichetta «Open Source» nasconde. Un applicativo è libero per licenza ma, di fatto, può risultare non manutenibile: quando nessuno ne conosce l’architettura, quando manca la documentazione, quando a monte c’è un solo sviluppatore che ha smesso di rispondere. La licenza è condizione necessaria del riuso; la manutenibilità reale è un’altra cosa e dipende dalle persone.

L’architettura del sostegno

A colmare questo spazio è l’azienda specializzata. Non come fornitrice di una scatola chiusa, ma come soggetto che si assume per contratto un insieme di obblighi che il codice libero apre senza obbligare nessuno ad assolverli. Conviene elencarli per esteso, perché è qui che si separa l’adozione formale da quella sostenibile.

  • Manutenzione correttiva e adattiva: applicare le patch di sicurezza a monte, aggiornare le dipendenze, adeguarsi ai cambi normativi. È il lavoro che tiene il sistema in esercizio fra un rilascio e l’altro.
  • Integrazione: collegare l’applicativo al protocollo informatico, ai sistemi di pagamento, alle anagrafiche già presenti. Quasi nessuna installazione reale sta in piedi da sola.
  • Contributo a monte: le correzioni utili a tutti tornano al progetto originario, invece di restare in un fork privato che a ogni rilascio diverge un po’ di più. Qui la convenienza è tecnica, non solo etica: un fork che diverge è un debito che cresce.
  • Formazione e trasferimento: il personale dell’ente impara a usare e, dove ha senso, a presidiare il sistema, riducendo la dipendenza dal singolo fornitore — proprio ciò che una licenza libera lascia fare e che un contratto su software chiuso preclude.

Un catalogo dei prodotti Open Source assistiti, come quello avviato in Toscana, serve esattamente a questo. Non è un elenco di software disponibile — quello lo offre già una qualunque distribuzione — ma una mappa di chi, sul territorio, garantisce le quattro voci qui sopra per un dato applicativo.

Il punto critico

La sostenibilità non si compra con una licenza, si costruisce con un mercato di competenze. Una pluralità di aziende capaci di intervenire sullo stesso codice è la garanzia concreta che l’indipendenza dal fornitore, scritta nelle premesse dell’articolo 68, sia reale e non solo nominale. Se un solo soggetto al mondo sa mettere mano a quel sorgente, l’ente ne dipende quanto dipenderebbe da un produttore di software proprietario — con una differenza che non è da poco: il diritto di rivolgersi a un altro resta, almeno sulla carta.

La conseguenza pratica è che la valutazione comparativa prevista dalla norma non dovrebbe fermarsi alla licenza e alle funzionalità. Dovrebbe pesare lo stato della comunità a monte (un mantenitore o trenta), la presenza di più fornitori in grado di intervenire, la storia dei rilasci. Sono dati verificabili: la frequenza dei commit, il numero di contributori distinti e la cadenza delle release sono pubblici per qualunque progetto ospitato su una forge.

Implicazioni

Per la PA il criterio di scelta si sposta dal prodotto al suo ecosistema. Un applicativo libero con un solo mantenitore e nessun fornitore locale è, per un ente che deve garantire continuità di servizio, più fragile di un applicativo con comunità attiva e tre aziende in grado di assisterlo, anche a parità di funzioni.

Per le aziende il modello sostenibile è il servizio continuativo, non la vendita una tantum di licenze, che il codice libero comunque non consente. Il contributo a monte, qui, è un investimento: tenere la versione installata dai clienti vicina a quella ufficiale abbassa il costo di ogni aggiornamento futuro.

Limiti

Quanto sopra descrive un meccanismo, non garantisce un esito. Un mercato di competenze locali non nasce per decreto e non è uniforme sul territorio: dove le aziende specializzate mancano, la facoltà di rivolgersi a un altro fornitore resta teorica. La frequenza dei commit misura l’attività, non la qualità del codice né l’affidabilità di chi lo manutiene. E l’indagine condotta in Toscana fotografa un campione regionale in un dato momento: serve a orientarsi, non a generalizzare oltre il suo perimetro. Sono punti da verificare caso per caso, non da dare per scontati.

Il ruolo delle aziende nel sostenere l’Open Source adottato dalla PA è il tema dell’intervento che noze porta alla giornata T-OSSLab di Pisa, documentato nell’insight relativo: https://www.noze.it/insights/tosslab-contributo-aziende-open-source/.

https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2005-03-07;82 http://www.osor.eu/ http://ec.europa.eu/idabc/ https://opensource.org/docs/osd http://www.tosslab.it

Immagine di copertina: Renzo Davoli durante un intervento al Linux Day 2010 a Bologna — foto di Davide Alberani, CC BY-SA 2.0 — https://commons.wikimedia.org/wiki/File:LinuxDay_2010_ERLUG_CNR_-_Renzo_Davoli.jpg