• Inizia in piccolo e inizia con la documentazione, i test e altre attività che ti consentono di entrare nella cultura del progetto open source.

• Le barriere includono la mancanza di documentazione, nessun avvio rapido per gli sviluppatori, nessun mentore e nessun problema specifico per i neofiti da affrontare.

Così ho iniziato su PCGen di:

• Metti in ordine alcuni dei documenti, il che mi ha dato molti complimenti dal resto dei contributori (a nessuno piace i documenti).

• Fornire brevi casi di test semplici per i problemi

• Essere una voce amica nella comunità (rispondendo a semplici Q, costruendo una FAQ ecc.)

• per aiutare a triage bug / problemi etc

Dopo 2 mesi che ero parte della community, ho capito come i vari bit si connettevano e avevo contribuito a una guida di avvio per sviluppatori che ho seguito per ottenere un ambiente di sviluppo locale completamente funzionante.

• Ho quindi passato il tempo a individuare bug di basso livello, quindi mi sono abituato allo stile di codifica, a come inviare patch ecc.

Dopo sono entrato nella roba del meater e il resto è una lunga storia noiosa su di me, quindi mi fermo qui:).

Ho iniziato nel progetto Mozilla quasi due anni fa. Sono stato assunto l'estate scorsa dalla Mozilla Corporation come stagista e ora sono un "peer di moduli", nel senso che ho una certa responsabilità per una certa parte del progetto e faccio recensioni di codice per questo (nel mio caso, il sistema di compilazione) . Immagino che questa posizione come contributore rispettata per un grande progetto è dove vuoi essere, quindi spero che la mia storia sia utile.

Entrare nello sviluppo dell'open source era qualcosa che avrei voluto fare per un po ', ma qualcosa che non avrei mai potuto fare. Ho iniziato riparando un bug quasi insignificante. Risolto il bug che mi insegnava come costruire Mozilla (su molti grandi progetti open source, la costruzione del progetto non è banale), navigare bugzilla, ottenere patch revisionate e commesse, ecc. Ho corretto alcuni bug più banali prima di affrontare il mio primo disco bug.

Senza entrare troppo nei dettagli ho passato un paio di settimane su un bug piuttosto sgradevole che richiedeva di scavare attraverso alcuni driver di terze parti e venire con gli hack per mantenerli funzionanti, e quindi modificare il nostro codice di hacking per correggere regressioni e altri problemi . Questo è stato il primo bug che ho risolto nel percorso critico di una release ed è stata una grande esperienza. Il momento era un po 'fortuito; Mi è capitato di avere l'hardware pertinente e il tempo di impegnarsi (durante l'estate all'università, quindi ho avuto un sacco di tempo libero).

Ho passato molto tempo a rintracciare le conseguenze di quel bug e poi da lì ho passato un pò di tempo a trascinare il codice di Windows perché ho trovato molto più facile hackerare il codice che aveva interazioni molto ben definite con altri pezzi di codice. Alla fine mi sono intrufolato in alcuni lavori di performance (perché costruire Mozilla su Windows è così slooooow). Col tempo sono diventato abbastanza competente nella base di codice per lavorare su importanti refactoring e aggiungere funzionalità sia in C ++ che in make e ho contribuito con patch abbastanza frequentemente che mi è stato dato l'accesso diretto al commit.

Il problema principale in cui mi sono imbattuto era la mancanza di documentazione. La maggior parte dei progetti open source sono sfortunatamente documentati. Questo è uno dei motivi per cui all'inizio ho trovato più facile hackerare codice in cui un "lato" se è stato ben definito da MSDN.

Il problema secondario era trovare i bug su cui lavorare. Trovare un bug che sia abbastanza stimolante da essere interessante ma non richieda una conoscenza approfondita della base di codice è generalmente difficile in Mozilla. Mozilla ha una lista di buoni primi bug che sono generalmente decenti, anche se a volte si tratta di una discarica per cambiamenti banali o progetti a cui nessuno si interessa abbastanza da affrontare. Se sei interessato a Mozilla in particolare, accedi alla nostra rete irc in #developers e chiedi in giro o ping a "khuey" e troveremo qualcosa per te. Probabilmente altri progetti hanno simili guide "introduttive" o persone che possono aiutarti a guidarti.

Un avvertimento: ho avuto il vantaggio di essere già competente in C ++. Se stai provando ad iniziare un progetto in cui non conosci la lingua (o una lingua strettamente correlata) potresti trovarla sostanzialmente più difficile.

Pubblicherei più link ma non permetterò ai nuovi utenti di farlo, quindi ne ho lasciato uno più importante.

Potresti voler contribuire al software OSS che usi ogni giorno. Guarda quali dei tuoi strumenti sono open source e se c'è qualcosa che ti piacerebbe migliorare in questi. Quindi vedi se c'è qualcosa che puoi fare al riguardo. Due piccioni con una fava: migliori i tuoi strumenti E contribuisci alla comunità OSS.

Hai bisogno di una community strong prima di avere un strong impulso da parte degli sviluppatori.

Guarda questo discorso di Jono Bacon chiamato I motori della comunità , penso ha anche un libro su questo.

I modi per raggiungere questo obiettivo è utilizzare Google Gruppi (è facile per la comunità rimanere connessi tramite email) e anche ospitare e mantenere il tuo codice in un posto come github o bitbucket . Un forum (SMF, MyBB, phpBB) può essere uno strumento abbastanza utile.

Penso che tutte le risposte alle tue domande siano in questo libro: link È gratis leggere online. Lo sto leggendo al momento per quasi le stesse domande. È sicuramente un'ottima fonte di informazioni sull'argomento.

Tutti i miei contributi a progetti open source piuttosto ampi provengono da cose avevo bisogno di me stesso . Non sono mai uscito e ho detto, "hey, ho così tanto tempo libero, voglio contribuire a qualcosa, dove posso candidarmi?"

Ho iniziato esaminando la sezione di richiesta di aiuto di sourceforge. Cercherei progetti che richiedessero le mie capacità, ma di solito si tratterebbe di progetti in cui potrei sviluppare alcune abilità di cui avevo tanto bisogno.

La prossima cosa che farei è imparare a configurare il codice base e far funzionare una copia di lavoro.

Quindi prova a capire un flusso di lavoro completo end to end. In questo modo capirò come il codice è scritto e sarei tranquillo assicurato che lo stesso modello sarebbe usato in altri flussi di lavoro. Per modello intendo cose come l'azione - > servizio - > dao ecc.

Quindi cercherò di trovare bug relativi al flusso di lavoro che ho appena compreso e provo a scrivere una correzione. Prima cercavo i test unitari scritti per il flusso di lavoro (se non ce n'è ne vorrei scriverne uno io stesso)

Quindi la prossima cosa sarebbe ottenere l'ultimo tizio che aveva commesso il codice nel particolare modulo per rivedere la mia correzione.

Le discussioni che seguiranno aiuteranno sicuramente ad aumentare la tua comprensione su molte cose.

Ora hai avuto un buon inizio e ben consapevole di almeno una piccola parte particolare del progetto. Prendi il controllo di esso e prova a scavare / ramificarti in altre aree.

Inoltre, come molti hanno già detto prima, prova a documentare tutto ciò che trovi e fallo rivedere dalla persona che ha commesso l'ultima parte del codice.

Queste sono le mie piccole pepite, buona fortuna. Buon codice.

Saluti, Goutham Rao