Nel Punto precedente abbiamo stabilito un principio generale: Salerno Verde deve privilegiare Software Libero, standard aperti e sviluppo tecnologico controllabile dall’Amministrazione. Adesso dobbiamo affrontare una questione ancora più concreta.

Quando il Comune finanzia lo sviluppo di software specifico per il progetto, a chi appartiene realmente ciò che viene prodotto? La risposta non può fermarsi alla proprietà contrattuale. Se il codice viene sviluppato con denaro pubblico e serve a gestire un’infrastruttura civica, il suo valore non è soltanto economico. È anche:

• conoscenza;
• capacità amministrativa;
• possibilità di riuso;
• trasparenza;
• autonomia.

Per questo Salerno Verde propone un principio molto netto:

ciò che viene sviluppato con risorse pubbliche dovrebbe, salvo eccezioni motivate, tornare alla collettività sotto forma di codice libero, documentato e riusabile.

Dal software acquistato al software posseduto davvero

Una pubblica amministrazione può pagare per anni un software senza possederne realmente la conoscenza. Può usarlo, può dipendere da esso ma non necessariamente può:

• modificarlo;
• farlo modificare da un altro soggetto;
• riutilizzarlo;
• condividerlo;
• comprenderne il funzionamento interno.

Salerno Verde deve evitare questa situazione. Quando finanzia sviluppo specifico, deve costruire un patrimonio che rimanga disponibile anche dopo la fine del contratto.

Public Money, Public Code

Il principio può essere espresso in una formula ormai molto chiara:

Public Money, Public Code

Se il denaro è pubblico, il codice finanziato con quel denaro dovrebbe essere, quando possibile:

• pubblico;
• accessibile;
• modificabile;
• riutilizzabile.

Non significa ignorare:

• sicurezza;
• diritti di terzi;
• componenti già esistenti;
• vincoli contrattuali legittimi.

significa che l’apertura deve essere considerata la regola da perseguire, non una concessione eventuale.

Il contratto deve prevederlo prima

Questo è il punto più concreto. Se la gara o l’affidamento non stabiliscono fin dall’inizio:

• chi possiede il codice;
• quale licenza verrà utilizzata;
• cosa deve essere consegnato;
• dove sarà mantenuto il repository;
• quale documentazione deve accompagnarlo,

alla fine del progetto potremmo trovarci con un problema difficilmente risolvibile.

La libertà tecnologica si decide nei capitolati, non dopo.

Consegnare il sorgente non basta

Avere una cartella con il codice sorgente non significa possedere realmente il software. Per essere riusabile servono almeno:

• repository completo;
• storia delle versioni;
• documentazione;
• istruzioni di installazione;
• dipendenze;
• schema dati;
• procedure di aggiornamento;
• test;
• licenza.

Un archivio ZIP consegnato alla fine del contratto e mai più aperto non è un patrimonio digitale. È soltanto un deposito.

Il repository deve essere vivo

Il codice dovrebbe essere sviluppato in un sistema di versionamento fin dall’inizio non caricato pubblicamente soltanto alla fine. Il repository dovrebbe permettere di seguire:

• versioni;
• modifiche;
• issue;
• rilasci;
• documentazione.

In questo modo il software possiede una storia verificabile.

Repository sotto controllo pubblico

Anche quando lo sviluppo viene svolto da un fornitore esterno, il repository principale dovrebbe essere controllato dall’Amministrazione o comunque da una infrastruttura sulla quale l’ente mantenga pieni diritti e possibilità di esportazione.

Il fornitore deve contribuire al repository pubblico non diventare l’unico custode del codice.

Una licenza chiara

Il codice deve essere pubblicato con una licenza libera riconosciuta. La scelta specifica dovrà dipendere dal progetto e dalle dipendenze utilizzate. L’importante è evitare formule vaghe come: “codice pubblico” oppure “open source” senza indicare i diritti effettivi.

La licenza deve chiarire:

• uso;
• modifica;
• redistribuzione;
• eventuali obblighi.

La licenza non può essere un’aggiunta tardiva

Se durante lo sviluppo vengono utilizzate librerie con determinate condizioni, queste possono influenzare la licenza finale e per questo la politica delle licenze deve essere definita all’inizio. Anche il fornitore deve sapere quali componenti può introdurre.

Evitare dipendenze incompatibili

Un software che vogliamo pubblicare liberamente potrebbe diventare difficile da distribuire se integra parti proprietarie non separabili o licenze incompatibili. La progettazione deve quindi considerare fin dall’inizio anche la compatibilità delle dipendenze.

È un tema tecnico ma ha conseguenze politiche sulla riusabilità.

Componenti preesistenti

Naturalmente non tutto il codice di un sistema deve essere stato finanziato dal Comune. Una parte può derivare da:

• framework;
• librerie;
• software libero esistente;
• componenti commerciali.

Dobbiamo distinguere chiaramente: ciò che esisteva già da ciò che viene sviluppato specificamente con risorse pubbliche.

Sul secondo elemento l’interesse pubblico all’apertura è particolarmente forte.

Nessun diritto esclusivo non necessario

Se il Comune finanzia una nuova funzionalità generica, non dovrebbe concedere automaticamente al fornitore un diritto esclusivo che impedisca ad altri di riutilizzarla. Al contrario, il riuso può moltiplicare il valore dell’investimento pubblico.

Un modulo sviluppato a Salerno può servire altrove

Immaginiamo un modulo per:

• gestire gli alberi;
• tracciare segnalazioni;
• calcolare indicatori;
• monitorare progetti.
• Se viene sviluppato in maniera sufficientemente generica, potrebbe essere riutilizzato da:
• un altro Comune;
• una Unione di Comuni;
• una università;
• una associazione.

Il denaro speso una volta produce valore molte volte.

Anche Salerno può riusare il codice altrui

Il principio funziona naturalmente in entrambe le direzioni. Prima di finanziare un nuovo sviluppo dovremmo verificare se un’altra amministrazione abbia già pubblicato qualcosa di adatto. Se esiste:

• riusiamo;
• adattiamo;
• contribuiamo.

Non reinventiamo.

Riuso come requisito progettuale

Potremmo quindi aggiungere una domanda obbligatoria a ogni nuovo sviluppo: questa funzione è specifica di Salerno oppure può essere progettata in modo riutilizzabile?

Se può esserlo senza costi sproporzionati, preferiamo una architettura più generica. Questo aumenta il valore pubblico dell’investimento.

Il codice deve essere comprensibile

Riusabilità significa anche qualità.

• Nomi chiari.
• Architettura comprensibile.
• Documentazione.
• Test.
• Standard di sviluppo.

Un codice tecnicamente aperto ma impossibile da mantenere rimane di fatto chiuso a chi non lo ha scritto.

Standard di qualità minimi

Per gli sviluppi significativi potremmo richiedere:

• documentazione;
• linting;
• test automatici dove appropriati;
• versionamento;
• gestione delle dipendenze;
• procedure di rilascio.

Non per trasformare ogni piccolo script in un grande progetto industriale ma per evitare software fragile.

Codice e infrastruttura non sono la stessa cosa

Un’applicazione può essere libera ma dipendere da:

• database proprietario;
• servizio cloud chiuso;
• API non controllabili.

Questo ne limita il riuso. Per questo dobbiamo valutare l’intera catena tecnologica.

• Software.
• Dati.
• Servizi.
• Infrastruttura.

Tutto deve essere progettato per ridurre dipendenze non necessarie.

Infrastructure as Code, dove utile

Per i sistemi più strutturati può essere utile documentare anche una parte della configurazione dell’infrastruttura attraverso strumenti automatizzati. Questo permette di:

• riprodurre ambienti;
• migrare;
• ridurre errori;
• documentare.

Ma vale sempre la regola della proporzionalità. Non aggiungiamo complessità soltanto per seguire una moda tecnologica.

Il codice di configurazione può essere patrimonio

Molto del lavoro reale di un sistema non sta soltanto nell’applicazione. Sta nelle configurazioni.

• Schema del database.
• Servizi.
• Automazioni.
• Script.

anche questi elementi dovrebbero essere versionati e documentati.

Separare i segreti dal codice

Repository aperto e sicurezza devono convivere. Mai pubblicare:

• password;
• token;
• chiavi private;
• credenziali;
• configurazioni sensibili.

I segreti devono essere gestiti separatamente. È un principio elementare ma essenziale.

La documentazione del deploy

Se il sistema viene installato soltanto dal fornitore e nessuno conosce la procedura, il codice aperto serve a poco. Servono istruzioni per:

• installazione;
• aggiornamento;
• backup;
• ripristino.

Il Comune deve poter consegnare il progetto a un altro soggetto senza dover ricostruire da zero la conoscenza.

Exit by design

Riprendiamo quindi il principio introdotto nel capitolo precedente. Ogni contratto tecnologico deve essere progettato sapendo già come potrà terminare. Alla fine devono rimanere:

• codice;
• dati;
• documentazione;
• procedure;
• competenze.

Possiamo chiamarlo:

exit by design

Il modo migliore per essere liberi di continuare con un buon fornitore è sapere che possiamo anche cambiarlo.

Nessun costo per riscattare il proprio codice

Dobbiamo evitare situazioni nelle quali, alla fine di un contratto, l’Amministrazione debba pagare ulteriormente per ottenere:

• sorgenti;
• database;
• specifiche

di un sistema che ha già finanziato. I diritti devono essere definiti prima.

Manutenzione aperta alla concorrenza

Se il software è documentato e libero, la manutenzione può essere affidata nel tempo a soggetti differenti. Questo aumenta:

• concorrenza;
• libertà di scelta;
• capacità negoziale dell’Amministrazione.

Il fornitore originario può continuare a essere il migliore ma deve esserlo per qualità. Non perché nessun altro può intervenire.

Il codice pubblico può essere controllato

L’apertura produce anche una possibilità ulteriore. Esperti indipendenti possono:

• studiare;
• segnalare errori;
• proporre miglioramenti;
• verificare algoritmi.

Naturalmente questo non sostituisce audit professionali quando necessari ma aumenta la superficie di controllo.

Responsible disclosure

Se il codice è pubblico, dovremo anche prevedere un canale chiaro per segnalare vulnerabilità di sicurezza. Non ogni problema deve essere pubblicato immediatamente come issue visibile. Serve una procedura di responsible disclosure. L’apertura deve essere accompagnata da buone pratiche di sicurezza.

Security policy

Ogni componente importante potrebbe avere una breve policy che spieghi:

• come segnalare vulnerabilità;
• quali versioni sono supportate;
• come vengono gestiti gli aggiornamenti.

Anche questa è documentazione.

Il codice degli algoritmi decisionali

Particolare attenzione dovremo riservare al software che produce:

• indicatori;
• punteggi;
• priorità.

Se un algoritmo contribuisce alla decisione su dove investire, il suo codice e la metodologia dovrebbero essere, per quanto possibile, pubblici.

Il cittadino deve poter replicare

Immaginiamo che il sistema dica: “Quartiere A ha priorità 87/100”. Un ricercatore dovrebbe poter prendere:

• dataset;
• formula;
• codice

e, in condizioni equivalenti, ottenere lo stesso risultato. Questo è un livello di trasparenza molto più profondo del semplice mostrare un numero.

Le decisioni politiche rimangono fuori dall’algoritmo

La pubblicazione del codice rende anche più facile distinguere: cosa ha calcolato il sistema da cosa ha deciso l’Amministrazione.

Se la politica sceglie un intervento differente da quello suggerito dall’indice, può motivarlo. La trasparenza rende la responsabilità più chiara.

Non tutto il software deve essere sviluppato dal Comune

Torniamo al realismo. Un sistema può utilizzare servizi e componenti già disponibili. La regola Public Money, Public Code riguarda soprattutto lo sviluppo specificamente finanziato con risorse pubbliche non significa che ogni componente utilizzato debba essere scritto internamente.

Acquistare supporto è legittimo

Software Libero non significa rinunciare all’assistenza professionale. Al contrario. Il Comune può acquistare:

• supporto;
• installazione;
• sviluppo;
• manutenzione;
• formazione.

La differenza è che il servizio viene acquistato senza cedere necessariamente il controllo del patrimonio digitale.

Il valore è nel servizio, non nella prigionia

Un’impresa può costruire un modello economico perfettamente sostenibile intorno a Software Libero. Il valore che vende è:

• competenza;
• affidabilità;
• rapidità;
• supporto.

non il fatto che il cliente non possa andarsene. È un modello che può funzionare bene anche per la Pubblica Amministrazione.

Codice pubblico non significa manutenzione pubblica gratuita

È importante chiarirlo: pubblicare il sorgente non significa che qualcuno lo manterrà gratuitamente. Serve comunque una politica di manutenzione:

• Issue.
• Aggiornamenti.
• Release.
• Sicurezza.
• Risorse.

Il Software Libero crea libertà non elimina il lavoro.

Un maintainer pubblico

Per ogni componente specificamente sviluppato per Salerno Verde dovrebbe essere individuata almeno una responsabilità organizzativa. Chi decide:

• quali modifiche accettare?
• quale versione rilasciare?
• quando aggiornare?

Non necessariamente una sola persona ma una funzione deve esistere.

Governance del repository

Se il progetto riceve contributi esterni, servono regole semplici.

• Come si propone una modifica?
• Chi la revisiona?
• Quali standard?
• Come si decide?

La collaborazione aperta funziona quando possiede una governance comprensibile.

Un modello semplice

Per progetti piccoli può bastare:

• issue;
• pull request;
• review;
• merge.

Niente strutture complesse. L’obiettivo è permettere collaborazione senza perdere controllo sulla qualità.

Contributor guidelines

Una breve guida può spiegare:

• come segnalare un bug;
• come proporre una funzione;
• come contribuire al codice;
• come contribuire alla documentazione.

Questo abbassa la barriera per chi vuole partecipare.

Non solo sviluppatori

Una comunità software non è fatta soltanto di programmatori.

Si può contribuire attraverso:

• documentazione;
• traduzioni;
• accessibilità;
• test;
• design;
• segnalazioni;
• esempi.

Salerno Verde dovrebbe riconoscere anche questi contributi.

L’accessibilità va verificata nel codice

Se sviluppiamo una piattaforma civica, l’accessibilità non deve essere un controllo finale. Deve entrare:

• nei componenti;
• nei test;
• nelle linee guida.

Un software pubblico che esclude una parte dei cittadini contraddice la funzione democratica del progetto.

Internationalizzazione e localizzazione

Se lo strumento viene progettato bene, potrebbe essere utilizzato anche altrove. La separazione tra:

• codice;
• testi;
• configurazioni;
• dati locali

facilita il riuso.

Non serve rendere ogni piccolo script internazionale ma per applicazioni strutturali può valerne la pena.

Configurazione invece di fork

Un altro principio importante. Quando altri Comuni riusano il software, dovrebbero poter adattare:

• logo;
• nome;
• categorie;
• workflow;
• confini territoriali

attraverso configurazioni, per quanto possibile.

Ma non bisogna creare una nuova versione separata per ogni città. Questo riduce enormemente i costi di manutenzione.

Il Comune può beneficiare delle migliorie altrui

Se il software viene riusato altrove, un’altra amministrazione potrebbe finanziare una funzione nuova. Se il progetto rimane comune, Salerno potrà beneficiarne. Il riuso diventa quindi co-sviluppo distribuito.

Un bene pubblico digitale

A questo punto possiamo utilizzare una definizione più ambiziosa. Il software prodotto potrebbe diventare un:

bene pubblico digitale

non nel senso giuridico stretto del termine, ma come infrastruttura immateriale:

• aperta;
• riusabile;
• non rivale;

capace di produrre valore oltre il progetto originario.

L’economia locale può partecipare

L’apertura non penalizza necessariamente le imprese locali. Al contrario se il sistema utilizza tecnologie aperte, più professionisti e aziende possono offrire:

• supporto;
• sviluppo;
• formazione;
• integrazione.

Una piattaforma chiusa concentra spesso la capacità di intervento mentre una piattaforma aperta può creare un ecosistema di competenze.

Competenze locali invece di rendite tecnologiche

Questo è uno dei possibili benefici economici. Spendere risorse per:

• formazione;
• sviluppatori;
• sistemisti;
• GIS;
• data engineer

costruisce competenze che rimangono nel territorio. Spendere tutto in canoni non necessariamente produce lo stesso effetto.

Ma niente localismo tecnologico

Non dobbiamo però scegliere un fornitore soltanto perché locale.

• Qualità.
• Sicurezza.
• Competenza.
• Costo.

devono rimanere criteri fondamentali. Il valore strategico è sviluppare un ecosistema aperto nel quale anche soggetti locali possano competere.

Misurare il riuso

In futuro potremmo addirittura monitorare:

• numero di componenti pubblicati;
• riusi da parte di altri enti;
• contributi ricevuti;
• componenti esterni riutilizzati da Salerno.

Non come principale indicatore del Piano ma come misura dell’impatto della strategia digitale.

Un catalogo del codice

Accanto al catalogo Open Data potremmo avere un:

Catalogo Software Salerno Verde

con:

• nome del progetto;
• funzione;
• repository;
• licenza;
• versione;
• stato;
• documentazione;
• modalità di riuso.

Un cittadino o un altro ente trova immediatamente ciò che è disponibile.

Codice attivo e codice archiviato

Non tutto rimarrà mantenuto per sempre. Distinguiamo:

Attivo

• In manutenzione limitata
• Archiviato
• Sostituito

Un progetto archiviato può continuare a essere pubblico ma nessuno deve pensare che riceva ancora aggiornamenti.

La conservazione digitale

Per componenti importanti dovremo garantire anche una forma di conservazione.

• Repository clonabili.
• Release.
• Documentazione esportabile.

Il patrimonio non deve dipendere dall’esistenza futura di una singola piattaforma di hosting.

Copie e backup dei repository

Se utilizziamo una piattaforma esterna per ospitare il codice, l’Amministrazione dovrebbe comunque mantenere:

• backup;
• mirror;
• possibilità di esportazione.

Anche l’hosting non deve diventare una nuova forma di lock-in.

Firma e provenienza dei rilasci

Per i componenti più importanti potremmo adottare pratiche che permettano di verificare la provenienza delle release.

La sicurezza della catena di distribuzione software sarà sempre più importante.

Non è necessario complicare i piccoli strumenti ma per l’infrastruttura centrale il tema va previsto.

Dipendenze aggiornate

Il codice pubblico permette a tutti di vedere le dipendenze ma serve qualcuno che le aggiorni. La manutenzione deve prevedere controlli periodici su:

• librerie obsolete;
• vulnerabilità;
• versioni non più supportate.

Non possiamo aspettare che un aggiornamento diventi un’emergenza.

Il ciclo di vita del software

Anche il software, come gli alberi, possiede un ciclo di vita. Nasce --> Cresce --> Viene mantenuto --> Talvolta deve essere sostituito.

La similitudine non è soltanto retorica; Salerno Verde deve pianificare la manutenzione digitale esattamente come quella fisica.

Ogni nuovo software genera un costo futuro

Prima di sviluppare un nuovo componente chiediamo quindi:

• chi lo manterrà?
• per quanto tempo?
• con quale costo?
• con quali competenze?

È la stessa domanda che abbiamo posto per un nuovo parco. Se non sappiamo rispondere, forse non dobbiamo ancora svilupparlo.

Meglio meno codice, mantenuto bene

La filosofia rimane quella già utilizzata per gli alberi e i dataset. Meglio:

• pochi componenti;
• ben documentati;
• ben mantenuti;
• riutilizzabili

che decine di microapplicazioni abbandonate.

Il software pubblico non deve diventare archeologia digitale

Una città può accumulare negli anni:

• portali;
• app;
• database;
• micrositi.

Molti smettono di essere aggiornati eSalerno Verde deve evitare questo destino.

Ogni anno:

• cosa utilizziamo?
• cosa possiamo consolidare?
• cosa va dismesso?

ed anche eliminare tecnologia può essere una buona decisione.

Prima consolidare, poi aggiungere

Se due componenti svolgono quasi la stessa funzione, valutiamo l’unificazione. Meno sistemi significano:

• meno aggiornamenti;
• meno superfici di attacco;
• meno formazione;
• meno costi.

Una infrastruttura che può essere capita

Il vero obiettivo di tutta questa strategia può essere riassunto in una frase: nessuna parte essenziale di Salerno Verde dovrebbe dipendere da qualcosa che il Comune non è in grado almeno di comprendere, documentare e sostituire.

Non è necessario conoscere ogni dettaglio. Serve controllo sufficiente.

Autonomia tecnologica come capacità di scelta

È importante usare bene il termine perchè Autonomia non significa non dipendere da nessuno. Ogni sistema tecnologico dipende da:

• comunità;
• fornitori;
• hardware;
• connettività;
• competenze.

Autonomia significa mantenere la possibilità di scegliere tra alternative.

Il valore democratico della possibilità di cambiare

Una futura amministrazione potrebbe preferire:

• un’altra interfaccia;
• un altro fornitore;
• un altro sistema di hosting.

Deve poter cambiare senza distruggere la base informativa e senza dover ricomprare ciò che la città ha già finanziato. Anche questa è libertà democratica.

Il codice come memoria istituzionale

Dentro il software vengono spesso incorporate decisioni.

• Workflow.
• Categorie.
• Regole.
• Calcoli.

Il repository documentato conserva quindi anche una parte della storia del progetto. Tra quindici anni potremo capire:

• come funzionava la piattaforma nel 2030;
• quali criteri utilizzava;
• quando sono cambiati.

Il codice diventa anche memoria amministrativa.

Non sostituire gli atti con il codice

Naturalmente le regole amministrative devono continuare a essere espresse negli atti appropriati. Il codice implementa non legifera.

Se esiste una differenza tra: regolamento e software, prevale l’atto amministrativo. È importante mantenere la gerarchia chiara.

Trasparenza anche sulle eccezioni

Potrebbero esistere casi nei quali un componente non possa essere pubblicato. Per esempio per diritti preesistenti o ragioni di sicurezza. In quei casi la scelta dovrebbe essere:

• specifica;
• motivata;
• limitata.

Non trasformare l’eccezione in regola generale.

Il criterio proporzionale

Non richiediamo la pubblicazione di codice dove non esiste sviluppo specifico finanziato. Se acquistiamo semplicemente un servizio standard, la situazione può essere differente. La strategia deve essere pragmatica. Il punto centrale rimane: quando il pubblico finanzia la creazione di un patrimonio software, dovrebbe cercare di conservarlo come patrimonio pubblico riusabile.

Da consumatori a produttori

Storicamente molte amministrazioni acquistano tecnologia come qualsiasi altro prodotto. Salerno Verde propone di aggiungere un ruolo. Quando serve, la Pubblica Amministrazione può diventare: committente consapevole e talvolta: produttrice di beni digitali riusabili. È un salto culturale importante.

Una politica del codice pubblico

Questa impostazione potrebbe essere formalizzata in una:

Policy del Codice Salerno Verde

basata su pochi principi:

• Riuso prima dello sviluppo.
• Sorgente disponibile per lo sviluppo finanziato pubblicamente, salvo eccezioni motivate.
• Licenze libere chiare.
• Repository controllabile dall’Amministrazione.
• Documentazione obbligatoria.
• Standard aperti.
• Portabilità.
• Sicurezza by design.
• Manutenzione programmata.
• Contributo upstream quando possibile.

Non serve essere una grande città tecnologica

Questa strategia non richiede una gigantesca struttura informatica ma può partire da pochi progetti:

• Uno script.
• Un modulo.
• Una dashboard.

Documentati bene e pubblicati. La cultura precede la dimensione.

Il primo progetto libero

Uno dei primi sviluppi specifici di Salerno Verde potrebbe diventare un caso pilota. Potremmo documentare:

• requisiti;
• gara o sviluppo;
• repository;
• licenza;
• rilascio;
• costo;
• riuso.

Un esempio concreto servirà molto più di decine di dichiarazioni sul Software Libero.

Imparare facendo

Anche qui il principio è: SPERIMENTA → DOCUMENTA → CORREGGI → STANDARDIZZA.

Il primo progetto ci insegnerà:

• quali clausole contrattuali funzionano;
• quale documentazione manca;
• quali competenze servono.

Poi miglioriamo il modello.

Una città che restituisce codice

Il risultato più interessante sarebbe vedere un giorno un’altra amministrazione scrivere: “Questo componente deriva dal progetto Salerno Verde del Comune di Salerno.” A quel punto una spesa sostenuta dai cittadini salernitani avrebbe prodotto valore anche fuori dal territorio. E magari un miglioramento sviluppato altrove potrebbe tornare a Salerno. È la logica del bene comune digitale.

Public Money, Public Code non è beneficenza

Condividere il codice non significa regalare qualcosa che avrebbe potuto produrre un grande profitto per il Comune. Normalmente un ente pubblico non ha come missione vendere licenze software. La sua missione è produrre servizi e valore pubblico ed il riuso può aumentare proprio quel valore.

Il pubblico non deve pagare più volte lo stesso sviluppo

Se dieci amministrazioni hanno lo stesso problema e ognuna paga separatamente un prodotto equivalente chiuso, il sistema pubblico nel suo complesso sostiene dieci costi.

Se un progetto viene condiviso e migliorato, parte della spesa può diventare cumulativa invece che duplicata. È anche una politica di efficienza.

Il software come infrastruttura comune

Alla fine il codice non è il protagonista. Il protagonista rimane Salerno Verde.

Ma senza software:

• gestiremo peggio i dati;
• misureremo peggio;
• parteciperemo peggio;
• dipenderemo maggiormente dai fornitori.

Per questo il codice entra nell’infrastruttura. Non come fine ma come strumento di autonomia e cooperazione.

Il principio conclusivo

Quando Salerno Verde finanzierà un nuovo software dovremo quindi chiedere: Possiamo riusare qualcosa che esiste?

Se no: possiamo sviluppare ciò che serve in modo aperto?

E una volta sviluppato: possiamo far sì che ciò che abbiamo pagato rimanga alla città e possa essere utile anche ad altri?

Se la risposta è sì, quella deve essere la strada preferita.

Perché il denaro pubblico non dovrebbe produrre soltanto un servizio temporaneo, dovrebbe, quando possibile, lasciare un patrimonio. Un patrimonio che può essere:

• letto;
• studiato;
• modificato;
• riutilizzato;
• migliorato.

E che continua a esistere anche quando il contratto finisce.

Questo significa, per Salerno Verde: Public Money, Public Code.

Non soltanto Software Libero. Software pubblico come bene comune digitale.