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, RIM, Sun (with Java), the Symbian Foundation, Adobe, 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).

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 (e.g.: 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 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:

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 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-source 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 performance 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 reliability. 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 (e.g.: 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.