QGis Grass PlugIn 2.0

[Andrea Peri]

scusate, mi e' partita la email per errore.
Stavo cercando di impostare un discorso complicato e mi e' partita la
email per errore quando non avevo nemmeno terminato la premessa.


Il 2 agosto 2015 17:29, Andrea Peri <[hidden email]> ha scritto:

> 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 àèìòù
> -----------------

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

[Andrea Peri]

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 (comunque per me sono
sono giuste). Ci sono e tanto basta. Non si possono ignorare.

QGIS tenta di proporre un modello unificato per i vari stakeholder:

-"chiedi cio' che ti serve, discutiamone in lista, mettiamoci daccordo su come va fatta, la funzionalita' che finanzi ci sara' nella prossima versione rilasciata"-

La prima cosa che a me salta agli occhi e' il problema procedurale che questo approccio fa nascere.
Esso presuppone di poter discutere fin dal principio con chi sviluppa o quanto meno con un soggetto che abbia ben chiaro cio' che serve, ma anche che sia in grado di interloquire sul livello di dettaglio necessario per poter tarare tecnicamente l'intervento da compiersi.
Il soggetto che si interfaccia con la community o con il gruppo decisionale per perorare la causa della evoluzione che si vuole compiere non puo' che essere colui che alla fine fara' il lavoro. Perche' quasi mai (ma potrei dire mai) chi finanzia ha un livello tecnico sufficiente per discutere di certi dettagli tecnici implementativi.

E' vero che questo non è un problema per uno stakeholder privato, che usualmente separa in due momenti distinti la fase di valutazione del lavoro dalla fase di implementazione vera e propria.
Egli infatti puo' commissionare a un developer il lavoro di studio del problema, costui effettua una indagine, valuta le varie problematiche e poi formula una ipotesi. Poi a fronte della relazione ricevuta dal developer, lo stakeholder privato potra' scegliere di estende al medesimo developer l'incarico dandogli il nulla osta al lavoro, oppure stoppandolo se ritiene che la soluzione proposta non sia accettabile per il suo fabbisogno o troppo costosa, o altri motivi.

E' invece un problema per uno stakeholder pubblico, il quale ha difficolta' a operare con queste modalita'.
Non che non si possa in assoluto, ma sicapisce bene che se si da' un incarico a un developer di studiare un problema, non si puo' poi dargli un nuovo incarico per l'implementazione del lavoro stesso.
L'incarico deve essere unico e complessivo. Per cui, non è opportuno separare in due fasi distinte.
Senza contare che la separazione in due fasi potrebbe portare ad avere soggetti differenti, esponendo anche al rischio che il secondo soggetto (quello implementatore) rimetta in discussione quando preparato dal primo soggetto progettista (chiamiamolo "progettista" per semplicita').

Questo e' il primo grosso problema che incontra una PA nell'approcciare uno sviluppo su QGIS.
Questo problema pero' e' comune a tutti i softwares Gfoss, ed e' la ragione per cui spesso si assiste alla nascita di forks di prodotto. Perche' non potendo separare facilmente la progettazione dallo sviluppo, e dovendo assegnare tutto a priori, finisce che chi ha l'incarico tende a fare un fork del prodotto.

Per parecchie ditte infatti la formulazione dell'offerta non contempla una interazione preventiva con la community , che viene invece vista come facente parte gia' della fase lavorativa.
Ovvero, prima di prende il lavoro e poi si interloquisce con la community.

Quando l'approccio e' questo, la conseguenza e' un fork , oppure una crescita dei costi (a posteriori).
Non si puo' infatti escludere che l'interazione con la community possa portare a una revisione di cio' che si prevedeva di fare.

Infatti in sede di offerta lo sviluppatore che opera secondo il modello classico tende sempre a identificare una strada di esecuzione del lavoro basandosi sul capitolato del committente, che ovviamente non puo' scendere cosi' in dettaglio, e cerchera' sempre la strada piu' agile e rapida per lo svolgimento del lavoro (quello che citavo nella altra email , dicendo che cerca sempre la strada piu' facile e rapida)  e su di essa formula il prezzo su cui viene poi dato l'incarico. Poi , dopo aver avuto l'incarico e iniziato a lavorare , interagendo con la community, si sente dire che deve seguire altre strade, piu' complicate e non previste. Conseguenza: I costi cambiano, aumentano. Il problema si sposta subito sul piano commerciale sottoponendo la scelta al suo committente. Le soluzioni proposte a quel punto sono le solite ovvie:
accettazione di un fork. Cioe' una versione fatta nei modi originariamente previsti e che mai sara' accettata dalla community di QGIS.
Oppure, una revisione dei prezzi, che sicuramente non sara' piccola.

Questo tipo di problema oggi in qualche modo, si riesce a superare.
Si riesce a superare perche' stanno nascendo un numero di ditte che hanno gia' in mente un approccio operativo specifico per il software gfoss. Ovvero hanno gia' al loro interno personale in grado di sviluppare su determinati prodotti gfoss con modalita' consone allo specifico prodotto.

Per semplificare tutto il discorso:
non basta saper programmare in C e compilare un qgis dai sorgenti.
Ma occorre che abbiano un flusso di lavoro che preveda gia' una interoperazione con una community.

Se la ditta lavora a scatola chiusa questo non succede e porta a problemi che sfociano in un fork o in una revisione di prezzi.

La modalit'a classica a scatola chiusa:
Formulano una offerta basandosi sul capitolato tecnico. Ottengono il lavoro, svolgono il lavoro, consegnano, riscuotono. Il tutto svolto nei prorpi uffici , con il propriopersonale, nessun'altro estenro al gruppo dilavoro che metta bocca sulle decisioni salvo il committente che ovviamente non ha le competenze per interloquire su determinate scelte. Approccio a scatola chiusa.

Ora ci sono nuove forme di ditte, con un modello commerciale rivolto al mondo OpenSource, non solo nel senso di lavorare su sorgenti di altri, ma anche perche' sono conscie che tutto cio' che fanno deve avere l'imprimatur di altri soggetti esterni non coinvolti formalmente nell'affido (la community).

Una community che partecipa gioco forza alle scelte e a determinare le medesime.

Una community che pero' non puo' essere coinvolta durante la fase lavorativa, ma bensi' prima, gia' durante la fase di formazione dell'offerta.

Quindi il primo problema, si sta naturalmente risolvendo.
Ma qui nasce poi il secondo problema:
Ovvero, la community stessa, la quale e' essa stessa una entita che oserei definire "liquida" e variabile.

Il risultato di questa liquidita' e' che cambia spesso opinione, dimentica cio'che e' stato fatto, si focalizza troppo su l'oggi e sottovaluta la visione strategica di un prodotto.

Questo porta al paradigma del prodotto che oggi ha i "bottoni" e domani "la zip".
E' il cosidetto approccio "bazar" che cita spesso Santilli assieme al suo approccio alternativo "a cattedrale".

A parer mio l'approccio "bazar" che e' il piu' pratico , perche' e' rapido e riesce a raccogliere spesso a coagulare attorno a se visioni differenti (il bazar appunto), e' anche quello che meno di confa' a un prodotto che punti ad avere come stakeholder una pubblica amministrazione.

L'approccio bazar , alla lunga finisce per far nascere anche lui i forks , perche' costringendo gli stakeholders a difendrsi dalla inevitabilita'del rischio del cambio "bottone <-> zip" li spinge a ricercare la sicurezza nella tranquilla oasi di un fork "istituzionale".

Poi vi e' l'approccio "cattedrale" , il quale "potrebbe" salvare invece la visione strategica del prodotto, perche' tenderebbe a far nascere un gruppo di decisori che coordinano le azioni.
Ma non e' sufficiente di per se che ci siano dei decisori.Intanto perche' questi decisori devono svolgere un ruolo che a volte e' difficile da svolgere. Ovvero quello di stoppare o negare (che e' poi la parte difficile del lavoro di arbitro) determinate azioni. Poi, essi sarebbero il classico collo di bottiglia, perche' dovendo passare da loro le decisioni, la fila sarebbe lunga, e non potrebbe piu' essere una attivita' hobbistica.
Poi, come non bastasse, occorre che essi stessi abbiano chiaro la visione strategica che si vuole dare al prodotto.

Mi spiego con un esempio di fantasia:
oggi , qgis e' aperto a ogni forma di contributo.
Se domani uno volesse implementare dentro qgis un calcolatore in rpn (stile HP per chiarire) finalizzato a fare calcoli algebrici , se fosse disposto a finanziarlo probabilmente troverebbe una porta aperta.
Gi basterebbe far notare che nelle calcolatrici in RPN si pigiano meno tasti (si risparmia il tasto = da pigiare) magari troverebbe anche il plauso della community (liquida appunto) e dal giorno dopo qgis agirebbe con un calculator in RPN.
A mio modo di vedere qui non centra l'approccio bazar o l'approccio cattedrale, centra la visione strategica di un prodotto.
Cosa deve fare e come lo deve fare cosa ci sta bene dentro di esso e cosa non ci sta' bene.

Come si risolve questo aspetto ?
Come si evita che oggi ci siano i bottoni e domani ci sia la zip ?
Che oggi si operi in notazione algebrica usuale e domani in polacca inversa (rpn) ?

E' questo il problema.

Come avere una visione strategica comune.
Certamente serve passare da un gruppo che coordini, ma non puo' bastare.

E' questa la sfida difficile che deve risolvere QGIS e il gruppo che intorno a qgis si sta coagulando.

Qui riprendo un discorso gia' avviato qualche tempo fa'.
Leggoche si sta formando (te stesso la hai citata nella tua replica) un gruppo qgis-users che abbia il copito di prendere le decsioni.
Questa e' una buona cosa, perche' va a contrastare l'egemonia dell'approccio bazar,
ma pero' si sta dicendo anche che nel gruppo decisionale i primari attori a prendere le decisioni debbano essere i developers.

Potra' questo garantire che domani non ci sia la zip al posto dei bottoni ?

Io non lo so', ma non credo.

E' questa la sfida difficile a cui qgis verra' chiamato nei prossimi anni.
Una evoluzione nel suo modello che preservi l'aspetto gfoss, mantenga la liberta' di chiunque di poter partecipare allo sviluppo di qgis (parlo di nuovi developers che volessero accedere a questo mercato), evitando la formazione di una nicchia di privilegiati. e preservare le evoluzioni gia' recepite nel prodotto.
Il gruppo dovra' essere capace di comprendere e proteggere gli aspetti di qgis che rappresentano elementi strategici rilevati (i bottoni) e salvarli dalle evoluzioni rovinose (la zip).

Questa evoluzione ha certamente dei costi vivi.
Non fosse altro per garantire a determinati soggetti di poterci lavorare sopra a tempo pieno.
Ma chi deve finanziare questo ?

Qui si arriva alla parte difficile.

A parer mio e' difficile che si possa chiedere a degli stakeholder pubblici di farsi carico di queste risorse economiche. Le norme che regolano l'uso dei fondi pubblici non credo che rendano facile questo impiego.

Forse soluzioni di crowd-funding potrebbero parzialmente risolvere il problema. Una altra parziale soluzione potrebbe arrivare dalla iscrizione annuale al qgis-users.
Ma tutte queste soluzioni terrebbero fuori lo stake-holder pubblico.
Che certamente non po' partecipare a u crowd-funding , ne puo' iscriversi a un qgis-users (che io sappia).

Pero' ci potrebbero pensare soluzioni piu' pragmatiche.

Ad esempio:
Ipotizzare un contributo da applicarsi al recepiento di una evoluzione che per la sua complessita' e stesura avesse richiesto in un moment precedente il coinvolgimento del gruppo guida di qgis nel determinare come impostarla e indirizzare le scelte in una certa direzione.

Questo contributo potrebbe essere codificato e facilmente conteggiato in una offerta economica formulata dalla ditta che valuta i costi per realizzare una evoluzione.

Certo occorrerebbe che non sia troppo esoso. Pero' ipotizzare che chi richiede il commit di codice sul repository di prodotto debba pagare un contributo (es: 500 euro).
E dare al gruppo guida il diritto di esonerare da questo pagamento persone meritevoli.

In maniera da esentare chi fornisce una patch a titolo di lavoro volontaristico, e costringere a questo pagamento chi invece ha sviluppato la patch per conto terzi ricavandone un profitto.

Potrebbe essere un esempio di soluzione per ricavare fondi per finanziare il lavoro di chi sviluppa patch, ma anche di un gruppo che collaborando con le ditte che sviluppano per conto terzi preservi il qgis dalle "zip".

My2ct.

A.

Il 02/08/2015 14:10, Luca Mandolesi 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

_______________________________________________
[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

[Silvio Grosso]

Salve Andrea,

Innanzitutto, grazie mille davvero per gli spunti molto interessanti e dettagliati, del tuo ultimo messaggio, su cui riflettere !

Andrea Peri ha scritto:
> Mi spiego con un esempio di fantasia:
oggi , qgis e' aperto a ogni forma di contributo.
Se domani uno volesse implementare dentro qgis un calcolatore in rpn
(stile HP per chiarire) finalizzato a fare calcoli algebrici , se fosse
disposto a finanziarlo probabilmente troverebbe una porta aperta.

Su questo punto, se mi permetti una battuta, da clima vacanziero estivo, come utente finale "privato" di Qgis vorrei aggiungere che io, personalmente, sono ben contento di ricevere una funzionalita' in piu'.
Ovviamente, purche' essa sia testata e *non* introduca instabilita' nel software.
Mal che vada, se non mi serve, evitero' semplicemente di utilizzarla... :-)

Scherzi a parte, ovviamente anche nel software commerciale vengono spesso rilasciati degli applicativi con molte funzionalita' che ai piu' sono "superflue".
All'inizio degli anni 2000, ricordo di aver letto un sondaggio della stessa Microsoft dove veniva evidenziato che gli utenti di Office utilizzavano mediamente solo il 20% delle opzioni disponibili per Excel.
Uno dei motivi, oltre a quelli prettamente commerciali, per cui e' stata rilasciata la versione 2007 di Office con l'interfaccia completamente modificata, la cosidetta "Ribbon" [1], era proprio quello di facilitare gli utenti a trovare meglio le opzioni supplementari.

Secondo me, tuttavia, nel software commerciale, avviene in genere l'opposto.  
Si cerca cioe' di spezzettare il software principale in piu' rilasci temporali successivi in modo da obbligare l'utente ad aggiornare sempre l'applicativo, con i conseguenti esborsi economici.
Oppure, altro giochetto classico, si fanno pagare come pacchetti supplementari delle opzioni indispensabili all'utente finale...
In entrambi i casi e' un po' l'opposto del rischio evidenziato per Qgis (il cosidetto calcoltare in rpn stile HP) :-)

Seguo da anni la mailing list internazionale degli sviluppatori di Qgis e penso sinceramente che, nel complesso, stiano lavorando nella giusta direzione...
Alcune nuove funzionalita' proposte sono state respinte perche' giudicate controproducenti per il progetto.
Non ho le competenze tecniche per entrare nel merito della decisione pero' posso citare per esempio la "bocciatura" recente di una proposta per migliorare la visualizzazione dei raster in Qgis [2]

Mi sembra anche di poter aggiungere che si stanno cercano di risolvere anche i problemi di stabilita' del software (bugs) e di regressioni [3].
L'instabilita' di Qgis e' stata giustamente un aspetto molto criticato in passato su questa stessa lista.
Peraltro la versione stabile 2.8.x ha proprio questo scopo.

Semmai il problema, come evidenziato da Andrea, e' quello di conciliare le esigenze delle pubbliche amministrazioni italiane con lo sviluppo di Qgis.
E' chiaro che con i procedimenti italiani, spesso macchinosi, e soprattutto con la carenza cronica di fondi e' tutto molto piu' *complicato* attualmente.
A livello italiano, il rischio maggiore, per me rimane comunque sopratutto quello di cercare di evitare lo sviluppo di fork del progetto principale (con qualche Regione che magari si crea la "propria" versione di Qgis...).
Questo per non sprecare sul lungo periodo le poche risorse economiche oggi disponibili.

Cordiali saluti

Silvio Grosso

[1] https://it.wikipedia.org/wiki/Ribbon
[2] https://lists.osgeo.org/pipermail/qgis-developer/2015-July/038609.html
[3] http://blog.vitu.ch/10102014-1046/crowdfunding-initiative-automated-testing

[pcav]

Il 02/08/2015 14:14, aperi2007 ha scritto:

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

Ciao.
Hai un riferimento alla vicenda?
Grazie.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.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]

Purtroppo no.
E' sicuramente roba che sta nella ML user o developer, ma e come
trovare un ago in due pagliaia . Anche con il supporto di nabble.

Comunque e' poco rilevande, in fin dei conti.
E'storia vecchia. Cio' che conta e' il principio.
Ovvero se uno va per la sua strada con un suo fork , poi e' scontato
che cio' che ha fatto prima o poi andra' perso.

Non e' detto che se lo metti nel repo ufficiale non vada perso
ugualmente. Pero' in questo caso e' una probabilita', nel primo e' una
certezza suffragata dal concetto stesso di fork del prodotto.

A.


Il 3 agosto 2015 12:44, Paolo Cavallini <[hidden email]> ha scritto:

> Il 02/08/2015 14:14, aperi2007 ha scritto:
>
>> 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 ?
>
> Ciao.
> Hai un riferimento alla vicenda?
> Grazie.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.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

[girarsi_liste]

Il 03/08/2015 14:56, Andrea Peri ha scritto:

> Purtroppo no.
> E' sicuramente roba che sta nella ML user o developer, ma e come
> trovare un ago in due pagliaia . Anche con il supporto di nabble.
>
> Comunque e' poco rilevande, in fin dei conti.
> E'storia vecchia. Cio' che conta e' il principio.
> Ovvero se uno va per la sua strada con un suo fork , poi e' scontato
> che cio' che ha fatto prima o poi andra' perso.
>
> Non e' detto che se lo metti nel repo ufficiale non vada perso
> ugualmente. Pero' in questo caso e' una probabilita', nel primo e' una
> certezza suffragata dal concetto stesso di fork del prodotto.
>
> A.
>

Non vedo perchè un fork una volta abbandonato, se ha una licenza
compatibile con Qgis, ed ha qualche funzionalità o miglioria importante,
non possa essere ripreso in Qgis o nei suoi plugin.

--
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|


_______________________________________________
[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

[giohappy]

Non vedo perchè un fork una volta abbandonato, se ha una licenza
compatibile con Qgis, ed ha qualche funzionalità o miglioria importante,
non possa essere ripreso in Qgis o nei suoi plugin.

Pereché magari nel frattempo QGIS è andato avanti, è cambiato il suo core, le API, ecc. ecc.

Riprendere quel che è stato aggiunto ad una vecchia versione e rintegrarlo in quella nuova è un lavoro dispendioso e, con molta probabilità, richiederebbe la riscrittura di parte delle aggiunte fatte sulla vecchia versione per adattarle alla nuova.

E' un approccio da evitare come il veleno!

 

--
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|

_______________________________________________
[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

[Sandro Santilli]

On Sun, Aug 02, 2015 at 09:08:51PM +0200, aperi2007 wrote:

> QGIS tenta di proporre un modello unificato per i vari stakeholder:
>
> -"chiedi cio' che ti serve, discutiamone in lista, mettiamoci
> daccordo su come va fatta, la funzionalita' che finanzi ci sara'
> nella prossima versione rilasciata"-

[...]

> E' invece un problema per uno stakeholder pubblico, il quale ha
> difficolta' a operare con queste modalita'.
> Non che non si possa in assoluto, ma sicapisce bene che se si da' un
> incarico a un developer di studiare un problema, non si puo' poi
> dargli un nuovo incarico per l'implementazione del lavoro stesso.

Scusa ma io questo non lo capisco. Non "si capisce bene", almeno io
non lo capisco bene. Perche' un ente pubblico non puo' dare un
incarico per la sola analisi e progettazione ? Non e' proprio la
pianificazione una delle fasi piu' importanti in qualunque progetto ?

> Per semplificare tutto il discorso:
> non basta saper programmare in C e compilare un qgis dai sorgenti.
> Ma occorre che abbiano un flusso di lavoro che preveda gia' una
> interoperazione con una community.

Esatto. Cambia proprio l'approccio.
Perche' si interviene su un bene condiviso.

> Ma qui nasce poi il secondo problema:
> Ovvero, la community stessa, la quale e' essa stessa una entita che
> oserei definire "liquida" e variabile.
>
> Il risultato di questa liquidita' e' che cambia spesso opinione,
> dimentica cio'che e' stato fatto, si focalizza troppo su l'oggi e
> sottovaluta la visione strategica di un prodotto.

Questa mi sembra una generalizzazione, e bisognerebbe portare
esempi specifici e concreti per capire meglio di cosa parli.

La modalita' aperta dello sviluppo rende davvero difficile
"dimenticare" qualcosa di quel che e' stato fatto.

Per quanto riguarda la visione strategica, entra in gioco la capacita'
del proponente di convincere i maintainer della validita' di un approccio.
Mi viene in mente il caso di Pierre Racine con i PostGIS Raster.
Non solo Pierre non era nel PSC, ma non era neanche uno sviluppatore.
Da utilizzatore ha lavorato su un piano strategico cosi' dettagliato
e convincente da far digerire perfino a Paul Ramsey l'idea di
supportare i raster nel db (lui ne era notoriamente contrario).
Va da se che se Pierre non si fosse anche occupato di trovare i fondi
per finanziarne lo sviluppo difficilmente la cosa sarebbe andata
avanti (nel senso che non basta convincere a parole, ma bisogna pure
offrire la nuova funzionalita' ...)

> L'approccio bazar , alla lunga finisce per far nascere anche lui i
> forks , perche' costringendo gli stakeholders a difendrsi dalla
> inevitabilita'del rischio del cambio "bottone <-> zip" li spinge a
> ricercare la sicurezza nella tranquilla oasi di un fork
> "istituzionale".

A me sembra un problema generale legato ai cambiamenti.
Non e' specifico del software libero, ma ben presente anche con quello
proprietario. Nel software libero semmai e' attenuato proprio perche'
avendo il diritto legale di distribuire il software non si pone mai il
problema di non trovare piu' disponibile una versione vecchia di un
programma (avendo l'accortezza di tenerne copia).

Se poi parliamo di "funzionalita' scomparse" e' un altro paio di
maniche, e rinnovo il mio invito a segnalare tali casi come bug.

> Come si evita che oggi ci siano i bottoni e domani ci sia la zip ?
> Che oggi si operi in notazione algebrica usuale e domani in polacca
> inversa (rpn) ?

La mia impressione e' che con il software libero se oggi c'e' la zip
domani ci puo' essere sia la zip che i bottoni (a scelta dell'utente).

La cosa da evitare e' che venga meno la zip se qualcuno la usa.
Ma dovra' chi la usa occuparsi di "difenderla" in qualche modo.
Dal conservare la vecchia versione (ultima spiaggia, ma sempre valida)
al far sentire la propria voce nel caso si proponesse di rimuoverla
o quando ci si accorga che e' sparita (se avviene vuol dire che non si
sta avendo cura dei propri strumenti come si dovrebbe).

> Come avere una visione strategica comune.

Partecipando alle liste di discussione.

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

tra i punti.

Il 03/08/2015 17:18, Sandro Santilli ha scritto:

>
> E' invece un problema per uno stakeholder pubblico, il quale ha
> difficolta' a operare con queste modalita'.
> Non che non si possa in assoluto, ma sicapisce bene che se si da' un
> incarico a un developer di studiare un problema, non si puo' poi
> dargli un nuovo incarico per l'implementazione del lavoro stesso.
> Scusa ma io questo non lo capisco. Non "si capisce bene", almeno io
> non lo capisco bene. Perche' un ente pubblico non puo' dare un
> incarico per la sola analisi e progettazione ? Non e' proprio la
> pianificazione una delle fasi piu' importanti in qualunque progetto ?

Certo, ma il problema e' la sequenzializzazione in due incarichi
distinti e differenti, alla medesima persona.
Il primo per progettare e il secondo per realizzare.
Potrebbe essere inteso come "frazionamento".

>> Ma qui nasce poi il secondo problema:
>> Ovvero, la community stessa, la quale e' essa stessa una entita che
>> oserei definire "liquida" e variabile.
>>
>> Il risultato di questa liquidita' e' che cambia spesso opinione,
>> dimentica cio'che e' stato fatto, si focalizza troppo su l'oggi e
>> sottovaluta la visione strategica di un prodotto.
> Questa mi sembra una generalizzazione, e bisognerebbe portare
> esempi specifici e concreti per capire meglio di cosa parli.

Ma che esempi.
Uno non lo fa' mica di mestiere di partecipare tutti i giorni alla
community.
Te stesso leggi solo ogni tanto.
Quindi il tuo pensiero e' presente a sprazzi.
Idem per chiunque altro. Per cui le opinioni variano in relazione a chi
legge e risponde.

Non mi pare che sulla community di qgis organizzino votazioni dando
tempi settimanali per esprimere pareri. Chi risponde risponde, poi le
decisioni sono prese sulla base di cio' che e' stato detto.


> La modalita' aperta dello sviluppo rende davvero difficile
> "dimenticare" qualcosa di quel che e' stato fatto.

NOn sto dicendoche le cose vanno perse, ma una volta che un rilascio di
qgis ha rotto qualcosa , te lo tieni in tal modo.
Non e' che chi lo ha rotto , si prende la briga di rimettere le cose a
posto, e se anche lo facesse, prima del successivo rilscio non sarebbe
nuovamente disponibile.

Te continui a vederla con l'ottica di uno sviluppatore che sicompila da
se' il prodotto. E quindi no ti preoccupa questo genere di cose perche'
ci metti 30 minuti a ricompilartelo su linux
Ma se pensi di essere un tecnico di un ufficio che deve fare un lavoro ,
che il tuo qgis non funziona piu' come ti aspettavi , e non puoi
riprendere la vecchia versione perche' e' mancante di alcune
funzionalit'a che ti servono pure esse, mica puoi aspettare 3 mesi per
riavere una vesione funzionante per benino.

> Per quanto riguarda la visione strategica, entra in gioco la capacita'
> del proponente di convincere i maintainer della validita' di un approccio.
> Mi viene in mente il caso di Pierre Racine con i PostGIS Raster.
> Non solo Pierre non era nel PSC, ma non era neanche uno sviluppatore.
> Da utilizzatore ha lavorato su un piano strategico cosi' dettagliato
> e convincente da far digerire perfino a Paul Ramsey l'idea di
> supportare i raster nel db (lui ne era notoriamente contrario).
> Va da se che se Pierre non si fosse anche occupato di trovare i fondi
> per finanziarne lo sviluppo difficilmente la cosa sarebbe andata
> avanti (nel senso che non basta convincere a parole, ma bisogna pure
> offrire la nuova funzionalita' ...)
>
>> L'approccio bazar , alla lunga finisce per far nascere anche lui i
>> forks , perche' costringendo gli stakeholders a difendrsi dalla
>> inevitabilita'del rischio del cambio "bottone <-> zip" li spinge a
>> ricercare la sicurezza nella tranquilla oasi di un fork
>> "istituzionale".
> A me sembra un problema generale legato ai cambiamenti.
> Non e' specifico del software libero, ma ben presente anche con quello
> proprietario. Nel software libero semmai e' attenuato proprio perche'
> avendo il diritto legale di distribuire il software non si pone mai il
> problema di non trovare piu' disponibile una versione vecchia di un
> programma (avendo l'accortezza di tenerne copia).
>
> Se poi parliamo di "funzionalita' scomparse" e' un altro paio di
> maniche, e rinnovo il mio invito a segnalare tali casi come bug.

Si certo, ma vale il discroso sopra detto.
Se rilevi questo problema su una versione rilasciata , nel caso peggiore
hai 3 mesi per riavere le cose a posto.
Una era geologica , in certe situazioni.

>> Come avere una visione strategica comune.
> Partecipando alle liste di discussione.

Due problemi:
il prim piu' terreno e' il seguente:

Te immagina di essere il boss diuna ditta che lavora nei GIS, e hai i
tuoi dipendenti , da cui dipende il tuo business. Devi fre una consegna
importantissima, entro le porissime 4 settimane.
Te vai a dire ai tuoi dipendneti, di destinare parte del loor tempo per
partecipare alle discussioni nelle Mailing List perche' devono
presidiare il software da cui dipende il tuo business ?

I dipendenti, o lavorano e producono o presidiano le ML.
Entrambe le cose in orario di ufficio non si possono fare.

Il secondo piu' virtuale e' che se anche presidi una ML, il tuo parere
conta 1 come quelo degli altri.
Se decino di fare una certa cosa perche' ce qualcuno che paga, e magari
piace ad altri , viene fatto.
A che serve presidiare ?

A prepararti mentalmente al casino che ti succedera' appena aggiornerai
qgis ?

Il problema e' che molti di queli che lavorano su QGIS, non credono loro
per primi in quelloche e' qgis.
Credono che sia niente di piu' che un programma di paint piu' complicato.
E pensano che rompere la compatibilit'a con il passato sia una cosa che
si puo' fre perche' tanto chi lo usa si mette li' con pazienza e se
vuole rifa' il progetto qgis daccapo, oppure non lo rifa' e lo abbandona
passando a farne altri.

E' una visione molto miope e dimostra una scarsa percezione del lavoro
che si sviluppa su un software gis.

Te pensa che noi abbiamo dei progetti con parecchie decine di strati
vettoriali con vestizioni moto complicate fatte da gente che ci ha
lavorato per mesi per farle , questa gente , erano studenti
universitari, che hanno realizzato queste vestizioni enl'ambito di un
progetot molto importante e i risultati di queste stampe sono divenuti
prodotti importanti.

In futuro qualcuno potrebbe aver bisogno di riprendere quei progetti e
riaprirli e poter rivedere quei risultati a video.

Ma se quei progetti sono stati fatti su qgis 2.2 e se quando li vado a
aprire con qgis 2.8 vedo risultati differenti, trasparenze che non
tornano piu' simbolismi che non compaiono , retinature con spaziature
difformi.
Etichette che tornano in posti differenti o non compaiono affatto,

Per noi e' una cosa che non va bene.

Te mi dici di restare alla versione 2.2 per avere certezza di poter
sempre riaprire quel progetto.

Puo' darsi che hai ragione, ma allora , capisci anche che quando mi si
viene a chiedere se si puo' evolvere qgis per avere una qualche
funzionalit'a differente, non posso che rispondere
NO, non e' possibile evolverlo ( al pari di un software commerciale).
Questo perche' l'evoluzione andrebbe in un nuovo qgis che non
funzionerebbe piu' bene con altri progetti che abbiamo.

Mica si puo' pretendere che un utente abbia sul suo pc 10 versioni
differenti di qgis una per ogni specifico progetto che deve riaprire.

A.

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