La tesi in breve

Ogni amministrazione compra e produce software. Se il codice resta chiuso, l'ente paga per usarlo ma spesso non può verificare come funziona, correggerlo, trasferirlo a un altro fornitore o riutilizzarlo altrove. Se il software è aperto e costruito su standard aperti, il valore dell'investimento può invece essere condiviso tra più uffici, enti e territori.

L'opportunità non consiste nel sostituire ogni prodotto proprietario con un'alternativa open source. Consiste nel cambiare il criterio di decisione:

  • valutare sempre il costo totale di possesso, non solo il prezzo della licenza;
  • preferire riuso, interoperabilità e portabilità quando offrono un risultato equivalente;
  • comprare servizi professionali — analisi, migrazione, integrazione, supporto e sicurezza — senza comprare una dipendenza permanente;
  • pubblicare il codice sviluppato con denaro pubblico in modo riusabile, documentato e sicuro;
  • finanziare la manutenzione comune, perché un repository abbandonato non è sovranità.

La domanda guida: quale combinazione di codice, dati, standard, persone e fornitori garantisce il miglior servizio pubblico nel tempo, con il minor costo totale e una vera possibilità di cambiare strada?

Che cosa significa “sovranità software”

La sovranità digitale non significa fare tutto in casa né rifiutare i fornitori privati. Significa che l'amministrazione conserva la capacità di decidere, controllare e cambiare.

In concreto, un ente è più sovrano quando può:

  • accedere al codice sorgente e alla documentazione;
  • esportare dati e configurazioni in formati aperti;
  • usare API e protocolli documentati per collegare sistemi diversi;
  • affidare manutenzione e gestione a più operatori qualificati;
  • correggere, aggiornare o far migrare una soluzione senza il permesso del fornitore originario;
  • verificare dipendenze, vulnerabilità, licenze e trattamento dei dati;
  • continuare a erogare il servizio se cambia il contratto, aumenta il prezzo o scompare il fornitore.

Il punto decisivo è la capacità di uscita. Un prodotto può essere tecnicamente valido e avere un prezzo iniziale basso, ma diventare costoso se il costo di migrazione è imprevedibile o se solo un fornitore conosce il funzionamento interno del sistema.

Dove nasce il risparmio

Il confronto corretto è il TCO — Total Cost of Ownership, cioè il costo complessivo nel ciclo di vita. Per un servizio pubblico comprende almeno licenze o abbonamenti, infrastruttura, configurazione, integrazioni, migrazione, formazione, assistenza, aggiornamenti, sicurezza, gestione degli utenti, conservazione dei dati e costo dell'eventuale indisponibilità.

1 · Licenze e duplicazioni

Si riducono i costi di licenza per utente o per postazione e si evita, soprattutto, di sviluppare più volte la stessa funzione in enti diversi.

2 · Concorrenza sui servizi

Codice e interfacce aperte rendono più facile cambiare integratore, cloud provider o manutentore. La concorrenza si sposta sulla qualità del servizio.

3 · Riutilizzo tra amministrazioni

Un componente finanziato da una Regione può diventare la base per i Comuni; una soluzione comunale documentata può essere adottata altrove.

4 · Durata degli investimenti

Dati, formati e codice non diventano inutilizzabili solo perché termina un contratto commerciale o una versione viene ritirata.

5 · Mercato locale

Le amministrazioni possono acquistare sviluppo, integrazione, assistenza e sicurezza da più imprese, incluse PMI e competenze del territorio.

Questi benefici sono potenziali, non automatici. Un progetto open source può costare più di un prodotto pronto se richiede una migrazione complessa, una personalizzazione eccessiva o un presidio che l'ente non sa organizzare. Il risultato va misurato su quattro anni, includendo uscita e continuità operativa.

Le evidenze disponibili

La Commissione europea ha stimato che nel 2018 le imprese europee investirono circa 1 miliardo di euro in software e hardware open source, con un impatto economico stimato tra 65 e 95 miliardi di euro. Lo studio rileva inoltre che, in diversi casi, l'acquisto di open source da parte del settore pubblico può ridurre il TCO, evitare il vendor lock-in e aumentare l'autonomia digitale. Sono stime macroeconomiche: non sono una previsione di risparmio per ogni singola amministrazione.

In Italia, il catalogo del riuso di Developers Italia riportava nel bilancio 2023 oltre 2.500 amministrazioni che avevano dichiarato di riutilizzare software pubblico o open source; il catalogo conteneva 403 soluzioni, il 58% delle quali era stato riusato almeno da una PA. Il successo non va misurato dal numero di repository pubblicati: conta quante soluzioni sono mantenute, adottabili e realmente operative.

La ricerca OSOR pubblicata nel 2025 sui governi locali europei conferma la stessa lezione. I casi di Consul, Digitransit, Golemio, OS2borgerPC/MedborgarPC e Parlameter mostrano modelli diversi: piattaforme nate in una città e poi diffuse, consorzi di enti, società pubbliche di servizio, associazioni di acquisto e comunità transnazionali. Il riuso del codice non è sempre integrale; spesso il risultato più importante è una combinazione di codice, standard, competenze e capacità di collaborazione.

Il quadro italiano ed europeo

In Italia il Codice dell'amministrazione digitale, all'articolo 68, richiede una valutazione comparativa tecnico-economica prima dell'acquisizione. La valutazione deve considerare il costo complessivo di acquisto, implementazione, mantenimento e supporto, l'uso di formati e interfacce aperti e le garanzie su sicurezza, privacy e livelli di servizio. Il ricorso a software proprietario con licenza d'uso deve essere motivato quando non risultano adeguate soluzioni già disponibili nella PA o soluzioni libere e a codice sorgente aperto.

Le Linee guida AgID su acquisizione e riuso del software indicano Developers Italia come catalogo di riferimento, prevedono la pubblicazione del codice delle soluzioni di cui la PA è titolare e richiedono di rendere disponibili anche le modifiche realizzate su una soluzione riusata. Il riuso deve quindi comprendere licenza, documentazione, manutenzione e responsabilità operative.

Le Linee guida AgID sulla sicurezza nello sviluppo aggiungono il tassello spesso trascurato: un progetto deve avere ciclo di sviluppo sicuro, gestione delle dipendenze, modellazione delle minacce, hardening, test, gestione degli aggiornamenti e ruoli organizzativi chiari. Il codice aperto rende possibile l'ispezione, ma non la sostituisce.

A livello europeo, il Regolamento Interoperable Europe Act (UE 2024/903) promuove la condivisione di soluzioni di interoperabilità, con documentazione, cronologia e, ove applicabile, codice sorgente. Quando le soluzioni sono equivalenti per funzionalità, costo totale, centralità dell'utente, sicurezza informatica e altri criteri oggettivi, il regolamento orienta verso soluzioni senza condizioni di licenza restrittive, comprese quelle open source.

Il segnale politico è chiaro: l'apertura è uno strumento per interoperabilità, continuità e autonomia. Non è una deroga alla qualità, alla sicurezza o alle regole di gara.

Tre livelli di opportunità

Livello nazionale: costruire una base comune

Lo Stato può ottenere il maggiore effetto di scala nei componenti trasversali: gestione documentale, identità e autorizzazioni, notifiche, interoperabilità, sistemi di pagamento, portali, registri, strumenti di analisi e componenti per l'accessibilità.

  • catalogo nazionale verificato, con codice, licenza, documentazione, dipendenze, manutenzione e sicurezza;
  • Open Source Programme Office nazionale con competenze tecniche, legali, di procurement e di comunità;
  • contratti quadro per supporto, audit, migrazione e sviluppo evolutivo, aperti a più operatori;
  • finanziamenti che premino riuso e manutenzione condivisa, non solo la pubblicazione di un prototipo;
  • distinta contabile del software pubblico: licenze, sviluppo, integrazione, assistenza e migrazione;
  • requisiti di portabilità, esportazione dei dati, SBOM e gestione delle vulnerabilità per i sistemi critici;
  • repository e infrastrutture di sviluppo sotto controllo pubblico o europeo, con piani di continuità.

Il bene pubblico non è solo il codice: è una capacità comune di mantenerlo e aggiornarlo.

Livello regionale: trasformare la Regione in piattaforma di riuso

La Regione è il livello adatto per aggregare bisogni simili e ridurre il divario tra grandi e piccoli enti. Può operare come centrale di competenza, non necessariamente come unico sviluppatore.

  • censire software, contratti, licenze, dati e dipendenze dei dipartimenti e degli enti collegati;
  • scegliere pochi domini ad alto riuso — portali, SUAP, gestione documentale, open data, GIS, partecipazione, prenotazioni — e definire standard comuni;
  • istituire un hub tecnico-legale per capitolati, licenze, privacy, sicurezza e valutazioni TCO;
  • finanziare la manutenzione pluriennale con quote proporzionate a popolazione, utilizzo o numero di istanze;
  • organizzare procurement aggregato senza escludere imprese locali;
  • creare comunità di pratica tra RTD, responsabili ICT, segretari comunali e fornitori;
  • pubblicare roadmap, issue tracker, documentazione e indicatori di riuso in un repository regionale interoperabile con Developers Italia.

Per la Sicilia, il vantaggio più concreto sarebbe condividere i costi fissi che un piccolo Comune non può sostenere da solo: analisi iniziale, revisione del codice, sicurezza, aggiornamenti, formazione e gestione della continuità.

Livello locale: comprare libertà operativa, non solo funzionalità

Un Comune non deve iniziare da una migrazione totale. Deve costruire una mappa delle dipendenze e scegliere un caso in cui l'uscita sia misurabile.

Le prime aree da valutare sono quelle con standard maturi, dati esportabili e più fornitori disponibili: produttività d'ufficio, siti e portali, gestione dei contenuti, open data, autenticazione, collaborazione interna, GIS e strumenti di consultazione. Per i servizi essenziali o altamente regolati, il criterio deve essere la continuità: ambiente di prova, backup verificato e piano di ritorno prima della decisione.

Un piccolo ente può adottare open source senza possedere un reparto IT, se compra correttamente i servizi necessari. Il capitolato dovrebbe chiedere:

  • repository e documentazione aggiornati;
  • elenco delle dipendenze e degli autori delle componenti;
  • formati di esportazione e prova periodica di ripristino;
  • tempi di risposta, patch di sicurezza e responsabilità per gli incidenti;
  • accesso amministrativo e credenziali sotto controllo dell'ente;
  • formazione minima del personale e consegna delle procedure operative;
  • possibilità di affidare supporto e hosting a un secondo operatore;
  • pubblicazione delle personalizzazioni secondo la licenza applicabile.

I rischi da non nascondere

L'open source non elimina i rischi: li rende più visibili e, in molti casi, più governabili.

  • Progetto abbandonato. Valutare attività recente, manutentori, release, issue, documentazione e piano di sostituzione.
  • Costo di competenza. Prevedere formazione, supporto professionale e almeno una competenza interna capace di controllare il fornitore.
  • Personalizzazione incontrollata. Adottare configurazione prima di fork, contribuire al progetto upstream e finanziare modifiche generalizzabili.
  • Vulnerabilità nella catena software. Usare inventario delle dipendenze, SBOM, scansioni, firme delle release, patch SLA e test di sicurezza.
  • Licenze incompatibili. Tenere un registro delle licenze e fare una revisione legale prima dell'integrazione.
  • Frammentazione. Adottare architetture di riferimento, standard regionali o nazionali e certificazione leggera.
  • Resistenza degli utenti. Progettare con gli uffici, migrare gradualmente, formare e misurare la produttività reale.
  • Falsa economia. Comparare TCO e costo di uscita su quattro anni, includendo downtime, migrazione e supporto.

La sicurezza non deriva dal fatto che il codice sia pubblico o privato. Deriva da un processo: revisione, test, controllo degli accessi, aggiornamenti, monitoraggio e responsabilità assegnate.

Un metodo decisionale per gli acquisti

Prima di una gara o di un affidamento, l'ente dovrebbe produrre una scheda comparativa con queste domande:

  • 1. Quale servizio pubblico deve essere garantito e quali sono i requisiti non negoziabili?
  • 2. Esiste una soluzione già riusabile nella PA o nel catalogo open source?
  • 3. Quali sono licenza, maturità, dipendenze, comunità e frequenza degli aggiornamenti?
  • 4. Quali dati entrano nel sistema, dove vengono trattati e come vengono esportati?
  • 5. Qual è il TCO su quattro anni nelle opzioni riuso, open source, proprietaria e sviluppo ex novo?
  • 6. Quanti fornitori possono installare, integrare e manutenere la soluzione?
  • 7. Chi paga e chi decide la manutenzione dopo il primo progetto?
  • 8. Come si verifica la sicurezza e quanto tempo serve per applicare una patch critica?
  • 9. Come si esce dal contratto senza interrompere il servizio?
  • 10. Che cosa verrà restituito alla comunità: codice, documentazione, test, connettori e miglioramenti?

La decisione può essere proprietaria. Ma deve essere una decisione dimostrata, non l'effetto automatico di un capitolato scritto attorno a un marchio o a un formato chiuso.

Roadmap proposta: 36 mesi

Primi 90 giorni: conoscere la dipendenza

Creare l'inventario di applicazioni, contratti, licenze, dati, interfacce, fornitori e scadenze. Classificare i sistemi per criticità e misurare costo annuale, rinnovo e migrazione. Selezionare due o tre casi pilota con alto potenziale di riuso e rischio operativo controllabile.

Da 3 a 12 mesi: dimostrare il modello

Eseguire i piloti con repository, documentazione, test di esportazione, formazione e metriche di servizio. Inserire nei contratti clausole su dati, codice, dipendenze, sicurezza, SLA e uscita. Pubblicare una valutazione ex ante ed ex post del TCO.

Da 12 a 24 mesi: aggregare

Unire gli enti con bisogni simili, definire una governance del progetto, dividere costi di manutenzione e creare un contratto di supporto multi-fornitore. Portare le soluzioni mature nel catalogo nazionale e riusare le personalizzazioni invece di replicarle.

Da 24 a 36 mesi: istituzionalizzare

Istituire un OSPO o una funzione equivalente, collegare il programma al piano triennale dell'ente, finanziare sicurezza e manutenzione come spesa ordinaria e pubblicare un rapporto annuale su risparmio, riuso, qualità e dipendenza dai fornitori.

Come misurare se funziona

Il programma dovrebbe rendere pubblici almeno questi indicatori:

  • costo totale per servizio e costo di uscita stimato;
  • quota di software con dati e API documentati in formato aperto;
  • numero di soluzioni riusate e numero di enti che le usano;
  • euro di sviluppo evitato grazie al riuso, documentati con una baseline;
  • quota di spesa affidabile a più fornitori qualificati;
  • tempo medio per applicare patch critiche;
  • percentuale di dipendenze inventariate e aggiornate;
  • tempo necessario per esportare e ripristinare i dati;
  • ore di formazione e competenze disponibili nell'ente;
  • numero e qualità dei contributi restituiti ai progetti condivisi.

Non basta contare le licenze eliminate. Un risparmio che produce più ore di lavoro, incidenti o disservizi non è un risparmio pubblico.

Le decisioni che spettano agli amministratori

  • open e riuso come opzione iniziale, con motivazione documentata quando non sono adeguati;
  • TCO e portabilità come criteri di gara, non come allegati facoltativi;
  • codice pubblico quando è titolarità pubblica, salvo eccezioni motivate per sicurezza, privacy o diritti di terzi;
  • manutenzione finanziata, con una quota esplicita per sicurezza, aggiornamenti e documentazione;
  • competenze distribuite, perché la sovranità non si ottiene sostituendo un monopolio privato con un monopolio interno;
  • cooperazione tra livelli, per non lasciare i piccoli enti soli davanti a una scelta tecnica e contrattuale complessa.

Per l'Italia e per la Sicilia, la risposta più promettente è un portafoglio di soluzioni aperte, mantenute insieme, acquistate come servizi competitivi e valutate con numeri verificabili. La sovranità software non è un gesto ideologico: è una politica di bilancio, sicurezza e continuità amministrativa.

Fonti e riferimenti

Nota editoriale: il quadro normativo e le pagine web sono stati verificati il 30 agosto 2026. Il testo è un'analisi di policy, non un parere legale né una valutazione economica per uno specifico affidamento.