come finanziare i GIS liberi

>Il giorno sab, 25/02/2012 alle 21.37 +0100, Andrea Peri ha scritto:
>> 
>> 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. 
>
>Il discorso è interessante. Commissionare una patch una tantum senza che
>questa venga integrata upstream è il vero spreco di risorse. Ma un ente
>può anche avere il personale in grado di mantenere un fork interno.
>

E' vero, infatti nel mio discorso io mi riferivo piuttosto al caso in cui un cliente
non è in grado di effettuare internamente e quindi si rivolge all'esterno.
Ovvio che anche le successive manutenzioni saranno all'esterno, da qui la scelta perdente di accettare un fork.

Essa significa legarsi mani e piedi a chi ti ha fatto il fork e il tuo software comunque invecchierà come funzionalità e efficienza.

Invece, se lo sviluppo è interno, cioè il cliente è in grado di gestirsi autonomamente l'evoluzione,

il fork non è una situazione cosi' penalizzante. Perchè esso non significa legarsi a quacuno esterno.

Questo pero' non vuol dire che le modifiche non debbano essere proposte alla community del prodotto.

Anche se poi non vengono accettate. Non importa, restanoc omuqneu depositate nel sistema di ticket e quindi 
qualcuno ne potrà trarre se vuole ispirazione per qualcosa di altro.

  >E in questo caso secondo me le cose stiano molto diversamente: con gli
>attuali sistemi di controllo versione (git e Mercurial, in sostanza) un
>fork è una cosa normale e quotidiana. E altrettanto normale è il
>rebasing, ovvero riportare le proprie modifiche personali "in cima" alla
>lista delle modifiche al software.
>
>http://book.git-scm.com/4_rebasing.html
>http://mercurial.selenic.com/wiki/RebaseExtension

So' di ditte che ancora usano il CVS e rifiutano perfino l'impiego del SVN.

>È ovvio che questo scenario non "finanzia i GIS liberi", ma al tempo
>stesso è possibile per la libertà stessa concessa dalla licenza.

E' il bello della licenza.
Resta il fatto che chi commissiona all'estenro deve evitare il fork perche' va contro il suo stesso interesse.

come finanziare i GIS liberi

Re: come finanziare i GIS liberi

Re: come finanziare i GIS liberi

Re: come finanziare i GIS liberi

Re: come finanziare i GIS liberi

Re: come finanziare i GIS liberi

Re: come finanziare i GIS liberi