Newsgroup: it.comp.lang.c++
Titolo: Chi partecipa a progetti Open Source?

Salve, è un po di tempo che vorrei partecipare attivamente a qualche
progetto opensource.
Il tempo è poco, ma magari in questo modo si impara qualcosa da quello
che fanno gli altri, oltre ovviamente a contribuire attivamente allo
sviluppo di qualcosa a cui si crede.
Mi piacerebbe partecipare allo sviluppo di openoffice, ma non riesco
proprio a capire come si faccia .. cioè .. da dove partire .. boh !!!
idem per mozzilla thunderbird ...
Avrei bisogno di scambiare 2 parole/mail con qualcuno che lo fa
abitualmente .. che mi dia qualche spunto ...
qualcuno di voi partecipa a qualche progetto opensource?

 qualcuno di voi partecipa a qualche progetto opensource?
io ho fondato Bugzilla-it, la localizzazione italiana di Bugzilla, ma
l'ho lasciata in mano ad altri due anni fa.
Per partecipare a GROSSI progetti come quelli che hai in mente tu, ci
vuole un sacco di studio e di esperienza, soprattutto su sistemi Unix.
Lo so perch� a suo tempo ho provato anch'io a contribuire :-)
Puoi farti un p� le ossa contribuendo alle localizzazioni italiane dei
suddetti programmi.

 qualcuno di voi partecipa a qualche progetto opensource?
Sì, e ti dirò: i due progetti che hai citato sono tra quelli con la
barriera d'entrata più alta.
Se fossi in te mi darei piuttosto alla risoluzione di alcuni bachi più
semplici. Per esempio, leggi 
http://live.gnome.org/GnomeLove
 e poi
inizia a lavorare su qualcuno dei bug su
http://bugzilla.gnome.org/reports/keyword-search.cgi?keyword=gnome-love
(ci mette un po' a caricarsi).
Spero tu abbia già un po' di familiarità con i sistemi di controllo di
versione, oppure creare e applicare patch non sarà semplicissimo.
Bazaar ha un tutorial piuttosto chiaro da leggere, e anche se decidi
poi di usare git, vale la pena di darci una sfogliata per i concetti
che introduce.
http://www.bazaar-vcs.org/
Tieni conto che per contribuire a progetti opensource di un certo
calibro, è apprezzabile avere un sistema libero come GNU/Linux
funzionanete, visto che molto del focus che essi spendono è proprio
nell'assicurarsi che tutto funzioni principalmente per questi sistemi.
Devi anche imparare ad usare gli autotools, e quella è la rogna che
scoraggia molti (anche se ti dirò, a me non hanno mai creato
particolari problemi).
Se poi ti serve ancora aiuto, chiedi su it.comp.linux.development,
oppure (meglio) sulle varie mailing list dedicate al progetto che
decidi di seguire.
Cerca anche di farti un piccolo progettino per conto tuo, tipo il
famoso blocco note o una calcolatrice grafica, per imparare a usare le
Gtk+/Gtkmm (oppure le Qt+ se contribuisci a software libero collegato
al progetto KDE).
Ciao,
Matteo

 Lo so perch� a suo tempo ho provato anch'io a contribuire :-)
Uhm .. mi sa che effettivamente ho puntato troppo in alto!
Temo che sar� necesario trovare qualche cosa di piu semplice.
Grazie 

barriera d'entrata pi� alta.
La tua risposta mi conferma che ho puntato troppo in alto!
Probabilmente mi conviene scegliere una progetto piu abbordabile.
Ti ringrazio per i suggerimenti, inizio con il studiarmi il Gnomelove.
Come progetto sarebbe bello anche questo, anche se sinceramente non avevo 
inizialmente intenzione di dedicarmi al mondo linux, e avevo valutato 
openoffice o mozzilla proprio perch� pensavo fosse sufficente una pc con 
windows per partecipare.
Ho una artizione con linux installata, ma sinceramente la uso raramente, 
dovrei imparare ad usarlo bene per iniziare a scrivere software, il che 
sposterebbe il mio obiettivo, non so ..

 sposterebbe il mio obiettivo, non so ..
Assolutamente OT, ma ho sempre trovato enormemente più semplice
scrivere per sistemi liberi che non per Windows. Sarà la mia pigrizia
ad impararmi le API di Windows... ad ogni modo alcuni software del
progetto GNOME funzionano anche su Windows, impiegando comunque i
toolkit tipici del mondo GNU/Linux che sono multipiattaforma. Questo è
l'aspetto veramente positivo della faccenda: non sei particolarmente
legato al sistema per il quale sviluppi, ma hai una buona astrazione
dovuta al toolkit.
Ciao,
Matteo

 idem per mozzilla thunderbird ...
Thunderbird???????????? Manco riesco a capire il suo
makefile ma ammetto di essere parecchio in basso in
un'ipotetica scala di capacità come programmatore.
So comunque che è un progetto enorme...
-- 
"La teoria è sapere come funzionano le cose e
non sapere come farle funzionare; la pratica è
sapere come far funzionare la cose senza sapere come
funzionano; il nostro scopo è unire la pratica
alla teoria per riuscire a non far funzionare
le cose senza capire come abbiamo fatto"

 
inizia ad imparare:
qt  => se vuoi collaborare al mondo kde
gkt => se vuoi collaborare col mondo gnome/xfce
il C e la programmazione di sistema per tutti i progetti "console"
leggiti gapil e impara ad usare almeno CVS
inizia a farti le ossa con bug semplici o localizzazioni giusto per
entrare nell'ottica dei makefile etc...
Alcuni progetti alle volte cercano anche grafici o programmatori web
vedi te, non si pu� generalizzare.
mozilla e openoffice sono due pezzi di software molto complessi.
Per capirsi io per lavoro sto studiando i sorgenti di analog e conto di
iniziare a farci qualche modifica non prima di met� settembre/ottobre �
un software infinitamente pi� semplice. (se non altro perch� non
utilizza toolkit particolari, va beh � un software C ma c'� un buon 50%
e pi� di C in molti moltissimi software open)
tanto per dire...

 
Ho avuto una sensazione anche peggiore una volta che volevo 
tentare di ispirarmi semplicemente a un modulo di rendering 
HTML di firefox ... ho scaricato il codice, e manco sono 
riuscito a capire quale parte mi poteva interessare. Forse 
bisogna investirci anni prima di solo orientarcisi
ciao
Soviet

interessare. Forse bisogna investirci anni prima di solo orientarcisi
Ok .. mi avete ufficialmente terrorizzato!
A questo punto non oso immaginare cosa significhi entrare a far parte degli 
sviluppatori del kernel di linux!
Sinceramente mi aspettavo che ci fosse uno sbarramento .. ma non di certo 
cos� difficile da superare!
Ma chi sono allora gli sviluppatori? cio� .. fanno solo quello di 
professione?
Questi famosi progetti opensource sono dunque il frutto di (relativamente) 
pochi sviluppatori.
A volte ho anche pensato che un sw opensource sia piu sicuro perch� il 
sorgente � controllato e sotto l'occhio di tutti, ma se poi l'accesibilit� � 
cos� difficile, non � poi una situazione di tanto differente da un sw 
proprietario. 

 dovuta al toolkit.
Ok .. sono daccordo!
Purtroppo per linux ci sono sia le GTK+ che Qt, e gia qui uno deve scegliere 
...
Io preferivo evitare di usare i toolkit per rimanere foclizzato piu sul C 
che appunto sui toolkit 

 situazione di tanto differente da un sw proprietario.
Feci una domanda non dissimile dalla tua nel tipo di risposta
che ci si poteva attendere. Mi ï¿œ stato spiegato che in alcuni
team di lavoro per progetti grandi, esistono relativamente poche
persone che sanno tenere le fila di tutto il contesto e se
dovessero per qualche ragione abbandonarlo, il progetto si
ritroverebbe con il sedere per terra. Ovviamente - Mario: mi
basta moooolto meno per mettere in crisi me - ci vogliono anni
prima di impratichirsi. A me piï¿œ che il kernel spaventerebbe il
compilatore, ma ï¿œ questione di gusti personali :)
Io posso gestire progetti fino a un paio di mega, roba scritta
da me, che come grandezza ï¿œ minima. Ultimamente sto lavorando a
una classe parecchio critica e molto, molto impicciata con
riferimenti incrociati a classi annidate eccetera. Sto
stringendo i denti perchï¿œ quando sarï¿œ a posto e non ci lavorerï¿œ
per qualche mese, avrï¿œ scordato tutto e non sarï¿œ facile
rimetterci le mani. Sono solo io, non ho problemi con SVN o
interazione con altra gente (e deve essere una difficoltï¿œ
enorme) e sono solo 4000 linee. Non oso pensare a cose come un
grande progetto OS. Certamente la media di capacitï¿œ di gestione
sarï¿œ molto piï¿œ alta, ma questa la mia ï¿œ.
ciao!
Apx.

 sar� molto pi� alta, ma questa la mia �.
Ecco .. pensa che io faccio gia confusione scrivendo qualche Kb di firmware 
...

 abitualmente .. che mi dia qualche spunto ...
Come ti hanno già detto altri hai praticamente dichiarato di voler imparare 
a nuotare attraversando l'Atlantico...
Per cominciare potresti cercare un progettino semplice, magari già avviato 
da qualcun altro, che rispecchi i tuoi interessi.
A questo punto è difficile darti una dritta senza sapere le tue competenze 
particolari, però hai indicato applicativi da interfaccia più che da riga di 
comando. Tieni presente che senza librerie aggiuntive come Gtk e Qt non vai 
da nessuna parte, quindi te li devi imparare (se facessi senza faresti certo 
più fatica!).
Io ho un'ottima esperienza con Qt. Documentazione ottima, libreria ben 
strutturata, sistema geniale di segnali e slot (adesso c'è anche nelle 
librerie boost, Qt usa delle macro).
Tieni presente che saper usare Qt è un qualcosa che puoi mettere in bella 
vista sul CV, un buon sviluppatore Qt è molto utile soprattutto adesso che 
Qt è stato rilasciato sotto LGPL ed è aggratis anche per gli scrocconi del 
software proprietario.
Prova a fare una ricerca su 
sourceforge.net
, ci sono un sacco di progettini 
mezzi avviati. Io tempo fa ho dato una mano per l'ottimizzatore di Calc, 
un'estensione di OpenOffice.org (che al momento è inutilizzabile, perché 
riesce a far funzionare solo i sistemi lineari).
http://code.google.com/p/scsolver/
Ciao,
-Federico

 proprietario.
C'è un fondo di verità in questa tua affermazione; bisogna anche però
dire che:
a) il codice opensource è in media meglio documentato e di più facile
comprensione, visto che nessuno deve "consegnare entro venerdì e
quindi anche se scrivo spaghettate meglio, perché così le capisco solo
io e se minaccio di andarmene mi danno un aumento di stipendio per
restare"
b) c'è solo un modo per impratichirsi nel codice altrui, che è leggere
codice altrui.
Ancora ora, per progetti nuovi (per esempio, ora sto lavorando presso
un'azienda che impiega Ruby on Rails per soluzioni e-commerce),
impiego diverse settimane ad imparare ad usare nuovi toolkit o
librerie proficuamente. È una fatica che arriva col software
proprietario tanto quanto con quello opensource (se non è codice di
altre aziende è codice scritto da altri dipendenti). Il buono è che,
capiti i meccanismi di un sistema, impiego sempre meno a riconoscere
pattern in sistemi anche abbastanza diversi. Col tempo, sto imparando
ad essere abbastanza veloce e preciso nel riconoscere bachi e ad
implementare nuovi pezzi (i principi di ingegneria del software e la
conoscenza dei design pattern aiutano molto).
È un addestramento che dura anni è che è comunque destinato a chiunque
voglia fare della programmazione il suo mestiere. Non si ha mai finito
di imparare.
So quanto sia scoraggiante iniziare; io stesso non avevo mai
programmato (seriamente) prima del primo anno di università (6 anni
fa). Ora posso dire di essere un programmatore discreto; ma più vado
avanti e più mi rendo conto che programmare alla fine è "lavoro da
scimmie", date le specifiche. Ma divago.
Il punto è che ho impiegato anni a trovare l'angolo di entrata nel
mondo opensource, e questo è passato per diversi fasi:
a) ho imparato a fare il report di bug upstream in modo che sia utile
agli sviluppatori
b) ho imparato a compilarmi i programmi con le patch degli
sviluppatori e testarmele
c) ho imparato a usare i sistemi di controllo di versione
d) ho imparato a tradurre un software in bella forma e con precisione
e) ho imparato a risolvere piccoli bug nel software, o quantomeno
generare autonomamente backtrace e isolare aree del programma
imputabili
f) ho scritto qualche progetto mio, che non sempre è andato a buon
fine (anzi, spesso non ci è andato)
g) eccomi qua.
Questo per dire che, come imparare a scrivere un romanzo (bisogna fare
i pensierini alle elementari, i temi alle medie e alle superiori e via
così) o come risolvere un problema di matematica (ti servono gli
operatori che ti insegnano alle elementari - i più e i meno - e via
via logaritmi, matrici, integrali etc.), anche imparare a costruire un
qualcosa di più grande di un uomo richiede pazienza ed esperienza.
Tieni conto che nessun programmatore in media tiene a mente più di
10'000 righe di codice. Né è in grado di scrivere più di 100 righe di
codice al giorno, con una media di 3-4 bachi per uno bravo. Il kernel
di GNU/Linux è di 4 milioni di righe di codice, mi pare. Nemmeno
Torvalds lo capisce tutto.
(Devo controllare cifre e dati, spero siano giusti. Credo di averlo
letto o sul Brooks "The Mythical Man Month" o sul Sommerville
"Software Engineering"; se trovate un errore in queste cifre o nelle
fonti vi ringrazio se riuscite a correggermi).
È il bello dello sforzo condiviso: nessun uomo da solo può costruire
una piramide egizia. Ma in 100... (e il tempo richiesto NON si divide
per 100, così come troppi cuochi rovinano la cucina).
Ciao,
Matteo
PS. spezzo una lancia a favore delle Gtk+. Stanno veramente maturando
molto in questo periodo, sono ben documentate, anche la controparte in
C++ funziona bene, e non hanno bisogno di un giro con il preprocessore
moc. Riconosco l'estrema validità delle Qt+, ma 26 Mb mi sembrano un
po' troppi per i miei gusti, e non mi piace troppo la sintassi che
hanno. In più, trovo le Gtk+ esteticamente più belle. Comunque, de
gustibus. Non voglio scatenare flame war, che sono tra l'altro OT.

 > Questo è l'aspetto veramente positivo della faccenda: non sei

Quando mi capita di partecipare alle selezioni per nuovi posti di
lavoro per programmatori come esaminatore, valuto di gran lunga di più
la conoscenza delle API di un particolare toolkit che ci serve in
azienda, che non di un particolare linguaggio.
Il lavoro del programmatore è perlopiù conoscere le API. Brutto, ma è
così. Se uno le conosce, puoi sbatterlo subito al lavoro; al massimo
impara un po' ad usare il linguaggio e in un paio di settimane se è
bravo produce codice passabile. Altrimenti, ci vogliono mesi prima che
sia produttivo.
Prendi Java: se uno mi dice "conosco il linguaggio Java e il
linguaggio C++ dall'università, ho preso trenta e lode nei due corsi",
e un altro mi dice "conosco il linguaggio Java così così, ma ho molta
familiarità con la libreria standard", *senza altri metri di misura*
(e ce ne sono tanti), propendo per il secondo.
Ciao,
Matteo

 cos�.
Sono daccordo!
Specialmente considerando la complesit� dei toolkit/framework/API che 
abbiamo a disposizione!
L'importante a questo punto � che il programmatore/studente scelga quello 
giusto su cui investire e speializzarsi. 

 sia produttivo.
Questo riecheggia una mia convinzione che sto maturando da un p�.
Ora vanno di moda gli oggetti, e le nuove tecnologie software sono "a 
oggetti", perfino i sistemi operativi (scetticismo). E quando uno va a 
vedere come si usano ste nuove tecnologie trova pagine e pagine di 
chiacchiere che descrivono a che serve l'oggetto X, perch� � stato 
creato l'oggetto Y, quale gravissimo problema risolve l'oggetto Z... 
alla fine, ma MOLTO alla fine, arriva l'elenco dei metodi e delle 
propriet� dei suddetti oggetti, spesso incompleto e frammentario... 
tanto che se voglio veramente sapere come funge e come si usa la 
tecnologia XYZ l'unica � mettermi l� a provare, o vedermi gli esempi 
forniti (le volte che ci sono).
Insomma visto che tanto alla fine gli "oggetti" non sono altro che delle 
raccolte di funzioni e variabili, perch� cavolo non ci fate una bella 
lista di tutto, con i parametri e i loro tipi e quello che fanno??? Ma 
no, c'� da parlare degli oggetti... ormai quando leggo di "oggetti" 
nella documentazione lo considero solo fumo negli occhi. E mi viene il 
latte alle ginocchia.

 lista di tutto, con i parametri e i loro tipi e quello che fanno???
Ben, c'� un libro del genere per il framework .NET .. ma alla fine cosa te 
nei fai?
Il framework viene aggiornato spesso, dovresti ricomprare il libro ogni 
volta.
Inoltre se devi usare l'oggetto, con l'help in linea hai esempi e 
spiegazioni.
Non credo sia utile 1 libro.
Tuttavia una visione generale del framework, di quali siano gli oggetti + 
importanti, quali conviene usare e quando, dei pattern di esempio ecc .. 
potrebbe essere utile. 

>Il lavoro del programmatore � perlopi� conoscere le API. Brutto, ma � cos�
Andr� a finire che solo chi scive i toolkit, i framework ecc... sar� un vero 
programmatore.
Gli altri saranno programmatori-user 

 proprietario.
In effetti la differenza, da questo punto di vista, non � moltissima ma c'�, 
dato che i programmatori in grado di occuparsi del software opensource 
esistono, anche se sono pochi.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg
The EMG Music page:         
http://www.emagsoftware.it/emgmusic
 

 con una media di 3-4 bachi per uno bravo.
Un baco ogni 25 righe scritte mi sembra troppo. Naturalmente non considero 
gli errori rilevati alla compilazione come bachi.


 azienda, che non di un particolare linguaggio.
A me questo non sembra un buon criterio. Sono quasi certo che alla lunga non 
paghi.


 raccolte di funzioni e variabili
Hai una visione piuttosto riduttiva della programmazione ad oggetti.
-- 
-riko


Ho specificato chiaramente che intendevo in mancanza di altre metriche
(e sono tante).
M.


Ho controllato, e la media in effetti è più bassa; tra 15 e 20 per
1'000 righe di codice. Pardòn.
Ciao,
Matteo

 altre metriche (e sono tante).
Se comunque alla conoscenza di una particolare libreria viene data pi� 
importanza della conoscenza del linguaggio di programmazione allora continuo 
a non essere d'accordo. Come si pu� utilizzare una libreria se non si 
conosce prima bene il linguaggio?


 1'000 righe di codice. Pard�n.
Continuano a sembrarmi troppi. Ma stiamo parlando di codice sviluppato da 
programmatori come si deve o da "spaghetti coders"?


 prima bene il linguaggio?
Oddio, da non addetto ai lavori mi verrebbe la
battuta che alle volte una libreria iper-sofisticata
potrebbe servire a evitare di dover conoscere bene
il linguaggio. So che è come dici tu, ma c'è, forse,
una stretta zona di sovrapposizione in cui le
librerie possono parzialmente sopperire. Comunque è
più che altro una battuta...
ciao
Apx.


 sviluppo di qualcosa a cui si crede.
Non programmo direttamente ma seguo molto da vicino lo sviluppo di alcuni 
programmi liberi della famiglia di KDE (
http://kde.org/
), prevalentemente 
invio bug report, partecipo a discussioni in diverse mailing list e faccio 
traduzioni, anche se ogni tanto una sbirciatina al codice gliela dò...
Ti posso garantire che è molto facile (e incoraggiato: 
http://kde.org/getinvolved/
) collaborare con la comunità attorno a KDE 
(immagino sia ugualmente facile collaborare con Gnome), c'è un mucchio di 
gente simpatica disposta ad aiutarti e ci sono infinite mailing list, canali 
IRC, forum, etc per chi vuole contribuire a parti del progetto. 
Inoltre c'è una ragionevole quantità di documentazione che ti spiega come 
cominciare a contribuire.
Per come è concepito KDE, molto modulare, ci sono un'infinità di piccoli 
programmi che fanno cose utili nell'ambiente desktop, e perciò puoi partire 
da qualcuno di essi per lavorare a qualcosa di inizialmente semplice ma 
comunque utile e farti un po' di esperienza. Vedi:
http://kde.org/getinvolved/development/
Non conosco l'ecosistema ;-) di Gnome, ma mi aspetto che sia molto simile e 
altrettanto accogliente.
in bocca al lupo
gerlos
-- 
"Solo lo scienziato è vero poeta: ci dà la luna, ci promette le stelle,
 ci farà un nuovo universo se sarà il caso."
                 < 
http://gerlos.altervista.org
 >
 gerlos  +- - - >  gnu/linux registred user #311588