dovete sapere che il Dipartimento della Funzione Pubblica che ha realizzato ParteciPA sulla base di modificazioni software della piattaforma Decidim, lo ha anche messo in riuso su Github e pubblicato su Developers Italia, apportando fra le modifiche la più importante che è l’integrazione SPID.
Peccato che la messa in riuso, nonostante le buone intenzioni, sia realizzata in violazione delle regole stessi di riuso, come gli ho riportato sul seguente ticket Github, anche confermato dal Maintainer stesso del progetto ParteciPA.
Credo che le pubbliche amministrazioni abbiano veramente una scarsa conoscenza delle dinamiche legate all’utilizzo di software opensource come base per i propri progetti, vedasi l’azione legale GlobaLeaks vs. ANAC per il ripristino della licenza AGPLv3 per dirne una, o in questo caso in cui la Funzione Pubblica stessa espressamente conferma l’intenzione della violazione, cioè l’assenza di re-integrazione delle modifiche effettuate.
Credo che su questo tema, cioè come lavorare con l’opensource, si debba fare molto, e prima di tutto l’informazione e l’educazione specialistica sia necessaria.
Avrebbe probabilmente senso produrre qualcosa di più sul tema della adozione in opensource di software terze parti, con una checklist chiara per la verifica e validazione indipendente, come anche delle video-guide che forniscano il supporto formativo necessario.
In merito alla violazione da parte della Funzione Pubblica, provvederò ad attivare il Difensore Civico Digitale, per valutare la sua efficacia di intervento operativo in quest casi.
Altresì dovrebbe essere forse necessario che tutti i software che finiscono su Developers Italia in riuso, abbiano una checklist smarcata per valutarne la compliance alle linee guida riuso.
Fabio, tutto idealmente giusto ma non e’ la prima norma che descrive scenari idiliaci irrealizzabili.
Nello specifico, direi che e’ del tutto irrealizzabile l’impianto generale dell’idea di riuso nella parte in cui prevede che la p.a. che sviluppa o fa sviluppare un software lo pubblichi poi come opensource e si faccia poi promotrice e leader di una comunità di sviluppo. Non rientra nelle funzioni isituzionali di una publbica amministrazione. Anzi, i piu’ intransigenti dicono che e’ addirittura danno erariale far lavorare un dipendente o comunque un soggetto pagato da una amminsitrazione per un’altra amminsitrazione. Sara’ anacronistico ma c’e’ un fondo di verità.
Inoltre, se scorri il catalogo del riuso, vedi bene che - in pieno ossequio della normativa - molte iniziative di riuso hanno un mantainer che e’ la software house che ha sviluppato il software. Ci si potrebeb chiedere: nella sostanza, al netto della necessità di acquistare una licenza d’uso temporanea o sempiterna, al netto della bellezza estetica di dire “uso un software open”, cosa cambia fra un prodotto a riuso con mantainer una software house privata e un “banale” software SaaS? Quante amministrazioni sono in grado di partecipare attivamente a una comunità di sviluppo, proporre e realizzare modifiche ecc?
Anzi, io posso assicurarti che per la stragrande maggioranza delle p.a. italiane, il riuso e’ una strada impercorribile. Fosse anche solo per doversi procurare in proprio l’infrastruttura (cloud) dove installarla e farla funzionare.
Aggiungerei qualche altra riflessione in merito al riuso dei software presenti in Developers. In genere, a meno di prerequisiti “proprietari”, i software open source sono scaricabili e installabili più o meno facilmente dalla PA che intende valutarli ed eventualmente utilizzarli. Viceversa, per la maggior parte di quelli presenti in Developers o vi sono prerequisiti da acquistare, e questo sarebbe il meno, o le versioni scaricabili da github non sono funzionanti o installabili e necessitano, per la loro implementazione di un contatto con il mantainer chiaramente a pagamento. Per il resto mi trovo ancora in pieno accordo con quanto da lei scritto. Ma è questo il percorso per favorire l’open source nella PA?
Facci sapere come va a finire.
In questo caso è pur vero che l’upstream non mi sembra aver capito molto l’importanza del contributo e potrebbe comunque fare cadere un eventuale PR nel dimenticatoio nella usa ruolo di Gatekeeper del repository
In questo thread ravvedo un grande pessimismo, mio avviso del tutto fuori contesto.
In Francia la collaborazione della PA con il settore privato nel mondo dell’opensource vale 5 miliardi all’anno, e ciò avviene solo perché c’è un contesto di regole da rispettare che mantengono il mercato fluido nel modo di fare.
Mantenere il mercato fluido e dinamico significa adeguarsi al modus operandi del mondo dell’opensource.
Non è difficile, non è impossibile e in tutti i mercati sviluppati e moderni avviene.
In Italia, affinché ciò avvenga, serve innanzitutto cultura, propositività, ottimismo e non ultimo monitoraggio sia civico (come quello che sto facendo io) sia istituzionale (come dovrebbe fare la Corte dei Conti e lo stesso Ministero Innovazione).
Quando un progetto software viene avviato sulla base di un progetto opensource, è facile, è banale e dovrebbe essere normale seguirne il modello di sviluppo, di interazione con il maintainer, di re-integrazione, di impedimento di fork(), esattamente come le linee guida prevedono.
Non viene fatto? C’è un ovvio aggravio di costo per lo stato a vantaggio di privati.
Fine.
Cos’altro va valutato, se non lavorare nel modo che ingeneri minori costi e maggiori vantaggi per la collettività?
Mah… riguardando il caso specifico e le linee guida, io avrei seri dubbi che le linee guida sul riuso obblighino una amministrazione che adotti un software opensource esistente (di terze parti, non p.a. italiana) a partecipare alla sua comunità di sviluppo.
La Funzione pubblica ha preso un software opensource, decidim (con una comunità spagnola, forse internazionale), lo ha adattato alle sue esigenze e lo ha chiamato parteciPA.
Lo ha quindi a sua volta “messo in riuso”, diventando maintainer del software parteciPA. A questo punto si’, se una amministrazione prende parteciPA in riuso e fa delle modifiche deve sottostare alle regole di ricondivisione di modifiche, minimizzazione delle modifiche ecc.
Che poi l’omino della Funzione pubblica che ha pacioccato con decidim partecipi alla community di decidim sarebbe cosa buona e giusta, ma mi sembrerebbe eccessivo (e fuori giurisdizione) che fosse un obbligo di legge. Immagino anche che chi ha creato parteciPA, se ha intenzione di mantenrlo vivo, partecipi eccome alla community di decidim, ma per sopravvivenza e convenienza, non per ossequio alla legge. Un po’ come fanno tutti gli users delle community, no?
Questo per quanto riguarda l’aderenza alla normativa.
C’e’ poi il giudizio sulla normativa stessa, che non e’ pessimismo ma solo realismo e pragmatismo. Questo pero’ e’ OT rispetto a decidim/pagopa quindi cancello
Francesco, la legge è legge e non ammette ignoranza.
L’Allegato D delle Linee Guida, come parte integrante del CAD parla molto chiaro in tutte le sezioni indicate come MUST:
Nel caso di modifiche necessarie per implementare le nuove funzionalità, l’Incaricato è tenuto (MUST) a prendere contatto con il maintainer attraverso i canali pubblici del repository (issue tracker) in modo da presentare il nuovo caso d’uso, proporre la modifica ed ottenere feedback sulle modalità da seguire soprattutto nell’ottica di scrivere modifiche che possano essere incorporate dal maintainer originale.
Al termine dello sviluppo, l’Incaricato è tenuto a proporre al maintainer originale le proprie modifiche (MUST), con delle proposte di codice (pull request) granulari, ovvero distinte per singole funzionalità in modo da consentire al maintainer di valutarle singolarmente.
l’Incaricato è inoltre tenuto (MUST) a tenere traccia di tutte le contribuzioni al software inviate al maintainer del software originale, documentandone lo stato di integrazione all’interno del file README del repository.
Nel caso di correzioni di bug, l’Incaricato è tenuto (MUST) ad inviare al maintainer originale la proposta di correzione usando gli strumenti di collaborazione previsti dalla piattaforma di code hosting (ad es. pull request).
Queste regole di operatività tecnica sono semplici da eseguire, direi banali, in qualunque logica di esecuzione di un contratto o progetto di sviluppo software.
Non farle, comporta un danno economico per la collettività e ciò è dimostrato e dimostrabile econometricamente con tanto di perizia in tribunale civile o tribunale amministrativo che sia.
Le PA che non le rispettano violano le norme, dovremo poi arrivare con il tempo a comprendere tramite la giurisprudenza amministrativa, se vi siano responsabilità civili anche per le società private che eseguono contratti in violazione del CAD.
Il mio punto e’ che quelle regole che citi testualmente si applicano nel caso di un maintainer membro della p.a. italiana che ha pubblicato il suo software in riuso. Si applicano quindi d’ora inpoi a parteciPA.
In questo caso al limite la Funzione pubblica ha violato qualche regola della comunità di decidim, che credo sia fuori e dalle competenze AgID e in generale dalla giurisdizione italiana.
Dai, delle linee guida AgID non possono regolare rapporti fra un’amministrazione italiana e una comunità opensource qualsiasi.
Le regole indicate," Allegato D: Guida alla presa in riuso di software open source", si applicano esattamente alla messa in riuso di software basati su opensource di terze parti, cioè quando un ente prende un software open già di pubblico dominio e vi ci applica delle modifiche.
La Funzione Pubblica ha violato le regole in modo palese, e lo ha anche confermato nel ticket, sono convinto non per dolo ma per ignoranza.
Vediamo, conunque non mi pare di leggere ammissioni di colpevolezza sul ticket github.
Resto perplesso su cone AgID possa mettere bocca su rapporti che non riguardino solo soggetti italiani.
Francesco, AgID non mette bocca su rapporti che riguardano soggetti terzi che non siano le PA.
Le PA devono operare nell’ottica di collaborazione con il maintainer di un progetto software di terze parti, esattamente come farebbe qualunque sconosciuto della comunità opensource globale, senza alcun tipo di accordo con questo.
Le PA devono farlo come modello operativo obbligatorio.
Il che non garantisce né impegna il soggetto terzo che gestisce il software opensource di terze parti ad accettare le modifiche della PA.
Difatti le linee guida obbligano le PA a realizzare modifiche in modo modulare, chirurgico e compatibile con il software design del progetto software opensource di terze parti modificato, e a proporre a questi modifiche secondo tale criterio di modularità e usando il sistema pubblico di issue tracking.
Se la PA non lo fà, è in violazione e genera un danno economico alla collettività.
Per inciso, la Funzione Pubblica ha confermato che non intende farlo, sottoscrivendo una ammissione di colpevolezza:
“Il progetto ParteciPa non prevede di contribuire allo sviluppo del progetto Decidim; i due progetti rimangono separati ed indipendenti, con l’unico punto di contatto dato dal fatto che ParteciPa è basato sul riuso di Decidim.”
Tale affermazione conferma senza ombra di dubbio la violazione, quindi il danno erariale.
Io nelle linee guida ci leggo qualcosa di diverso, ma va bene lo stesso. L’interpretabilità e’ il sale della vita!
Evidentemente la persona della Funzione pubblica che ti ha risposto la vede come me. Non ti ha scritto: ho violato le linee guida scientemente, ha solo constatato la realta’ dei fatti: ha riusato (nell’accezione comune del termine) decidim per creare parteciPA come progetto separato, in linea con la licenza os di decidim e, a mio parere e anche suo a quanto pare in linea con le linee guida su acquisizione del software (e qui uso “acquisizione” perche’ per me quando le linee guida parlano di riuso parlano di riuso di un software os di cui e’ titolare una p.a.).
Evidentemente per te questo è un fatto grave e un attentato all’economia della colletività, per altri e’ perfettamente in linea con quanto indicato dalle linee guida.
Resta poi il fatto, che e’ quello che ha scatenato la mia prima risposta, che - a prescindere dal fatto se in questo caso si sia rispettata la normativa (di basso rango) o meno - non vedo un grande beneficio economico nell’adozione di riuso di opensource e di opensource, tanto se non sei un nerd abile programmatore, l’“incaricato fornitore di servizi” (terminologia dell’allegato D) sempre fra i 300 e i 1200 euro/(giornata*uomo) ti prende…
Non capisco cosa manca? Forse Manca una PR da parte di PartciPA sul repository upstream di Decidim?
Perché poi il ruolo di gatekeeper ce l’hanno comunque sempre quelli di Decidim.
Ipotizziamo che la PR va fatta comunque, vista la risposta che hanno dato quelli di Decidim, ci sono grosse probabilità che non siano interessati a revisionarla e/o a fare il merge.
I permessi di scrittura sul repository upstream sono comunque in mano a loro e la PR potrebbe rimanere parcheggiata a tempo indeterminato o chiusa senza essere revisionata.
A quel punto cosa fa la PA? Prova periodicamente ogni tot mesi a riaprire una PR?
Al di la della buona volontà di aprire una PR la capicità di revisionarla mergiarla o chiuderla è di diritto al progetto upstream.
Appunto.
Ripeto, le parti di linee guida che regolano la condivisione di software opensource non possono che applicarsi a software di cui e’ titolare una p.a. italiana. Per dirla col vocabolario opensourcese - che mi state insegnando a conoscere - si applicano solo quando il progetto upstream (o il fork o il il fork() ) è in capo a una p.a. che diventa gatekeeper del repository e valuta le PR.
Fra l’altro, pare che a mr. decidim non gliene importi nulla di “mergiare” una eventuale PR sulla spid authentication. Meno male che il gatekeeper ultrapireneo non fa giurisprudenza in Italia, altrimenti alla Funzione pubblica sarebbe da chiedere indietro i soldi buttati via!!!
Stefano, mi pare che il tuo lavoro vada decisamente nella direzione delle linee guida superando la palese violazione della Funzione Pubblica, tuttavia sia in altrettanta violazione delle linee guida riuso nei seguenti punti:
Nel caso di modifiche necessarie per implementare le nuove funzionalità, l’Incaricato è tenuto (MUST) a prendere contatto con il maintainer attraverso i canali pubblici del repository (issue tracker) in modo da presentare il nuovo caso d’uso, proporre la modifica ed ottenere feedback sulle modalità da seguire soprattutto nell’ottica di scrivere modifiche che possano essere incorporate dal maintainer originale.
Al termine dello sviluppo, l’Incaricato è tenuto a proporre al maintainer originale le proprie modifiche (MUST), con delle proposte di codice (pull request) granulari, ovvero distinte per singole funzionalità in modo da consentire al maintainer di valutarle singolarmente.
Non sei entrato in contatto con il maintainer PRIMA di sviluppare e NON hai fatto quanto indicato nelle linee guida:
“presentare il nuovo caso d’uso”
“nell’ottica di scrivere modifiche che possano essere incorporate dal maintainer originale”
Diversamente, in merito alla violazione di cui sopra hai sviluppato e solo dopo preso contatto con il maintainer presentando il risultato a cose fatte, cioè non orientando il modus operando secondo quanto previsto dalla legge.
Non hai proposto modifiche granulari, andando in violazione del punto delle linee guida:
"proporre al maintainer originale le proprie modifiche (MUST), con delle proposte di codice (pull request) granulari, ovvero distinte per singole funzionalità "
Come ti viene fatto notare dal commento difatti, la pull request non è granulare e distinta, rendendo quindi difficile e oneroso effettuarne una review e integrazione:
“Also, repo owners don’t like to see so many changes in a PR that are unrelated to the need being addressed.”
Anche qui mi pare che ci sia su eidas-saml-extensions un mancato rispetto delle linee guida riuso Allegato D nei punti su indicati.
Come post mortem analisys, avendole seguite e cioè avendo PRIMA presentato lo use-case al maintainer, avendo conseguentemente implementato SECONDO I SUGGERIMENTI RICEVUTI, e avendo DOPO fatto dell pull request secondo la granularità richiesta, molto probabilmente sarebbero state re-integrate.
Così invece, c’è un danno economico per la collettività, dovendo mantenere codice non pensato per essere integrato e riusato nel progetto originario, costi che si quantificano:
O nel tuo lavoro di ri-scrittura delle modifiche secondo le linee guida ai fini di accettazione
O di mantenimento di versioni di software disallineate e di maggiore costo di manutenzione correttiva ed evolutiva.
In entrambi i casi la collettività subisce un maggior costo per la mancata opportunità di integrazione.
Se la PA opera secondo le linee guida riuso, che rappresentano un obbligo di operare secondo i modelli di contribuzione opensource, i progetti terze parti usate come base vedranno un miglioramento a beneficio complessivo di tutti con forti riduzioni di costi di manutenzione correttiva ed evolutiva.
Le linee guida non obbligano a non fare un fork, ma obbligano a lavorare nel modo migliore affinché ciò abbia la maggiore probabilità di essere evitato.
Se la PA che modifica software terze parti o il suo fornitore non operano in tal senso, stanno ponendo le basi per il danno erariale conseguente, non hanno cioè operato affinché i costi di manutenzione evolutiva e correttiva siano drasticamente ridotti, così come il lock-in del fornitore/in-house della PA.
Un altro elemento da considerare è la formazione di professionalità che conoscano come ci si muove in un progetto collaborativo in software libero. Non sono competenze che si acquisiscano da un giorno all’altro o con un tratto di penna di qualche dirigente.
Capisco che le PA spesso non abbiano le risorse per investire sulle professionalità, e che certe competenze siano difficili da reperire sul mercato, ma è un cane che si morde la coda. Il caso francese mi pare abbia dimostrato (almeno secondo i numeri di uno studio citato in precedenza) che l’investimento pubblico ha aumentato significativamente la partecipazione di sviluppatori francesi ai vari progetti in software libero, allargando quindi il bacino di professionalità a cui attingere. Probabilmente non ci si può aspettare che siano gli operatori privati a spendere capitale per creare tali competenze e metterle sul mercato, specie quando non c’è garanzia che la PA vada effettivamente a comprare tali competenze in futuro (dato che c’è sempre la possibilità di ignorare bellamente le leggi e le linee guida, e andare a comprare software proprietario da qualche megafornitore monopolista).
Non è che sono contrario a quello che dici del resto la pull Request non è mia ma era solo per prendere un esempio.
In linea di principio però e giusto anche sottolineare che se ti devi mettere d’accordo sempre prima del design con i manutentori, in base anche alla loro disponibilità di tempo o interesse sulla questione specifica, rischi di dover aspettare a scrivere del codice finché non si trova la quadra o puoi finire anche su un binario morto.
Ad esempio il tuo thread con il Manutentore di Decidim, anche dopo che gli hai spiegato Eidas, non mi sembra sia molto vivo.
Cioè è giusto che ci devi provare prima ma è anche vero il fatto che se per questioni di tempo o interesse non si trova una quadra in tempi “decenti” rimani comunque bloccato nell’iniziare lo sviluppo della funzionalità e anche questo crea un danno economico alla collettività perché alla fine risulta che non hai nulla di utilizzabile a livello pratico.
