Public Sector Open Source Program Offices - Archetypes for how to Grow (Common) Institutional Capabilities

Questo studio qualitativo analizza 16 casi di uffici per l'open source nel settore pubblico europeo per definire sei archetipi organizzativi e fornire linee guida strategiche su come istituire tali uffici al fine di promuovere l'adozione dell'open source, la sovranità digitale e l'interoperabilità dei servizi.

L'essenziale

Ecco una spiegazione semplice e creativa di questo studio, pensata per chiunque voglia capire come funziona il "motore" dietro l'uso del software libero nella pubblica amministrazione.

🏛️ Il Problema: La Pubblica Amministrazione e il "Cantiere" del Software Immaginario

Immagina che la Pubblica Amministrazione (comuni, ministeri, ospedali, scuole) sia come un enorme cantiere edile che deve costruire servizi digitali per i cittadini (pagare le tasse online, prenotare visite, votare, ecc.).

Per decenni, questo cantiere ha funzionato così: ogni volta che serviva un nuovo attrezzo o un nuovo macchinario, l'amministrazione lo comprava da un'azienda esterna, pagando un prezzo alto e firmando un contratto che diceva: "Questo è mio, non puoi toccarlo, e se si rompe devi chiamare solo noi per ripararlo".

Oggi, però, c'è una rivoluzione: il Software Open Source (OSS).
Pensa all'Open Source come a un enorme magazzino di mattoni gratuiti e condivisi che chiunque può prendere, migliorare e ridare agli altri. Il 90% delle infrastrutture digitali moderne (dai siti web alle app bancarie) è fatto con questi mattoni.

Il problema? La Pubblica Amministrazione è spesso spaventata da questo magazzino.

• "Chi ci garantisce che il mattone è sicuro?"
• "Come facciamo a ripararlo se non abbiamo un meccanico interno?"
• "Chi ci insegna a usarlo?"

Di conseguenza, molti comuni e ministeri restano bloccati, comprando ancora software costosi e chiusi, perdendo tempo e denaro.

🚀 La Soluzione: L'OSPO (L'Ufficio "Capocantiere" per l'Open Source)

Lo studio analizza come alcune organizzazioni hanno risolto questo problema creando un OSPO (Open Source Program Office).

Se la Pubblica Amministrazione è il cantiere, l'OSPO è il Capocantiere esperto o il Responsabile della Logistica che sa esattamente come usare quei mattoni gratuiti. Il suo compito non è solo dire "usate l'Open Source", ma assicurarsi che:

1. Si sappia come usarlo.
2. Si sappia come ripararlo se si rompe.
3. Si sappia come contribuire a migliorarlo per tutti.

🧩 I 6 Tipi di "Capocantiere" (Gli Archetipi)

Lo studio ha intervistato 18 esperti in 16 casi diversi (dall'Italia alla Francia, dalla Germania all'Irlanda) e ha scoperto che non esiste un unico modo per essere un OSPO. Come ci sono diversi tipi di chef, ci sono 6 tipi di OSPO, ognuno adatto a una situazione diversa:

1. L'OSPO Nazionale (Il "Ministro della Tecnologia")

• Chi è: Un'agenzia governativa centrale (es. in Francia, Italia, Germania).
• Cosa fa: È come il Ministro dei Lavori Pubblici. Non costruisce i mattoni, ma scrive le regole: "Tutti i comuni devono usare questi mattoni gratuiti". Crea le leggi, i cataloghi centrali e aiuta tutti gli altri a capire come muoversi.
• Metafora: È il regista che decide la sceneggiatura di tutto il film.

2. L'OSPO Istituzionale (Il "Responsabile IT Interno")

• Chi è: Un dipartimento IT dentro un grande ente (es. l'Unione Europea, l'Agenzia delle Entrate o un grande ospedale).
• Cosa fa: È il capo officina interno. Si assicura che i suoi dipendenti sappiano usare i mattoni gratuiti senza farsi male. Gestisce i rischi legali e di sicurezza, ma lascia libertà ai tecnici di scegliere gli attrezzi giusti.
• Metafora: È il meccanico capo di una grande flotta di auto, che garantisce che tutti guidino in sicurezza.

3. L'OSPO Locale (Il "Sindaco Innovatore")

• Chi è: Un singolo comune o città (es. Parigi, Bratislava).
• Cosa fa: È il sindaco del quartiere che ha deciso di fare le cose in modo diverso. Spesso sono piccoli team che costruiscono soluzioni specifiche per i loro cittadini (es. un'app per la raccolta rifiuti) e le condividono con gli altri comuni.
• Metafora: È il pioniere che prova un nuovo tipo di aratro e lo insegna ai vicini.

4. L'OSPO di Associazione (Il "Club di Calcio")

• Chi è: Un'associazione di comuni (es. l'associazione dei comuni olandesi o danesi).
• Cosa fa: È come un club sportivo. I singoli comuni sono piccoli e non possono permettersi un allenatore costoso. Quindi si uniscono, pagano una quota e creano un "allenatore comune" (l'OSPO) che sviluppa software per tutti.
• Metafora: È il consorzio che compra un trattore gigante da dividere tra 50 aziende agricole.

5. L'OSPO Accademico (Il "Professore Ricercatore")

• Chi è: Università e centri di ricerca (es. Trinity College a Dublino).
• Cosa fa: È il laboratorio universitario. Si occupa di trasformare la ricerca scientifica in software aperto. Aiuta i professori a capire come pubblicare il loro codice senza violare i diritti di proprietà intellettuale o i contratti con le aziende finanziatrici.
• Metafora: È il ponte che trasforma la teoria della fisica in un prototipo funzionante.

6. L'OSPO "Sociale" (L'Organizzazione No-Profit)

• Chi è: Organizzazioni della società civile (es. Code for Romania).
• Cosa fa: Sono i volontari super-competenti. Non fanno parte del governo, ma costruiscono software per aiutare il governo a funzionare meglio (es. app per i rifugiati). Spesso colmano i buchi che il governo non riesce a riempire.
• Metafora: Sono gli artigiani che entrano nel cantiere e dicono: "Ehi, ho visto che questo muro è storto, lasciate che vi aiuti a raddrizzarlo gratis".

💡 Cosa ci insegna questo studio?

1. Non esiste una ricetta unica: Non puoi copiare e incollare l'OSPO di Parigi nel tuo piccolo comune. Devi adattarlo alle tue risorse e ai tuoi obiettivi.
2. Serve un "Capocantiere": Se vuoi usare l'Open Source, non basta dire "fate pure". Serve qualcuno che guidi il processo, formi le persone e gestisca i rischi.
3. La collaborazione è la chiave: I comuni più piccoli non possono fare tutto da soli. Devono unirsi (tramite associazioni) o chiedere aiuto a chi è più esperto (nazionale o società civile).
4. Non è solo software: L'obiettivo finale non è avere codice gratuito, ma avere servizi pubblici migliori, più sicuri, più economici e che appartengano davvero ai cittadini (sovranità digitale).

In sintesi

Questo studio ci dice che per modernizzare la Pubblica Amministrazione, non serve comprare nuovi "attrezzi" costosi. Serve formare dei Capocantieri esperti (OSPO) che sappiano usare i mattoni gratuiti che già esistono, insegnando a tutti come costruirsi la casa da soli, insieme.

Sommario tecnico

Ecco una sintesi tecnica dettagliata del documento di ricerca "Public Sector Open Source Program Offices - Archetypes for how to Grow (Common) Institutional Capabilities", presentata in italiano.

1. Il Problema e il Contesto

Il software open source (OSS) costituisce oltre il 90% dell'infrastruttura digitale che sostiene i servizi pubblici e industriali. Nonostante il suo potenziale per accelerare la digitalizzazione, garantire la sovranità digitale e migliorare l'interoperabilità, le Organizzazioni del Settore Pubblico (PSO - Public Sector Organisations) in Europa affrontano sfide significative nell'adozione e nella gestione dell'OSS.

Le principali barriere identificate includono:

• Dipendenza dall'esternalizzazione: Le PSO tendono a fare affidamento sull'acquisto e sull'esternalizzazione delle competenze tecniche, limitando lo sviluppo di competenze interne in ingegneria del software e OSS.
• Vincoli normativi e culturali: Framework di appalto complessi, incentivi politici a breve termine e una cultura IT conservatrice e avversione al rischio ostacolano l'adozione.
• Mancanza di strutture di supporto: A differenza del settore privato, dove gli Open Source Program Offices (OSPO) sono diventati comuni, il settore pubblico manca di linee guida chiare su come strutturare queste funzioni di supporto per gestire la strategia, la conformità e la collaborazione OSS.

Lo studio mira a colmare questo divario esplorando come le PSO in UE, Norvegia, Liechtenstein e Islanda possano istituire e gestire OSPO per abilitare l'adozione, lo sviluppo e la collaborazione sull'OSS.

2. Metodologia

La ricerca adotta un approccio qualitativo esplorativo, strutturato in tre cicli di ricerca iterativi:

1. Ciclo 1 (Concettualizzazione): Analisi della letteratura pratica (grey literature) e dei report del settore privato (es. The TODO Group, OSPO Alliance) per costruire un quadro concettuale iniziale sulle strutture, i ruoli e le responsabilità degli OSPO.
2. Ciclo 2 (Indagine Empirica):
   • Campione: Sono stati selezionati 16 casi di OSPO nel settore pubblico attraverso un campionamento mirato (purposive sampling), coprendo diversi livelli di governo (nazionale, regionale, locale), settori e maturità.
   • Raccolta Dati: Sono state condotte 17 interviste semi-strutturate con 18 rappresentanti chiave degli OSPO.
   • Analisi: I dati sono stati codificati utilizzando metodi di codifica strutturale, aperta e assiale per identificare temi ricorrenti e modelli.
3. Ciclo 3 (Validazione): Due gruppi di discussione (focus group) con partecipanti delle interviste ed esperti esterni sono stati utilizzati per validare e arricchire i risultati, confermando l'identificazione degli archetipi.

3. Contributi Chiave

Il principale contributo dello studio è l'identificazione e la definizione di sei archetipi distinti di OSPO nel settore pubblico europeo. Questo modello offre una tassonomia pratica che aiuta le organizzazioni a progettare la propria struttura di supporto in base al proprio contesto, alle risorse e agli obiettivi di policy.

I sei archetipi sono:

1. OSPO di Governo Nazionale: Ospitati da ministeri o amministrazioni centrali (es. DINUM in Francia, Developers Italia).
2. OSPO Istituzionali: Ospitati all'interno di dipartimenti IT di grandi istituzioni pubbliche (es. Commissione Europea, Agenzia delle Entrate olandese).
3. OSPO di Governo Locale: Ospitati da comuni o città (es. Parigi, Bratislava, Ventspils).
4. OSPO Basati su Associazioni: Entità create da consorzi di enti pubblici (es. OS2 in Danimarca, VNG nei Paesi Bassi) per condividere risorse e governance.
5. OSPO Accademici: Ospitati da università o centri di ricerca (es. Trinity College Dublin, Lero in Irlanda) per gestire la proprietà intellettuale e la diffusione della ricerca.
6. Organizzazioni con Funzioni di Supporto Simili agli OSPO: Entità della società civile indipendenti che supportano il settore pubblico (es. Code for Romania).

4. Risultati e Analisi Tecnica

L'analisi incrociata dei casi ha rivelato come ciascun archetipo gestisca nove aree di responsabilità chiave, con approcci diversi:

• Strategia e Policy: Gli OSPO nazionali fungono da mediatori tra la legislazione e l'implementazione pratica, traducendo mandati politici in linee guida operative. Gli OSPO locali e istituzionali adattano queste strategie al contesto specifico.
• Adozione e Consumo: Gli OSPO nazionali e associativi gestiscono piattaforme centralizzate e cataloghi per la condivisione della conoscenza. Gli OSPO istituzionali si concentrano su processi di intake sicuri e autonomi per gli sviluppatori interni.
• Sviluppo e Rilascio: Mentre gli OSPO nazionali e locali spesso sviluppano e mantengono applicazioni critiche per l'infrastruttura pubblica (es. OpenDesk in Germania, Lutece a Parigi), gli OSPO accademici si concentrano sulla disseminazione dei risultati della ricerca come OSS.
• Conformità e Licenze: Tutti gli archetipi gestiscono la conformità, ma con strumenti diversi: dagli elenchi curati di licenze e SBOM (Software Bill of Materials) automatizzati (nazionali) alla consulenza legale specifica per la commercializzazione della ricerca (accademici).
• Inner Source: La maggior parte degli OSPO pubblici preferisce l'approccio "Open by default" (rilascio pubblico immediato) rispetto all'Inner Source, considerandolo superfluo o meno trasparente, a meno che non vi siano vincoli specifici.
• Formazione e Community: Esiste un forte investimento nella creazione di comunità di pratica (es. Blue Hats in Francia, Developers Italia) e nella formazione, sebbene le risorse siano spesso limitate, specialmente a livello locale.
• Metriche: Il monitoraggio delle metriche è riconosciuto come cruciale per giustificare i finanziamenti, ma la sua implementazione varia notevolmente, passando da analisi sistematiche (nazionali) a tracciamenti informali o basati su casi specifici (locali).

5. Significato e Implicazioni

Lo studio fornisce raccomandazioni concrete per policymaker e praticanti:

• Per i Governi Nazionali: È essenziale istituire OSPO nazionali per coordinare le strategie digitali, fornire linee guida sugli appalti e creare reti trasversali per la condivisione delle competenze.
• Per i Governi Locali: Si raccomanda la creazione di OSPO locali o l'adesione ad associazioni per superare la carenza di risorse e competenze, permettendo ai comuni più grandi di guidare l'adozione OSS per quelli più piccoli.
• Per le Istituzioni Accademiche: Gli OSPO devono bilanciare la proprietà intellettuale con i principi della scienza aperta, supportando i ricercatori nella scelta delle licenze e nella commercializzazione dei risultati.
• Ruolo della Società Civile: Organizzazioni come Code for Romania dimostrano che entità esterne possono fungere da catalizzatori per l'adozione OSS, colmando il divario di competenze tra il settore pubblico e la tecnologia.

Conclusione:
Il documento conclude che gli OSPO non sono entità monolitiche ma devono essere progettati in modo contestuale. Non esiste un modello "taglia unica". Tuttavia, l'OSPO funge da agente di cambiamento fondamentale, trasformando la cultura organizzativa, gestendo i rischi legali e tecnici e abilitando la sovranità digitale. In futuro, il ruolo degli OSPO si espanderà oltre il software per includere dati aperti, standard, hardware e intelligenza artificiale, diventando pilastri per un ecosistema digitale pubblico interoperabile e resiliente.