Por que e Como Participar de Projetos Open Source

Júlio Biason
@juliobiason
https://functional.cafe/@juliobiason
julio.biason@gmail.com
http://presentations.juliobiason.net

Motivação

Por Que Participar?

Aprender algo novo
O que a maior parte dos professores (principalmente) faz é sugerir participar de um projeto open source para aprender uma nova linguagem.
Para retornar à comunidade
Essa deve ser o "por que" mais citado: O software está disponível para quem quiser usar e seria interessante que quem utilize retorne algo ao desenvolvimento.
"Code rot"
Software, com o tempo, se "deteriora". Se não tiver alguém olhando, ele pára de funcionar.
"Scratch an itch"
Se tem algo lhe incomodando no software, ele pode ser alterado. E se você não se sentir capaz de fazer, ainda é possível pedir pra alguém resolver isso pra você (e talvez você queria pagar essa pessoa...)
Fator abandono.
Software estável recebe poucas atualizações, mas as pessoas tendem a ver software com poucas atualizações como "abandonado". Alguém olhando, comentando, discutindo features, explicando como fazer as coisas deixa o projeto "vivo".

Como Participar

Enviar código com novas features é a forma mais direta mas não a mais fácil.

Enviar Código

Aclimate-se ao ambiente do projeto (IRC, Maillist, Slack, etc)
Seguir os padrões de codificação do projeto (HACKING.md)
Entender os objetivos do projeto (isso está na cabeça dos mantenedores)

Anedota: Mitter.

Enviar Código

Lembre-se: para alguém, o projeto é seu filho.

Anedota: IceWM.

IceWM é um gerenciador de janelas com uso mínimo de memória, mas altamente configurável. Depois de abandonado pelo desenvolvedor original, ele foi mantido por outra pessoa. Eu comecei a portar os temas do Enlightment (o gerenciador com os temas mais bonitos que havia), mas havia um problema: Sombras nos títulos. Como o IceWM não tinha suporte às sombras, alguns temas ficavam completamente ilegíveis. Eu corri atrás do código onde mostrava o título (dica: eu procurei dentro do código pela variável do arquivo de tema que definia a cor do título) e adicionei a nova funcionalidade. Como o meu patch gerou mais burburinho na lista de discussão e IRC do que o que o mantenedor estava fazendo, ele portou meu patch, trocando os nomes das variáveis. No final, eu fiquei como "co-autor" da feature e não como contribuidor. Mas eu ganhei a feature que eu queria. (Dica: o que eu usei pra achar onde estava a função foi `grep`.)

Enviar Código

Algumas vezes, o projeto já está abandonado pelo autor original, mas a comunidade ainda mantém indiretamente.

Anedota: Blackbox.

Enviar Código

Muito raramente, o desenvolvedor simplesmente não tem tempo para pesquisar como corrigir uma feature que ele mesmo quer colocar.

Anedota: Htop.

Uma noite, quando eu estava trabalhando até mais tarde, o Hisham, autor do Htop, veio conversar comigo no IM da época (que eu não lembro exatamente qual era), como era costume quando ele tava perdido e querendo desopilar um pouco. Ele me explicou que tava com um problema no top dele, para mostrar o usuário correto em aplicativos que estavam em unidades NFS, mas o `ps` mostrava corretamente. "Olha o fonte do psutils, oras. É pra isso que é open source", eu disse. "Ah, não tô com vontade." Por pura irritação, eu baixei o fonte do psutils e olhei o nome da função que encontrava o usuário e passei pra ele. Meu nome está no "Thanks" do Htop 1 até hoje simplesmente por isso. (Dica: o que eu sei pra encontrar a função foi `ctags` pra mapear o conteúdo do projeto e fui correndo de função em função)

Como Participar

Bug reports

Bug Reports

Quando encontrar um problema, tente repetir; tente isolar o que causa o problema (uma configuração, o nome do arquivo); se conseguir, envie para o desenvolvedor.

Anedota: Skyrim.

Bug Reports

Se possível, crie um teste que mostre como o problema se repete (o que é mais fácil para bibliotecas e frameworks do que projetos).

Anedota: MongoEngine.

O Fork

Quando o desenvolvedor original do projeto não tem mais interesse e não quer continuar, sempre há a possbilidade de ter um desenvolvimento em separado.

Anedota: Jenkins, Pillow

O Fork

... e há vezes que um fork, com ajuda da própria comunidade, volta para o projeto original.

Anedota: Compiz, GCC

Como Participar

Traduções

Se você não entende de código, pode ajudar traduzindo a aplicação para a sua língua.

Anedota: Mitter e Fábio Beneditto

Como Participar

Artwork

Muitos projetos precisam de um site bonito e até mesmo um logotipo interessante. Ajudar o desenvolvedor mantendo um site que consiga comunicar o objetivo do projeto sempre ajuda.

Anedota: Alguma-Coisa-Dog.

Como Participar

Documentação

Desde "como instalar esse projeto" ao "o que ele faz", ainda falta documentação de muita coisa. Nem é preciso saber programar, pegando algumas dicas com o autor do projeto.

Dica: Embora alguns desenvolvedores reclamem da falta de man pages, é possível fazer coisas bem legíveis usando projetos como ReadTheDocs e Gitbook.

Como Participar

Doações

Alguns projetos tem pessoas trabalhando full time e precisam de alguma forma de pagar essas pessoas.

Anedota: VIM, Mozilla

Como Participar

Evangelização

Você pode ajudar um projeto a crescer divulgando o mesmo em palestas ou até mesmo comentando com seus colegas.

Dica: Evite guerras santas do tipo "meu projeto vs seu projeto".

Anedota: Eu ;).

Como Participar

"Obrigado"

Poucas coisas conseguem ser tão poderosas como um simples "obrigado por ter feito esse projeto".

Dica: Cerveja e Pizza também contam como obrigados.

Anedota: Htop.

Perguntas?

@juliobiason
https://functional.cafe/@juliobiason
julio.biason@gmail.com
http://presentations.juliobiason.net