[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