L'open source è un'opportunità strategica per ridurre il vincolo da un singolo fornitore, riusare gli investimenti pubblici e trattenere competenze e valore sul territorio. Non è però sinonimo di software gratuito: il risparmio arriva solo quando codice, dati, competenze, manutenzione e acquisti vengono governati come un'infrastruttura condivisa.
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à.
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à.
L'open source può produrre risparmio attraverso cinque canali:
1. Licenze e duplicazioni. Si riducono i costi di licenza per utente o per postazione e, soprattutto, si evita di sviluppare più volte la stessa funzione in enti diversi. 2. Concorrenza sui servizi. Il codice e le interfacce aperte rendono più facile cambiare integratore, cloud provider o manutentore. La concorrenza si sposta dal possesso esclusivo del prodotto alla qualità del servizio. 3. Riutilizzo tra amministrazioni. Un componente finanziato da una Regione può diventare la base per i Comuni; una soluzione comunale ben documentata può essere adottata da altri enti senza ripartire da zero. 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, invece di concentrare tutta la spesa in un unico ecosistema proprietario.
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. Per questo il dossier propone di misurare il risultato su quattro anni, includendo anche 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 della Commissione 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 dato mostra che una base di condivisione esiste, ma anche che 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, tra gli altri elementi, 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. La conseguenza pratica è importante: il riuso non è un download senza responsabilità, ma una scelta di procurement che deve 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 le amministrazioni 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à.
Le priorità dovrebbero essere:
- un catalogo nazionale verificato, con codice, licenza, documentazione, dipendenze, stato di manutenzione e livelli di sicurezza;
- un Open Source Programme Office nazionale, con competenze tecniche, legali, di procurement e di gestione della comunità;
- contratti quadro per supporto, audit, migrazione e sviluppo evolutivo, aperti a più operatori;
- finanziamenti che premino il riuso e la manutenzione condivisa, non soltanto la pubblicazione di un prototipo;
- una distinta contabile del software pubblico: quanto viene speso in 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 livello nazionale dovrebbe inoltre evitare che ogni amministrazione centrale ricrei la propria piattaforma. 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.
Una politica regionale credibile dovrebbe:
- censire software, contratti, licenze, dati e dipendenze dei propri dipartimenti e degli enti collegati;
- scegliere pochi domini ad alto riuso — per esempio portali, SUAP, gestione documentale, open data, GIS, partecipazione, prenotazioni — e definire standard comuni;
- istituire un hub tecnico-legale che aiuti i Comuni con capitolati, licenze, privacy, sicurezza e valutazioni TCO;
- finanziare una manutenzione pluriennale con quote proporzionate a popolazione, utilizzo o numero di istanze;
- organizzare procurement aggregato senza escludere imprese locali dalla fornitura dei servizi;
- 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à: prima si prepara un ambiente di prova, un backup verificato e un piano di ritorno, poi si decide.
Un piccolo ente può adottare open source senza possedere un reparto IT, se compra correttamente i servizi necessari. Il capitolato dovrebbe chiedere almeno:
- 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. Mitigazione: valutare attività recente, manutentori, release, issue, documentazione e piano di sostituzione.
- Costo di competenza. Mitigazione: prevedere formazione, supporto professionale e almeno una competenza interna capace di controllare il fornitore.
- Personalizzazione incontrollata. Mitigazione: adottare configurazione prima di fork, contribuire al progetto upstream e finanziare le modifiche generalizzabili.
- Vulnerabilità nella catena software. Mitigazione: inventario delle dipendenze, SBOM, scansioni, firme delle release, patch SLA e test di sicurezza.
- Licenze incompatibili. Mitigazione: registro delle licenze, revisione legale e policy per l'integrazione e la distribuzione.
- Frammentazione. Mitigazione: architetture di riferimento, standard regionali o nazionali e un processo di certificazione leggera.
- Resistenza degli utenti. Mitigazione: progettazione con gli uffici, migrazione graduale, formazione e misurazione della produttività reale.
- Falsa economia. Mitigazione: 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 il costo annuale, il costo di rinnovo e il costo stimato di 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 pubblico o privato secondo la sensibilità del progetto, 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
Per cogliere l'opportunità, Stato, Regione e Comuni dovrebbero adottare una politica semplice:
- 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.
La domanda non è “open source o proprietario?”. La domanda è: “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?”.
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
- Agenzia per l'Italia Digitale, Riuso e Open Source.
- Agenzia per l'Italia Digitale, Linee guida su acquisizione e riuso di software per le PA e testo PDF.
- Developers Italia, Acquisizione di software per la Pubblica Amministrazione e risultati del catalogo 2023.
- Normattiva, Codice dell'amministrazione digitale, articolo 68.
- Agenzia per l'Italia Digitale, Linee guida per lo sviluppo del software sicuro.
- Unione europea, Regolamento (UE) 2024/903 — Interoperable Europe Act.
- Commissione europea, studio sull'impatto economico dell'open source, 2021.
- OECD, Digital Government Outlook 2026 — open source e infrastruttura digitale pubblica.
- European Commission OSOR, Open Source Software Adoption and Reuse in European Local Governments: A Multiple-Case Study, 2025.
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.