Why on request but not public? Why plan but not have it so from the beginning?
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 API docs are available on request mostly because we are phasing out some old APIs we don't want people to use and don't have bandwidth to provide support for them.
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.
> because we are phasing out some old APIs we don't want people to use
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?
These are good points, though at this point I think it does make sense to wait a bit to clean up the deprecated stuff, given that a lot was waiting on this release and we'll probably drop the old stuff in a month or so.
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.
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.