Respuesta corta
- Empieza por el propio repositorio: un README que responda qué es, por qué y cómo empezar, una licencia, hasta 20 temas de GitHub y una imagen de vista previa social.
- Después ve adonde ya hablan tus usuarios: el foro, el chat o el subreddit de tu lenguaje o framework, y Show HN cuando se pueda ejecutar sin registrarse.
- Pide a los mantenedores de una o dos listas awesome adecuadas que te incluyan, siguiendo las reglas de contribución de cada lista.
- Añade una web o versión alojada a unos cuantos directorios y plataformas de lanzamiento, y sigue publicando versiones. La actividad constante sigue atrayendo visitantes nuevos.
El mapa de distribución del código abierto
El código abierto se descubre en cuatro capas. Cada una se apoya en la anterior: una publicación en una comunidad envía gente a tu repositorio, así que el repositorio tiene que convencerla primero.
- 1 · El repositorioLo primero que ve cada visitante.
- README
- Licencia
- Temas
- Vista previa social
- Versiones
- 2 · Descubrimiento en GitHubCómo te encuentran dentro de GitHub.
- Páginas de temas
- Búsqueda de GitHub
- Explore
- Estrellas y listas
- 3 · ComunidadesDonde ya hablan tus usuarios.
- Show HN
- Foros y chats del ecosistema
- Subreddits
- Respuestas a preguntas
- 4 · Curado y listadoSitios que siguen apuntando a ti.
- Listas awesome
- Registros de paquetes
- Directorios
- Newsletters
Crea tu plan de cuatro semanas
Responde ocho preguntas y pega tus temas. El planificador comprueba los temas con las reglas de GitHub y coloca cada canal en una semana, marcado como listo o con lo que debes arreglar antes. Todo se ejecuta en tu navegador; no se envía ni se guarda nada.
Haz que el repositorio se encuentre
Todos los canales de esta página terminan en la página de tu repositorio. La propia documentación de GitHub dice qué debe responder un README; la tabla lo convierte en contenido concreto para la primera pantalla.
| Parte | Qué necesita el visitante | Qué funciona |
|---|---|---|
| Qué hace | Decidir en segundos si encaja con su problema | Una frase bajo el título, con las palabras que buscarían tus usuarios |
| Por qué es útil | Un motivo para elegirlo frente a la alternativa obvia | Una diferencia concreta o una comparación breve |
| Cómo empezar | Un primer éxito en minutos | Un comando de instalación y un ejemplo mínimo que funcione tal cual se pega |
| Muéstralo funcionando | Una prueba antes de instalar | Una captura, un GIF o una grabación de terminal cerca del principio |
| Dónde pedir ayuda | Confianza en que no los dejarás solos | Enlaza Issues, Discussions o un chat; di qué va en cada sitio |
| Quién lo mantiene | Seguridad de que está vivo | Mantenedores, versión reciente, guía de contribución |
Temas: hasta 20 puertas a la búsqueda de GitHub
- Combina los cuatro tipos que sugiere GitHub: propósito (cli, static-site-generator), materia (accessibility), comunidad (hacktoberfest) y lenguaje (rust).
- Usa los temas que la gente explora de verdad. Abre github.com/topics/ y comprueba que un tema ya tiene repositorios.
- GitHub también propone temas para los repositorios públicos. Acepta los que encajen y rechaza el resto.
Vista previa social
Sin imagen, un enlace compartido muestra datos básicos del repositorio y tu avatar. Una imagen clara de 1280 × 640 con el nombre del proyecto y una línea sobre su propósito hace que cada enlace compartido sea reconocible. Comprueba el tamaño y el formato en el comprobador gratuito de tamaños de imagen antes de subirla. Comprueba el tamaño de tus imágenes de lanzamiento por plataforma →
| Regla | Texto oficial | Qué significa para ti |
|---|---|---|
| README | A README is often the first item a visitor will see when visiting your repository. | Trata el README como tu landing page: la primera pantalla decide si la gente se queda. |
| Tamaño del README | When your README is viewed on GitHub, any content beyond 500 KiB will be truncated. | Los README largos se recortan. Lleva el material de referencia extenso a la documentación y enlázalo. |
| Tipos de temas | Helpful topics to classify a repository include the repository's intended purpose, subject area, community, or language. | Elige temas de propósito, materia, comunidad y lenguaje, no diez variantes de la misma palabra. |
| Formato de los temas | Use lowercase letters, numbers, and hyphens. Use 50 characters or less. Add no more than 20 topics. | El comprobador del planificador aplica exactamente estas tres reglas. |
| Vista previa 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 un PNG o JPG de 1280 × 640 de menos de 1 MB. |
| Perfil de comunidad | 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 en tu repositorio y añade lo que falte. |
Listas awesome: dos caminos distintos
Las listas awesome son colecciones curadas en GitHub, una por tema. Las reglas que se citan a menudo, como los 30 días y las cuatro revisiones, se aplican a un caso concreto. Ten claro en qué camino estás.
Camino A: tu proyecto entra en una lista temática
Es el caso habitual para una biblioteca, una herramienta o una app. Busca una o dos listas activas de tu tema, lee el archivo de contribución de esa lista y propón una línea en su formato. Las listas difieren en lo que aceptan, así que manda su propia guía. Tu README, tu licencia y tu actividad reciente son lo que convence al mantenedor.
Camino B: tu lista curada entra en la metalista awesome
Solo si mantienes una lista tú mismo. Entonces se aplica la plantilla estricta de la metalista: al menos 30 días de antigüedad, revisar 4 pull requests abiertas de otros, pasar awesome-lint, una licencia Creative Commons, los temas awesome y awesome-list y un título con la forma «Add Name of List».
| Regla | Texto oficial | Qué significa para ti |
|---|---|---|
| Entrar en una lista | If you have something awesome to contribute to an awesome list, this is how you do it. | Cada lista explica su propio camino. Lee la guía de contribución de esa lista, no una genérica. |
| Antigüedad de la lista | That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent. | Solo para listas que quieren entrar en la metalista awesome: espera 30 días desde el primer commit real. |
| Revisiones | Just commenting “looks good” or simply marking the pull request as approved does not count! | Quien envía a la metalista debe revisar al menos 4 pull requests abiertas de otros, con comentarios reales. |
| IA | Fully AI-generated pull requests are not accepted. | Escribe tú la pull request. Una generada por completo se cierra. |
| Licencia | A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. | Una lista necesita una licencia Creative Commons, se recomienda CC0. Las licencias de código no cuentan. |
| Calidad | Only has awesome items. Awesome lists are curations of the best, not everything. | Las listas incluyen lo mejor, no todo. Lo que te hace entrar son tu README y tu actividad. |
Citamos las reglas a la fecha de revisión; los mantenedores las actualizan. LaunchRepo no abre pull requests ni contacta con mantenedores de listas por ti.
Comunidades que reciben bien los proyectos
El código abierto tiene aquí una ventaja: muchas comunidades de desarrolladores agradecen ver un proyecto que funciona, siempre que resuelva un problema real y te quedes a responder preguntas.
| Canal | Ideal para | Primer paso |
|---|---|---|
| Show HN (Hacker News) | Herramientas que se pueden ejecutar enseguida | Publica una vez, quédate en el hilo y responde a cada pregunta |
| El foro o chat de tu ecosistema | Bibliotecas y plugins para un lenguaje o framework | Lee las reglas de presentación de proyectos y publica un caso de uso, no un eslogan |
| Un subreddit adecuado | Proyectos con un público claro en Reddit | Revisa antes la regla de autopromoción de cada subreddit |
| Respuestas a preguntas | Proyectos que resuelven una pregunta recurrente | Responde a la pregunta por completo; menciona el proyecto donde ayude de verdad |
| Newsletters semanales de tu ecosistema | Versiones con una historia detrás | Envía a los editores una nota breve con el enlace a la versión |
| Meetups y charlas en conferencias | Proyectos con una lección que enseñar | Empieza en un meetup local de tu lenguaje |
En nuestro conjunto de datos público con las 15.859 publicaciones de Show HN que enlazaron un repositorio de código entre septiembre de 2025 y agosto de 2026, la publicación mediana obtuvo 2 puntos y el 9,5 % alcanzó 10 puntos o más. Una publicación es un comienzo, no el plan.
Cómo lanzar tu proyecto en Show HN →Promociona tu SaaS en Reddit sin saltarte las reglas →
| Regla | Texto oficial | Qué significa para ti |
|---|---|---|
| Qué encaja | Show HN is for something you've made that other people can play with. | Algo que la gente pueda ejecutar, no un anuncio ni una landing page. |
| Sustancia | The project should be non-trivial. Don't post quickly-generated one-offs; anybody can do that now. | Publica un proyecto en el que hayas trabajado de verdad y del que puedas hablar. |
| Barreras | Please make it easy for users to try your thing out, ideally without barriers such as signups or emails. | Un repositorio público con un solo comando de instalación es el Show HN ideal. |
| Votos | Please don't ask friends to upvote or comment. That's not ok on HN. | Comparte el enlace sin pedir votos. Deja que el trabajo hable. |
| Público | Don’t spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project. | Elige unas pocas comunidades donde el proyecto resuelva un problema real. |
| Reputación | the best way to invite people to share and contribute to your project is to share and contribute to their projects. | Ayuda primero en otros proyectos. La gente lo nota y mira el tuyo. |
Directorios y plataformas de lanzamiento
En cuanto hay una web, un sitio de documentación o una versión alojada, unos cuantos directorios se convierten en una fuente extra y constante de visitas y enlaces. Tres que encajan bien con el código abierto:
- AlternativeTo: cuando tu proyecto es una alternativa gratuita a un software conocido.
- SourceForge: aloja proyectos de código abierto con descargas a través de su vía Create a Project, separada de sus fichas de software empresarial.
- Product Hunt: para proyectos con una interfaz pulida y un día de lanzamiento al que puedas dedicarte.
Elige las plataformas según el encaje con su público y revisa las reglas actuales de cada una; una ficha es una puerta, no una garantía de usuarios. Lanza tu herramienta para desarrolladores en 299 directorios con tu propio agente →
Qué dejar fuera
- Estrellas compradas o intercambiadas
- Las políticas de GitHub prohíben el abuso de rankings, y la investigación muestra que las estrellas compradas solo ayudan un tiempo breve. Los detalles, con nuestra propia medición: Ganar estrellas en GitHub siendo útil de verdad →
- Pedir votos a tus amigos
- Hacker News lo dice claramente: eso no está bien. Además, los votos de un grupo de amigos no te dicen nada sobre el interés real.
- La misma publicación en todas partes
- Los anuncios copiados y pegados en muchas comunidades el mismo día parecen spam. Elige unos pocos sitios y escribe para cada uno.
- Lanzar antes que el README
- La atención dura poco. Arregla la primera pantalla del repositorio antes de publicar nada.
Dónde encaja LaunchRepo
LaunchRepo se encarga de la capa de directorios y plataformas de lanzamiento: tu agente de programación prepara y envía la web de tu proyecto a un amplio catálogo de directorios, con un seguimiento que distingue una ficha publicada de una pendiente.
Las publicaciones en comunidades, las peticiones a listas awesome y las conversaciones siguen siendo cosa tuya, porque funcionan mejor con tu propia voz. LaunchRepo te libera las horas que te llevarían los formularios para que puedas dedicarlas a eso.
Fuentes
Todas las reglas se leyeron el 1 de octubre de 2026 y se citan palabra por palabra en inglés. Guardamos copias del texto junto con nuestras pruebas.
| Fuente | Última actualización | Revisado |
|---|---|---|
| GitHub Docs: About the repository README file | sin fecha indicada | |
| GitHub Docs: Classifying your repository with topics | sin fecha indicada | |
| GitHub Docs: Customizing your repository's social media preview | sin fecha indicada | |
| GitHub Docs: About community profiles for public repositories | sin fecha indicada | |
| GitHub Docs: Accessing a project's community profile | sin fecha indicada | |
| GitHub Docs: Saving repositories with stars | sin fecha indicada | |
| sindresorhus/awesome: pull request template | sin fecha indicada | |
| sindresorhus/awesome: contribution guidelines | sin fecha indicada | |
| Hacker News: Show HN Guidelines | sin fecha indicada | |
| Open Source Guides: Finding Users for Your Project | sin fecha indicada | |
| GitHub Acceptable Use Policies | sin fecha indicada | |
| He et al.: Six Million (Suspected) Fake Stars in GitHub (ICSE 2026, arXiv:2412.13459v2) |
Preguntas frecuentes
- ¿Cómo promociono un proyecto de código abierto?
- Empieza por el repositorio: un README que responda qué es, por qué y cómo empezar, una licencia, temas y una imagen de vista previa. Después compártelo en la comunidad de tu ecosistema y en Show HN cuando se pueda probar sin registrarse, pide la inclusión en una o dos listas awesome adecuadas y sigue publicando versiones.
- ¿Cómo meto mi proyecto en una lista awesome?
- Abre la lista, lee su archivo de contribución y propón una entrada en su formato. Las reglas estrictas (30 días, cuatro revisiones, awesome-lint) solo se aplican cuando envías tu propia lista curada a la metalista awesome.
- ¿Cuántos temas de GitHub debo añadir?
- GitHub permite hasta 20. Usa los que describan propósito, materia, comunidad y lenguaje, escritos con minúsculas, números y guiones, de 50 caracteres o menos cada uno.
- ¿Es Show HN un buen sitio para el código abierto?
- Sí, si la gente puede ejecutar el proyecto enseguida y tú puedes quedarte a responder preguntas. Show HN pide algo que se pueda probar, sin barreras de registro y sin pedir votos a los amigos.
- ¿Debería comprar estrellas de GitHub para parecer consolidado?
- No. Las Acceptable Use Policies de GitHub prohíben el abuso de rankings, como dar estrellas de forma automatizada, y un gran estudio encontró que las estrellas compradas solo ayudan un tiempo breve y perjudican a largo plazo.
- ¿LaunchRepo publica en comunidades por mí?
- No. LaunchRepo da a tu agente los playbooks para los envíos a directorios y plataformas de lanzamiento de la web de tu proyecto. Las publicaciones en comunidades y las peticiones a listas awesome siguen siendo personales.
Deja los directorios a tu agente
Una sola compra, tu agente de programación, cada producto que crees: tu agente de programación usa LaunchRepo para enviar la web de tu proyecto a directorios y plataformas de lanzamiento mientras tú hablas con tus usuarios.
Ver precios