Dicas para criar um projeto open source popular
(skerritt.blog)<p>"Efeito de rede: quanto mais pessoas procuram, mais usuários aparecem, mais gente participa, os recursos melhoram e o projeto fica ainda mais conhecido"<br />
Como fazer para ganhar popularidade?<br />
<br />
#1. Um README bem projetado <br />
- Explique de forma concisa logo no começo <br />
→ O que isso faz?<br />
→ Resolve o meu problema?<br />
→ Resolve o meu problema melhor do que os concorrentes?<br />
→ Como eu instalo?<br />
→ Quais são os comandos básicos que eu preciso saber?<br />
→ Para onde eu vou se precisar de ajuda?<br />
<br />
1.1 Criar um cabeçalho que resuma o projeto <br />
→ Logo: crie um logo em GIF em algo como o Canva <br />
→ Slogan: explique o projeto em uma linha. Use isso na descrição do GitHub<br />
⇨ Deve chamar atenção de imediato<br />
⇨ Por que o usuário precisa disso <br />
⇨ Por que isso é melhor do que as outras opções <br />
⇨ Fácil de entender <br />
⇨ Ex) hugo: The world’s fastest framework for building websites<br />
→ Badges: pequenos itens de imagem/link que explicam o projeto <br />
⇨ atividade recente, número de downloads, quantas pessoas estão no chat, versões em uso, licença etc. <br />
→ Instalação rápida: destaque logo de cara os comandos para instalar de forma simples e rápida<br />
⇨ Para quem já chegou sabendo o que quer possa testar rapidamente <br />
⇨ Mostre o quanto antes coisas como instalação em uma linha via Docker/PIP <br />
⇨ docker run -it --rm remnux/ciphey<br />
→ Links rápidos (não obrigatório)<br />
⇨ site, fórum, documentação, guia de instalação, guia de contribuição, Twitter etc.<br />
<br />
1.2 Explicar o projeto de forma concisa em "What is This?" <br />
→ Descrição curta + GIF mostrando o projeto em funcionamento + recursos essenciais que as pessoas vão querer ver <br />
→ Ex) Starship: duas colunas, com os recursos essenciais à esquerda e o GIF de funcionamento à direita <br />
→ 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 <br />
<br />
1.3 Comparar com concorrentes em "X vs Y" <br />
→ É preciso mostrar por que alguém deve escolher este projeto em vez dos concorrentes <br />
→ Faça com que as vantagens sejam fáceis de enxergar<br />
→ É parecido com a ideia do lean startup de encontrar primeiro os "early adopters" em vez do "usuário médio" <br />
⇨ Pessoas que, se houver recursos melhores, não hesitam em trocar para uma ferramenta nova <br />
→ 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 <br />
→ O jeito mais fácil é criar uma tabela comparando os principais recursos<br />
⇨ Mostre com números em vez de palavras <br />
⇨ Também é bom comparar o funcionamento com GIFs <br />
<br />
1.4 Criar uma documentação excelente <br />
→ 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 <br />
→ Como o método de instalação já foi mostrado acima, o que vale acrescentar é <br />
⇨ como executar<br />
⇨ onde encontrar a documentação<br />
⇨ como obter suporte <br />
→ Também é bom mostrar a forma de execução com GIFs <br />
<br />
1.5 Explicar como contribuir, agradecer e dar boas-vindas aos contribuidores <br />
→ Como contribuir com o projeto<br />
→ Agradecer aos contribuidores anteriores <br />
→ Usar um bot como o all-contributors <br />
<br />
#2. Fazer algo que as pessoas queiram <br />
→ Um bom README atrai o interesse das pessoas, e um projeto que "resolve seus problemas" faz com que elas falem sobre ele <br />
<br />
2.1 Primeiro vem o problema, depois o produto<br />
→ Em vez de criar algo só para fazer um produto, resolva um problema <br />
→ "O progresso vem não só de grandes saltos, mas também de centenas de pequenos passos"<br />
<br />
2.2 Conviver com o problema <br />
→ Sem um problema, não dá para resolvê-lo de forma eficaz <br />
→ Em vez de gerar ideias aleatórias, é muito mais fácil observar os problemas que existem na sua própria vida <br />
→ Quando você percebe que há um problema, descobre duas coisas: que ele existe de fato e que outras pessoas também o têm.<br />
<br />
2.3 Encontrar problemas na comunidade <br />
→ Ao observar a comunidade, as pessoas acabam expondo os problemas que enfrentam <br />
→ Quanto mais gente houver e quanto mais você ouvir, mais ideias surgem do que se você tentasse pensar sozinho <br />
→ Tente criar um MVP (Minimum Viable Product) que resolva um problema da comunidade <br />
→ Compartilhe com a comunidade, meça o impacto, aprenda a melhorar e então refaça ou adicione o necessário para evoluir <br />
<br />
#3. Colocar para fora <br />
→ Mesmo que esteja bem feito, se você não divulgar, ninguém vai ver <br />
→ Se você usou a comunidade antes, melhor ainda: ela já vai conhecer e usar <br />
→ É difícil fazer um GitHub Star ir de 0 para 1, mas de 10 para 100 é mais fácil <br />
<br />
3.1 Compartilhar com a comunidade <br />
→ Loop Build, Measure, Learn <br />
→ No primeiro release real, faça questão de que a comunidade saiba. Eles vão compartilhar com os amigos<br />
<br />
3.2 News Aggregators <br />
→ O Subreddit desejado <br />
→ HackerNews<br />
→ Lobste.rs <br />
<br />
3.3 Awesome List <br />
→ Encontre listas relacionadas ao tema e envie um PR </p>
2 comentários