Cosa valutare prima di scegliere
Una lista che non dipende da GitHub
I contributori hanno un nome utente su GitHub, non un indirizzo che hanno scelto di darti per le newsletter. L’indirizzo che compare nei commit non è una lista di iscritti: usarlo senza consenso è un problema di privacy. La lista nasce da un modulo sul sito o nel file di presentazione del repository, con una frase chiara su cosa riceverà chi si iscrive e con la cancellazione in un clic.
Le release come feed, prima che come campagna
Se il repository pubblica un feed delle release, uno strumento che lo converte in email ti evita di scrivere due volte lo stesso testo. Non tutti i servizi lo fanno: chiedi se esiste un invio da feed RSS o una funzione equivalente, e a quale piano appartiene. In alternativa, resta il lavoro manuale di una riga e un link alle note, che per molti progetti è più che sufficiente.
Un canale separato per gli avvisi di sicurezza
Un difetto di sicurezza si gestisce prima in privato con chi lo ha segnalato, poi con una correzione, e solo dopo con un annuncio pubblico. Il messaggio ai tuoi utenti deve partire da una lista dedicata, con un mittente riconoscibile e senza altre notizie accanto. Chiedi allo strumento se consente liste separate con iscrizione distinta e se puoi esportare gli iscritti in qualsiasi momento.
Utenti, contributori e sostenitori su liste diverse
Chi usa il software vuole sapere quando aggiornare; chi contribuisce vuole sapere dove serve una mano; chi sostiene il progetto vuole vedere come vengono usati i fondi. Tieni tre liste con una frase d’iscrizione diversa per ciascuna, e un unico posto dove ognuno gestisce le proprie scelte. Controlla che lo strumento permetta di appartenere a più liste senza duplicare l’iscritto e il suo consenso.
Donazioni, sponsor e struttura giuridica
Il progetto può raccogliere fondi tramite piattaforme di sponsorizzazione, un conto comune o un’associazione. Cambia molto il trattamento fiscale di una donazione, di una sponsorizzazione e di una quota associativa: chiedi al commercialista. Nelle email dichiara chi raccoglie i fondi e a cosa servono; evita la parola «gratuito» se il software ha una versione a pagamento e un modello di supporto.
Costo, esportazione e alternative da installare
Per una lista piccola conta il piano gratuito, per una grande conta il prezzo oltre le soglie e la possibilità di esportare tutto. Alcuni progetti scelgono un software di newsletter open source da ospitare sul proprio server, come listmonk: non paghi licenze, ma ti occupi tu del server, della consegna e dell’autenticazione del dominio. Valuta se hai davvero tempo di farlo, oltre a manutenere il progetto.
Domande frequenti
Come annuncio una release senza riempire le caselle?
Manda un messaggio per le versioni che cambiano il comportamento del software, e una nota cumulativa per le correzioni minori, perché chi ha scelto di seguirti non vuole una mail per ogni patch. Scrivi una frase su cosa cambia per chi usa il progetto, un esempio di aggiornamento e il link alle note complete. Se hai un feed delle release e lo strumento lo converte in email, usalo solo per chi lo ha scelto.
Posso scrivere agli indirizzi che trovo nei commit?
No, almeno non per inviare newsletter: l’indirizzo di un autore compare nella cronologia per attribuire il lavoro, non per ricevere comunicazioni promozionali, e il consenso dovrebbe essere esplicito. Se vuoi dare il benvenuto a chi ha inviato la prima modifica, fallo dentro GitHub, nella conversazione, e aggiungi un link a un modulo di iscrizione facoltativo. In caso di dubbio, chiedi al tuo consulente o consulta le indicazioni del Garante.
Come invito nuovi contributori a partecipare?
Più che un flusso di email serve un buon file di presentazione del repository, con le istruzioni per preparare l’ambiente, un elenco di attività adatte a chi comincia e una persona che risponde. L’email entra dopo: un riepilogo mensile, per chi lo ha chiesto, con tre problemi aperti adatti a nuovi arrivati e i nomi di chi ha aiutato. Non scrivere in automatico a chi ha lasciato un solo commento: rischi di sembrare invadente.
Come comunico un cambio di licenza o una modifica che rompe la compatibilità?
Con largo anticipo, in una lista a cui chi usa il software è iscritto, e con il testo scritto da chi decide, non da uno strumento. Spiega perché cambia, cosa resta uguale, a chi si applica e come restare sulla versione precedente. Una modifica di licenza ha conseguenze legali per chi lo usa in azienda: fai rileggere il messaggio a un consulente prima dell’invio e pubblicalo anche nel repository, non solo via email.
Come chiedo una sponsorizzazione alle aziende italiane?
Scrivi a una persona, non a un indirizzo generico, spiegando quale parte della loro attività usa il progetto e cosa permetterebbe di fare il contributo: manutenzione, sicurezza, documentazione. Proponi livelli semplici e dì chiaramente cosa ricevono, come un logo nel repository o il supporto prioritario. Per fatture, IVA e differenza tra sponsorizzazione e donazione parlane con il commercialista, che saprà dirti cosa è corretto per la tua forma giuridica.
Come uso la newsletter per eventi come il Linux Day o un meetup?
Usa l’email per tre momenti: l’invito con data, luogo e programma, un promemoria pochi giorni prima e un riepilogo con slide e foto dopo l’evento. Se partecipi a incontri locali o a eventi più grandi all’estero, controlla ogni anno le date sul sito ufficiale e non darle per fisse. Chiedi sempre consenso separato per gli iscritti agli eventi, e conserva l’elenco solo per il tempo necessario all’organizzazione.
Come evito che newsletter, chat e forum si sovrappongano?
Scegli un posto dove gli annunci ufficiali compaiono sempre, e fai in modo che gli altri canali rimandino lì. L’email è il registro più duraturo: resta negli archivi, si cerca e non dipende da una piattaforma di chat che può cambiare regole. Nelle conversazioni quotidiane usa chat o forum, e nella newsletter metti solo ciò che chi non vi partecipa ha bisogno di sapere.
Che cosa metto in un riepilogo mensile?
Tre cose: cosa è stato incorporato nel progetto, cosa serve adesso e chi ha aiutato. Una riga per punto, con un link, bastano; evita di gonfiarlo per sembrare più attivo di quanto sei. Una nota firmata da una persona, in italiano o nella lingua principale del progetto, ha più valore di un elenco generato da uno strumento. Se un mese non c’è nulla da dire, salta l’invio.
E se il progetto lo mantengo da solo?
Tieni tutto minimo: una sola lista, una nota a ogni release importante, un avviso per la sicurezza. Scegli un piano gratuito e non costruire automazioni che poi devi tenere aggiornate. La newsletter non deve diventare un secondo lavoro non retribuito: dichiara la frequenza nel modulo e rispettala, anche se significa scrivere quattro volte l’anno. Meglio poche note regolari che una serie interrotta.
Come capisco se la comunità sta crescendo davvero?
Le email dicono poco da sole. Guarda quante persone nuove aprono una discussione o una proposta di modifica, in quanto tempo ricevono risposta e quanti ritornano. Dalla newsletter ricava i clic verso la documentazione e le iscrizioni dopo ogni evento. Non confrontare con progetti di dimensioni diverse e non inventare soglie: tieni un registro semplice, mese per mese, e leggi l’andamento nel tempo.