QGis Grass PlugIn 2.0
Locked
12
12
 
|
salve,
il grass plugin per QGis 2.0 (che credo "mi sia arrivato" con la 2.10) non ha il pannello browser, che è molto utile. ho letto qualcosa sulla raccolta fondi, ma mi pare sia per il supporto di grass 7. è successo che siamo in mezzo al guado? ovvero il plugin di 2.10 si chiama grass 6, ma contiene solo il codice per grass 7 finora realizzato? leggo qui http://www.gissula.eu/qgis-grass-plugin-crowdfunding/ **: forse ho un po' di casino in testa io, oppure non so come funziona l'ingegneria del software. ma togliere una cosa che funziona, ed aspettare che venga rifinanziata per rimetterla, a casa mia si chiama in un certo modo. scusate la franchezza. qualcuno per cortesia mi può spiegare, grazie. devo ritornare alla 2.8? oppure posso avere la 2.10 ma il vecchio plugin? marco ** Package 2: Browser Partial cumulative target €2300, delivery in QGIS 2.10 The current implementation of the plugin has its own implementation of a browser which allows to browse and manage data in active mapset. The browser in the plugin duplicates the standard QGIS browser widget but it offers more functions. The standard QGIS browser widget and items representing GRASS mapsets and layers will be extended to support what is now available in the plugin browser. It means that it will allow to display layer's metadata, copy, rename and delete layers. Completely new feature will be the possibility to import raster and vector data to a GRASS mapset using drag and drop in the QGIS browser widget. It should greatly simplify data import and moderate GRASS learning curve. The browser from the plugin will be removed. This will be implemented for both GRASS 6 and 7. -- Marco Guiducci <[hidden email]> Firenze, via di Novoli 26 055 4383194 _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
|
|
On Fri, Jul 31, 2015 at 11:42:24AM +0200, Marco Guiducci wrote:
> forse ho un po' di casino in testa io, oppure non so come funziona l'ingegneria del software. > ma togliere una cosa che funziona, ed aspettare che venga rifinanziata > per rimetterla, a casa mia si chiama in un certo modo. scusate la > franchezza. Una nota nel merito: stiamo parlando di software libero. Tra le liberta' a cui si fa riferimento c'e' quella di usare e distribuire il software che si e' acquisito. Non e' possibile _togliere_ qualcosa ad un software che si e' acquisito. Non che non capisca il problema di cui parli, lo capisco molto bene, ma e' importante mettere i puntini sulle "i". Nessuno ha tolto nulla a nessun altro. Il software funzionante esiste ancora, e' ancora distribuibile, modificabile e ri-distribuibile da chiunque. > qualcuno per cortesia mi può spiegare, grazie. > devo ritornare alla 2.8? oppure posso avere la 2.10 ma il vecchio plugin? Una cosa positiva' e' che la 2.8 e' ancora mantenuta. Siamo arrivati alla versione 2.8.3, anche se non e' stata annunciata in pompa magna, ed e' un grosso passo avanti. Mio consiglio: torna alla versione 2.8 per la produzione, segnala i problemi sul tracker pubblico affinche' si risolvano entro la prossima long-term-release, chiedi all'ente in cui lavori di distribuire la versione stabile in modo da non dipendere unicamente dalla distribuzione ufficiale del software. --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
|
|
On Fri, Jul 31, 2015 at 11:59:33AM +0200, Sandro Santilli wrote:
> Mio consiglio: torna alla versione 2.8 per la produzione, segnala i > problemi sul tracker pubblico affinche' si risolvano entro la prossima > long-term-release Visto che ci ho perso un po' di tempo, segnalo la pagina in cui si trovano l'agenda dei rilasci (non completamente tradotta): http://qgis.org/it/site/getinvolved/development#release-schedule E la politica di rilascio: http://qgis.org/it/site/getinvolved/development#road-map Calcolatrice alla mano, pare che la prosisma LTR sara' la 2.14 e dovrebbe uscire a febbraio 2016. --strk; _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
|
|
In reply to this post by Marco Guiducci-3
Il browser è stato integrato in quello principale.
Saluti. Il 31 luglio 2015 12:42:24 EEST, Marco Guiducci <[hidden email]> ha scritto: salve, -- Paolo Cavallini http://www.faunalia.eu _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
|
|
In reply to this post by Sandro Santilli
Ciao strk.
Intanto ti segnalo che per qualche motivo che mi sfugge quando faccio reply a tuoi messaggi la tua email non mi compare mai e devo agiungerla a mano. Venendo al tuo discorso. Ce un dettaglio che non mi torna nel tuo ragionamento e vorrei charirmelo. Te dici: >Non che non capisca il problema di cui parli, lo capisco molto bene, >ma e' importante mettere i puntini sulle "i". Nessuno ha tolto nulla >a nessun altro. Il software funzionante esiste ancora, e' ancora >distribuibile, modificabile e ri-distribuibile da chiunque. Facciamo un esmepio concreto. Noi abbiamo commissionato una evoluzione su qgis a una ditta di cui non cito il nome per non fare pubblicita'. Questa evoluzione ci e' stato detto che e' OBBLIGATORIO che sia fatta su la qgis-dev e quindi entrera' in un prossimo rilascio di QGIS. Non entrera' nella 2.8.x Su questosiamo tutti daccordo. Pero' te dici che io sono libero di usare la 2.8.x e nessuno m cambiera'nulla sudi essa. Ma se io io finanzio una evoluzione e la volgio sulla 2.8 perche' la conosco e so' che mi va bene. Te mi dici che non e' posssibile e previsto.E' prvisto per la versione successiva. Che peor' io ancora non conosco e quindi non so' se mi andra' bene. Magari poi quando viene rilasciata scopro che gli manca un plugin che a me serviva. E allora come la si mette ? In soldoni , mi pare che l'unica soluzione sia non finanziare piu' nessuna evoluzione perche' finisce sempre in una versione di qgis ignota a priori e quindi a rischio di non essermi utile. Come nel caso citato da Marco. Non so' se e' chiaro l'incongruenza della situazione. Da una parte si dice che se uno vuole certezze deve usare quella stabile. Dall'altra si dice che se uno vuole evoluzioni deve finanziare una versione che a quesot punto e' ignota, e magari assieme alla evoluzione finanziata ci trova anche alcune sorprese per cui cio' che gli serviva poi non ci sta piu'. Fino ad oggi si pensava che la versione successiva di qgis avrebbe sicuramente avuto tutto cio' che vi era nelle verisoni precedenti. Ora si dice che se uno si spostaa alla versione successiva , se qualcosa non torna l'unica cosa certa che puo' fare e' finanziare la rimessa a posto oppure usare quella passata. Dove guarda caso cio' che si e' finanxiato come evoluzione non e' presente. A me non torna molto questa cosa. Quindi , passo successivo: te dici di finanziare un professionista che si occupi di verificare se e' sabile. Ma questo professinista, fino a che non e' rilasciata non credoche potrebbe dirmi si va bene o no non va bene. E allora come si fa' a finanzare evoluzion su una versione che nessuno ancora conosce ? A. Il 31 luglio 2015 11:59, Sandro Santilli <[hidden email]> ha scritto: > On Fri, Jul 31, 2015 at 11:42:24AM +0200, Marco Guiducci wrote: > >> forse ho un po' di casino in testa io, oppure non so come funziona l'ingegneria del software. >> ma togliere una cosa che funziona, ed aspettare che venga rifinanziata >> per rimetterla, a casa mia si chiama in un certo modo. scusate la >> franchezza. > > Una nota nel merito: stiamo parlando di software libero. > Tra le liberta' a cui si fa riferimento c'e' quella di usare e > distribuire il software che si e' acquisito. > Non e' possibile _togliere_ qualcosa ad un software che si e' > acquisito. > > Non che non capisca il problema di cui parli, lo capisco molto bene, > ma e' importante mettere i puntini sulle "i". Nessuno ha tolto nulla > a nessun altro. Il software funzionante esiste ancora, e' ancora > distribuibile, modificabile e ri-distribuibile da chiunque. > >> qualcuno per cortesia mi può spiegare, grazie. >> devo ritornare alla 2.8? oppure posso avere la 2.10 ma il vecchio plugin? > > Una cosa positiva' e' che la 2.8 e' ancora mantenuta. > Siamo arrivati alla versione 2.8.3, anche se non e' stata annunciata > in pompa magna, ed e' un grosso passo avanti. > > Mio consiglio: torna alla versione 2.8 per la produzione, segnala i > problemi sul tracker pubblico affinche' si risolvano entro la prossima > long-term-release, chiedi all'ente in cui lavori di distribuire la > versione stabile in modo da non dipendere unicamente dalla distribuzione > ufficiale del software. > > --strk; > > () Free GIS & Flash consultant/developer > /\ http://strk.keybit.net/services.html > _______________________________________________ > [hidden email] > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > Questa e' una lista di discussione pubblica aperta a tutti. > I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. > 750 iscritti al 18.3.2015 -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
Finanziare sviluppo di software libero (era: QGis Grass PlugIn 2.0)
|
|
On Fri, Jul 31, 2015 at 06:35:54PM +0200, Andrea Peri wrote:
> Intanto ti segnalo che per qualche motivo che mi sfugge quando faccio > reply a tuoi messaggi la tua email non mi compare mai e devo > agiungerla a mano. Succede solo coi miei o anche con quelli degli altri ? > Te dici: > > >Non che non capisca il problema di cui parli, lo capisco molto bene, > >ma e' importante mettere i puntini sulle "i". Nessuno ha tolto nulla > >a nessun altro. Il software funzionante esiste ancora, e' ancora > >distribuibile, modificabile e ri-distribuibile da chiunque. > > Facciamo un esmepio concreto. > > Noi abbiamo commissionato una evoluzione su qgis a una ditta di cui > non cito il nome per non fare pubblicita'. > > Questa evoluzione ci e' stato detto che e' OBBLIGATORIO che sia fatta > su la qgis-dev e quindi entrera' in un prossimo rilascio di QGIS. > Non entrera' nella 2.8.x > > Su questosiamo tutti daccordo. Bene. Non vogliamo destabilizzare la release stabile... > Pero' te dici che io sono libero di usare la 2.8.x e nessuno m > cambiera' nulla sudi essa. Quella e' l'intenzione del branch stabile. > Ma se io io finanzio una evoluzione e la volgio sulla 2.8 perche' la > conosco e so' che mi va bene. > Te mi dici che non e' posssibile e previsto.E' prvisto per la versione > successiva. > Che peor' io ancora non conosco e quindi non so' se mi andra' bene. > Magari poi quando viene rilasciata scopro che gli manca un plugin che > a me serviva. > > E allora come la si mette ? Io non ho detto che non e' possibile. Assieme all'ultima versione 2.8.x hai ricevuto una licenza di modifica e distribuzione del codice. Hai tutto il diritto di modificare quella versione e pure di distribuirla con le modifiche che vuoi. Ovviamente non credo tu voglia mantenere un fork, ed e' quindi conveniente per te che la nuova funzionalita' sia anche inclusa nella prossima release "ufficiale". Ma nessuno ti vieta di includerla _anche_ in un fork diciamo "temporaneo" del codice. > te dici di finanziare un professionista che si occupi di verificare se > e' sabile. > Ma questo professinista, fino a che non e' rilasciata non credoche > potrebbe dirmi si va bene o no non va bene. Il codice e' disponibile _durante_ lo sviluppo, non solo al momento del rilascio. Io compilo qgis periodicamente (a volte giornalmente) e mi accorgo subito se (ad esempio) smette di compilare sul mio sistema. Come me, molti altri sviluppatori fanno lo stesso. Inoltre, ci sono ora "robot" che lo fanno ad ogni commit, e riportano lo stato su una (o piu') pagine web. I robot non solo provano la possibilita' di compilare, ma lanciano anche tutti i test attualmente disponibili e verificano che funzionino tutti. Se la funzionalita' che si e' persa e' passata inosservata, evidentemente non aveva un test associato. Il professionista potrebbe occuparsi, tra le altre cose, di aumentare la copertura dei test automatici, partendo magari da quelli per le funzionalita' care al proprio cliente. --strk; _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
Re: Finanziare sviluppo di software libero (era: QGis Grass PlugIn 2.0)
|
|
solo con i tuoi.
Vengo al tuo discorso. Io non credo che un sistema del genere possa realmente funzionare su un sistema come qgis. me pare il classico "calcio al barattolo" in termini informatici. 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. . Cosa che poi finrebbe per divenire onerosa essa stessa. Piu' ancora che non mettere in piedi l'infrastruttura stessa di test. Del resto , e' nota in informatica, la legge del 20/80. Ove mediamente il 20% del costo complessivo e' il costo di sviluppo e l' 80% e' il costo di debug. Per cui questa parte dei test potenzialmente potrebbe arrivare al' 80% del costo complessivo. In questo caso i tests sono anche piu' complessi perche' molto spesso rivolti a verificare la parte della GUI, ovvero l'interfaccia grafica. A. Il 31 luglio 2015 18:55, Sandro Santilli <[hidden email]> ha scritto: > On Fri, Jul 31, 2015 at 06:35:54PM +0200, Andrea Peri wrote: > >> Intanto ti segnalo che per qualche motivo che mi sfugge quando faccio >> reply a tuoi messaggi la tua email non mi compare mai e devo >> agiungerla a mano. > > Succede solo coi miei o anche con quelli degli altri ? > >> Te dici: >> >> >Non che non capisca il problema di cui parli, lo capisco molto bene, >> >ma e' importante mettere i puntini sulle "i". Nessuno ha tolto nulla >> >a nessun altro. Il software funzionante esiste ancora, e' ancora >> >distribuibile, modificabile e ri-distribuibile da chiunque. >> >> Facciamo un esmepio concreto. >> >> Noi abbiamo commissionato una evoluzione su qgis a una ditta di cui >> non cito il nome per non fare pubblicita'. >> >> Questa evoluzione ci e' stato detto che e' OBBLIGATORIO che sia fatta >> su la qgis-dev e quindi entrera' in un prossimo rilascio di QGIS. >> Non entrera' nella 2.8.x >> >> Su questosiamo tutti daccordo. > > Bene. Non vogliamo destabilizzare la release stabile... > >> Pero' te dici che io sono libero di usare la 2.8.x e nessuno m >> cambiera' nulla sudi essa. > > Quella e' l'intenzione del branch stabile. > >> Ma se io io finanzio una evoluzione e la volgio sulla 2.8 perche' la >> conosco e so' che mi va bene. >> Te mi dici che non e' posssibile e previsto.E' prvisto per la versione >> successiva. >> Che peor' io ancora non conosco e quindi non so' se mi andra' bene. >> Magari poi quando viene rilasciata scopro che gli manca un plugin che >> a me serviva. >> >> E allora come la si mette ? > > Io non ho detto che non e' possibile. > Assieme all'ultima versione 2.8.x hai ricevuto una licenza di modifica > e distribuzione del codice. Hai tutto il diritto di modificare quella > versione e pure di distribuirla con le modifiche che vuoi. > > Ovviamente non credo tu voglia mantenere un fork, ed e' quindi > conveniente per te che la nuova funzionalita' sia anche inclusa nella > prossima release "ufficiale". Ma nessuno ti vieta di includerla > _anche_ in un fork diciamo "temporaneo" del codice. > >> te dici di finanziare un professionista che si occupi di verificare se >> e' sabile. >> Ma questo professinista, fino a che non e' rilasciata non credoche >> potrebbe dirmi si va bene o no non va bene. > > Il codice e' disponibile _durante_ lo sviluppo, non solo al momento > del rilascio. Io compilo qgis periodicamente (a volte giornalmente) > e mi accorgo subito se (ad esempio) smette di compilare sul mio > sistema. Come me, molti altri sviluppatori fanno lo stesso. > > Inoltre, ci sono ora "robot" che lo fanno ad ogni commit, e riportano > lo stato su una (o piu') pagine web. I robot non solo provano la > possibilita' di compilare, ma lanciano anche tutti i test attualmente > disponibili e verificano che funzionino tutti. > > Se la funzionalita' che si e' persa e' passata inosservata, > evidentemente non aveva un test associato. > > Il professionista potrebbe occuparsi, tra le altre cose, di aumentare > la copertura dei test automatici, partendo magari da quelli per le > funzionalita' care al proprio cliente. > > --strk; -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
Re: Finanziare sviluppo di software libero (era: QGis Grass PlugIn 2.0)
|
|
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; _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
Re: Finanziare sviluppo di software libero (era: QGis Grass PlugIn 2.0)
|
|
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 <[hidden email]> 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 àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
Re: Finanziare sviluppo di software libero (era: QGis Grass PlugIn 2.0)
|
|
In reply to this post by Sandro Santilli
On Fri, 31 Jul 2015 18:55:27 +0200
Sandro Santilli <[hidden email]> wrote: > Io non ho detto che non e' possibile. > Assieme all'ultima versione 2.8.x hai ricevuto una licenza di modifica > e distribuzione del codice. Hai tutto il diritto di modificare quella > versione e pure di distribuirla con le modifiche che vuoi. certo, ma noi siamo utilizzatori, io sono per formazione cartografo. il mio tempo lo dedico anche ad aggiornarmi sulle nuove procedure di produzione, ma non fino al punto di compilarmi software o stare dietro ai log dei bug e così via. da qui, come si diceva, dell'esigenza di un terzo che esegua questa funzione. e, di nuovo, il software libero è sul mercato e ne segue le stesse logiche: crea il bisogno e soddisfa il bisogno. (il dumping, voluto o non voluto, è dietro le porte e qualcuno potrebbe certo approfittarne, confidando del fatto che l'utlizzatore finale in alcuni casi potrebbe non avere tutti i mezzi necessari per essere autonomo). in definitiva: non CI (notare il ci che ci accumuna, appunto) dovremmo sentire tanto diversi da chi, in maniera palese, ci fa business, cioè le software house. a volte ho colto questo atteggiamento "superiore". diciamo semplicemente che è un'altro modo di far girare i soldi. -- Marco Guiducci <[hidden email]> Firenze, via di Novoli 26 055 4383194 _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
Re: Finanziare sviluppo di software libero (era: QGis Grass PlugIn 2.0)
|
|
Il giorno 31 luglio 2015 21:09, Marco Guiducci <[hidden email]> ha scritto: On Fri, 31 Jul 2015 18:55:27 +0200 Ciao, Discussione un po' difficile da seguire, sicuramente utile per capire il punto di vista dell'utilizzatore finale e capisco la frustrazione che in alcuni casi può coglierci, ma questa affermazione (conclusione?) mi pare decisamente riduttiva e non la condivido. Io (come molti altri che lavorano nel/col software libero), "business" ce lo faccio (o almeno, ci provo :) ) , in maniera palesissima: ho una ditta, sono iscritto alla camera di commercio, sono sul MEPA con prodotti e servizi basati su sw libero, partecipo a gare e bandi ed emetto regolare fattura se riesco a prendere un lavoro. Quindi dove sta la differenza tra me/noi ditte e quelle che vendono prodotti e servizi basati su software proprietario? È solo un altro modo di far girare i soldi? Si: è un altro modo di far girare i soldi (o perlomeno un timido tentativo di farlo), ma non è **solo** questo! Davvero dobbiamo spiegarlo un'altra volta? -- Alessandro Pasotti
w3: www.itopen.it _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
|
|
Penso (e spero) sia chiaro a tutti che il sw libero, come ogni altro sw, non nasce spontaneamente come l'erba medica. E' ovvio che ci sia dietro un modello di business per sostenerne sviluppo, manutenzione, diffusione, ecc. Detto ciò, questo non toglie nulla agli assiomi del mercato, tra cui la responsabilità di accontentare l'utente prima di tutto. A volte percepisco un certo arroccamento da parte della comunità degli sviluppatori/manutentori nel cercare di motivare agli utenti i limiti che si possono incontrare, giustificandoli con argomentazioni che all'utente, giustamente, possono non interessare. Allora, se emerge da più parti (come nel caso della questione LTR) che forse si potrebbe cercare di migliorare ulteriormente l'approccio, forse si potrebbero valutare alternative e nuove strategie, più che motivare la situazione con uno stato de facto tecnico, e rendendo all'utente l'onere di arrangiarsi. giovanni Il giorno 31 luglio 2015 21:09, Marco Guiducci <[hidden email]> ha scritto: On Fri, 31 Jul 2015 18:55:27 +0200 Ciao, Discussione un po' difficile da seguire, sicuramente utile per capire il punto di vista dell'utilizzatore finale e capisco la frustrazione che in alcuni casi può coglierci, ma questa affermazione (conclusione?) mi pare decisamente riduttiva e non la condivido. Io (come molti altri che lavorano nel/col software libero), "business" ce lo faccio (o almeno, ci provo :) ) , in maniera palesissima: ho una ditta, sono iscritto alla camera di commercio, sono sul MEPA con prodotti e servizi basati su sw libero, partecipo a gare e bandi ed emetto regolare fattura se riesco a prendere un lavoro. Quindi dove sta la differenza tra me/noi ditte e quelle che vendono prodotti e servizi basati su software proprietario? È solo un altro modo di far girare i soldi? Si: è un altro modo di far girare i soldi (o perlomeno un timido tentativo di farlo), ma non è **solo** questo! Davvero dobbiamo spiegarlo un'altra volta? -- Alessandro Pasotti
w3: www.itopen.it _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
|
|
In reply to this post by Andrea Peri
Andrea, mi spieghi perchè è obbligatorio sia fatta sulla dev? Cioè, non potete prendere il codice della 2.8 e farvi l'evoluzione in casa? Mi sono perso.. Ciao Luca _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
|
|
E' nelle regole stabilito dal chi controlla e dirige losviluppo di qgis.
Una verisone rilasciata stabile (ad oggi la 2.10) diviene congelata e non ci si puo' fare sopra piu' niente. Recentemente hanno aperto alla ipotesi di farci sopra delle patch di manutenzione, ma niente nuove evoluzioni. Ogni nuova evoluzione che vuole entrare nel qgis ufficiale (qcioe' quello scaricabile da www.qgis.org) deve obbligaotiramente andare su QGIS-DEV. Poi, e' anche vero cio' che die strk, cioe' che se uno vuole si puo' scaricare la qgis 2.8 e andare amodificarsela, ma pero' diviene una cosa differente, non sarebbe piu' parte del mondo qgis conscuto. Faremmo prima a chiamarla "Qualcosaltro-GIS" e farla scaricare da n altro sito internet. Perche' non sarebbe mai accettata su qgis ufficiale. Il quale accetta nuove evoluzioni solo sulla QGIS-dev. Ma inserire evoluzioni in una verisone propria di qgis, sarebbe fare un fork e nessuno riuscira' mai a convincermi che sia una cosa buona. Per me fare una cosa del genere equivarrebbe a buttare via soldi. A tali condizioni moto meglio spenderli in softwares commerciali. Infatti se evolvessimo una nostra versione specifica di qgis sganciata da quello del repository ufficiale ci metterebbe alla fine nella situazione di avere un prodotto qgis-like che comunque sarebbe invecchiato, ma non per questo piu' stabile. Inoltre avremmo perso tutte le evoluzioni che altri contestualmente a noi avrebbero finanziato su qgis. Insomma, se ognuno si facesse il proprio fork personale e evolve solamente il suo, assisteremmo esattamente a un proliferare di tanti qgis che piano piano prenderebbero ad avere nuovi e differenti nomi. Con una base di partenza comunque che per' piano piano si diversificherebbero , e probabilmente resterebbero estrememanete scadenti sotto il profilo della stabilita' e della affidabilita'. Perche' per essere stabili i softwares devono essere testati e usati QGIS viene usato da decine di migliaia di persone nel mondo. Un qgis interno di un ente come RT avrebbe avuto al massimo 100 utilizatori e probabilmente prima che un baco venisse profilato passerebbero anni. Poi chi sarebbe stato in grado di risolverlo e'una altra storia (probabilmente nessuno). E qui non ce consulente o esperto che tenga. Un conto e' avere un softwareprovato da centinaia di migliaia di utenti e un conto e avere 2-3 persone che lo usano e che cercano di capire se ha qualche baco oppure no. Ma anche senza considerare l'aspetto del debug dei bachi, sarebbe comunque una pratica controproducente. Ti faccio un esempio: noi finanziammo il rendering con regole mi pare ai tempi della 1.4 o 1.6 . E puntammo fortemente che fosse committato nel dev di qgis. Questo ha fatto si' che ora te sul qgis che usi hai il rendering con regole. Se lo avessimo inserito in una nostra verisone interna senza farlo mettere sulla dev ufficiale di qgis, oggi la tua versione di qgis probaiblmente non avrebbe il rendering a regola a meno che qualcun'altro non avesse pagato nuovamente un programmatore per riprendere quel codice e riportarlo in qgis Ma chi lo avrebbe pagato ? Non certo noi che lo avevamo gia' pagato per averlo su una verisone nostra specifica. Non penso nemmeno te. Probaiblmente nesusno lo avrebbe pagato perche' nessuno avrebbe neanche saputo che esisteva, perche' chi si sarebbe mai scaricato la versione diqgis di RT per installarsela e provarla ? Nessuno a parte gli utenti di RT (forse). Quindi, noi avremmo fatto un nostro qgis inchiodto alla versione 1.8 e su di esso avremmo nell'arco del tempo immesso varie evoluzioni. Pero' nel frattempo , su qgis ufficiale sarebbero arrivate altre evoluzioni fatte da altri soggetti (francia, svizzera, australia, etc...) , che noi di RT non avremmo avuto nella nostra versione specifica, e che noi avremmo dovuto pagare per far riportare nella nostra. Quindi ri-pagare per avere quanto altri hanno gia' pagato per fare. Ma ti pare plausibile ? E nel contempo altri non avrebbero potuto avere se non pagando essi stessi cio' che noi abbiamo gia' finaiziato nella nostra versione specifica. Il 1 agosto 2015 15:11, Luca Mandolesi <[hidden email]> ha scritto: > Andrea, mi spieghi perchè è obbligatorio sia fatta sulla dev? Cioè, non > potete prendere il codice della 2.8 e farvi l'evoluzione in casa? Mi sono > perso.. > > Ciao > Luca -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
|
|
Salve a tutti,
Andrea Peri ha scritto: > Ma inserire evoluzioni in una verisone propria di qgis, sarebbe fare un fork e nessuno riuscira' mai a convincermi che sia una cosa buona. Per me fare una cosa del genere equivarrebbe a buttare via soldi. A tali condizioni moto meglio spenderli in softwares commerciali. Concordo pienamento al 100% :-) E' risaputo che ci sono esempi di successo relativi a fork di software molto noti. Tra i casi piu' lampanti c'e' certamente quello di LibreOffice che sta avendo uno sviluppo [1] *molto* maggiore di OpenOffice, da cui deriva [2] . Nel caso di LibreOffice questo e' dovuto pero' sopratutto al cospicuo numero di sostenitori del progetto (Red Hat, Canonical, Collabora, Google con i Google Summer of Code etc). Il Comune di Monaco di Baviera, per esempio, ne ha appena finanziato una nuova funzionalita' [3]. Peraltro tutte le principali distribuzioni Linux lo installano di default da tempo al posto di OpenOffice. Per OpenOffice, come grossa azienda finanziatrice, mi pare di capire che sia rimasta "solo" IBM. Secondo me, e' fondamentale utilizzare i sempre piu' limitati soldi pubblici in attivita' che diano il massimo "profitto" per la collettivita'. Come evidenziato da Andrea Peri, spesso i fork del progetto principale (in questo caso io mi riferisco a Qgis) non danno sempre grandi benefici nel lungo periodo. In Italia in particolare, poi i fork del progetto (Qgis) potrebbero presentare il rischio aggiuntivo che possano alimenatare piccole clientele locali... :-( Per Qgis la "soluzione" piu' banale mi pare essere quella di favorire il finanziamento del progetto stesso perche' gli sviluppatori abbiano i fondi per migliorare le diverse versioni: stabile 2.8.x e di sviluppo 2.10. Ovviamente questa mia constatazione sembrera' ai piu' la classica "scoperta della acqua calda"... :-) Tuttavia, per il massimo vantaggio per la collettivita' in termini di utlizzo di fondi pubblici, oggi sempre piu' scarsi, penso che sia la soluzione piu' *lungimirante*. Cordiali saluti (e buone vacanze a tutti) ! Silvio Grosso [1] https://wiki.documentfoundation.org/ReleaseNotes/5.0 [2] http://www.nouenoff.nl/downloads/LibreOffice_AOO_CompetitiveFeatureMatrix_20150318.pdf [3] http://vmiklos.hu/blog/mail-merge-embedding.html |
|
|
Però Andrea scusami, il presupposto che hai messo tu è che non vuoi, come me, rischiare di avere una versione nuova di QGis evoluta, ma magari ti vanno a carte 48 gli stili. Quindi io come ditta farei così: 1 - Prendo Qgis 2.8 interno alla mia ditta perchè mi garba quello è stabile ecc. e pago un programmatore per farmi il pezzo in più e uso solo la 2.8 da qui a 5 anni (nella mia ditta andiamo avanti con la 2.4 ancora e nessuno ha problemi) 2 - Rilascio il pezzo evoluto e la qgis.org lo può prendere e finanziare l'inserimento nella dev. 3 - A questo punto io avrei la mia stabilità interna a Qgis 2.8 e magari un giorno ci sarà pure nella dev. Ora quello che io non capisco per limiti miei come programmatore è se si parla di "aggiungere" una parte nuova, come un plugin e quindi reinseribile in maniera "semplice" oppure si tratta di mettere mano a tante linee di codice in qua e in là per adattare le nuove funzioni? _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
|
|
Andrea si riferisce al core. Regione Toscana ha finanziato, e continua a farlo, diverse migliorie che entrano nel core. Finanziarne lo sviluppo su versioni non dev sarebbe poco sensato e lungimirante. giovanni Il 02/ago/2015 12:04, "Luca Mandolesi" <[hidden email]> ha scritto:
_______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
|
|
Ma allora come si esce dal paradosso che mette in evidenza Andrea: come si fa ad investire su una dev che non sai se funzionerà per come ti serve e non ti manderà a carte 48 i vecchi lavori? _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
|
|
In reply to this post by mando
NOn il tuo modello e' sbagliato.
Il 02/08/2015 12:04, Luca Mandolesi ha
scritto:
Mettimao che domani a te serve una funzionalit'a core che qgi non fa' e che a te serve perche' altrimenti non porti a termine un lavoro importante. Te finanzi l'evoluzione sulla tua vecchissima 2.4. Ma a te chi ti dice che il programmatore per far l'evoluzione che te gli hai commissionato non intervenga pesantemente sul codice apportando modifiche che rendono a lui molto semplice lo sviluppo, ma renda il qgis forked molto differente rispetto a quello originale ? Un conto e' apportare una patch per risolvere un bachettino, un altro e' aggiungere una cosa che manca. Metti che domani ti serve il 3D e lo devi finanziare da zero. Mettereil 3D su qgis non è uno scehrzo. Te prendi metti sulpiatto 40.000 euro e lo fai fare alla tua 2.4 da una ditta. La modifica va in profondita', devono aggiungere librerie nuove, modificare comportamenti, fare modifiche all a semantica dei files di progetto di qgis, magari cambiano nche la struttura delle finestre di interfaccia. Te demandi qtutte queste scelte alla tua ditta selezionata. Lei ovviamente opera in autonomia, e' il tuo unico interlocutore, le decisioni le prende lei. Questo portera' sicuramente a un codice molto differente rispetto a quello originale di qgis. >2 - Rilascio il pezzo evoluto e la qgis.org lo può prendere e finanziare l'inserimento nella dev. Si, in teoria potrebbe, ma non e' obbligata a farlo. E se per farlo deve pagare e trovare qualcun che finanzia cio' capisci bene che finisce che si paga due volte il medesimo lavoro.... Se va bene. Ma in realta' non andrebbe come pensi te. In realta' quello che succedera' e' che nessuno si prendera' la briga di dare una occhiata al codice di qgis-forked perche' sara' molto probabilmente completamente differente, magari non si compilera piu' nemmeno con i medesimi compilatori, e forse richiederebbe anche nuove librerie non previste dal qgis originale. A quel punto se la qgis.org volesse fargli una occhiata dovrebbe pagare qualcuno per dargli una occhiata e il responso sarebbe molto probabilmente del tipo: il codice e' molto differente e non e' chiaro se vale la pena recuperarlo. Se si vuole quella funzionalit'a conviene rifarla daccapo. A questo punto la cmmunity te pensi che finanzierebbe il 3D ? Ma manco ci pensa. Perche' chi ne aveva interesse cioe' te, ha gia' finanziato lo sviluppo sul suo qgis 2.4 forked e quindi perche' dovrebbe pagarlo di nuovo ? A questo punto che fine fa' qis ? Diventerebbe una sorta di universo di tante versioni ognna con qualcosa in piu' e qualcosa in meno e nessuno che ha interesse e forza per rimettere tutto insieme. chi ha avuto il vantaggio ? Ti racconto un caso realmente avvenuto: circa3 o 4 anni fa' , quando qgis era gia' passato alla versione 2.0, ci fu' una universita' straniera che contatto' la community di qgis, perche' avevano tempo addietro preso un qgis credo fosse la 1.8 e avevano di loro inizitiva su di esso effettuato tutta una serie di modifiche per evolverlo portandoci dentro nuove fnzionalita' di elaborazione , mi pare nel settore idraulico. E ora volevano rilasciare tutto Gfoss e ci tenevano che venisse recepito nel nuovo qgis. Tutta roba bellissima e molto interessante. Ma la risposta della community di qgis fu' assolutamente negativa. Era logico. Gli davano sostanzilmente un qgis 1.8 da doversi ristudiare daccapo per prelevare cio' che era stat fatto e cambiato. E ri-implementarlo su un qgis 2.0 Grazie tante, ma tenetevelo, e' roba sviluppata su una vecchia versione di qgis e non è possibile portarla all'ultima versione. Poi, ovviamente se ce' chi paga magari profumatamente, tutto si fa'. Questo fu' il responso. Logico. E ora credo che chi si vuole usare quel bellissimo codice idraulico se lo deve usare su un vecchioqgis 1.8 scaricabile da quella universit'a straniera. E pure in una lingua straniera, anche il manuale. Non mi ricordo quale fosse, forse era ungherese ? :) A. _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
|
|
In reply to this post by mando
Il modello di sviluppo di qgis e' tarato per venire incontro alle
esigenze dei developers. Ma non prende in considerazione i problemi eventuali degli stakeholders. Su qgis insistono varie tipologie di stakeholders. Ma tra di essi la PA e' uno stakeholder complicato. Perche' , a differenza, di un privato (una ditta o un libero professionista) opera su dei vincoli ben precisi. Delle norme a cui deve rigorosamente attenersi. Non entro nel discorso se siano giuste o sbagliate (comunper me sono sono giuste comunque). Ci sono e tanto basta. Non si possono ignorare. Il 2 agosto 2015 14:10, Luca Mandolesi <[hidden email]> ha scritto: > Ma allora come si esce dal paradosso che mette in evidenza Andrea: come si > fa ad investire su una dev che non sai se funzionerà per come ti serve e non > ti manderà a carte 48 i vecchi lavori? > > _______________________________________________ > [hidden email] > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > Questa e' una lista di discussione pubblica aperta a tutti. > I messaggi di questa lista non hanno relazione diretta con le posizioni > dell'Associazione GFOSS.it. > 750 iscritti al 18.3.2015 -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |