If you're working on a RIM app, I'm asking you: why? I am honestly curious.

Edit: I went to rim.com, and after three pages and six clicks (including that funny country selector thing - why do I have to do this again? I don't need to do this when I visit apple.com), I finally got to the "playbook" page. But nowhere on that page is any indication of when I'll be able to buy this thing, or any kind of online store that would let me order it. All I can see is "Get Updates" which takes me to the form on the bottom of the page where I can tell them how to send me a promotional newsletter. (This makes me glad that I bought an iPad last April. If I had to wait for RIM, the best I could do would be to print out a picture of their product, glue it to a thin book and pretend that I have an iPad.)

Edit #2: You know, Palm made a great effort at almost this same thing, actually shippped their product, and they still sank (and they're only relevant now because HP picked up the pieces) for messing up less than this. How is this going to be any different, except that this time around, there's won't be a suitor like HP to buy up what's left of RIM?

Mike Kirkup had promised free Playbooks to devs who got their apps submitted early on. (NB: I don't know if that still applies, that was last year.) So there's a pretty good reason, submit an app, get some free hardware.

The main reason though would be if you were a Flash developer. Playbook looks like an absolute godsend for them, because they can just take their flash app, wrap it as an archive (presumably signing it and zipping it up) and plop it straight into Playbook. I'm not aware of any other mobile platform that runs adobe stuff natively like that.

Of course, all of RIM's developers were Java guys, so you can imagine that the subset of their developer base that were also secretly Adobe fanboys was actually quite small...

Nokia and RIM both seem to be massive train-wrecks in the whole 'looking after your developers' department. Maybe the guys in Waterloo have been taking coaching from Elop or some other major Microsoft shareholder.

Next to that, if I select it once, I would hope Apple would be at least smart enough to save my selection in a cookie, so that when I visit the site tomorrow, it doesn't require me to enter the same exact information.

It's obvious Apple is dropping the same ball on browser locale here just as RIM does, so my comment disproves his comparison with Apple.

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14...

This is a really good point - GeoIP is almost guaranteed to be accurate enough to determine country of origin now. We should no longer have to deal with that crap.

No. No no no. Please don't do that. I know everybody does, but it's such a terrible idea. If you rely on geographical ___location to set language, you're ignoring travelers, expats, regions with multiple languages, etc.

Look at my browser's Accept-Language header. Go with that. It's almost certainly what I want. If you have a really good reason to serve me content based on my ___location, use GeoIP to determine that. Never ever use it for language. And make it really easy to change both.

I would prefer a combination though. If I live in Italy but am browsing in English, use the Italian product page via GeoIP but the language according to the Accept-Language header.

We are responding to criticism just as we respond to competition: We announce that we're working on something wonderful which will ship Real Soon Now.

Actually doing something about our development tools and process will be prioritized with the same business processes that are responsible for doing something about Apple and Google fighting over our lunch in the tablet and greater mobile space.

My prediction:

Some time after it is far too late to stop independent developers from defecting to other platforms, RIM will discover that even their corporate strongholds are looking at switching to Android or iOS, and will get feedback about their tools from their existing customers.

They will then make something just like Blackberry Storm: It will have the surface appearance of a slick, easy to use developer process that will satisfy the CTOs playing golf with RIM salespeople, but will somehow be unusable in ways that make the actual developers cringe.

I think that senior RIM management should start visiting old folks homes and talk to people who worked in the disk drive business and the cable-actuated construction equipment business. They may find they have a tremendous amount in common with people managing those businesses.

-----

An alternate view, as presented not so long ago by one pundit is that RIM doesn't even realise how bad their position is, because they are still making a lot of money and still have a lot of market share. The thing is that if you drop from 30% market share to 20% market share that is bad, right? Well, what if the market tripled in that same time? You would be losing market share, but actually selling twice as many units as you did in the previous time period!

And RIM has had some gangbuster sales figures. Profit? Not so much. The pundits argue that the gangbuster sales are blinding RIM to the fact that their margins are rapidly disappearing.

----

So here's some scenarios:

(1) it is entirely possible that they have no idea how bad things are for them.

(2) they know, but they don't know how to fix it (because it depends on the whims of external developers, and yea forsooth we art mightily fickle beasts)

(3) they know and there are no quick fixes. The iPad was in semi-secret development long before the iPhone was announced. The iPhone was announced in 2007 I believe. You do the math. No wait, I'll do the math for you. This means that everyone else is 4-5 years behind Apple. The problems RIM are running into now are problems that Apple was solving back in 2006 or even earlier. Some things just take time.

(4) They have been surprised by the lack of enthusiasm/rate of abandonment from their old devs. RIM has a history of short term kludges to try to fix their developer relations. E.g. instead of maintaining their IDE and modernising it, they let it fester and rot, and then when it started to smell too much they jumped on the Eclipse plugin band-wagon (which was an ugly kludge at best). But my estimate would be that of any random sample of Java devs, at least 60% of them actively dislike Eclipse. So the band-aid solution just slices their pool of potential developers even more finely.

I think the RIM response was great given the timing and don't be too quick to decide it fell short given that the people who would need to be involved in any change to their policies probably are not easily obtained during a weekend.

Lets see what else happens over the course of the working week.

Now admittedly they might have initially gotten drowned out by the screams of a million java developers wailing and gnashing their teeth about having to pay big $ to do everything with the adobe tools (or, alternatively to do everything on the command line, which is a huge pain in the bum when you're having to learn a new toolkit from scratch).

The fact that it has taken them ~6 months to take their fingers out of their ears and stop saying "la la la la la we can't hear you" indicates just how humungously badly messed up RIM is right now.

They don't deserve credit, they deserve a bullet. And the way they are headed the market is going to give them one.

1. They would take at least a month to notice (if at all), 2. Nobody would go to write an actual response, 3. The customer would be flagged as "that pedantic asshole", 4. Any internal dissenters who would notice the whole deal would be ignored or coerced into obedience.

Oh and not to mention that said organization has immense illusions of grandeur.

Your company with the one month time to notice and make a response is actually responding 5 times faster than RIM in this instance. Scary eh?

Don't get me wrong - I see RIM as going the same way as NOKIA (read: nowhere fast). But to their credit - they were able to get an actual product to the market and get to where they can fall deep :).

Have they actually started selling Playbooks? My understanding is that it has been in a state of "we'll release it real soon now" for quite some time.

I can't help myself thinking of a saying: Losers always whine about their best. Winners go home and fuck the prom queen.

After a decade of Palm, WinMo and Win development I can say that the tool set and tool process were the worst I had ever experienced, even including Palm OS 1.0 releases. Code signing was a horrible pain. But my $2k bought us lots of help from their tech team, which was fantastic.

Where things fell apart was around shipping. What I thought I was getting was some tech support and marketing position, but RIM's partners were pretty much ignored and we were quickly out of the loop. There were no app stores so site placement at RIM was critical. Any mentions of partner companies were well buried on their site and every time there was a special section focused on our customer sections, we were left out.

We stayed involved for another year until RIM revamped their developer program so you had to meet certain requirements to be involved, all of which were aimed at helping RIM. You had to bring customers or come to their dev conference -- not free -- and a host of other things that would earn us points to participate. This was on top of the $2k per year to be in the program.

So while it is good to see a response from RIM so quickly, I am highly skeptical that the company can really be developer-centric and do what is right for its community. The only way they get us as a developer now is to fully support Android software as all the rumors are indicating.

I suspect the iPad will continue to dominate this year as more android developers gear up for honeycomb. Where does that really leave the playbook. Specs are great, but apps sell hardware.

They are essentially applying a financial penalty to iterative development. Unbelievable.

Patching your app? $20 please.

Is this actually a meaningful revenue source?

Which is refreshing in a way, because usually when people are being that hysterical and illogical it is over Apple. Nice to see some other company getting that treatment for a change.

"Is this actually a meaningful revenue source?"

Obviously not. 0 x N = 0 after all. They will however try to make it up in volume (normally a bad joke, but in this case it makes sense). They are massively behind Google's and "the company which must not be named"'s app stores... how then will they come to market with a credible number of apps?

I think the switch to Flash is by RIM a vote of no confidence in their current developers, and I think they were hoping that a big bunch of Flash developers would jump on the band wagon. It might work, who knows. Flash developers have basically no other ways of monetising their work (other than page views of course) so it might seem like a good deal to them. RIM might have looked at their piddly number of apps available for sale for the blackberry and decided that their Java developers just weren't up to snuff.

Of course there are or were systematic issues with app world (basically not available for a very long time outside of the US, the carrier will often not install the app world app, or will delete it before selling the blackberries to the customers, even if you know of its existence it is hard to find etc.)

Also, if the Java developers suck so much, why has Google's app store got so many apps?

All it does is make developers nervous that they might be locked into paying money in the future. Just do like Google and charge developers a token fee (to verify identity and intent, I'm guessing) right from the beginning.

If the goal is to lower the barriers to developer adoption, a $25 fee isn't going to stop anyone like the threat of a $200 fee in the future will.

1. Yes - great, they replied publicly. While others may have complained before, at least they're finally replying in public.

2. "Suggestions like his are critical in helping us improve our products and processes". Why should things ever be as remotely bad to start with as what the OP was describing? Downloading an installer program that just copies an ISO to a folder? SDK and Simulator only available as separate downloads? Repeated data entry on multiple screens? Does no one at RIM sit down before things are released and say "OK, let's test this end to end and see if it really makes sense."?

Again - great that they responded, but having multiple poor experiences rolled up together gives the impression that RIM just really doesn't care that much, and can't be bothered to make the process for developers remotely straightforward.

The blackberry eco-system is to a certain extent based on trust. But the trust is backed by accountability. Every piece of code that runs has to be signed by RIM† using your personal signing key. That way if somebody writes an app that does something bad, they know exactly who is to blame.

It is kind of the opposite of Apple's walled garden approach, but it achieves the same goal - that end users can trust the software from dodgy third party devs like you and me. In Apple's case it is because they 'carefully' cough vet the apps. In RIM's case it is because they will come down on you like a ton of bricks (wrapped in legal weasels) if you do anything dodgy.

†This applies even for you writing and testing code on your own device. You have to send the code to RIM who sign it and munge it up with their 7 secret herbs and spices and then they send you back a binary file that is what you actually install.

RIM's challenge here is to convert developers into RIM developers, i.e. people who are going to make them money. Why throw in any more hurdles than necessary?

Information should be requested at the last moment it is required. For instance, initially ask for an email just to ensure it the SDK results in a computer being vulnerable to security issues. Deployment to a virtual machine running beta versions should not require any code signing.

On the Blackberry for instance, I could put up a web page with a link to my test file and you could download it directly to your device.

Hence everything needs to be signed before it can run.

Now, that said, the crusty old IDE that they had for Blackberry development had an emulator built into it. Being an emulator there were certain things you couldn't do (make calls, bluetooth etc).

If you asked "why didn't they just do another emulator?" that would be a good question. Complaining about the code signing is not a good question - it is far too fundamental to how their whole infrastructure works.

Also, the code signing process itself is automated, so in terms of interrupting you workflow it is not too bad (if you have a good internet connection) - 15-30 seconds or less -I've seen corporate build files that were worse... much much worse. /twitch

A simple, "We've told the X team to get a clue and fix the multiple registration form stupidity by next Friday" would go farther than eight paragraphs of borderline marketing bilge.

Of course, these are not the /actual/ problems at RIM. The real problems are the mindset and processes that allowed this type of stuff to happen in the first place. They have a long row to hoe to get their house in order, since it's probably fractally bad in there.

I should add: I was in a developer tools org once (at a certain large hardware company) that had nearly exactly the same problems: Expensive tools, confusing processes, and probably worse support than RIM has. Over years of trying, the underlying troubles were never fixed (but a lot of manager careers were lofted on internal promises and new "team initiatives").

This is a new platform, analogous to apple when they migrated to osx.

If this was 1998 you could replace every RIM with Apple in these threads.

It's a very easy thing to throw stones.