[pugMI] Progetti open source

[Gaetano Giunta]

Mirko Benedetti wrote:
> Salve mailing list,
> vorrei chiedere se qualcuno conosce dei progetti open source a cui potersi unire
> per cominciare a scivere codice 'sul serio' o anche per vedere un po' di codice
> scritto professionalmente, eventualmente qualcuno di voi ha un
> progetto su github (open)
> che si può clonare ed eventualmente è aperto a delle domande.

Probabilmente in lista ci sono + persone che hanno uno o + progetti opensource "loro".
Io p.e. gestisco la libreria phpxmlrpc (su sf.net con svn, non migrata ancora su git) e una vagonata di plugins per eZPublish (su https://github.com/gggeek/).
Non so quanto la prima sia ancora di utilità generale, nell'epoca del REST imperante, e quanto i secondi possano interessare chi non utilizza quel CMS...

Approvo pienamente lo spirito che anima la volontà di "cominciare a collaborare con progetti open source": serve per rimpolpare il curriculum, per migliorare le 
proprie comptenze, per conoscere persone spesso intelligenti ed interessanti e stringere anche qualche legame - perlopiù virtuale, ma non necessariamente.

Aneddoto tratto dalla storia personale: per aver aperto vari bachi php relativi al connettore oracle, collaborato a debuggare il supporto ad oracle della 
libreria adodb e bazzicato in maniera sporadica la mailing list php internals, ho conosciuto lo sviluppatore che manutiene il connettore php-oracle in quanto 
dipendente full-time della casa del database. Quando ho avuto bisogno di consigli di livello "guru" relativi ad una analisi ed ottimizzazione di una 
configurazione perniciosa, il buon Christopher mi ha supportato con una prolungata discussione via mail e persino due ore di conference call - senza avere 
nessun rapporto di tipo contrattuale.

Riguardo alla scelta del progetto: io ho sempre cominciato la mia partecipazione a progetti che utilizzavo, e nel 95% dei casi si è trattato di apertura di bug, 
seguiti se possibile da invio di patch. In ogni caso anche l'analisi dettagliata delle cause di un baco porta valore al progetto, ed è in genere ben accolta 
dagli autori (il discorso è molto diverso per quanto riguarda la scelta della migliore strategia correttiva e l'insistenza degli utenti che ritengono che il 
proprio baco sia quello più importante tra tutti o che la propria patch sia la migliore).
Non so se scegliere un progetto in base a criteri astratti sia la scelta giusta - sicuramente i progetti che usi tutti i giorni sono quelli che ti motivano di + 
a partecipare.
Per quanto riguarda la scrittura di documentazione, non bisogna sottovalutare la complessità di questa attività: spesso ci sono standard da seguire e aree 
specifiche da coprire, e se non si è mai utilizzato lo strumento in questione si rischia di avere un punto di vista diverso rispetto agli altri sviluppatori ed 
utilizzatori e utilizzare metafore inadatte se non dire cose completamente errate.
La traduzione di documentazione esistente invece non dovrebbe presentare difficoltà specifiche, e non riesco ad immaginare alcun motivo per cui la community 
esistente possa non apprezzare un tale "regalo dal cielo".
Un'altra attività spesso "ingrata", non complessissima e che beneficia sempre dell'apporto di braccia fresche è il triaging dei bachi aperti, specialmente per i 
progetti grandi che hanno sempre bug trackers intasati da migliaia di issues storiche e nessuno che sappia dire se sono ancora valide per la release + recente.

Ciao
Gaetano

ps: la community di eZ Publish ha disperato bisogno di menti nuove...

>
> Credo che la migliore forma di crescita per noi che ci affacciamo da
> poco alla programmazione
> professionale sia scrivere codice.
>
> Grazie in anticipo a tutti,
>
> Mirko Benedetti
> _______________________________________________
> Milano mailing list
> Milano a ml.grusp.org
> http://ml.grusp.org/listinfo.cgi/milano-grusp.org
>