A free, open-source future for Mailspring

Mailsync Is Now GPL!

Hey folks! Our 2021 roadmap for Mailspring is off to a great start - since January 1st, we’ve launched this forum, @CodeMouse92 has tamed GitHub issues to make them more actionable, and we’ve published a community-driven release with features from a half dozen contributors!

Today, I am excited to announce that I am open-sourcing mailsync - the C++11 core of Mailspring that performs email sync - under the same GPLv3 license used by the rest of the app, making Mailspring entirely free software. :tada:

Outside my work on the Mailspring Electron application, this is the largest contribution I have ever made to open-source - the product of a year of full-time work and three more years of improvements and bug fixes. It’s also a labor of love that I have been hesitant to open-source. At the beginning of the Mailspring project, I wanted to focus contributors on the front-end codebase where it is much easier to contribute. I’d seen other (comparatively simple) C++ projects go open source only to be flooded with reports of “it won’t build!”, and knew mailsync might permanently render my GitHub notifications useless. But as we look to the future, I believe GPLv3 is the best path forward for Mailspring as a project and product.

Over the last 5 years, Mailspring’s open-source interface has become more and more polished. It’s been localized into dozens of languages, themed by great designers and seen powerful new features like templates and signatures. In many ways, we’re closing in on the “last mile” required for it to be a best-in-class mail client, and that work - resolving sync bugs, handling IMAP / SMTP idiosyncrasies, etc - has increasingly been in the mailsync core. The longer I work on Mailspring and fix these bugs, the more I am convinced that this is work best done by a community with broad access to mail servers and edge cases.

Looking forward, I also believe that Mailspring has the potential to be a clean, minimal alternative to Thunderbird. It has a strong plugin architecture and a UI that is easy to work with thanks to Electron and the modern web. In my discussions with @CodeMouse92, I’ve realized that this future requires that the project is fully free and open-source - software the community can trust, invest in, and iterate on.

Mailspring IDs and Paid Features

In the last few years, the Mailspring project has achieved something fairly rare: by offering “pro” features as a paid subscription, we have been able to offer everyone features that use paid APIs (email translation and contact enrichment) and offset the costs of web services, Google OAuth security audits (now $15,000 a year), Travis CI, Windows Authenticode and Mac codesigning certificates, and more. If the paying user base - primarily folks who use Mailspring at work or in place of email power-tools like MixMax - continues it’s slow growth, I expect we’ll start offering bug bounties on GitHub later this year.

I am extremely grateful to everyone paying for Mailspring Pro, and I am excited that Mailspring has found a happy medium between project and product that will allow it to thrive long-term. In many prominent open source projects, a large fraction of commits are made by contributors paid full-time or part-time (see LibreOffice) and I’m hopeful that continued work to serve Mailspring Pro users will let us invest in our community and contributors.

While Mailspring’s focus on growing a paid user base has been critical to building a sustainable foundation for the open-source project, it has also made it less appealing to users interested in a basic free client. While you can use Mailspring entirely for free, you’ve had to create a Mailspring ID to do so. (The “Mailspring ID” stores metadata that can’t be synced to IMAP for snoozing, send later and read receipts, and holds your “Pro” membership should you upgrade.)

In the first half of this year, I will merge changes making it possible to opt-out of the Mailspring ID and use the app without it’s web services. (Please be aware this is not a trivial change!) I think that it’s important that the product continues to be a valuable productivity tool for our pro users who are making so much of this possible, and I think Mailspring is best with these features enabled (especially if you use it on multiple computers), but I believe we can be more inclusive of the open source hacker community and their needs as well.

Call for Contributors

If you have deep knowledge of C++ or IMAP/SMTP, I would love your help pushing the open-source mailsync project forward. Feel free to message me or @CodeMouse92 here on Discourse if you’re interested in contributing! Fixing bugs related to IMAP is not for the faint of heart but I am hopeful we can close the “last mile” and solidify Mailspring’s future as a robust, modern and fully open-source mail client.

27 Likes

Hey everyone,

In light of the awesome news above, I wanted to get everyone up to speed on the plan forward. There’s a bit of work to do in the near term to get ready for open source contributors.

How Issues Works

All bug reports, sync issues, feature suggestions, and packaging/distribution issues for Mailsync should be reported here on Discourse, the same as you would Mailspring issues. This is helpful because, often, there’s a fair bit of overlap between the two projects, and we don’t want to have to move things around.

GitHub Issues is strictly for our contributors, and will only contain vetted issues which are on the short-term roadmap. This way, problems can be discussed in detail on Discourse, and only the immediately relevant information moved to GitHub Issues.

Building Mailsync

We need to iron out a few wrinkles with Mailsync’s build scripts. Do NOT open issues about building Mailsync! We’ll be creating a place for build-related discussions later, separate from the issue reporting.

Building Mailspring

By default, the Mailspring repository actually relies on a compiled binary of Mailsync. This won’t be changing, as it mitigates a lot of issues regarding building and versions and whatnot. Folks who want to work on Mailspring should not have to muck around with Mailsync.

Of course, we’ll have instructions for changing what version of Mailsync you’re using, for testing purposes. Documentation forthcoming on that. Speaking of which…

Documentation, Standards, and Cleanup

Our first priority was just to get Mailsync GPL’d. There’s still a lot of work to do!

  • Documentation needs to be written.
  • Coding standards for Mailsync need to be formally nailed down.
  • The code needs to be tidied up in places.
  • The PR workflow needs to be set up.

In other words, please pardon our dust.

The Repository

3 Likes

This Is Wonderful News! Thank you! :heart:

I have been watching Mailspring for years but I haven’t used it much due to the Mailspring ID requirement. I understand the technical value of it but I’d rather not have those features if it means I can use the client without the additional server involvement.

This new change to allow for Opt-Out of the Mailspring ID system is great news for me! I don’t like the client I have and the little that I tested Mailspring I always felt it was a great option. I only didn’t use it because of the ID requirement and the MailSync piece being proprietary. Both of these things being changed is very very exciting to me!

I’d also like to know will it be possible to have a Pro Subscription to get some features but also be able to Opt-Out of the ID? I’d like some of the stuff in Pro but not all of it. For example, I’d like the template support but I don’t need read receipts. :smiley:

Thank You for taking this approach! I will certainly be letting people know about this. :slight_smile:

3 Likes

Very glad you’re excited!

I’d also like to know will it be possible to have a Pro Subscription to get some features but also be able to Opt-Out of the ID? I’d like some of the stuff in Pro but not all of it. For example, I’d like the template support but I don’t need read receipts.

Likely, the answer would be “no”. Mailspring ID is essential to the Pro subscription — if you think about it, you’d have to “sign up” for Pro in some fashion anyway. However, we hope that by making Mailsync open source, it’ll be easier to confirm what we do and don’t send up to the servers in relation to that Mailspring ID.

We may look into offering different pricing tiers down the road, but right now our main focus is on the optional-ID feature. In the meantime, do know that you are able to turn off read receipts and link tracking if you don’t want them.

I wish the project takes the attention it deserves. I am not a programmer so i can not have any valid opinion about the technical issues and the resourses that have to be available for mailspring to thrive.

But such a project can not be an one man show unfortunately. There has to be a dedicated team for that. And if making it open source is the way for that, then it’s probably the best solution.

During the last weeks i am struggling to find a usefull and reliable alternative to web Gmail. I ve tried

Outlook
Thunderbird
emClient
PostBox
Newton
Wundermail
Spike
Front
Mailbird
Shift

Most of these were fine for most of the users. But for me, templates-receipts-reminders-signatures are essential. I use a plugin for Gmail for these as Ben said, and i’d like an alternative.

One other advantage of Mailspring is the performance (with some exceptions) and the easy and simple interface.

I bought a paid plan only for Mailspring, because it’s closer to my needs - although not 100%. But i would like to remain a Pro User and wait for some things to get better in the foreseeable future.

From a Pro user perspective, of course the option of not using Mailspring ID will be excellent news for many users. But you should also focus on Pro users who don’t mind using your server in order to have the Pro features such as Synched Receipts-Temlates-Reminders-Send Later etc.

If someone uses only one PC, MailSpring Pro is Best In Class. The issues start when you have to use other PC’s as well.

I wish all the best to your efforts and hope i’ll remain a Pro user for a very long time

Came here to say thanks and once the ID requirement is lifted, and calendar support enabled I’ll donate and use Mailspring on Linux!

Thank you for making this choice. :+1: :pray: :innocent: I will promote your project at my level :smiley:

Best news for a very long time!
Have now reactivated my Pro account

2 Likes

Hey there, Mailspring-Libre maintainer here! First of all, a HUGE thank you to the whole Mailspring team and, of course, in particular to @bengotow for such a wonderful app. I know the decision to fully open up the source code must have been hard, but hopefully it brings some new contributors and some new Pro subscribers as well :‌-)

One more thing I’d suggest is – if possible from a legal and PR standpoint – starting to accept donations, or maybe allowing starting Pro subscription from website, without linking it to a Mailspring instance. I understand that donations will probably never be as profitable as selling actual features, but having a way to support the team behind a product you use is something really nice to have – I know I’d donate some $5/mo if I had a way to.

@CodeMouse92 @bengotow: I’ll get back to you next week regarding your collaboration proposal, sorry – this is just too huge of a news to me!

4 Likes

Thank you a lot ! I’m using Mailspring for profesional use with ubuntu OS and i have bought a licence just to support your effort :slight_smile:

Are there any roadmap for calendar integration ?

Regards !

4 Likes

It’s on the short-term. Right now, we have to fulfill our promises here about making Mailspring ID optional, and we need to fix some major sync stability issues with Mailsync for various email services. Once that’s nailed down, Calendar is squarely at the top of our priorities. Of course, it’s hard to promise dates — that’s indie software for ya!

1 Like

this is great news. Will actually give it a spin to see how it turns. Privacy question though: now that’s it’s open source without the ID, is everything done locally, even the special features as snoozing etc? No more going thru external servers?

PS, just downloaded the MacOS 1.8 version and still asks to set up ID…

Hi @ihubgit,

The Pro features that rely on the servers will continue to do so. (Some Pro features don’t go through external servers.) However, because Mailsync is open source, you’ll be able to audit what exactly gets sent up to the servers, and what doesn’t.

just downloaded the MacOS 1.8 version and still asks to set up ID…

Yes, we know. 1.8.0 was released prior to this announcement. There will probably still be a few minor releases before the ID is made optional. As Ben said, there is a tremendous amount of work to do in the code to make the Mailspring ID optional. It won’t be an overnight feature, purely because of the amount of work involved. It’s our chief priority (besides bugfixes).

ok good luck then with coding that up !

This is great news. Super excited to see things on a good track for Mailspring. Just converted my lapsed monthly pro account to an annual pro, and mentioned this Discourse in the Slack channel.

1 Like

I would love if you offered an open-source self-hosted server for storing this metadata. Understandably it wouldn’t support all the feature (particularly if some features have recurring costs for you), but a basic self-hosted server to store the metadata for snoozing, send later, read receipts, etc. would be awesome for people that don’t want to rely on third-party servers.

I can answer to that one a little bit. The primary reason we have no plan for this is because Mailspring is only viable as a product because we’re in a position to compete with proprietary email products with similar features, but in a privacy-oriented model. If we open-sourced the server, there would be nothing preventing any of those companies — some of whom completely ignore the terms of the GPL — from ripping off Mailspring as a service in its entirety at no cost to them.

Because Mailspring ID has been made optional, and because Mailsync is now open source, so you can understand what that metadata is, that satisfies nearly all privacy-related concerns regarding use of our third-party servers. Beyond that, we don’t want to jeopardize the future of Mailspring by open sourcing the server-side. It was surprising to me just how brutally cutthroat the proprietary email client landscape really is.

Totally understandable :slight_smile: Thanks for the reply.

That’s understandable, but at the same time, it’s inevitable that someone will eventually create a replacement server that’s API-compatible with the ‘official’ one to fulfill this use case (eg. similar to how Bitwarden has an unofficial port in Rust, bitwarden-rs) :slight_smile: