Skip to content

Latest commit

 

History

History
89 lines (45 loc) · 5.43 KB

ROADMAP.md

File metadata and controls

89 lines (45 loc) · 5.43 KB
Raw

Roadmap:

The initial release of Mailspring was in Nov. 2017. The roadmap is largely based on popular GitHub issues plus the larger projects outlined here. For a complete list of features that have been shipped in the app, see the release notes in the changelog.

Summer 2019 (Planned)

  • Calendar

    Goal: Build a beautiful CalDav and Google Calendar interface that can be opened in a new window or as a tab in the main window, making Mailspring a full replacement for the calendar-contacts-email suite.

Spring 2019 (Planned)

  • Email Signing

    Goal: Allow users to sign outgoing email with a certificate, and verify the signatures of signed inbound email.

  • Mail Merge

    Goal: Make it possible to use a Template and a spreadsheet to batch-send emails with open / link tracking. Nylas Mail used to have this feature but the implementation confused users and didn't handle sending errors well. The new version will

  • Theme and Plugin Browser

    Goal: Make it easier to download and install community themes and plugins from a trusted, centralized "gallery", like the Chrome Web Store. (No immediate plans to allow to enable paid plugins.)

Fall 2018

  • Localization

    Goal: Make underlying architectural changes that will allow Mailspring to be localized into dozens of languages. (Shipped in 1.5.0)

  • Electron 4

    Goal: Move Mailspring to a newer Electron release and make the necessary changes to support it.

Summer 2018

  • Improved Search UI

    Goal: Highlight Mailspring's Gmail-style search features by overhauling the search bar. Allow users to save searches to the sidebar and right-click threads to "Search for more like this..." (Sihpped in 1.3.0)

  • macOS Touchbar Support

    Goal: Expose a broad set of touch bar actions that mirror options shown in Mailspring's UI and expand the app's menus to include all keyboard shortcuts. (Shipped in 1.4.0)

Spring 2018

  • Thread Sharing

    Goal: Bring back the old Nylas Mail feature that allowed you to sync an email thread to the cloud and share it using a link. (Shipped in 1.2.0)

  • Overhauled Composer

    Goal: Replace Mailspring's custom contenteditable wrapper and it's many bugs with a standard JS library that is maintained on it's own, lowering the surface area we need to maintain for Mailspring. (Shipped SlateJS in 1.1.0)

  • New Template Editor

    Goal: Brand new template editor in Preferences > Templates with a more streamlined UI based on the new composer. (Shipped in 1.1.0)

Longer-term

  • Sync Issues

    Goal: Make it possible to connect and sync any IMAP account with Mailspring. The project is close but still encounters sync issues with small or unsual IMAP providers.

  • Performance

    Goal: Users shouldn't notice Mailspring is an Electron app. Need to improve typing / load performance of the composer and continue improving responsiveness of the thread list and message list.

  • Advanced Mail Rules

    Goal: Create a new UI and revamp the mail rules engine to enable mail rules based on custom JavaScript code. Could enable really advanced workflows to be automated if we did it right!

  • Contact Management

    Goal: Replace Mailspring's built in contacts list (which is based on email headers) with one that uses CardDav and syncs with Google Contacts / O365 Contacts and allows full contact CRUD.

Why is Mailsync Closed Source?

For the initial release I've decided to keep the new C++ codebase closed-source. When you pull this repository and run npm install, the correct Mailsync build for your platform is automatically downloaded and put in place so you can hack away on the Mailspring Electron app. For those of you who are interested, here's why it's closed-source:

  • Open source is a commitment. When I was the lead engineer of the Nylas Mail team at Nylas, I spent thousands of hours responding to GitHub issues, helping people build the source, and trying to give PR feedback that was actionable and kind. I'm expecting to spend about 30% of my time working with the open-source community on the JavaScript side of Mailspring, and I'd rather focus on improving existing documentation and hackability than expand code surface area past what I can support. Especially until it's past the "bus factor" of one!

  • Mailsync is hard to compile. Mailsync is written in C++0x and uses new features like shared_ptr and condition_variable. It requires GCC 4.8 and has a ton of dependencies and required build flags. If node-sqlite3 is any indication, open-sourcing it in it's current form would be a GitHub Issues disaster. (Compared to mailsync, node-sqlite3 is pretty easy to build but a whopping 35% of it's open issues are compilation-related! 😰).

  • The odds of great PRs are low. Mailsync is a multithreaded, cross-platform C++ application that interfaces with old, fragile protocols that have their own learning curves and are difficult to mock. For folks to contribute meaningful pull requests, I'd have to write great docs and tests. I'd also need to spend a /lot/ of time reviewing changes for side-effects, enforcing good C++ techniques, and checking changes for performance impact. Maybe I'll be able to support this in the future, but not yet!

If you're interested in contributing to the Mailspring Mailsync codebase and have some time and skill to throw at it, please let me know!