It's really funny to think about cyclical stuff and see how Blackberry used to treat their developers like shit (with stupid signing keys and stuff) and just look at Apple falling into the same trap.
Apple seriously needs to re-focus.
I would say the issue is complicated:
1) BlackBerry was never thought of internally as a 'platform' more of a 'solution' (i.e. you get what you get out of the box) - apps were a little secondary. That perspective was too slow to evolve.
2) The original Java APIs were not very well thought out - part of the problem in 'great docs' was that the underlying platform wasn't very good to begin with.
3) BlackBerry was a tiny company compared to Apple and Google. When BB launched maps, there was no 'mapping team'. There were 0 people dedicated to mapping. G had I think more than 100 at the time, just dedicated to that. BB was growing rapidly, but had found itself jammed between Apple and Google - two of the most magnificent and well capitalised companies in the world.
I'm still amazed that BB had all the features it did given how small the teams were. Most of the handheld - hardware and software - was developed in one little building - you could literally know everyone working on it personally if you worked there.
3) All of that said - the docs were not that bad. Everything was technically documented. The support teams were decent, just small.
All the data was routed through Canada, right?
Kind of, but not quite.
Little known history: BlackBerry 'became encrypted' because back in the days when it was really just a 'pager with email' - North American carriers (channel partners) were actually reading BB executives emails during negotiations (!!!). BB discovered this and decided to start with the encryption. Seriously - the first 'illegal' act was by BB customers/channel partners!
From there, it was always pragmatic. BB was never specifically motivated by protecting individuals from governments persey.
Due to its 'highly secure nature' it was sought after by individuals within regimes that had known surveillance and BB was way ahead of FB/Google in terms of attention by national powers around the world and having to 'deal with them' - at very least because it was actually used by entities in the first place! One of the drawbacks of Barack Obama using your device is that it's 'front and centre' and 'widely used' by every relevant 'agency' in the world.
It was a hugely difficult issue; hackernews tends to be 'anti state surveillance' in all forms - personally, I'm not as long as there's judicial oversight/applied properly (though sometimes it's not the case even in 'good' regimes) - the fact is basically every country you can think of wanted some type of special deal, the details of which I'm not at liberty to go into sufficed to say it was complicated on every level.
I can say however that Venezuela specifically was never going to get any help from us, and that BB was huge in that country due to it's effective protection from federal sources. Several countries like this were 'big blips' in sales due to the networking effects of this and other things. Penetration of BlackBerry around the world was very irregular, not like other platforms.
Why specifically not Venezuela?
Even so the Symbian team did some pretty cool things such as creating open source documentation standards for C++ and the tools to support that.
Source: I was there.
> What's the purpose of the throwaway account for this?
My guess is they want keep their other account pseudonymous, and admitting that they were one of a specific team of 20 people at a specific company goes a long way towards unambiguously identifying them. At a minimum, one of their teammates could probably ID them.
We're talking about one of the biggest platforms in the world here with unlimited money to throw at this problem there is no excuse
In contrast, I've always found Microsoft's documentation to be incredible. It can often be hard to find the right thing (though that has getting better, though that might be just my growing experience on how to find things), but they put real, actual effort into documentation.
Also, Microsoft has a very strong "corporate style guide" for API design. Every MS API within their major silos is built exactly the same way as every other API. Once you've had some experience with them, it's easy to figure out the others. I find Android to be down-right schizophrenic in comparison.
It's one of the many reasons I continue to focus on MS platforms for my work. It's been 20 years since they were the hostile "kill everything that moves" company that people lament.
In contrast, I've always found Microsoft's documentation to be incredible.
I don't know how Apple and Google work, but as a long-time-ago MSFT employee, I can tell you it is because they have entire teams. Chain-of-command, senior-level, leads, managers (don't know if there's such a thing as User Ed VP/Director, though) the whole works, like Microsoft kinda took it seriously or something. Hence my ranking of docs:
1. Microsoft: could be better, but you're going to have an easy time finding worse. No, they're actually pretty damned good. When I worked there, for instance, there was a big push that example code will be secure. The mantra was "sample code becomes production code". APIs have close-to-real-world examples of usage. "Could be better"? Eh, I don't know what I'd improve, frankly.
2. Back before they got really big, I'd say about Apple's docs, "does the job; it's not Microsoft-quality, but they don't have Microsoft resources, now do they?" Umm, that's not true anymore, and I think the quality has gone down since.
3. Google: just use Stack Overflow. The docs are just going to frustrate you with their incompleteness and outdateness.
Even if the documentation department never made a profit themselves, I imagine being able to point to some revenue and it being an important part of the overall business strategy kept it as feeling fairly important to most execs.
In that Microsoft has it, Google doesn't, and Apple... magic?
But if you're going to run a competent support org, you need to have high-quality, easily-accessible documentation. Because you're not going to know anything about {insert random thing support ticket is asking about}.
And if you've already created those docs for internal use, why not simply make them public?
https://docs.microsoft.com/en-us/windows/win32/api/winsock/n...
Compare with the MSDN page which is surprisingly still there (if it isn't when you read this, check the Internet Archive):
https://msdn.microsoft.com/en-us/windows/ms741519(v=vs.100)
Or just plain misleading, like this function which definitely returns a value but has "void" in place of the actual type:
https://docs.microsoft.com/en-us/windows/win32/api/wininet/n...
The page on MSDN is correct as usual:
https://msdn.microsoft.com/en-us/windows/aa385098(v=vs.80)
I've also noticed a relatively huge amount of grammar/spelling errors in their newer docs, no doubt because MS has lost much of its real documentation team.
Fortunately most of my work with Win32 uses stable APIs that have been around since Win95/NT4, and thus are nicely documented in the infamous WIN32.HLP.