Yesterday, I wrote
about the war -- more like the Armageddon -- that's on the verge of
eruption in the mobile space. Given how critical third party software
developers are to the strategic success of any platform ecosystem, we
can fully expect Apple,Google (NSDQ: GOOG), RIM (NSDQ: RIMM), Sun (with Java), the Symbian Foundation, Adobe (NSDQ: ADBE)
and others to fight tooth and nail for every mobile developer on the
planet. More than one will succeed. But not all. Or, might it not
matter? The answer could very much depend on how exactly Google plays
its cards with Android, Chrome, and Gears. Consider this.
For those of you who are deeply familiar with Android, Chrome, and
Gears, here's the punchline so you won't have to read any further: By
offering mobile developers an alternative way for making their mobile
applications run on handsets, even when no wireless connection exists,
Google is paving the way for developers to build browser-based
applications that can run on any mobile platform as opposed to having
to build separate versions of their applications in order to support
those same mobile platforms.
Simply put, software developers want access to volume markets. Given
the fragmentation in the mobile platform market, it's not as easy as it
was in the original desktop days to pick one platform that can get you
access to the majority of the market's volume.
For mobile developers to reach the entire market, they have to think
"cross-platform" and, unfortunately, the only cross-platform play in
the mobile market is the Web browser. It's the only "platform" that, in
one form or another, is available on all of today's smartphones (as
well as many other handsets). Why do I say "unfortunately?" Because the
Web experience is only as good as the weakest link which, in the case
of mobiles, is pretty darn weak: the network. If the network is either
slow or unavailable to your handset, the Web experience is not even an
experience. It's wholly unreliable.
Mobile developers are painfully aware of the situation. As a result,
if they want their software to experience any sort of success in the
mobile market, their only choice for reliability's sake is to write
their applications in such a way that they can be downloaded, stored,
and run locally on the handsets themselves, outside of the Web browser.
These non-browser based applications must be developed specifically for
the various mobile applications and in many cases, specific to certain
handsets. From a developer's point of view, having to maintain multiple
versions of the same application is a nightmare, and you simply can't
support everything. Choices have to be made (and the various mobile
platform makers will bend over backwards to make sure you choose them).
In the 1-2-3 combination of Android, Chrome, and Gears, Google
appears to be sending a message to developers: it's time to end the
nightmare.
Android, as most know, is the open source handset operating system
that Google is launching into the market. Expectations are that the
first Android handset -- HTC's Dream -- will ship later this month.
T-Mobile is the network operator (take that AT&T (NYSE: T)).
Chrome is the name of Google's recently announced Web browser. It's
only available for Windows but the word is that it will be available
for other operating systems including Mac, Linux and, of course,
Android.
Gears is another one of Google's open source technologies that, for
the Web applications that support it, makes a Web browser think it has
a connection to the Web, even when it doesn't (like, on an airplane).
Without a connection to the Internet, most Web-based applications (eg:
Web-based e-mail) stop working because they can't exchange data and
instructions with a Web server. The number of Web apps that support
Gears is slowly ticking up. Because of its open source nature, neither
the browser nor the Web application has to be Google-based. Zoho is
just one example of a competitor to Google (in the Web-based office
suite market) that uses Gears so that Zoho customers can access Zoho
applications, even when they can't connect to Zoho's Web servers.
Earlier this week, MySpace announced at the TechCrunch50 conference that it would offer its members offline access using Google's Gears.
Since the offline problem is one of the key arguments against switching from locally installed software like Microsoft (NSDQ: MSFT)
Office to Web-based competitors like Google Apps, Gears has been widely
discussed as the game-changing technology that could ameliorate the key
disadvantage of using Web apps. In the context of desktop and notebook
PCs, the combination of browsers, browser-based applications and a
technology like Gears is a very credible threat to franchises like
Microsoft's Windows and Office and is very often discussed as such. For
example, under the headline of "Chrome: Google's Windows Killer", PC World's Steve Bass recently wrote:
This is a direct attack on Microsoft -- and I think
Microsoft is worried. That's because a small kernel on your local
system could boot you into directly into Chrome, or a server-based
operating system, and you could start working sans Windows.
Notwithstanding Office on the Mac, sans Windows also means sans Microsoft Office.
But, the existence alone of a potentially game-changing technology
like Gears usually isn't enough to change the game. Gears is not an
application like Office or Google Apps that people see in a user
experience. It's infrastructural in nature. When Gears is in use, it
runs quietly behind the scenes or in what many refer to as "the
fabric." Unfortunately, it's not in the fabric by default. And it's not
like visiting an Adobe Flash-based application or a Java-based
application where end-users who don't have the necessary "fabric" on
their devices are prompted with an in-your-face dialog that says "Hey!
You need Flash to do this. Click here to download and install it."
Unlike with Flash and Java, Gears isn't needed to blanketly to run
the Web applications that support it [sic]. It's only needed to run
those applications in a certain mode (the offline mode) that, for some
of the applications like Google Reader that support Gears, doesn't get
invoked unless the user explicitly invokes it as shown below:
Even worse (in terms of getting a technology like Gears into the
fabric), the option to invoke the Gears-driven offline mode of a Web
application like Google Reader isn't even available as an option unless
Gears is locally installed (as seen in the bottom part of the above
graphic). The net net is that Gears isn't the easiest technology to
ubiquitously deploy into the fabric of the Web.
Enter Chrome (and its open source nature).
Most people missed it. But originally, the download for Google's Chrome browser was associated with Gears on Google's Web site.
Today, to get the functionality of Gears in one of the main three
browsers (Internet Explorer, FireFox, or Safari), it must be added-on
separately by the end-user. With Chrome, it won't be an add on. It will
be a foundational element of the browser.
Last week, I juxtaposed the comments
from the executives at Google and Mozilla to show that, when it came to
browser fundamentals, Google and Mozilla were not seeing eye-to-eye on
something (or probably multiple things). My guess is that Google sees
an offline technology like Gears as being so fundamental to the future
of Web applications, that it can't not be built into the browser. The
folks at Mozilla (where Gears is an add-on t the browser), on the other
hand, probably didn't see it that way.
I'm speculating here, but, from Google's point-of-view, if it gets
built into the various browsers, making Gears a part of the Web's
fabric the way HTML renderers or Javascript engines are a part of the
fabric is no longer a problem. That's one reason Google open-sourced
it: to encourage unencumbered adoption. It's one of the main reasons
that any vendor would open-sources anything. From the Mozilla
Foundation's point of view (in my opinion), building a vendor-provided
technology like Gears into FireFox (as opposed to requiring the add-on
approach) sets a precedent that the Foundation must be careful about
setting. If Gears, then why not Flash? Or Java?
There are probably technical reasons it makes more sense for Gears
to be a foundational element of the browser rather than an add-on. My
guess is that it offers more stability and reliability, particularly in
a partitioned environment where, like in Chrome, tabs are actually
separate instances of the browser.
So, what does any of this have to do with mobile developers. If
there's one environment that's super duper sensitive to both the
presence and peformance of the network, that environment, as stated
earlier is the mobile Web browser. Going back to Google founder Larry
Page's statements about Chrome, he mentioned the need for speed. In a
mobile environment, a technology like Gears is really just a cache and,
in the technology world, caches are more commonly associated with
performance than they are with the off-line mode of a browser.
Technically speaking, there's no reason a technology like Gears can't
be seamlessly working in the background all the time so that a mobile
browser can fetch the next thing it needs from that cache instead from
the slow and/or non-present network.
Let' say the two biggest reasons mobile developers are choosing to
build locally stored and executed applications instead of mobile
browser-based applications are speed and performance. Now let's say
both of those challenges can be addressed by the presence of a standard
caching technology like Gears in the majority of the mobile browsers
found in many of the future's handsets. As a developer looking to
access as much of the market as possible with a single code-base, your
first choice would have to be to develop for the browser first. Not
only does this give you access to the broadest part of the mobile
market, it gives that same application access to the desktop/notebook
market too (where the fabric is really no different).
One counter-argument to this is that there is a software development
kit for Android much the same way there's one for the other mobile
operating systems and that its presence encouraqes developers to go the
platform-specific route rather than the Web route. But in the big
picture, Google has no interest in limiting the availability of its
cloud to Android handsets. Google wins much bigger so long as end-users
perceive mobile Web apps to be fast and reliable and, by way of mobile
browsers, more users have fast and reliable access to Google's Web
apps.
One of the best ways to create that perception (and reality) is to
get more mobile developers building for the Web instead of any specific
platform. It's a win for developers looking to reach the broader
market. It's a win for end-users who shouldn't be forced into picking a
specific platform or network (eg: iPhone/AT&T) just to get access
to certain applications. It's a win for Google. Who is it not good for?
You don't have to look far.
