LaunchRepoRisposta breve
- Parti dal repository: un README che spiega cosa fa, perché e come iniziare, una licenza, fino a 20 topic GitHub e un’immagine di anteprima social.
- Poi vai dove i tuoi utenti parlano già: il forum, la chat o il subreddit del tuo linguaggio o framework, e Show HN appena le persone possono eseguirlo senza registrarsi.
- Chiedi ai maintainer di una o due awesome list adatte, seguendo le regole di contribuzione di ciascuna lista.
- Aggiungi un sito web o una versione ospitata a qualche directory e piattaforma di lancio, e continua a pubblicare release. Un’attività costante continua a portare nuovi visitatori.
La mappa della distribuzione per l’open source
Nell’open source la scoperta avviene su quattro livelli. Ognuno poggia sul precedente: un post in una community manda le persone al tuo repository, quindi è il repository che deve convincerle per primo.
- 1 · Il repositoryQuello che ogni visitatore vede per primo.
- README
- Licenza
- Topic
- Anteprima social
- Release
- 2 · La scoperta su GitHubCome ti trovano dentro GitHub.
- Pagine dei topic
- Ricerca GitHub
- Explore
- Stelle e liste
- 3 · Le communityDove i tuoi utenti parlano già.
- Show HN
- Forum e chat dell’ecosistema
- Subreddit
- Risposte nei Q&A
- 4 · Selezionato e catalogatoI posti che continuano a rimandare a te.
- Awesome list
- Registri di pacchetti
- Directory
- Newsletter
Crea il tuo piano di quattro settimane
Rispondi a otto domande e incolla i tuoi topic. Il pianificatore controlla i topic secondo le regole di GitHub e assegna ogni canale a una settimana, segnandolo come pronto o indicando cosa sistemare prima. Tutto gira nel tuo browser; nulla viene inviato o salvato.
Rendi il repository facile da trovare
Ogni canale di questa pagina porta alla pagina del tuo repository. La documentazione di GitHub indica a cosa deve rispondere un README; la tabella lo traduce in contenuti concreti per la prima schermata.
| Parte | Cosa serve al visitatore | Cosa funziona |
|---|---|---|
| Cosa fa | Decidere in pochi secondi se fa al caso suo | Una frase sotto il titolo, con le parole che i tuoi utenti cercherebbero |
| Perché è utile | Un motivo per sceglierlo al posto dell’alternativa ovvia | Una differenza concreta o un breve confronto |
| Come iniziare | Un primo successo in pochi minuti | Un comando di installazione e un esempio minimo che funziona appena incollato |
| Mostralo in azione | Una prova prima di installare | Uno screenshot, una GIF o una registrazione del terminale in alto |
| Dove trovare aiuto | La fiducia di non essere lasciati soli | Collega Issues, Discussions o una chat; spiega cosa va dove |
| Chi lo mantiene | La certezza che il progetto è vivo | Maintainer, release recente, guida per contribuire |
Topic: fino a 20 porte d’ingresso nella ricerca di GitHub
- Combina i quattro tipi suggeriti da GitHub: scopo (cli, static-site-generator), argomento (accessibility), community (hacktoberfest) e linguaggio (rust).
- Usa i topic che le persone sfogliano davvero. Apri github.com/topics/ e verifica che un topic contenga già dei repository.
- GitHub propone anche dei topic per i repository pubblici. Accetta quelli adatti e rifiuta gli altri.
Anteprima social
Senza immagine, un link condiviso mostra i dati di base del repository e il tuo avatar. Un’immagine chiara da 1280 × 640 con il nome del progetto e una riga sul suo scopo rende riconoscibile ogni condivisione. Controlla dimensioni e formato con il verificatore gratuito delle dimensioni delle immagini prima di caricarla. Verifica le dimensioni delle tue immagini di lancio per piattaforma →
| Regola | Testo ufficiale | Cosa significa per te |
|---|---|---|
| README | A README is often the first item a visitor will see when visiting your repository. | Tratta il README come la tua landing page: la prima schermata decide se le persone restano. |
| Dimensione del README | When your README is viewed on GitHub, any content beyond 500 KiB will be truncated. | I README lunghi vengono tagliati. Sposta il materiale di riferimento dettagliato nella documentazione e aggiungi un link. |
| Tipi di topic | Helpful topics to classify a repository include the repository's intended purpose, subject area, community, or language. | Scegli topic che coprano scopo, argomento, community e linguaggio, non dieci varianti della stessa parola. |
| Formato dei topic | Use lowercase letters, numbers, and hyphens. Use 50 characters or less. Add no more than 20 topics. | Il controllo del pianificatore applica esattamente queste tre regole. |
| Anteprima 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 da 1280 × 640 sotto 1 MB. |
| Profilo della community | 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. | Apri Insights → Community Standards nel tuo repository e aggiungi ciò che manca. |
Awesome list: due strade diverse
Le awesome list sono raccolte curate su GitHub, una per argomento. Le regole citate spesso, come i 30 giorni e le quattro revisioni, valgono per un caso specifico. Sappi su quale strada sei.
Strada A: il tuo progetto entra in una lista tematica
È il caso tipico per una libreria, un tool o un’app. Trova una o due liste attive sul tuo argomento, leggi il file di contribuzione di quella lista e proponi una riga nel suo formato. Le liste accettano cose diverse, quindi la regola è la loro guida. A convincere il maintainer sono il tuo README, la licenza e l’attività recente.
Strada B: la tua lista curata entra nella meta-lista awesome
Solo se mantieni tu stesso una lista. Allora vale il template rigoroso della meta-lista: almeno 30 giorni di vita, revisionare 4 altre pull request aperte, eseguire awesome-lint, una licenza Creative Commons, i topic awesome e awesome-list e un titolo nella forma “Add Name of List”.
| Regola | Testo ufficiale | Cosa significa per te |
|---|---|---|
| Aggiunta a una lista | If you have something awesome to contribute to an awesome list, this is how you do it. | Ogni lista spiega la propria procedura. Leggi la guida per contribuire di quella lista, non una generica. |
| Età della lista | That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent. | Solo per le liste che vogliono entrare nella meta-lista awesome: aspetta 30 giorni dal primo vero commit. |
| Revisioni | Just commenting “looks good” or simply marking the pull request as approved does not count! | Chi propone una lista alla meta-lista deve revisionare almeno 4 altre pull request aperte, con feedback reali. |
| AI | Fully AI-generated pull requests are not accepted. | Scrivi tu la pull request. Una generata interamente viene chiusa. |
| Licenza | A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. | Una lista ha bisogno di una licenza Creative Commons, consigliata CC0. Le licenze per il codice non valgono. |
| Qualità | Only has awesome items. Awesome lists are curations of the best, not everything. | Le liste includono il meglio, non tutto. Sono il tuo README e la tua attività a farti entrare. |
Citiamo le regole alla data della verifica; i maintainer le aggiornano. LaunchRepo non apre pull request e non contatta i maintainer delle liste al posto tuo.
Community che accolgono i progetti
Qui l’open source ha un vantaggio: molte community di sviluppatori sono felici di vedere un progetto funzionante, purché risolva un problema reale e tu resti a rispondere alle domande.
| Canale | Ideale per | Primo passo |
|---|---|---|
| Show HN (Hacker News) | Tool che si possono eseguire subito | Pubblica una volta, resta nel thread, rispondi a ogni domanda |
| Il forum o la chat del tuo ecosistema | Librerie e plugin per un linguaggio o framework | Leggi le regole per presentare progetti, poi pubblica un caso d’uso, non uno slogan |
| Un subreddit adatto | Progetti con un pubblico chiaro su Reddit | Controlla prima la regola sull’autopromozione di ogni subreddit |
| Risposte nei Q&A | Progetti che risolvono una domanda ricorrente | Rispondi alla domanda in modo completo; cita il progetto dove aiuta davvero |
| Newsletter settimanali del tuo ecosistema | Release con una storia da raccontare | Manda alla redazione una breve nota con il link alla release |
| Meetup e talk alle conferenze | Progetti con una lezione da insegnare | Inizia da un meetup locale del tuo linguaggio |
Nel nostro dataset pubblico di tutti i 15.859 post Show HN che rimandavano a un repository di codice tra settembre 2025 e agosto 2026, il post mediano ha ottenuto 2 punti e il 9,5% ha raggiunto 10 punti o più. Un post è un inizio, non il piano.
Come lanciare il tuo progetto su Show HN →Promuovi il tuo SaaS su Reddit senza violare le regole →
| Regola | Testo ufficiale | Cosa significa per te |
|---|---|---|
| Cosa è adatto | Show HN is for something you've made that other people can play with. | Qualcosa che le persone possono eseguire, non un annuncio o una landing page. |
| Sostanza | The project should be non-trivial. Don't post quickly-generated one-offs; anybody can do that now. | Pubblica un progetto su cui hai lavorato davvero e di cui sai parlare. |
| Ostacoli | Please make it easy for users to try your thing out, ideally without barriers such as signups or emails. | Un repository pubblico con un solo comando di installazione è lo Show HN ideale. |
| Voti | Please don't ask friends to upvote or comment. That's not ok on HN. | Condividi il link senza chiedere voti. Lascia parlare il lavoro. |
| Obiettivo | Don’t spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project. | Scegli poche community in cui il progetto risolve un problema reale. |
| Reputazione | the best way to invite people to share and contribute to your project is to share and contribute to their projects. | Prima aiuta in altri progetti. Le persone lo notano e guardano il tuo. |
Directory e piattaforme di lancio
Quando c’è un sito web, un sito di documentazione o una versione ospitata, qualche directory diventa una fonte costante di visitatori e link in più. Tre adatte all’open source:
- AlternativeTo: quando il tuo progetto è un’alternativa gratuita a un software noto.
- SourceForge: ospita progetti open source con download tramite il percorso Create a Project, separato dalle sue schede di software aziendale.
- Product Hunt: per progetti con un’interfaccia curata e un giorno di lancio a cui puoi essere presente.
Scegli le piattaforme in base al pubblico e controlla le regole attuali di ciascuna; una scheda è una porta, non una garanzia di utenti. Pubblica il tuo strumento per sviluppatori dove gli sviluppatori cercano davvero. →
Cosa lasciare fuori
- Stelle comprate o scambiate
- Le policy di GitHub vietano la manipolazione delle classifiche, e la ricerca mostra che le stelle comprate aiutano solo per poco. I dettagli, con la nostra misurazione: Guadagnare stelle su GitHub essendo davvero utili →
- Chiedere agli amici di votare
- Hacker News lo dice chiaramente: non va bene. E i voti di un gruppo di amici non dicono nulla sull’interesse reale.
- Lo stesso post ovunque
- Annunci copiati e incollati in tante community nello stesso giorno sembrano spam. Scegli pochi posti e scrivi per ciascuno.
- Un lancio prima del README
- L’attenzione dura poco. Sistema la prima schermata del repository prima di pubblicare qualsiasi post.
Dove si inserisce LaunchRepo
LaunchRepo si occupa del livello delle directory e delle piattaforme di lancio: il tuo coding agent prepara e invia il sito del tuo progetto a un ampio catalogo di directory, con un tracker che distingue una scheda online da una in attesa.
Post nelle community, richieste alle awesome list e conversazioni restano a te, perché funzionano meglio con la tua voce. LaunchRepo ti libera le ore che porterebbero via i moduli, così puoi dedicarle a quello.
Fonti
Tutte le regole sono state lette in data 1 ottobre 2026 e sono citate parola per parola in inglese. Le copie testuali sono conservate con le nostre prove.
| Fonte | Ultimo aggiornamento | Verificato |
|---|---|---|
| GitHub Docs: About the repository README file | nessuna data indicata | |
| GitHub Docs: Classifying your repository with topics | nessuna data indicata | |
| GitHub Docs: Customizing your repository's social media preview | nessuna data indicata | |
| GitHub Docs: About community profiles for public repositories | nessuna data indicata | |
| GitHub Docs: Accessing a project's community profile | nessuna data indicata | |
| GitHub Docs: Saving repositories with stars | nessuna data indicata | |
| sindresorhus/awesome: pull request template | nessuna data indicata | |
| sindresorhus/awesome: contribution guidelines | nessuna data indicata | |
| Hacker News: Show HN Guidelines | nessuna data indicata | |
| Open Source Guides: Finding Users for Your Project | nessuna data indicata | |
| GitHub Acceptable Use Policies | nessuna data indicata | |
| He et al.: Six Million (Suspected) Fake Stars in GitHub (ICSE 2026, arXiv:2412.13459v2) |
Domande frequenti
- Come si promuove un progetto open source?
- Parti dal repository: un README che spiega cosa fa, perché e come iniziare, una licenza, i topic e un’immagine di anteprima. Poi condividilo nella community del tuo ecosistema e su Show HN appena si può provare senza registrarsi, chiedi a una o due awesome list adatte e continua a pubblicare release.
- Come faccio a far entrare il mio progetto in una awesome list?
- Apri la lista, leggi il suo file di contribuzione e proponi una voce nel suo formato. Le regole rigorose (30 giorni, quattro revisioni, awesome-lint) valgono solo quando proponi la tua lista curata alla meta-lista awesome.
- Quanti topic GitHub dovrei aggiungere?
- GitHub ne consente fino a 20. Usa quelli che descrivono scopo, argomento, community e linguaggio, scritti in lettere minuscole, numeri e trattini, ciascuno di 50 caratteri o meno.
- Show HN è un buon posto per l’open source?
- Sì, se le persone possono eseguire subito il progetto e tu puoi restare a rispondere alle domande. Show HN chiede qualcosa che si possa provare, senza ostacoli di registrazione, e nessuna richiesta di voti agli amici.
- Dovrei comprare stelle GitHub per sembrare affermato?
- No. Le Acceptable Use Policies di GitHub vietano la manipolazione delle classifiche, come l’assegnazione automatica di stelle, e un ampio studio ha rilevato che le stelle comprate aiutano solo per poco e danneggiano nel lungo periodo.
- LaunchRepo pubblica nelle community al posto mio?
- No. LaunchRepo dà al tuo agente i playbook per gli invii alle directory e alle piattaforme di lancio per il sito del tuo progetto. Post nelle community e richieste alle awesome list restano personali.
Lascia le directory al tuo agente
Un solo acquisto, il tuo coding agent, ogni prodotto che costruisci: il tuo coding agent usa LaunchRepo per inviare il sito del tuo progetto a directory e piattaforme di lancio mentre tu parli con i tuoi utenti.
Vedi i prezzi