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