[PT-BR] O que aprendi em (quase) um ano de Open-Source

This post is also available in English

Há cerca de um ano, decidi dedicar parte do meu tempo livre contribuindo com projetos de código aberto (também conhecidos como open-source). A ideia era melhorar minhas habilidades de desenvolvimento e ter contato com novas tecnologias e frameworks. Aprendi muito nessa época e gostaria de compartilhar com vocês algumas dicas que gostaria que alguém tivesse me contado quando eu estava começando.

Aqui está um resumo das dicas, se você for mais adepto do tl;dr;

1. Comece pequeno, aprenda os fluxos do Git e do Github antes de mergulhar em projetos complexos
2. Pesquise por "good first issue" ou tags equivalentes nos projetos com os quais deseja contribuir e comece por essas tarefas
3. Não tenha medo do feedback que você recebe sobre seus PRs
4. Você pode criar e gerenciar um projeto sozinho
5. Participe ou crie uma comunidade para tópicos relacionados ao open-source
6. Lembre-se de se divertir

O amanhecer do open-source (para mim)

Achei uma boa ideia começar por um dos serviços ou aplicativos que eu usava diariamente, já que muitos deles eram de código aberto, e isso pessoal, foi meu primeiro erro. Eu me deparei com uma base de código realmente grande e assustadora de Software como Inkscape e Gimp, sobrecarregada por todos aqueles componentes e infraestrutura complexa não tão documentada.
Fiquei desmotivada com a quantidade de esforço que estava colocando para tentar entender o código e não ser capaz de progredir em tarefas simples, então precisei mudar minha abordagem.

Passos de bebê

Percebi que havia mais coisas que eu precisava aprender além do código de um projeto em si: eu precisava aprender Git de verdade e também entender melhor como o Github, a principal plataforma para projetos de código aberto, funcionava.
Então comecei a procurar projetos menores, especialmente aqueles focados em documentar coisas ou precisando de trabalho de localização (tradução de textos de software para outros idiomas). Normalmente, quando o repositório tem esses objetivos, você não precisa se preocupar em compilar o código, o que simplifica bastante o fluxo.
Aqui está minha primeira dica: comece pequeno, pegue o jeito das ferramentas como Git, entenda o que são solicitações de pull (PRs) e aprenda como funciona o fluxo.

Boa primeira tarefa

Depois de dominar a plataforma (Github) e a ferramenta (Git), pude ir atrás de problemas que exigiriam um bater de tecla mais "real". Por já estar familiarizado com o Github, sabia que alguns dos projetos têm tags como "good first issue", que rastreiam tarefas menores e mais simples. Normalmente, esses repositórios são mais recepitivos a novos contribuidores e com melhor documentação sobre como compilar e testar o código. Dica número 2: procure por "good first issue" ou labels equivalentes nos projetos com os quais deseja contribuir e comece com eles.

Solicitações de mudança NÃO são seus inimigos

Depois de um tempo, estava me sentindo muito bem com meu progresso e contribuições, ja mergulhava em projetos mais complexos a cada semana, melhorando e fortalecendo minha presença em vários desses projetos. Minha confiança (que geralmente é muito baixa - tenho que trabalhar nisso) estava lá em cima, mas mesmo assim, em cada PR (pull request) que enviava, eu ficava nervosa em expor meu trabalho (potencialmente ruim), para outros revisarem.
No meu dia-a-dia no trabalho, enviar revisões é algo que não temo mais, pois conheço a maioria das pessoas que revisam meu código e sou bastante confiante em relação as minhas habilidades de programaçao e estilo para o projeto em que trabalho. Eu sei que (quase) todos os problemas que alguém abre no meu código têm o objetivo de tornar o software melhor e podem me ensinar algo novo, mas eu não estava aplicando isso no open-source, e isso estava me segurando.
Terceira dica: não tenha medo do feedback que você recebe, aprenda com eles.

O outro lado

Depois de alguns meses, percebi a necessidade de um software simples que me ajudasse a controlar minhas horas de trabalho e, como estava profundamente envolvida com o open-source, por que não torná-lo um projeto no Github?! Assim nasceu a Time to Leave e me permitiu vivenciar o outro lado do Github, gerenciando um projeto que recebe a contribuição de pessoas ao redor do mundo. Toda essa experiência merece um post só por isso, mas vou deixar aqui a próxima dica: se ninguém fez o que você quer, então, construa você mesmo.

Com uma pequena grande ajuda dos meus amigos

A principal coisa que me motiva até hoje a continuar e a descobrir coisas novas é que encontrei muitos amigos que se são tão entusiasmados com o código aberto quanto eu. Criamos grupos nos quais compartilhamos projetos que achamos interessantes, discutimos fluxos e problemas de desenvolvimento e incentivamos as pessoas que desejam começar a realmente fazê-lo.
Então, minha próxima dica é para que você encontre pessoas e comunidades que compartilham seu interesse em código aberto e desenvolvimento. Eles podem ser colegas de trabalho ou faculdade, ou até mesmo estranhos no Twitter e em canais do Discord.

Faça valer a pena

Minha dica final para você é não se esqueça de se divertir! Contribuir com código aberto é usar seu tempo livre. Nem todo o trabalho que você faz precisa ter uma meta que faça seu lado profissional parecer melhor. Às vezes, você só quer se divertir e contribuir com um projeto que não se encaixa no seu padrão, e isso é totalmente aceitavel!