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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
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?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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
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: _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
2012/2/21 tommaso <[hidden email]>:
> 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 :) 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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
In reply to this post by tommaso
Il 21/02/2012 20:40, tommaso ha scritto:
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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
Il 22 febbraio 2012 08:20, Paolo Cavallini <[hidden email]> 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 ;-) > Saluti. > -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
In reply to this post by Luca Delucchi
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 ;-) 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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
In reply to this post by Paolo Viskanic
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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
In reply to this post by pcav
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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
In reply to this post by Paolo Viskanic
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; _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
In reply to this post by pcav
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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
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------' _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
In reply to this post by tommaso
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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
In reply to this post by Sandro Santilli
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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
In reply to this post by pcav
On Fri, Feb 24, 2012 at 7:21 AM, Paolo Cavallini <[hidden email]> 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. 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:
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:
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): 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 ------------------------------------------------------- _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
On Sat, Feb 25, 2012 at 7:01 PM, Andrea Aime <[hidden email]> wrote:
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 ------------------------------------------------------- _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
In reply to this post by pcav
>
>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) > E chi e' che finanzia qualcosa che dopo un po' è invecchiato e inutile ? Nel software GFoss , come nel software commerciale e' necessario fare aggiornamenti e manutenzioni al software. Non parlo di evoluzioni, ma anche di corrzione dei difetti riscontrati. ArcGIS esce una volta l'anno con un service pack che corregge i naturali problemi che ogni software puo' avere, quesot service pack contrariamente a quello che si puo' pensare rappresenta un valore aggiunto, perche' si sa' che ogni anno arcgis e' sempre milgiore perche' i problemi vengono risolti. Stesso concetto per il software GFoss. Anche un software GFoss ogni tanto palesa dei difetti, e come per ArcGIS questi difetti vengono scoperti e risolti con i giusti tempi. Ma se hai fatto un fork del software chi ti rimette a posto la tua versione per i bachi che non attendono alla tua modifica , ma che erano in tale versione di software gia' in partenza ? Per me salvo rarissimi casi molto particolare l'idea che un cliente che commissiona una patch possa accettare che cio' provochi un fork del prodotto e' folle. Quando uno sente il bisogno di affidarsi a qualcun'altro per farsi sviluppare delle funzionalità allora, secocondo me, chi finanzia non vuole mai che sia fatto un fork. E' contro il suo interesse. Chiunque esso sia, una pubblica amministrazione o un privato. Per cui non essendo suo interesse finanziare il fork, se il fork nasce per me' si potrebbe anche pensare che il poveretto che ha pagato il fork sia stato ingannato. Dovrebbe esserci una legge che obblighi a firmare una specifica clausola di FORK pena la nullità del contratto. Qualcosa del tipo: " Il committente riconosce e accetta che alla fine il lavoro commissionato si tradurrà n un FORK del prodotto principale. " In assenza di questa clausola in grassetto e opportunamente controfirmata il contratto dovrebbe essere nullo. Ci vorrebbe davvero una legge in questo senso. Questa e' la mia opinione ovviamente, non tutti la pensano così. Infatti ricordo che qualche anno fa', mi trovai a discutere con una persona su questioni inerenti il software GFoss . A un certo punto la discussione entro' nella questione dei forks. Io segnalavo l'opportunita che una pubblica amministrazione doveva stare attenta a non incappare nei forks dei prodotti, proprio per evitare di dover ripagare ogni anno la manutenzione della propria versione di software, ma doveva piuttosto puntare a far entrare le evoluzioni nei cores principali di sviluppo. La risposta che mi fu' detta mi spiazzo' decisamente. Infatti io ritenevo che questo fosse un concetto ovvio e condivisibile facilmente, invece mi fu' ribattuto che la PA spendeva già molto nel software commerciale e se avesse anche speso annualmente per la manutenzione di una versione forked non ci sarebbe stato niente di male e andava comunque bene. Quindi i punti di vista possono essere i più vari. -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
Free forum by Nabble | Edit this page |