As consumers increasingly purchase sophisticated smartphones such as the iPhone, BlackBerry, and Droid, they are developing expectations for how these phones allow contacts, calendars, e-mail, and social networks to remain in sync across all their devices.
One of the big challenges is that users don't always maintain the same source of inputting data--they switch from browser to desktop application to smartphone as their data access and entry point, introducing many variables into the data chain. And data integrity will only get more complicated as more applications become browser-based and keep no local data storage.
Most enterprise users have a local store in addition to the cloud storage, something that I still find puzzling from the T-mobile Sidekick outage, where consumer data that should have been in multiple locations (or at least present on the device) was thought to be lost.
The most common sync services are not provided directly by the mobile operator. Generally this is a good thing, as the more you can dis-intermediate the carrier, the more control you have over your data. But because the sync services are provided by others--notably Microsoft, Google, and Apple--you end up locked-in to their data structures as well as whatever privacy and data management issues that might arise in relation to advertising or other usage of your information.
Today, you can fairly easily sync your mobile device with most common online e-mail and PIM services although the BlackBerry, Droid, and the iPhone differ in their approaches--or at least in the visibility of how they work. For example, you can sync with Gmail and other services on the iPhone, but it rather perversely requires the Microsoft ActiveSync protocol.
By controlling the address book, Google and Apple effectively lock-in users to their sync service, leaving the carriers and devices to be easily replaced (minus the cancellation charges.) The user would barely notice the difference, aside from the sticker on his phone that says AT&T or Verizon.
Mobile operators do not want to cede control of the address book to Google or Apple, but they are late to the game and do not yet have sync solutions of their own. As a result, they are scrambling to add this functionality, but building a sync solution that works with all different devices and email services is no easy task, thanks to the widespread problem of device fragmentation in the industry.
One option is to deploy a white label solution, like the open mobile cloud sync offered by Funambol. Funambol CEO Fabrizio Capobianco told me the company has been approached by many of the top mobile operators, with several of them looking to setup sync services for their customers. They all recognize the issue, and according to Capobianco can turn to Funambol as a way to quickly bring a high-quality solution to market.
With all the different players in mobile sync, users will begin to question who owns their data. Enterprise users, in particular, should have privacy concerns about trusting their data to someone else. In the case of Android users, there is a growing anti-Google sentiment, and if Google already owns your email, calendar, and search queries, do you really want them to own your phone contacts as well?
Despite concerns that people would forgo dietary staples like bread and milk before giving up their mobile phones, we can definitely expect to see companies and consumers cutting mobile expenses as they look for ways to reduce overall budgets and spending.
The slowing economy has yet to be felt by Apple, with the company announcing that it sold 6.9 million iPhones this quarter (compared with 1.1 million in the third quarter of 2007). With Apple as a clear leader in mobile innovation, will other mobile vendors be able to keep up as budgets are tightened?
Open-source mobile e-mail and platform provider Funambol, issued a paper yesterday outlining eight reasons why open-source push e-mail and mobile sync will triumph in a downturn. Not surprisingly, Funambol predicts that mobile customers will want more value for less.
Why pay $30 a month for a BlackBerry push e-mail service if there's an equally good open-source alternative available for $10 a month? Even better for the tight pocketbook, Funambol recently launched a free version of its open-source mobile push e-mail service funded by mobile microbanner ads.
... Read more
As reported on Moconews, T-Mobile USA is planning to launch an open development platform for all of its phone platforms from upcoming Android to Java to Sidekick and Windows Mobile.
From Moconews:
Starting this fall, T-Mobile USA will take the extraordinary step of ditching its traditional deck on the phone and replacing it with a platform that's open to almost any developer, multiple sources have told us. Think of *Apple's* App store, but for the entire carrier's handset line-up from smartphone to feature phone.
While this is an obvious attempt to compete with the iPhone App store it does a lot more to encourage ecosystems to be built around platforms that are not Apple.
With having gone open source, the mobile market is getting much more interesting. There are more possibilities to bypass the carriers stronghold.
If you want to see people get lit up about a service that they hate, but can't live without, ask them about their mobile phones.
Never mind the dropped calls or the death-grip lock-in, just the outrageous cost is enough to send people into a rage. So, today when Verizon and T-mobile both introduced new flat rate price plans (which are very appealing to heavy users) I would have thought that this would be viewed as a good thing--helping to retain the more valuable customers. Instead, analysts whined that this would undercut pricing. To an extent it will effect all pricing, but aren't happy customers the key to maintaining a successful business?
So, I have to ask, which is better for mobile phone carriers: unhappy shareholders or unhappy customers. My take is that if customers go away, shareholders will be far less excited than if they stay and commit to the service. This equation has been unbalanced for far too long.
- prev
- 1
- next
