Se l’uso è una-tantum, per un uno specifico e limitato nel tempo,
è probabilmente ragionevole fare una versione specifica (fork) senza
verifiche di qualità, basta
che vada per lo specifico uso per cui è pensata (se poi un anno dopo si
vuole quella
funzionalità più qualcosa di nuovo che è nel software principale… >ciccia)
E chi e’ che finanzia qualcosa che dopo un po’ è invecchiato e inutile ?
Nel software GFoss , come nel software commerciale e’ necessario fare aggiornamenti e manutenzioni al software.
Non parlo di evoluzioni, ma anche di corrzione dei difetti riscontrati.
ArcGIS esce una volta l’anno con un service pack che corregge i naturali problemi che ogni software puo’ avere, quesot service pack contrariamente a quello che si puo’ pensare rappresenta un valore aggiunto, perche’ si sa’ che ogni anno arcgis e’ sempre milgiore perche’ i problemi vengono risolti.
Stesso concetto per il software GFoss.
Anche un software GFoss ogni tanto palesa dei difetti, e come per ArcGIS questi difetti vengono scoperti e risolti con i giusti tempi.
Ma se hai fatto un fork del software chi ti rimette a posto la tua versione per i bachi che non attendono alla tua modifica , ma che erano in tale versione di software gia’ in partenza ?
Per me salvo rarissimi casi molto particolare l’idea che un cliente che commissiona una patch possa accettare che cio’ provochi un fork del prodotto
e’ folle.
Quando uno sente il bisogno di affidarsi a qualcun’altro per farsi sviluppare delle funzionalità allora, secocondo me, chi finanzia non vuole mai che sia fatto un fork.
E’ contro il suo interesse.
Chiunque esso sia, una pubblica amministrazione o un privato.
Per cui non essendo suo interesse finanziare il fork, se il fork nasce per me’ si potrebbe anche pensare che il poveretto che ha pagato il fork
sia stato ingannato.
Dovrebbe esserci una legge che obblighi a firmare una specifica clausola di FORK pena la nullità del contratto.
Qualcosa del tipo:
" Il committente riconosce e accetta che alla fine il lavoro commissionato si tradurrà n un FORK del prodotto principale. "
In assenza di questa clausola in grassetto e opportunamente controfirmata il contratto dovrebbe essere nullo.
Ci vorrebbe davvero una legge in questo senso.
Questa e’ la mia opinione ovviamente, non tutti la pensano così.
Infatti ricordo che qualche anno fa’, mi trovai a discutere con una persona su questioni inerenti il software GFoss .
A un certo punto la discussione entro’ nella questione dei forks.
Io segnalavo l’opportunita che una pubblica amministrazione doveva stare attenta a non incappare nei forks dei prodotti, proprio per evitare di dover ripagare ogni anno la manutenzione
della propria versione di software, ma doveva piuttosto puntare a far entrare le evoluzioni nei cores principali di sviluppo.
La risposta che mi fu’ detta mi spiazzo’ decisamente. Infatti io ritenevo che questo fosse un concetto ovvio e condivisibile facilmente, invece
mi fu’ ribattuto che la PA spendeva già molto nel software commerciale e se avesse anche speso annualmente per la manutenzione di una versione forked non ci sarebbe stato niente di male e andava comunque bene.
Quindi i punti di vista possono essere i più vari.