Analisi delle priorità di sviluppo di QGIS 3.x (2018-2025)

QGIS QGIS-it-user
, ,
1

Ciao lista,

desidero condividere un’analisi quantitativa delle aree di sviluppo di QGIS dalla versione 3.0 ad oggi, basata sui dati ufficiali dei changelog del progetto.

# CATEGORY count perc%
1 Processing 268 17,19%
2 Data Providers 138 8,85%
3 Symbology 107 6,86%
4 Print Layouts 100 6,41%
5 Expressions 82 5,26%
6 User Interface 82 5,26%
7 Data Management 74 4,75%
8 Programmability 59 3,78%
9 3D Features 57 3,66%
10 Forms and Widgets 55 3,53%
11 Labelling 54 3,46%
12 QGIS Server 53 3,40%
13 Digitizing 52 3,34%
14 Application and Project Options 43 2,76%
15 Browser 41 2,63%
16 Mesh 40 2,57%
17 Map Tools 38 2,44%
18 Rendering 32 2,05%
19 General 31 1,99%
20 Analysis Tools 24 1,54%

DISTRIBUZIONE DELLE AREE DI SVILUPPO (Top 20)

Le prime 5 categorie rappresentano il 44% dello sviluppo totale:

  1. Processing (268 update, 17.19%) - chiaramente l’area prioritaria
  2. Data Providers (138, 8.85%) - focus sull’interoperabilità e accesso ai dati
  3. Symbology (107, 6.86%) - sviluppo della cartografia tematica
  4. Print Layouts (100, 6.41%) - produzione cartografica
  5. Expressions + User Interface (82 ciascuna, 5.26%) - funzionalità di base

AREE EMERGENTI

Alcune categorie mostrano investimenti significativi in tecnologie innovative:

  • 3D Features (57, 3.66%) - sviluppo costante delle capacità 3D
  • Programmability (59, 3.78%) - estensibilità e automazione
  • Mesh (40, 2.57%) - dati scientifici e modellazione

DISTRIBUZIONE DELLE PRIORITÀ

Aggregando per macro-aree, emerge questo quadro:

  • Processing e automazione: ~21%
  • Visualizzazione (simbologia, 3D, rendering, labeling): ~17%
  • Gestione dati e providers: ~13%
  • Interfaccia utente e usabilità: ~11%
  • Output cartografico: ~6%
  • Strumenti di analisi: ~4%

OSSERVAZIONI METODOLOGICHE

I dati mostrano una distribuzione dove:

  • Il 50% dello sviluppo si concentra sulle prime 8 categorie
  • Le funzionalità “core” (processing, data providers, simbologia) rappresentano 1/3 del totale
  • Le tecnologie emergenti (3D, mesh, temporal) hanno circa il 7% complessivo
  • Categorie come QGIS Server (3.40%) e Plugin (1.09%) mostrano percentuali relativamente contenute

ELEMENTI SIGNIFICATIVI

È interessante notare che alcune funzionalità utilizzate quotidianamente dagli utenti non compaiono tra le prime 20 categorie. Questo potrebbe indicare:

  • Stabilità raggiunta in determinate aree
  • Riallocazione di risorse verso nuove funzionalità
  • Differente metodo di categorizzazione degli interventi

LIMITI DELL’ANALISI (grazie a Vincent Picavet e al commento)

È importante sottolineare alcuni bias metodologici di questa analisi:

  1. Bias del Changelog: I changelog elencano principalmente cambiamenti visibili, nuove funzionalità o nuovi comportamenti. Piccoli miglioramenti e rifattorizzazione del codice generalmente non vengono documentati.

  2. Sviluppo nelle librerie sottostanti: Molto lavoro avviene in librerie come GDAL, GEOS, PROJ che non compare nei changelog di QGIS ma ne migliora sostanzialmente le capacità.

  3. Migrazione funzionale: Alcuni strumenti di analisi tradizionali sono stati sostituiti da algoritmi di processing, creando una apparente riduzione di sviluppo in alcune categorie quando in realtà c’è stata una riorganizzazione.

  4. Metriche alternative: Analizzare le Pull Request e il numero di righe di codice modificate potrebbe fornire un quadro completamente diverso e più accurato dell’effettivo sforzo di sviluppo.

RIFLESSIONI SUL MODELLO DI SVILUPPO

I dati sollevano una questione fondamentale del finanziamento del software open source:

È strutturalmente più facile trovare finanziamenti per nuove funzionalità “scintillanti” che per la manutenzione e il miglioramento incrementale delle funzionalità esistenti.

Questo fenomeno non è specifico di QGIS ma caratterizza l’intero ecosistema open source. Finché gli utenti (aziende, enti pubblici, professionisti) non saranno disposti a pagare per la manutenzione annuale del software senza aspettarsi necessariamente nuove funzionalità visibili, questa dinamica difficilmente cambierà.

AREE DI POTENZIALE MIGLIORAMENTO

Dall’analisi emergono alcune considerazioni:

  1. Ascolto degli utenti finali: Potrebbe esserci uno spazio per un dialogo più strutturato tra sviluppatori e utenti finali sulle reali esigenze quotidiane

  2. Manutenzione e miglioramento continuo: Le caratteristiche esistenti necessitano di finanziamenti dedicati per evoluzione incrementale e ottimizzazione

  3. Focus sull’User Experience: Investimenti mirati sull’UX potrebbero migliorare significativamente l’esperienza d’uso in tutte le aree di QGIS, rendendo il software più accessibile ed efficiente

CONCLUSIONI

I dati mostrano un progetto maturo con:

  • Forte investimento su capacità di processing (quasi 1/5 dello sviluppo)
  • Attenzione equilibrata tra backend (data providers, server) e frontend (UI, simbologia)
  • Crescita programmata verso tecnologie emergenti (3D, temporal, mesh)
  • Consolidamento degli strumenti di produzione cartografica

Questa distribuzione riflette sia le dinamiche di finanziamento del software open source che le priorità strategiche del progetto. Comprendere questi meccanismi è fondamentale per chi utilizza QGIS professionalmente e potrebbe considerare di contribuire al suo sviluppo, non solo tecnicamente ma anche economicamente.

Sarei interessato a conoscere le vostre osservazioni su questi dati, sul modello di finanziamento e su come tutto questo corrisponda alle esigenze che riscontrate nel vostro utilizzo quotidiano di QGIS.

saluti

2

Analisi interessante soprattutto a valle delle osservazioni di Vincent che aggiustano il tiro.

effettivamente la comodità di un’analisi via AI come quella che hai fatto e cui hai affidato in parte le prime conclusioni, a volte fa perdere di vista il contesto generale e quello particolare.

mi riferisco al già citato discorso della do-acracy.
è forse triste dirlo, ma in questi progetti “comanda” chi fa. le virgolette sono d’obbligo perché comunque QGIS ha una governance e un contatto con gli utenti anche se sicuramente andrebbero ascoltati di più.

ricordo tanti anni fa quando QGIS veniva sarcasticamente chiamato crashGIS a causa delle frequenti battute d’arresto e blocchi strani ed improvvisi. io personalmente riscontro nel mio uso pressoché quotidiano che QGIS è stabilissimo e le volte in cui ho un crash è da imputare al dataset o alla illogicità di una operazione richiesta.

Dunque gli sviluppi volti a migliorare le performance del nostro software non fanno rumore ma, assieme a quelli legati alle librerie di appoggio, hanno contribuito alla stabilità e completezza di cui oggi tutti godiamo.

quanto alla priorità degli sviluppi core, ognuno ha le proprie priorità.
Tu, Totò, solleciti il miglioramento della gestione della tabella attributi, chi invece con la diffusione degli strumenti di produzione di dati 3D (nuvole di punti LiDAR, SLAM eccetera, BIM) spinge su questo versante ed è oggettivamente vero che o uno sviluppatore gratis et amore dei si applica e a quel punto fa quello che gli piace fare e che sente di più nelle sue corde, oppure se c’è un affidamento pagato sviluppa quanto richiesto.

Gli utenti possono cambiare qualcosa?
Sicuramente sì e il “grido di dolore” lanciato da Totò non sarà inascoltato, ma ricordiamoci che, tornando alla do-acracy, spetta anche a noi agire.

L’alternativa che vedo sempre di più esaltata anche da chi usa QGIS su LinkedIN è il modello di business proprietario di ESRI, che a me inorridisce ma che invece ha grande appeal sia negli utenti sia in chi decide, rendendo vani i discorsi di sovranità digitale, lock in eccetera.

8500 anno a licenza per desktop + spatial analyst è un abominio.
ma il problema come ha detto Luca Lanteri è che siamo ancora alla fase di “uso-e-basta”, senza che ci sia la consapevolezza piena di free software, open source, gratuito, freemium, proprietario eccetera.

Ho assistito a presentazione di progetti da decine di milioni di euro PNRR basati su infrasruttura ESRI e a richiesta specifica di spiegazioni sui criteri di scelta di questa soluzione (proprietaria) a fronte del dettato del Codice dell’Amministrazione Digitale (artt. 68 e 69) la risposta è stata data più o meno genericamente o che si usano prodotti già esistenti e quindi in continuità oppure che è più “comodo” usare infrastruttura ESRI.

Insomma, il panorama proprietario è sempre più affamato per ridurre anche a livello mediatico gli strumenti liberi come innocui passatempo non adatti a costruire sistemi robusti ed affidabili e soprattutto ai piccoli enti la soluzione proprietaria sembra la più adatta.

Sullo sviluppo di QGIS, l’AI sta mettendo in evidenza che è possibile per tutti o quasi creare strumenti per migliorare la propria produttività (plugin) e credo che prima o poi, non a tutti, sarà concesso anche di lavorare per lo sviluppo core.

Noi utenti finali dovremmo forse essere più presenti nei momenti in cui viene richiesto un intervento o in ogni caso non aprire generiche feature request sul git ma strutturare esigenze funzionali magari anche con indicazioni di quanto potrebbe costare.

non so se in questo pomeriggio di fine vacanze sono riuscito a rispondere a tutte le sollecitazioni sollevate da Totò, spero di sì…

Keep the Faith

s.

3

“non so se in questo pomeriggio di fine vacanze sono riuscito a rispondere a tutte le sollecitazioni sollevate da Totò, spero di sì”

sei stato chiarissimo e poi, in fondo, queste giornate di relax sono il momento migliore per fare queste piacevoli “chiacchierate” tra persone in sintonia di interessi

4

questa è una bella osservazione:

image
image534×293 17.3 KB

sarebbe molto utile!