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 [email protected] 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
