Contribuir para Projetos Open-Source não é Simples
Meu Objetivo:maple_leaf:
Tenho estudado programação há alguns anos e, em 2024, decidi focar em arquitetura de software, especialmente em padrões de design, microsserviços, escalabilidade e melhores práticas para integração e entrega contínua. Minha experiência inclui criar, modificar e desenvolver scripts, além de pequenos programas que integram dois ou três scripts de maneira coesa. Por exemplo, já criei scripts para automatizar o envio de relatórios, coletar dados de APIs e realizar análises básicas de logs de sistema. Também desenvolvi programas menores para organizar arquivos e otimizar processos repetitivos. Com essa bagagem, achei que seria interessante procurar alguns projetos open-source para contribuir.
A Realidade da Contribuição:ghost:
Foi então que percebi o tamanho do desafio. Contribuir para um projeto open-source não é simplesmente chegar e sair codando. É necessário absorver uma grande quantidade de informações antes de sequer sugerir uma alteração. A complexidade do código, a documentação extensa e a necessidade de entender cada detalhe antes de contribuir tornam esse processo intenso. Para fazer um pull request, é essencial entender bem o projeto, ter uma noção clara dos seus objetivos e do fluxo geral do que está sendo proposto.
Encontrei algumas estratégias que me ajudaram a entender melhor os projetos, como começar por issues marcadas como 'good first issue', ler a documentação oficial com cuidado e explorar o histórico de commits para entender como o código evoluiu ao longo do tempo. Essas práticas ajudaram a tornar o processo de imersão um pouco mais eficiente. No entanto, ainda assim, demanda-se uma quantidade considerável de tempo para leitura e compreensão.
Reflexão sobre o Esforço:sparkler:
Contribuir para um projeto open-source me deu a sensação de estar realmente trabalhando. Não foi apenas uma questão de escrever algumas linhas de código, mas de investir uma grande quantidade de esforço, tempo e energia, além de sentir a pressão de produzir algo que outras pessoas iriam usar. Percebi que, para me dedicar a um projeto open-source, eu preciso realmente gostar do que está sendo produzido ali.
Por exemplo, eu gostaria de contribuir com projetos que envolvem automação de tarefas do dia a dia, desenvolvimento de ferramentas de análise de dados ou algo relacionado a jogos e machine learning. Esses tipos de projetos me motivam porque combinam minhas paixões e interesses pessoais com minhas habilidades técnicas. Sem essa conexão, a dedicação pode facilmente se tornar um fardo e a motivação, diminuir.
Uma Pergunta aos Programadores Mais Experientes:bird:
Gostaria de saber dos programadores mais experientes: com o tempo, esse processo de imersão nos projetos se torna mais ágil? Ou essa minha dificuldade é algo que persiste para todos que contribuem para projetos open-source? Sei que há outras maneiras de contribuir, mas aqui estou falando especificamente da contribuição com código, que envolve leitura extensiva e compreensão profunda do projeto.
Primeiro, parabéns pela iniciativa! Considero a comunidade Opensource como o meio mais rápido e efetivo de ganhar e gerar conhecimento prático e teórico. O grande problema é justamente esse que você enfrentou: o onboarding e depois o apoio técnico do dia a dia. Quando você entra como colaborador de um projeto desses não pode esperar algo como apoio pedagogico, no máximo tirar dúvidas de quem ja domina a stack e as ferramentas. Sentindo essa carência eu adotei nos meus projetos do Github justamente esse diferencial, de, se necessário, pegar pela mao, e fazer parcerias com universidades, uma vez que duas de minhas filhas lecionam em universidades publicas e me ajudam nesse processo. Fique a vontade se quiser bater um papo lá pelo Github, só abrir um issue ou já pedir pra colaborar. Vou deixar o link de apenas um projeto, o mais simples pra facilitar: https://github.com/gersonfreire/novo-cnpj
Vou relatar a minha experiência com contribuições para projetos open-source e colocar a minha visão sobre o que acho que funciona (ou deveria funcionar) o open-source.
Minha visão
Na minha visão, o open-source funciona bem quando você cria algo que resolve um problema seu e abre o código para que outras pessoas possam usufluir disso e eventualmente contribuir para melhorar o projeto. E não funciona bem quando a ideia é criar um projeto para portfolio ou produto e quer abrir o código para ter pessoas trabalhando de graça no seu projeto. O Linux é um exemplo muito claro do primeiro e o segundo caso é algo mais complicado de colocar um exemplo, mas acho que empresas que tem seu produto em cima do open-source e ficam "chateadas" com outros ganham dinheiro em cima do seu produto são exemplos (mesmo que extremados) disso, como ElasticSearch, Redis e agora WordPress.
Como eu costumo contribuir e me sinto feliz fazendo:
As vezes, usando algum aplicativo open-source, vejo um problema, crio uma issue (se for github), tento entender como funciona e se entender, crio um PR com solução e espero que seja aprovada, se não for, porque pode ser que a issue seja um dor que só eu tenha, eu uso me branch e sigo feliz, sem ressentimentos com o dono do projeto, mas muito feliz por ele ter liberado o código e permitido que eu faça minhas correções.
Quando eu acho que é frustração
Quando o projeto não te atende em nada e você só quer contribuir por autruísmo ou ego, você vai ter trabalho em entender algo que não usa só para ajudar ou ter um GitHub bonito e eventualmente vai ficar de saco cheio com uma obrigação que não te agreda em nada.
O quando você abre o código de algo que você gosta e ter o problema de ter que dar suporte ou satisfazer expectativas de uma comunidade (eu relato esse problema e o projetos como xz, openssl e Hyprland também tiveram problemas semelhantes).
Exemplos das minha contribuições:
O gerador de sites estáticos hugo tinha o nodejs desatualizado por usar o que vem com o Ubunto na sua versão Snap https://github.com/gohugoio/hugo/pull/9029
A extensão para Kubernetes do VS Code tava com problemas para colorir arquivos Helm https://github.com/vscode-kubernetes-tools/vscode-kubernetes-tools/pull/1198
Exemplo que deu errado
Em 2013/2014, eu criei um ERP e resolvi abrir o código fonte de módulos que não eram o core do meu negócio mas que ajudariam outras pessoas, minha ideia era que eventualmente esses modulos (que era trabalhosos) pudessem ter mais gente testando e eventualmente contribuindo, um desses módulos era para gerar os arquivos do SPED (a escrituração digital da Receita Federal do Brasil), o https://github.com/sped-br/python-sped.
Eventualmente, meu ERP não deu muito certo (por diversos motivos) e esse módulo virou um fardo que algumas empresas usavam (tinham integrado ele ao OpenERP/Odoo) mas quase ninguém contribuia, e deva trabalho por precisar de atualizações, cheguei a tentar transferir o repositório para outra empresa que tinha contribuido com ele, mas não foi pra frente e decidi encerrar o projeto, mas mesmo assim continuei a receber emails de gente querendo suporte por bastante tempo ainda.
Aqui fica a lição que o open-source não tem obrigação de te dar um software que atenda aos seus problemas, isso fica bem explicito em muitos licenças quando fala de não haver garantias.
Acho que você está tentando contribuir de maneira "errada". Na grande maioria das vezes você usa o projeto e encontrou um bug enquanto usava, clona o repo, arruma e faz o PR.
Nesse meu artigo, eu comento brevemente da minha última contribuição. Eu nem se quer estava procurando um bug para corrigir, só estava dando uma olhada no código.
Uma sugestão tambem pode ser você contribuir em algum projeto open-source que voce já utiliza(ou utilizou por um tempo) e que você goste, ajudar a melhorar uma coisa que você já utiliza é bem mais simples do que se aventurar em algo novo que você ainda não tenha muito conhecimento.
Se os projetos que você utilizou nao despertam muito interesse e você realmente quer contribuir em novos projetos, a dica do amigo @devjonatas de perguntar o que o projeto precisa é um bom ponto de partida.
@Estagiario, vou responder sua pergunta com base nas minhas experiências e fazer algumas considerações.
Com o tempo, esse processo de imersão nos projetos se torna mais ágil?
Sim. Pessoas mais experientes vão conseguir contribuir de maneira significativa com projetos que nunca trabalhou muito mais rapidamente do que pessoas que estão começando a jornada profissional.
Talvez a pergunta importante agora seja: como fico experiente? Para isso, recomendo fortemente a leitura do artigo aprenda a programar em dez anos.
Ainda falando de estudo, seja curioso e entenda como o código dos projetos que você utiliza direta e indiretamente funciona debaixo do capô. Leia e entenda o código das bibliotecas e frameworks que você utiliza. Seja ousado, leia o código de banco de dados, de sistemas operacionais e do que mais surgir de interesse.
Retomando a discussão sobre contribuição em projetos opensource, a maneira mais fácil e rápida é corrgir problemas. Para isso, veja se tem algum bug reportado que não foi corrigido, colabore com a discussão, reproduza o erro e proponha a correção. Outro caminho é você mesmo encontrar erros nos projetos open source que você utilizar.
Eu não sou um grande contribuidor de projetos open source, ainda assim vou deixar aqui algumas pequenas contribuições que fiz, demonstrando que é possível começar com pouco:
- Adicionei índice no banco de dados do TabNews
- Corrigi um link quebrado na documentação do Firefly, um projeto de controle de finanças pessoais
- Aumentei a cobertura de testes de um middleware do Iris, um framework web
- Corrigi uma falha para executar o script de migração do banco de dados do Sylius, uma plataforma de ecommerce
Boa sorte nos estudos e nas suas contribuições.
nas minhas experiências foi corrigir o bug escrever testes documentae e fazer pr nada demais tudo seguindo os padrões do projeto
Uma dica, entre nos canais de comunicação dos times do projeto, pode ser matrix, irc ou algum outro chat. Pergunte o que eles precisam, normalmente as pessoas são solicitas. Segundo normalmente os repositórios tem um "good first issue" normalmente são coisas que dão pra fazer antes de saber como o projeto funciona totalmente.
Eu tenho isso no meu projeto
OUtra coisa que também ajuda é traduzir ou revisar tradução da documentação.