Nel capitolo precedente abbiamo stabilito che i dati di Salerno Verde devono essere, per quanto possibile, aperti. Adesso dobbiamo affrontare l'altra metà della questione:  Con quali strumenti costruiamo, gestiamo e pubblichiamo quei dati?

La risposta non può essere neutrale perché una piattaforma tecnologica non è soltanto un mezzo. Determina:

• chi può modificarla;
• quanto costa mantenerla;
• quanto è facile cambiare fornitore;
• quanto possiamo controllarne il funzionamento;
• quanto possiamo riutilizzare ciò che è stato sviluppato;
• quanto dipendiamo da soggetti esterni.

Salerno Verde propone quindi un principio chiaro:

privilegiare Software Libero, standard aperti e sviluppo controllabile dall'Amministrazione.

Non per una scelta ideologica astratta ma per costruire autonomia tecnologica pubblica.

Software Libero non significa software gratuito

La prima distinzione è fondamentale. Software Libero non significa necessariamente:

software senza costi. Servono comunque:

• server;
• configurazione;
• sviluppo;
• sicurezza;
• formazione;
• manutenzione;
• supporto.

Il vantaggio principale non è quindi l'assenza di spesa. È la possibilità di:

• studiare il codice;
• modificarlo;
• riutilizzarlo;
• farlo manutenere da soggetti differenti;
• non dipendere necessariamente da un unico fornitore.

La libertà tecnologica non elimina i costi. Riduce la dipendenza.

Il vero costo del lock-in

Un sistema proprietario può funzionare perfettamente. Il problema nasce quando:

• i dati sono conservati in formati difficili da esportare;
• le personalizzazioni appartengono soltanto al fornitore;
• le API sono limitate;
• la documentazione è incompleta;
• cambiare gestore significa ricostruire l'intero sistema.

A quel punto il costo non è soltanto il canone annuale. È il costo della dipendenza tecnologica. Salerno Verde deve cercare di evitarlo fin dall'inizio.

Autonomia, non autarchia

Dobbiamo però chiarire subito anche l'errore opposto. Autonomia non significa: fare tutto da soli.

Il Comune non deve sviluppare da zero:

• un database;
• un GIS;
• un server cartografico;
• un framework web.

Esistono già strumenti maturi. L'obiettivo è utilizzare e integrare ciò che funziona. Lo sviluppo interno deve concentrarsi soprattutto su ciò che è specifico di Salerno Verde.

Prima riuso, poi sviluppo

La sequenza dovrebbe essere:

CERCARE

↓

VALUTARE

↓

RIUSARE

↓

ADATTARE

↓

SVILUPPARE SOLO CIÒ CHE MANCA

È uno dei principi più importanti di tutta la strategia digitale. Prima di finanziare un nuovo software dobbiamo verificare se:

• esiste già una soluzione libera;
• esiste un progetto sviluppato da un'altra amministrazione;
• esiste un componente adattabile.

Il denaro pubblico non dovrebbe pagare due volte per reinventare la stessa funzione.

Un ecosistema già disponibile

Per molte esigenze di Salerno Verde esiste già un ecosistema libero molto maturo. A titolo progettuale, e senza trasformare questo documento in un capitolato tecnico, possiamo immaginare strumenti come:

• QGIS per cartografia e analisi;
• PostgreSQL/PostGIS per il database geografico;
• server e servizi geografici liberi;
• framework web open source;
• strumenti Git per codice e documentazione;
• formati e protocolli aperti.

La scelta definitiva deve comunque derivare dai requisiti e non dal nome del prodotto.

Prima i requisiti

Prima di scegliere uno strumento dobbiamo scrivere cosa deve fare. Per esempio:

• gestire alberi;
• gestire progetti;
• ricevere segnalazioni;
• pubblicare Open Data;
• fornire mappe;
• esporre API;
• calcolare indicatori;
• conservare storico.

Poi chiediamo: quale componente soddisfa meglio questi requisiti?

È il metodo opposto a quello nel quale si acquista una piattaforma e successivamente si tenta di adattare il progetto a ciò che la piattaforma consente.

Architettura modulare

Salerno Verde dovrebbe essere costruito come un insieme di componenti:

• Database.
• GIS.
• API.
• Interfaccia.
• Segnalazioni.
• Dashboard.

Non come un unico grande prodotto indivisibile.

Questo permette di sostituire una parte senza ricostruire tutto:

• Possiamo aggiornare l'interfaccia mantenendo il database.
• Cambiare un componente cartografico mantenendo le API.
• Aggiungere un modulo.

La modularità è una forma di resilienza tecnologica.

Il Comune deve possedere la conoscenza del sistema

Anche quando parte dello sviluppo viene affidata all'esterno, l'Amministrazione deve conoscere almeno:

• architettura;
• schema dei dati;
• dipendenze;
• procedure di installazione;
• modalità di backup;
• processo di aggiornamento.

Non deve necessariamente saper modificare ogni riga di codice ma deve essere capace di capire che cosa possiede e come funziona.

Sviluppo in house: cosa significa davvero

Per Salerno Verde, sviluppo in house non deve essere interpretato come: “un dipendente scrive tutto il software”. Può significare invece che l'Amministrazione conserva internamente:

• analisi dei requisiti;
• architettura;
• controllo del repository;
• schema dati;
• integrazione;
• test;
• documentazione;
• gestione delle versioni.

Parti dello sviluppo possono essere affidate a soggetti esterni ma il centro di gravità della conoscenza rimane pubblico.

Una piccola squadra è meglio di un grande contratto cieco

Una piccola squadra competente può permettere al Comune di:

• valutare preventivi;
• controllare fornitori;
• fare modifiche semplici;
• gestire integrazioni;
• evitare richieste inutili;
• comprendere i problemi.

Senza competenze interne anche il miglior contratto può generare dipendenza.

Per questo una parte delle risorse tecnologiche dovrebbe essere destinata non solo all'acquisto di servizi, ma alla costruzione di capacità interna.

Formazione come investimento

Se Salerno Verde dura fino al 2050, la formazione non può essere una attività iniziale una tantum. Servirà aggiornamento periodico su:

• GIS;
• database;
• Open Data;
• sviluppo;
• sicurezza;
• standard;
• gestione del codice.

Il personale può cambiare, le tecnologie possono cambiare ma capacità di apprendere deve rimanere.

Documentare tutto ciò che conta

Lo sviluppo interno o aperto fallisce rapidamente se la conoscenza rimane soltanto nelle persone. Ogni componente dovrebbe quindi avere:

• README;
• schema architetturale;
• istruzioni di installazione;
• dipendenze;
• configurazione;
• procedure di backup;
• istruzioni per gli aggiornamenti;
• licenza.

La documentazione non è un allegato ma è parte del software.

Il repository pubblico

Quando non esistono ragioni di sicurezza o altre limitazioni, il codice sviluppato per Salerno Verde dovrebbe essere conservato in un repository pubblico. Il repository può contenere:

• codice sorgente;
• script;
• documentazione;
• schema del database;
• specifiche API;
• issue;
• roadmap.
• Questo rende possibile:
• controllo;
• riuso;
• collaborazione;
• continuità.

Public Money, Public Code

Il principio può essere espresso in una frase:

Public Money, Public Code

Se il denaro pubblico finanzia un software, il codice dovrebbe, salvo eccezioni motivate, tornare alla collettività con una licenza libera. Non significa che ogni riga scritta da qualunque fornitore debba essere automaticamente pubblicata senza verifiche ma che l'apertura deve essere il punto di partenza contrattuale, non una eventuale concessione finale.

L'apertura deve entrare nei capitolati

Questo è decisivo. Se vogliamo il codice, dobbiamo stabilirlo prima dell'affidamento. Un capitolato dovrebbe chiarire, quando appropriato:

• consegna del sorgente;
• licenza;
• repository;
• documentazione;
• diritti di modifica;
• formati dei dati;
• API;
• procedure di deploy.

Non possiamo scoprire alla fine che il software pagato dal Comune non può essere riutilizzato.

Dipendenze libere, per quanto possibile

Un software pubblicato con licenza libera può comunque dipendere da componenti proprietari essenziali. Questo riduce enormemente la sua riusabilità. La progettazione dovrebbe quindi preferire, ove ragionevole, dipendenze anch'esse:

• aperte;
• documentate;
• sostituibili.

L'obiettivo non è la purezza tecnologica ma evitare colli di bottiglia proprietari nascosti.

Le licenze vanno scelte bene

Non basta scrivere: “open source”. Il codice deve avere una licenza precisa e la scelta dovrà essere valutata in base al progetto e agli obblighi derivanti dalle componenti utilizzate. L'importante è che sia chiaro:

• chi può usare il software;
• come può modificarlo;
• come può redistribuirlo;
• quali obblighi conserva.

La licenza deve essere decisa all'inizio, non alla pubblicazione finale.

Non pubblicare segreti

Repository pubblico non significa pubblicare:

• password;
• chiavi;
• token;
• configurazioni riservate;
• dati personali.

La sicurezza deve essere integrata nel processo:

• Configurazione pubblica dove possibile.
• Segreti separati.
• Permessi.
• Revisioni.
• Automazioni di controllo.

Il Software Libero richiede professionalità tanto quanto qualsiasi altra infrastruttura.

Sviluppo aperto, non soltanto pubblicazione finale

Un'altra differenza importante. Possiamo sviluppare un software completamente in privato e pubblicarlo alla fine. È meglio di non pubblicarlo ma Salerno Verde dovrebbe, quando possibile, adottare un modello più aperto.

• Roadmap.
• Issue.
• Versioni.
• Commit.
• Discussione tecnica.

Il progetto diventa osservabile mentre cresce.

Il codice racconta le decisioni

Un repository versionato permette di sapere:

• quando una funzione è stata aggiunta;
• quando un algoritmo è cambiato;
• quale bug è stato corretto.

Questo ha un valore particolare per un sistema che calcola indicatori pubblici. Se cambiamo la formula dell'Indice di Priorità Verde, possiamo collegare:

• metodologia;
• versione del codice;
• data di entrata in vigore.

La trasparenza diventa anche riproducibilità.

Code review

Sviluppo in house non deve significare che una sola persona possa introdurre modifiche direttamente in produzione. Serve una metodologia.

• Review.
• Test.
• Versionamento.
• Ambienti separati.
• Backup.

Anche un piccolo gruppo può adottare buone pratiche. Il codice pubblico deve essere trattato come infrastruttura pubblica, non come script personale.

Test automatici

Per le componenti più importanti dovremmo prevedere progressivamente test automatici. Particolarmente quando il software:

• calcola indicatori;
• trasforma dati;
• pubblica API;
• gestisce segnalazioni.

Un aggiornamento non dovrebbe modificare silenziosamente risultati che prima funzionavano. La qualità del codice ha conseguenze sulla qualità delle decisioni.

Continuous integration, quando utile

Possiamo utilizzare processi automatici per:

• testare;
• controllare;
• costruire;
• validare.

Non perché dobbiamo imitare una grande azienda tecnologica. Perché l'automazione riduce alcuni errori ripetitivi.

Anche qui vale il principio: quanto basta per rendere il sistema affidabile.

Sicurezza e aggiornamenti

Il Software Libero offre accesso al codice, ma questo non elimina la necessità di:

• monitorare vulnerabilità;
• aggiornare dipendenze;
• installare patch;
• controllare accessi.

Un componente non mantenuto diventa un rischio indipendentemente dalla licenza. Per questo ogni software adottato dovrebbe essere valutato anche rispetto a:

• attività della comunità;
• frequenza degli aggiornamenti;
• documentazione;
• maturità.

Non adottare software libero soltanto perché è libero

Questa frase deve essere esplicita. Un progetto open source:

• abbandonato;
• insicuro;
• poco documentato;
• incompatibile con i requisiti

non diventa una buona scelta semplicemente perché possiede una licenza libera.

Il criterio deve essere: libero e adeguato.

Valutare la comunità

Quando selezioniamo un componente dovremmo guardare anche a:

• numero e qualità dei manutentori;
• frequenza dei rilasci;
• issue aperte;
• documentazione;
• adozione;
• governance del progetto.

Un ecosistema attivo riduce il rischio di trovarsi con una tecnologia senza futuro.

Contribuire upstream

Quando Salerno sviluppa una correzione o una funzione utile a un software libero esistente, dovrebbe valutare di restituirla al progetto originale. Questo è importante. Se manteniamo tutte le modifiche solo nella nostra versione interna, accumuliamo un fork difficile da aggiornare. Contribuire upstream significa:

• ridurre manutenzione;
• migliorare il software;
• restituire valore alla comunità.

Salerno non soltanto utente, ma contributore

Questo potrebbe diventare uno degli aspetti più interessanti del progetto. Una pubblica amministrazione non deve essere necessariamente soltanto consumatrice di tecnologia ma può contribuire a:

• codice;
• documentazione;
• traduzioni;
• test;
• specifiche.

Salerno Verde può diventare, in piccolo, parte attiva dell'ecosistema del Software Libero.

Il riuso tra enti

Un modulo per il catasto arboreo potrebbe essere utile anche ad altri Comuni, un sistema di segnalazioni potrebbe essere adattato, un algoritmo per il calcolo dell'accessibilità al verde potrebbe essere riutilizzato.

Se pubblichiamo tutto in forma aperta, un'altra amministrazione può partire dal nostro lavoro e noi possiamo fare lo stesso con il loro. Il valore del denaro pubblico aumenta quando il risultato è riusabile.

Una comunità di amministrazioni

Nel lungo periodo potremmo immaginare una collaborazione tra enti che utilizzano gli stessi componenti.

• Costi di manutenzione condivisi.
• Sviluppi comuni.
• Documentazione comune.
• Una funzionalità finanziata da una città diventa disponibile anche alle altre.

È uno dei modelli più interessanti resi possibili dal Software Libero.

Università

La collaborazione universitaria può essere particolarmente utile nello sviluppo di:

• algoritmi;
• analisi spaziali;
• prototipi;
• visualizzazioni;
• strumenti di citizen science.

Ma i risultati utili devono poter essere portati fuori dal contesto della ricerca.

• Codice documentato.
• Licenza.
• Dataset.
• Procedure.

Altrimenti il prototipo muore alla fine della tesi.

Tirocini e formazione

Il progetto potrebbe anche diventare occasione per:

• tirocini;
• laboratori;
• tesi;
• percorsi professionalizzanti.
• GIS.
• Open Data.
• Sviluppo web.
• Ecologia urbana.
• Data science.

Salerno Verde potrebbe contribuire contemporaneamente alla trasformazione urbana e alla formazione di competenze locali.

Ma non lavoro gratuito strutturale

È importante evitare un equivoco. Studenti, volontari e comunità possono contribuire non devono sostituire permanentemente professionalità necessarie alla gestione di una infrastruttura pubblica. Il nucleo essenziale deve avere:

• responsabilità;
• continuità;
• risorse.

La collaborazione aggiunge valore non sostituisce il lavoro strutturale.

Software e partecipazione

Il Software Libero assume un valore ancora maggiore quando alimenta strumenti di partecipazione. Una piattaforma civica basata su codice pubblico permette di verificare:

• come vengono gestiti gli stati delle segnalazioni;
• quali informazioni sono raccolte;
• come vengono calcolate alcune statistiche.

La trasparenza riguarda non soltanto il dato ma anche la macchina che lo gestisce.

Nessun algoritmo segreto sulle priorità

Se utilizzeremo uno strumento per attribuire punteggi ai progetti in base a:

• calore;
• verde;
• popolazione;
• permeabilità,

la logica deve essere pubblica.

Codice e metodo disponibili non perché ogni cittadino debba leggerli ma perché possa farlo chi desidera verificarli.

L'algoritmo non decide

Anche con codice completamente aperto, la decisione rimane pubblica e politica. L'Indice di Priorità può suggerire: quartiere A prima di quartiere B. La Cabina di Regia potrebbe decidere diversamente per una ragione motivata.

La piattaforma deve mostrare la differenza tra: risultato tecnico e decisione finale.

Nessuna intelligenza artificiale come scorciatoia

Nel lungo periodo potranno essere utili anche strumenti di intelligenza artificiale per:

• classificazione;
• analisi;
• supporto alla gestione.

Ma Salerno Verde non deve utilizzare l'AI per sostituire:

• dati affidabili;
• competenze;
• decisioni.

Ogni sistema automatizzato con effetti significativi dovrebbe essere valutato rispetto a:

• trasparenza;
• accuratezza;
• bias;
• controllabilità;
• costi;
• dipendenza dal fornitore.

La tecnologia entra quando risolve un problema reale non perché è di moda.

Preferire strumenti locali e controllabili

Quando una funzione semplice può essere svolta:

• sui server del Comune;
• con software libero;
• senza inviare dati inutilmente a servizi esterni,

questa soluzione può offrire vantaggi in termini di:

• privacy;
• controllo;
• costi;
• continuità.

Non tutto deve diventare cloud e non tutto deve rimanere necessariamente on-premise. Anche qui decidiamo secondo il requisito.

Cloud senza lock-in

Se vengono utilizzati servizi cloud, i dati e le applicazioni devono comunque poter essere:

• esportati;
• migrati;
• ripristinati altrove.

L'infrastruttura deve essere progettata in modo da non rendere il provider una scelta irreversibile.

Container e automazione: dove utili

Tecnologie come container e deployment automatizzati possono migliorare:

• riproducibilità;
• migrazione;
• aggiornamento.

Ma non devono diventare ulteriore complessità fine a se stessa. Il team deve essere capace di gestirle.

La regola rimane: tecnologia proporzionata alla capacità organizzativa.

Una piattaforma che può vivere anche senza il fornitore originario

Questo è forse il test più importante. Immaginiamo che tra cinque anni la società che ha sviluppato un componente:

• non esista più;
• non vinca il nuovo affidamento;
• non voglia più collaborare.

Il Comune deve poter consegnare a un altro soggetto:

• codice;
• documentazione;
• database;
• procedure.

E continuare; se non può farlo, il sistema non è realmente sotto controllo pubblico.

Contratti con uscita prevista fin dall'inizio

Possiamo chiamare questa strategia:

exit by design

Ogni contratto tecnologico importante deve prevedere già all'inizio:

• come recuperare i dati;
• come trasferire il servizio;
• quale documentazione ricevere;
• quale codice consegnare;
• come effettuare la migrazione.

Non aspettiamo la fine del contratto per scoprire come uscirne.

Nessuna black box indispensabile

In alcune situazioni potremo utilizzare componenti proprietari ma dovremmo evitare che una black box diventi il cuore indispensabile dell'infrastruttura. Se un componente proprietario sparisce, il sistema deve poter continuare oppure essere sostituito ragionevolmente.

Costi trasparenti

La scelta del Software Libero deve essere valutata attraverso il costo totale di possesso.

Non solo licenze. Anche:

• personale;
• sviluppo;
• server;
• supporto;
• formazione;
• migrazioni;
• manutenzione.

Confrontiamo quindi soluzioni differenti su un periodo pluriennale. Questo rende la decisione più seria e difendibile.

Il valore del riuso deve entrare nel bilancio

Se spendiamo 40.000 euro per sviluppare un modulo che può essere utilizzato per dieci anni e da altre amministrazioni, il valore pubblico non coincide soltanto con il primo utilizzo. Dovremmo imparare a considerare anche:

• riuso;
• vita utile;
• riduzione delle dipendenze.

Non sempre è facilmente monetizzabile ma è reale.

Codice come patrimonio pubblico

Normalmente pensiamo al patrimonio comunale come:

• edifici;
• terreni;
• mezzi;
• infrastrutture.

In un progetto digitale dovremmo aggiungere:

• codice;
• schemi dati;
• documentazione;
• procedure.

Sono beni immateriali ma possono avere un enorme valore operativo.

L'inventario del software

Salerno Verde dovrebbe quindi mantenere anche un piccolo:

Inventario Software

Per ogni componente:

• nome;
• funzione;
• versione;
• licenza;
• repository;
• responsabile;
• dipendenze;
• stato di manutenzione.

In questo modo evitiamo che dopo anni nessuno sappia più quali strumenti sostengano il sistema.

La Software Bill of Materials

Per i componenti più importanti potrebbe essere utile mantenere anche una lista delle principali dipendenze software.

Questo aiuta soprattutto:

• sicurezza;
• aggiornamenti;
• gestione delle vulnerabilità.

Non serve trasformare il progetto in un laboratorio di compliance ma serve sapere da cosa dipende ciò che utilizziamo.

Roadmap tecnologica

La tecnologia deve avere una pianificazione propria. Non sapere soltanto cosa sviluppare. Anche:

• cosa aggiornare;
• cosa sostituire;
• cosa dismettere.

Una:

Roadmap Tecnologica Salerno Verde

potrebbe essere aggiornata annualmente insieme al Piano.

Dismettere è normale

Un buon sistema non conserva ogni tecnologia per sempre perchè inevitabilmente alcuni componenti diventeranno obsoleti.

Dovremo poterli eliminare senza perdere i dati. Questo è un altro vantaggio dell'architettura modulare e degli standard aperti.

Niente software zombie

Un piccolo strumento creato per un progetto pilota può smettere di essere utile e non deve essere mantenuto artificialmente per venticinque anni. Possiamo:

• archiviarlo;
• documentarlo;
• disattivarlo.

La sostenibilità digitale significa anche sapere cosa non mantenere.

L'accessibilità del codice non basta

Un repository pubblico pieno di codice incomprensibile non produce automaticamente riuso. Servono:

• documentazione;
• esempi;
• installazione semplice;
• licenza;
• issue tracker.

L'obiettivo deve essere che un tecnico esterno possa ragionevolmente comprendere come riutilizzare il progetto.

Scrivere anche in italiano

La documentazione tecnica potrà naturalmente utilizzare terminologia internazionale ma una parte essenziale dovrebbe essere disponibile anche in italiano. Soprattutto:

architettura;

• procedure operative;
• guide per gli amministratori;
• documentazione per i cittadini.

Il Software Libero è davvero riusabile quando la conoscenza non è riservata a pochi specialisti.

Comunità locale del Software Libero

Salerno Verde potrebbe creare occasioni di collaborazione anche con:

• associazioni;
• gruppi di utenti GNU/Linux;
• sviluppatori locali;
• comunità open source.

Non affidando loro responsabilità amministrative ma coinvolgendoli in:

• test;
• laboratori;
• feedback;
• documentazione;
• eventi di sviluppo.

Il progetto pubblico può dialogare con la comunità dalla quale molti degli strumenti utilizzati provengono.

Un laboratorio permanente, non un evento

Più che un singolo hackathon, potrebbe essere interessante un:

Laboratorio Software Libero Salerno Verde

periodico.

Un luogo nel quale tecnici pubblici, studenti e comunità possano lavorare su problemi reali. Per esempio:

• visualizzare meglio la chioma urbana;
• migliorare un modulo;
• documentare una API;
• realizzare una funzione di accessibilità.

Piccoli problemi, risultati concreti.

Tutto deve tornare nel progetto

Ogni attività collaborativa deve produrre risultati che possano essere:

• revisionati;
• documentati;
• eventualmente integrati.

Altrimenti rimane soltanto un evento. Il valore sta nella continuità.

Acquistare servizio, non dipendenza

Quando serve supporto esterno, il Comune può acquistare:

• sviluppo;
• assistenza;
• formazione;
• hosting;
• sicurezza.

Ma deve cercare di non acquistare dipendenza esclusiva. Più soggetti dovrebbero poter offrire supporto sullo stesso sistema.

È anche una forma di concorrenza più sana.

Il fornitore migliore non è quello insostituibile

Anzi. Un buon fornitore dovrebbe consegnare:

• codice chiaro;
• documentazione;
• formazione;
• procedure.

rendendo possibile, alla fine, che il Comune possa scegliere liberamente se continuare con lui.

La qualità della relazione non dovrebbe dipendere dall'impossibilità di andarsene.

Software Libero e appalti

Questa strategia richiederà particolare attenzione nella scrittura degli atti di gara. Specificare:

• standard;
• interoperabilità;
• sorgenti;
• licenze;
• portabilità;
• documentazione;
• assenza di vincoli ingiustificati.

Le competenze giuridiche e tecniche devono lavorare insieme. La sovranità tecnologica si costruisce anche nei capitolati.

Non richiedere marchi, richiedere funzioni

Quando possibile, i capitolati dovrebbero descrivere:

• funzioni;
• prestazioni;
• standard;
• interoperabilità.

non un determinato prodotto, salvo motivazioni tecniche legittime. Questo favorisce:

• concorrenza;
• riuso;
• soluzioni alternative.

Dati e codice rimangono separati

Il codice può essere pubblico. Alcuni dati no. L'architettura deve mantenere chiaramente questa separazione.

Possiamo rendere pubblico tutto il software della piattaforma di segnalazione senza rendere pubblici:

• nomi;
• email;
• dati personali dei segnalanti.

Apertura del codice e protezione dei dati sono perfettamente compatibili.

Una strategia di lungo periodo

Tra oggi e il 2050 il panorama tecnologico cambierà radicalmente. Non possiamo scegliere oggi il software che utilizzeremo tra venticinque anni ma possiamo però scegliere principi che rimarranno validi:

• dati portabili;
• standard aperti;
• codice accessibile;
• documentazione;
• modularità;
• competenze interne;
• assenza di dipendenze irreversibili.

Questa è la vera strategia tecnologica.

Le tecnologie passano, l'autonomia resta

Forse nel 2045 QGIS, PostGIS o gli altri strumenti oggi disponibili saranno molto diversi, forse utilizzeremo componenti che ancora non esistono. Non importa.

Se abbiamo mantenuto:

• dati;
• standard;
• conoscenza;
• capacità di migrazione,

potremo cambiare tecnologia senza perdere il progetto.

Un principio di prudenza digitale

Ogni nuova tecnologia dovrebbe quindi rispondere a cinque domande:

• ci serve davvero?
• possiamo controllarla?
• possiamo esportare i dati?
• possiamo sostituirla?
• possiamo mantenerla nel tempo?

Se la risposta a più di una domanda è no, dobbiamo riflettere prima di adottarla.

Il Minimo Software Utile

Come per il sistema informativo, applichiamo il principio incrementale. Non sviluppiamo subito una piattaforma gigantesca ma partiamo da:

• database;
• mappa;
• registro progetti;
• dataset;
• segnalazioni.

Automatizziamo ciò che produce un vantaggio concreto. Il software cresce insieme alle necessità.

Il codice non deve precedere il processo

Un altro errore frequente: sviluppare un'applicazione per un procedimento amministrativo non ancora definito. Prima dobbiamo sapere:

• chi riceve la segnalazione?
• chi la verifica?
• quali stati possiede?
• entro quali tempi?

Solo dopo traduciamo il processo in software. Altrimenti digitalizziamo la confusione.

Digitalizzare significa anche semplificare

Prima di automatizzare una procedura chiediamoci:

• serve davvero questo passaggio?
• Possiamo eliminare una duplicazione?
• Possiamo recuperare automaticamente un dato?

La trasformazione digitale deve anche ridurre complessità e non soltanto spostarla dallo sportello allo schermo.

Il valore politico del Software Libero

Arriviamo infine al punto più importante. In Salerno Verde il Software Libero non è una preferenza tecnica tra prodotti equivalenti. È coerente con la filosofia complessiva del Piano. Abbiamo detto:

• dati aperti;
• decisioni verificabili;
• partecipazione;
• controllo civico;
• riuso.

Se il software che governa tutto questo rimane completamente chiuso e incontrollabile, esiste una contraddizione.

La tecnologia pubblica deve essere controllabile

Un cittadino non deve necessariamente saper programmare, così come non deve essere ingegnere per attraversare un ponte ma deve esistere la possibilità che:

• esperti;
• università;
• comunità;
• altre amministrazioni

possano verificare e studiare il sistema. La controllabilità è un valore democratico.

Libertà di studiare

Il Software Libero rende possibile capire:

• come funziona una funzione;
• come viene calcolato un indicatore;
• come vengono trasformati i dati.

Questo non sostituisce documentazione e trasparenza amministrativa. Le rafforza.

Libertà di modificare

Se nel 2032 Salerno avrà una necessità nuova, non dovrà necessariamente aspettare che il produttore originario decida di svilupparla. Potrà:

• farlo internamente;
• affidarlo a un altro soggetto;
• collaborare con la comunità.

È una differenza fondamentale.

Libertà di condividere

Se uno strumento funziona, può essere ceduto ad altri Comuni senza nuovi costi di licenza legati alla copia del codice. Il pubblico finanziamento produce così un patrimonio riutilizzabile.

Libertà di cambiare

Forse la libertà più importante per una pubblica amministrazione è proprio questa: poter cambiare fornitore e poter cambiare tecnologia senza perdere ciò che ha costruito.

Il Software Libero, combinato con standard aperti e buona documentazione, rende questa libertà molto più concreta.

Public Money, Public Code come principio Salerno Verde

Possiamo quindi farne uno dei principi ufficiali del progetto:

Quando risorse pubbliche finanziano lo sviluppo di software specifico per Salerno Verde, il codice dovrebbe essere, salvo eccezioni motivate, rilasciato con licenza libera, documentato e reso riusabile.

Non è un dettaglio tecnico. È una regola di gestione del patrimonio pubblico digitale.

Una infrastruttura digitale civica

Il risultato finale che immaginiamo non è soltanto un insieme di programmi.

È una vera:

Infrastruttura Digitale Civica Salerno Verde

costruita con:

• dati aperti;
• software libero;
• standard aperti;
• API;
• documentazione;
• repository pubblici;
• competenze interne;
• collaborazione.

Una infrastruttura che il Comune governa, che i cittadini possono utilizzare, che altri possono riusare, che nessun singolo fornitore può portarsi via alla scadenza di un contratto.

La domanda finale

Quando Salerno acquisterà o svilupperà un nuovo componente tecnologico per il Piano, dovrà quindi chiedersi: questa scelta rende la città più autonoma o più dipendente?

Non sempre la soluzione più aperta sarà automaticamente la migliore ma l'autonomia deve entrare nel bilancio della decisione esattamente come:

• costo;
• sicurezza;
• funzionalità;
• prestazioni.

Non tecnologia per la tecnologia

Salerno Verde non vuole diventare un progetto informatico ma vuole essere un progetto urbano capace di utilizzare bene la tecnologia. Il software deve aiutare a:

• piantare meglio;
• gestire meglio;
• misurare meglio;
• pubblicare meglio;
• partecipare meglio.

Se non produce uno di questi risultati, probabilmente non ci serve.

Dal Software Libero alla città libera di scegliere

Alla fine il collegamento più profondo è questo:

• Proteggiamo il suolo perché una città futura possa ancora scegliere cosa farne.
• Manteniamo aperti i dati perché i cittadini possano conoscerli e riutilizzarli.
• Manteniamo aperto il software perché l'Amministrazione possa modificarlo e sostituirlo.

È la stessa filosofia applicata a livelli differenti: non chiudere oggi tutte le possibilità di domani.

Per questo Salerno Verde considera il Software Libero parte della propria infrastruttura democratica e non perché tutto ciò che è libero sia automaticamente migliore.

Ma perché una città che vuole essere aperta nei dati, partecipativa nelle decisioni e autonoma nella gestione dovrebbe cercare di esserlo anche nel codice che utilizza per governarsi.

Public Money, Public Code.
Open Data, Open Standards, Software Libero.
Autonomia senza isolamento.
Riuso invece di dipendenza.

Questa è la direzione tecnologica di Salerno Verde 2050.