Skip to content

Comment on You win, RIM (An open letter to RIM's developer relations)parent

Comments

Honestly as an ex-indie PalmOS developer, I'm having trouble being sympathetic. I don't do blackberry myself, and don't have any particular affection for RIM, but this is just a little much.

As I understand, RIM's gonna do all the fulfillment & billing for you in the app store? This is the SDK for an unreleased product? On a new, unreleased OS? On a different architecture than your dev machine? Yeah, it may require some paperwork, and the SDK & dev docs might not be where all their developers' attention currently is.

Actually, the 10 app limit impressed me. I don't want my apps as #13 in middle of 25 variations of the same app from another developer. $20 a product just isn't expensive.

Also, why do you have to use VMWare fusion if it's an ISO? Couldn't you use any of its competitors if it's not in a proprietary file format?

Finally, as for all the 'cryptic commands'... write a shell script. ( http://tldp.org/LDP/abs/html/ )

If you want a button, write an applescript app that shows a button & runs the shell script. ( http://www.mactech.com/articles/mactech/Vol.21/21.04/IntroTo... )

It's not a question of whether you CAN make it work, but whether you should have to. RIM is in competition for developers with Apple and Google. Why would a developer choose to go with RIM when the experience is much better elsewhere. I think we can all agree that apps are one of the things that will make or break a smartphone platform in the current market conditions. If RIM can't attract talented developers to write apps for their platform, the outlook can't be good for them.

RIM's got two nice advantages to it:

(1) Employers often pay for the BB, and the data plan. You're getting access to a lot of users who wouldn't otherwise be customers in the smartphone arena.

(2) As the phones are already part of the business's primary operations, you have some nice opportunities to sell apps that integrate with the business.

Considering that RIM's product isn't even out the door yet, and the specific strengths RIM holds, it's not 100% comparable to the iOS & Android side. You've got the chance to provide something that isn't a (a) fart app; (b) casual game; (c) train schedule; or (d) local wrapper for the website.

Frankly, the superficial weaknesses of the form fillout and download procedure just aren't substantial. That's what, half a day? The next few months are gonna be in the APIs, and the next few years are gonna be in the customer base, app market, maintenance, and support of the app.

I'm not sure the first advantage really makes a difference though. Corporate users are not buying a lot of apps. This is shown in the latest market share data, where the App Store took in $769 million in revenue, with RIM App World in second place with only $36 million. This is especially significant because RIM has a similar smartphone market share as Apple. So you've got two companies with similar market shares, and one is doing 21 times the app revenue than the other.

The 2nd point is definitely valid, but it's a niche market. I'm not saying ALL developers would abandon RIM, but just that most would. I don't think a major player in the smartphone market can afford to only go after a niche market.

I agree that a lot of the stuff I mentioned is small. But a lot of small problems add up to a big problem. It's well known in the development community that Apple and Google have superiors SDKs in terms of ease of use, as well as tools and APIs. With the Android growth explosion, they will have a much bigger app market, and Apple will probably have the most profitable market for some time to come because Apple customers have demonstrated their willingness to spend money. RIM is going to have to really up their game if they want to lure some of the talented developers away from the other platforms.

To add on to your first point, I know people who have company-provided-and-paid-for blackberries, and they buy their own iphone out of pocket and use that more. the BB is just for the bare minimum compliance at work - all their downtime is with their device of choice - and that's where their money gets spent (on apps, add-ons, etc).

Would people using company-provided blackberries - the kind companies love because they can be 'locked down' to the 'enterprise's' needs - even be allowed to purchase apps on their own?

Not to mention this market segment is usually behind a product iteration, or two, due to corporate security policies. This bunch probably won't have the Playbook or whateverphoneisnext--that can actually do anything remotely worth purchasing--vetted for them until RIM's all set and done.

#1 is a big disadvantage. Those devices are all locked down by IT staff and software won't install. RIM is a tricky platform. I found that the market is split mostly between consumers who text and corporate/government employees who have their devices locked down.

Depends on the employers. Lot more employers now are willing to switch away from BB. There were some reports few months ago that was showing how the BB market on corporate/enterprise was declining.

For me personally, I own both Droid and iPhone, and bought lots of apps as well, with my own money. There's no way I will do that on BB.

As an old Palm OS developer and someone who wrote code for BlackBerry OS, I can tell you that BlackBerry is much much much much worse than Palm OS ever was.

As someone who, at one point, tried to write for Palm OS: wow, that must be awful.

ON the bright side, I think the Playbook is based on QNX, and hopefully will have a different experience from BlackBerry OS...

> Actually, the 10 app limit impressed me. I don't want my apps as #13 in middle of 25 variations of the same app from another developer. $20 a product just isn't expensive.

Completely agree. It's like if email spammers had to pay 1 cent per spam email - spam would go away. With Android as an example, when there's no cost to publish per App, you get a ton of garbage. I think $20/app is a good value to discourage spam.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.