The Little Technology That Will

For road warriors among us, the promise of an untethered world is a mixed blessing. While some foresee huge productivity improvements from being always connected, for most of us, the very notion probably conjures up scenes of entrapment inside noisy commuter trains with everybody’s cell phones and pagers going off.

And, as one former itinerant consultant confided to us, isolation can be a blessing. There is a reason why libraries are supposed to be quiet, and, he noted, a reason why the isolation of cross-country flights can provide the most productive hours of consulting projects. Nonetheless, the unexpected success of Blackberries indicates pent-up demand for at least some mobile connectivity.

Consequently, we expect WiFi to become “the next little thing” for wireless. Cheap and simple, costing less than $500 apiece for local transmitters, almost anybody can set up a WiFi hot spot.

In that context, we were amused in reading accounts of a wireless forum at Comdex this week. The carrier and technology establishment is being caught off guard by this guerilla technology, just as phone carriers were when dial-up Internet flooded local switches a few years back.

Among key hurdles are billing and network handoffs, because mobile broadband — whether WiFi or 3G — will involve multiple carriers. While the problem has continued to dog even terrestrial carriers, that hasn’t shut down long distance service. Other objections were raised that WiFi won’t adequately cover the landscape. However, Qualcomm’s notion that 3G will make WiFi obsolete was pretty laughable, given the company’s track record supplying the proprietary technologies that have rendered U.S. cell phones useless in the rest of the world.

WiFi is the little technology that will. Although security questions remain, they will get solved years before 3G networks ever reach critical mass. With Intel about to embed WiFi into its P4 mobile chips next year, the installed base will quickly mushroom.

We expect that hotels could prove the tipping point, since WiFi is cheaper and quicker than extending T1 lines to every room, a captive market exists (road warriors have to sleep somewhere), and there is an existing billing mechanism. Furthermore, the environment is conducive but not ubiquitous (road warriors leave their rooms every morning). Our main concern, however, is that those poor souls won’t lose too much sleep in the process.

GUI’s Only Skin Deep

The Java community just likes to argue and argue. While Microsoft’s .NET framework rolls on with a largely coherent technology base, the Java folks crave religious debates over standards, arguing the merits of issues that occasionally border on the sublime. We’ve previously noted that the Java community has tended to over-standardize.

Chafing under Sun’s control over the Java standards process, IBM formed Eclipse roughly a year ago. The goal was generating a new open source framework enabling tools to plug and play. Rubbing things in, IBM based the framework on a set of GUI controls (the things that developers use to paint screen features) differing from what the official Java Community Process had previously blessed.

Eventually Borland, more recently followed by Oracle, joined Eclipse under the notion that it’s safer to sleep with the enemy than fight from the outside. Both joined to prod the group to adopt the Java Community’s “Swing” controls. Our prognostication? Fat chance.

But then again, how important is the whole debate? If standardizing GUI controls was really that strategic, why doesn’t IBM or Sun just fold their cards here and get on with life?

In reality, the whole issue is a non-starter. Like SQL databases before it, J2EE technology might be standard, but the appservers on which the technology is deployed require highly specific skillsets. Just as IT shops are more likely to rip out servers before messing with their databases, we believe the same is true for appservers. And, not surprisingly, the tools used for developing applications for J2EE appservers are becoming very appserver-specific: the Eclipse-based tools and IBM WebSphere, Borland JBuilder and BEA WebLogic, Forte (now Sun ONE) and iPlanet (now also Sun ONE), Oracle JDeveloper and Oracle 9i Appserver. So if each development tool has different GUI controls, who cares?

We agree with Sun’s Jeff Anders, who maintains that the real problem is how to make Enterprise Java Beans easier to build, deploy, and maintain. Indeed, Microsoft is facing the same challenges in getting its developer base to cross the chasm to .NET. To paraphrase MasterCard, some things are worth standardizing, but simplifying application development? Priceless.