Collegamento:
https://lg-acquisizione-e-riuso-software-per-la-pa.readthedocs.io/it/latest/premessa.html
Contenuto:
1. Premessa
1.1. Finalità e struttura del documento
1.2. Software oggetto di queste linee guida
1.3. Riuso del software
1.4. Soggetti destinatari
1.5. Titolarità
1.6. Conformità del software alla normativa
1.7. Glossario
Nel capitolo 1.6: “…debba risultare conforme alla disciplina vigente.”.
Suggerirei di sostituire “disciplina” con “normativa”.
a me non è chiarissimo cosa si intende riguardo “disciplina vigente”. se si intende alla normativa tout court potrebbe apparire pleonastica (cosa è lecito che non sia conforme alla disciplina vigente ?)
Nel punto 1.2 sarebbe utile aggiungere alla lista anche i sistemi operativi.
Il punto 1.5, per come è espresso, presenta una grave criticità: vieta di fatto l’uso di software libero e di software open source dalla pubblica amministrazione, in quanto non è possibile “l’acquisizione in capo ad essa di tutti i diritti di proprietà intellettuale e industriale”.
Ad esempio nella parte finale della sezione 1.5, nessuna delle diciture proposte sarebbe compatibile con un software GPL o BSD.
La stragrande maggioranza delle licenze open source e tutte le licenze copyleft garantiscono all’utenza (fra cui la pubblica amministrazione) il diritto non esclusivo ad utilizzare, studiare, modificare, ridistribuire (senza vietare né richiedere un compenso).
Tuttavia tale diritto non è mai esclusivo e talvolta presuppone alcune condizioni in carico chi ne usufruisce, come la ridistribuzione dei miglioramenti con la stessa licenza e la disponibilità dei sorgenti a tutti gli utilizzatori del software.
Di conseguenza nessuna diciture proposte al termine della sezione 1.5 sarebbe compatibile con sistemi come Linux, database potentissimi come PostgreSQL o suite per ufficio come LibreOffice, limitando fortemente l’offerta disponibile per la PA ed incrementando di conseguenza i prezzi proposti dai fornitori.
Buongiorno, mi sono posto la stessa domanda sul paragrafo 1.5. :
“Ogni amministrazione deve, in sede di negoziazione di un contratto volto a commissionare lo sviluppo di un software, garantirsi, all’esito dell’esecuzione del contratto, la piena ed esclusiva titolarità di tutti i diritti sul software oggetto di sviluppo, salvo che questo risulti eccessivamente oneroso per comprovate ragioni di carattere tecnico-economico”.
E’ comprensibile che la titolarità del software sia “piena”, ovvero che la pubblica amministrazione abbia tutto il diritto di utilizzare un software senza dipendere da nessuno.
Ma qual è la necessità di avere una titolarità esclusiva su un software che verrà pubblicato con licenza open source?
Mi pongo il problema in particolare per i “framework”, che non sono software “riutilizzabili” in quanto di per se non hanno delle funzionalità per gli utenti finali, ma sono uno strumento per “sviluppare più velocemente del software senza riscrivere la ruota da zero”.
Nel caso in cui la pubblica ammnistrazione commissioni lo sviluppo di un software da realizzare secondo le proprie specifiche, se l’azienda che vince l’appalto usa un framework come Django oppure Laravel ed è richiesto di inserire nel copyright un ringraziamento agli autori originali del framework, significa che la titolarità sui diritti del software non è esclusiva?
Ciao Marco,
colgo l’occasione del tuo commento per rispondere a un dubbio che noto emergere più volte. Il paragrafo 1.5 si applica al “software oggetto di sviluppo”, anche come patch, ovvero ciò che viene sviluppato per conto della Pubblica Amministrazione da un fornitore terzo, NON al software adottato o al software già creato da terze parti indipendentemente dalla commessa della PA.
Mi spiego meglio: il Comune di Bagnacavallo può decidere liberamente di adottare LibreOffice (o un altro prodotto commerciale) per i suoi uffici, anche se, ovviamente, non ne detiene la titolarità. Se però il Comune di Bagnacavallo commissiona a XXX SpA una modifica a LibreOffice, deve assicurarsi che, una volta completata la fornitura, abbia tutti i diritti per rilasciare la patch con licenza aperta, indipendentemente da XXX SpA.
Per fare ciò deve assicurarsi che il copyright di ogni riga di codice sia trasferita a sé, ovvero deve garantirsi la titolarità, per avere i diritti necessari a rilasciare il nuovo codice sotto una licenza aperta. Se questa patch verrà poi integrata nel branch principale, il Comune di Bagnacavallo figurerà tra i contributor a LibreOffice; allo stesso modo altri sviluppatori potranno mandare ulteriori modifiche al comune, esattamente come avviente in un altro progetto open. Tutto ciò senza incidere sulla possibilità di adozione, da parte di Bagnacavallo o altri, del software open.
Ciao,
Riccardo
Al par. 1.5 la frase “, o comunque l’acquisizione della titolarità risulti eccessivamente onerosa (per esempio nei casi in cui la titolarità è acquisibile solo attraverso l’acquisizione dei diritti di software proprietario).” sembra un refuso. si potrebbe cambiare " … o comunque …" con “…salvo che …” come citato più avanti.
L’elenco delle componenti software per quanto non voglia/possa essere esaustiva presenta forse qualche overlap di parole sinonimo tra italiano e in inglese.
Per maggiore leggibilità dato che in una semplice lista le voci non sono raggrupparli, potrebbero essere riordinate alfabeticamente.
“1.3. Riuso del software”: ‘un “valore aggiunto” per il nuovo soggetto utilizzatore.’
Il valore aggiunto da difendersi, è spesso quello degli ‘utilizzatori’ come pluralità.
E’ spesso difficile convincere la pubblica amministrazione che il valore aggiunto non sarà per se stessa, ma per tutti i suoi utilizzatori.
Modificherei in:
“1.3. Riuso del software”: 'un “valore aggiunto” per i suoi utilizzatori.
Nelle linee guida viene fatto ampio uso di richiami RFC come ad esempio per l’uso di parole MUST, SHOULD, MAY.
Lo ritengo utilte e importante richiamo ma suggerirei formalmente l’aggiunta di un paragrafo come il seguente:
Definizioni:
Le parole “DEVE” (in inglese “MUST” e “SHALL”), “NON DEVE” (in inglese “MUST NOT” e “SHALL NOT”), “RICHIESTO” (in inglese “REQUIRED”), “DOVREBBE” (in inglese “SHOULD”), “NON DOVREBBE” (in inglese “SHOULD NOT”), “RACCOMANDATO” (in inglese “RECOMMENDED”), “PUÒ” (in inglese “MAY”) e “OPZIONALE” (in inglese “OPTIONAL”), usate in questo documento, devono essere interpretate secondo le definizioni presenti in RFC2119.
.
Leggo con piacere che l’interpretazione del paragrafo data dagli autori coincida con la mia in particolare e con quella FOSS in generale, ma la frase "
contiene anche la risposta: disambiguizzate il paragrafo 1.5 in modo da escludere una o più interpretazioni ed inserire direttamente quella giusta. Questo può essere fatto in diversi modi, sia descrivendo in termini espliciti “titolarità” nella stessa frase, adottando una nota, etc. In generale non fa un buon effetto in un documento nel primo capitolo, le fondamenta, ci siano punti ambigui: il castello che viene dopo poi ne risente.
Si prongono alcune considerazioni di carattere generale
Rispetto all’impostazione complessiva, potrebbe essere utile considerare anche alcuni spunti, quali:
Par. 1,5
Contributo di Confindustria Digitale alla consultazione sulle Linee Guida Acquisizione e Riuso software per le Pubbliche Amministrazioni
Siamo lieti di presentare le raccomandazioni sviluppate da Confindustria Digitale per la consultazione in oggetto.
Nel redigere tali proposte, siamo partiti dalla convinzione che il processo di acquisizione e riuso del sw pubblico può essere un importante elemento di accelerazione del percorso di modernizzazione in corso in Italia.
Per questo, come federazione delle aziende del settore, abbiamo voluto elaborare delle raccomandazioni che possono facilitare una maggiore sinergia tra pubblico e privato lungo l’intero processo di acquisizione e riuso del sw, nella speranza che dal confronto continuo tra bisogni e capacità possano emergere nuove opportunità di crescita e sviluppo per il nostro Paese.
Per comodità di lettura abbiamo strutturato le nostre raccomandazioni attorno a 10 punti:
1. Individuare gli ambiti ottimali per il riuso
La prima raccomandazione è quella di segmentare la complessità del sw pubblico per identificare gli ambiti ottimali per il riuso. Alcuni servizi istituzionali di tipo critico, infatti, potrebbero richiedere livelli contrattuali di intervento che il modello della community, agendo in modalità best effort, potrebbe non essere in grado di garantire con la necessaria continuità.
Nel caso di sistemi complessi, sarebbe opportuno evitare di ricorrere alla frammentazione come mezzo di riduzione della complessità. In questo caso, infatti, la complessità dal dominio funzionale verrebbe spostata a quello dell’integrazione, realizzando di fatto uno scenario nel quale le singole soluzioni rischierebbero di evolvere in modo non orchestrato, rendendo necessario rivedere ogni volta l’integrazione e la copertura funzionale complessiva.
Per contro, vi sono degli ambiti, come ad esempio quello della conservazione dei documenti, nei quali il riuso potrebbe essere particolarmente utile per stimolare l’adozione di un modello condiviso, facilitando, di fatto, l’integrazione e la trasversalità tra attori diversi.
In generale il ricorso al riuso potrebbe essere utile nelle situazioni caratterizzate da servizi consolidati e maturi (dove il ciclo di innovazione appare sostanzialmente in fase di esaurimento, mentre l’esigenza di interoperabilità è molto più significativa). Nelle situazioni, invece, dove il ciclo di innovazione è all’inizio, potrebbe essere più utile agevolare gli investimenti delle imprese e l’avvio di sperimentazioni per facilitare la creazione di nuovi modelli di servizio e di creazione di valore.
Infine, la segmentazione potrebbe facilitare l’allocazione delle competenze. Attraverso l’identificazione degli ambiti ottimali di riuso, infatti, potrebbe essere più facile reperire, sviluppare ed allocare le competenze e professionalità necessarie per lo svolgimento di progetti di questo tipo.
2. Favorire la co-progettazione
Una seconda raccomandazione riguarda il modo con cui favorire meccanismi di “co-progettazione” che permettano l’interazione e la collaborazione tra pubbliche amministrazioni e sviluppatori sin dalla fase iniziale di definizione delle esigenze (fase di demand).
Potrebbe essere utile, a tale scopo, creare nella community prospettata dalle Linee Guida dei meccanismi di condivisione delle informazioni, supportate da strumenti di correlazione semantica dei fabbisogni, per facilitarne l’uso e amplificarne l’efficacia.
Nel momento in cui una certa amministrazione dovesse avere necessità di un sw, dovrebbe poter:
• Condividere le proprie esigenze (studio preliminare / formalizzazione ad alto livello dei requisiti) con altre amministrazioni che possano ravvisare in esse un grado di copertura tale da indurle a proporsi per un “percorso comune” lungo il flusso definito dalle linee guida (per arrivare a “co-progettare” l’acquisizione, sia essa poi un riuso, una personalizzazione di prodotti esistenti – open source o di mercato - o una decisione “make”)
• Condividere il proprio processo decisionale che la portano a selezionare un sw già presente/segnalato come disponibile al riuso, o la decisione di personalizzare un prodotto open source esistente non ancora presente/segnalato come disponibile al riuso, così come la decisione di personalizzare un prodotto di mercato per poi rendere disponibile tale personalizzazione per il riuso, al fine di aggregare sin dalla nascita più iniziative di riuso concomitanti per evitare eccessivi branch
• Condividere la propria decisione di procedere al “make” e raccogliere eventuali adesioni da parte di altre Amministrazioni impegnate in un processo decisionale analogo e che ravvisino la possibilità di convergere verso gli stessi requisiti (rivedendo eventualmente la progettazione che ha portato alla decisione di “make”, apportando fonti di cofinanziamento, ovvero individuando procedure comuni di acquisizione, ovvero contribuendo a definire i contorni della progettazione esecutiva)
3. Sviluppare in ottica di riuso
Il modello di riuso attuale tende a generare n implementazioni one-of-a-kind di una medesima applicazione. Per evitare tutto ciò, potrebbe essere opportuno fare in modo che, fin dalla fase dello sviluppo, l’applicazione venga “scritta in ottica di riuso”, con un layer di componenti applicative di uso più generale (che verranno esposte come API e che verranno mantenute dalla PA che ha sviluppato l’applicazione) e una serie di componenti specifiche (che saranno mantenute da ogni PA).
Il punto chiave, in altri termini, è quello di favorire una corretta componentizzazione delle applicazioni, per facilitare by design il riuso e la migrazione al Cloud della PA attraverso opportuni meccanismi di facilitazione per le PA interessate a sviluppare in modo modulare e componentizzato.
Se la PA committente è un consorzio o un’aggregazione di più amministrazioni, la scrittura “in ottica di riuso” appare come la strada più naturale e conveniente anche dal punto di vista economico.
Nel caso in cui l’organizzazione committente sia costituita da una singola amministrazione, lo sforzo richiesto per un disegno della soluzione “in ottica di riuso” potrebbe essere facilitato dalla messa a disposizione di opportuni modelli di riferimento e strumenti di supporto (rif. Raccomandazione 10).
4. Migliorare la replicabilità
Come già indicato al punto precedente, il riuso ha spesso generato fenomeni di moltiplicazione dei percorsi di sviluppo ed implementazione separati dalla linea applicativa principale (branch). Per evitare l’eccessiva proliferazione di implementazioni one-of-a-kind, potrebbe essere utile definire modalità di gestione del processo basate su regole più chiare e formalizzate (arrivando a definire delle vere e proprie reference implementation, la cui corretta implementazione dovrebbe essere verificata da un soggetto terzo). Il rischio è che con un processo di riuso poco formalizzato possano accumularsi e propagarsi errori e percorsi implementativi non funzionali al disegno di trasformazione complessivo del digitale pubblico.
Un altro strumento per migliorare la replicabilità potrebbe essere quello di formalizzare in maniera più strutturata le informazioni a corredo delle soluzioni messe a riuso, che le diverse amministrazioni devono predisporre all’atto della loro pubblicazione (par. 3.4 - Processo di messa a riuso del software sotto licenza aperta). Tali informazioni non dovrebbero essere rivolte solo al “developer” ma dovrebbero contenere anche dettagli utili per il “decision maker” di una eventuale ipotesi di riuso, per consentirgli una rapida e completa valutazione (anche alla luce di quanto previsto nel par. 3.4.3). Tali informazioni potrebbero essere organizzate in una check list che definisca le modalità di utilizzo, i costi di governance e le responsabilità sulla manutenzione/evoluzione della soluzione, come, ad esempio:
• Le modalità con cui potrà essere garantita la conformità della soluzione ai requisiti normativi di riferimento (es. GDPR, sicurezza, accessibilità, …)
• La roadmap della soluzione definita e proposta dall’Amministrazione cedente
• Ulteriori elementi che supportino le Amministrazioni nella valutazione della ipotesi di riuso
Un ulteriore strumento per favorire la replicabilità delle soluzioni potrebbe essere quello di prevedere, tra i ruoli previsti nel processo di riuso, anche quello del distributore, che dovrebbe affiancarsi a quello dello sviluppatore e dell’eventuale manutentore di una singola implementazione.
5. Chiarire il tema della Titolarità
Nel par. 1.5 potrebbe essere utile chiarire la relazione tra componenti open source e componenti personalizzate per la PA che dovrebbe seguire modalità analoghe a quelle tra personalizzazioni e software proprietario di mercato. La trasformazione di un software a base open source in un software di proprietà della PA, oltre a modificare in maniera sostanziale il criterio di copyleft, fa venir meno i vantaggi che provengono dal supporto della community. Per questo motivo la Titolarità dovrebbe essere limitata a moduli di integrazione. E anche se il concetto è chiarito implicitamente nel par. 1.7, sarebbe utile chiarire meglio i termini del problema.
Un ulteriore elemento che riteniamo utile evidenziare è che nel par. 1.5 l’affermazione “La mancata acquisizione della titolarità dell’opera non può essere utilizzata per ottenere condizioni economiche più vantaggiose, poiché non costituisce comprovata ragione di carattere tecnico-economico ai sensi dell’articolo 69 comma 2 del CAD” sembra non tenere conto di quanto previsto per gli appalti pre-commerciali. Riteniamo potrebbe essere utile un chiarimento in questo senso.
6. Premiare gli elementi migliorativi
Il par. 2.6 il testo indica che, relativamente alla ricerca di soluzioni proprietarie, l’Amministrazione deve "valutare se la soluzione è disponibile almeno parzialmente in dual-licensing”. Potrebbe essere utile chiarire meglio gli elementi migliorativi da considerare (come, ad esempio, quelle soluzioni nelle quali la parte proprietaria è un on top su base open source e garantisce pienamente la portabilità).
7. Favorire la compliance
Nel caso di riuso di un sw da parte di una PA, le prescrizioni previste dal GDPR (come, ad esempio, la nomina di un Data Protection Officer) e il presidio di tutti gli aspetti di sicurezza collegati alla manutenzione e alla gestione dei dati personali pongono nuovi livelli di complessità sia per chi ha sviluppato il codice sia per chi lo riutilizza, affidandone la personalizzazione e la manutenzione ad un soggetto terzo.
Una soluzione informatica, infatti, non è fatta solo dal codice, ma da tutto il sistema di regole e clausole contrattuali che ne regolano l’acquisizione, la gestione e l’operatività. Sarebbe quindi utile chiarire meglio come, nel caso di riuso, dovranno essere garantiti aspetti chiave come i SLA, la compliance rispetto al GDPR, i tempi di ripristino in caso di malfunzionamento, e le responsabilità per eventuali danni da malfunzionamento e/o da violazioni delle norme sulla riservatezza e protezione dei dati.
In base all’art. 3.4.3 gli Enti che procedono al riuso di una soluzione software non hanno nessuna garanzia sul software da parte della PA cedente.
Sulla base delle considerazioni di cui sopra, riteniamo che, per garantire che il software possa essere messo in esercizio, sia necessario che ogni PA riusante preveda le attività di maintenance sul software preso a riuso, i cui livelli di maintenance saranno identificati attraverso SLA definiti in base agli ambiti di applicazione del software.
E’ consigliabile che vengano definite sin dalla prima stesura del software gli standard di riferimento in merito alla sicurezza applicativa, in modo da favorire gli interventi manutentivi successivi.
Per tale attività di maintenance dovrà esserne effettuata la valutazione economica per la previsione del TCO in fase di selezione del software.
8. Sviluppare le competenze
La valutazione sulla opportunità di adottare un sw in riuso richiede una serie di competenze specifiche (tecniche, legali e contrattuali) per riuscire a valutare correttamente la convenienza del progetto e gestire la sua implementazione nel nuovo contesto applicativo. Essa diviene particolarmente delicata nel caso di applicazioni mission critical, per le quali occorre tenere in considerazioni tutti i fattori di rischio.
Per questo si raccomanda di creare percorsi formativi adeguati con cui sviluppare le competenze e le professionalità interne alla PA necessarie per gestire nella maniera più corretta progetti di riuso.
9. Abilitare l’innovazione del mercato
Sarebbe particolarmente auspicabile favorire un modello di riuso capace di valorizzare il contributo che il sistema delle imprese ICT può offrire in termini di innovazione, eliminazione del lock-in e responsabilizzazione nell’esercizio della soluzione.
Le linee guida pubblicate da AgID individuano tre macro fasi che caratterizzano il processo decisionale per dare seguito alla valutazione comparativa prevista dal CAD:
• Individuazione delle esigenze
• Analisi delle soluzioni a riuso e delle soluzioni open source
• Analisi delle altre soluzioni
Mentre nella prima macrofase, dove l’amministrazione è chiamata a definire le esigenze specificando i bisogni e i vincoli, non può che essere l’amministrazione stessa ad esprimere in modo completo ed esaustivo i requisiti della soluzione da realizzare, nella seconda riteniamo che potrebbe essere opportuno consentire un ruolo più attivo da parte delle imprese.
Il flusso decisionale che rappresenta l’esplosione della seconda macrofase (par. 2.5) prevede attualmente che sia l’amministrazione a effettuare la selezione e la valutazione delle soluzioni riusabili e a prendere la decisione su quale soluzione adottare. Nel caso in cui sia necessario l’approvvigionamento di servizi legati alla evoluzione e all’esercizio della soluzione, l’amministrazione può rivolgersi al mercato correndo però il rischio di venir meno al principio del favor partecipationis se la soluzione scelta non fosse sufficientemente documentata o se l’analisi delle caratteristiche non funzionali e di qualità intrinseca del software (modularità, scalabilità, astrazione), non fosse stata attentamente eseguita in fase di valutazione. In questo caso si rischierebbe una forma di lock-in legata, non tanto all’acquisizione di licenze, quanto, piuttosto, all’esistenza di un insieme molto ristretto di soggetti in grado di operare con efficacia sulla soluzione scelta.
Volendo cercare di trarre comunque il massimo vantaggio dagli investimenti fatti da altre amministrazioni su specifici ambiti applicativi il riuso potrebbe essere un processo aperto alle imprese anche e soprattutto nella fase di scelta della soluzione da riusare. Fermo restando la totale esclusività delle scelte dell’amministrazione in tutti gli step della macrofase 1, nella macrofase 2 l’amministrazione potrebbe limitarsi ad indicare requisiti tecnici di alto livello, e lasciare alle imprese, in sede di proposizione tecnica, la scelta della soluzione a riuso da cui partire.
Tale modalità, oltre a garantire una maggiore apertura del mercato, garantirebbe la piena e totale responsabilizzazione dell’impresa proponente al mantenimento di livelli di servizio essenziali per l’esercizio della soluzione.
10. Facilitare l’accesso ai dati, agli artifact e alle nuove tecnologie
A nostro giudizio, la pratica del riuso dovrebbe, in ultima analisi, favorire lo sviluppo e la diffusione di applicazioni più efficienti e di qualità all’interno della PA italiana.
Il riuso, tra l’altro, non dovrebbe riguardare solo il codice ma anche tutte quelle nuove categorie di artifact che fanno parte del ciclo di vita del software, quali, ad esempio, le descrizioni di un processo o, ancora, i training e i test set di preparazione dei sistemi cognitivi per il machine learning di tipo supervised.
Inoltre possono essere oggetto di riuso anche artifact di gestione di processo (es GDPR) che non si traducono necessariamente in sviluppo di applicazioni o “ricette” di contesti di Software Defined Data Center (ad esempio Hot file di gestione Openstack) o file di configurazione di piattaforma, quali, ad esempio, template di gestione di container.
Per questo, come Confindustria Digitale, riteniamo potrebbe essere particolarmente utile aprire un tavolo di confronto AgID-Team Digitale-Mercato per capire quali potrebbero essere gli elementi fondamentali di un ecosistema di supporto allo sviluppo e al riuso delle applicazioni.
Un sistema di questo tipo, dovrebbe mettere a disposizione dei developer, sia pubblici sia privati, strumenti capaci di favorire la creazione di soluzioni ad elevato tasso di innovazione.
Potrebbe essere interessante, ad esempio, immaginare quali infrastrutture immateriali realizzare per facilitare l’accesso alle nuove tecnologie (dalla blockchain al cognitive), consentire lo sviluppo di applicazioni in modalità devops ed agile, favorire la creazione di architetture a micro-servizi, etc.
I processi di componentizzazione, ad esempio, potrebbero trarre grande beneficio dalla definizione di un modello di riferimento che distingua i servizi di carattere generale da quelli di tipo più specifico e che favorisca un livello di componentizzazione ottimale proprio nell’ottica del riuso.
Conclusioni
Nel loro insieme, le proposte di Confindustria Digitale puntano a creare una maggiore sinergia tra amministrazioni ed imprese lungo tutto il processo di acquisizione e riuso del sw pubblico, dalla individuazione degli ambiti ottimali di applicazione alla definizione delle modalità più efficaci per facilitare l’accesso alle nuove tecnologie.
Un maggiore dialogo tra pubblico e privato può essere particolarmente importante per riuscire a comprendere come prevenire le molteplici forme di lock-in tecnologico che possono manifestarsi lungo l’intera filiera dello sviluppo sw. Perché, ovviamente, il concetto di lock-in non può essere associato solo all’acquisto di sw proprietario ma si manifesta o può manifestarsi per cause molto diverse tra loro: investimenti iniziali, costi di formazione, implementazioni one-of-a-kind di una medesima applicazione sw (nelle quali, evidentemente, sono i servizi a determinare l’infungibilità della soluzione), lock-in determinati dai dati su cui l’applicazione è costruita e che, se non resi disponibili in formato aperto, possono rendere impossibile la mobilità dell’applicazione tra ambienti diversi, etc.
Eliminare il lock-in e garantire il riuso del sw, in questo scenario, richiede una strategia complessiva di azioni e di interventi che, a nostro giudizio, non può che nascere da una collaborazione più stretta tra amministrazioni, imprese e sviluppatori, per comprendere come gestire volta per volta le situazioni più sfidanti e favorire un riuso intelligente e consapevole del sw.
In questo scenario, a nostro giudizio, il concetto di costo della soluzione andrebbe rivisto in una logica più allargata, non riferendolo tanto a meri aspetti di “acquisto e/o di ownersihp” ma parametrandolo di più sugli effetti che l’investimento produce sul contesto. In questo caso, più che parlare di TCO, sarebbe forse utile cominciare a parlare di TCI (Total Cost of Impact), per facilitare l’individuazione di quelle opzioni di infrastrutturazione che producono gli impatti maggiori su un determinato bacino di riferimento.
Su questo come su tutte le proposte descritte in questo documento saremmo lieti, come federazione delle aziende ICT in Italia, di partecipare ad un tavolo di confronto AgID-Team Digitale-Mercato.
Quando è prevista l’edizione finale delle linee guida riuso?