Como e por que manter projetos Open Source na área de dados
Dicas para criar e manter um projeto relevante para a comunidade
Um projeto de software open source é aquele que permite a qualquer pessoa visualizar, utilizar, modificar e distribuir. A comunidade formada em torno desses projetos abertos e colaborativos é um dos pilares mais interessantes da área da ciência da computação. Graças a essa cultura, centenas de desenvolvedores se unem voluntariamente para resolver problemas em comum, criando soluções que podem impactar positivamente diversas áreas e segmentos de mercado. Keras, TensorFlow, Pandas e Pytorch são apenas alguns exemplos de bibliotecas de código aberto amplamente utilizadas para resolver desafios relacionados a dados.
Por conta disso, dedicar tempo para contribuir com projetos open source costuma trazer diversos aprendizados e edificar a carreira do profissional de tecnologia, sendo inclusive valorizado por algumas empresas em processos seletivos. Hoje em dia, existem inúmeros tutoriais e artigos com dicas úteis sobre como encontrar um bom projeto e se tornar um contribuidor, iniciando sua jornada no mundo do código aberto.
Ainda assim, pouco se fala a respeito do outro aspecto fundamental que compõe a comunidade: como criar e manter o seu próprio projeto open source?
Na minha opinião, há várias razões pelas quais esse tema é menos abordado. Primeiro, criar um projeto próprio costuma exigir mais tempo e dedicação do que contribuir para um já existente. Além disso, muitas pessoas acreditam que é necessário ser um grande especialista na área para lançar um projeto de código aberto, ou que é preciso criar uma solução extremamente robusta e completa.
Dito isso, um dos principais objetivos desse artigo é desmistificar esses paradigmas, mostrando que mesmo um projeto simples tem o potencial de impactar diversas pessoas ao redor do mundo, além de promover sua carreira e ampliar sua rede de contatos.
Embora grande parte do que será discutido aqui possa ser aplicado a qualquer tipo de iniciativa open source, o foco será na área de dados, pois é o contexto no qual tive a experiência de criar e manter um projeto ao longo dos últimos três anos. Este artigo resume os principais pontos que eu gostaria de ter me atentado desde o início da minha jornada.
Contextualizando o projeto
Antes de mais nada, acredito que seja necessário algum contexto a respeito do meu principal projeto open source. Primeiramente, vale destacar que não se trata de nenhum projeto gigantesco da área de dados, possuindo 156 Stars, 33 Forks e 30 issues resolvidos no Github. Ainda assim, desde que decidi torná-lo público, no início de 2020, me deparei com diversos aprendizados que podem ser valiosos para quem deseja iniciar neste mundo.
Trata-se de um projeto chamado “Auto-Annotate”, que tem por objetivo servir como uma ferramenta de anotação semi-supervisionada para modelos de detecção de objetos treinados com a biblioteca do TensorFlow. Com o auxílio da ferramenta, é possível utilizar as inferências do modelo para criar as labels em arquivos XML, seguindo a estrutura definida pelo padrão PASCAL VOC.
Logo de cara, fica claro que esse projeto possui um nicho bem específico, voltado principalmente para engenheiros de visão computacional e pesquisadores que trabalham com detecção de objetos no TensorFlow.
Neste momento, você pode estar pensando que eu desenvolvi um software revolucionário e que gastei meses de codificação. Não se deixe enganar pela descrição cheia de siglas e termos, meu objetivo com essa ferramenta era apenas resolver um problema prático que enfrentei durante o desenvolvimento do meu TCC na faculdade. Por isso, levei apenas alguns poucos dias para criar a versão inicial da biblioteca, cujo código inicial era bastante simples (e até meio mal escrito).
Considerando a tamanha especificidade do projeto e o fato do código ter sido desenvolvido por um júnior sem muita experiência na época, eu estava certo de que ninguém se interessaria por esse trabalho, estando satisfeito com o fato de a ferramenta ao menos ter me ajudado a concluir o meu TCC.
No entanto, para minha surpresa, em poucos meses comecei a notar um crescente número de pessoas interagindo com o repositório do projeto, dando Stars, realizando Forks e até mesmo abrindo novas Issues. Perceber que mesmo algo simples e nichado pode ser útil para outras pessoas foi minha primeira grande lição no mundo open source.
Portanto, tenha em mente que nenhuma experiência é única. Se o seu projeto é útil pra você, é bastante provável que também seja útil para outras pessoas da comunidade.
Por que criar e manter um projeto open source?
Uma das perguntas mais óbvias nesse ponto é: por que criar meu próprio projeto open source ao invés de contribuir com os projetos existentes? Primeiro, tenha em mente que uma coisa não elimina a outra. Acredito que contribuir com projetos da comunidade seja muito importante, especialmente se você tem pouca experiência de como esse universo funciona. Ainda assim, existem algumas vantagens interessantes que podem motivá-lo a desenvolver e manter seu próprio projeto.
Criando algo que é SEU
Primeiramente, de maneira quase óbvia, quando você inicia sua própria iniciativa, você está trabalhando em uma ideia sua, algo em que realmente acredita e que possui um propósito claro para você (ou pelo menos deveria).
Quem trabalha com tecnologia sabe quão única é a sensação de poder criar algo com suas próprias mãos e desenvolver sua própria solução. Quando você está à frente de um projeto open source, tem a oportunidade de liderar as decisões, conceber novas funcionalidades e ditar o escopo de algo que leva totalmente a sua “marca”.
Na minha máquina funciona
Quem já desenvolveu um projeto próprio em um repositório privado sabe muito bem que certas coisas são simplesmente deixadas “para depois”. Nem sempre criamos uma documentação bem elaborada, nos preocupamos com compatibilidade ou, às vezes, nem sequer estruturamos um simples arquivo de “requeriments.txt” para gerir as dependências.
Quando um projeto é voltado para comunidade, por sua vez, esses aspectos mais amplos que compõe o software não podem ser ignorados. É necessário se preocupar com fatores como a compatibilidade da ferramenta com diferentes sistemas operacionais, versionamento semântico, gestão de dependências, segurança, documentação e até mesmo o roadmap do produto. Trabalhar nesses pontos permite que você desenvolva diferentes habilidades e adquira uma visão mais crítica a respeito do ciclo de vida de um software, sendo habilidades essenciais para um profissional de tecnologia com maior nível de senioridade.
Novamente, meu objetivo não é desencorajar os menos experientes, visto que todas essas habilidades não são um pré-requisito para que você inicie seu projeto. Entretanto, a medida que sua solução evolui e se torna mais robusta, é natural que você passe a pensar nesses aspectos, visto que são essenciais para garantir uma boa experiência por parte dos usuários da comunidade.
Dominando o open source
Ser contribuidor de um projeto open source ensina lições valiosas, como criar issues bem documentadas e relevantes, submeter merge requests adequados, se comunicar de maneira assertiva com desenvolvedores ao redor do mundo e lidar com bases de código legado.
Ainda assim, não existe maneira melhor de entender toda a dinâmica por trás do open source do que ser um mantenedor de código aberto. Ao assumir essa posição, você enfrenta preocupações que talvez nunca tivesse antes. Isso vai além de manter um código limpo e bem documentado, pois envolve também a criação e gestão da comunidade em torno do seu projeto.
Nesse contexto, é essencial estabelecer diretrizes e um código de conduta claros, guiando os membros da comunidade sobre como abrir issues, contribuir, reportar problemas e solicitar melhorias.
Networking e portfólio
Como mencionado anteriormente, contribuir com projetos de código aberto tem um grande potencial para enriquecer seu portfólio, sendo valorizado em alguns processos seletivos. Nesse sentido, ser o responsável por um projeto open source pode ser ainda mais interessante, visto que essa posição exige um conjunto diversificado de hard skills do profissional, conforme citado anteriormente.
Além disso, estar a frente desse tipo de iniciativa faz com que seu nome ganhe destaque, facilitando a criação de networking com outros desenvolvedores da área.
Contribuição
Por fim, projetos open source úteis para a comunidade tendem a evoluir naturalmente graças ao esforço coletivo de desenvolvedores e especialistas ao redor do mundo. Isso permite que você obtenha contribuições valiosas, tornando seu projeto mais robusto e impactante.
Dicas para iniciar e manter um projeto open source
Se você chegou até aqui, espero que esteja convencido a iniciar o seu próprio projeto de código aberto e contribuir com a comunidade! Dito isso, este artigo não tem como objetivo ser um tutorial sobre como criar um issue template, um arquivo de requirements para gerenciar dependências, nem sobre qual é a melhor licença para seu repositório. Para esses fins, existem diversos outras fontes que você pode consultar, algumas das quais estão na seção de referências ao final deste artigo.
Tendo isso em vista, as seções subsequentes focam nos conceitos que eu considero mais importantes e que me ajudaram na criação e manutenção do meu próprio projeto open source.
Resolva um problema
Uma vez ouvi dizer que uma ideia vale apenas um real. Isso significa que, mesmo que você tenha uma ideia genial de projeto ou negócio, ela não terá valor se não for executada.
Algo similar pode ser aplicado a projetos open source. De nada adianta utilizar uma tecnologia de ponta, escrever um código limpo e seguir uma arquitetura escalável se o projeto não resolve nenhum problema real.
Por conta disso, começar pelo problema é uma das coisas mais importantes para se ter um projeto impactante. No meu caso, por exemplo, a ideia de uma biblioteca para auxiliar na criação das anotações para detecção de objetos surgiu depois de gastar horas criando um conjunto de dados com centenas de imagens para meu TCC. Ao buscar por uma ferramenta que pudesse me ajudar nessa tarefa, não encontrei nada gratuito ou open source. Com isso, tive que criar minha própria solução para agilizar a etapa de criação do dataset.
Após concluir o TCC, percebi que, embora o código desenvolvido fosse simples, ele resolveu meu problema e poupou horas de trabalho. Essa foi toda a motivação que precisei para decidir torná-lo open source, na esperança de também facilitar a vida de outros pesquisadores.
Assim, o primeiro ponto a se pensar é se o que você está criando de fato resolve um problema real, se é algo que fará diferença para a comunidade e que as pessoas terão interesse em utilizar por algum motivo. Tome cuidado para não subestimar o seu potencial. Se o seu projeto efetivamente te ajudou a economizar esforço, tempo ou custo para executar uma tarefa, essa já é uma boa motivação para compartilhá-lo.
Por fim, costuma ser bastante útil verificar se já existem opções gratuitas ou open source que fazem a mesma coisa que você está propondo. Hoje em dia, é bastante provável que você encontre algo similar. Ainda assim, não desanime: estude os projetos “concorrentes” para entender as funcionalidades oferecidas, a linguagem de programação utilizada, compatibilidade e outros fatores relevantes.
Muitas vezes, só de oferecer uma documentação mais bem detalhada e uma ferramenta um pouco mais fácil de se utilizar já é o suficiente para convencer novos usuários a optarem pela sua solução. Além disso, projetos similares podem servir como uma importante fonte de inspiração!
O básico bem feito
Quando compartilhamos um projeto, existem alguns pontos básicos e até meio óbvios que não podem ser ignorados. O primeiro deles é escrever um bom código. É sempre importante ter em mente que seu código será lido e utilizado por diversas pessoas ao redor do mundo. Portanto, pense em um código que possa ser entendido com o mínimo de dificuldades, independente do seu público.
Isso inclui evitar termos específicos ou regionalizados, manter os nomes claros e criar uma estrutura no repositório que siga os padrões da linguagem ou dos frameworks adotados, fazendo com que a curva de aprendizado para utilizar o projeto seja a menor possível. No fim das contas, escrever um código limpo é essencial quando estamos trabalhando em equipe, pois facilita o entendimento e a compreensão por parte de outros desenvolvedores.
Além disso, é fundamental estruturar um bom repositório no GitHub, seguindo os padrões da comunidade sempre que possível. Isso envolve ter um README com uma introdução clara do projeto e de como utilizá-lo, um código de conduta, diretrizes de contribuição, template de issues, e entre outros detalhes.
Mesmo que a versão inicial do seu projeto não possua todos os itens supracitados, lembre-se de que quanto mais trabalhar neles, maiores serão as chances do seu projeto ser adotado pela comunidade. Isso também reduz o número de issues abertos com dúvidas triviais que poderiam ser evitadas com uma documentação ou código mais bem elaborados.
Conforme mencionado no início dessa seção, não pretendo detalhar todos os aspectos necessários para criar um bom repositório, pois há outros artigos e tutoriais que já abordam isso. Ainda assim, vale reforçar a importância de um bom README.
A documentação de um projeto de software costuma ser a sua principal fonte de conhecimento e guia de uso. Além de ser um manual, o README acaba sendo a página inicial do seu projeto, tornando-se um espaço essencial para explicar as motivações por trás da sua ferramenta, o problema que ela resolve e por que as pessoas deveriam se interessar por ela.
Você também pode usar o README para responder algumas questões importantes a cerca do projeto, como se aceita novas contribuições, se há um roadmap de novas funcionalidades e até mesmo para listar algumas limitações conhecidas. Acredito que uma documentação ruim seja a principal causa de abertura de issues desnecessárias.
Por fim, utilizar materiais visuais como imagens, GIFs e até vídeos pode ser um recurso lúdico extremamente eficaz para tornar sua documentação mais atrativa e amigável. Esses elementos ajudam a ilustrar conceitos, guias e exemplos de forma mais acessível, reduzindo as barreiras para novos usuários. Ademais, você pode considerar ir além e criar um site específico dedicado à documentação da sua ferramenta, como é comum em diversas soluções disponíveis no mercado.
A armadilha do nicho
Muita vezes, quando construímos uma nova solução para um determinado problema, estamos inseridos em um nicho específico. No meu caso, por exemplo, minha ferramenta é voltada para pesquisadores e engenheiros de visão computacional que utilizam o TensorFlow. Nesse contexto, cometi o erro de assumir algo que parecia óbvio: que os usuários da ferramenta teriam conhecimento sobre modelos de detecção de objetos e saberiam usar o TensorFlow.
Isso é o que chamo de uma armadilha de nicho. Assumimos que, baseado no contexto do projeto e no problema que a ferramenta resolve, todos os usuários estarão familiarizados com o tema ou área em que estamos trabalhando.
Embora essa suposição pareça natural, ela pode levar a um gasto desnecessário de tempo. Ao longo do meu projeto, me deparei com diversas pessoas que claramente nunca haviam treinado um modelo usando TensorFlow ou que não compreendiam bem como um detector de objetos funcionava.
Como consequência, precisei dedicar várias horas para dar suporte em issues relacionadas a questões básicas, que surgiram devido à falta de conhecimento dos usuários. Sinceramente, acredito que seja quase impossível eliminar completamente esse tipo de problema. Ainda assim, algo que pode ajudar bastante a diminuir essas ocorrências é documentar de maneira detalhada os pormenores da sua ferramenta.
Claro que a ideia não é escrever um repositório completo de conhecimento sobre o tema em questão. Mas, na medida do possível, procure esclarecer termos muito específicos que possam gerar dúvidas, especialmente entre pessoas com menos familiaridade com o assunto. Uma boa estratégia é anexar links para documentações externas que expliquem conceitos relevantes de forma mais abrangente.
No meu caso, por exemplo, entender a estrutura do PASCAL VOC para criação de labels é um conceito fundamental para o uso da minha biblioteca. Por conta disso, faz sentido explicar a importância dessa estrutura e incluir um link para o paper original dos autores, o qual detalha os aspectos mais técnicos.
Em resumo, nunca assuma que seus usuários tem muito conhecimento prévio.
Tenha paciência com alguns usuários
Ao longo da minha jornada, me deparei com issues e questionamentos difíceis de se explicar. Algumas pessoas podem ser rudes com você, agir como se fossem seus chefes ou até mesmo fazer perguntas cuja resposta está destacada em negrito no primeiro parágrafo da documentação. Como lidar com isso?
A resposta mais fácil seria ser igualmente rude ou simplesmente fechar a issue sem explicações. Por mais tentador que isso seja, obviamente não é uma boa prática. Vale lembrar que, na comunidade open source, é altamente valorizado o uso de uma linguagem não agressiva. Muitos devs cometem o erro de deixar a arrogância falar mais alto, e acabam se comunicando de uma maneira pouco amigável, afastando novos contribuidores e até mesmo possíveis conexões de networking.
Além disso, é importante entender que algumas pessoas não agem assim por mal. Há quem esteja começando no mundo open source e ainda não compreenda muito bem a dinâmica de como as coisas funcionam. Talvez alguém acredite que você é pago para desenvolver o projeto e que, por isso, é sua obrigação atendê-lo.
Diante disso, o primeiro passo é sempre tentar manter uma comunicação amigável e respeitosa. Seja gentil e demonstre disposição para ajudar, mesmo que demore alguns dias para responder à issue. Sempre que possível, utilize recursos externos para responder à dúvida, como a própria documentação do projeto ou issues previamente resolvidas.
Outra medida útil é criar um modelo (template) para a abertura de issues, incentivando os usuários a preencher informações básicas que possam ajudar na resolução do problema. Geralmente, a comunicação nesses projetos é assíncrona e possui um delay de vários dias. Por isso, é extremamente improdutivo gastar tempo lendo uma issue em que o usuário nem sequer especificou a versão do Python ou o sistema operacional que está utilizando.
Por fim, aproveite cada comentário ou dúvida no seu projeto como uma oportunidade para melhorar a experiência do usuário e a documentação. Quanto mais complexa a instalação ou usabilidade, maiores serão as chances de encontrar pessoas que ficaram travadas no primeiro erro que encontraram ou na execução de um determinado comando.
Divulgue seu projeto
Nunca se iluda imaginando que seu projeto irá crescer organicamente. Apenas criar um repositório no Github, ainda que bem documentado, não é o bastante para atrair a atenção ou mesmo ser encontrado pela comunidade. Por isso, uma das responsabilidades de um mantenedor é justamente divulgar a solução que foi desenvolvida.
Um dos momentos de maior crescimento do meu projeto, por exemplo, foi quando escrevi um artigo sobre ele em uma comunidade de ciência de dados no Medium. Artigos, comunidades do Reddit, canais do Slack e vídeos no Youtube são apenas algumas das maneiras de promover sua solução para pessoas com problemas simulares ao seu. Ainda que seja trabalhoso, essa é uma das formas mais efetivas de fazer com que mais pessoas conheçam o que você criou.
Dedique algum tempo
Se você chegou até aqui, já deve ter percebido que existem algumas dificuldades inerentes a criar e manter um projeto open source. Além do esforço inicial, que costuma ser o mais intenso de todo o ciclo de vida da iniciativa, enquanto o projeto estiver com o código aberto, é provável que você precise dedicar algum tempo a ele.
Mesmo que não surjam novas issues, é sempre uma boa prática manter as dependências atualizadas para evitar possíveis vulnerabilidades de segurança. Além disso, projetos que não recebem atualizações há muito tempo tendem a ser menos adotados pela comunidade, pois os usuários perdem a confiança no comprometimento do mantenedor.
Por fim, caso sua solução se torne popular, é bem provável que você precise dedicar cada vez mais tempo não apenas ao código, mas também respondendo issues e ajudando os contribuidores. Nessa situação, existem boas práticas para escalar seu projeto e manter o equilíbrio como mantenedor de uma ferramenta popular de código aberto.
Conclusão
Muito se fala sobre as vantagens e a importância de contribuir para projetos open source. Ainda assim, espero que este artigo tenha trazido uma nova perspectiva sobre o que é ser um mantenedor e criar o seu próprio projeto.
Embora possa ser um pouco mais trabalhoso, dedicar-se a um projeto que te motiva é, muitas vezes, tão divertido quanto qualquer lazer. Além disso, você terá a oportunidade de desenvolver habilidades que raramente são exercitadas ao ser apenas um contribuidor de projetos já existentes.
As dicas deste artigo são apenas um ponto de partida, mas espero que ajudem você a ser mais produtivo e confiante ao liderar esse tipo de iniciativa!
