<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<pre wrap="">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.</pre>
<br>
QGIS tenta di proporre un modello unificato per i vari stakeholder:<br>
<br>
-"chiedi cio' che ti serve, discutiamone in lista, mettiamoci
daccordo su come va fatta, la funzionalita' che finanzi ci sara'
nella prossima versione rilasciata"-<br>
<br>
La prima cosa che a me salta agli occhi e' il problema procedurale
che questo approccio fa nascere.<br>
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.<br>
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. <br>
<br>
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.<br>
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.<br>
<br>
E' invece un problema per uno stakeholder pubblico, il quale ha
difficolta' a operare con queste modalita'.<br>
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.<br>
L'incarico deve essere unico e complessivo. Per cui, non è opportuno
separare in due fasi distinte.<br>
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').<br>
<br>
Questo e' il primo grosso problema che incontra una PA
nell'approcciare uno sviluppo su QGIS.<br>
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.<br>
<br>
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.<br>
Ovvero, prima di prende il lavoro e poi si interloquisce con la
community.<br>
<br>
Quando l'approccio e' questo, la conseguenza e' un fork , oppure una
crescita dei costi (a posteriori).<br>
Non si puo' infatti escludere che l'interazione con la community
possa portare a una revisione di cio' che si prevedeva di fare. <br>
<br>
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:<br>
accettazione di un fork. Cioe' una versione fatta nei modi
originariamente previsti e che mai sara' accettata dalla community
di QGIS.<br>
Oppure, una revisione dei prezzi, che sicuramente non sara' piccola.<br>
<br>
Questo tipo di problema oggi in qualche modo, si riesce a superare.<br>
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.<br>
<br>
Per semplificare tutto il discorso:<br>
non basta saper programmare in C e compilare un qgis dai sorgenti.<br>
Ma occorre che abbiano un flusso di lavoro che preveda gia' una
interoperazione con una community. <br>
<br>
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.<br>
<br>
La modalit'a classica a scatola chiusa:<br>
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.<br>
<br>
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).<br>
<br>
Una community che partecipa gioco forza alle scelte e a determinare
le medesime.<br>
<br>
Una community che pero' non puo' essere coinvolta durante la fase
lavorativa, ma bensi' prima, gia' durante la fase di formazione
dell'offerta.<br>
<br>
Quindi il primo problema, si sta naturalmente risolvendo.<br>
Ma qui nasce poi il secondo problema:<br>
Ovvero, la community stessa, la quale e' essa stessa una entita che
oserei definire "liquida" e variabile.<br>
<br>
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.<br>
<br>
Questo porta al paradigma del prodotto che oggi ha i "bottoni" e
domani "la zip".<br>
E' il cosidetto approccio "bazar" che cita spesso Santilli assieme
al suo approccio alternativo "a cattedrale".<br>
<br>
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.<br>
<br>
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".<br>
<br>
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.<br>
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.<br>
Poi, come non bastasse, occorre che essi stessi abbiano chiaro la
visione strategica che si vuole dare al prodotto.<br>
<br>
Mi spiego con un esempio di fantasia:<br>
oggi , qgis e' aperto a ogni forma di contributo.<br>
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.<br>
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.<br>
A mio modo di vedere qui non centra l'approccio bazar o l'approccio
cattedrale, centra la visione strategica di un prodotto.<br>
Cosa deve fare e come lo deve fare cosa ci sta bene dentro di esso e
cosa non ci sta' bene.<br>
<br>
Come si risolve questo aspetto ?<br>
Come si evita che oggi ci siano i bottoni e domani ci sia la zip ?<br>
Che oggi si operi in notazione algebrica usuale e domani in polacca
inversa (rpn) ?<br>
<br>
E' questo il problema.<br>
<br>
Come avere una visione strategica comune. <br>
Certamente serve passare da un gruppo che coordini, ma non puo'
bastare.<br>
<br>
E' questa la sfida difficile che deve risolvere QGIS e il gruppo che
intorno a qgis si sta coagulando.<br>
<br>
Qui riprendo un discorso gia' avviato qualche tempo fa'.<br>
Leggoche si sta formando (te stesso la hai citata nella tua replica)
un gruppo qgis-users che abbia il copito di prendere le decsioni.<br>
Questa e' una buona cosa, perche' va a contrastare l'egemonia
dell'approccio bazar,<br>
ma pero' si sta dicendo anche che nel gruppo decisionale i primari
attori a prendere le decisioni debbano essere i developers.<br>
<br>
Potra' questo garantire che domani non ci sia la zip al posto dei
bottoni ?<br>
<br>
Io non lo so', ma non credo.<br>
<br>
E' questa la sfida difficile a cui qgis verra' chiamato nei prossimi
anni.<br>
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.<br>
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).<br>
<br>
Questa evoluzione ha certamente dei costi vivi.<br>
Non fosse altro per garantire a determinati soggetti di poterci
lavorare sopra a tempo pieno.<br>
Ma chi deve finanziare questo ?<br>
<br>
Qui si arriva alla parte difficile.<br>
<br>
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.<br>
<br>
Forse soluzioni di crowd-funding potrebbero parzialmente risolvere
il problema. Una altra parziale soluzione potrebbe arrivare dalla
iscrizione annuale al qgis-users.<br>
Ma tutte queste soluzioni terrebbero fuori lo stake-holder pubblico.<br>
Che certamente non po' partecipare a u crowd-funding , ne puo'
iscriversi a un qgis-users (che io sappia).<br>
<br>
Pero' ci potrebbero pensare soluzioni piu' pragmatiche.<br>
<br>
Ad esempio:<br>
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.<br>
<br>
Questo contributo potrebbe essere codificato e facilmente
conteggiato in una offerta economica formulata dalla ditta che
valuta i costi per realizzare una evoluzione.<br>
<br>
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). <br>
E dare al gruppo guida il diritto di esonerare da questo pagamento
persone meritevoli.<br>
<br>
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.<br>
<br>
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".<br>
<br>
My2ct.<br>
<br>
A.<br>
<br>
Il 02/08/2015 14:10, Luca Mandolesi ha scritto:<br>
<blockquote
cite="mid:CAHmdnV5YqJouiA3NgviNLhzCHFnT-vwG1TrfWVT1pe1jr8xodA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">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?</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Gfoss@lists.gfoss.it">Gfoss@lists.gfoss.it</a>
<a class="moz-txt-link-freetext" href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss">http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss</a>
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</pre>
</blockquote>
<br>
</body>
</html>