Código aberto: não é tão assustador!

O seguinte foi publicado antes do lançamento do Toptal Scholarships for Female Developers.

Como desenvolvedor, é emocionante e desafiador manter-se atualizado com as últimas tendências em tecnologia. Todos os dias, novas linguagens, frameworks e dispositivos capturam nossa atenção e estimulam conversas em encontros, fóruns e chats. No entanto, nossa comunidade de desenvolvedores é feita de pessoas, não de ferramentas, e é fascinante explorar seus aspectos sociopolíticos (por falta de uma palavra melhor; “social” tende a ser associado às redes sociais, hoje em dia).

Na Toptal, recentemente tivemos algumas conversas interessantes sobre o quanto as mulheres contribuem para o código aberto e o que pode estar impedindo-as de contribuir mais, então investigamos o assunto. Tendo participado dessa conversa com Breanden Beneschott e Bozhidar Batsov, fiquei pensando: Bozhidar é um dos principais contribuidores de código aberto no GitHub. Onde estou? Se você verificar minha conta pública do GitHub a partir de hoje, são principalmente pequenos projetos de teste que usei em sala de aula para meus alunos. Eles são incompletos e definitivamente não representam minhas habilidades ou conhecimentos. (Você terá que aceitar minha palavra sobre isso.) Se alguém considerasse me contratar com base no que pode encontrar nessa conta, acho que teria dificuldade em ganhar a vida. Ainda assim, sou um desenvolvedor profissional há mais de 20 anos e, no meu trabalho diário, tenho usado mais software de código aberto do que gostaria de lembrar. Com o tempo, hackeei o kernel do Linux para adaptá-lo a alguma necessidade específica, ajustei todos os roteadores e NAS que comprei, esperei pacientemente por meses na lista de espera do Raspberry Pi para colocar minhas mãos nele e obter minha domótica caseira como Eu gosto disso. Ainda assim, nenhum desses ajustes e testes chegou ao meu GitHub para se tornar código aberto. Além disso, além de corrigir um bug em uma das primeiras versões do Tomcat, nunca contribuí para um projeto de código aberto. Curioso, não é?

Você poderia pensar que é apenas falta de tempo ou interesse, mas eu sei que não é. Quanto aos meus projetos pessoais, posso ter pensado que ninguém poderia realmente se interessar pelo que eu fiz, mas principalmente é que a própria ideia de publicar meu trabalho lá, para todos verem e para a posteridade, me assusta muito. E embora você sempre possa derrubar um projeto pessoal do GitHub, no dia em que tentar contribuir para um projeto de código aberto amplamente disponível, não há como voltar atrás. E se meu código não for bom o suficiente? E se eu não entendi o problema corretamente? E se minha solicitação pull for rejeitada? E se as pessoas me trollarem?

Uma rápida rodada de ligações com colegas desenvolvedores amigos, principalmente do sexo feminino, logo me convenceu de que não sou o único com esse problema, mas para um engenheiro não há problemas, apenas soluções, certo?

Este é um problema importante para resolver, porque contribuir para um projeto de código aberto pode fazer uma diferença dramática:

• Durante a sua carreira : Muitos clientes vão olhar para o seu tudo social antes de decidir contratá-lo; sua conta do GitHub e seu currículo do LinkedIn estão no topo da lista, junto com seus perfis do Facebook e Twitter. Você deve usá-los com sabedoria.
• Para suas habilidades técnicas : Examinar uma base de código escrita por outros desenvolvedores, e muitas vezes muito bons, ensina muito. A capacidade de extrair o significado de uma base de código mal escrita irá desafiá-lo e ensiná-lo da mesma forma.
• Para suas habilidades sociais : O software de código aberto é um processo colaborativo e quase todos os projetos interessantes são criados por equipes. Aprender a trabalhar com outros desenvolvedores através das ferramentas que todos usam, a se misturar com a equipe, a se comunicar com eficiência, é o que fará de você um grande desenvolvedor, não apenas um habilidoso.
• Para a comunidade : Cada bit que você contribui para um projeto de código aberto conta. Quanto mais você contribuir, melhor, mas mesmo corrigir um pequeno erro de digitação em uma tradução tornará o produto final melhor.
• Para sua rede : Você pode enviar centenas de currículos para empresas, mas nada funciona como ter colegas com conexões pessoais. Envolver-se ativamente em um projeto de código aberto garantirá que você conheça pessoas e ganhe seu respeito, e sua reputação crescerá, o que é inestimável para qualquer profissional.

Esta é minha pequena jornada pessoal na luta contra esse medo. Publicar este artigo faz parte da própria jornada. Estou escrevendo na esperança de que qualquer um que esteja bloqueado em escrever um post no blog, ou tenha medo de fazer uma pequena contribuição, veja que no final, não foi tão assustador. Além disso, destina-se a ajudar qualquer pessoa que gostaria de contribuir para o código aberto, mas não sabe por onde começar, então começarei com o básico.

O que é um software de código aberto e onde posso encontrá-lo?

Software de código aberto, ou OSS abreviado, é qualquer software lançado com seu código-fonte e inclui uma licença que permite modificá-lo e redistribuí-lo. Pode ser entregue em qualquer lugar: em um site, por meio de uma lista de discussão ou com uma coruja. O cenário mais comum, e o que nos interessa, é quando a base de código é mantida em um repositório colaborativo. Aqui, estamos focando no GitHub, mas existem outras opções, como SourceForge e Bitbucket. O GitHub é muito amigável, tem uma enorme base de usuários, pode ser usado para qualquer tipo de código e com qualquer ambiente de desenvolvimento que você usar. É importante ressaltar que também é amplamente utilizado para projetos de código não aberto. As chances são de que seu próximo projeto de cliente seja hospedado lá, portanto, saber trabalhar com ele é uma habilidade útil por si só.

E se eu não souber codificar?

Se você está lendo isso, é provável que queira aprender a codificar. Você pode encontrar cursos incríveis em vários sites gratuitos e pagos. Você deve escolher um idioma para aprender; se não tiver preferência, vá com JavaScript. Você já tem tudo o que precisa para começar em seu navegador da Web e é uma das habilidades mais usadas e comercializáveis. Meu favorito pessoal é o Python, que é usado tanto em desenvolvimento web quanto em aplicações científicas. Eu também tenho um curso para iniciantes favorito, “Introdução à ciência da computação” no Udacity. Eu gosto porque é um curso prático, onde você trabalha em um projeto enquanto aprende. Você também pode encontrar vários outros cursos no Coursera, Khan Academy e PluralSight.

E se eu não souber Git?

Como mencionado anteriormente, conhecer o Git é importante, então, faça uma aula de Git. Faça isso mesmo se você estiver trabalhando com Git por um tempo; você não sabe o quanto não sabe sobre o Git até realmente estudá-lo. Faça isso se você não puder explicar com confiança o que o comando rebase faz. Faça isso mesmo que um rebase errado não te assuste. Eu fiz o caminho completo do Git no Code School, mas, novamente, você pode explorar outros sites para mais opções.

Como escolho um projeto no GitHub?

É provável que você use algum OSS em seu desenvolvimento diário. Escolher uma estrutura familiar é um bom ponto de partida; você já está familiarizado com os recursos e como o framework funciona. Ao mergulhar no código-fonte, você aprenderá mais e entenderá sua lógica ainda mais claramente. Se houver uma tecnologia ou ferramenta que você goste particularmente, procure por projetos que a mencionem, ou pelo próprio projeto da ferramenta. Como último recurso, você pode conferir os projetos no GitHub Showcases e começar escolhendo uma categoria que lhe interesse.

Por exemplo, uma busca rápida por “Raspberry” na busca do GitHub mostra mais de 17 mil repositórios. É fácil se perder, então procure um projeto com uma boa comunidade e bom acompanhamento de problemas. Ao escolher um projeto, verifique o número de:

• Colaboradores : segmente qualquer coisa acima de dez colaboradores. Isso deve garantir que o projeto tenha interesse suficiente e não seja simplesmente um pequeno esforço de equipe. Se você é novo em OSS, ou não muito habilidoso, limite sua busca a projetos com no máximo cinquenta colaboradores; comunidades maiores implicam bases de código maiores e projetos mais complicados.
• Commits : Vá para projetos que tenham pelo menos mil commits e onde a atividade mais recente não tenha mais de uma semana. Um projeto que ficou inativo por um mês ou mais é antigo e obsoleto em termos de OSS, e você provavelmente não receberá respostas rapidamente. A atividade diária é o sinal de um projeto saudável.
• Problemas : Problemas são problemas abertos, bugs que foram relatados ou recursos solicitados para serem implementados. Eles lhe darão um ponto de partida e são uma boa métrica do interesse no projeto.

Além disso, descubra qual é a linguagem principal do projeto; você pode ver as estatísticas do idioma na barra superior da página principal do projeto. Reserve algum tempo para ler o tom da discussão, veja como os comentários são amigáveis ​​e educados. Alguns projetos são famosos por suas comunidades agressivas, portanto, podem não ser o ponto de partida certo.

Escolhi o ScyllaDB, um projeto de armazenamento de dados colunar, pois tenho um fascínio por dados - qualquer coisa relacionada a desempenho. Nunca trabalhei com ele, mas espero poder mergulhar em sua base de código. Pode ser mais simples trabalhar com ferramentas que eu conheço, mas estou encarando isso como um desafio e uma oportunidade para aprender algo novo. De resto, atende perfeitamente; ele tem 18 contribuidores, 6,5 mil commits (o mais recente foi há 23 horas no momento da redação), 178 questões abertas e parece ativo.

O que eu faço agora?

Primeiro, clone o repositório e instale o software em sua máquina para ter uma ideia de suas partes móveis. Em seguida, comece a ler as questões. Quando estiver pronto, veja se consegue reproduzir o problema em sua máquina e comece a analisar o que faz o software se comportar mal.

Outra abordagem seria encontrar algo que você mesmo possa melhorar ou modificar. Talvez você tenha notado um erro de digitação ou uma fonte desalinhada, por exemplo. Optei por corrigir um pequeno bug, especificamente um nome de variável errado usado na documentação de um script.

Parece minúsculo, mas a documentação errada é muito pior do que nenhuma documentação. Os usuários instalarão o ScyllaDB e seguirão as etapas de instalação, confiarão cegamente no que está escrito nesse script e acabarão frustrados. Isso foi perfeito para minhas habilidades, e corrigi-lo exigirá que eu siga todo o processo e me familiarize um pouco com a base de código. A correção de bugs é chata, mas é um ótimo começo para encontrar o caminho para um projeto.

Criando um garfo

Isso pode ser trivial, mas no momento, para o projeto ScyllaDB, sou a Sra. Ninguém; seria arriscado me permitir fazer alterações no código deles sem supervisão. O que eu preciso fazer é criar um “fork” na minha própria conta do GitHub. Aqui está meu fork do ScyllaDB. É meu próprio playground onde tenho acesso a todo o código, podendo modificar os arquivos como quiser. Se eu quisesse criar minha própria versão do ScyllaDB e ajustá-lo para fazer algo completamente diferente do seu propósito original, eu poderia fazê-lo aqui. Criar um fork é simples; vá para a página principal do projeto e clique no botão “fork”. Não é nada assustador.

Hora de corrigir o bug

Agora, é hora de testar o código em seu computador e fazer as modificações necessárias. Antes de tudo, verifique se você instalou o cliente Git em sua máquina. Em seguida, adicione sua chave pública SSH ao GitHub e verifique se ela foi carregada pelo seu agente ssh. Obter o código localmente é simples; basta usar o comando git clone que aponta para o seu fork, em vez do branch principal:

 git clone [email protected]:acbellini/scylla.git

Até agora, você deve ter testado o projeto no branch principal, então você vai construir seu código localmente e testá-lo da mesma maneira. Tenha em mente que você terá que bifurcar quaisquer outros projetos do GitHub dos quais seu projeto depende, pois as referências são relativas. No meu caso, tive que bifurcar seastar, scylla-ami e scylla-swagger-ui.

O bug que preciso corrigir é relativamente simples; a documentação em conf/scylla.yaml menciona três diretórios configuráveis: Um para arquivos de dados, um para logs de commit e um, aparentemente não utilizado, para caches, todos eles padronizados para algum subdiretório de $CASSANDRA_HOME :

Mergulhando no código, ele mostra que os padrões são diferentes e, como mencionado na edição #372 que comecei, $CASSANDRA_HOME não deve ser usado. Eu valido minha hipótese testando o código com algumas configurações diferentes, removendo a configuração do arquivo de configuração e verificando quais diretórios são usados. Uma vez confiante o suficiente de que tudo está correto, posso adicionar, confirmar e enviar o arquivo modificado:

 git add conf/scylla.yaml git commit -m 'Correct default directories values in conf/scylla.yaml #372' git push

Observe que eu introduzi o número do problema precedido por um hash na mensagem de confirmação. Isso dirá ao GitHub para vincular automaticamente meu código ao próprio problema.

Outra coisa importante a ser observada é que, ao pesquisar o código, percebi que o terceiro diretório, o de caches, na verdade não é usado. É tentador ir longe demais e remover essa configuração em si, ou adicionar um comentário que não é usado, mas que estaria fora do escopo do problema #372, e seria errado confirmar qualquer coisa que não esteja estritamente relacionada a isso questão. Você deve manter suas mudanças focadas e limitadas à tarefa em mãos.

Neste ponto o código está corrigido e está no GitHub, no meu fork privado. É aí que entra a parte assustadora: pedir ao pessoal do ScyllaDB para aceitar meu código. Isso é chamado de pull request.

A etapa final: o pull request

Eu gosto de criar pull requests diretamente da interface web no GitHub. Acho mais intuitivo e à prova de erros do que tentar fazê-lo a partir da linha de comando. Tudo o que preciso fazer para criar meu pull request é clicar no pequeno botão verde ao lado do nome do meu branch:

Observe que o comentário foi calculado automaticamente pelo GitHub. Meu branch agora tem um novo commit, mas desde que criei meu fork existem mais 14 commits no repositório principal, então vou clicar no ícone verde à esquerda.

Felizmente, meu único commit não entra em conflito com os outros 14, então o GitHub me informa que estou pronto para ir. Não preciso adicionar nenhum outro comentário ou mensagem. A mensagem de confirmação, embora muito curta, diz tudo: O que minha alteração de código faz e com o que ela está relacionada. Quando clico no último botão para confirmar meu pedido, me pergunto o que achei tão assustador alguns dias atrás. Não há nenhum monstro rugindo para mim agora, e as chamas do inferno não parecem estar queimando. Honestamente, não foi nada assustador. No caso improvável de eu ter errado, minha correção não será aceita e pronto.

Se agora você verificar os detalhes do problema, poderá ver que o GitHub adicionou automaticamente uma nota de que há uma solicitação de pull fazendo referência a esse problema. Essa é a mágica do #372 na mensagem do commit. Isso ajudará a evitar que outras pessoas percam tempo para consertar algo que já foi consertado.

Notas finais

Agora estou aguardando a aceitação do meu pull request, receberei uma notificação quando isso acontecer. Tenha em mente que isso pode levar alguns dias, até semanas; alguém precisa revisar meu código, testá-lo como descrito, corrigir o problema e, em última análise, certificar-se de que não afete negativamente a funcionalidade do restante do código (leia-se: cria novos bugs). Tudo isso leva o tempo de alguém, então seja paciente. No final, quando meu pull request for aceito, o ScyllaDB terá mais um colaborador, um problema a menos e eu terei minha primeira contribuição OSS. Agora, é hora de você tentar também. Afinal, não é nada assustador.