Software Libero, standard aperti e autonomia

Quando una città sceglie come raccogliere, organizzare e pubblicare i propri dati, non sta compiendo soltanto una scelta tecnica. Sta decidendo anche:

• chi può controllare gli strumenti;
• quanto sarà semplice modificarli;
• quanto costerà mantenerli;
• se sarà possibile cambiare fornitore;
• se i dati potranno essere esportati;
• se il codice potrà essere verificato;
• se altri soggetti potranno riutilizzare quanto è stato realizzato.

Per questo la tecnologia non è un elemento secondario del progetto ma è parte della sua architettura istituzionale.

Software Libero: che cosa significa davvero

Parlare di Software Libero non significa semplicemente dire che un programma è gratuito. Il punto centrale è tutt' altro.

Un software libero permette, secondo la licenza con cui viene distribuito, di:

• utilizzarlo;
• studiarne il funzionamento;
• modificarlo;
• redistribuirlo;
• condividere le modifiche.

Queste libertà cambiano profondamente il rapporto tra chi utilizza il software e chi lo produce.

• Il codice non è una scatola completamente chiusa.
• Può essere verificato.
• Può essere adattato.
• Può essere mantenuto anche da soggetti differenti.

Gratuito e libero non sono sinonimi

Un software può essere gratuito e completamente proprietario. Può essere utilizzato senza pagare una licenza iniziale ma lasciare l'utente dipendente:

• dal produttore;
• dalla piattaforma;
• dalle condizioni contrattuali;
• dal formato dei dati.

Al contrario, un software libero può richiedere costi importanti per:

• installazione;
• configurazione;
• personalizzazione;
• manutenzione;
• assistenza;
• formazione.

Il Software Libero non elimina i costi. Cambia il luogo dove si trovano i costi e chi controlla ciò che viene realizzato.

Il costo corretto da misurare

Quando confrontiamo soluzioni differenti non dovremmo quindi chiederci soltanto quanto costa la licenza? Dovremmo valutare il costo complessivo nel tempo.

• Acquisto.
• Installazione.
• Personalizzazione.
• Formazione.
• Aggiornamenti.
• Assistenza.
• Migrazioni.
• Esportazione dei dati.
• Cambio di fornitore.
• Eventuale dismissione.

Un software apparentemente economico può diventare molto costoso se rende difficile uscire dal sistema.

Il problema della dipendenza dal fornitore

Un'amministrazione può trovarsi in una situazione nella quale soltanto il fornitore originario conosce realmente il sistema. Per modificare una funzione deve rivolgersi a lui, per esportare i dati deve rivolgersi a lui, per integrare un servizio deve rivolgersi a lui, per migrare deve rivolgersi a lui.

Questa dipendenza viene spesso indicata come vendor lock-in. Non è soltanto un problema economico ma è un problema di autonomia.

La vera domanda: possiamo cambiare?

Un buon sistema dovrebbe permettere di rispondere positivamente a una domanda semplice: se domani decidiamo di cambiare tecnologia o fornitore, possiamo farlo senza perdere dati, conoscenza e capacità operativa?

Se la risposta è no, abbiamo costruito una dipendenza. Se la risposta è sì, abbiamo costruito maggiore autonomia.

Il Software Libero riduce una parte del rischio

La disponibilità del codice sorgente permette, almeno in linea di principio, che soggetti diversi possano:

• comprendere;
• manutendere;
• correggere;

il sistema. L'amministrazione non è necessariamente obbligata a continuare per sempre il rapporto con chi ha realizzato la prima installazione.

• Può affidare attività successive a soggetti differenti.
• Può sviluppare internamente alcune competenze.
• Può collaborare con comunità e altri enti.

Questo non elimina ogni forma di dipendenza ma riduce la possibilità che il controllo del sistema sia completamente nelle mani di un solo fornitore.

Libero non significa senza responsabilità

È importante evitare un equivoco opposto. Scegliere Software Libero non significa installare un programma e abbandonarlo. Un'infrastruttura pubblica ha bisogno di:

• aggiornamenti;
• sicurezza;
• backup;
• monitoraggio;
• manutenzione;
• documentazione;
• responsabilità.

Il Software Libero fornisce libertà. Quelle libertà devono però essere accompagnate da capacità organizzativa.

La libertà senza competenza serve a poco

Possedere il codice sorgente è utile soltanto se esiste la possibilità concreta di comprenderlo e utilizzarlo. Per questo un progetto di autonomia digitale deve prevedere anche:

• documentazione;
• formazione;
• competenze interne;
• contratti ben progettati;
• procedure di manutenzione.

La sovranità tecnologica non nasce dalla licenza da sola ma dalla combinazione di:

software + dati + standard + competenze + organizzazione.

Standard aperti prima ancora del software

Il Software Libero è importante ma da solo non basta. Possiamo utilizzare un programma libero e memorizzare i dati in un formato poco documentato o possiamo utilizzare un programma proprietario ma esportare facilmente informazioni in standard aperti. Le due dimensioni devono essere distinte.

Per garantire continuità nel tempo servono soprattutto:

formati aperti;
standard documentati;
API documentate;
modelli dei dati conosciuti;
possibilità di esportazione.

Il software è uno strumento. Il patrimonio da proteggere è soprattutto la conoscenza.

Che cosa sono gli standard aperti

Uno standard aperto è una specifica pubblicamente disponibile che permette a soggetti differenti di implementarla senza dipendere da una singola tecnologia chiusa. Nel nostro progetto possiamo incontrare standard per:

• formati dei file;
• rappresentazione geografica;
• date e orari;
• scambio dei dati;
• vocabolari;
• metadati;
• API.

Quando sistemi differenti utilizzano regole condivise, comunicare diventa più semplice.

Lo standard è più importante del programma

Supponiamo che oggi utilizziamo un determinato CMS. Domani potremmo sostituirlo.

Se i dati sono esportabili in formati aperti e il modello è documentato, il cambiamento può essere gestibile, se invece l'intera informazione dipende da strutture proprietarie comprensibili soltanto dal vecchio sistema, la migrazione diventa molto più difficile.

Per questo possiamo formulare un principio: il software può cambiare; il dato deve poter rimanere.

La durata del dato e la durata del software

• Un'applicazione può durare cinque anni.
• Un portale dieci.
• Un dataset storico può avere valore per cinquanta.

Pensiamo ai dati sulle presenze turistiche: il loro valore aumenta proprio perché possiamo confrontare periodi differenti. Non possiamo permettere che una serie storica diventi illeggibile perché il software che l'aveva prodotta non esiste più. La conservazione della conoscenza deve essere progettata su tempi più lunghi della vita del singolo programma.

Autonomia non significa isolamento

Parlare di autonomia digitale non significa costruire tutto in casa. Una città può utilizzare:

• servizi esterni;
• cloud;
• fornitori;
• consulenti;
• software sviluppato altrove.

L'autonomia consiste nel mantenere la possibilità di:

• scegliere;
• cambiare;
• esportare;
• verificare;
• interoperare.

Non dobbiamo possedere ogni componente ma dobbiamo evitare che una componente diventi indispensabile e insostituibile senza alternative.

Il ruolo delle competenze interne

Anche quando lo sviluppo viene affidato all'esterno, l'amministrazione dovrebbe conservare una capacità minima interna di comprendere il sistema. Sapere:

• come sono organizzati i dati;
• dove sono conservati;
• come vengono esportati;
• quali componenti vengono utilizzati;
• quali licenze sono coinvolte;
• come funziona l'integrazione.

Non significa che ogni ente debba diventare una software house ma che deve essere un committente consapevole.

Comprare software o comprare competenza?

Una strategia basata sul Software Libero permette anche di spostare una parte della spesa. Meno risorse destinate esclusivamente a licenze e più risorse potenzialmente utilizzabili per:

• personalizzazione;
• assistenza;
• formazione;
• sviluppo;
• manutenzione.

La spesa può trasformarsi più facilmente in competenza e lavoro. Non sempre questo avverrà automaticamente ma è una possibilità importante.

Il codice finanziato con risorse pubbliche

Quando una pubblica amministrazione finanzia lo sviluppo di un software, nasce una domanda legittima: quel codice può essere riutilizzato anche da altre amministrazioni?

Se ogni Comune paga separatamente per sviluppare soluzioni quasi identiche e il risultato rimane chiuso, la spesa pubblica viene duplicata. Mentre un codice riutilizzabile può invece generare un effetto moltiplicatore.

• Un ente sviluppa.
• Altri riusano.
• Altri migliorano.
• Le modifiche possono tornare alla comunità.

Dal “pagato una volta” al “riutilizzato molte volte”

Il principio è molto simile a quello già visto per i dati:  Un dato, molti utilizzi.

Possiamo affiancargli: un codice, molti riusi.

• Un modulo sviluppato per gestire eventi potrebbe essere utilizzato da più territori.
• Uno strumento per raccogliere segnalazioni potrebbe essere adattato ad altre città.
• Un componente per pubblicare Open Data potrebbe essere condiviso.

La spesa pubblica può produrre beni digitali riutilizzabili.

Il Software Libero come bene comune digitale

In questa prospettiva il codice assume una dimensione simile a quella dei dati. Non è soltanto un prodotto informatico ma può diventare un bene comune digitale.

• Con documentazione.
• Licenza.
• Versioni.
• Repository.
• Comunità.
• Possibilità di miglioramento.

È un patrimonio che può sopravvivere al progetto che lo ha originato.

Riutilizzare non significa imporre

Un software riutilizzabile non deve diventare obbligatorio per tutti; qualsiasi altro ente può decidere di utilizzare uno strumento differente. Il valore consiste nella possibilità di scegliere.

Se il codice è disponibile, può essere:

• utilizzato;
• modificato;
• studiato;
• ignorato.

La libertà di riuso comprende anche la libertà di adottare soluzioni differenti.

La trasparenza del codice

La disponibilità del codice permette inoltre una forma di trasparenza. Possiamo verificare:

• come viene calcolato un indicatore;
• come funziona una procedura;
• quali regole applica un sistema;
• quali dati utilizza.

Naturalmente leggere codice richiede competenze ma la possibilità di verifica rimane importante. Un algoritmo utilizzato in un servizio pubblico non dovrebbe essere necessariamente una scatola incomprensibile e incontrollabile.

Trasparenza non significa sicurezza automatica

Un'altra semplificazione da evitare è: codice aperto = codice sicuro.

Non è vero automaticamente: un programma libero può contenere vulnerabilità mentre un programma proprietario può essere ben protetto.

La sicurezza dipende da:

• qualità del codice;
• aggiornamenti;
• configurazione;
• monitoraggio;
• gestione degli accessi;
• procedure.

Il vantaggio del codice aperto è che può essere esaminato da soggetti differenti ma deve comunque essere mantenuto correttamente.

Sicurezza e autonomia

Per un sistema pubblico è importante poter reagire rapidamente a una vulnerabilità. Se soltanto un fornitore può correggere il programma, bisogna dipendere dai suoi tempi. Con un software aperto, almeno teoricamente, la correzione può essere realizzata anche da altri soggetti competenti. Ancora una volta il valore è nella possibilità di scelta.

Le dipendenze esistono anche nel Software Libero

Ogni software moderno utilizza molte componenti.

• Librerie.
• Framework.
• Database.
• Sistemi operativi.

Anche un progetto completamente libero può dipendere da tecnologie sviluppate altrove. L'autonomia non consiste quindi nell'eliminare ogni dipendenza - è impossibile - consiste nel costruire dipendenze:

• conosciute;
• sostituibili;
• documentate;
• basate su standard;
• senza un unico punto di controllo.

Comunità e continuità

Uno dei vantaggi di molti progetti liberi è la presenza di comunità.

• Sviluppatori.
• Utilizzatori.
• Aziende.
• Enti.
• Documentazione condivisa.

Una tecnologia sostenuta da una comunità ampia può continuare a evolvere anche se un singolo soggetto abbandona il progetto.

La dimensione della comunità non garantisce automaticamente la qualità ma è un elemento importante nella valutazione della continuità.

Evitare il Software Libero “di facciata”

Scegliere un programma libero ma costruire intorno ad esso:

• moduli proprietari indispensabili;
• formati chiusi;
• procedure non documentate;
• servizi accessibili soltanto al fornitore

può ricreare lo stesso lock-in che volevamo evitare.

Non basta quindi controllare la licenza del prodotto principale ma dobbiamo guardare l'intera architettura.

La documentazione come requisito

Un sistema realmente autonomo deve essere documentato:

• Architettura.
• Configurazione.
• Modello dei dati.
• Procedure di backup.
• Aggiornamenti.
• API.
• Dipendenze.
• Personalizzazioni.

Senza documentazione, anche un software completamente libero può diventare di fatto inseparabile dalle persone che lo hanno installato. La conoscenza tecnica deve essere trasferibile.

Il repository

Quando viene sviluppato codice specifico per un progetto pubblico, può essere utile conservarlo in un repository.

Il repository permette di mantenere:

• codice;
• versioni;
• modifiche;
• documentazione;
• segnalazioni;
• contributi.

Diventa la memoria dello sviluppo e non soltanto un luogo nel quale scaricare un programma.

La cronologia è conoscenza

Sapere che cosa è stato modificato e perché può essere importante quanto possedere l'ultima versione.

Una decisione tecnica presa oggi potrebbe essere incomprensibile tra cinque anni se non viene documentata e quindi versionare il codice e la documentazione significa conservare anche la storia delle decisioni tecnologiche.

Standard aperti e accessibilità

L'uso di standard aperti ha anche una dimensione di accessibilità:

• Un documento pubblicato esclusivamente in un formato utilizzabile da un solo programma crea una barriera.
• Un formato standard può essere aperto da strumenti differenti, compresi molti strumenti assistivi.

L'apertura tecnologica può quindi contribuire anche all'accesso universale all'informazione.

Standard aperti e conservazione

I formati aperti sono particolarmente importanti per gli archivi. Un documento deve poter essere letto anche quando il programma originario non esiste più. Per una pubblica amministrazione questo è un requisito essenziale.

• Bilanci.
• Piani.
• Dataset.
• Studi.
• Mappe.
• Documentazione.

La memoria digitale della città non può dipendere dalla sopravvivenza commerciale di un singolo prodotto.

Il dato deve poter uscire

Possiamo fissare un requisito molto concreto. Ogni sistema utilizzato dal progetto dovrebbe poter rispondere chiaramente alla domanda: come posso esportare tutti i dati?

Non un singolo report, non una selezione ma tutto il patrimonio informativo che appartiene al progetto. In formati documentati e con relazioni e metadati sufficienti per ricostruirne il significato.

Questa è una delle prove più importanti dell'autonomia.

Il codice può cambiare, i diritti sui dati no

Bisogna inoltre distinguere chiaramente la licenza del software da quella dei dati. Un software può essere libero ma i dati contenuti al suo interno possono avere:

• licenze differenti;
• vincoli;
• dati personali;
• restrizioni.

Il codice aperto non rende automaticamente aperti i dati ed allo stesso modo un dataset Open Data può essere pubblicato attraverso software proprietario.

Le due dimensioni sono collegate ma non coincidenti.

Una politica coerente

Per Salerno Turismo Aperto l'obiettivo non è scegliere un'etichetta tecnologica. È costruire una politica coerente basata su:

Software Libero quando appropriato;
standard aperti;
formati aperti;
interoperabilità;
portabilità;
documentazione;
Open Data;
controllo pubblico del patrimonio informativo.

Questi elementi si rafforzano reciprocamente.

Non una guerra tra software libero e proprietario

La discussione non deve trasformarsi in uno scontro ideologico tra prodotti:

• Esistono strumenti proprietari eccellenti.
• Esistono strumenti liberi mediocri.

Una scelta pubblica deve valutare:

• qualità;
• sicurezza;
• funzionalità;
• costi;
• continuità;
• interoperabilità;
• accessibilità;
• portabilità;
• dipendenza.

Il Software Libero assume un valore strategico perché offre caratteristiche particolarmente coerenti con l'autonomia non perché la licenza possa sostituire ogni altra valutazione.

Preferenza motivata, non automatismo

Possiamo quindi formulare una posizione equilibrata: quando esistono soluzioni libere adeguate alle necessità, la pubblica amministrazione dovrebbe considerarle con particolare attenzione.  Perché possono favorire:

• riuso;
• trasparenza;
• autonomia;
• concorrenza tra fornitori;
• controllo del codice;
• continuità.

La scelta finale deve però essere motivata sulla base del sistema complessivo.

Anche il fornitore beneficia di un ecosistema aperto

Un'architettura aperta non esclude le imprese anzi può creare un mercato più competitivo.

Più aziende possono offrire:

• assistenza;
• sviluppo;
• integrazioni;
• formazione;
• hosting;
• personalizzazioni.

La competizione si sposta dalla proprietà esclusiva del prodotto alla qualità del servizio. Questo può favorire anche operatori locali e specializzati.

Concorrenza senza prigionia

In un sistema chiuso, cambiare fornitore può significare cambiare completamente tecnologia e migrare con grande difficoltà mentre in un ecosistema aperto, fornitori differenti possono lavorare sullo stesso patrimonio tecnologico.

La città può scegliere chi offre il servizio migliore senza dover necessariamente ricostruire tutto da zero.

È una forma di: concorrenza senza prigionia tecnologica.

Cooperazione tra amministrazioni

Il Software Libero può inoltre favorire una forma di cooperazione istituzionale.

• Due Comuni hanno spesso problemi simili.
• Gestione eventi.
• Mappe.
• Segnalazioni.
• Dataset.
• Servizi turistici.

Invece di finanziare separatamente due soluzioni chiuse quasi identiche, potrebbero:

• sviluppare insieme;
• riutilizzare;
• condividere miglioramenti.

L'infrastruttura digitale può diventare terreno di cooperazione.

Condividere non significa avere città identiche

Ogni territorio mantiene caratteristiche proprie e condividere una base software non significa uniformare politiche e contenuti. Due città possono utilizzare lo stesso strumento e organizzare servizi completamente differenti, come avviene con una strada o con una rete.

L'infrastruttura comune non cancella l'identità maa rende più economica da esprimere.

Il caso di GiraSalerno

GiraSalerno utilizza Drupal. Drupal è Software Libero.

Questa scelta è coerente con il progetto perché consente di:

• gestire dati strutturati;
• costruire relazioni;
• personalizzare il sistema;
• sviluppare integrazioni;
• esporre servizi;
• controllare il codice;
• evitare che il dimostratore dipenda da una piattaforma completamente chiusa.

Ma questo non significa che: Salerno Turismo Aperto = Drupal.

Drupal è uno strumento attuale del dimostratore. L'architettura del progetto deve poter sopravvivere anche a Drupal.

Il miglior test: poterlo sostituire

Può sembrare paradossale. Uno dei modi migliori per dimostrare che Drupal è utilizzato correttamente è progettare GiraSalerno in modo che un giorno possa essere sostituito senza perdere il patrimonio informativo.

Se dati, standard e documentazione sono separati dalla piattaforma, la migrazione rimane possibile.

La vera autonomia non consiste nell'affezionarsi a un software ma nel non diventare prigionieri nemmeno del software che abbiamo scelto liberamente.

Dal dimostratore al patrimonio riutilizzabile

Gli sviluppi realizzati per GiraSalerno possono inoltre produrre componenti riutilizzabili.

• Modelli dei dati.
• Configurazioni.
• Procedure di importazione.
• API.
• Moduli.
• Documentazione.
• Schemi.

Quando possibile, questi elementi possono essere pubblicati e messi a disposizione.

Il dimostratore non produrrebbe quindi soltanto un sito ma anche e soprattutto conoscenza tecnica riutilizzabile.

Il Software Libero come strumento di partecipazione

Esiste infine una dimensione direttamente democratica. Con un sistema aperto, una comunità tecnica può:

• segnalare problemi;
• proporre modifiche;
• analizzare il codice;
• sviluppare estensioni;
• riutilizzare componenti.

Naturalmente non tutti i cittadini programmano. La partecipazione tecnologica non sostituisce quella politica o civica ma aggiunge un ulteriore livello di possibilità.

Partecipare significa poter comprendere anche l'infrastruttura

Una politica pubblica digitale è sempre più spesso mediata da software.

• Come vengono mostrati i dati?
• Come viene calcolato un indicatore?
• Quali informazioni vengono filtrate?
• Quali categorie vengono utilizzate?

Rendere documentati e verificabili questi meccanismi aumenta la possibilità di controllo pubblico.

La trasparenza contemporanea non riguarda più soltanto gli atti ma anche i sistemi che trasformano i dati in servizi e decisioni.

Autonomia non è autosufficienza

Possiamo ora chiarire un ultimo punto: una città autonoma digitalmente non è una città che costruisce da sola ogni programma.

È una città che:

• conosce i propri dati;
• conosce i propri sistemi;
• può esportare;
• può integrare;
• può migrare;
• può scegliere fornitori differenti;
• può verificare ciò che utilizza;
• può conservare la conoscenza anche quando cambia tecnologia.

Questa è l'autonomia che interessa al nostro Piano.

Una strategia che guarda al lungo periodo

Nel breve periodo può sembrare più semplice acquistare una soluzione chiavi in mano ma nel lungo periodo dobbiamo chiederci:

• chi manterrà il sistema?
• chi controllerà i dati?
• quanto costerà cambiarlo?
• potremo collegarlo a nuovi servizi?
• potremo conservare la storia?
• potremo riutilizzare ciò che abbiamo finanziato?

Una politica digitale sostenibile deve guardare oltre la durata del singolo contratto.

La città deve possedere la propria memoria digitale

Il principio finale è molto semplice:

• Una città può affidare servizi.
• Può acquistare tecnologie.
• Può utilizzare piattaforme.

ma non dovrebbe perdere il controllo della propria memoria.

• Dati.
• Documentazione.
• Modelli.
• Codice sviluppato con risorse pubbliche quando riutilizzabile.
• Serie storiche.
• Procedure.

Questi elementi costituiscono un patrimonio.

La tecnologia può essere affidata. La conoscenza della città non può essere ceduta.

Il passo successivo

Abbiamo costruito un'infrastruttura aperta, definito il valore dell'interoperabilità, introdotto Software Libero, standard aperti e autonomia ma un sistema aperto può essere perfettamente interoperabile e continuare a fornire informazioni sbagliate, incomplete o obsolete.

Rimane quindi una domanda decisiva: come possiamo sapere se un dato è affidabile?

• Chi lo ha prodotto?
• Quando?
• Con quale metodologia?
• Quanto è completo?
• Quando deve essere aggiornato?
• Come gestiamo un errore?
• Come distinguiamo un dato ufficiale da una stima o da una segnalazione?

È il tema della prossima puntata perché una conoscenza aperta e autonoma ha valore soltanto se può essere anche verificata, aggiornata e considerata affidabile.