Monday, January 31, 2011

What killed Google's love for the web app?

Recently, I ran across a ZD Net article (gosh they provide me with a lot of fodder to base my blogs on) about how Google has decided to invest heavily in client-side binary applications rather than web applications.

This has baffled a lot of people given that Google has been a long time and rabid supporter of HTML5 as the future of application development.  Heck, Google and Apple's commitment to it was enough to make Microsoft drink the kool-aid and switch their strategy on Silverlight.

So the biggest question is:  Why?  With Chrome OS (the so-called "Cloud-based OS", which I still believe is just a very fancy way of saying "Rich content capable dumb terminal") just around the corner and being highly dependent on "web applications", the timing seems odd that Google would switch strategy.

So what happened?  I suspect a few things...

Chrome OS has been met with relatively luke-warm reception.  Not much has been said about it since the very short "marketing" campaign around the pilot program, which resulted in review of the hardware that hosted it rather than the operating system itself.  Perhaps the windless sails on this project is making it hard to live in Android's shadow, especially since the tablet targeting Honeycomb is gathering very positive feedback from the press and geeks alike.  Tablets are basically becoming the net book successor, which is a market that has arguably been dying the past year or so anyway.

Second.. there has been a change of command at Google.  This could very be well be one of the first strategy moves of Larry Page.  From my understanding, there has been a bit of pressure in the ranks of Google to move strategies forward at a far more rapid rate than they have.  And with HTML5 being designed by a committee of competing agendas, it's gotta be difficult to patiently wait for specifications to be approved and instituted as official standards.  At least within the Android/Dalvik eco-system, Google can move quickly to add features and keep the experience relatively consistent across platforms.  Ironically, it's the strategy that Microsoft was originally trying to employ with Silverlight, and why "plug-ins" like Silverlight and Flash have a distinct advantage over HTML5 in terms of the speed of trajectory for upgrade and maintenance.

HTML5 support on portable devices is also pretty sketchy at the moment to target as the most cross-platform viable solution out there.  Especially since its cross-platform capabilities are highly exaggerated.  Many critics of Android complain about it's fragmentation while touting HTML5 as some baseline consistent standard.  And unfortunately, this is simply not true in the real world.  As of this writing, HTML5 is still mired in writing workaround code for unsupported features, code branching for platform and browser specific implementations, as well as hosting different versions of the same content to ensure compatibility across browsers (it seems a standard is only as consistent as it's interpretations).  So the part of the software development cycle of testing applications on the desired target platforms still does not go away even with HTML5, which puts it on par with native application development from that aspect.

And finally and most importantly, it's all about the ability to monetize.  This is something that HTML5 is also currently very weak at providing.  As of now, it is difficult to protect offline content and intellectual property within HTML5 and Javascript. The "always online" utopia simply doesn't exist yet, and because users will still want to play games on an airplane where an internet connection is not allowed (or expensive), or in places where you can't get a good signal from a cellphone tower, there is a market for traditional downloadable retail for these types of applications.  In short, if a developer wants a good shot at making an offline application, actually charging for it, and actually making money on it, it's probably not going developed with HTML5.

To further support the monetization, one has to look at the concept of the app store as a possible motivation for this decision.  All of these stores, no matter where they reside (be it at Google, Microsoft, Apple or even Barnes and Noble or Intel), are profit centers for their respective companies.  All seem to operate on the 70/30 split. Google's app store claims the 30% is distributed amongst the carriers and payment processors (and since Google processes the payment, that would be them).  Google also charges developers a registration fee of $25 to develop.  With rumors of big players such as Sony entering into the Android eco-system with their Zeus phone, it makes sense to invest in a monetization path that the built-in user base of a product like that are already accustomed to (such as the Playstation Network). 

You can't very easily sell an HTML5 application in an App store because of the lack of asset protection, (or in the case of a cloud/server-dependent application, there really is no app to sell more than access control to a website).  HTML5 also provides no real conduit for exclusivity, whereas the Apple store, Google store and Microsoft stores can cater focus to the platforms they own or have a stake in.

So as with everything, it ultimately comes down to control, capability, and how to make money off of the technology available.  Google has that today with it's Android development story, so it makes a lot of sense for them to move their strategy in that direction.

1 comment:

  1. Really meaningful information about this applications and you are a great reviewer, I will definitely try this applications. Thanks a lot for spreading this information here.