Tim Anderson

The intention of Google Gears, now in beta, is to provide a standard mechanism by which web applications can be used offline. Until now, the ability to work offline has been the preserve of desktop applications, but the monopoly no longer holds. You will be able to board a train, pull out your laptop, and work with Google email, documents and spreadsheets. When you next connect, code running on Gears will synchronise your changes back to the internet.

Gears is significant even for those who rarely work offline. It is an insurance against connection failure, reducing the risk of unproductive time. In addition, it gives web developers a few more tricks they can use for optimisation, including a fast local SQL database engine. In conjunction with Ajax, Gears raises the bar for web applications.

Will Gears succeed? I think it will, provided that Google can address several critical areas. The first is to provide compelling Gears-enabled applications. This will drive adoption. Deployment will take off when the various components of what you might call Google Office are available.

Second, the product needs to improve. On first impressions the initial beta is an elegant solution to a difficult problem, and the embedded database is excellent, but by Google’s standards, it is a rough beta, and installation failures are common.

Third, Google has to convince the industry that Gears is more than just an attempt to hook us to its platform.

In fairness, there is currently nothing specific to Google in Gears, other than the URL for installation. You can run a Gears application that does not talk to Google’s servers, and the code is there for all to download. Yet it is disappointing to find that Gears installation requires agreeing to allow Google to install software on your machine without further consent.
Indeed, if you install Gears on Windows, you will find a new auto-run service called GoogleUpdate.exe, running under the powerful local system account. No big deal, provided that you trust Google, though I prefer to approve any updates before they are installed.

This issue of trust is critically important. At best, Google’s rich browser applications are an exit route from vendor lock-in; at worst, the industry is sleepwalking from one big vendor dependency towards another. I am inclined to the former view, but onerous and unnecessary licence agreements raise doubts.