[Gfoss] QGis Grass PlugIn 2.0

[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