><br>>Se l'uso è una-tantum, per un uno specifico e limitato nel tempo,<br>>è probabilmente ragionevole fare una versione specifica (fork) senza<br>>verifiche di qualità, basta<br>>che vada per lo specifico uso per cui è pensata (se poi un anno dopo si<br>
>vuole quella<br>>funzionalità più qualcosa di nuovo che è nel software principale... >ciccia)<br>><br><br>E chi e' che finanzia qualcosa che dopo un po' è invecchiato e inutile ?<br>Nel software GFoss , come nel software commerciale e' necessario fare aggiornamenti e manutenzioni al software.<br>
<br>Non parlo di evoluzioni, ma anche di corrzione dei difetti riscontrati.<br><br>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.<br>
Stesso concetto per il software GFoss.<br>Anche un software GFoss ogni tanto palesa dei difetti, e come per ArcGIS questi difetti vengono scoperti e risolti con i giusti tempi.<br><br>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 ?<br>
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<br>e' folle.<br><br>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.<br>
E' contro il suo interesse.<br>Chiunque esso sia, una pubblica amministrazione o un privato.<br><br>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 <br>
sia stato ingannato.<br><br>Dovrebbe esserci una legge che obblighi a firmare una specifica clausola di FORK pena la nullità del contratto.<br><br>Qualcosa del tipo:<br><br>" Il committente riconosce e accetta che alla fine il lavoro commissionato si tradurrà n un FORK del prodotto principale. "<br>
<br>In assenza di questa clausola in grassetto e opportunamente controfirmata il contratto dovrebbe essere nullo.<br>Ci vorrebbe davvero una legge in questo senso.<br><br>Questa e' la mia opinione ovviamente, non tutti la pensano così.<br>
<br>Infatti ricordo che qualche anno fa', mi trovai a discutere con una persona su questioni inerenti il software GFoss .<br>A un certo punto la discussione entro' nella questione dei forks.<br>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<br>
della propria versione di software, ma doveva piuttosto puntare a far entrare le evoluzioni nei cores principali di sviluppo.<br><br>La risposta che mi fu' detta mi spiazzo' decisamente. Infatti io ritenevo che questo fosse un concetto ovvio e condivisibile facilmente, invece<br>
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.<br><br>
Quindi i punti di vista possono essere i più vari.<br><br><br>-- <br>-----------------<br>Andrea Peri<br>. . . . . . . . . <br>qwerty àèìòù<br>-----------------<br><br>