GPhone — If I Built It (Part 3)
This is the third and final part of this series. If you haven’t read the first two, check them out here:
The news around GPhone has heated up in past few weeks. There have been several reports of Google working with wireless carriers like T-Mobile and Sprint. WSJ even reports that the announcement can come as early as Monday.
So it will soon be evident as what Google has in store for us. Until then we can speculate. So in this final post of the series, I look at two major components of the GPhone ecosystem, the “Application Ecosystem” and the all important “Revenue Enablement”.
Application Ecosystem
Current mobile devices are notorious for limiting access to 3rd party developers and app providers. They offer restrictive sand-boxed environments with J2ME and BREW. I have seen some great applications deployed using these environments, but they still do not come close to any application written to leverage the phone’s native capabilities. This includes newer devices like the iPhone as well. Think about the possibilities, if Apple offered access to native capabilities like the Accelerometer to 3rd party apps.
As user’s expect more and more everyday from their cellphone, the success of next generation mobile experience relies heavily on ability to allow 3rd party applications. From my point of view, Google should take the lead and squarely address this situation. Facebook’s developer program has demonstrated the success of such an approach.
Google who already offers services like Google Gears, iGoogle and now OpenSocial is well versed with enabling such environments. It simply needs to extend that thought process to the mobile handset.
What we need is a flexible and secure way to offer an open environment for developers. Quite frankly mobile phones are mini PCs and in my opinion should have the flexibility of a PC OS. Google should enable the following within their app ecosystem:
- Access to basic phone applications
- Such as Caller list, VoiceMail, Messaging
- Phonebook, Browser etc
- Access to native functions
- GPS, Accelerometer, Camera, Configurable buttons Menu schemes etc
- Robust Security model
- Using trusted certificates
- User authorizations (kinda like Facebook)
Yes most smartphones come close to the aforementioned list. However Google needs to go beyond by giving 3rd party apps equal status as it own applications. That is when we will have the exact PC model on the handset.
Security will be a huge portion of this framework. Google will have to build it in from the ground up. Only trusted, tested providers should be allowed access to the device capabilities. If the phone is built on a Unix based OS, it will be easy to extend its security model.
Revenue Enablement
I don’t have to describe why this aspect of the GPhone ecosystem is critical. Today almost all mobile OS providers cover their costs from the actual device price itself. Google’s approach will be different in order to enable an ongoing revenue model.
This model will be extended to the 3rd party services as well. As we all expect Google will and should leverage their ad network within the mobile environment. The GPhone shall support AdSense (or a variation) within the mobile framework itself. Current Mobile ad platforms leverage SMS, MMS or WAP browsers. Google will take the ad framework deeper.
In my opinion Google should enable a device resident AdSense proxy. This ad framework shall be able to access any part of the phone UI and serve ads whenever needed. This framework will be open to Google and app builders alike. They will be able to call “context sensitive” ads wherever in their app flow.
Such a framework enables subsidization of services for the end consumer. Theoretically they could drive the cost down to zero and recover revenue from ads only. I mentioned this in a post from August. Depending upon Google’s agreements with the carrier’s, they can configure the phone to serve ads wherever needed.
This environment will also enable mobile application developers to monetize their work without charging users monthly fees. Frankly no one likes paying those monthly fees for applications they use few times in a month.
So, this concludes my three part series on the Gphone. Now remember these are just my views and opinions about how to build it. I am sure Andy Rubin has his own ideas and will hit it out of the park. Read a great story on him from NYT.
I am eagerly waiting for the announcement next week. Please do send in your thoughts and opinions.
Add New Comment
Viewing 10 Comments
Thanks. Your comment is awaiting approval by a moderator.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Add New Comment
Trackbacks
(Trackback URL)
November 5, 2007 at 3:05 am
[...] Application Ecosystem and Revenue Enablement (live now) [...]
November 5, 2007 at 2:43 pm
[...] Revenue Enablement I don’t have to describe why this aspect of the GPhone ecosystem is critical. Today almost ...
November 7, 2007 at 10:56 am
[...] is no mention of revenue enablement capabilities. One would think that Google will probably enable some sort of local ...