Open source vs Closed source: quale aiuta di più l’innovazione?

Il titolo chiede molto di più rispetto a quanto io sia capace di argomentare, quindi forse può essere un po’ fuorviante. Però l’argomento che sta sotto a queste mie piccole considerazioni è proprio quello.

Negli ultimi giorni ho incontrato due esempi che mi hanno fatto ragionare (e confermare una convinzione cresciuta man mano che la mia conoscenza in ambito geospatial si ampliava) su come un approccio open allo sviluppo di software (geografici in questo caso) sia molto più efficace per il miglioramento del software stesso e quindi anche verso l’innovazione in generale.

Blending Modes

Il primo esempio parte dalla notizia che la prossima versione di Quantum GIS, la 2.0, conterrà la possibilità di applicare varie “modalità di sfumatura” (dall’inglese “blending modes“) a layer sia raster sia vettoriali. E’ una tecnica che, mi pare di aver capito, viene usata soprattutto in software per elaborazione di immagini tipo Photoshop o GIMP (qui un esempio dal manuale di GIMP che permette di capire cosa fanno i vari filtri).

In questo caso (ma anche in altri casi, come ad es. in Tilemill) è stato applicato in ambito geografico.

Overlaying rasters with multiply

Overlaying rasters with multiply

Ecco qui la richiesta della funzionalità nel sito di sviluppo di QGIS: ticket aperto esattamente un anno fa, chiuso ieri.

Stessa richiesta per ArcMap, sembra senza risposta da 10 anni (anche se l’idea è stata caricata sul sito 2 anni fa).

Supporto SLD per WMS

Il secondo esempio è di oggi, ed è tratto da una discussione sulla lista gfoss.it, in particolare questa mail, di cui qui sotto ho estratto una parte:

Avevamo pensato di impostare un progetto GIS di medio-grandi dimensioni con
layer di tipo WMS generati da un motore ArcGIS Server 10.

Niente di trascendentale, semplici punti di origine GPS e settori di
pertinenza, entrambi dinamici a fronte di filtri attivati dall'’utente,
pertanto volevamo applicare una stilizzazione dinamica WMS SLD: di per sé
molto semplice, colorazioni differenti in base al contesto.

In questi casi si include l'’SLD direttamente nella chiamata WMS perché,
appunto, è dinamico, ma ci siamo scontrati subito con un problemino “da
nulla” ( = non funzionava niente) che ci è stato giustificato come un “baco
noto di quella versione di ArcGIS” [sic].

Per ovviare, ci siamo inventati un meccanismo di cui vi risparmio i dettagli
e che di fatto trasformava il riferimento SLD da dinamico puro, in una
chiamata costruita al momento ma riferibile ad una URL statica. Questo
sistema di per sé dava il risultato atteso, ma non capivamo perché in
semplice visualizzazione il SQL Server che stava dietro arrancava tanto che
temevamo ci cascasse esanime. Analizzando meglio abbiamo verificato come,
per motivi davvero ignoti, a fronte di una semplice richiesta WMS SLD con
10-20 “colorazioni” diverse, ArcGIS Server scatenava una tempesta di
centinaia di pesanti query. Una inefficienza piuttosto imbarazzante.
L’abbiamo fatto presente a ESRI che ci ha confermato che in quella versione
“l’implementazione WMS funziona male”. E quindi
 quindi
 ora vi lascio
immaginare il finale.

Un inguaribile ottimista potrebbe pensare “ah, emerso un problema serio al
core di piattaforma, ora ESRI scatenerà supporto e sviluppatori per ovviare
e aiutare il suo cliente”.

Eh, magari

La realtà è ben diversa: “la 10 non va bene, dovete comprare la 10.1,
acquistare un contratto di manutenzione e anche pagare la manutenzione per
il periodo passato”.

Ma come? Ci avete venduto una versione farlocca e ora dobbiamo pagare triplo
per il semplice diritto di poterla usare? 

E invece sì: hai comprato una versione fallata, te la tieni, e se proprio
vuoi paghi di nuovo, credi e speri. 

Follia, follia pura.

Da quel momento in poi abbiamo compreso che sia ESRI che il nostro partner
di riferimento ci hanno “scaricato”.

Ora, sono consapevole che anche nel mondo dei software open source ci sono bachi, errori, mancanze, ritardi nell’implementazione di funzionalità ecc. I due esempi ovviamente non sono rappresentativi di tutti i possibili casi positivi o negativi nei due mondi.

Però mi sembra evidente che affidarsi a software proprietari, con nessuna o pochissima potenzialità di interazione o contrattazione, soprattutto per utenti medio/piccoli, possa essere un salto nel vuoto…

Una cosa che cerco sempre di evidenziare—e qui veniamo all’innovazione—è che quando si paga qualcosa nel mondo dell’open source, non è per avere qualcosa (il software), ma è per migliorare (correggere un difetto, aggiungere una funzionalità, migliorare le prestazioni) quello che c’è già a disposizione e, non secondario, permettere a chiunque di usufruire di quel miglioramento. Acquistare una licenza significa semplicemente comprare qualcosa che c’è, senza aggiungere niente di nuovo e senza dare la possibilità a nessun altro di usufruirne.

Quale approccio aiuta maggiormente l’innovazione?

Annunci

3 pensieri su “Open source vs Closed source: quale aiuta di più l’innovazione?

  1. >Acquistare una licenza significa semplicemente comprare qualcosa che
    >c’è, senza aggiungere niente di nuovo e senza dare la possibilità a
    >nessun altro di usufruirne.
    Permettimi, ma trovo semplicistica questa affermazione.
    Acquistare la licenza permette di comprare qualcosa che c’è e che da stipendio a chi la produce, e che può quindi sviluppare nuove funzionalità.

  2. Ovviamente è un’affermazione semplicistica, concordo 🙂
    Quello che dici è giusto, cioè che comprando una licenza permetti agli sviluppatori di sostenere il proprio lavoro e quindi di continuare a sviluppare il software. I software a codice non aperto non sono il male, né tantomeno chi li sviluppa. Mai detto e soprattutto mai pensato niente di vicino a ciò, tanto per sgombrare il campo da interpretazioni possibili sul significato di questo articolo.
    Il fatto però è che quando si compra la licenza per un software, quello che si compra, e che in effetti si vuole comprare, è proprio il software in sè.
    Pagare lo sviluppo di base di un software open source, lo sviluppo di una funzionalità o plugin specifico, la chiusura di un bug, ha espressamente lo scopo di migliorare il software in qualche suo aspetto, non di acquisire una licenza per il suo utilizzo nella sua attuale forma.
    Il problema semmai è che spesso “open source” viene semplicisticamente assimilato solo a “gratis”, azzoppando la sua vera potenzialità che è appunto quella di “innovare” qualcosa.

  3. Pingback: Il vespaio | UBlog – il blog di Urbis Project

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...