menu di navigazione del network

Linee Guida OpenSource a Software Whistleblowing ANAC


(Maurizio De Magnis) #1

Buongiorno,

sono Maurizio De Magnis, sviluppatore e cittadino di Desio.

Da un po’ di tempo sto cercando di aiutare il Comune di Desio ad implementare una buona soluzione di Whistleblowing.

In seguito alla notizia di ANAC del 08/02/2018 di creazione di un servizio di Whistleblowing su base nazionale, ho verificato che ANAC sta ora usando un sw Open Whistleblowing, una versione leggermente personalizzata (e non aggiornata) del software opensource GlobaLeaks.

Ho quindi suggerito al Comune di Desio l’adozione di Globaleaks e l’URP mi ha risposto dicendo che aspettano che ANAC rilasci tale software nel catalogo del riuso AgID, come da comunicato di ANAC:

“l’obiettivo dell’Autorità è la realizzazione di un sistema per la gestione delle segnalazioni di condotte illecite da inserire nel catalogo del riuso tenuto dall’Agenzia per l’Italia Digitale (AgID) in modo da renderlo disponibile a tutte le Amministrazioni che ne vorranno fare uso al fine di gestire le segnalazioni provenienti dal proprio interno. La disponibilità del sistema nel catalogo del riuso sarà, logicamente, soggetta alle regole dettate dalla stessa Agenzia che avrà cura di verificarne il rispetto anche in termini di qualità del software e qualità della documentazione.”
Fonte

Ora, dato che:

  1. il catalogo del riuso AgID non avrà vita lunga. È anzi sicuro che verrà cestinato e rimpiazzato da altre linee guida:

http://www.agid.gov.it/catalogo-nazionale-programmi-riusabili

ed è quindi improbabile che ANAC possa pubblicarlo lì come ha invece indicato;

  1. Open Whistleblowing è una versione vecchia (2 anni) rispetto a GlobaLeaks e che quindi:
    • GlobaLeaks sia considerabile quantomeno assimilabile alla soluzione implementata da ANAC (Open Whistleblowing) in quanto ad aderenza alle linee guida ANAC
    • Globaleaks sia considerabile la più robusta evoluzione della soluzione implementata da ANAC (Open Whistleblowing), comprendente non solo il mero bug fixing ma anche importanti evolutive in fatto di manutenibilità ed esperienza utente (ho letto che include il webserver HTTPS con LetsEncrypt, introduce il supporto multi-database, supporto multi-sito, API di provisioning e addirittura il cambio dell’ORM perché quello della versione su cui si basa OpenWhistleblowing non è più manutenuto perché non python3-compliant)

Open Whistleblowing risulta essere indietro di 3354 commit rispetto alla versione corrente di GlobaLeaks.

Sarebbe utile se AgID e ANAC chiarissero la propedeuticità o meno, per una PA come quella del Comune di Desio, di attendere la disponibilità nel catalogo del riuso di Open Whistleblowing.

Anche sul Forum GlobaLeaks ci sono tecnici della PA che chiedono che venga fatta chiarezza su quale software usare e come!

Soprattutto, non sarebbe più comodo per le PA se ANAC rilasciasse nel catalogo del riuso (ammesso che questo esisterà ancora) direttamente GlobaLeaks o che ANAC contribuisca con le sue modifiche con una pull request?

Grazie in anticipo per il tempo e per l’impegno che dedicate. :slight_smile:


(Daniele Scasciafratte) #2

@fpietrosanti può dirti di più riguardo la questione visto che lui “comanda” su globaleaks


(Giovanni Bajo) #3

Ciao,

La tua domanda tocca due temi: come effettuare in modo corretto la modifica di un software upstream, e come scegliere tra più fork. Vediamo il primo.

A livello generale, oggi non c’è nessun tipo di indicazione o incentivo a essere dei “bravi cittadini” del mondo open source (passami il termine); d’altra parte, anche nel mondo privato (soprattutto nelle enterprise) non è così diffuso il concetto che il coordinamento con l’upstream possa avere benefici di medio termine, e quindi può succedere che si massimizzi il breve termine, effettuando fork e dimenticando l’upstream. È anche vero che il mondo open-source è molto vasto ed è difficile sapere, a priori, se l’upstream sarà responsivo a sufficienza, se accoglierà le modifiche che si mandano (anche fossero solo bugfix!), se respingerà del tutto alcune modifiche perché fuori dallo scopo del programma, e così via. Io stesso mi sono trovato in difficoltà con PR pendenti per anni praticamente senza feedback, nonostante numerosi ping.

Detto questo, nelle linee guida OSS stiamo indicando come modello preferenziale quello di collaborazione con upstream, dando indicazioni teoriche e pratiche sul fatto che sia preferibile un modello di collaborazione (laddove upstream sia presente e collaborativo). In particolare, uno degli allegati sarà proprio una guida tecnica che, per esempio, ANAC (seguendo queste linee guida, se ci fossero state) avrebbe allegato alla gara d’appalto per richiedere al fornitore la collaborazione con upstream.

Vediamo ora il tema della scelta di un software tra più fork.

In generale, una PA deve scegliere un software che le consenta di adempiere alle norme vigenti. Non posso giudicare il caso specifico perché non conosco nel dettaglio le norme, GlobalLeaks né tanto meno le modifiche che ANAC ha commissionato, ma mi sento di dire che, in linea generale, possa tranquillamente succedere che un software, per quanto vicino alle esigenze di una PA, possa richiedere degli adattamenti per essere perfettamente allineato, e non necessariamente le modifiche necessarie potranno sempre essere riportate upstream e/o configurate come default. Mi viene in mente, per esempio, che una PA potrebbe volere “spegnere” alcune funzionalità che non servono e/o sono potenzialmente fuori norma (anche solo per evitare errori umani compiuti dagli utenti). Di conseguenza, l’indicazione che stiamo dando nelle linee guida è che, in linea generale (di “default”), è sempre preferibile utilizzare il software rilasciato da un’altra PA (cosiddetto “riuso” nel CAD) poiché probabilmente più allineato alle proprie necessità. Detto questo, ovviamente, ciascuna PA è libera di effettuare una valutazione di dettaglio diversa, conoscendo il contesto della norma e le opzioni specifiche che sta valutando.

Come ulteriore punto, le linee guida chiedono che, all’interno dei contratti di manutenzione, venga sempre effettuato un’attività di tracciamento dell’upstream. Se dunque ANAC (come penso sia utile, vista la delicatezza della materia in questione) vorrà occuparsi della manutenzione, in allegato alla gara vi sarà sperabilmente una guida che abbiamo preparato che chiede al fornitore di valutare ogni nuova versione rilasciata upstream per un eventuale allineamento, anche ai fini della sicurezza. Se dunque il fork di ANAC sarà mantenuto, possiamo sperare che questo divario che si è accumulato vada a ridursi, tramite le indicazioni delle linee guida che spingono in questa direzione.


(Maurizio De Magnis) #4

Ciao Daniele! :slight_smile:

In realtà le PA (come il Comune di Desio) si affidano quasi ciecamente alle linee guida istituzionali e su questo poco può fare il buon @fpietrosanti :sweat_smile: .

Un estratto dalla risposta del Responsabile prevenzione della corruzione del Comune di Desio:

[…] le comunichiamo che sul tema l’Amministrazione Comunale ha preso atto di quanto dichiarato da ANAC lo scorso 21 settembre 2017 qui https://www.anticorruzione.it/portal/public/classic/Comunicazione/News/_news?id=a4698f830a77804245e7ad43fa4ee680 .
Nel citato documento ANAC ribadisce che “l’obiettivo dell’Autorità è la realizzazione di un sistema per la gestione delle segnalazioni di condotte illecite da inserire nel catalogo del riuso tenuto dall’Agenzia per l’Italia Digitale (AgID) in modo da renderlo disponibile a tutte le Amministrazioni che ne vorranno fare uso al fine di gestire le segnalazioni provenienti dal proprio interno. La disponibilità del sistema nel catalogo del riuso sarà, logicamente, soggetta alle regole dettate dalla stessa Agenzia che avrà cura di verificarne il rispetto anche in termini di qualità del software e qualità della documentazione.” […]

Ora, dato che il catalogo del riuso è in già in fase di dismissione e volendo fornire al Comune di Desio una soluzione lungimirante, risulta propedeutica una risposta/suggerimento “istituzionale”. :slight_smile:


(Fabio (Naif) Pietrosanti) #5

Ciao Maurizio e Giovanni,

su questo tema del riuso software whistleblowing percepisco che ci sia una certa complessità da dipanare.

Facendo una fotografia ad oggi ci sono parecchie centinaia di pubbliche amministrazioni che già usano GlobaLeaks (oramai abbiamo perso il conto, ne scopriamo di nuove da google alert e dalle richieste di supporto fra forum ed email), addirittura stanno nascendo tante aziende che erogano servizi sulla base del software (ne ho contate 5, facendo un censimento da ricerca su google), di cui una ha realizzato proprio il sistema di Whistleblowing di Agid (usando una versione lievemente modificata di GlobaLeaks) il quale lo aveva già messo in riuso nel catalogo riuso.

Per cui per Maurizio, se dovessi rispondere alle domande:
Ma GlobaLeaks è già in riuso?
Si nella forma, fatto da Agid 1-2 anni orsono con il vecchio catalogo riuso, ma in una edizione del software modificata da una delle società private con finalità di lucro che lo sta installando in giro (società privata che purtroppo non ha poi contribuito al progetto opensource con pull request, ha fatto un fork privato che si è trovata a non mantenere aggiornato, uno dei potenziali rischi che si potrebbero correre con il riuso ANAC).
Si, nella sostanza, con centinaia di aziende pubbliche e aziende private controllate dal pubblico che lo hanno installato e ogni giorno lo installano (contiamo 5-6 installazioni al giorno e alcuni deployment che abbiamo visto hanno anche 40-50 enti attivati sullo stesso server).

Tuttavia quanto messo in riuso non è quanto effettivamente poi usato e diffuso come adozione allo stato corrente.

Consideriamo che, dato che gli enti pubblici adoperano il sistema di whistleblowing digitale sulla base delle linee guida ANAC, che è anche il soggetto deputato a verificare, ispezionare ed eventualmente sanzionare, l’edizione software GlobaLeaks in riuso ANAC sarebbe quella che teoricamente prenderebbe maggiore adozione laddove dovesse esistere sotto forma di fork().

E’ nostro impegno come Centro Hermes, una volta che ANAC rilascerà qualsivoglia modifica software o questionario, di integrarlo nel software GlobaLeaks per renderlo a disposizione dietro un bottone di un “Profilo di configurazione ANAC”, visto che già oggi ci sono interlocuzioni per fare i “Profili di configurazione” per Comuni, ASL, Anticorruzione in Spagna, e così via.

In questo modo le centinaia di PA che in autonomia hanno già installato il software, potranno essere “allineate” e avere la manutenzione comunitaria che oggi esiste del progetto e la “compliance” con le feature/questionari/modelli rilasciati ANAC.

Come commento/considerazione in merito a potenziali criticità inerenti la manutenzione evolutiva del progetto di Whistleblowing Digitale in ambito ANAC:

  • non pare essere esposta né una roadmap; né un bucket di ticket di sviluppo pubblici;
  • l’aggiudicatario del bando che dovrebbe occuparsi della MAD/MAC non pare occuparsi di questo tema/progetto in modo specifico (da ricerca online pare faccia principalmente servizi di helpdesk in outsourcing);
  • nel bando specifico non sono in alcun modo indicate come attività da svolgere tutte quelle necessarie sia al rilascio in riuso (che non è la mera pubblicazione sul vecchio catalogo riuso come erroneamente spesso interpretato da giuristi non avvezzi di tecnologia) sia necessarie al supporto e gestione della comunità di utilizzatori e futuri contributori del progetto, quindi chi se ne occuperà?

In generale a riguardo di GlobaLeaks penso che il modello di riuso da parte di ANAC dovrebbe almeno:

  • considerare lo status quo di diffusione della tecnologia e l’assenza di un piano di manutenzione evolutiva dello stesso
  • considerare la criticità di assenza di un percorso di sviluppo che “nasce collaborativo” e che avrebbe quindi delle legittime-naturali difficoltà nel diventarlo ex-post (se non, IMHO, tramite l’integrazione delle minori modifiche apportate da ANAC all’interno del software GlobaLeaks, task che comunque noi faremo a prescindere)
  • vedere coinvolti da T-0 tutti gli stakeholder della tecnologia sottostante (ovvero anche noi, ma anche le varie aziende ed enti pubblici che ci stanno mettendo mano nel percorso di adozione);

Tutto ciò sarebbe necessario per non ingenerare ulteriori dubbi e incertezze, come quelli sottolineati da @silva ed altri.

Scriverò a breve ai contatti con cui due anni orsono facemmo il workshop con ANAC che ha dato inizio alla sua sperimentazione proponendogli se volessero dal punto di vista implementativo affrontare il riuso come ha fatto la Città di Barcellona, dove:

  • sono state fatte delle personalizzazioni reintegrando upstream tutte le funzionalità aggiuntive realizzate
  • sono stati predisposti opportuni profili di configurazione che possono essere applicati dagli utilizzatori (e questi sono oggi redistribuità dalla città di barcellona)
  • le modifiche saranno entro un paio di mesi integrate nel software a vantaggio del progetto stesso e della sua intera comunità di utenti, usando la nuova feature dei “Profili di Configurazione”

Con la Città di Barcellona abbiamo anche convenuto quali testi dovranno essere sulla pagina web di GlobaLeaks in catalano per sottolineare l’evidenza del progetto nell’ambito della PA della Catalogna, lo stesso si potrebbe fare per il sito globaleaks in Italiano.

Certo è che, la legittima domanda che mi porrei come ANAC, in quale modo mi posso accordare in merito alla governance del progetto, ovvero le regole di “open-governance” che per quello che ho inteso saranno definite dalle nuove linee guida riuso di prossimo rilascio ?

Cioè in quale modo potere garantire l’ente pubblico ANAC che il software GlobaLeaks rispecchi sempre, nel tempo, le sue linee guida e che un domani non cambi il suo scopo e inizi a mostrare nyancat javascript che girano per lo schermo come easter-egg del primo aprile?

Ecco, su questo ho proprio una domanda aperta, che si dovrà porre nelle linee guida riuso che andranno in consultazione, perché tanti saranno gli enti pubblici che baseranno il loro sviluppo sulla base di un progetto open-source esistente, faranno fare le modifiche software necessarie al suo specifico scopo d’uso alla azienda X o alla in-house Y, ma a quel punto si troveranno di fronte a due scelte:

a) Fare un fork() del progetto OSS da cui sono partiti e assorbire tutto l’oneroso l’impegno di manutenzione correttiva ed evolutiva senza beneficiare dei contributi del progetto principale, magari trovandosi dopo uno o due anni indietro di migliaia di commit, features e bugfixes

b) Contribuire al progetto originale da cui sono partiti con delle pull requests, ma in questo caso non avrebbero garanzie “contrattuali” (e nella PA le garanzie sono tutto) né che le modifiche saranno integrate né che saranno manutenute nel tempo. Magari i maintainer del progetto open-source su cui si sono basati non sono neanche in Italia e ci sono difficoltà linguistiche nel dialogarci.

E’ ovvio che sarebbe sempre meglio evitare fork, soprattutto quando si fanno minori modifiche, ma questo richiede che vi sia una costante partecipazione al progetto e che vi sia una disponibilità del progetto open-source su cui la PA ha sviluppato ad avere un modello di governance che fornisca alla PA le “garanzie” che le features di cui ha bisogno rimangano e soprattutto vengano integrate.

In uno scenario simile, come venirne fuori e risolvere affinché ci sia sia la massima efficienza operativa con riduzione costi (quindi no-fork() e distribuzione del costo di manutenzione evolutiva e correttiva sulla comunità esistente) ma ci siano le “garanzie” necessarie affinché l’ente pubblico sia tranquillo che lo strumento software faccia sempre quel che dovrebbe fare e includa sempre le modifiche software che gli sono necessarie?

Mi sembra un problema interessante da affrontare, ragionare e risolvere, al di là del caso specifico GlobaLeaks, perché penso che si porrà numerose volte con le nuove linee guida riuso, e nessuno auspica di vedere centinaia di fork() di progetti opensource fatti dalla PA italiana (pensiamo a fork della PA italiana di wordpress, django, jboss, apache, postfix, nginx, amavis, discourse, insomma non avrebbe molto senso…)

Quale sarebbe l’indirizzo/suggerimento che Agid e Team Trasformazione Digitale darebbero in un caso simile?

Fabio


(Fabio (Naif) Pietrosanti) #6

Ciao a tutti,

volevo condividere che abbiamo lanciato un servizio gratuito di Whistleblowing per la PA Italiana (e sue controllate) assieme a Transparency International chiamato WhistleblowingPA su https://www.whistleblowing.it .

Il servizio è gratuito, basato sul Software OSS GlobaLeaks, fornisce all’ente una istanza virtuale pre-configurata per compliance 190/2012 e 179/2017 per la PA con la conoscenza specifica di Transparency (noi come Centro Hermes facciamo i tecnologhi) https://NOME-ENTE.whistleblowing.it .

Fabio


(Fabio (Naif) Pietrosanti) #7

Ieri 16 Gennaio 2019 l’Autorità Nazionale Anticorruzione (ANAC) ha pubblicato l’edizione di GlobaLeaks da loro chiamata OpenWhistleblowing, realizzata a partire dalla edizione Software GlobaLeaks del 2016 versione 2.60.144.

In quanto sviluppatori del software GlobaLeaks, come Centro Hermes, abbiamo effettuato immediatamente una analisi del software pubblicato e rendiamo quì pubblicamente disponibile la nostra Valutazione tecnica dell’edizione GlobaLeaks messa in riuso con nome OpenWhistleblowing da ANAC .

Riteniamo che le modifiche minori di tipo funzionale apportate alla edizione OpenWhistleblowing 1.0.1 di ANAC vadano re-integrate nella più moderna, performante e manutenuta edizione ufficiale di GlobaLeaks 3.6. Difatti la diffusione di una edizione di software basata su componenti tecnologiche non più manutenute comporterebbe un certo aggravio di costi di installazione e manutenzione per la PA, nonché potenziali rischi di cybersecurity.

Ulteriormente, in considerazione delle diverse PA che effettuano progetti di riuso su base GlobaLeaks, pubblichiamo la guida sulle Regole di Riuso per Software di Whistleblowing Anticorruzione GlobaLeaks dove sono indicate le diverse esigenze di compliance nell’operare su GlobaLeaks, in quanto software opensource di terze parti. Non è stata ancora effettuata una analisi di compliance dell’edizione software in riuso da parte di ANAC.

In seguito condividiamo il risultato sintetico della valutazione tecnica al 15/01/2019

Risultato sintetico della valutazione tecnica

ANAC ha rilasciato in data 15/01/2019 l’edizione GlobaLeaks dal nome OpenWhistleblowing sul repository Github https://github.com/anticorruzione/openwhistleblowing .

Tale edizione è basata sul software GlobaLeaks versione 2.60.144, rilasciato il 14 Marzo 2016.

Lo sviluppo software effettuato dal fornitore di ANAC è basato sull’edizione 2.x, obsoleta, invece che sulla attuale 3.x; in questo modo il software rilasciato da ANAC non gode dei benefici e miglioramenti apportati dalle centinaia di correzioni e nuove funzionalità che trovano spazio nell’edizione 3.x, richiedendo quindi ulteriori adeguamenti con i connessi costi.

L’edizione correntemente manutenuta e diffusa del software GlobaLeaks, è giunta alla edizione 3.6.

GlobaLeaks 3.6 rispetto alla edizione ANAC ha avuto significativi miglioramenti conseguiti in oltre 5 anni uomo di sviluppo software, tecnicamente realizzati attraverso 7357 commit, 911 file cambiati di cui 263.257 righe aggiunte e 33.946 righe rimosse e oltre 202 versioni intermedie rilasciate in cui sono state introdotte oltre 630 funzionalità tra minori, maggiori, e correzioni di irrobustimento.

Tali significativi miglioramenti non sono disponibili nella edizione GlobaLeaks rilasciata da ANAC, in quanto non re-integrata all’interno del supporto software della edizione 3.x .

L’edizione GlobaLeaks rilasciata da ANAC con il nome OpenWhistleblowing presenta le seguenti caratteristiche, dal punto di vista della valutazione tecnica:

  • si basa su una edizione di GlobaLeaks piuttosto vecchia (2.60.144 del 14/03/2016) senza recepire alcuno dei suoi aggiornamenti evolutivi o correttivi;
  • impiega alcune componenti tecnologiche core obsolete, non più mantenute e abbandonate dagli sviluppatori originali, e ciò introduce rischi di sicurezza oltre ad aumentare significativamente i costi di manutenzione;
  • aumenta la complessità e costo di installazione e manutenzione introducendo software terzi come dipendenze funzionali (postgresql, tor2web, apache) andando nella direzione opposta agli obiettivi di design del progetto GlobaLeaks (autocontenimento e semplificazione per installazione, manutenzione e gestione);
  • introduce funzionalità, quali ad esempio la rimozione dei metadati, che vanno a ledere l’integrità dei dati apportati come evidenze documentali dai segnalanti, rendendoli di difficile impiego in giudizio;
  • manca della completa pubblicazione dei codici sorgenti;
  • manca della pubblicazione della documentazione in formato editabile;
  • manca della pubblicazione di tutti gli applicativi software menzionati nel manuale installatore;
  • non è stato effettuato un riuso software secondo quanto determinato da AgID, in particolare orientato alla collaborazione e integrazione delle modifiche nel software opensource di terze parti;
  • aumenta i costi di approvvigionamento hardware, con requisiti esagerati (3 server per 72GB di RAM, 10 CPU core e 600GB di dischi) di un ordine di grandezza superiori rispetto all’edizione software GlobaLeaks 3.6 (1 server con 2GB di RAM, 20GB di disco e 2 core);
  • aumenta i costi di approvvigionamento software, richiede l’uso di sistemi operativi commerciali, Redhat Enterprise Linux Server 7.x, con almeno 3 licenze server per circa 1.000 euro di costi di licenze software;
  • aumenta la superficie di vulnerabilità applicativa, richiede di disabilitare le funzionalità di sicurezza informatica native del sistema operativo (SELinux Sandboxing).

Per approfondimenti, domande, dubbi, elaborazioni e ragionamenti sul tema si può usare tanto il forum quanto condividere la chat pubblica GlobaLeaks nel canale #globaleaks-support-it.

Saluti
Fabio Pietrosanti


(Giulia Macchi) #8

Proprio questa mattina abbiamo preso visione della circolare ANAC e pur non essendo specialisti è subito saltato all’occhio il problema delle risorse, in un momento in cui, tra l’altro, è vietato potenziare il datacenter ed è ancora abbastanza nebulosa la questione della migrazione verso i PSN… :3 server per 72GB di RAM, 10 CPU core e 600GB di dischi per implementare un sistema che probabilmente (si spera almeno) non farà nulla per la maggior parte della sua vita pare un po’ esagerato. Nei casi poi come il nostro di una Unione che aggrega come sistemi informativi 9 enti (8 comuni più l’unione stessa), basta fare due conti per capire che effettivamente diviene improponibile, a meno di fare una macchina unica, cosa che però mette sul tavolo il problema dei custodi delle chiavi che nel nostro caso sarebbero più di uno… In parole povere è apprezzatissimo (almeno da noi) l’intento di fornire una mano ai poveri enti… speriamo però che la cosa non finisca qui, e che si dia seguito sia alla migrazione sulla nuova edizione di GlobalLeaks 3.6, sia ad una soluzione multiente, oppure che richieda risorse inferiori. Un saluto e grazie per l’attenzione


(Fabio (Naif) Pietrosanti) #9

Salve Giulia,

abbiamo implementato assieme a Transparency International Italia il servizio di Whistleblowing Anticorruzione gratuito WhistleblowingPA a cui ci si può iscrivere gratuitamente su https://www.whistleblowing.it .

WhistleblowingPA è interamente realizzato su base GlobaLeaks 3.6 con codice opensource, così da facilitare la replica e realizzazione di iniziative di Whistleblowing Anticorruzione anche da parte di unioni di comuni, società in-house, regioni e così via dicendo second una logica di “riuso” che integri i le funzionalità di multi-tenancy di GlobaLeaks 3.x (ovvero la possibilità di creare un numero virtualmente illimitato di istanze/siti di whistleblowing su un singolo server fisico).

Ad oggi su un singolo server con 2GB di RAM ci girano oltre 500 siti, parliamo di ordini di grandezza inferiori rispetto all’approccio di requisiti proposto da ANAC usando la versione di GlobaLeaks datata di circa 3 anni orsono 2.x (che ha numerosi problemi di prestazioni nonché di manutenibilità).

Difatti come Centro Hermes stiamo andando a reintegrare in GlobaLeaks 3.6 quelle 4 piccole modifiche funzionali che sono state apportate da ANAC a GlobaLeaks sulla non più manutenuta edizione GlobaLeaks 2.x, così da consentire alla PA di basare le proprie installazioni su un software manutenuto e usato già da migliaia di organizzazioni nel mondo.

Annunceremo a breve la data di reintegrazione di queste 4 modifiche minori apportate al software, confidando che ANAC come atto di responsabilità e consapevolezza non diffonda e promuova l’uso di un software non più manutenuto, nonché privo di una comunità e di una base di utenti reali.

Se hai bisogno di supporto nell’andare in una direzione (iscrivendo i propri enti al servizio gratuito WhistleblowingPA) o un altra (dotandoti di infrastruttura propria usando l’opensource GlobaLeaks 3.6), possiamo darti supporto pro-bono in chat su https://slack.hermescenter.org sul canale #globaleaks-support-it dove ci sono già molti RPCT nonché IT di enti e in-house che usano il software e si supportano vicendevolmente.

Saluti
Fabio Pietrosanti


(Giulia Macchi) #10

Per il momento ti ringrazio moltissimo, studieremo un po’ quello che ci hai indicato e proveremo a proporre la soluzione migliore ai responsabili anticorruzione dei nostri enti, cercando di fare capire loro i problemi tecnici della proposta dell’ANAC.


(Alessandro Vecchi) #11

Scusate la domanda… ma, a prescindere da tutto, qualsiasi sia la soluzione che un ente decide di utilizzare: dove andrebbe richiamata sul sito web dell’ente? esiste una direttiva o perlomeno un’indicazione di massima su dove posizionare il link alle segnalazioni? In tal senso io non ho trovato alcuna informazione e, nell’ottica di standardizzazione dei siti web della PA, credo che sia una grave lacuna: si rischia che ognuno faccia a modo suo vanificando il concetto di modello condiviso.


(Gianni Bassini) #12

Nell Albero della Trasparenza
Amministrazione trasparente -> altri contenuti ->prevenzione della corruzione-> Segnalazione di episodi di corruzione


(Alessandro Vecchi) #13

Ciao Gianni,
ti ringrazio per la risposta ma non esiste una sottosezione “Segnalazione di episodi di corruzione” che io sappia e non è consigliabile crearne arbitrariamente.
Io penso che possa essere inserito genericamente in “altri contenuti / prevenzione della corruzione”.

ho visto anche inserirlo in “Altri contenuti / Prevenzione della Corruzione / Atti di accertamento delle violazioni” ma non mi sembra corretto.