[Gfoss] come finanziare i GIS liberi

[Andrea Peri]

>
>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.


-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20120225/40accd85/attachment.html>