In my opinion, it's the intent of true openness (even if there are no guarantees of stability or availability) is what matters, not the promise of eventual availability.
The bridge and the import/export tool are not yet open source for similar reasons 1) They are both bandwidth intensive, so we'd like to release access to them gradually 2) Part of running a freemium service is giving paid users perks, and one of those is access to closed betas before general release.
I still don't see how having API spec with a big fat "everything will break tomorrow, look completely different and may eat your pet hamster - you have been warned" disclaimer is an issue. Existence of a specification doesn't mean that things will be supported forever and are not subject for changes. What matters is that feeling that there's a spec and willingness to publish it - so when it'll be necessary it most likely will be there.
If you even plan deprecations ahead and not just refactor things as development goes then I really don't see what could be wrong, because if that's the case - I believe you're better than a lot of in-house APIs I've seen.
And if you wouldn't have mentioned that you provide spec on request I wouldn't have thought you have it, and if go with RE.
The difference I see is that with open development is so I can persuade myself that when necessity arises I can be sure, having a proper paid account, I can take whatever docs and code is available and help myself. Even though it's recognizably hard it still gives a feeling of safety and control (which IMHO really matters for personal email) - not having to wait for company to eventually possibly release something that may or may not exactly do what I want to have. Developers are, hopefully, sane enough to understand that if there's a warning that things are under development and change then it means that their code will break. And non-developers won't see the difference anyway.
> release access to them
Access is completely different from source code availability, isn't it? Your APIs do account plan checks anyway, don't they?
Re: API access control, sure they do, but given that export is essentially calling 'GET message X' it's not as if we can restrict that to a subset of users.
Still, please consider providing API specifications and, ideally, free licensing of mobile applications' source code, if those won't negatively impact your business. I don't think they should.
I currently self-host but I'm open to the promise of email as a service. I think I can trust you with really encrypting my spam before it hits the storage, however, when evaluating any options I'm always considering "shall they be unable to provide something I'll need - what would be my options?". Full API availability (even if specs are in flux) and ability to hack on client software would mean I can achieve most things or hire someone to do so.
> but given that export is essentially calling 'GET message X' You can rate limit, I guess. That would be fair.
IMAP doesn't have a builtin way to deal with fully encrypted mail transmission including all headers and the GPG user experience is last I checked still subpar while additionally I'm fairly certain it doesn't handle fully encrypted mail.
The problem I see is not that they're not providing IMAP access, but that they're not providing any alternatives except for their product. Would the attitude be "here is a living API spec we currently use, subject to changes without warning, some endpoints not really documented (documentation PRs welcome), and some endpoints require paid account - but that's the best we can afford to provide" - I would've felt very differently about them.