Minha experiência comandando um projeto de código aberto

Meu trabalho é projetar e desenvolver software. Meu hobby é projetar e desenvolver software. Ou seja, o típico cara impopular em festas da empresa: enquanto as pessoas vão estar falando sobre qualquer outra coisa, é bem provável que eu vou estar falando sobre o kernel do Linux.

Então, durante meu tempo livre, eu costumo ajudar alguns projetos de código aberto ou trabalhar em algum software que vá me ajudar no trabalho. Isso pra nem falar nas minhas contribuições pra emuladores de videogames e coisas relacionadas… (mas se você quiser ter uma idéia, basta dar uma olhada na minha conta do GitHub).

Tendo isso em mente, agora vamos iniciar a história: de volta a 2013, eu comecei a trabalhar, como terceirizado, no projeto Groupon, e eles usavam o Campfire como ferramenta de conversa e colaboração (hoje o Campfire faz parte de um produto maior, o BaseCamp).

O Campfire tinha versões web, para Windows e Mac, mas sem versão oficial para Linux. Havia uma versão de código livre, chamada Snakefire.

Campfire client

O Snakefire era um programinha feito em python, que consumia a API do Campfire. Eu tentei achar um pacote (instalador) para o Ubuntu, sem sucesso. Então, decidi ajudar, e aprendi como funciona um pacote Debian/Ubuntu, e como fazer um repositório pra ele.

Outra coisa interessante que eu percebi enquanto mexia com o Snakefire, é que o painel do chat em si era um um container que renderizava HTML. Então bastava carregar o log do chat e produzir um HTML (inclusive com JavaScript e CSS).

Então pensei comigo: se eu fosse o autor de um software como esse, e tivesse pouco tempo disponível, talvez eu optasse por fazer o programa inteiro sendo apenas um renderizador da versão web. Seria bem mais rápido do que fazer um programa consumindo a API.

Claro que hoje em dia, lançar um programa usando o Electron de forma que esse programa seja apenas um invólucro para a versão web do mesmo sistema virou rotina, e todos nós adoramos falar mal do consumo de memória desse tipo de programa. Mas na época pouca gente conhecia.

Slack

Internamente, a empresa em que trabalho estava usando o HipChat, mas então no começo de 2015, decidiram trocar o HipChat pelo Slack como ferramenta de conversa e colaboração.

Cliente do HipChat

O HipChat tinha uma versão ótima pra Linux, oferecendo as mesmas características em todas as plataformas. Mas o Slack, por outro lado, tinha apenas versão para Mac (isso mesmo, nem pra Windows).

Cliente do Slack: só pra Mac!

A versão web tinha alguns contras: era um parto ter que abrir uma aba do navegador para cada projeto; era difícil achar a aba certa em meio a outras 20 abas abertas do navegador; não ficava claro quando alguém te mencionava (ou falava com você) em algum projeto.

Eu mandei um email pra eles (Slack), perguntando sobre uma possível versão pra Linux, e a resposta foi:

Não temos uma versão pra Linux no momento, mas talvez tenhamos no futuro.

Perguntei então se eu poderia ajudar de alguma forma a desenvolver um cliente de código aberto para Linux, e a resposta foi de que eles tinham um time de desenvolvimento, então “não”.

Sem API

Então fui eu lá, durante o final de semana, e comecei a desenvolver um cliente simples para o Slack. Como eles não tem uma API (de mensagens ou de qualquer coisa), eu usei essa idéia que eu tinha ficado na cabeça desde o Campfire: fiz um programinha desktop que simplesmente rodava a versão web (meu primeiro programa em python e Qt!).

Dei uma inspecionada no código JavaScript deles e fiz meu cliente interagir com ele, mostrando notificações nativas no desktop para novas mensagens, mostrar no ícone do programa o número de mensagens não lidas e fazer também o ícone dar uma balançada quando aparecessem novas mensagens.

Mandei um email para a empresa (Slack), dizendo que eu tinha feito um cliente para Linux, e eles pediram apenas para que eu não usasse nome ou logotipo deles, deixando claro que não era um programa oficial da empresa. O que é totalmente justo, já que eles tinham trabalho artístico envolvido e com certeza tecnologias com propriedades registradas envolvidas.

Então eu pensei num nome feio, fiz um ícone mais feio ainda, criei um instalador para o Ubuntu e publiquei meu programinha no GitHub com o nome de ScudCloud:

Ficando popular

Na esperança de divulgar o programinha, mandei um pedido de inclusão para o AlternativeTo, pra que o programa fosse listado como uma alternativa de código aberto ao Slack no Linux (pedido aceito por eles).

Provavelmente também devo ter mencionado o ScudCloud enquanto respondia perguntas no StackOverflow (pois é, eu também gasto um tempo ajudando as pessoas lá).

Ganhei algumas citações aqui e ali, mas depois que o site MakeUseOf falou sobre o ScudCloud, é que o uso do programinha decolou!

Minha recompensa: eu estava ajudando as pessoas com meu programa de código livre! E claro… como eu poderia me esquecer: centenas de pedidos no GitHub!

Sem contar as toneladas de bugs, vários eram pedidos de melhorias: suporte a copiar e colar conteúdo do clipboard, suporte a atalhos de teclado, suporte para altas resoluções (HiDPI), temas personalizados, correção ortográfica, autenticação empresarial com o Google, instalador para outras distribuições (Fedora, RedHat, Arch), salvar o log de conversas, etc.

Eu comecei a implementar algumas dessas coisas no meu tempo livre, mas as notificações por email não paravam de aumentar.

E o que era a parte mais difícil: como o Slack não tem API oficial e documentada, eles ficam mudando o JavaScript interno deles praticamente todo dia. Então, todo dia de manhã, eu já acordava com vários emails me pedindo pra eu arrumar o programa que passou a ficar quebrado enquanto eu dormia.

E não somente isso: algumas pessoas eram realmente deseducadas, algumas vezes bem agressivas!

No geral eu sou super profissional gerenciando meu tempo livre, mas dessa vez eu estava cego: inicialmente eu estava super animado. E você sabe: o amor faz com que a gente faça coisas estúpidas!

Então recapitulando. Como isso começou: eu costumo gastar 1 hora da minha manhã antes do horário de trabalho, em pequenos projetos. Geralmente algo que vá me ajudar, dando aquele ganho de produtividade. E foi o que eu fiz: gastei umas horinhas do final de semana criando um cliente simples pro Slack, pra não precisar usar a terrível versão web.

E como isso terminou: comigo gastando todo meu tempo livre nisso. Inicialmente pela animação, e depois imaginando que talvez chegasse rapidamente num determinado momento em que o programa estivesse polido o suficiente, diminuindo assim a quantidade de problemas reportados.

Meu dia basicamente virou codificar no meu trabalho (que eu adoro), codificar no ScudCloud, e dormir.

Eu programo desde os 11 anos, e pela primeira vez na minha vida inteira, eu fiquei cansado de trabalhar em um projeto.

Gerenciando o burnout

Eu cheguei num ponto em que eu não podia nem ver o ícone roxo do ScudCloud (é sério!).

Então percebi o óbvio: eu tava próximo de um burnout.

E a partir daí poderiam acontecer duas coisas: o projeto ficar parado e morrer (embora pela natureza de código livre, provavelemente alguém assumiria e levaria pra frente, no caso do software ser importante o suficiente); ou eu tentar gerenciar isso de uma forma mais profissional.

Tentei misturar algumas dicas profissionais (óbvias) e aproveitar alguns benefícios do projeto ser de código aberto.

Vamos à elas.

1. Organize as notificações

Como eu trabalho terceirizado para diferentes projetos, recebo muitos emails e notificações do GitHub no meu inbox.

Eu gerencio isso redirecionando todos os emails das diferentes contas para minha conta do Gmail, que contém filtros para mover todos os emails para as pastinhas relacionadas. E todos os emails de diferentes projetos ficam dentro de uma pastinha chamada [Work].

Então resolvi fazer o mesmo com os projetos de código livre que geram muitos emails: criei uma pastinha [FOSS], e dentro dela sub pastas pra cada projeto de código livre.

Com isso, eu posso simplesmente clicar e fechar a pasta [FOSS], e esquecer dela até que eu tenha algum tempo livre pra isso.

Sei que isso é simples e óbvio, mas isso fez uma diferença ENORME no meu dia-a-dia!

2. Limite seu tempo

Eu estava gastando todo meu tempo livre com um projeto que, embora ajudasse as pessoas, não era onde eu fazia meu dinheiro. Eu estava gastando tempo que eu deveria estar gastando com qualidade de vida: com a família, fora de casa, etc.

E, como dito antes, se eu chegasse no burnout e abandonasse o projeto, não estaria beneficiando ninguém.

Então voltei às raízes aqui: trabalhar 1 hora antes do trabalho. Seja em outros projetos, seja no ScudCloud. Eventualmente fazer algum bug fix antes de ir pra cama.

3. Eleja a prioridade

Essa é óbvia: já que, pra sobreviver, vou limitar o tempo, não vou ter tempo pra tudo que foi reportado ou pedido no GitHub.

Então escolhi a prioridade: manter o programa funcionando, já que o jogo de gato e rato (o Slack alterando o código JavaScript diariamente) era a coisa mais difícil e importante da lista.

4. Limite o escopo do projeto

Não é o suficiente apenas listar a prioridade na lista de problemas e pedidos de melhorias, mas também você vai precisar pensar exatamente qual é o objetivo do seu projeto.

Como eu disse, as pessoas começaram a me pedir as mais variadas melhorias, mesmo coisas que o Slack não oferecia naquela época, como por exemplo, temas pessoais.

Desde então eu passei a responder claramente: desculpe, mas meu objetivo é manter, dentro do possível, o ScudCloud como um simples container para o Slack (claro, com as integrações ao desktop).

Basicamente, se alguém queria mais coisas no Slack, que pedissem para o time do Slack.

5. Deixe a comunidade ajudar

Eu comecei a ser mais claro nas minhas respostas no GitHub. Exemplos:

• isso não é uma prioridade;
• não tenho tempo pra esse;
• não faço a mínima idéia de como implementar isso.

Um exemplo de melhoria que as pessoas pediam era pra eu criar pacotes para outras distribuições. Eu respondia simplesmente que eu fiz para o Ubuntu porque era o que eu usava. Criar outro instalador estava fora do meu escopo, mas que eu apreciaria ajuda.

O GitHub inclusive tem, dentro das tags padrão, uma tag pra isso, help wanted.

E adivinha só? As pessoas começaram a enviar código! Algumas melhorias para o programa, código python melhorado, pacotes para outras distribuições, até mesmo a autenticação empresarial foi enviada por contribuidores!

Então basicamente: se o seu projeto é popular, e você for amigável com os pull requests, e as pessoas realmente precisarem de alguma melhoria, elas vão te ajudar!

6. Crie uma lista de contribuidores e suas funções

Vários dos instaladores (para Fedora, RedHat, Arch) foram feitos por contribuidores. E alguns bugs relacionados a eles começaram a aparecer.

Eu lembrava que estes instaladores tinham sido feitos por alguém que não eu, mas eu não conseguia lembrar exatamente o autor! (Eu tinha que sair buscando nos pull requests quem tinha feito aquilo no passado).

O mais fácil a fazer é manter uma lista (de preferência no arquivo README) de contribuidores, seus papéis e um link para o projeto externo.

Desse jeito, era bem mais fácil responder no GitHub: “esse problema não está relacionado ao ScudCloud diretamente, nem ao instalador do Ubuntu, por favor fale com o fulano no projeto X” (adicionando a URL do projeto).

7. Esteja preparado para receber comentários deseducados e agressivos

Eu gosto de ajudar em projetos de código aberto, porque sinto que estou gastando um tempinho ajudando os outros com os mesmos problemas que enfrentei (e que muitas vezes também fui ajudado por outros).

Muitas vezes recebo emails muito legais, dizendo o quanto meu código ajudou. Já recebi até emails me oferecendo um pequeno valor em dinheiro como agradecimento! Eu gentilmente agradeço e recurso a oferta, pois é algo que fiz por diversão pra me ajudar e estou apenas compartilhando com outros.

Em contrapartida, você vai receber um número (pequeno) de emails de pessoas deseducadas, reportando problemas e exigindo grosseiramente correção para isso, como se você fosse um time de suporte pago e que aquela pessoa estivesse no topo da lista de prioridades!

Infelizmente isso sempre vai acontecer, é um fato. Esteja preparado pra isso. Mas não leve para o lado pessoal. Muitas vezes as pessoas nem sabe que se trata de um projeto de código livre. Algumas vezes a pessoa estará escrevendo algo enquanto está realmente muito frustrada com algum problema maior.

Meu primeiro conselho é: se você receber algum destes emails, e você ficar realmente ofendido e bravo, nunca responda nos primeiros minutos. Espere mais de uma hora, até que você consiga digerir isso. Se você sente que precisa realmente expressar seus sentimentos, escreva uma resposta agressiva, mas não envie naquele momento. Do mesmo modo, espere algumas horas. E aí depois disso, reveja esse email que você redigiu: com certeza você vai apagar ele e começar de novo, de forma bem menos agressiva.

Tente relevar as palavras agressivas do email e focar no problema reportado.

De qualquer forma, sempre seja gentil. Sempre.

8. Não prejudique o negócio original

Esse conselho não está relacionado ao “quase burnout”. Mas é uma dica para qualquer projeto de código livre: se você está fazendo um programa de código livre relacionado a algum negócio de outra empresa, respeite o modelo de negócios dessa empresa.

No Slack, o plano inicial de uso deles é gratuito. Você pode criar seu time, usar a ferramenta e consultar o histórico de conversa até um certo limite. Se você quiser ver todo o histórico de conversa, você precisa partir para um plano pago.

Algumas pessoas começaram a me pedir para implementar esse histórico no ScudCloud. Obviamente isso iria prejudicar o modelo de negócios do Slack!

Além disso, o time de suporte do Slack sempre foi muito gentil comigo. Eles até mesmo incluíram o ScudCloud na lista de clientes desktop deles!

Então, minha resposta era sempre clara e direta: “NÃO!”. Claro, eu explicava o motivo: vai prejudicar o modelo de negócios do Slack; e vai fugir do meu escopo (ser um simples container em volta do Slack web).

Slack lança um cliente oficial

O projeto então atingiu um ponto em que dava pra gerenciar: eu conseguia ter uma vida, as pessoas estavam ajudando, o ScudCloud era o cliente Slack padrão no Fedora, ainda problemas e melhorias reportados no GitHub, etc.

Alguns meses depois, o Slack recebeu um cliente oficial pra Linux. Perguntei para as pessoas no GitHub, se eu deveria manter o projeto. Vários disseram “sim!” pelas seguintes razões: melhor integração com o desktop Linux; o fato de ser um projeto de código livre; melhor gerenciamento de memória.

Slack agora oficialmente pra Linux!

O cliente oficial era um tanto quanto parecido com o ScudCloud: um invólucro sobre a versão web. Mas feito com node.js e usando o Electron (que é construído sobre o Chromium, a versão de código aberto do Google Chrome).

O ScudCloud era feito usando o webkit, que era apenas o motor central HTML usado por Chrome, Safari e outros navegadores.

E as pessoas realmente não estavam contentes com o consumo de memória do cliente oficial.

Mas se por um lado o ScudCloud era eficiente e tinha melhor integração com o desktop, por outro ele tinha uma desvantagem óbvia: pelo menos uma vez por semana ele quebrava por causa do Slack alterando sua API.

Eu até cheguei a propôr unir forças com outro cliente Slack para Linux, mas os mantenedores daquele projeto disseram que não tinha mais interesse algum em manter o projeto deles.

A Google para de usar o webkit

Bem, isso não foi em 2015, foi em 2013: a Google criou um fork do webkit e chamou de blink.

Mas foi no final de 2015 que eu comecei a sentir os efeitos dessa mudança: alguns bugs começaram a aparecer no ScudCloud porque o webkit não estava funcionando adequadamente com JavaScript mais novo feito usado pelo Slack.

Inicialmente eu resolvi alguns dos problemas injetando algum JavaScript no ScudCloud (algumas vezes era só polyfill), mas depois começou a ficar mais complicado.

Eu cheguei até mesmo a empacotar uma versão mais nova do webkit para o Ubuntu, o que resolveu por alguns meses, mas depois nem isso foi suficiente.

Minhas opções então eram:

a) Tentar usar uma versão mais nova ainda do webkit, mas também só ajudaria o Ubuntu… ou ter o trabalho imenso e tentar gerar um instalador desse webkit atualizados para outras distros;

b) Mudar o ScudCloud para usar um componente baseado no Chromium, como o QtWebEngine.

É hora de dar tchau

Eu medi todos os prós e contras, e percebi que eu iria gastar um tempo enorme trabalhando em algo que nem era o produto principal do projeto, mas sim apenas a biblioteca responsável por gerar o conteúdo HTML.

E percebi que embora o ScudCloud fosse relativamente bom e popular, o fato é que no decorrer desse tempo o cliente oficial do Slack estava bom o suficiente. Eles até mesmo retrabalharam ele pra ser mais responsivo, abrir mais rápido e usar menos memória!

Então, no fringir dos ovos, eu resolvi arquivar o projeto no GitHub.

Algumas considerações

Bem, depois de tudo isso fiquei com sentimentos contraditórios. Feliz porque o cliente oficial do Slack pra Linux agora existia e estava a par com as outras plataformas. Feliz porque trabalhar no ScudCloud estava sendo exaustivo. E um pouco triste, porque queira ou não, foi uma jornada incrível (e eu aprendi MUITO!).

Eu ainda contribuo em vários projetos de código livre, mas agora em papéis mais específicos. Volta e meia até tenho idéias para alguns projetos, mas prefiro tentar ajudar os já existentes do que tentar criar algo sozinho de novo.

Uma coisa que nunca ficou clara pra mim é a razão do Slack nunca ter lançado uma versão que pudesse ser embutida do seu cliente.

Eu entendo que é bem mais fácil não publicar uma API, afinal é bem mais fácil usar o Electron e ter um programa “desktop” que roda em todas as plataformas.

Mas eles poderia ter essa versão que pudesse ser embutida em outros projetos, e poderiam cobrar por isso.

Eu cheguei até mesmo a receber email de um projeto de crypto moedas, que queria me pagar pra embutir o ScudCloud na ferramenta de trading deles (e eu recusei). Se o Slack tivesse essa versão embutível, eles poderiam cobrar de qualquer empresa que estivesse fazendo um programa que, ao invés de implementar seu próprio chat, quisesse usar o Slack.

Enfim, é isso. Espero que você tenha gostado de me acompanhar nessa jornada e com tudo que aprendi nesse meio tempo. Realmente foi algo muito emocionante pra mim!