Comment by philsnow
2 years ago
You have a bullet point about compliance / hosting concerns. I'm curious, do you have any idea how many of your customers care about that?
Do you have any concern that a customer is going to look under the covers and re-implement your product? I would guess the overwhelming majority of customers are going to be happy to just consume the API and go about their own business, but some products attract copycats, and handing out code / build artifacts makes that easier.
The tradeoff you've made makes a ton of sense if you're not concerned about copycats.
Compliance issues are a real concern. For example, I have some customers who switched from Nylas to EmailEngine because Nylas closed their Canada DC, even though EmailEngine is an inferior product. I'm not really worried about copycats, as it's a niche and complex project. There are literally hundreds of email RFCs, some as long as a book, and you would need to have at least an overview of these. You can already use IMAP client libraries in any language, but what EmailEngine does is cover all the weird edge cases, like handling sequence numbers as identifiers. Those who have the skill likely have better things to do, and those who don't probably find easier things to copy.
Who are your main customer segments? I ask because I'm implementing Microsoft, Google and Apple email support for my app and Microsoft and Google have an API now, while Apple is still a pain. Beyond that, for custom email providers, I'm not sure who else is major enough to implement for. I guess I'm asking, couldn't your customer do something like I'm doing, to cover 80% of the use cases by using the Microsoft and Google APIs and spending some time using an IMAP client for Apple iCloud, and discarding the other smaller percentage of other email providers?
Granted, it still does kind of suck to implement even these three, but I'm sure it would likely suck less if I were part of a bigger enterprise who could afford Nylas for example, which I looked into but seemed too enterprisey for my needs.
Most EmailEngine customers are smaller SaaS services like niche CRM providers etc. EmailEngine can also work with Gmail and MS365, as they support IMAP in addition to their proprietary APIs. So you get quite a large coverage by using EmailEngine out of the box (all smaller providers + most Gmail/MS365 accounts). Additionally, in some cases going with IMAP is the only way - for Gmail email API access, you need a very expensive security assessment that you might also fail for various reasons, like when your use case is not allowed by Google's terms. In comparison, there are no conditions for using app-password-based IMAP for Gmail. EmailEngine does not work with email accounts where their organization has disabled IMAP/SMTP access entirely (common with on-prem Exchange servers, a lot of MS365 accounts, etc.)
6 replies →
If you're worried about copying the code, I could see having the self hosted artifact be compiled or otherwise obfuscated would probably deter most people who wanted to reverse engineer it, since it would take significantly more time and effort to open up a compiled app than something just made in JS for example.
If you're worried about copying the API design, well, the implementation is the hard part, not necessarily the API design, which the Google vs Oracle lawsuit also showed, interestingly enough.
EmailEngine has all the code public [1], even though it is not open-source but is source-available. Some core parts I even published under the MIT license, like the IMAP client library I built from scratch to serve the special requirements EmailEngine has for IMAP access [2]
My thinking has always been that those who try to hack the license validation stuff and replace the missing build pipeline were never going to be my customers in the first place, so every second I would spend on them is a wasted effort.
[1] https://github.com/postalsys/emailengine [2] https://imapflow.com/