Why the BlackBerry? It's shaped like the future.

After the rush of getting Skip's beta product published, it's nice to take a step back and have a look. The first thing you see (if you're me anyway) is missing pieces or obvious questions not really addressed in the current release. One of the biggest, to my mind, is this: Why the BlackBerry? I.e., why is the BlackBerry client the "flagship" one ... and why are the other clients patterned on the BlackBerry client, rather than simply being the best possible implementations for their respective platforms?

It's hardly that the BlackBerry device or platform is perfect for deploying a next-gen mobile productivity app. The total number of subscribers is not large. They are not, as a group, as likely to download (or -- gasp! -- buy) 3rd-party apps as, say, Palm (Treo) users. There is a mass of underpowered legacy devices in use. The platform features an inordinate number of API changes between minor versions; a vendor tool suite from another millennium (an era that Eclipse and VS.net have put behind us); and a complex deploy environment due to the BlackBerry Enterprise Server which provides the "BlackBerry magic" along with numerous possible fine-grained management/security restrictions.

Well here's the deal:

The BlackBerry platform has the general shape of what a net-connected mobile personal device ought to be:

• It's always connected, or at least your app can assume that it is. Net problems are handled gracefully, and the stack is clearly optimized to behave well with the squirrely environment of mobile data. But beyond this, the shape: it doesn't feel like network access was grafted on (virtual serial port + PPP + #777, anyone?). It's just transparently there all the time and in that sense it's more like a PC plugged into a LAN and VPN than other systems (which generally resemble a PC with a dialup ISP account).
  
  
• Threading works well. That's a big and gnarly statement, but what I mean is: for a basic business productivity app that wants to run tasks in the background, including network access, it works so well that I've never had to wonder what sort of embedded OS might be underneath the Java VM. The same cannot be said for many other devices/platforms.
  
  
• Multifunction integration on the device. The code-signing bits for directly interacting with the unit's PIM, telephone, and network are inexpensive and easily obtained. So it's easy to create the kind of smart interconnected apps we all want. The kind where you can dial the phone, if that's what the user wants, or where you can create "hotspots" that automatically integrate with the existing email or web browser tools, or grab a contact from the address book.
  
  
• Multitasking. Based on threads (with enhancements) rather than full process independence, but for the average user, it's multitasking. So you're not forced to quit the app just to check your email, make a phone call, or look at your calendar. You can run Skip in the background forever, if you want to.
  
  
• Upgradeable. The BlackBerry is upgradeable to new platform versions. While this exacerbates the "mass of underpowered legacy devices" issue, it creates more customer (user) empowerment ... like with your PC, you decide when to toss that monochrome unit, or the one with the old processor for the new one with the Intel XScale. But in the meantime, you can keep your data and upgrade the system! From an ISV point of view, this means it's reasonable to offer an app for, say, platform v. 4.0.0+, instead of having to choose to either support the baked-in non-upgradeable platform version in a particular model, or else not support that model at all.
  

I believe that these properties describe the fundamental "shape" of an Internet connected personal device, more than a built-in camera, VGA screen, or even EVDO (or HSDPA). For this reason, the BlackBerry app becomes the flagship. I decided that in the first iteration, I'd like to see how close the other platforms could come to this basic set of functionality. With that territory charted, we can go back and adjust the other client versions in the future, hewing closer to the specific strengths/weaknesses of their respective deployment platforms.