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@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
_______________________________________________
Gfoss@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
