[Gfoss] come finanziare i GIS liberi

Local Chapters GFOSS.it
1

Salve.
Faccio seguito ad una interessante discussione avviata al recente meeting a Trieste, per dare indicazioni pratiche di come un ente pubblico possa finanziare i GIS liberi per lui più importanti.
La soluzione e' semplice: individuate una funzionalità mancante, o alcuni malfunzionamenti, importanti per il vostro lavoro, e trovate uno sviluppatore che possa sistemarli.
Il punto più importante è assicurarsi che questi cambiamenti vengano effettivamente incorporati nel software di vostro interesse. Come ci spiegava bene Andrea Aime, questo è un passaggio non scontato. Per fare questo, il suggerimento è di verificare le effettive capacita' dello sviluppatore in questione, accertandosi che abbia contribuito in modo efficace a quel determinato software in tempi recenti. L'apertura del codice rende questo molto semplice e certo.
Se ci sono dubbi, non esitate a chiedere.
Cordiali saluti.

--
Paolo Cavallini
See: http://www.faunalia.it/pc

2

Ciao, a me interesserebbe il finanziamento di GIS opensource da parte di un privato.
Alcune domande pratiche:
mettiamo che una ditta abbia bisogno di una certa funzionalità e decide di finanziarne lo sviluppo:

chi decide l’entità del finanziamento? ci sono delle tariffe standard prezzo / ora di lavoro richiesto?
cosa si fa praticamente? si firma un contratto?
esistono esempi / documentazione su casi di questo tipo da poter prendere come esempio?

Saluti Tommaso

On Mon, 2012-02-20 at 12:24 +0100, Paolo Cavallini wrote:

Salve.
Faccio seguito ad una interessante discussione avviata al recente 
meeting a Trieste, per dare indicazioni pratiche di come un ente 
pubblico possa finanziare i GIS liberi per lui più importanti.
La soluzione e' semplice: individuate una funzionalità mancante, o 
alcuni malfunzionamenti, importanti per il vostro lavoro, e trovate uno 
sviluppatore che possa sistemarli.
Il punto più importante è assicurarsi che questi cambiamenti vengano 
effettivamente incorporati nel software di vostro interesse. Come ci 
spiegava bene Andrea Aime, questo è un passaggio non scontato. Per fare 
questo, il suggerimento è di verificare le effettive capacita' dello 
sviluppatore in questione, accertandosi che abbia contribuito in modo 
efficace a quel determinato software in tempi recenti. L'apertura del 
codice rende questo molto semplice e certo.
Se ci sono dubbi, non esitate a chiedere.
Cordiali saluti.

-- 
Paolo Cavallini
See: [http://www.faunalia.it/pc](http://www.faunalia.it/pc)

_______________________________________________
Iscriviti all'associazione GFOSS.it: [http://www.gfoss.it/drupal/iscrizione](http://www.gfoss.it/drupal/iscrizione)
[Gfoss@lists.gfoss.it](mailto:Gfoss@lists.gfoss.it)
[http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss](http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss)
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
569 iscritti al 4.1.2012
3

Da questo punto di vista non ci sono differenze rispetto a qualunque lavoro di sviluppo:

  • cerchi uno sviluppatore che faccia al caso tuo (facile, perche’ puoi vedere chi ha fatto cosa, tramite l’ispezione dell’svn o git)
  • scrivi le specifiche
  • gli chiedi un preventivo
  • firmi un contratto
  • finito il lavoro, collaudi e paghi.
    Saluti!
··· 
-- 
Paolo Cavallini
See: [http://www.faunalia.it/pc](http://www.faunalia.it/pc)
4

Io ho già preso contatto con un programmatore e ho ottenuto una specie di preventivo. Il punto è che non sono io che prendo le decisioni e il mio capo si è mostrato un po’ scettico, ha detto che una cosa del genere lui non l’ha mai vista e che gli sembra strana (perché non compriamo una licenza, cosa invece normale). Quindi volevo sapere se esistono degli esempi pratici (documenti di altri finanziamenti) da poter mostrare al mio capo e convincerlo.

Saluti Tommaso

PS: Quello che vorrei finanziare è una nuova funzione del plugin per Qgis CadTools.

On Tue, 2012-02-21 at 19:47 +0100, Paolo Cavallini wrote:

Il 21/02/2012 19:28, tommaso ha scritto:

chi decide l’entità del finanziamento? ci sono delle tariffe standard prezzo / ora di lavoro richiesto?
cosa si fa praticamente? si firma un contratto?
esistono esempi / documentazione su casi di questo tipo da poter prendere come esempio?

Da questo punto di vista non ci sono differenze rispetto a qualunque lavoro di sviluppo:

  • cerchi uno sviluppatore che faccia al caso tuo (facile, perche’ puoi vedere chi ha fatto cosa, tramite l’ispezione dell’svn o git)
  • scrivi le specifiche
  • gli chiedi un preventivo
  • firmi un contratto
  • finito il lavoro, collaudi e paghi.
    Saluti!
-- 
Paolo Cavallini
See: [http://www.faunalia.it/pc](http://www.faunalia.it/pc)
5

2012/2/21 tommaso <tommasodb@googlemail.com>:

Io ho già preso contatto con un programmatore e ho ottenuto una specie di
preventivo. Il punto è che non sono io che prendo le decisioni e il mio capo
si è mostrato un po' scettico, ha detto che una cosa del genere lui non l'ha
mai vista e che gli sembra strana

Per fortuna c'è nulla di strano. Sia al mio precedente istituto che alla
Fondazione E Mach dove lavoro da qualche anno riceviamo contratti
di sviluppo di software libero (GRASS in particolare, grazie al Comune
di Trento) ma noi paghiamo anche sviluppatori esterni (per esempio,
"thin spline interpolation" in GDAL - F Warmerdam; sviluppo di ZOO
Web Services - G Fenoy; sviluppo di GRASS GIS - M Landa etc).

Cerco essenzialmente di - se serve - finanziare sviluppo di GFOSS
da qualche progetto di ricerca. Mi sembra anche giusto che i soldi
che sono tipicamente pubblici (provincia, ministero, UE etc) vengono
indirettamente resi a disposizione di tutti come possibile con software
libero.

(perché non compriamo una licenza, cosa
invece normale).

Per noi no :slight_smile: Per noi è normale di pagare il *servizio* di sviluppo e
che il software abbia la licenza che piace a noi: in questo caso che
sia libera! Solo così possiamo prendere il software sviluppato per
noi e combinarlo con altro software libero, modificarlo, rilasciarlo etc.

Quindi volevo sapere se esistono degli esempi pratici
(documenti di altri finanziamenti) da poter mostrare al mio capo e
convincerlo.

I documenti del Comune di Trento del progetto GFOSS-TN sono
online da qualche parte. Ho una serie di altri contratti ma visto che
sono di diritto privato non posso pubblicarli in lista.
La traccia in GDAL:
http://www.gdal.org/gdal__alg_8h.html#a245802b88a8126c138d24febe6c9822a
--> "Incorporation of the algorithm into GDAL was supported by the
       Centro di Ecologia Alpina (http://www.cealp.it)." (ora Fondazione E Mach)

Spero che sia utile questo commento,
Markus

--
Markus Neteler, PhD
Fondazione Edmund Mach (FEM) - Research and Innovation Centre
Department of Biodiversity and Molecular Ecology
Head of GIS and Remote Sensing Unit
Via E. Mach, 1 - 38010 S. Michele all'Adige (TN), Italy
Web: http://gis.cri.fmach.it - http://grass.osgeo.org
Email: markus.neteler AT fmach.it

6

Io ho già preso contatto con un programmatore e ho ottenuto una specie di preventivo. Il punto è che non sono io che prendo le decisioni e il mio capo si è mostrato un po’ scettico, ha detto che una cosa del genere lui non l’ha mai vista e che gli sembra strana (perché non compriamo una licenza, cosa invece normale). Quindi volevo sapere se esistono degli esempi pratici (documenti di altri finanziamenti) da poter mostrare al mio capo e convincerlo.

Qualunque lavoro di sviluppo funziona cosi’, in tutti i campi. In questo senso non ci sono differenza col software proprietario.

PS: Quello che vorrei finanziare è una nuova funzione del plugin per Qgis CadTools.

In questo caso, la prima scelta e’ chiedere direttamente a chi l’ha sviluppato.
Attenzione a non far fare il lavoro a qualcuno che poi non puo’ integrare i risultati nel plugin originale.
Saluti.

··· 
-- 
Paolo Cavallini
See: [http://www.faunalia.it/pc](http://www.faunalia.it/pc)
7

Il 22 febbraio 2012 08:20, Paolo Cavallini <cavallini@faunalia.it> ha scritto:

In questo caso, la prima scelta e' chiedere direttamente a chi l'ha
sviluppato.

+1

Attenzione a non far fare il lavoro a qualcuno che poi non puo' integrare i
risultati nel plugin originale.

questo mi sembra strano, al massimo qualcuno può decidere di non
integrare i risultati, ma le patch per integrare il codice esistono da
sempre :wink:

Saluti.

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

8

Segnalo anche un'altra modalità alla quale possono aderire più utenti interessati alla stessa funzione ed i costi vengono ripartiti tra i vari utenti.
A titolo di esempio nel link qui sotto trovate una raccolta fondi per una nuova funzionalità in PostGIS, alla quale hanno aderito vari utenti del software interessati. Nel giro di un mese sono stati raccolti i fondi ed è partito lo sviluppo.
http://www.pledgebank.com/postgistopology

Paolo

9

Il 22/02/2012 08:33, Luca Delucchi ha scritto:

questo mi sembra strano, al massimo qualcuno può decidere di non
integrare i risultati, ma le patch per integrare il codice esistono da
sempre :wink:

Certo, e sono pure facili. Pero', come ci spiegava bene Andrea Aime a Trieste, e come indicavano altri nel caso di gvSIG, questo non garantisce che le patches vengano integrate. Dal punto di vista del committente, e' facile assicurarsi che cio' accada, con una clausola del tipo "non ti pago finche' il tuo lavoro non viene integrato nel codice sorgente principale".
Saluti.

--
Paolo Cavallini
See: http://www.faunalia.it/pc

10

Il 22/02/2012 08:55, Paolo Viskanic ha scritto:

Segnalo anche un'altra modalità alla quale possono aderire più utenti interessati alla stessa funzione ed i costi vengono ripartiti tra i vari utenti.
A titolo di esempio nel link qui sotto trovate una raccolta fondi per una nuova funzionalità in PostGIS, alla quale hanno aderito vari utenti del software interessati. Nel giro di un mese sono stati raccolti i fondi ed è partito lo sviluppo.
http://www.pledgebank.com/postgistopology

Si', verissimo, grazie per ricordarcelo. Fra l'altro, GFOSS.it ha contribuito alla "colletta". Una modalita' di questo tipo, pero', penso che sia difficilmente percorribile per un ente pubblico (la scintilla che ha fatto partire questa discussione).
Saluti.

--
Paolo Cavallini
See: http://www.faunalia.it/pc

11

In data mercoledì 22 febbraio 2012 08:20:47, Paolo Cavallini ha scritto:

Il 21/02/2012 20:40, tommaso ha scritto:

In questo caso, la prima scelta e' chiedere direttamente a chi l'ha
sviluppato.
Attenzione a non far fare il lavoro a qualcuno che poi non puo'
integrare i risultati nel plugin originale.

Sarebbe a dire che lo può fare solo l'autore?
Suvvia....

--
Alessandro Pasotti
itOpen - "Open Solutions for the Net Age"
w3: www.itopen.it
Linux User# 167502

12

Il 22/02/2012 09:20, Alessandro Pasotti ha scritto:

Sarebbe a dire che lo può fare solo l'autore?
Suvvia...

Certo che no. Basta che il committente si accerti che il lavoro venga integrato.
Saluti.

--
Paolo Cavallini
See: http://www.faunalia.it/pc

13

On Wed, Feb 22, 2012 at 08:55:04AM +0100, Paolo Viskanic wrote:

Segnalo anche un'altra modalità alla quale possono aderire più utenti interessati alla stessa funzione ed i costi vengono ripartiti tra i vari utenti.
A titolo di esempio nel link qui sotto trovate una raccolta fondi per una nuova funzionalità in PostGIS, alla quale hanno aderito vari utenti del software interessati. Nel giro di un mese sono stati raccolti i fondi ed è partito lo sviluppo.
http://www.pledgebank.com/postgistopology

Quella modalita' li' va un po' per le lunghe, e non garantisce
il raggiungimento dell'obiettivo. Se parliamo di un soggetto che
ha un'esigenza e' molto meglio andare diretti come descritto da
altri.

PS: complimenti a Markus per la politica che porta avanti
    nell'istituto di ricerca !

--strk;

14

On Wed, Feb 22, 2012 at 09:28:17AM +0100, Paolo Cavallini wrote:

Il 22/02/2012 09:20, Alessandro Pasotti ha scritto:
>Sarebbe a dire che lo può fare solo l'autore?
>Suvvia...
Certo che no. Basta che il committente si accerti che il lavoro
venga integrato.

Faccio notare che non sempre l'integrazione o meno del risultato
dipende direttamente da chi ha prodotto il patchset
o il prodotto. Un esterno al team di sviluppo normalmente deve
affrontare un reviewing da parte del team medesimo, e questa
cosa costa tempo (al team, a parte che a chi ha prodotto il patchset).
In definitiva il team medesimo potrebbe continuare a ignorare
il patchset ad libitum, per motivi non legati alla qualità tecnica
del lavoro.

Diversamente stai sostenendo che si debba pagare solo chi
ha un commit privilege, cioè un gruppo generalmente piuttosto
ristretto di sviluppatori. Non mi pare molto sensato, anche
considerando che il committente potrebbe essere interessato
a una funzionalità piuttosto specializzata.

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.

--
Francesco P. Lovergine

15

On Thu, Feb 23, 2012 at 04:18:44PM +0100, Francesco P. Lovergine wrote:

On Wed, Feb 22, 2012 at 09:28:17AM +0100, Paolo Cavallini wrote:
> Il 22/02/2012 09:20, Alessandro Pasotti ha scritto:
> >Sarebbe a dire che lo può fare solo l'autore?
> >Suvvia...
> Certo che no. Basta che il committente si accerti che il lavoro
> venga integrato.
>

Faccio notare che non sempre l'integrazione o meno del risultato
dipende direttamente da chi ha prodotto il patchset
o il prodotto. Un esterno al team di sviluppo normalmente deve
affrontare un reviewing da parte del team medesimo, e questa
cosa costa tempo (al team, a parte che a chi ha prodotto il patchset).
In definitiva il team medesimo potrebbe continuare a ignorare
il patchset ad libitum, per motivi non legati alla qualità tecnica
del lavoro.

Diversamente stai sostenendo che si debba pagare solo chi
ha un commit privilege, cioè un gruppo generalmente piuttosto
ristretto di sviluppatori. Non mi pare molto sensato, anche
considerando che il committente potrebbe essere interessato
a una funzionalità piuttosto specializzata.

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.

--strk;

  ,------o-.
  | __/ | Delivering high quality PostGIS 2.0 !
  | / 2.0 | http://strk.keybit.net - http://vizzuality.com
  `-o------'

16

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.
Saluti.

--
Paolo Cavallini
See:http://www.faunalia.it/pc

17

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 :slight_smile:

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

18

On Fri, Feb 24, 2012 at 7:21 AM, Paolo Cavallini <cavallini@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:

  • è stata discussa con la comunità prima dello svilupppo (per assicurarsi che non confligga con altri
    sforzi e sia in linea con l’architettura del prodotto)
  • è stata sviluppata seguendo le stesse convezioni di codifica del progetto, senza riformattare codice
    esistente (in modo che le modifiche siano tutte e sole le parti evidenti dal file di patch)
  • è dotata di test automatici (junit nel nostro caso) che ne dimostrano il corretto funzionamento
    (oggi e anche in futuro)
  • se è una nuova funzionalità, è stata anche aggiunta una patch alla documentazione (questo non è
    di fatto richiesto, ma è così bello quando succede!)

Se una patch rispetta le regole di massima esposte sopra entra. Detto questo, non ci sono garanzie sui tempi,
per fare un esempio un paio di settimane fa è stata proposta una patch relativamente piccola, ma molto
ben fatta, su geoserver-devel:
http://osgeo-org.1560.n6.nabble.com/Proposal-to-enhance-control-flow-module-td4474108.html

Una prima review a partire dalla presentazione del lavoro (senza guardare la patch)
ha individuato problemi nel lavoro, che sono stati corretti.
La patch è poi stata aggiunta qui, ma inizialmente non si applicava a un checkout:
https://jira.codehaus.org/browse/GEOS-4961
Visto che la review e il commit di roba non lavorativa ho tempo di farlo solo il fine settimana,
la cosa è andata avanti un po’ nel tempo, forse domani riuscirò a guardarla e a committarla.
Da notare che questo è il primo contributo per lo sviluppatore in questione, ma bisogna dire
che si è presentato nel migliore dei modi.

Non sempre le cose vanno altrettanto bene. Qui c’e’ un caso in cui si è andati
avanti un paio di mesi partendo da una prima patch un po’ pasticciata, con
alcuni bug, e senza test
(e in cui ho dovuto aggiungere del mio per dare una sistemata alla patch):
https://jira.codehaus.org/browse/GEOS-4927

CiaoAndrea

–

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

19

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

On Fri, Feb 24, 2012 at 7:21 AM, Paolo Cavallini <cavallini@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

20

Il 25/02/2012 19:01, Andrea Aime ha scritto:

Concordo sulla gerarchia, in termini di probabilità generale, completamente slegata
dal singolo contesto.

Grazie. E grazie anche per le importanti precisazioni, tue e di altri.
Non vorrei che la cosa sembrasse troppo complicata a chi si avvicina per la prima
volta a questi problemi: quello che intendevo fare era dare una guida semplice dei
passi da compiere per contribuire, in maniera efficace e trasparente, ai GIS liberi.
Saluti, e buona giornata.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc