Own Your Community's Voice: Why Open Source Projects Should Run Their Own Mailing Lists

A few weeks ago I stood in front of a room of small business owners in Melaka and told them something I have believed for twenty years: the internet is land, and you should own a piece of it instead of renting forever. I was talking about domains, websites, and customer relationships. But the same idea applies just as brutally to how open source communities communicate with the people who matter most to them.

Your contributors, your users, your sponsors, your security reporters — these people are not "followers" or "members" of a platform. They are your community. And if the only way you can reach them is through someone else's algorithm, you do not own that relationship. You are renting it.

This is why I think every open source project that is serious about its community should run its own mailing list on its own domain. Not as a replacement for everything else. As a foundation. The home you own, even if you also keep a stall in the busy mall.

KaiMail just added mailing lists to the custom domain email service we have been running. That is the immediate reason I am writing this. But the argument is older than the feature.

The Rented Land Problem, Applied to Communities

In Melaka I showed the room a simple stat: a business post on Facebook reaches roughly one or two of every hundred followers without paid promotion. That is the rent. You built the audience; the platform charges you to reach them.

Community platforms work the same way, just with different currency.

• Discord decides which channels you can have, what bots you can run, and what data it mines from your conversations. Your community lives inside its architecture.
• Slack free plans delete message history after 90 days. Your institutional memory evaporates unless you pay.
• Twitter/X and LinkedIn groups throttle reach algorithmically. A post your members explicitly followed you for may simply never appear in their feed.
• Facebook Groups can and do vanish to automated moderation errors, with no human to appeal to.

I am not saying these platforms are useless. They are excellent for real-time chatter, quick questions, and the social energy that keeps a community warm. But they are rented stalls. The landlord can change the layout, raise the rent, or close the mall. And when they do, your community does not get to take the building with them.

A mailing list on your own domain — [email protected], [email protected] — is land you own. The address is yours. The list of people who chose to hear from you is yours. Nobody can throttle it, re-sort it, or switch it off because an automated system flagged a keyword.

What a Mailing List Actually Gives You

1. A direct line that nobody gates

Email is the only universal protocol left. There are over 4 billion email users worldwide. Every developer has an address. Every sponsor reads theirs.

When you send to a mailing list, the message goes to the inbox. Not to a notification panel competing with thirty other channels. Not to a feed sorted by engagement predictions. The inbox. If your subscriber checks email, they see it. Full stop.

Email marketing as a channel still delivers an average of $36 for every $1 spent, compared to roughly $2.80 for social media. Those numbers come from commerce, but the underlying mechanic is the same: email is personal, direct, and unfiltered by a third-party algorithm.

2. An archive that outlives platforms

Mailing lists produce a permanent, searchable, public record of decisions. If you want to know why the Python Steering Council rejected a proposal in 2019, the thread is in the archives. If you want to know why a Django design decision was made in 2014, the discussion is preserved.

Try finding a Slack thread from 2019. Or a Twitter conversation from before the API changes. Or a Facebook group post from a group that moved platforms. Rented land does not keep archives for you. It keeps them for itself, until it decides not to.

For open source projects, this matters enormously. Governance decisions, security discussions, and API design debates are the institutional memory of the project. Losing them because the free tier expired is not a technical failure. It is a stewardship failure.

3. Async-by-default, which is how open source actually works

Open source contributors are distributed across time zones. A contributor in Kuala Lumpur, a maintainer in Berlin, and a sponsor in San Francisco do not share waking hours. Real-time chat assumes synchronous attention. Mailing lists assume the opposite.

When a discussion happens on a list, everyone can read the thread, think, research, and reply on their own schedule. The format encourages longer, more considered responses. It rewards writing things down properly. These are habits that make open source better, not worse.

4. Professional identity on your own domain

When your project announces a release, the email should come from [email protected], not from a noreply address at a third-party service. When a security researcher reports a vulnerability, they should send it to [email protected], not to a maintainer's personal Gmail.

I have written before about why every open source project needs its own domain email. The short version: [email protected] undermines trust, creates bus-factor risk, and turns personal inboxes into project infrastructure. A mailing list on your domain solves this at the same time it solves broadcast communication.

5. Privacy that you control

When your community lives inside Discord or Slack, the platform has access to every message, every private channel, every DM. That data is used to train models, target ads, and inform corporate strategy. Your community's private technical discussions are someone else's product.

A self-hosted or domain-based mailing list does not eliminate all privacy risks, but it dramatically reduces the attack surface. Your conversations are not being scanned to improve a recommendation engine.

The Honest Costs: Where Mailing Lists Fall Short

I promised a balanced draft, so here is where the argument gets honest.

1. Younger contributors do not check email

This is the hardest demerit to argue around. Developers under thirty often treat email as a notification dump for receipts and password resets, not a place where real work happens. They live in Discord, in Slack, in Telegram. If your community skews young, a mailing list can feel like shouting into a void.

The honest answer is that you probably need both. Use the chat platform for warmth and real-time energy. Use the mailing list for announcements, governance, and anything that needs a permanent record. One does not replace the other.

2. Spam filters are brutal

Gmail and Yahoo have tightened DMARC enforcement so aggressively that legitimate mailing list traffic gets flagged if authentication is not perfect. DKIM alignment, SPF records, and list rewriting all have to be correct, or your carefully crafted announcement lands in the spam folder of half your subscribers.

This is a solvable technical problem — KaiMail handles DKIM signing and DMARC-compatible From rewriting for exactly this reason — but it is a real barrier that did not exist in 2010. Running a list today requires understanding email authentication, or using a service that does it for you.

3. Setup still asks more than a Discord server

Creating a Discord server takes three clicks. Setting up a mailing list on your domain requires DNS records, MX configuration, and some understanding of how email flows. The gap is narrowing — services like KaiMail are built to make this a five-minute job — but the perception of complexity lingers.

For volunteer-run projects with no infrastructure person, this perception matters. The barrier is not just technical; it is cognitive. Someone has to decide it is worth doing, and that decision competes with every other priority.

4. Engagement rates are lower than instant messaging

Email open rates for community lists typically sit between 20% and 40%. That sounds low until you compare it to social media organic reach, but it is undeniably lower than the near-100% visibility of a message posted in an active Discord channel.

The trade-off is quality versus quantity. The 30% who open your project announcement are the ones who actually care. The 70% who do not were never going to act on it anyway. But if your goal is maximum visibility for a time-sensitive call for proposals, a mailing list alone will disappoint you.

5. Discovery is harder

Nobody stumbles across a mailing list the way they stumble across a Subreddit or a Discord server. You have to know the project exists, find the signup page, and opt in. For new projects trying to build an audience from zero, this is a genuine disadvantage.

Social platforms are discovery engines. Mailing lists are retention engines. The former helps you grow; the latter helps you keep the people you have. Which one you need more depends on where your project is in its lifecycle.

What We Built

KaiMail's new mailing list feature is built specifically for people who have already decided to own their communication. It runs on the custom domain you already have set up with us, and it gives you three modes:

• Public lists for shared mailboxes like [email protected]
• Broadcast lists for announcements and newsletters where only the owner posts
• Discussion lists where members reply-all and the conversation stays on the list, with proper Reply-To handling and DMARC validation

Every message sent through broadcast and discussion lists is DKIM-signed with your domain's key. We rewrite the From header in a DMARC-compatible way, similar to how Mailman handles it, so your messages land in inboxes rather than spam folders. You compose in your regular mail client and send through authenticated SMTP on port 587. No separate dashboard for writing. No proprietary editor.

And because it lives on the same domain as your project email, your subscribers see emails from [email protected], not from some third-party sending service. SPF, DKIM, and DMARC all align properly because we control the full sending path.

For open source communities running on tight budgets, our free plan covers basic forwarding, and we have a community upgrade program for volunteer-led projects that need broadcast and discussion features.

The Bottom Line

In Melaka I closed with this line: "You would never run your real shop from a stall you rent by the day, from a landlord who can evict you tomorrow on a whim. Do not build your business's future on one either."

The same applies to communities. Your contributors are not a "user base" to be harvested by a platform's engagement model. They are people who chose to spend their time on your project. The least you can do is make sure you can still talk to them if the platform changes its mind.

A mailing list is not nostalgia. It is infrastructure. It is the difference between renting a community and stewarding one. And with the tools available today — including the ones we have just added to KaiMail — the setup burden is no longer a credible excuse.

Own your domain. Own your list. Own your relationship with the people who make your project possible. The rest follows.