[Gfoss] QGis Grass PlugIn 2.0

[aperi2007]

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?
>
>
> _______________________________________________
> Gfoss a lists.gfoss.it
> 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

-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20150802/5a69804c/attachment-0001.html>