Nylas-mail: Option to opt-out for "Nylas Identity"

[Egoscio-zz]

Hello,

I'm running Mac OS X El Capitan with Nylas N1 v0.4.45 (Latest at the time of writing), and I use Gmail. Prior to updating to v0.4.45, I had v0.4.40, which didn't require me to create an account to use your client. From what I've observed, the only way to proceed is to create a Nylas Identity, which I find to be rather unnecessary and contradictory to the purpose of this project (from my perspective). I hopped on the train not too long ago for "an open-source mail client built on the modern web", not a service. Forcing me to sign up for an account doesn't feel right. I believe I and many others would appreciate a feature to opt-out, as all I want is the open-sourced developer plan, not a service. The mail client itself is wonderful, but I don't like how this is going.

Thank you for your time and consideration,

Egoscio

[grinich]

Hi @Egoscio -- getting this integrated with our backend and across all of N1 was a pretty big undertaking! The Nylas fully-supported Nylas builds integrate with the Nylas Cloud and are supported by Pro (https://nylas.com/blog/nylas-pro).

Going forward a lot of our features need to tie identity to some cross-mailbox entity, so a different account is necessary. (It's also obviously necessary for billing.)

If you'd like to stay on 0.4.40 I'd recommend checking out that tag from the GitHub history and running open source sync engine within your own VM (or locally). You can also fairly easily maintain a fork of N1 and only pull on the patches for future features that you are interested in.

Also if you'd like to read more about the architecture of the cloud sync engine, I recommend this post in our help center: https://support.nylas.com/hc/en-us/articles/217518207-Why-does-Nylas-N1-sync-email-via-the-cloud-

[grinich]

(Happy to continue the convo here, but I'm going to close the issue since we don't consider this a "bug")

[RReverser]

That's really saddening and should be opt-in for users who use sync, switch to paid versions etc. Monetization is a good thing for any project (especially open-source), but privacy and being able not to create an account which links all your identities (personal, work, various organizations) is concern no. 1.

Been a happy user of N1 since beginning as it was lightweight, easy to install and work with, and well, it's React-ish :), but, unfortunately, such move forces me to switch to another client which would be just a program that doesn't attempt to become a yet another service. Yes, checking out a specific tag and hacking to run just it is another option, but I want to be sure that I receive any important updates and not stuck on an outdated version of any software.

Thanks for all your work so far, it was a pleasure to use N1!

[thomaslee]

Ah man, I don't like complaining about things on GitHub since this stuff is typically a labor of love, but since the changes seem to have been made for the purposes of monetization:

Clicked the "upgrade" button and was suddenly locked out of my mail two days after installing N1 for the very first time ... I was excited about a full-featured open source email client for OSX, but this wasn't a great experience. Time to try something else. 😢

[Egoscio-zz]

@grinich Monetization is a perfectly understandable move to make in a company, as you need to somehow put bread on the table. In this case, the only painful aspect of this process is having your user base spoiled with a wonderful, free technology (the latter being an assumption on my part as well as others) that is clearly labeled and marketed as "open source", then suddenly making a huge change which indicates other true intentions (not bad ones, just unexpected). If you, for example, put a huge "Open Beta" label on the website's front page, such a move is obviously expected, as it was in the case of screenhero after it exited beta stage. In addition to this, I had no idea there was a backend aspect to this until I read your reply. I thought this is purely client side, just like Apple's desktop mail app, and the pro feature being just a few perks added on thanks to a optional backend. Having the entire platform depend on a backend is a even better justification for monetization due to obvious hosting prices, but making that aspect evident is somewhat neglected in marketing (imho).

TL;DR: If this project started with more emphasis on "Open Beta Service" (service being the backend aspect respectivly), and a little less emphasis on "Open Source", nobody would be complaining.

I would like to thank you and your team for your great effort in "fixing mail". It was a fun and unfortunately short ride.

Best,

Egoscio

PS: Creating a separate branch which bundles the engine with the actual client into one easy to install executable would be relatively easy to do. It would eliminate hosting cost as everything would run on the user's machine... but that would be a loss in profit on your side, as potential buyers would resort to that instead of purchasing your service, so nobody expects you to do it.