Da parte del Centro Hermes per la Trasparenza e Diritti Umani Digitali:
Il calcolo del TCO dovrebbe, per quanto attiene al processo di riuso, identificare dei pesi e delle metriche relative alla manutenzione evolutiva e correttiva, perché la queste rappresentano il costo principale del ciclo di vita del software nel medio periodo.
Ovviamente, ciò va ad impattare direttamente il percorso di scelta definito nel capitolo 2, con particolare considerazione alla differenza fra “Software in Riuso” e “Software Opensource” laddove entrambe le soluzioni sono a codice aperto, ma il secondo potrebbe avere una comunità di contributors di ordini di grandezza superiore al “Software in Riuso” .
Al capitolo 2.5.2 sono identificati i parametri che, nella sostanza, impattano in modo diretto i costi di medio periodo relativi alla manutenzione evolutiva e correttiva:
“Sostenibilità del progetto Open Source attraverso la valutazione di indicatori visibili sul repository Open Source, quali per esempio frequenza delle modifiche (code activity), frequenza dei rilasci (release history), comunità degli utenti (user community), longevità del progetto (longevity).”
Tuttavia questi parametri non sono considerati ed esplicitati nel calcolo del TCO, laddove si debba effettuare una valutazione non già fra “Software proprietario” vs. “Software Opensource” ma fra “Software Opensource” e “Software in Riuso” .
Ipotizziamo che un “Software in Riuso” sia stato basato su “Software OpenSource” e a distanza di un anno ci troviamo con la seguente situazione:
- Software OpenSource: 450 code commit, 250 fork, 12 rilasci con nuove features
- Software in Riuso: 20 code commit, 2 fork, 1 rilascio con minor bugfix
In uno scenario del genere, la scelta del “Software in Riuso”, nella componente e metrica di manutenzione che guarda al medio periodo, in considerazione della scarsa sostenibilità, comporterebbe costi maggiori e sarebbe preferibile la scelta del “Software OpenSource” .
Ovviamente uno scenario simile potrebbe essere frutto di un Maintainer poco attivo o di un Fornitore che opera come Maintainer che adotta questa strategia per ridurre i suoi costi e portare a maggiori richieste commerciali di supporto e assistenza.
Al fine di evitare che ci si possa trovare di fronte a situazioni di “abuso del riuso” per via di un vizio procedurale di scelta preferendo il “Software in Riuso” rispetto al “Software OpenSource” è necessario espandere nell’elemento di valutazione del TCO relativo alla manutenzione le metriche effettive di sostenibilità.