Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

CEO of MZLA (the Mozilla entity that develops Thunderbird). One point of clarification, we don't get money from any source but our donors. After years of funding issues, MZLA was created by the Mozilla Foundation and the Thunderbird Council (our community governance body), to provide a legal/financial home for Thunderbird.

Launching Thundermail this year (an email service) which we hope to help provide even more funds for development, beyond just donations. Also serving a user need (lots of our users ask us to help them get off Gmail).

Lots of interest in how the money is spent - answer: mostly on devs, landed Exchange support recently (big for a lot of MS users), working on Graph support as well, JMAP after that. Updating the calendar (primarily UX/UI there), continuing to improve our Android app, working on a native iOS app and the aforementioned Thundermail service.

We publish yearly reports and will publish one again this year detailing all this.

Here is a 2025 recap: https://blog.thunderbird.net/2025/12/thunderbird-2025-review...

But the blog has a ton of updates across the different efforts: https://blog.thunderbird.net

Happy to answer questions and we are an open source project so feel free to reach out to us and engage if you really want to see how the sausage is made!

*Edit: More context on what Thunderbird Council is*



Since most of the people here who seem wary about how their donation is getting spent, I have a feeling that "mostly on devs" probably won't cut it for them, though I assume it's true. Have you considered doing any sort of year end cost reporting where you show percentages of what money went where? If it's going where you say it is I think making that information transparent would be a free win. (I know there would be some level of effort constructing the report but I also have to assume you already have reports like this internally)


> Have you considered doing any sort of year end cost reporting

That very much exists, and is issued yearly.

Consolidated Financial Statements 2024-2023:

https://stateof.mozilla.org/pdf/Mozilla%20Fdn%202024%20-%20A...

Expenses in Software Development (2024):

> 290,448,000

Total Expenses (2024):

> 588,215,000

Ryan Sipes, if you can read this, everybody online remembers the 2020 Servo team lay-offs, and the juxtaposition of the C level compensation.

If you are serious about winning back donors and trust:

- Allow for a transparent breakdown of expenses on things like external consultancy and also C level compensation

- Allow financial ring-fencing of donations. Such that my donation can only finance Firefox devs or Thunderbird devs. (Not teams, not products, not managers/VPs/Directors just developers. Everyone else's compensation should come from corporate donations or other means)

I love Firefox and Thunderbird, use both everyday, was also a yearly donor up to 2020 (now I just donate to Archive.org and KDE).

You have great products that people love but if you are serious about gaining back trust you need to show judicious spending on the top side of the org. Justifying it with we need to spend money to get fundraisers doesn't pass the community test.


That's Mozilla-wide and includes the Mozilla Corporation and other entities.

We have 2023-2024 reporting via these two links:

https://stats.thunderbird.net/#financials

https://blog.thunderbird.net/2024/10/thunderbird-annual-repo...

We need to update the ratio for 2025, but it shouldn't be dramatically different.


would be nice to have the personnel costs further split up I suppose


You cannot simultaneously increase the percentage of donations going to directly paying "just developers" while decreasing the percentage going to admin costs. Who will be responsible for implementing this ring-fencing of donations, if not precisely the non-developers you'd like them to spend less on?


We still need to produce a big report like this for 2025. But you can find MZLA specific info for 2024 and 2023 via the below links:

https://stats.thunderbird.net/#financials

https://blog.thunderbird.net/2024/10/thunderbird-annual-repo...


As a user from Germany, it would help a lot if you could provide an IBAN to send you money in EUR directly. These payment providers all take a cut and what ends up being used for recurring donations is SEPA direct debit, which costs me about 10€ if my account ever happens do be too low to take the charge. Please make a way around supporting this ecosystem of banking with every donation!


Thundermail is a great idea! I'd be more than happy to switch over assuming the migration path from say Gmail, Fastmail, etc was easy enough, and it supported custom domains.


>Thundermail is a great idea!

I think the synergy part is what is great here. Imagine thundermail is a FOSS server app. Imagine they implement things like proof-of-work for senders, and no PoW means the mail goes into a quarantine instead of directly in the user's inbox. That could fight spam, without the centralization and loss of privacy we've had in email. That hasn't happened now, because of the chicken-egg problem. There's no client that supports it because there's no server that supports it because there's no client that supports it.

Thunderbird is a very big client. It could push email forward like nothing before. I may give Thundermail a try. I'd much rather self-host a Thundermail server... one that works around the port 25 block on every residential IP. Maybe my self hosted instance could receive messages relayed from the "real" thundermail server on something other than port 25.


Sign up for the waitlist here: https://Thundermail.com

Also the Thundermail service is based on Stalwart (completely foss). We'll open source any additional relevant bits.

We also released the supporting services:

https://github.com/thunderbird/appointment

https://github.com/thunderbird/tbpro-add-on

https://github.com/thunderbird/thunderbird-accounts


Will support custom domains out of the box. Getting real close to launch. Join waitlist at https://thundermail.com


Is unlimited email aliases (with or without custom domains) also on the roadmap?


With custom domains... Yes! :)


I can see switching from gmail, but it would have to be really compelling to get me to switch from Fastmail.


What would get you to switch from Fastmail?


The few times I've needed support, Fastmail has responded nearly immediately with the exact info I needed. So Moz would need to demonstrate excellence in customer service before I would consider any migration.

(I know that doesn't directly answer your question, but it does articulate a necessary pre-condition, and one that is hard for businesses entering a new line of service to deliver--although not impossible, of course.)


JMAP is a bonus (other fastmail user here) bjt if I can do custom sieve rules and or unlimited aliases created on demand at (somestring)@customdomainiown.com thst I can then use the sieve rules to put into a folder of the same name as that email address, I would rather give my money to support Thunderbird. Fastmail is fine and all but they are in australia so they live on spyware island and they dont have good native clients in the works like thunderbird does.


Unlimited aliases at custom domains are a part of the offering. Technically, Thundermail supports sieve rules, we do need to come up with UX to expose it to users for management.


Probably JMAP support.


Already a part of the offering. :)


Thanks for posting here. This information is helpful.

I strongly encourage you to provide that information on the page asking for donations. Even if it's just one sentence with a link and even if it doesn't fit with Mozilla's corporate policies.


We still need to produce a big report like this for 2025. But you can find MZLA specific info for 2024 and 2023 via the below links:

https://stats.thunderbird.net/#financials

https://blog.thunderbird.net/2024/10/thunderbird-annual-repo...


> CEO of MZLA (the Mozilla entity that develops Thunderbird).

Was it really too hard to say "I am the" or add "here" at the end? Instead we get this lazy "words hard less wrds good" manner of speaking.


Why use many word when few word do trick.


I meant to have a "here" at the end, just typed while excited. Typically known for using too many words.


I've been using Thunderbird exclusively for as long as I can remember (Internet user since '92).

I don't understand why they make it so hard to donate anonymously. I actually found their IBAN (DE05 5123 0500 0500 2158) on the Google results page, not on the page it linked to.

Annoying.


I've been trying to use Exchange support at work but there's an ongoing problem that the OAuth login screen can't display PIN prompts for things like Yubikeys.

So I'd love to use the feature, but modern corporate auth defeats it currently.


I'd love to know more about what you are hitting. Care to open a bug then ping me back here? I'll put it in front of the right people.

https://bugzilla.mozilla.org/enter_bug.cgi?product=Thunderbi...


With "Graph support" you mean "Microsoft Graph API"?


That's right. We've long had Microsoft account users across Exchange, Office365 and Outlook.com complain about having issues using Thunderbird. So we're trying to account for all protocols from MS.


Excited about Thundermail!


Sign up for the waitlist at https://thundermail.com


You could convince me to switch from gmail but I'm not sure I would switch from Proton to thundermail.


Protonmail = privacy at all costs. Thundermail = freedom at all costs (open standards, use w/ whatever client you want, upload your own encryption key and "go dark")


I assume if I upload my own key, the receiver of the emails needs to also have my key? I'm not necessarily trying to send encrypted emails to people. I would want zero-access encryption which means not even Thundermail knows what my emails are.


No, we rely on PGP encrypted email. What I'm talking about is the latter. Emails are encrypted with your public key before being stored in the database. (Our stack is based on Stalwart, you can read about how it works here: https://stalw.art/docs/encryption/overview )


Thanks for explaining the broad strokes. I'm a bit more interested now and signed up on the waitlist.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: