É ruim participar de projetos de código aberto como amador?

Há seis meses, penso que devo ingressar em um projeto de código aberto para iPhone ou iPad para aprimorar minhas habilidades no Objective-C, mas toda vez que faço isso, vejo milhares de linhas de código em grandes projetos que eu acabo me convencendo de que nunca entenderia. Eu sempre acho que meus commits acabariam sendo um aborrecimento para administradores de projetos e contribuidores mais experientes, então eu sempre recuo no último segundo.

Minha pergunta é essencialmente: é um aborrecimento quando um programador com experiência intermediária ingressa em um projeto de código aberto?

Não, não é.

Se a base de código dos projetos que você vê for muito assustadora, considere:

• Escolhendo um projeto (ainda) menor para trabalhar.
• Escolha uma tarefa menor dentro do projeto:
  • Escreva um exemplo / tutorial / demo para algo
  • Atualizar e corrigir documentação (todos os projetos, SO ou não, precisam de documentos melhores)
  • Corrija muitos bugs de baixa prioridade, mas fáceis de corrigir (ótima exposição ao código, os desenvolvedores geralmente são felizes, baixo risco)
• Existem maneiras de contribuir sem confirmar o acesso à fonte principal, como:
  • Enviando patches, que podem ser comentados.
  • Bifurcação e envio de solicitações pull (veja acima)
  • Bifurcando-se e trabalhando sozinho, apenas para ver aonde isso o leva. Se você estiver feliz, peça aos desenvolvedores que vejam o que você fez para ver se faz sentido.

Para superar o seu "medo" de não ter seus commits aceitos, procure pontos seguros primeiro. Isso permitirá que você e a equipe de desenvolvimento ganhem confiança em seu relacionamento e aprendam o modo de pensar um do outro. À medida que você melhora (tanto em habilidade, experiência, qualidade do código e compreensão da equipe do seu projeto do SO quanto em sua dinâmica), você será capaz de lidar com tarefas maiores e, ao mesmo tempo, com menos problemas.

Também ajuda a pedir pontos de partida adequados e a ver o que a equipe pode achar adequado para você.

Como exemplo, eu contribuí um pouco para o Buildbot ao longo dos anos. Comecei apenas a corrigir alguns pequenos problemas e, em seguida, aprimorei a qualidade das etapas de origem do Mercurial, corrigindo alguns erros flagrantes. Por fim, reescrevi a maioria das páginas da Web e troquei a colagem de html no código para uma solução de geração de HTML baseada em modelo. O último foi algumas centenas de commits ao longo de alguns meses de trabalho duro.

Também fiz alguns trabalhos da Mercurial, mas esses caras são mais exigentes e a tecnologia é mais complicada, por isso ainda não consegui nenhuma correção no núcleo. Fiz alguns relatórios de erros e escrevi algumas pequenas extensões, mas não consegui nada maior no momento.

Espero que ajude.

Participe. Monitore as listas de desenvolvimento por um tempo e apresente-se quando se sentir confortável. Muitos projetos têm trabalhos mais fáceis em correção de erros ou documentação que os regulares terão prazer em apontar para você. A maioria dos projetos é bastante amigável para as novas mãos, e eles o ensinam a trabalhar rápido o suficiente para que você possa se tornar um ativo real do projeto.

Depois de um tempo, você estará familiarizado com a estrutura e as partes mais importantes da base de código. Aprender a entender códigos como esse é uma parte realmente importante da programação, e o código aberto é uma ótima maneira de aprendê-lo.

Vá em frente. Há muitos iniciantes fazendo o mesmo. O líder do projeto pode ajudar a encontrar coisas para você trabalhar e que não estão fora do seu alcance. Você gradualmente cresce para o resto.

Ah, e só porque você não entende o código não significa que é bom . Eu vi algum código seriamente horrível por aí. Algumas delas são difíceis de entender porque são mal escritas e feitas para serem muito mais complexas do que deveriam ser.