Dear RIM, time to pull your finger out

10 comments

Posted on 15th February 2010 by jeff in Mobile

BlackBerry, Android, Apple and Windows

BlackBerry, Android, Apple and Windows Phone 7

I’ve been a long time user of BlackBerry devices, from the very first “Inter@ctive Pager”, the 850, to my primary device today, a Javelin 8900 with at least one BlackBerry from every major RIM epoch along the way. In short I’m a huge fan.

Today’s consumers have unprecedented choice when it comes to choosing a smartphone. Recently, the details of Windows Phone 7 were made public along with the news of Nokia and Intel teaming up. With increased competition from handset manufacturers and the carriers, the consumer wins and that’s a good thing for everyone.

I’ve used devices from Apple, Nokia, Motorola and HTC running Android, iPhone OS, Maemo and WinMo. Each has it’s own strengths but if I have to write an email longer than a few words I definitely want to be on RIM hardware but that’s not the case if I have to write software for a mobile platform. RIM is the last platform I want to be on.

I don’t think it is any secret that RIM’s development tools are by far the worst on the planet. That crappy experience extends beyond to the JDE to other aspects of building and developing for the BlackBerry platform.

Today RIM faces a fork in the road — a giant, prickly fork. Will it react quickly to increased market competition or keep its head in the sand until it is no longer relevant? Here’s my wish list of things RIM should fix now in an effort to attract developers to its platform while retaining its current flock:

  1. Fix the cold war era JDE. While it is a blast from the past to code in the JDE, bringing it on par to the productivity of competing platforms isn’t an option anymore, it is necessary. Providing an enjoyable and productive development environment would be a really good idea. Spend some time in the other environments to see what you’re up against, I think you’ll be shocked. About as shocked as developers who come to the BlackBerry platform are when they fire up the RIM tooling. The Eclipse plug-in is a step in the right direction but there’s a long way to go. Design time UI previews anyone?
  2. Fix the OS. I prefer RIM’s approach to threading and background processes over its competitors however the OS itself feels antiquated, that’s because it is. 5.0 is yet another step in the right direction but RIM needs to start taking some leaps. Forget about Apple, have you seen Windows Phone 7? Now change your underwear and get cracking on a new, sexy UX stat.
  3. No more secret APIs. RIM already requires code signing to do anything useful on the platform, that same signing should give you access to all the APIs. The era of RIM being able to create more interesting 3rd party apps (GTalk, Facebook, etc…) than its developer community has to end. No more secret, special access APIs. It’s all or nothing time.
  4. Embrace your developers, don’t compete with them. The best way to scare developers away from your platform is to create the fear that you’ll eradicate them in an instant, senseless act. For example there are several Twitter clients available for the BlackBerry: TwitterBerry and SocialScope are two that I’ve used quite happily myself. So why alienate those developers by releasing a RIM Twitter client? Now perhaps there was a good reason why you felt your user base required a RIM provided Twitter client, but in the absence of some explanation and details, it just looks like a dumb move. RIM you need every developer you can get right now, chasing them off your platform  by competing with them doesn’t just kill a handful, it scares the crap out of your entire developer ecosystem.
  5. Work on a Mac. Why doesn’t the JDE work on a Mac? Head to a DemoCamp and count how many Windows machines you see. My guess is that you’ll find you’ve lost more than a few would-be developers because they weren’t willing to fire up a VM to use your tools.
  6. Fix AppWorld. This is a biggie. AppWorld blows and everyone knows it. Do whatever you need to do with the carriers to make AppWorld pre-installed on every device. Fix the payment process so it is as frictionless, if not better than the iTunes/AppStore process. Innovate here, connect developers with their customers. Recognize that most mobile app developers are small shops. Jump on the Lean Startup/Customer Development/Metrics bandwagon and enable us to interact, to measure and respond and I promise you both developers and customers will beat a path to your door.

Ok RIM, I’m rooting for you, I really am. I haven’t dumped my device or sold my stock but I need to some action and I’m afraid I’m not the only one.

This website uses IntenseDebate comments, but they are not currently loaded because either your browser doesn't support JavaScript, or they didn't load fast enough.

10 Comments
  1. Speg says:

    I’m not holding my breath. It’s been 3 years since the iPhone was unvieled and RIM is still limping along with their Java dog.

    15th February 2010 at 9:47 pm

  2. uberVU - social comments says:

    Social comments and analytics for this post…

    This post was mentioned on Twitter by WatTechDigest: Two local takes on RIM: 1) Jeff Fedor http://bit.ly/9ki2jI 2) Christopher Reid http://bit.ly/9csTkL...

    15th February 2010 at 10:30 pm

  3. Shai says:

    right on, I wrote a related blog post as well, focusing on why I think Android is big trouble for RIM – http://shaigoldman.wordpress.com/2010/02/16/rimbl...

    15th February 2010 at 2:46 am

  4. jfedor says:

    I think it is deeper than that. Google is doing fine with their Java dog but it is much more of a playful pup. RIM's dog is arthritic and needs a nap.

    15th February 2010 at 3:06 am

  5. Jim Murphy says:

    Great post, Jeff. Its great to see some of the local conversation fodder getting written down and out in the open where (hopefully) it can do some good. As you know I've had this very same conversation with a dozen people, half from RIM. *Everyone* knows this is the case and in say 5 years when RIM is in serious trouble I'm sure there will be no shortage of geniuses that point back to the disconnect with the developer community as a primary misstep.

    I want to see Jim on stage doing the "developers, developers, developers…" monkey boy thing(http://tinyurl.com/yckzcy). But, as your post implies I worry that its more of a cultural problem. Is encouraging an ecosystem really in the DNA of the company?

    I hope for its sake it is.

    15th February 2010 at 2:27 pm

  6. Jim Murphy says:

    Sorry for that trailing ). on the previous comment. The working url is:
    http://tinyurl.com/yckzcy

    More to the point would be:
    http://tinyurl.com/2xzgaq

    15th February 2010 at 2:31 pm

  7. jfedor says:

    Shai, you beat Google to the punch: "Google's Future is in the Enterprise" http://www.readwriteweb.com/enterprise/2010/02/go...

    15th February 2010 at 3:56 pm

  8. jfedor says:

    I'd smash my iPhone to see that: "Dance Monkey Boy!"

    I think you're right though, this has to come from the top. Perhaps a little less NHL folly and a lot more developer love.

    15th February 2010 at 3:58 pm

  9. Socorro Cimko says:

    Most testers find themselves outnumbered by devs. In my instance it’s almost 10 to 1. (The desirable ratio is a spent discussion I’d like to head off in this post.) Alternatively, I would like to bitch about a problem I’ve discovered as I amass more projects to test. Presuming my ten devs are extended between five projects (or app modules), every dev must pay heed simply the Feature Review/Design group meetings for the project they are responsible for. However, the tester must pay heed all five. Do you figure a problem here? Let’s do the math for a 40 hour work workweek. If every project’s Feature Review/Design meetings consume eight hours per week, every dev will have 32 hours left to write code. Every tester is provided with ZERO hours to examine code! The above scenario is not that much of an overstatement for my squad. The tester has no choice but to skip some of these meetings just to pinch in a little testing. The tester is asked to “stay in the know” about all projects (and how those projects mix with each other), while the dev can often focus on a single project. I conceive the above-mentioned problem is an oversight of many managers. I doubt it gets acknowledged because the testers’ time is being nickel and dimed out. Yet most testers and directors will assure you, “It’s a no-brainer! The tester should attend all design reappraisals and feature walkthroughs…testing should initiate as early as possible”. I agree. But it is an nonrational expectation if you staff your team like this.

    15th February 2010 at 11:27 am

  10. jfedor says:

    I'm all for an appropriate ratio of testers to developers and would never recommend 1 to 10. I feel your pain. I don't blog much about testers but there's an older post here: http://buzzpressure.com/2007/11/08/test-test-revo...

    15th February 2010 at 12:06 am

Leave a comment