menu di navigazione del network

Proposta di valorizzazione del riuso secondo il paradigma del "Community By Design"

Dal 9 maggio, in cui sono state rilasciate le nuove Linee guida per l’acquisizione ed il riuso di software da parte delle Pubbliche amministrazioni da parte di AgID, abbiamo visto un incremento costante e incessante di software pubblicato sul catalogo Developers Italia.
Un trend che spero aumenti, ma che porta con sé il concreto rischio che la piattaforma diventi sostanzialmente sempre meno “consultabile”, ovvero intellegibile, per via della numerosità dei prodotti pubblicati. Questo fenomeno potrebbe paradossalmente rendere difficilmente praticabile quella sinergia tra PA che costituisce uno dei punti essenziali del rilancio dell’istituto del riuso tramite il software libero, facendo un po’ perdere l’efficacia di una normativa che ha come obiettivo la massima diffusione di software pubblico al minor costo, attraverso il riuso di soluzioni già presenti e operative nelle PA italiane senza dover nuovamente investire eccessivamente nell’acquisto o nello sviluppo di nuovo software.
In altri termini, il rischio è che, continuando in questo modo, ogni amministrazione andrà a pubblicare il proprio software con il risultato di veder moltiplicate le offerte simili, mettendo di conseguenza in difficoltà nella valutazione del software esistente le PA che hanno necessità di acquisire nuove soluzioni, o che hanno la necessità di cambiare quelle esistenti. Invece riteniamo che non ci sia bisogno di tante offerte simili, ma piuttosto di un sistema che favorisca la convergenza di esigenze simili verso prodotti utilizzati e che siano contribuiti da un più ampio numero di amministrazioni.
Come superare questo momento di esplosione?
Secondo noi attraverso la creazione di un “ombrello” di riferimento, non solo tecnico, ma anche organizzativo e, perché no, giuridico, all’insegna della “Collaborazione”. Significa promuovere la “community by design”. In tal senso il ruolo del Team Digitale e di AgID è fondamentale in questo, in sinergia con le regioni quali intermediari tecnologici del territorio.
Come raggiungere questo obiettivo?
Intanto, promuovendo la creazione e/o l’identificazione di una community all’avvio di un progetto o al momento della evoluzione significativa di un prodotto già presente sul catalogo o disponibile già con licenza open source. Significa anche convergere verso modelli di contribuzione standard, che ogni PA possa fare propri a seconda dei contesti, che risolvano già a monte i dubbi circa la gestione dei finanziamenti, delle linee di codice, ecc. Significa, magari, mettersi d’accordo per promuovere una normativa facilitatrice che permetta di procedere con la creazione di community di soggetti in tempi stretti, e la costituzione di uno strumento che consenta di incrociare le reciproche necessità in modo da creare un progetto che soddisfi le necessità e le opportunità, anche economiche, di tutti i soggetti interessati.
Insomma, prepararsi al co-editing del software e alla co-partecipazione attiva alla realizzazione di un software o all’evoluzione di uno esistente. Partecipare insieme e non ognuno per proprio conto.
Tutto questo non significa solo parlare dei “massimi sistemi”, ammesso che lo siano: significa anche intervenire sugli standard, che permettano e accolgano la collaborazione. Ad esempio, componente normativa e organizzativa a parte, potrebbe essere utile anche prevedere che il software abbia una dichiarazione di titolarità multipla, insomma di proprietà di più enti; questa cosa nel publiccode.yml ad oggi non è possibile, in quanto c’è la sola possibilità di dichiarare un unico codice IPA per poi, eventualmente, rimandare la dichiarazione di titolarità multipla nel Copyright. Basterebbe anche solo una lista di codiceIPA, che permetta di attribuire la titolarità a più enti e non ad uno solo così da permettere di lavorare fin d’ora in questa direzione. L’altro aspetto sarebbe quello di non avere vincoli sulla corrispondenza tra codiceIPA registrato nella procedura di on-boarding, con indicazione della URL della Organization, e il codiceIPA interno ai publiccode.yml; ciò aiuterebbe ancora di più a liberarsi da costrizioni inutili nella gestione delle community.
Quindi, le nostre proposte vanno sia nella direzione di avviare un iter normativo che faciliti la costituzione delle community tra enti pubblici e dall’altro tecnico che liberi il publiccode da vincoli inutili.