Come promuovere un progetto open source

Il giorno del lancio, e tutti i giorni dopo

Il giorno del lancio porta un picco di visite, poi il silenzio. Quasi tutti quelli che adotteranno il progetto nel corso dell’anno lo trovano più tardi, in thread come questi:

• Un’alternativa self-hosted a un’app per le note, con crittografia end-to-end e sincronizzazione su mobile?
• Quale libreria Python estrae le tabelle dai PDF senza bloccarsi sui documenti scansionati?
• Questo progetto è ancora mantenuto? L’ultima release sembra vecchia.
• Possiamo usare un progetto AGPL dentro il nostro SaaS?
• Una status page open source che giri su una piccola VPS?

La Open Source Guide di GitHub su come trovare utenti dà la versione del maintainer: vai dove i tuoi utenti si ritrovano già, rispondi a chi ha il problema che il tuo progetto risolve, cita il progetto solo quando c’entra e metti in conto che la crescita richieda mesi o anni.

Dove pubblicare, e le regole di ogni community

Le regole di Reddit valide su tutto il sito chiedono di partecipare in modo autentico alle community che ti stanno a cuore, di non fare spam e di non ingannare nessuno su chi sei. Poi ogni subreddit fissa le proprie regole, e quelli sull’open source sono più severi della media. La tabella si basa su una directory dei canali per l’open source che ha registrato queste regole il 7 ottobre 2026, più le pagine di Hacker News che abbiamo letto noi. Le regole cambiano, quindi leggi la sidebar prima di ogni post.

Un piano per la settimana di lancio

Infisical, un secrets manager open source, ha raccontato il suo lancio: post su r/opensource, r/github e r/node, uno Show HN, e nei giorni successivi newsletter come TLDR e Console.dev che lo hanno ripreso. L’autore consiglia di partecipare a quelle community prima del lancio, cosa che loro non avevano fatto. Ecco un piano che parte da lì:

1. Prima del lancio: rendilo facile da provare
   Un README che mostri cosa fa il progetto già nella prima schermata, istruzioni di installazione che funzionino su una macchina pulita, un file LICENSE e una release con tag.
2. Settimane prima: partecipa
   Rispondi alle domande dove si trovano i tuoi utenti, senza citare il progetto. Il resoconto di Infisical indica proprio questo come il passo che aveva saltato.
3. Giorno del lancio: un post per canale, scritto da te
   Due o tre canali adatti, il megathread o il flair che ciascuno richiede, e parole tue. Resta nei commenti: ti mostrano cosa manca nel README.
4. Dopo: gli elenchi
   Directory e liste curate vengono dopo. awesome-selfhosted aspetta che la tua prima release abbia più di quattro mesi.

Rispondere da maintainer

La fonte costante di nuovi utenti sono i thread di domande. Una buona risposta aiuta la persona a scegliere, anche quando la scelta non è il tuo progetto. Rispondere ai thread in cui si chiedono consigli sugli strumenti spiega lo schema generale; nell’open source tre domande tornano abbastanza spesso da valere un piano.

“Un’alternativa a X?”

Indica le opzioni adatte ai loro vincoli, comprese quelle che non hai scritto tu, e di’ in cosa la tua è diversa. Se serve la sincronizzazione su mobile e la tua non ce l’ha, dillo.

“È ancora mantenuto?”

Rispondi con fatti verificabili: la data dell’ultima release, ogni quanto fai merge, quanto in fretta le issue ricevono risposta. Il controllo Maintained dell’OpenSSF Scorecard, per esempio, cerca commit settimanali negli ultimi 90 giorni, dà il punteggio più basso ai repo archiviati e considera troppo nuovi per essere giudicati i progetti con meno di 90 giorni.

“Posso usarlo con questa licenza?”

Linka il testo della licenza e una sintesi semplice invece di dare consulenza legale. Per l’AGPL-3.0, la sintesi di choosealicense.com spiega che, quando una versione modificata viene usata per offrire un servizio in rete, il codice sorgente completo di quella versione modificata deve essere reso disponibile.

Quell’ultima frase conta anche quando il progetto è gratuito. Le indicazioni della FTC sulle endorsement dicono che i legami da dichiarare non sono solo economici e includono il rapporto di lavoro e la comproprietà, e che indicare il datore di lavoro nel profilo non basta. Se quelle indicazioni valgano anche per un progetto amatoriale non retribuito è una questione legale, ma le regole di Reddit già chiedono di non ingannare nessuno su chi sei. I modelli di dichiarazione offrono formule che stanno in una riga.

Le stelle vengono per ultime

La documentazione di GitHub dice che molte delle sue classifiche dei repository dipendono dalle stelle, e descrive una stella come un modo per tenere traccia dei progetti e mostrare apprezzamento al maintainer, non come il segno che qualcuno abbia installato qualcosa. Uno studio accettato a ICSE 2026, rivisto su arXiv nel 2025, ha trovato circa sei milioni di stelle sospette false, soprattutto su repo di phishing e malware dalla vita breve, e ha rilevato che le stelle false aiutano per meno di due mesi e poi diventano un peso.

Misura i numeri che dicono che qualcuno ha usato il progetto: download del pacchetto, issue aperte da persone che non conosci e nuovi contributor alla prima esperienza. Per quest’ultimo punto, etichetta le issue adatte ai principianti e scrivi un CONTRIBUTING.md; l’elenco good-first-issue chiede almeno tre issue per principianti aperte, dieci contributor, documentazione di setup e una licenza open source.

Dove serve un agente, e dove no

La parte lenta di tutto questo è leggere: trovare i thread sulle alternative e sulla manutenzione su Reddit e X prima che si spengano. Agent Agency fa questa parte. Incolli il sito del tuo progetto, lui legge fino a cinque pagine pubbliche e scrive un Product DNA che approvi tu, e gli agenti leggono ogni community e restano nei limiti giornalieri. In modalità Approvazione ogni commento, post e DM aspetta il tuo OK. Gli agenti tornano su un thread per giorni a rispondere a chi interviene, e citano il progetto solo quando risponde alla domanda, entro un tetto giornaliero. In Come funziona trovi il flusso completo.

Reddit e X sono disponibili e YouTube è in test. Con i crediti paghi il lavoro, e i prezzi li annunciamo con i primi inviti. Se il tuo progetto è uno strumento commerciale per sviluppatori più che un progetto di community, è più adatta la pagina per i developer tools.

Domande

Dove conviene pubblicare per primo un progetto open source?

Dove i tuoi utenti fanno già domande, nel formato che ogni canale richiede. Per un’app self-hosted può essere il megathread settimanale di r/selfhosted; per una libreria Python, il thread mensile delle presentazioni su r/Python; per qualcosa che si può provare subito, uno Show HN. Scegline due o tre, scrivi tu ogni post e resta nei commenti.

Devo dichiarare che sono il maintainer di un progetto gratuito?

Sì, dillo. Le regole di Reddit chiedono di non ingannare nessuno su chi sei, e le indicazioni della FTC dicono che legami come un rapporto di lavoro o la comproprietà vanno dichiarati anche quando non girano soldi. Basta una riga come “ne sono il maintainer”, nel commento stesso e non solo nel profilo.

Un agente AI può pubblicare sul mio progetto su r/programming o su Hacker News?

Quei canali rifiutano i testi scritti con l’AI: r/programming vieta i contenuti scritti da un LLM e Hacker News chiede niente testi generati o rivisti con l’AI. Agent Agency non ha un agente per Hacker News, e su Reddit quei post è meglio scriverli tu e rifiutare le bozze per ogni subreddit con quella regola.

Agent Agency trova i thread in cui le persone cercano un progetto come il tuo e scrive le bozze di risposta che approvi tu. Iscriversi alla lista d’attesa è gratis. Mettiti in lista d’attesa