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”?