[Gfoss] come finanziare i GIS liberi

Francesco Paolo Lovergine frankie a debian.org
Sab 25 Feb 2012 12:29:06 CET


On Thu, Feb 23, 2012 at 04:34:02PM +0100, Sandro Santilli wrote:
> > 
> > Temo che la cosa si debba valutare caso per caso. Ci sono progetti
> > piuttosto monolitici in cui certe cose non si possono proprio
> > fare senza poter mettere mano al core e altri in cui basta 
> > implementare un 'plugin' o un modulo del tutto indipendente 
> > per risolvere.
> 
> Questa e' una discussione interessante.
> 
> Mette l'accento su due approcci al software libero:
>  - Il valore e' nella tecnologia  
>  - Il valore e' nella comunita' 
> 
> Il reviewing da parte del team e' senza dubbio un valore aggiunto.
> Riuscire ad ottenerlo, di conseguenza, ha un valore maggiore rispetto
> ad uno sviluppo "autistico".
> 
> Certo non si puo' pretendere che una comunita' intera sia sempre
> a disposizione per fare le review, ma si puo' fare del proprio meglio
> affinche' tali review costino meno in termini di costo. La produzione
> di testcase di larga copertura, ad esempio, o la meticolosa
> documentazione del processo, e un codice di facile lettura.
> 
> Dopodiche' se il progetto e' inaccessibile secondo me c'e' qualcosa
> che non va e che ne limita il valore (nella comunita'). Cio' non esclude
> la possibilita' di rinunciare a tale valore e puntare al solo valore
> tecnologico.
> 

A mio modo di vedere la gestione più o meno aperta dei contributi
esterni è in parte legata alla governance e in parte alle caratteristiche
architetturali del prodotto. Il discorso è piuttosto complesso, ma alcune
riflessioni si possono facilmente fare guardando progetti con 
una lunga storia alle spalle tipo il kernel e diversi linguaggi di
programmazione e toolchain più o meno noti.

Una governance di successo non si improvvisa e alcuni approcci in tale sono
applicabili o da applicare solo nel caso di prodotti con una larga base
di sviluppatori e in qualche modo 'legacy'.

E' parimenti vero che se il prodotto è architetturalmente valido,
composto di molte parti indipendenti, con possibilità di plugin e
interfacce stabilizzate e chiare, distribuire la responsabilità è molto
più semplice. Ma una disegno 'cazzuto' non è che uno se lo può dare
da un giorno all'altro :) 

Una lettura interessante su questi temi può essere

Producing Open Source Software:
How to Run a Successful Free Software Project

di Karl Fogel

che parla proprio di queste tematiche. Il PDF/EPUB ecc. è libero.

-- 
Francesco P. Lovergine


Maggiori informazioni sulla lista Gfoss