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.

Tuesday, January 4, 2011

Android, "Fragmentation", how it will always be the developer's burden, and how it can be resolved.

I recently stumbled upon a link to a ZDNet article in my email around Android fragmentation.

It's always interesting to see how the talk-back section reacts to things like this.  And the article in general isn't terribly forgiving toward this perceived problem.

Though I question the amount of credibility given to Rovio as an authority on how fragmented the Android eco-system is, I suppose they have the most vocal feedback from the end-users out there because of the volume of units they've sold.  However, it should be noted that the development and distribution of one application does not make them an expert.  Without insight into their code's quality or their ability to anticipate conflicts when targeting multiple platforms, it's hard to say if the problem is with Android itself, or their development approach.
(Update 1/7/2010 - A bit of proof that Rovio is not infallible in their platform ports. Seems their recent Mac port neglected to lock up their application against piracy via Apple's documented procedure.) 

All in all, the article is a good summarization of the concerns.  However, if you ask Google's Andy Rubin, he will say it's "differentiation", not fragmentation.  This is further solidified by today's announcement of Honeycomb, and how it's requirements differ to pander to the strengths of tablets.


Why doesn't Google just handle this??
To truly answer this question, you have to ask.. Where in Android's distribution does Google benefit the most?  Since they make it available for free, there's no licensing income from the operating system itself (though some proprietary applications such as the Marketplace and Maps applications are rumored to be available to OEMs on the base install for a small royalty).

Simply put, Google benefits less from the operating system itself more than the services that are consumed on it. So, from their point of view, it's easy to hide behind how "open" the operating system is, and do whatever they can to encourage manufacturers to embrace the platform so they can distribute their services.  Even if it means touting the ability of the manufacturer to put their own thumb-print on it at perhaps the expense of compatibility of applications not written by Google.

And since Google's proprietary Android apps are very transactional and "business-like" in nature around Google's web-based services, the likelihood of incompatibility for these base-line compatible applications is very slim.

I hate to say they're sort of hanging us out to dry... but...  Hey.. it's free.  You can ask for your money back. 

Some might suggest that Google should lock down the ability to customize the OS.  However, this contradicts the very nature of it's "openness", and creates some issues around how it's licensed. Simply put, the license in place allows for customization at just about every level.  

For arguments sake, lets say they could do so without creating these issues (such as changing the license agreement).  Enforcement isn't something that a company can do for free.  Follow up for compliance and certification can eat into the budget of an OS that's technically not making any money, and certainly not scoring any revenue for chasing down consistency.  And furthermore, it's a legal management nightmare for OEMs to juggle what parts of the system are modifiable and what parts aren't.  At that point, the return on investment starts to decline, and an OEM might decide to go another way (such as licensing Windows Phone 7 or Symbian).  Also, closing the source in certain areas invites the temptation of software patents.  And speaking of patents, Apple and Microsoft have already sued a few handset manufacturers over violations within Android software.  Google certainly doesn't want to be named as a defendant if they're forcing an OEM into an actionable position due to some arbitrary compliance rule. 


Android is like Silverlight
Before you get riled up, I'm not comparing it to Silverlight in terms of capability or even drawing parallels to measures of success.

However, I am talking about how it's marketed.  Lately, Silverlight is the prefix buzzword to a bunch of differing development platforms at Microsoft.  You have Silverlight for Windows, Silverlight for Mac, Silverlight for Windows Phone 7, Silverlight for Symbian, Silverlight for Embedded, Silverlight the Flame thrower, Silverlight the T-Shirt, Silverlight the Toilet paper.. etc., etc. etc.  Merchandising! Merchandising!

While these products all bear the name Silverlight, and all have the same goal of being an application platform for various devices, each and every one of them are not 100% compatible with the other.

Google has taken this same approach with Android, but for a different reason.  Whereas Microsoft's "fragmentation" of Silverlight is often due to hardware differences or where they wish to invest their resources, Google's approach is to make the platform compelling to OEMs by allowing them to modify it enough to "differentiate" (there's that word again) themselves from other manufacturer's products.  Though it appears that Honeycomb will also introduce the hardware reasoning as well.

Managing Fragmentation Differentiation (TEST TEST TEST)
First of all, repeat after me...  Android is a marketing term and a baseline specification.  It's not the device itself.  And once the OS has been tweaked, it's not even pure Android anymore, but rather a slight mutation of it.  Barnes and Noble's Nook Color is a good example of a device that differentiates itself without relying on the Android brand for marketing and creating confusion.  Under the plastic, it's powered by Android Eclair, but the marketing materials surrounding it downplay that fact quite bit.

The baseline Android OS merely implies that the porting effort for applications is probably going to be less across the various "Android powered" devices.  In other words, unless you're making very simple apps (i.e. not graphically/input  intensive like games), it's going to be a roll of the dice if it works on every device.  The sooner you accept that, the happier you will be.  You need to think of each manufacturers device, despite the fact it's "Android powered", to be as different as HTML5 is across various browsers (in other words, a common API with varying degrees of compatible behavior).  You may get lucky and the application may work without any modification.  But if you don't expect that, you will be happier when it does.

Unless you have tested on any particular handset, you can't be certain that it works.

Currently, the Android marketplace gives no filter by particular device, so unless a developer has expressly said so, you have to consider an app on any particular device is "use at your own risk" in terms of it's functionality on any untested device.  Unfortunately for those that wish to monetize applications outside of in-application advertisement (i.e. charge for it), this isn't a very appealing model.  To fairly service your customer in this scenario, you must provide a trial version with the appropriate disclaimer that it may or may not work on that customer's device and they should use the trial as a litmus test to see if it works.

If you're a bigger company with some money to burn, there are various services out there that will let you test your application on various devices.  Perfecto mobile is an example.  Not endorsing or have even used this service to offer any real opinion of it, but it's an example of how one can test a number of devices without physically owning any of them.

Not a big company?  Then you need to network.  Due to the "open" nature of the Android community, there are plenty of people out there with various handsets who might be willing to try your trial application and evaluate it for you.  Surprisingly, many end users (especially those excited about your product) will happily provide free beta testing for you just for the privilege of seeing it run "behind closed doors" and having exclusive access to it.  Worried about having your code out in the wild?  Network locally.  Between myself, family and co-workers, I have access to  about a half dozen different Android handsets.  Assuming they would trust installing an app I have written on their phone, I would be able to see it run on a physical handset for free (or the cost of lunch).  Local Android user/developer groups might also be an avenue of access to disparate hardware.

And lastly, snoop around a bit.  Along with the standard emulator that comes with the Android SDK from Google. The Android Virtual Devices (AVDs) specific to certain devices are sometimes published. (For example, here's where you can get the Nook Color AVD and the Samsung Galaxy tablet AVD.)

So what COULD be done..
Ok, so Google isn't terribly invested in the success of your application. Not because they hate you, or because they are evil. They are just following their philosophy and guiding principles.  (which incidentally says nothing about ensuring your application runs on Android nor even admits being a software company, but DOES say they make money off of advertising and providing information services)  And if they have published such principles, you can hardly blame them for doing something they've not promised to do.

However, as at least one discussion participant at ZDNet pointed out, Google will likely get the blame for the "differentiation".  And articles such as this obviously won't help the cause.  Perception is everything. And this is something that Google's basement computer geek mentality has a hard time comprehending.  It doesn't matter if you're actually not to blame if everyone thinks you are.  "Free" goes both ways in this case.  Allowing a brand you own to be the forefront of marketing on mobile devices in the way Windows is on PCs tends to make the consumers expect a similar consistent experience.  The price of that freedom could very well be Google's reputation on how it chooses to handle (or not handle) the mess.

So what should they do?  Obviously the phones that have their proprietary applications on them got there through a relationship with the OEM.  In those situations, Google should encourage the OEMs to make official Android Virtual Devices and make them available and easy to find for the development community so applications can be tested.  Perhaps even making this a requirement in order to use the Android name in the marketing would be a good way to handle it.  Odds are, the OEMs have these virtual devices available to their internal engineers anyway. This would level the playing field for those that can't afford the testing services, and would give a very feasible way for the development community to manage the "differentiation" between devices.  And if Google won't step up to do it, the development community should.  Email campaigns work wonders if done in significant numbers and if the emails find their way into the inbox of the right entity.

Another thing Google could do is discourage and minimize deep modification by abstracting the areas that the OEMs like to change the most. OEMs would appreciate this because it would require them to do less modification to make their handset/tablet look different.  Letting them just modify the surface areas of the OS  would bode well for application compatibility across devices.

Google has done a rotten job at properly conveying it's vision for Android properly.  To be fair, they've never said it was going to be a consistent experience like Windows, iOS or OSX across devices.  But also to be fair, they haven't went out of their way to say it isn't, and have been coasting on that false perception to build it's success.  Android is actually closer to the Linux roots it's based upon.  And like other Linux distros, common roots do not guarantee compatibility.