[LG-SW] 2. Linee Guida sull'acquisizione di software

Consultazioni pubbliche LG acquisizione e riuso di software per la pa
1

Collegamento:
https://lg-acquisizione-e-riuso-software-per-la-pa.readthedocs.io/it/latest/acquisizione-software.html

Contenuto:
2. Linee Guida sull’acquisizione di software
2.1. Introduzione e contesto normativo
2.2. Oggetto della valutazione
2.3. Valutazione comparativa
2.3.1. Descrizione delle soluzioni
2.3.2. Descrizione dei criteri per la valutazione
2.3.3. Descrizione delle macro-fasi
2.4. Macro fase 1: Individuazione delle esigenze
2.4.1. Fase 1.1: Analisi del fabbisogno
2.4.2. Fase 1.2: Individuazione dei vincoli
2.4.3. Fase 1.3: Redazione del documento descrittivo delle esigenze
2.5. Macro fase 2: Analisi delle soluzioni a riuso delle PA e delle soluzioni Open Source
2.5.1. Fase 2.1: Selezione soluzioni riusabili per la PA
2.5.2. Fase 2.2: Valutazione soluzioni riusabili per la PA
2.5.3. Fase 2.3: Approvvigionamento della soluzione riusabile per la PA
2.5.4. Fase 2.4: Selezione soluzioni Open Source
2.5.5. Fase 2.5: Valutazione soluzioni Open Source
2.5.6. Fase 2.6: Approvvigionamento della soluzione Open Source
2.5.7. Fase 2.7: Accertamento impossibilità
2.6. Macro fase 3: Analisi delle altre soluzioni
2.6.1. Fase 3.1: Ricerca soluzioni proprietarie
2.6.2. Fase 3.2: Studio realizzazione ex-novo
2.6.3. Fase 3.3: Comparazione soluzioni proprietarie e realizzazione ex novo
2.6.4. Fase 3.4: Approvvigionamento soluzioni proprietarie o realizzazione ex novo
2.7. Total Cost of Ownership (TCO)
2.8. Scelta della modalità di erogazione del software

2

Miglioramento Proposto:
La Fase 2.2 (paragrafo 2.5.2) fa imputare alla eventuale soluzione in riuso (e forse anche all’eventuale soluzione open source: il paragrafo 2.5.5 è molto più blando in termini di specifiche) i costi di formazione sia degli addetti alla sua manutenzione che degli utenti finali, mentre la Fase 3.1 (paragrafo 2.6.1) prevede, per l’eventuale soluzione proprietaria, la valutazione dei soli costi di formazione degli addetti. Ciò si traduce in un indesiderabile vantaggio per le soluzioni proprietarie.

Caso d’uso probabilmente comune (i nomi dei prodotti sono ovviamente casuali :wink: ): Migrazione dal classico Office a LibreOffice VS Migrazione dal classico Office a Office 365. In entrambi i casi si opta per una soluzione diversa da quella di partenza, ed anzi il secondo prevede uno stravolgimento del paradigma d’uso da parte dell’utente finale (che a maggior ragione dovrà essere sottoposto a formazione), è chiaro che questo deve impattare sull’analisi dei costi di entrambe le scelte.
A tal pro, mi sono permesso di avanzare una semplice PR direttamente su GitHub.

Considerazione 1:
Nel Capitolo 3 si raccomanda (giustamente!) di allegare ai capitoli tecnici dei bandi di gara le varie Guide per pubblicazione e modifica di software opensource, ma da nessuna parte nel Capitolo 2 viene raccomandato di pubblicare anche la Valutazione comparativa in caso di scelta di una soluzione proprietaria. Credo che questo dovrebbe essere un requisito indispensabile, per garantire la massima trasparenza delle procedure e la verifica dell’applicazione delle Linee Guida.

Considerazione 2:
Data la già citata limitatezza del paragrafo 2.5.5 (Valutazione delle soluzioni Open Source), credo che non sia stato dato adeguato spazio all’opzione di personalizzazione di una soluzione open esistente. Penso che una soluzione già esistente cui mancano solo alcune funzioni per coprire i bisogni (descritti nel Capitolo 2.4) dovrebbe comunque essere preferibile alla reimplementazione ex-novo o all’adozione di una soluzione proprietaria, ma tale principio dovrebbe essere espresso in maniera esplicita.
Potrebbe bastare estendere i criteri di valutazione delle soluzioni riusabili (paragrafo 2.5.2) alle soluzioni open source, una semplice riformulazione del 2.5.5.

1 Mi Piace
3

Con riferimento alla legge 4/2004, va ricordato alla voce 2.3 (Valutazione comparativa) e alla voce 2.4.2. (Fase 1.2. Individuazione dei vincoli) quanto previsto dalla legge n. 4/2004 all’art. 4 comma 1.

1. Nelle procedure svolte dai soggetti di cui all’articolo 3, comma 1, per l’acquisto di beni e per la fornitura di servizi informatici, i requisiti di accessibilità stabiliti con il decreto di cui all’articolo 11 costituiscono motivo di preferenza a parità di ogni altra condizione nella valutazione dell’offerta tecnica, tenuto conto della destinazione del bene o del servizio. La mancata considerazione dei requisiti di accessibilità o l’eventuale acquisizione di beni o fornitura di servizi non accessibili è adeguatamente motivata.
2 Mi Piace
4

Sempre in relazione ai vincoli (2.4.2), va ricordato che nel caso di richiesta di acquisizione di soluzioni Web based (siti Web, applicazioni Web, applicazioni basate su tecnologie Web) è necessario che nei vincoli contrattuali sia previsto il rispetto dei requisiti tecnici in materia di accessibilità, pena nullità del contratto (art. 4 comma 2 legge 4/2004).

1 Mi Piace
5

Grazie della segnalazione @rscano

Umberto Rosini
Agenzia per l’Italia Digitale

1 Mi Piace
6

In “2.5.2. Fase 2.2: Valutazione soluzioni riusabili per la PA” si legge:

“Per ognuna delle “soluzioni a riuso delle PA” potenzialmente d’interesse si provvede a verificare:
la conformità alle regole sull’interoperabilità prescritte dalla linee guida emanate in attuazione dell’articolo 73 del CAD;
la conformità alle normative sulla protezione dei dati personali;
la conformità ai livelli di minimi sicurezza previsti per le pubbliche amministrazioni”

Visto che si tratta di soluzioni già a Catalogo, non sarebbe più produttivo che tali controlli vengano assolti all’atto dell’inserimento in Catalogo? Si rischia di far ripetere lo stesso lavoro a tutte le PA che intraprendono la valutazione di uno stesso Sw a catalogo…

7

Buongiorno.

  • riguardo il paragrafo 2.5.7 “Fase 2.7 Accertamento impossibilità”:

“Nel caso in cui sia accertata l’impossibilità di individuare una soluzione che soddisfi le esigenze dell’amministrazione tra le “soluzioni a riuso della PA” e le “soluzioni Open Source”, si procede alla redazione di un documento (senza vincoli di forma) che motivi le ragioni dell’accertata impossibilita.”

E’ possibile chiedere che i documenti prodotti per accertare l’impossibilità di soluzioni a riuso della pa e soluzioni open source vengano registrati sul sito Developers Italia in modo da essere indicizzati e presenti in un motore di ricerca presente sul sito?

Si potrebbe utilizzare per questi documenti la stessa metodologia di indicizzazione descritta al paragrafo 5.11 11 “Registrazione del repository su Developers Italia”.

  • riguardo il paragrafo 2.6.3 Fase 3.3: Comparazione soluzioni proprietarie e realizzazione ex novo.

Tra i vantaggi di acquisto di una soluzione proprietaria viene citata la “garanzia totale e rischio applicativo a carico del fornitore”.

Ora, è vero che nel caso di sviluppo di una soluzione ex novo oppure nel caso di utilizzo di una soluzione open source queste non sono dotate “di per se” di una garanzia sul software, ma anche per i software open source esiste la possibilità di stipulare contratti che dietro il pagamento di un canone “scarichino” sui fornitori della PA i rischi applicativi e l’onere di offrire delle garanzie.

Al rigo successivo tra i vantaggi di sviluppare una soluzione ex novo citerei espressamente la garanzia di investire dei soldi provenienti da contribuenti residenti in Italia in attività residenti in Italia, con un ritorno sui posti di lavoro creati e sullo sviluppo di competenze informatiche che un paese industriale come l’Italia deve incentivare.

8

Per quanto riguarda il riuso di soluzioni già presenti in una PA (RIUSO SEMPLICE), ma per vari motivi non inclusi nei repository di Code Hosting del software open source, per le PA che volessero farne riuso devono ancora stipulare una convenzione bilaterale con la PA cedente ? non sarebbe più pratico per la PA cedente fare una sorta di convenzione quadro cui possono aderire le PA interessate ?

9

Per quanto riguarda la modalità di acquisizione come SaaS (Software as a Service), l’imposizione della qualificazione sia del servizio stesso messo a riuso o erogato in tale modalità secondo le linee guida “Criteri per la qualificazione di servizi SaaS per il Cloud della PA” e l’obbligo connesso di essere erogato su un PSN o su Cloud SPC Lotto 1 o su presso Cloud Service Provider Qualificati secondo le linee guida “Criteri per la qualificazione dei Cloud Service Provider per la PA” sembra essere un criterio stringente al punto da limitare o scoraggiare questo tipo di proposte o di collaborazioni tra PA, al netto degli aspetti economici connessi all’erogazione del servizio stipulate tra le parti

10

“Oggetto della valutazione”:

A titolo esemplificativo, rimangono all’esterno del perimetro di questo documento: … progetti di consolidamento e/o virtualizzazione, per i quali i percorsi di scelta della soluzione tecnologica devono riferirsi a metodi e parametri necessariamente diversi da quelli applicati nelle presenti Linee guida.

Questa motivazione di esclusione appare a mio vedere molto generica e qualunque nuova implementazione purchè basata su virtualizzazione di aggirare le linee guida.

13

concordo. Va ribadito (anche per non incorrere in violazione della recependa direttiva UE in materia di accessibilità per siti web e app) che anche per il software e hardware la preferenzialità va verso il prodotto maggiormente accessibile e nel caso il prodotto non lo sia va adeguatamente motivato.

14

@rscano +1 !! ho inserito su github un paio di pull request per l’accessibilità https://github.com/AgID/lg-acquisizione-e-riuso-software-per-pa-docs/pulls :grinning:

15

Par. 2.4.2

  • rispetto al tema ivi accennato della individuazione della disponibilità di bilancio, il tema dovrebbe essere meglio precisato in quanto in questa fase detta disponibilità potrebbe essere indicativa, e meglio potrebbe per essere successivamente rivista a seguito dell’approfondimento sui costi (TCO) risultanti dall’analisi delle diverse soluzioni. Infatti durante la fase di analisi del fabbisogno e dei vincoli non ci sono ancora tutti gli elementi per poter determinare un valore economico corretto, se non di riferimento. Sarebbe altrimenti possibile valutare il valore se si effettuassero stime in FP, ma l’analisi del fabbisogno in questo caso richiederebbe già delle attività di analisi di dettaglio e quindi dei tempi più lunghi (oltre che potrebbe essere persino una analisi eccessiva se poi si ricorresse ad una acquisizione). Inoltre nella disponibilità di bilancio, per calcolare correttamente il TCO dovrebbero essere anche indicate le quote relative agli anni successivi l’acquisizione e la messa in esercizio.

Par. 2.5

  • Il processo suggerisce una analisi prima delle soluzioni a riuso, e solo in seconda battuta in open source. Tuttavia, pur comprendendo che lo scenario in prospettiva è quello di fare riferimento a soluzioni comunque open, solo di diversa titolarità (PA o terzi) è forse utile considerare che ad oggi il riuso potrebbe anche essere rappresentato da realtà non open, acquisibili, per così dire, tramite i canali “tradizionali”; di conseguenza, perché prima il riuso? Sarebbe forse opportuno estendere due ricerche parallele e se risultassero disponibili soluzioni a riuso e open, dovrebbero compararsi.

Par. 2,5,2

  • indicazione dei fornitori a supporto (si segnala qui un concetto che più volte ritorna nel testo): il punto, così come formulato, conserva una certa ambiguità; sarebbe in primo luogo utile distinguere il ruolo di una in house rispetto a quello di un fornitore di mercato; infatti, se la PA riutilizzatrice può appoggiarsi alla PA concedente per personalizzazioni ed avvio, non così automaticamente può affidare al fornitore della PA cedente, ove operatore di mercato; in questo caso, infatti, dovrebbe verificarsi la presenza di effettiva concorrenza (con approvvigionamento secondo criteri codice appalti). Anche in questo contesto, allora e come alternativa in grado di preservare anche un know-how veramente “pubblico”, dovrebbe valutarsi la possibilità di ipotizzare dei poli di competenza nazionali, magari valorizzando proprio quelle società/consorzi in house che dovrebbero avere la capienza e la competenza per fare davvero da maintainer dei progetti; valutare la presenza di un fornitore di mercato sembra quasi indurre, operativamente e nel tempo, la costituzione di un lock in di fatto;

  • rispetto all’invito di indicare, rispetto ad un prodotto pubblicato, numero e tipologia di PA riutilizzatici: sarà opportuno almeno specificare che si indicheranno le PA note che utilizzano il prodotto, o meglio, sarebbe più utile evidenziare eventuali accordi di co-sviluppo e/o iterazioni già in essere con altre PA contribuitici ad una stessa community, affinché si valuti come elemento di valore la possibilità di fare sinergia tra PA e non la mera presenza di un fornitore;

  • sarebbe utile (v. infra commento al par. 3.6) non dare per scontato che tutto quanto messo a riuso sia in open source: infatti sarebbe utile trovare una via di “sanatoria” per quei progetti già pubblicati ma non rilasciabili in OS, che andrebbero forse valutati insieme al nuovo riuso ed all’open source anche in ottica di potenziale evoluzione in senso open;

  • per uniformità di confronto tra valutazioni di software e soluzioni differenti sarebbe utile poter comunque disporre di un template che guidi alla valutazione comparativa in modo oggettivo (simile a quanto faceva la circ. 63 ma con maggiore enfasi sulla documentazione del confronto). Pur nella sua forte analiticità, la circ. 63 forniva elementi di solido riferimento come le tabelle di descrizione dei requisiti (con il livello di dettaglio più opportuno), le tabelle di confronto tra tutte le tipologie di soluzioni analizzate e la valutazione dei criteri art. 68 c. 1-bis del CAD. Per operare una comprensibile semplificazione, in questa versione di linee guida si rischia di perdere il senso di uniformità di valutazione comparativa. Inoltre, sarebbe forse utile chiarire espressamente se in detto processo per fasi l’indagine di mercato su soluzioni proprietarie possa essere condotta solo in caso di mancata rispondenza di soluzioni open source e a riuso, in quanto il processo nel caso potrebbe temporalmente allungarsi rispetto ala possibilità di procedere con indagini condotte “in parallelo”. Se invece si ipotizzasse di raccogliere tutte le informazioni e procedere “solo” alla fase successiva di comparazione vera e propria per fasi, sarebbe forse utile esplicitarlo;
    Par. 2.5.7

  • sarebbe opportuno approfondire – magari proponendo una casistica di riferimento - cosa potrà, ai sensi delle presenti linee guida, intendersi per “accertata impossibilità”; ciò, anche in considerazione del fatto che in base ai criteri di cui alla circolare 63/2013 detta impossibilità era anche “relativa”, ovvero dedotta dalla maggior alta rispondenza ai requisiti di una soluzione, ad esempio, proprietaria. Detta comparazione, tuttavia, non appare più ipotizzabile nel processo articolato per fasi progressive come ad oggi impostato (ovvero: se trovo una soluzione rispondente alle mie esigenze open o a riuso, procedo senza ulteriori indagini). Potrebbe al riguardo essere utile recuperare ad esempio il distinguo con le soluzioni miste, avendo però cura di fornire un criterio di corretta qualificazione (nessuna ipotesi di riuso/OS esclude qualsiasi adattamento, seppur minimo).

Par. 2.6

  • nella valutazione della soluzione di “realizzazione ex-novo” si dovrebbe considerare anche la possibilità di individuare fin dal principio l’interesse di altre amministrazioni a contribuire a partecipare alla spesa ed alla realizzazione del software, così da massimizzare la resa e minimizzare l’effort di ogni singola amministrazione. Fondare già in fase di progettazione una sorta di community ex-ante può essere un vero punto di forza atto a creare software riusabili e efficaci fin dalla progettazione per un più largo numero di PA. Ciò soprattutto in considerazione del fatto che spesso una singola amministrazione non è in grado di sostenere l’onere della realizzazione, oltre che non è neppure in grado di generalizzare i requisiti per l’uso da parte di altre amministrazioni, rischiando quindi sempre di ricadere nello scenario “buy”. Nel caso in cui le soluzioni “make” fossero riusabili da terzi su una PSN in modalità Cloud (SaaS) nel calcolo del TCO si dovrebbero anche considerare i potenziali ritorni economici da parte dell’amministrazione erogante.

Par. 2,6,1

  • l’affermazione secondo cui va effettuata una ricerca di soluzione con licenza d’uso proprietaria “analizzando le offerte secondo quanto indicato dal Codice dei contratti pubblici” meglio potrebbe richiedere una revisione ed un approfondimento. Se infatti ci si colloca in un contesto esplorativo, ci si chiede se il riferimento a vere e proprio “offerte” sia corretto. Inoltre le linee guida potrebbero costituire l’occasione per fornire qualche prezioso criterio di orientamento alle PA su come effettuare dette indagini di mercato, anche in proporzione, ad esempio, alle competenze interne, agli importi in gioco ed all’articolazione del mercato. Infatti, e sempre a titolo di esempio, alcuni strumenti, come l’art. 66 Codice Appalti, potrebbero essere sproporzionati rispetto ad un contesto di importo e/o complessità limitata; inoltre, una indagine relativa alle soluzioni disponibili potrebbe condurre ad individuare soluzioni anche tecnicamente difformi tra loro, o viceversa fornire un panorama molto omogeneo, di fatto in questo senso condizionando anche le modalità di comparazione successiva (infatti, in questo caso e se bene inteso, non si sta selezionando la soluzione ma la modalità di approvvigionamento, che solo incidentalmente potrebbe indicare una unicità di soluzione di mercato). In altri termini, l’occasione andrebbe colta per fornire anche qualche indicazione su come indagare il mercato nel rispetto della concorrenza. Sarebbe opportuno che l’Agid/l’Anac fornissero qualche indicazione in più rispetto alla ricerca delle soluzioni proprietarie, tenendo anche conto di quanto previsto, anche in termini di trasparenza e rispetto della concorrenza, dal Codice dei Contratti Pubblici. Ad esempio, ci si chiede se non possano espressamente prevedersi modalità di ricerca più semplici e meno strutturate (anche dal punto di vista economico) in base al valore dell’applicativo e alla sua diffusione sul mercato (ad esempio, se esistono solo due soluzioni in possesso di determinate caratteristiche e il cui valore è contenuto, la raccolta di informazioni potrebbe essere gestita tramite mere risorse accessibili online, etc…

Par. 2.6.2 e 2.6.3

  • la realizzazione ex-novo solitamente soddisfa appieno tutti i requisiti indicati nella analisi dei fabbisogni. Dovrebbe comunque essere considerata una forchetta tecnico-economica che soddisfi i requisiti minimi e quelli massimi sia per il “make” che per tutte le altre soluzioni che non soddisfano appieno i requisiti,ma che - dopo l’acquisizione - saranno oggetto di personalizzazione ed estensione di tutti i requisiti richiesti. Questo è necessario per permettere il confronto tra soluzioni che soddisfano pari requisiti. Contrariamente sarebbe quasi sempre una comparazione a svantaggio del “make”.
16

Da parte del Centro Hermes per la Trasparenza e Diritti Umani Digitali:

2.5.2 Fase 2:

“SOFTWARE IN RIUSO” vs. “SOFTWARE OPENSOURCE” <— Quando il riuso è basato su “opensource”

Onde evitare che l’approccio del riuso del software possa essere abusato strumentalmente (come è stato fatto per molti anni da software-house per fare marketing di prodotti in sostanziale lock-in con la PA), è necessario che le metriche di misurazione elencate al punto 2.5 siano quanto più oggettive e deterministiche e considerino tutti i casi.

In particolare faccio riferimento a un CASO NON CONSIDERATO DALLE LINEE GUIDA e cioè quando per una determinata soluzione ESISTE SIA UNA SOLUZIONE IN RIUSO SIA UNA SOLUZIONE OPENSOURCE.

Difatti laddove una PA effettui uno sviluppo software “SULLA BASE DI UN OPENSOURCE” e ne effettui un rilascio in riuso, si può determinare una condizione di FORK, ovvero una duplicazione della base di codice sorgente del software.

In una condizione simile il FORK magari contiene minori modifiche di codice ma configurazioni e templates che non sono stati ingegnerizzati per divenire moduli funzionali del software opensource principale, di fatto andando a PERDERE LA MANUTENZIONE EVOLUTIVA E CORRETTIVA COMUNITARIA del software originario. Ciò può inficiare i parametri di sostenbilità per ridotta manutenzione (magari anche di ordini di grandezza inferiore rispetto al software opensource), non diventando un abbandonware ma sostanzialmente perdendo completamente l’integrazione di roadmap del progetto su cui si è basato.

Cioè si pone il concreto rischio che il “SOFTWARE IN RIUSO COSTI DI PIU’ DEL SOFTWARE OPENSOURCE” perché per malizia o imperizia la software-house che ha fatto il lavoro di sviluppo per la PA ha cercato di rendere le modifiche quanto meno compatibili con il software opensource su cui si è basata, così da farne un “sostanziale, ma non formale, lock-in” (quindi aumentare i costi di manutenzione correttiva ed evolutiva, rendere difficile/meno vantaggioso l’uso in-proprio, etc).

A quel punto è necessario che il workflow delle linee guida su acquisizione del software contempli questa condizione in modo oggettivo e procedurale:

QUANDO LA STESSA SOLUZIONE ESISTE’ SIA COME “SOFTWARE IN RIUSO” CHE “SOFTWARE OPENSOURCE” (dove il primo è stato un fork del secondo con alcune modifiche, e magari rimasto indietro di anni di manutenzione evolutiva rispetto al primo) SECONDO QUALI CRITERI UNA PA SCEGLIE?

Questa condizione si determinerà decine se non centinaia di volte e può determinare un uso strumentale da parte di software-house per fare lock-in del processo di software selection su proprie edizioni di software fatte mettere in riuso dalla PA.

La linea guida allo schema 2.5 non prevede questa condizione e non fornisce indicazione su come scegliere.

Riteniamo necessario esplicitare come gestire questa condizione, poiché anche applicando la funzione di TCO, non sarà possibile con i parametri correnti determinare se la “SOLUZIONE IN RIUSO” ha un costo maggiore della “SOLUZIONE OPENSOURCE” per i problemi di scarsa manutenzione applicativa ed evolutiva che portano a una divergenza delle due.

In modo chiaro ed esemplificativo, questa problematica si pone per l’attuale soluzione di Whistleblowing Opensource più usata dalla pubblica amministrazione, il software GlobaLeaks, di cui oggi ci sono già 2 edizioni di software in riuso (fatte da 2 aziende diverse per 2 pa diverse), derivate entrambe da una edizione opensource “principale”.

Le edizioni in riuso sono basate sulla edizione opensource ma:

  • La prima è vecchia di 3 anni rispetto alla edizione opensource
  • La seconda è vecchia di 2.5 anni rispetto alla edizione opensource (vedi analisi riuso globaleaks/anac )

Entrambe le “edizioni in riuso” oltre ad essere basate su codice vecchio e non performante:

  • hanno modifiche minori del codice sorgente rispetto alla edizione da cui sono derivate
  • NON hanno visto la volontà delle aziende (e/o delle PA che hanno acquisito il sw) di integrare le modifiche di codice nel software opensource originario

In questo scenario il “software opensource” ha con se quasi 5 anni di sviluppo uomo in più del “software in riuso” e le aziende che hanno adottato questa tecnica stanno vendendo tantissimo facendo spendere una enormità di soldi alle PA per la loro adozione “in riuso”.

E’ ovvio che in uno scenario del genere il workflow virtuoso di acquisizione di software di cui al punto Punto 2 delle linee, diventerebbe un modo per fare “lock-in” e obbligare le PA a scegliere la “soluzione in riuso” e quindi di fatto entrare in contatto con la PA e le aziende che sono maintainer di questa (ovvero la PA diventa front-facing di promozione commerciale della azienda che ne è effettivo maintainer, e ha l’interesse a tenere separato il prodotto in riuso dal prodotto originale opensource, come canale di marketing).

Nota bene: il TCO, in una situazione come quella su indicata, potrebbe comunque essere più basso nel “breve periodo” acquisendo il software in riuso, ma rappresentare un costo decisamente maggiore nel “medio-lungo periodo” perché il costo di manutenzione correttiva ed evolutiva del “software in riuso” sarebbe sganciato dal “software opensource” .

E’ ovvio, ci rendiamo conto che possa apparire un edge-case, ma ricordiamoci che questo progetto di linee guida andrà a pestare i piedi a centinaia di milioni di fatturato di centinaia di società software che hanno un primario interesse di lucro privato e non di risparmio ed efficentamento della PA.

E’ chiaro che l’Allegato E “Guida alla modifica di software open source preso a riuso o di terzi” fornisce un indirizzo su come dovrebbe essere fatto il riuso in futuro quando basato su opensource terzi, tuttavia l’amministrazione (e il fornitore privato dell’amministrazione) potrebbe comunque, anche seguendo quanto indicato nel “8.4 4. Pubblicazione di codice open source non già a riuso” riuscire a consolidare un proprio FORK con lo scopo di disallineamento (segue commento in apposita sezione su questo punto).
Si veda nel dettaglio nostro contributo alla consultazione su Allegato-E.

E’ necessario quindi esplicitare in modo quanto più oggettivo possibile come gestire questa condizione. che sintetizzo in chiusura ulteriormente:

Quando un “software in riuso” è basato su un “software opensource”, esistono quindi due (o più) edizioni del medesimo software, in quale modo determino se usare il “software opensource” o il “software in riuso”?