Palm’s future in the smartphone market remains uncertain, but its technology could prove valuable to Research in Motion, makers of the popular BlackBerry smartphones – especially as Research in Motion (RIM) continues its consumer push.

Reading David Coursey’s InfoWorld post “Palm is doomed; let the good-byes begin”, I couldn’t help but wonder “what next for Palm?” As Coursey and the Wall Street Journal mention, Palm has released strong products since re-launching on the WebOS platform and enjoys excellent carrier support. Yet, this hasn’t helped Palm’s share grow:

“In the nicest way possible, it (the Wall Street Journal) says Palm, with a mere 0.7 percent of the smartphone market, compared to 14.4 percent for Apple and 20 percent for RIM, simply can’t catch up.”

Being acquired by RIM is definitely one answer to the “what next for Palm” question. There is however the slight issue of Palm’s $1 billion market cap putting a serious dent in RIM’s $1.3 billion cash and near cash position. However, RIM doesn’t have any debt, so there’s room to finance the acquisition. RIM’s stock, while not priced where it’s used to being, remains on most investor’s tech stock short list, and could help fund the acquisition. For our purposes let’s assume RIM could close the deal.

The larger question is “Why would RIM want to acquire Palm?”

The 0.7 percent market share of Palm isn’t reason enough to acquire Palm. RIM could get its share of that 0.7 percent as Palm users look for future devices from Apple, RIM or Android phone manufacturers.

One reason to acquire Palm would be to leverage Palm’s open source experience. I’ve argued that RIM could benefit from using open source more effectively in its business. Palm would jumpstart this effort.

The more compelling reason to acquire Palm would be Palm’s WebOS platform. The BlackBerry platform, built on the aging BlackBerry OS, is in serious need of a refresh. This is less the case for enterprise BlackBerry users, many of whom couldn’t function without the email and messaging capabilities that the BlackBerry excels at. The user interface and rich interactivity of BlackBerry applications are secondary to the mail and messaging requirements. This will change over time as more businesses expose enterprise applications to mobile devices. For instance, the fact that a company’s CRM application is more usable on an iPhone or Android versus a BlackBerry may well entice an enterprise user to migrate off their BlackBerry. A revamped OS would resonate a lot more with younger consumers deciding between an iPhone or a BlackBerry Curve. The fact that one’s friends are on BlackBerry Messenger (BBM) is reason enough to leave behind 100,000 plus iPhone apps for the ability to communicate with tens or hundreds of ones (closest?) friends on BBM. BBM is an instant messaging platform available to BlackBerry device users. Giving these consumers users a richer, more fun, user experience would go a long way towards keeping these BlackBerry users happy in the face of iPhone toting friends.

The user experience would be vastly different between a WebOS-based BlackBerry and a BlackBerry OS-based BlackBerry. But this would be a point in time statement and one that retains and attracts both enterprise and consumer users. For a consumer the WebOS-based BlackBerry lineup, especially if new RIM designed devices are released in addition to the existing Palm devices, would be a much more compelling user experience than what’s available through the current BlackBerry OS-delivered user interface. For the enterprise user, the addition of a WebOS-based BlackBerry line, along with RIM’s commitment to bring the user experience to all BlackBerry’s would be a reason to remain a BlackBerry user until the new interface arrives on BlackBerry’s enterprise-targeted product line. Waiting for coveted features on a product or platform you’ve already invested time and money in is not uncommon in the IT market. For instance, as terrible as the BlackBerry browser is, many BlackBerry users are waiting at the edge of their seats for a new WebKit-based browser rather than jumping ship to an iPhone or Android device.  Early iPhone users lacking copy and paste capabilities are another example.

There’s also an issue of existing BlackBerry applications running on WebOS-based devices. Maybe a stripped down BlackBerry OS could run in a virtual machine on the mobile device? I’m sure RIM’s engineers could come up with some creative solutions.

As a BlackBerry user, I’d love to get the WebOS user experience in addition to the email and messaging capabilities of a BlackBerry.

Would you?

Follow me on twitter at: SavioRodrigues

PS: I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.”

Last week I wrote about the benefits of open standards versus open source. I argued that open standards provide greater protection against vendor lock-in than open source alone. I was reminded of this conclusion when reading Peter-Paul Koch’s analysis of WebKit implementations. Thanks to Palm’s Dion Almaer for pointing out the analysis.

Readers know WebKit as the open source web browser engine used by several mobile and PC web browsers including Apple’s Safari, Google’s Chrome, Palm’s WebOS and the Web Browser for Android. In fact, Wikipedia lists 19 browsers that are based on the open source WebKit browser engine. As you read on, keep in mind that there is no standard that vendors using WebKit must adhere to or claim certification against. A WebKit based browser is, well, whatever the vendor wants it to be.

When Koch tested WebKit browser versions on twenty seven tests, he found:

  • Out of 19 tested WebKits, no two are exactly the same.
  • The best WebKit available is Safari 4; the worst is S60v3.
  • The Android G1 and G2 WebKits score rather badly; it’s the worst mobile WebKit except for S60.
  • Regressions are fairly common: iPhone 3.1, Android G2, and S60v5 all (partially) dropped support for something their predecessors did support.
  • The closest relation of a desktop WebKit to a mobile WebKit is between Safari 3.0 and S60v5. I’m now fairly certain S60v5 is actually based on Safari 3.0. Unfortunately this is the single example of such a close relation.

Koch’s testing highlights two truths. First, pity the mobile web application developer whose manager or customer expects that the application will work on multiple mobile browsers that are “built on WebKit”. Second, open source does not make it easier for customers, or their developers, to transition applications from, for example, building for the Google Android platform to, for example, Plam WebOS.

Imagine if there were a WebKit standard and a compliance test suite that vendors had to certify against to use the “WebKit” brand. Customers and developers would gain protection against vendor lock-in that open standards deliver to a much higher degree than open source alone. I’m not naive enough to think that open standards equals “write once, run anywhere”. But even if a WebKit open standard could drive a 50% improvement in compatibility across WebKit-based browsers, that would be something to write home about.

Follow me on twitter at: SavioRodrigues

PS: I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.”

I’ve blogged about building native mobile device applications using a Web technology-based framework such as PhoneGap from Nitobi in the past. When I first wrote about the open source PhoneGap project in March 2009 I concluded: “If I worked at RIM, I’d take a trip out to Vancouver to talk to the Nitobi dudes. This framework is exactly what RIM needs to counter the trend of developers targeting the iPhone/iPod as the premier environment for mobile device applications”.

Fast forward seven months and RIM announces a beta of the BlackBerry Widget SDK that:

“allows web developers to package up their web assets into BlackBerry Widgets (small, discrete, standalone web applications that use HTML, CSS and JavaScript). A BlackBerry Widget looks, behaves and has the same security mechanisms as a native BlackBerry application. BlackBerry Widgets can be installed on a BlackBerry smartphone like any native application and can be extended to use device-specific information and data using the BlackBerry Widget APIs.”

Wow, sounds like an enhanced PhoneGap tuned for BlackBerry applications. With fingers crossed I pinged Andre & Dave to ask if RIM was using PhoneGap for this SDK. I’d scoured the BlackBerry Widget SDK website and knew the answer before Dave and Andre replied “nope”.

This was absolutely a missed opportunity for RIM to compete versus Apple, Palm and others using open source. No, I’m not going to suggest that RIM open source the BlackBerry Enterprise Server; that would be silly. Rather, I believe RIM could have saved R&D costs, increased the value of its BlackBerry platform and influenced developers building for the iPhone if RIM had built the Widget SDK on top of the open source project like PhoneGap.

RIM should be utilizing R&D investments more effectively by leveraging exiting open source projects. RIM could have built this SDK for a lower investment by staring with PhoneGap, or another equivalent open source framework. Of course there might have been a feature gap between what PhoneGap offers and what RIM wanted to deliver in version 1.0. However, assigning RIM developers to the PhoneGap project to add these features whilst leveraging all the other APIs in PhoneGap would have saved RIM the work of reinventing the wheel for those other APIs.

RIM would have also benefited from new features added by the PhoneGap community. A PhoneGap community member who loves his BlackBerry and wants to “scratch an itch” could contribute a PhoneGap feature that other BlackBerry developers would find extremely useful.

Finally, RIM would be contributing to a framework that developers are already using to develop iPhone applications. RIM needs to figure out a way to entice developers to build BlackBerry applications before iPhone applications. However, RIM should also be working to get developers to port their iPhone apps to the BlackBerry platform. As a PhoneGap contributor, RIM could offer a simple and painless porting option for existing and new PhoneGap-based iPhone applications.

I could come up with additional benefits for RIM, but these three are big enough for RIM to reconsider its strategy for delivering the Widget SDK. RIM could yet contribute all or part of their Widget SDK to an established mobile framework open source community and build its Widget SDK product from the resulting open source community code.

I suggest this strategy because I’ve witnessed IBM using it with great success. In the WebSphere division, we contribute to countless open source projects, including the Apache HTTPD, Dojo Toolkit and Eclipse Equinox projects. We then utilize code from these projects with IBM enhancements inside of WebSphere Application Server. This strategy allows us to, with less, do more.

I hope friends at RIM can learn a lesson from IBM’s use of open source for competitive differentiation. With Dion & Ben at Palm, you can bet that Palm is thinking about using open source more effectively within its strategy.

Follow me on twitter at: SavioRodrigues

PS: I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.”