LaunchRepoResposta curta
- Começa pelo próprio repositório: um README que responda ao quê, porquê e como começar, uma licença, até 20 tópicos do GitHub e uma imagem de pré-visualização social.
- Depois vai aonde os teus utilizadores já conversam: o fórum, o chat ou o subreddit da tua linguagem ou framework, e o Show HN quando já se puder executar sem registo.
- Pede aos mantenedores de uma ou duas listas awesome adequadas que te incluam, seguindo as regras de contribuição de cada lista.
- Adiciona um site ou versão alojada a alguns diretórios e plataformas de lançamento, e continua a publicar versões. A atividade constante continua a trazer novos visitantes.
O mapa de distribuição para open source
O open source é descoberto em quatro camadas. Cada uma assenta na anterior: uma publicação numa comunidade envia pessoas para o teu repositório, por isso o repositório tem de as convencer primeiro.
- 1 · O repositórioO que cada visitante vê primeiro.
- README
- Licença
- Tópicos
- Pré-visualização social
- Versões
- 2 · Descoberta no GitHubComo te encontram dentro do GitHub.
- Páginas de tópicos
- Pesquisa do GitHub
- Explore
- Estrelas e listas
- 3 · ComunidadesOnde os teus utilizadores já conversam.
- Show HN
- Fóruns e chats do ecossistema
- Subreddits
- Respostas a perguntas
- 4 · Curado e listadoSítios que continuam a apontar para ti.
- Listas awesome
- Registos de pacotes
- Diretórios
- Newsletters
Cria o teu plano de quatro semanas
Responde a oito perguntas e cola os teus tópicos. O planeador verifica os tópicos segundo as regras do GitHub e coloca cada canal numa semana, marcado como pronto ou com o que tens de corrigir primeiro. Tudo corre no teu browser; nada é enviado nem guardado.
Torna o repositório fácil de encontrar
Todos os canais desta página acabam na página do teu repositório. A própria documentação do GitHub diz a que perguntas um README deve responder; a tabela transforma isso em conteúdo concreto para o primeiro ecrã.
| Parte | O que o visitante precisa | O que funciona |
|---|---|---|
| O que faz | Decidir em segundos se serve para o seu problema | Uma frase por baixo do título, com as palavras que os teus utilizadores pesquisariam |
| Porque é útil | Uma razão para o escolher em vez da alternativa óbvia | Uma diferença concreta ou uma comparação curta |
| Como começar | Um primeiro sucesso em minutos | Um comando de instalação e um exemplo mínimo que funcione tal como é colado |
| Mostra-o a funcionar | Uma prova antes de instalar | Uma captura de ecrã, um GIF ou uma gravação do terminal perto do topo |
| Onde obter ajuda | Confiança de que não vão ficar sozinhos | Põe links para Issues, Discussions ou um chat; diz o que vai para onde |
| Quem o mantém | Confiança de que está vivo | Mantenedores, versão recente, guia de contribuição |
Tópicos: até 20 portas para a pesquisa do GitHub
- Combina os quatro tipos que o GitHub sugere: finalidade (cli, static-site-generator), assunto (accessibility), comunidade (hacktoberfest) e linguagem (rust).
- Usa os tópicos que as pessoas exploram de facto. Abre github.com/topics/ e confirma que um tópico já tem repositórios.
- O GitHub também propõe tópicos para repositórios públicos. Aceita os que fazem sentido e rejeita os restantes.
Pré-visualização social
Sem imagem, um link partilhado mostra dados básicos do repositório e o teu avatar. Uma imagem clara de 1280 × 640 com o nome do projeto e uma linha sobre a sua finalidade torna cada partilha reconhecível. Verifica o tamanho e o formato no verificador gratuito de tamanhos de imagem antes de carregar. Verifica o tamanho das tuas imagens de lançamento por plataforma →
| Regra | Texto oficial | O que significa para ti |
|---|---|---|
| README | A README is often the first item a visitor will see when visiting your repository. | Trata o README como a tua landing page: o primeiro ecrã decide se as pessoas ficam. |
| Tamanho do README | When your README is viewed on GitHub, any content beyond 500 KiB will be truncated. | READMEs longos são cortados. Passa o material de referência extenso para a documentação e põe um link. |
| Tipos de tópicos | Helpful topics to classify a repository include the repository's intended purpose, subject area, community, or language. | Escolhe tópicos de finalidade, assunto, comunidade e linguagem, não dez variantes da mesma palavra. |
| Formato dos tópicos | Use lowercase letters, numbers, and hyphens. Use 50 characters or less. Add no more than 20 topics. | O verificador do planeador aplica exatamente estas três regras. |
| Pré-visualização social | Your image should be a PNG, JPG, or GIF file under 1 MB in size. For the best quality rendering, we recommend a size of at least 640 by 320 pixels (1280 by 640 pixels for best display). | Prepara um PNG ou JPG de 1280 × 640 com menos de 1 MB. |
| Perfil da comunidade | The community profile checklist checks to see if a project includes recommended community health files, such as README, CODE_OF_CONDUCT, LICENSE, or CONTRIBUTING, in a supported location. | Abre Insights → Community Standards no teu repositório e acrescenta o que faltar. |
Listas awesome: dois caminhos diferentes
As listas awesome são coleções curadas no GitHub, uma por tema. As regras citadas com frequência, como os 30 dias e as quatro revisões, aplicam-se a um caso específico. Sabe em que caminho estás.
Caminho A: o teu projeto entra numa lista temática
É o caso habitual para uma biblioteca, ferramenta ou app. Encontra uma ou duas listas ativas sobre o teu tema, lê o ficheiro de contribuição dessa lista e propõe uma linha no formato dela. As listas diferem no que aceitam, por isso a regra é o guia de cada uma. O teu README, a tua licença e a tua atividade recente é que convencem o mantenedor.
Caminho B: a tua lista curada entra na meta-lista awesome
Só se tu próprio mantiveres uma lista. Aí aplica-se o modelo rigoroso da meta-lista: pelo menos 30 dias de idade, rever 4 outros pull requests abertos, correr o awesome-lint, uma licença Creative Commons, os tópicos awesome e awesome-list e um título no formato «Add Name of List».
| Regra | Texto oficial | O que significa para ti |
|---|---|---|
| Entrar numa lista | If you have something awesome to contribute to an awesome list, this is how you do it. | Cada lista explica o seu próprio caminho. Lê o guia de contribuição dessa lista, não um genérico. |
| Idade da lista | That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent. | Só para listas que querem entrar na meta-lista awesome: espera 30 dias após o primeiro commit real. |
| Revisões | Just commenting “looks good” or simply marking the pull request as approved does not count! | Quem submete à meta-lista tem de rever pelo menos 4 outros pull requests abertos, com feedback real. |
| IA | Fully AI-generated pull requests are not accepted. | Escreve tu o pull request. Um totalmente gerado é fechado. |
| Licença | A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. | Uma lista precisa de uma licença Creative Commons, sendo recomendada a CC0. Licenças de código não contam. |
| Qualidade | Only has awesome items. Awesome lists are curations of the best, not everything. | As listas incluem o melhor, não tudo. O teu README e a tua atividade é que te fazem entrar. |
Citamos as regras à data da verificação; os mantenedores atualizam-nas. O LaunchRepo não abre pull requests nem contacta mantenedores de listas por ti.
Comunidades que acolhem projetos
O open source tem aqui uma vantagem: muitas comunidades de programadores gostam de ver um projeto que funciona, desde que resolva um problema real e tu fiques para responder a perguntas.
| Canal | Ideal para | Primeiro passo |
|---|---|---|
| Show HN (Hacker News) | Ferramentas que se podem executar logo | Publica uma vez, fica na discussão e responde a todas as perguntas |
| O fórum ou chat do teu ecossistema | Bibliotecas e plugins para uma linguagem ou framework | Lê as regras de apresentação de projetos e publica um caso de uso, não um slogan |
| Um subreddit adequado | Projetos com um público claro no Reddit | Verifica primeiro a regra de autopromoção de cada subreddit |
| Respostas a perguntas | Projetos que resolvem uma pergunta recorrente | Responde à pergunta por completo; menciona o projeto onde ajuda de verdade |
| Newsletters semanais do teu ecossistema | Versões com uma história | Envia aos editores uma nota curta com o link da versão |
| Meetups e palestras em conferências | Projetos com uma lição para ensinar | Começa num meetup local da tua linguagem |
No nosso conjunto de dados público com todas as 15.859 publicações do Show HN que apontavam para um repositório de código entre setembro de 2025 e agosto de 2026, a publicação mediana teve 2 pontos e 9,5% chegaram a 10 pontos ou mais. Uma publicação é um começo, não o plano.
Como lançar o teu projeto no Show HN →Promove o teu SaaS no Reddit sem quebrar as regras →
| Regra | Texto oficial | O que significa para ti |
|---|---|---|
| O que encaixa | Show HN is for something you've made that other people can play with. | Algo que as pessoas possam executar, não um anúncio nem uma landing page. |
| Substância | The project should be non-trivial. Don't post quickly-generated one-offs; anybody can do that now. | Publica um projeto em que tenhas posto trabalho a sério e sobre o qual consigas falar. |
| Barreiras | Please make it easy for users to try your thing out, ideally without barriers such as signups or emails. | Um repositório público com um só comando de instalação é o Show HN ideal. |
| Votos | Please don't ask friends to upvote or comment. That's not ok on HN. | Partilha o link sem pedir votos. Deixa o trabalho falar por si. |
| Público-alvo | Don’t spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project. | Escolhe algumas comunidades onde o projeto resolve um problema real. |
| Reputação | the best way to invite people to share and contribute to your project is to share and contribute to their projects. | Ajuda primeiro noutros projetos. As pessoas reparam e vão ver o teu. |
Diretórios e plataformas de lançamento
Assim que existe um site, um site de documentação ou uma versão alojada, alguns diretórios tornam-se uma fonte extra e constante de visitantes e links. Três que se adequam bem a open source:
- AlternativeTo: quando o teu projeto é uma alternativa gratuita a software conhecido.
- SourceForge: aloja projetos open source com downloads através da sua via Create a Project, separada das fichas de software empresarial.
- Product Hunt: para projetos com uma interface cuidada e um dia de lançamento em que possas estar presente.
Escolhe as plataformas pela adequação ao público e verifica as regras atuais de cada uma; uma listagem é uma porta, não uma garantia de utilizadores. Lança a tua ferramenta para developers em 299 diretórios com o teu próprio agente →
O que deixar de fora
- Estrelas compradas ou trocadas
- As políticas do GitHub proíbem o abuso de rankings, e a investigação mostra que as estrelas compradas só ajudam por pouco tempo. Os pormenores, com a nossa própria medição: Ganhar estrelas no GitHub sendo útil a sério →
- Pedir votos aos amigos
- O Hacker News di-lo claramente: isso não está bem. Além disso, os votos de um grupo de amigos não te dizem nada sobre o interesse real.
- A mesma publicação em todo o lado
- Anúncios copiados e colados em muitas comunidades no mesmo dia parecem spam. Escolhe poucos sítios e escreve para cada um.
- Um lançamento antes do README
- A atenção é curta. Corrige o primeiro ecrã do repositório antes de publicar seja o que for.
Onde entra o LaunchRepo
O LaunchRepo trata da camada dos diretórios e plataformas de lançamento: o teu agente de programação prepara e submete o site do teu projeto a um grande catálogo de diretórios, com um acompanhamento que distingue uma listagem publicada de uma pendente.
As publicações em comunidades, os pedidos a listas awesome e as conversas ficam contigo, porque funcionam melhor com a tua própria voz. O LaunchRepo liberta as horas que os formulários levariam, para que as possas passar aí.
Fontes
Todas as regras foram lidas a 1 de outubro de 2026 e são citadas palavra por palavra em inglês. Guardamos cópias do texto com as nossas provas.
| Fonte | Última atualização | Verificado |
|---|---|---|
| GitHub Docs: About the repository README file | sem data indicada | |
| GitHub Docs: Classifying your repository with topics | sem data indicada | |
| GitHub Docs: Customizing your repository's social media preview | sem data indicada | |
| GitHub Docs: About community profiles for public repositories | sem data indicada | |
| GitHub Docs: Accessing a project's community profile | sem data indicada | |
| GitHub Docs: Saving repositories with stars | sem data indicada | |
| sindresorhus/awesome: pull request template | sem data indicada | |
| sindresorhus/awesome: contribution guidelines | sem data indicada | |
| Hacker News: Show HN Guidelines | sem data indicada | |
| Open Source Guides: Finding Users for Your Project | sem data indicada | |
| GitHub Acceptable Use Policies | sem data indicada | |
| He et al.: Six Million (Suspected) Fake Stars in GitHub (ICSE 2026, arXiv:2412.13459v2) |
Perguntas frequentes
- Como promovo um projeto open source?
- Começa pelo repositório: um README que responda ao quê, porquê e como começar, uma licença, tópicos e uma imagem de pré-visualização. Depois partilha-o na comunidade do teu ecossistema e no Show HN quando já se puder experimentar sem registo, pede inclusão numa ou duas listas awesome adequadas e continua a publicar versões.
- Como ponho o meu projeto numa lista awesome?
- Abre a lista, lê o ficheiro de contribuição e propõe uma entrada no formato dela. As regras rigorosas (30 dias, quatro revisões, awesome-lint) só se aplicam quando submetes a tua própria lista curada à meta-lista awesome.
- Quantos tópicos do GitHub devo adicionar?
- O GitHub permite até 20. Usa os que descrevem finalidade, assunto, comunidade e linguagem, escritos em minúsculas, números e hífenes, cada um com 50 caracteres ou menos.
- O Show HN é um bom sítio para open source?
- Sim, se as pessoas puderem executar o projeto logo e tu puderes ficar para responder a perguntas. O Show HN pede algo que se possa experimentar, sem barreiras de registo e sem pedidos de votos aos amigos.
- Devo comprar estrelas no GitHub para parecer consolidado?
- Não. As Acceptable Use Policies do GitHub proíbem o abuso de rankings, como dar estrelas de forma automatizada, e um grande estudo concluiu que as estrelas compradas só ajudam por pouco tempo e prejudicam a longo prazo.
- O LaunchRepo publica em comunidades por mim?
- Não. O LaunchRepo dá ao teu agente os playbooks para as submissões a diretórios e plataformas de lançamento para o site do teu projeto. As publicações em comunidades e os pedidos a listas awesome continuam a ser pessoais.
Deixa os diretórios com o teu agente
Uma só compra, o teu agente de programação, todos os produtos que criares: o teu agente de programação usa o LaunchRepo para submeter o site do teu projeto a diretórios e plataformas de lançamento enquanto tu falas com os teus utilizadores.
Ver preços