[Gfoss] come finanziare i GIS liberi

Andrea Aime andrea.aime a geo-solutions.it
Sab 25 Feb 2012 19:58:20 CET


On Sat, Feb 25, 2012 at 7:01 PM, Andrea Aime
<andrea.aime a geo-solutions.it>wrote:

> On Fri, Feb 24, 2012 at 7:21 AM, Paolo Cavallini <cavallini a faunalia.it>wrote:
>
>> Per chiarire: l'inclusione nel codice sorgente non e' mai automatica, e
>> non e' certamente necessario essere sviluppatori di quel particolare pezzo
>> di software per esserne certi.
>> Le probabilita' comunque, IMHO vanno in modo decrescente con questo
>> ordine approssimativo:
>> sviluppatore di quel determinato pezzo>sviluppatore di quel
>> progetto>sviluppatore di un altro progetto libero>non contributore di alcun
>> progetto.
>> E ovviamente la qualita' del codice e la governance del progetto hanno
>> un'importanza molto rilevante.
>>
>
> Concordo sulla gerarchia, in termini di probabilità generale,
> completamente slegata dal singolo contesto.
> Per fare un esempio che mi è familiare, GeoServer, una patch ha elevata
> probabilità di essere integrata se:
>

Btw, il discorso che ho fatto vale per una patch che modifica la versione
ufficiale del software.
Ovviamente ci sono altre alternative:
- fork del software.
- fare un plugin che eviti completamente la comunità, o quantomeno il
"core", rilasciato e gestito a parte

Se l'uso è una-tantum, per un uno specifico e limitato nel tempo,
è probabilmente ragionevole fare una versione specifica (fork) senza
verifiche di qualità, basta
che vada per lo specifico uso per cui è pensata (se poi un anno dopo si
vuole quella
funzionalità più qualcosa di nuovo che è nel software principale... ciccia)

Un plugin a parte è un altro modo per evitare il costo/tempo di interazione
(e integrazione)
con la comunità degli sviluppatori.
Il che va bene, ma chi accetta tale soluzione dovrebbe chiedersi chi ne fa
manutenzione
in lungo periodo: il contratto copre solo la produzione del nuovo plugin, o
anche
il suo mantenimento del tempo in uno stato funzionante?

L'integrazione di una patch nel core è un po' diversa, una volta che è
messa dentro
l'onere di manutenzione non è solo su chi l'ha prodotta, ma anche su chi
l'ha accettata
(anzi, spesso chi ha prodotto la patch sparisce e rimangono solo gli
svilupatori abituali
 a gestire quel nuovo blocco di codice, anche noto come "contributo hit and
run").
Chiaro, questo non vuol dire che i "core developer" andranno come avvoltoi
su ogni
problema rilevato nel codice integrato nel core,ma senz'altro c'e' un
occhio di riguardo
che non può esserci nel codice gestito al di fuori del core (codice che gli
sviluppatori
abituali non conoscono e/o di cui non sanno l'esistenza).

Ciao
Andrea


-- 
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:      +39 0584 962313
mob:    +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20120225/79fecf86/attachment.html>


Maggiori informazioni sulla lista Gfoss