[Gfoss] Finanziare sviluppo di software libero (era: QGis Grass PlugIn 2.0)

[Andrea Peri]

Il paradigma della sarta e' quanto di piu' distante ci sia dal software gfoss.

Perche' proprio perche' fatto da una sarta , sono capi unici, ognuno
differente dall'altro. Soprattutto perche' ognuno tagliato su misura.

Qui si parla invece di un software che dovrebbe essere a comune tra
tutti gli utilizzatori.

Per chiarire meglio:
se io commissiono un abito alla nonna sarta,e quella mi fa' le maniche
corte peche' cosi' tornano meglio a un altro cliente.

Io mica glielo pago.

Pero' la nonna sarta mi dice di passare dal suo laboratorio e con
mezza giornata di lavoro mi rimette a posto per me la mia copia del
vestito.

Ecco che non torna per niente con il software gfoss, dove l'idea di
base non e' che se ci sono 100 utilizzatori ognuno di essi abbia una
versione su misura per lui solamente.

Questo farebbe la gioia degli sviluppatori (cioe' della nonna sarta),
ma non e' il nostro caso.

Il nostro paradigma e' piu' simile a un vestito pret-a-porter.
In cui tutti sono uguali, e il gioco sta proprio nel farli sempre tuttiuguali.

IL problema e':
quando viene rilasciata la nuova versione del vestito, come si fa' a
commissionare una evoluzione , ad esmepio un taschino intenro alla
giacca, se poi si scopre solo alla consegna che ce' il taschino
richiesto, ma il modello e' cambiato e non ci stanno piu' i bottoni,
ma piuttosto una zip ?


A.


Il 31 luglio 2015 19:40, Sandro Santilli <strk a keybit.net> ha scritto:
> On Fri, Jul 31, 2015 at 07:27:18PM +0200, Andrea Peri wrote:
>
>> A fronte di un problema, rappresentato dal barattolo,
>> Il lavoro consiste nel dargli un calcio e spostare il problema piu' in la'.
>>
>> Ovvero si fa' una infrastruttura in grado di fare certi tipi di tests
>> e poi salta fuori che presente l'infrastruttura , mancano i tests, che
>> vanno studiati e sempre tenuti aggiornati, e aggiornare i tests di una
>> struttura di autotesting non è molto facile, e il rischio e' che
>> sostanzialmente da una versione alla successiva di qgis vadano
>> sostanzialmente riscritti.
>
> Questo rischio aumenta la stabilita' del software,
> perche' lo sviluppatore che si vede costretto a riscrivere un test
> che sta fallendo preferisce evitare di cambiare le API facendo si
> che il test continui a funzionare, e tutti sono piu' contenti :)
>
> Ovviamente questo meccanismo funziona soltanto se c'e' una politica
> che impedisce al suddetto sviluppatore di disabilitare il test e
> andare a casa tranquillo ...
>
>> Cosa che poi finrebbe per divenire onerosa essa stessa. Piu' ancora
>> che non mettere in piedi l'infrastruttura stessa di test.
>
> La qualita' ha un costo. Come dice sempre la nonna sarta...
>
> --strk;



-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------