Por que contribuir para o open source?

Contribuir para o open source pode ser uma maneira gratificante de aprender, ensinar e construir experiência em praticamente qualquer habilidade que você possa imaginar.

Por que as pessoas contribuem para o open source? Há muitas razões!

Melhorar as habilidades existentes

Seja codificando, desenhando interface do usuário, desenhando gráfico, escrevendo ou organizando, se você está procurando por prática, há uma tarefa para você em um projeto open source.

Encontre pessoas que estão interessadas em coisas parecidas

Projetos open source com comunidades calorosas e acolhedoras mantêm as pessoas voltando por anos. Muitas pessoas formam amizades duradouras através da participação em open source, seja em reuniões, em conferências ou conversas online sobre burritos.

Encontre mentores e ensine outras pessoas

Trabalhar com outras pessoas em um projeto compartilhado significa que você terá que explicar como você faz as coisas, além de pedir ajuda a outras pessoas. Os atos de aprendizagem e ensino podem ser uma atividade gratificante para todos os envolvidos.

Construa artefatos públicos que ajudam você a crescer sua reputação (e uma carreira)

Por definição, todo o seu trabalho open source é público, o que significa que você recebe exemplos gratuitos para levar a qualquer lugar como uma demonstração do que você pode fazer.

Aprenda habilidades interpessoais

O open source oferece oportunidades para praticar habilidades de liderança e gerenciamento, como resolver conflitos, organizar equipes de pessoas e priorizar o trabalho.

É empoderador poder fazer mudanças, mesmo pequenas

Você não precisa se tornar um contribuidor vitalício para participar no open source. Você já viu um erro de digitação em um site e desejou que alguém o consertasse? Em um projeto open source, você pode fazer exatamente isso. O open source ajuda as pessoas a sentirem propósito sobre suas vidas e como elas experimentam o mundo, e isso em si é gratificante.

O que significa contribuir

Se você é um novo contribuidor open source, o processo pode ser intimidador. Como você encontra o projeto certo? E se você não souber codificar? E se algo der errado?

Não se preocupe! Há todo tipo de maneiras de se envolver com um projeto open source, e algumas dicas ajudarão você a aproveitar ao máximo sua experiência.

Você não precisa contribuir com código

Um equívoco comum sobre contribuir para o open source é que você precisa contribuir com código. Na verdade, muitas vezes são as outras partes de um projeto que são mais negligenciadas ou esquecidas. Você fará um grande favor ao projeto, oferecendo-se para contribuir com esses tipos de contribuições!

Mesmo se você gosta de escrever código, outros tipos de contribuições são uma ótima maneira de se envolver com um projeto e conhecer outros membros da comunidade. Construir esses relacionamentos lhe dará oportunidades de trabalhar em outras partes do projeto.

Você gosta de planejar eventos?

  • Organize workshops ou encontros sobre o projeto, como @fzamperin fez para NodeSchool
  • Organize a conferência do projeto (se eles tiverem uma)
  • Ajude os membros da comunidade a encontrar as conferências apropriadas e a submeter propostas de apresentação

Você gosta de design?

  • Reestruture layouts para melhorar a usabilidade do projeto
  • Realize pesquisas de usuário para reorganizar e refinar a navegação ou menu do projeto, como sugere o Drupal
  • Coloque junto um guia de estilo para ajudar o projeto a ter um design visual consistente
  • Crie arte para camisetas ou um novo logotipo, como os contribuidores do hapi.js fizeram

Você gosta de escrever?

  • Escreva e melhore a documentação do projeto
  • Organize uma pasta de exemplos mostrando como o projeto é usado
  • Inicie uma newsletter para o projeto ou selecione resumos da lista de discussão
  • Escreva tutoriais para o projeto, como os contribuidores do PyPA fizeram
  • Escreva uma tradução para a documentação do projeto

Você gosta de organizar?

  • Crie links para issues duplicadas, e sugira novos labels para issues, para manter as coisas organizadas
  • Revise as issues abertas e sugira o fechamento das antigas, como @nzakas fez para o ESLint
  • Faça perguntas de esclarecimento sobre issues abertas recentemente, para dar continuidade a discussão.

Você gosta de codificar?

  • Encontre um problema em aberto para resolver, como @dianjin fez para o Leaflet
  • Pergunte se você pode ajudar a codificar uma nova função
  • Automatize a configuração do projeto
  • Melhore as ferramentas e os testes

Você gosta de ajudar as pessoas?

  • Responda a perguntas sobre o projeto, por exemplo no Stack Overflow (como este exemplo do Postgres) ou Reddit
  • Responda as pessoas, em questões que ainda estão abertas
  • Ajude a moderar os painéis de discussão ou os canais de comunicação.

Você gosta de ajudar os outros a codificar?

Você não precisa apenas trabalhar em projetos de software!

Embora “open source” geralmente se refira a software, você pode colaborar em praticamente qualquer coisa. Existem livros, receitas, listas e aulas que são desenvolvidos como projetos open source.

Por exemplo:

Mesmo que você seja um desenvolvedor de software, trabalhar na documentação de um projeto pode ajudá-lo a começar no open source. Geralmente, é menos intimidador trabalhar em projetos que não envolvam código, e o processo de colaboração aumentará sua confiança e experiência.

Se orientando para um novo projeto

Para qualquer outra coisa além de um erro de digitação, contribuir para o open source é como caminhar até um grupo de estranhos em uma festa. Se você começar a falar sobre lhamas, enquanto eles estavam mergulhados em uma discussão sobre peixinhos dourados, eles provavelmente olharão para você um pouco estranhamente.

Antes de pular cegamente com suas próprias sugestões, comece aprendendo a ler o ambiente. Isso aumenta as chances de que suas ideias sejam notadas e ouvidas.

Anatomia de um projeto open source

Toda comunidade open source é diferente.

Passar anos em um projeto open source significa que você conheceu um projeto open source. Mude para um projeto diferente, e você pode achar que o vocabulário, as normas e os estilos de comunicação são completamente diferentes.

Dito isso, muitos projetos open source seguem uma estrutura organizacional similar. Entender os diferentes papéis da comunidade e o processo geral ajudará você a se orientar rapidamente em qualquer novo projeto.

Um típico projeto open source tem os seguintes tipos de pessoas:

  • Autor: A pessoa ou organização que criou o projeto
  • Proprietário: Pessoa(s) que tem propriedade administrativa sobre a organização ou repositório (nem sempre é o autor original)
  • Mantenedores: Colaboradores que são responsáveis por conduzir a visão e gerenciar os aspectos organizacionais do projeto. (Eles também podem ser autores ou proprietários do projeto.)
  • Colaboradores: Todos que contribuíram com algo para o projeto.
  • Membros da comunidade: Pessoas que usam o projeto. Eles podem ser ativos em diálogos ou expressar sua opinião sobre a direção do projeto.

Projetos maiores também podem ter subcomitês ou grupos de trabalho focados em tarefas diferentes, como ferramentas, triagem, moderação da comunidade e organização de eventos. Procure no site do projeto uma página “equipe” ou no repositório procure por documentação sobre governança, para encontrar essas informações.

Um projeto também possui documentação. Esses arquivos são geralmente listados no nível superior de um repositório.

  • LICENSE: Por definição, todo projeto open source deve ter uma licença open source. Se o projeto não tiver uma licença, não é open source.
  • README: O README é o manual de instruções que dá as boas-vindas aos novos membros da comunidade para o projeto. Isso explica por que o projeto é útil e como começar.
  • CONTRIBUTING: Enquanto os READMEs ajudam as pessoas a usar o projeto, os documentos sobre contribuição ajudam as pessoas a contribuir para o projeto. Ele explica quais tipos de contribuições são necessários e como o processo funciona. Embora nem todo projeto tenha um arquivo CONTRIBUTING, sua presença sinaliza que este é um projeto acolhedor a novas contribuições.
  • CODE_OF_CONDUCT: O código de conduta estabelece as regras básicas para o comportamento dos participantes e ajuda a facilitar um ambiente amigável e acolhedor. Embora nem todo projeto tenha um arquivo CODE_OF_CONDUCT, sua presença indica que este é um projeto acolhedor a novas contribuições.
  • Outros documentos: Pode haver documentação adicional, como tutoriais, instruções passo a passo ou políticas de controle, especialmente em projetos maiores.

Por fim, os projetos open source usam as seguintes ferramentas para organizar a discussão. Ao ler os arquivos, você terá uma boa ideia de como a comunidade pensa e trabalha.

  • Issue tracker: Onde as pessoas discutem issues relacionadas ao projeto.
  • Pull requests: Onde as pessoas discutem e revisam as alterações que estão em andamento.
  • Fóruns de discussão ou listas de discussão: Alguns projetos usam esses canais para tópicos de conversação (por exemplo, “Como faço para …“ ou “O que você acha sobre …“ em vez de relatórios de bugs ou solicitações de recursos). Outros usam o issue tracker para todas as conversas.
  • Canais de bate-papo: Alguns projetos usam canais de bate-papo (como o Slack ou o IRC) para conversas casuais, colaboração e trocas rápidas.

Encontrando um projeto para contribuir

Agora que você descobriu como os projetos open source funcionam, é hora de encontrar um projeto para contribuir!

Se você nunca contribuiu para o open source antes, siga alguns conselhos do presidente dos EUA John F. Kennedy, que uma vez disse: “Não pergunte o que seu país pode fazer por você - pergunte o que você pode fazer pelo seu país.”

Contribuir para o open source acontece em todos os níveis nos projetos. Você não precisa pensar sobre o que exatamente será sua primeira contribuição ou como será sua aparência.

Em vez disso, comece pensando nos projetos que você já usa ou deseja usar. Os projetos para os quais você contribuirá ativamente são aqueles para os quais você voltará.

Dentro desses projetos, sempre que você se perceber pensando que algo poderia ser melhor ou diferente, aja de acordo com seu instinto.

O open source não é um clube exclusivo; é feito por pessoas como você. “Open source” é apenas um termo chique para tratar os problemas do mundo como “consertáveis”.

Você pode ler um README e encontrar um link quebrado ou um erro de digitação. Ou você é um novo usuário e percebeu que algo está quebrado ou um problema que você acha que deveria estar na documentação. Em vez de ignorá-lo e seguir em frente, ou pedir a alguém para consertá-lo, veja se você pode ajudar. É disso que se trata o open source!

28% das contribuições casuais para o open source são de documentação, como uma correção de erro de digitação, reformatação ou escrita de tradução.

Você também pode usar um dos seguintes recursos para ajudá-lo a descobrir e contribuir para novos projetos:

Um checklist antes de você contribuir

Quando você encontrar um projeto para o qual gostaria de contribuir, faça uma verificação rápida para garantir que o projeto seja adequado para aceitar contribuições. Caso contrário, seu trabalho duro poderá nunca obter uma resposta.

Aqui está um checklist útil para avaliar se um projeto é bom para novos contribuidores.

Atende a definição de open source

O projeto aceita contribuições ativamente

Veja a atividade de commit no branch main. No GitHub, você pode ver essas informações na página inicial de um repositório.

Em seguida, examine as issues do projeto.

Agora faça o mesmo para os pedidos de pull requests do projeto.

Projeto é acolhedor

Um projeto que é amigável e acolhedor indica que eles serão receptivos a novos contribuidores.

Como submeter uma contribuição

Você encontrou um projeto que gosta e está pronto para fazer uma contribuição. Finalmente! Veja como realizar sua contribuição de forma correta.

Se comunicando de forma eficaz

Seja você um colaborador ocasional ou esteja tentando entrar em uma comunidade, trabalhar com outras pessoas é uma das habilidades mais importantes que você desenvolverá no open source.

Antes de abrir uma issue, pull request ou fazer uma pergunta no bate-papo, ter os pontos a seguir em mente irá ajudar a transmitir sua ideia de maneira eficaz.

Contextualize Ajude os outros a entenderem rapidamente. Se você está patinando em um erro, explique o que você está tentando fazer e como reproduzir este erro. Se você está sugerindo um nova ideia, explique por que você acha que ela seria útil para o projeto (não apenas para você).

😇 “Não acontece X quando eu faço Y”

😢 “X esta quebrado! Por favor conserte isto.”

Faça, antes, sua lição de casa. Não há problema em não saber as coisas, mas mostre que você tentou. Antes de pedir ajuda, verifique o README de um projeto, a documentação, as issues (abertas ou fechadas), a lista de e-mail e procure na internet por uma resposta. As pessoas vão gostar quando você demonstrar que está tentando aprender.

😇 “Não sei como implementar o X. Verifiquei os documentos de ajuda e não encontrei nada mencionando.”

😢 “Como eu faço X?”

Mantenha-se conciso e direto. Assim como enviar um e-mail, todas as contribuições, por mais simples ou úteis, exigem a análise de outra pessoa. Muitos projetos têm mais solicitações recebidas do que pessoas disponíveis para ajudar. Seja conciso. Você aumentará a chance de que alguém possa ajudá-lo.

😇 “Eu gostaria de escrever um tutorial da API”

😢 “Eu estava dirigindo pela estrada no outro dia e parei para abastecer, e então eu tive essa ideia incrível para algo que deveríamos fazer, mas antes de explicar isso, deixe-me mostrar-lhe …“

Mantenha toda a comunicação pública Embora seja tentador, não procure mantenedores de forma privada, a menos que você precise compartilhar informações confidenciais (como um problema de segurança ou violação grave de conduta). Quando você mantém a conversa pública, mais pessoas podem aprender e se beneficiar com a sua troca. As discussões podem ser, em si mesmas, contribuições.

😇 (um comentário) “@-maintainer Olá! Como devemos proceder neste PR?”

😢 (um email) “Ei, desculpe incomodá-lo por e-mail, mas eu queria saber se você teve a chance de rever o meu PR”

Não há problema em fazer perguntas (mas seja paciente!). Todo mundo já foi novo no projeto em algum momento, e até colaboradores experientes precisam se atualizar quando olham para um novo projeto. Da mesma forma, mantenedores de longa data nem sempre estão familiarizados com todas as partes do projeto. Mostre a mesma paciência que você gostaria que eles tivessem com você.

😇 “Obrigado por pegar este erro. Eu segui sua sugestão. Aqui está a saída.”

😢 “Porque você não pode resolver meu problema? Este projeto não é seu?”

Respeite a decisão da comunidade. Suas ideias podem ser diferentes das prioridades ou visão da comunidade. Eles podem oferecer feedback ou decidir não seguir sua ideia. Enquanto você deve discutir e procurar uma solução, os mantenedores têm que viver com sua decisão por mais tempo do que você. Se você não concordar com a decisão deles, você pode sempre trabalhar em sua própria cópia do projeto ou iniciar seu próprio projeto.

😇 “Estou desapontado por não poder apoiar o meu caso de uso, mas como você explicou, isso afeta apenas uma pequena parte dos usuários, eu entendo o porquê. Obrigado por ouvir.”

😢 “Porque você não dá suporte ao meu caso de uso? Isto é inaceitável!”

Acima de tudo, mantenha a classe. O open source é composto por contribuidores de todo o mundo. O contexto se perde em idiomas, culturas, regiões geográficas e fusos horários. Além disso, a comunicação escrita torna mais difícil transmitir um tom ou humor. Assuma boas intenções nessas conversas. É normal se desfazer de uma ideia de forma educada e pedir mais contexto ou esclarecer melhor sua posição. Apenas tente deixar a internet melhor do que quando você a encontrou.

Capturando o contexto

Antes de fazer qualquer coisa, faça uma verificação rápida para garantir que a sua ideia não tenha sido discutida em outro lugar. Explore o README do projeto, os problemas (abertos e fechados), a lista de e-mails e o Stack Overflow. Você não tem que gastar horas passando por tudo, mas uma busca rápida por alguns termos-chave pode lhe dar uma boa visão.

Se você não encontrar sua ideia em outro lugar, você está pronto para fazer uma contribuição. Se o projeto estiver no GitHub, você provavelmente se comunicará abrindo uma issue ou pull request:

  • Issues são como o início de uma conversa ou discussão
  • Pull requests são para início dos trabalhos em uma solução
  • Para comunicações leves, para esclarecimentos ou questões de como fazer, tente perguntar no Stack Overflow, IRC, Slack, ou outro canal de comunicação, se o projeto tiver.

Antes de abrir uma issue ou pull request, verifique os documentos de contribuição do projeto (geralmente um arquivo chamado CONTRIBUTING ou no README), para ver se é necessário incluir algo específico. Por exemplo, eles podem pedir que você siga um modelo ou exigir que você use testes.

Se você quiser fazer uma contribuição substancial, abra uma issue para perguntar antes de trabalhar nela. É útil olhar o projeto por um tempo (no GitHub, você pode clicar em “Watch” para ser notificado de todas as conversas) e conhecer os membros da comunidade, antes de realizar trabalhos que possam não ser aceitos.

Abrindo uma issue

Você deve normalmente abrir uma issue nas seguintes situações:

  • Reportar um erro que você não pode resolver por conta própria.
  • Discutir um tópico de alto nível ou ideia (por exemplo, comunidade, visão ou políticas)
  • Propor uma nova função ou outra ideia do projeto.

Dicas para se comunicar sobre problemas:

  • Se você vir uma issue aberta que deseja resolver, comente na issue para que as pessoas saibam que você está interessado nela. Dessa forma, as pessoas estarão menos propensas a duplicar seu trabalho.
  • Se uma issue foi aberta há algum tempo, É possível que ela esteja sendo resolvida em algum outro lugar ou já tenha sido resolvida, por isso, comente para pedir confirmação antes de iniciar o trabalho.
  • Se você abriu uma issue, mas descobriu a resposta mais tarde, comente na issue para que as pessoas saibam, então feche a issue. Mesmo este registro serve como documentação para o projeto.

Abrindo um pull request

Você deve normalmente abrir um pull request nas seguintes situações:

  • Envio de correções triviais (por exemplo, um erro de digitação, um link quebrado ou um erro óbvio)
  • Iniciar o trabalho em uma contribuição que já foi discutida, ou que você já tenha discutido em uma issue

Um pull request não precisa representar o trabalho final. Geralmente, é melhor abrir um pull request no início, para que outras pessoas possam acompanhar ou dar feedback sobre seu progresso. Basta marcá-lo com um “WIP” (Work in Progress) na linha de assunto. Você sempre pode adicionar mais commits depois.

Se o projeto estiver no GitHub, veja como enviar um pull request:

  • Faça um fork do repositório e clone localmente. Conecte seu repositório local com o “upstream” adicionado-o como repositório remoto. Baixe as alterações do “upstream” com frequência para que você fique atualizado, quando enviar seu pull request, os conflitos de mesclagem serão menos prováveis. (Veja instruções mais detalhadas aqui.)
  • Crie um branch para suas edições.
  • Referencie qualquer issue relevante ou documentação de suporte em seu PR (por exemplo, “Closes #37.”)
  • Inclua imagens do antes e depois se suas mudanças incluírem diferenças no HTML/CSS. Copie e cole as imagens na mensagem do seu pull request.
  • Teste suas mudanças! Execute suas alterações em relação a quaisquer testes existentes, e crie novos quando necessário. Se os testes existirem sempre verifique se suas alterações não quebram o projeto existente.
  • Contribua para o estilo do projeto para melhorar suas habilidades. Isso pode significar usar recuos, ponto-e-vírgula ou comentários de maneira diferente do que você faria em seu próprio repositório, mas torna mais fácil para o mantenedor unir códigos, e para outros manter, entender e melhorar no futuro.

Se este é o seu primeiro pull request, confira Faça um pull request, que @kentcdodds criou como um tutorial em vídeo passo a passo. Você também pode praticar a criação de um pull request no repositório Primeira Contribuição, criado por @Roshanjossey.

O que acontece depois que você envia uma contribuição

Você conseguiu! Parabéns por se tornar um contribuidor open source. Esperamos que seja a primeira de muitas.

Depois de enviar uma contribuição, uma das seguintes situações ocorrerá:

😭 Você não recebe uma resposta.

Espero que você tenha checado o projeto em busca de sinais de atividade antes de fazer uma contribuição. Mesmo em um projeto ativo, no entanto, é possível que sua contribuição não receba uma resposta.

Se você não obtiver uma resposta após uma semana, é justo responder educadamente no mesmo tópico, pedindo a revisão de alguém. Se você souber o nome da pessoa certa para revisar sua contribuição, você poderá @-mencioná-la nesse tópico.

Não contate essa pessoa em particular; Lembre-se de que a comunicação pública é vital para projetos open source.

Se você fizer uma chamada educada e ninguém responder, é possível que ninguém responda, nunca. Não é um sentimento agradável, mas não deixe que isso o desanime. Aconteceu com todos! Existem muitas razões possíveis pelas quais você não recebeu uma resposta, incluindo circunstâncias pessoais que podem estar fora de seu controle. Tente encontrar outro projeto ou uma maneira de contribuir. Bem como outros motivos, esta é uma boa razão para não investir muito tempo em fazer uma contribuição antes que outros membros da comunidade estejam engajados e responsivos.

🚧 Alguém solicita alterações na sua contribuição.

É comum que você seja solicitado a fazer alterações em sua contribuição, ou mesmo feedback sobre o escopo de sua ideia ou alterações em seu código.

Quando alguém solicitar alterações, seja responsivo. Eles levaram algum tempo para revisar sua contribuição. Abrir um PR e ir embora é má educação. Se você não souber como fazer as alterações, pesquise o problema e peça ajuda se precisar.

Se você não tiver mais tempo para trabalhar no assunto (por exemplo, se a conversa já dura meses, e suas circunstâncias mudaram), informe ao mantenedor para que ele não esteja esperando uma resposta. Alguém pode ficar feliz em assumir o controle.

👎 Sua contribuição não é aceita.

Sua contribuição pode ou não ser aceita no final. Espero que você não tenha trabalhado muito nisso até então. Se você não tem certeza do motivo pelo qual não foi aceito, é perfeitamente razoável pedir feedback e esclarecimentos ao mantenedor. Em última análise, no entanto, você precisa respeitar que essa é a decisão deles. Não discuta ou seja hostil. Você é sempre bem vindo para fazer uma cópia e trabalhar em sua própria versão, se você não concordar!

🎉 Sua contribuição é aceita.

Viva! Você fez uma contribuição open source com sucesso!

Você conseguiu!

Se você acabou de fazer sua primeira contribuição open source ou está procurando novas maneiras de contribuir, esperamos que você esteja inspirado a agir. Mesmo que sua contribuição não tenha sido aceita, não se esqueça de agradecer quando um mantenedor se esforçar para ajudá-lo. O open source é feito por pessoas como você: uma issue, pull request, comentário ou high-five de cada vez.