🌟 Reflexões sobre Open Source - 1 ano, 780 estrelas e 80k downloads depois · igorbenav

Há pouco mais de um ano, comecei a programar o FastCRUD - Operações CRUD Robustas e Criação Flexível de Enpoints para FastAPI, meu projeto open source.

Não foi o primeiro projeto open source que eu fiz, também não foi a primeira biblioteca, mas certamente algumas mudanças interessantes aconteceram no meu pensamento sobre como abordar projetos desde então. A ideia aqui é falar um pouco sobre essas reflexões e sobre os aprendizados que tive, talvez interessar mais de vocês por open source.

A ideia geral aqui é falar como fazer um projeto open source de sucesso.

TL;DR:

Faça algo útil pra você mesmo
Não comece por "o que fazer", comece com "por que fazer"
Faça a coisa mais simples possível que resolva o problema
Documentação, documentação, documentação
Consiga alguma prova social
Divulgue
Apanhe
Mantenha o seu projeto
Saiba pedir ajuda

Contexto

Eu costumava trabalhar principalmente com dados, passei por Analista de Dados, Analytics Engineer e Engenheiro de Dados, até fazer deploy de modelos de Machine Learning, mas confesso que sentia muita falta de programar.

A real é que trabalhando com dados você não programa tanto, e - quando programa - não faz coisas tão interessantes assim. É muito mais pipeline de dados, transformações (em SQL ou python), eventualmente alguma modelagem preditiva ou deploy de machine learning, mas a parte de programação desses problemas meio que já tá resolvida. O que realmente gera valor nessas coisas - a menos que você esteja em empresas gigantes que a infraestrutura importa muito - é muito mais entender o negócio, otimizar queries, saber responder as perguntas (e quais perguntas as pessoas realmente tão fazendo), e eventualmente isso fica meio repetitivo.

Com saudades da minha época de programar na faculdade e nas minhas (falidas) empresas, decidi começar a criar projetos open source pra saciar isso.

O que faz um projeto de sucesso?

Bem, pra começar a falar sobre como ter sucesso em um projeto, importante definir o que é sucesso. A verdade é que isso varia bastante, mas depois de algum tempo eu movi a minha definição de sucesso de "pessoas vendo, usando, estrelando" pra "é útil pra mim".

A única coisa que você consegue controlar sobre o projeto é se vai ser útil pra você, não se os outros vão gostar ou se vai ser útil pra eles. Se essas coisas acontecerem, ótimo, mas a real é que depois de um tempo você valoriza menos essas métricas de vaidade.

Claro que isso muda dependendo do seu objetivo, se você tá fazendo o projeto pra melhorar o seu portfólio, vai querer usar a tecnologias relevantes pra isso, vai querer que tenha mais visibilidade. De qualquer forma, leve a máxima "isso vai ser útil pra mim?" pra fazer, na pior das hipóteses, você não perdeu o seu tempo (além do aprendizado).

Talvez você descubra que para seu problema específico é melhor contribuir com um projeto existente que fazer o seu próprio projeto.

Como ter ideia do que fazer?

Aqui temos uma outra máxima, não comece por "o que fazer", comece com "por que fazer". Não tem como fazer algo de útil pra você (e, quem sabe, pra outros) sem algum domínio da área. O mais importante é saber o que tem de problema na área.

Exemplo prático:

Eu precisava melhorar em fazer deploy de modelos de machine learning pro trabalho, por isso decidi aprender FastAPI
Após usar FastAPI por um tempo, vi que muitas coisas não tinham um padrão de como fazer, então resolvi criar um template pra mim mesmo pra facilitar a criação de apis com as tecnologias que eu gostava
Descobri que não tinha nenhum painel de admin pra FastAPI do jeito que eu gostava, então decidi criar um (pra eu usar)
Pra criar esse painel, tinha que ter uma forma fácil de gerar CRUD e endpoints a partir de modelos SQLAlchemy e schemas Pydantic, então criei o FastCRUD pra facilitar o meu trabalho.

Percebe como todo projeto aqui teve uma motivação natural antes? Algum problema que eu precisava resolver pra mim mesmo (ou pra empresa que eu trabalhava). Exatamente por isso, mesmo se ninguém tivesse visto ou usado os projetos, ainda teria sido um sucesso pra mim.

De bônus, se esses projetos resolvem um problema pra mim, a chance de resolverem problemas de outras pessoas é maior (como foi o caso).

A ideia geral aqui é começar pensando em resolver algum problema, não em criar um projeto. Talvez você não saiba qual é esse problema ainda, então antes disso vá estudar, explorar, sentir na pele.

Como desenvolver?

Agora que você já sabe o que fazer (e - mais importante - por que fazer), você vai de fato começar a desenvolver. A máxima dessa seção é muito simples, faça a coisa mais simples possível que resolva o problema.

Comece pequeno, lembre que seu objetivo inicial é resolver o problema, não fazer a coisa mais bonita possível. Uma vez que tiver uma solução inicial, você pode ir adicionando coisas e refatorando (quando for relevante).

Exemplo prático:

Queria uma forma mais fácil de filtrar pro meu painel admin, então adicionei filtros no estilo django orm no fastcrud.
Pessoas começaram a pedir suporte pra SQLModel, então adicionei.
Tava cansado de ficar reimplementando paginação toda vez, então criei utils pra isso no fastcrud.

Uma coisa interessante é que aqui as pessoas começaram a achar útil e usar, então identificaram problemas, começaram a pedir coisas e até a contribuir abrindo pull requests.

É importante falar como as pessoas ficaram sabendo do meu projeto, pra isso temos a próxima parte.

Como divulgar o projeto?

Aqui as coisas começam a ficar mais políticas. Embora nossa definição inicial de projeto open source de sucesso tenha sido algo útil pra nós mesmos, a verdade é que quanto mais pessoas contribuindo, melhor.

Você provavelmente não vai achar todos os bugs sozinho, não vai pensar em todas as melhoras por si só, também vai aprender mais devagar sem outras pessoas estressando a sua ideia.

O que eu aprendi (após apanhar bastante) é:

Documentação, documentação, documentação. Um README útil sobre o que é e como usar o projeto é o mínimo. Quanto mais você facilitar a vida dos outros pra entender as coisas, maior a chance de eles ajudarem. Se inspire em documentações que você gosta, escreva, escreva, escreva.
Consiga umas 10-20 estrelas antes de divulgar. Isso é triste, mas se você não pedir as estrelas iniciais pra amigos, ninguém vai olhar seu projeto. A ideia nem é ganhar estrelas depois disso, mas as pessoas não vão olhar e levar a sério sem alguma validação social. Se você não tiver muitos amigos pra experimentarem seu projeto, tudo bem divulgar sem.
Divulgue. Pode ser meio óbvio, mas as pessoas costumam ter medo disso. Quanto antes você perder o medo de mostrar as coisas (que certamente não vão estar perfeitas), melhor. Poste aqui, no linkedin, no reddit (sem emojis, eles odeiam) e espere as críticas, elogios, dicas. Não seja chato, não é pra ficar divulgando toda hora.
Apanhe. As pessoas vão falar mal, é normal. Avalie o que é útil pra você e melhore, ignore o que não é útil.

E agora?

Agora vem a parte mais importante. Mantenha o seu projeto.

Se o projeto for útil pra você, isso não vai ser problema. Você mesmo vai precisar corrigir os bugs ou melhorar coisas pro seu próprio uso. Se outras pessoas começarem a usar, a responsabilidade é ainda maior. Enquanto tiver tempo, você deve arrumar bugs importantes pros outros, não só pra você. Eventualmente uma comunidade pode ser criada ao redor do seu projeto, outras pessoas vão contribuindo e melhorando algo que você começou.

Claro que, pra muitos de nós, as prioridades mudam. Se isso acontecer, saiba pedir ajuda. Procure outras pessoas interessadas em manter ou contribuir, tente não simplesmente abandonar o projeto se outras pessoas usam. Lembre de todo mundo que mantém as coisas que você usa.

Conclusão

Pra você que chegou até aqui e passou por algo parecido, quais foram os seus aprendizados? Divulgue seu projeto, comente sobre o que leu (o que concorda, o que discorda), peça ajuda se for o caso.

Se ficou alguma dúvida ou quiser falar sobre algo em particular, aqui está meu Linkedin e Github pra quem se interessar.