Dicas para criar um projeto open source popular
(skerritt.blog)"Efeito de rede: quanto mais pessoas procuram, mais usuários aparecem, mais gente participa, os recursos melhoram e o projeto fica ainda mais conhecido"
Como fazer para ganhar popularidade?
#1. Um README bem projetado
- Explique de forma concisa logo no começo
→ O que isso faz?
→ Resolve o meu problema?
→ Resolve o meu problema melhor do que os concorrentes?
→ Como eu instalo?
→ Quais são os comandos básicos que eu preciso saber?
→ Para onde eu vou se precisar de ajuda?
1.1 Criar um cabeçalho que resuma o projeto
→ Logo: crie um logo em GIF em algo como o Canva
→ Slogan: explique o projeto em uma linha. Use isso na descrição do GitHub
⇨ Deve chamar atenção de imediato
⇨ Por que o usuário precisa disso
⇨ Por que isso é melhor do que as outras opções
⇨ Fácil de entender
⇨ Ex) hugo: The world’s fastest framework for building websites
→ Badges: pequenos itens de imagem/link que explicam o projeto
⇨ atividade recente, número de downloads, quantas pessoas estão no chat, versões em uso, licença etc.
→ Instalação rápida: destaque logo de cara os comandos para instalar de forma simples e rápida
⇨ Para quem já chegou sabendo o que quer possa testar rapidamente
⇨ Mostre o quanto antes coisas como instalação em uma linha via Docker/PIP
⇨ docker run -it --rm remnux/ciphey
→ Links rápidos (não obrigatório)
⇨ site, fórum, documentação, guia de instalação, guia de contribuição, Twitter etc.
1.2 Explicar o projeto de forma concisa em "What is This?"
→ Descrição curta + GIF mostrando o projeto em funcionamento + recursos essenciais que as pessoas vão querer ver
→ Ex) Starship: duas colunas, com os recursos essenciais à esquerda e o GIF de funcionamento à direita
→ Não é preciso mostrar todos os recursos. Liste apenas o que os usuários vão querer ver e explique de forma fácil de entender
1.3 Comparar com concorrentes em "X vs Y"
→ É preciso mostrar por que alguém deve escolher este projeto em vez dos concorrentes
→ Faça com que as vantagens sejam fáceis de enxergar
→ É parecido com a ideia do lean startup de encontrar primeiro os "early adopters" em vez do "usuário médio"
⇨ Pessoas que, se houver recursos melhores, não hesitam em trocar para uma ferramenta nova
→ Só faz sentido mirar no "usuário médio" quando não há concorrentes ou quando as soluções atuais são muito mais complexas do que a sua
→ O jeito mais fácil é criar uma tabela comparando os principais recursos
⇨ Mostre com números em vez de palavras
⇨ Também é bom comparar o funcionamento com GIFs
1.4 Criar uma documentação excelente
→ Não é necessário colocar toda a documentação no README. Isso dificulta atualização e busca, além de deixar o README mais pesado de ler
→ Como o método de instalação já foi mostrado acima, o que vale acrescentar é
⇨ como executar
⇨ onde encontrar a documentação
⇨ como obter suporte
→ Também é bom mostrar a forma de execução com GIFs
1.5 Explicar como contribuir, agradecer e dar boas-vindas aos contribuidores
→ Como contribuir com o projeto
→ Agradecer aos contribuidores anteriores
→ Usar um bot como o all-contributors
#2. Fazer algo que as pessoas queiram
→ Um bom README atrai o interesse das pessoas, e um projeto que "resolve seus problemas" faz com que elas falem sobre ele
2.1 Primeiro vem o problema, depois o produto
→ Em vez de criar algo só para fazer um produto, resolva um problema
→ "O progresso vem não só de grandes saltos, mas também de centenas de pequenos passos"
2.2 Conviver com o problema
→ Sem um problema, não dá para resolvê-lo de forma eficaz
→ Em vez de gerar ideias aleatórias, é muito mais fácil observar os problemas que existem na sua própria vida
→ Quando você percebe que há um problema, descobre duas coisas: que ele existe de fato e que outras pessoas também o têm.
2.3 Encontrar problemas na comunidade
→ Ao observar a comunidade, as pessoas acabam expondo os problemas que enfrentam
→ Quanto mais gente houver e quanto mais você ouvir, mais ideias surgem do que se você tentasse pensar sozinho
→ Tente criar um MVP (Minimum Viable Product) que resolva um problema da comunidade
→ Compartilhe com a comunidade, meça o impacto, aprenda a melhorar e então refaça ou adicione o necessário para evoluir
#3. Colocar para fora
→ Mesmo que esteja bem feito, se você não divulgar, ninguém vai ver
→ Se você usou a comunidade antes, melhor ainda: ela já vai conhecer e usar
→ É difícil fazer um GitHub Star ir de 0 para 1, mas de 10 para 100 é mais fácil
3.1 Compartilhar com a comunidade
→ Loop Build, Measure, Learn
→ No primeiro release real, faça questão de que a comunidade saiba. Eles vão compartilhar com os amigos
3.2 News Aggregators
→ O Subreddit desejado
→ HackerNews
→ Lobste.rs
3.3 Awesome List
→ Encontre listas relacionadas ao tema e envie um PR
2 comentários
Uma história sobre como consegui 500 estrelas no GitHub em apenas um dia
https://black7375.tumblr.com/post/653140399088631808/
Este é um texto que escrevi no passado.
Eu o escrevi com foco na estratégia de divulgação.
Nele, escrevi sobre a forma e o momento de publicar textos de divulgação, além de como defini a direção do desenvolvimento e o prazo de encerramento.
É algo meio óbvio, mas... o README de um projeto open source é realmente importante.
Mesmo que seja um projeto que resolva um problema que ninguém consegue resolver/não quer resolver, ou que tenha recursos incríveis que superem os concorrentes, o resultado pode mudar dependendo de como isso é escrito no README.
Seria ótimo se houvesse mais projetos open source que ficassem conhecidos não só no país, mas também no exterior.
Hoje em dia, vale a pena também dar uma olhada no GitHub About e no README de projetos open source feitos pelos desenvolvedores coreanos mais famosos.
swc : "Make the web (development) faster." swc is a super-fast compiler written in rust; producing widely-supported javascript from modern standards and typescript.
fzf : fzf is a general-purpose command-line fuzzy finder.