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. 
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.
I will promote your project at my level