Manuale d’uso del software libero nella PA: ecco perché è un freno all’adozione

Non raggiungeremo mai l’obiettivo di far adottare il software libero alla Pubblica Amministrazione fino a che i manuali saranno scritti da persone che non si sanno immedesimare nel loro lettore, che è quello che dovrebbe capire e soprattutto utilizzare i suggerimenti del manuale stesso.

Software e disuguaglianza digitale: le colpe della politica, l’importanza dell’open source

La Guida allo sviluppo e gestione del software libero

Stiamo parlando della “Guida allo sviluppo e gestione di software libero” (avrebbe dovuto essere “allo sviluppo e alla gestione” o “a sviluppo e gestione” volendo iniziare subito) che al titolo aggiunge “Release stabile” e già qui abbiamo capito che il linguaggio è per addetti ai lavori: sanno tutti che cosa è una release e soprattutto che cosa significa release stabile?

Passiamo all’indice, dopo l’introduzione il primo capitolo si intitola “Per le responsabili politiche e i responsabili politici”, capisco che volevano essere politically correct anche in ottica di genere, bene o no, non lo so, ma il capitolo successivo si intitola “Per gli amministratori pubblici”. Non ci sono amministratrici pubbliche? Credo semplicemente che questo capitolo lo abbia scritto una persona diversa da quella del capitolo precedente e soprattutto che non ci sia stato un/una revisore/a che avrebbe dovuto leggere il documento finale e uniformarlo oltre che renderlo comprensibile a tutti e tutte!

Linguaggio e definizioni

Una cosa che chiunque scriva un manuale sa è che non solo il linguaggio deve essere adattato alle persone cui è rivolto ma anche che le definizioni andrebbero date una sola volta e uniformate nel testo e magari concludere con un glossario e con l’esplicitazione degli acronimi.

Il titolo del manuale parla di software libero, ma nel testo si parla a volte di open source, a volte di software open source, a volte di codice aperto, a volte di codice sorgente e a volte di FLOSS (Free Libre Open Source Software), per non parlare delle volte in cui open source è scritto in maiuscolo e altre in italicus! Ma soprattutto non si trova mai la differenza tra software libero e open source (che peraltro nel CAD non è mai citato, si parla di “software libero o a codice sorgente aperto”), anzi, spesso si legge “open source o software libero”, sicuri di quell’o? Sono la stessa cosa? Sarebbe stato sufficiente citare la definizione della Free Software Foundation^[1] o più “morbidamente” la pagina di Wikipedia (visto che in altri contesti la citano) che ne descrive le reali differenze^[2].

Tornando al linguaggio del manuale, nel capitolo 1 si parla di CAD senza esplicitare l’acronimo; si tratta del Codice dell’Amministrazione Digitale, ma la prima volta che si scrive un acronimo è sempre opportuno definirlo e magari non sbagliare chiamandolo legge mentre in realtà è un decreto legislativo.

“Lo scopo di questa guida è quello di supportare concretamente e operativamente le Pubbliche Amministrazioni italiane a districarsi in un contesto nuovo e potenzialmente complesso”, così si legge nel Manuale, ma davvero si tratta di un contesto nuovo? Si parla di un decreto (il CAD) di 17 anni fa e di software nella Pubblica Amministrazione che è presente da ben più tempo.

Sono felice che tra gli obiettivi ci sia anche il desiderio di “attrarre nuovi sviluppatori grazie agli ecosistemi aperti”, ma siamo sicuri che i lettori cui il manuale è rivolto sappiano che cosa è un ecosistema aperto?

Le leggerezze che mettono il lettore in difficoltà

Segnalo poi alcune “leggerezze” che possono mettere il lettore non esperto in difficoltà:

• “Le migliori tecniche per sviluppare software in un ambiente aperto”: sanno tutti che cosa è un “ambiente aperto”? Ricordo che il manuale è scritto anche per responsabili politici, quindi mi aspetto che “soggetti coinvolti nella definizione delle politiche e delle regole che vengono applicate nello sviluppo di servizi e soluzioni software per la pubblica amministrazione, indirizzandone l’attuazione” (così sono descritti nel manuale i “responsabili politici”) non siano obbligatoriamente esperti di software e il linguaggio usato deve essere chiaro e comprensibile anche per loro;
• si parla di “sviluppo aperto” e “licenza aperta” senza definirli;
• il capitolo (dedicato esplicitamente ai decisori politici) dal titolo “I vantaggi dell’open source” inizia così “Le politiche pubbliche, definite democraticamente, sono codificate in norme, ovvero un “codice legale”. Questo codice, precursore dei codici «informatici» viene oggi spesso tradotto in algoritmi e codice software ed eseguito da macchine che interpretano il volere del decisore e lo rendono un’azione concreta.” Mi permetto di non commentare se non per ricordare che è essenziale, sempre, non solo scrivere in un italiano accettabile ma anche, come già detto, in un linguaggio comprensibile facilmente dalle persone cui ci rivolgiamo;
• un’altra frase che non commento fa capire, spero, che cosa intendo quando dico che così sarà impossibile raggiungere l’obiettivo di far adottare software libero alla Pubblica Amministrazione italiana (cito senza cambiare una virgola e neppure senza togliere gli spazi inutili): “cittadini e gli attori della società civile hanno bisogno che il software sia trasparente e responsabile e che sia quindi progettato e come un’infrastruttura civica essenziale che rispetti i loro diritti”;
• si legge inoltre che il software pubblico deve essere: trasparente e “responsabile, nel senso di accountable”; non aggiungo altro se non che accountability non significa responsabilità ma “responsabilità di rendicontazione”;
• “Dopo il rilascio è probabile, e anzi auspicabile, che altre sviluppatrici e sviluppatori contribuiscano al codice con dei bug fix, degli enhancement o con nuove funzionalità” e anche questa frase è rivolta a chi da indirizzi politici senza spiegare che cosa significhino le parole utilizzate.

Purtroppo, anche nel capitolo rivolto ai referenti delle amministrazioni pubbliche che si occupano a diverso livello dei progetti software del proprio ente, ci sono alcune imprecisioni e/o poca chiarezza nelle definizioni:

• che cosa significa “modello di sviluppo migliore”?
• “Il modello open source permette alla pubblica amministrazione di cambiare fornitore, se necessario, senza dover ricominciare il processo di sviluppo dal principio.” A volte è vero a volte no… forse è opportuno approfondire;
• “I fornitori delle organizzazioni pubbliche possono includere l’open source nelle loro offerte per contratti.” Che cosa si intende per “offerte per contratti”?
• “Tutte le volte che si progetta un nuovo servizio digitale, si possono usare codice o componenti open source già pronti.” Purtroppo, non sempre è vero, non è opportuno affermare cose falsificabili;
• “Nel caso in cui la PA decida di acquisire software in licenza o di svilupparne uno nuovo… deve motivare tale scelta attraverso la redazione di una valutazione comparativa scritta.” Tutto il software è “in licenza” anche il software libero… semplicemente ha una licenza diversa da quella del software proprietario (mai definito peraltro nel manuale anche se c’è un paragrafo intitolato “Gli svantaggi del software proprietario”); troppo spesso ci sono termini tecnici non definiti che non obbligatoriamente conosce chi legge il manuale.

Infine, ci sono molte imprecisioni di italiano che suggeriscono anche qui la necessità su una revisione fatta da chi sia da un lato competente della materia ma che sappia soprattutto quale linguaggio utilizzare per farsi capire dalle persone cui è dedicato il manuale.

Conclusioni

Sono speranzosa, nel nostro paese non mancano le competenze non solo tecniche che ben sono evidenziate nel manuale oggetto di questo articolo, ma anche le cosiddette soft skill che servono per scrivere in maniera comprensibile e utile al lettore.

E quando le attiveremo forse anche la PA più reticente potrà adottare software libero e rilanciare il riuso rispettando peraltro la normativa non solo italiana (es. il CAD) ma anche le risoluzioni europee come quella che a ottobre 2015 richiedeva: “la sostituzione sistematica del software proprietario con software open source controllabile e verificabile in tutte le istituzioni dell’UE” e ha anche definito la strategia open source 2020-2023^[3] dove si legge non solo che la Commissione “sfrutta il potere trasformativo, innovativo e collaborativo dell’open source, incoraggiando la condivisione e il riutilizzo di soluzioni software, conoscenze e competenze, per fornire risultati migliori servizi europei che arricchiscono la società e si concentrano sulla riduzione dei costi per tale società, ma ne spiega anche le ragioni dichiarando che è “vicino all’essenza del servizio pubblico, perché:

• è un codice pubblico, che garantisce un buon uso del denaro pubblico, promuove la libertà di scelta ed evita di essere “bloccato”;
• semplifica l’uso e il riutilizzo delle soluzioni software, in modo da poter unire gli sforzi per creare servizi transfrontalieri di valore interoperabili e aumentare l’efficienza;
• è facile ed efficiente aggiungere funzionalità al software open source, che può essere liberamente condiviso con chiunque, per qualsiasi scopo. Ciò significa che tutti possono beneficiarne.

Questa la strategia europea riassunta in un’immagine:

Non serve aggiungere altro se non buon lavoro a noi, ce la faremo, insieme!

Note

1. https://www.fsf.org/it ↑
2. https://it.wikipedia.org/wiki/Differenza_tra_software_libero_e_open_source ↑
3. https://ec.europa.eu/info/departments/informatics/open-source-software-strategy_en ↑