How OpenSpan Could Support the Google Chrome OS (and Linux in General)

Last week I mentioned that I would follow-up my original post on the Google Chrome OS with a post on how OpenSpan could support the Google Chrome OS (and Linux in general). I emphasize could, because we currently have no plans to support the Google Chrome OS or Linux. Thus, this post is really just informed speculation on how our technology could be applied to Linux.

Diagram 1
Diagram 2
Diagram 3Typically, when we talk about OpenSpan, we focus on our Windows translator, Scout, as the base layer which everything builds upon. In fact, we often say "OpenSpan sits in between the application and Windows". We then talk about how we use the Scout layer to detect when additional technologies are loaded into an application so we can load translators to expose those technologies. For example, to explain how we support Java, we might whiteboard something like Diagram 1.

However, Diagram 1 isn't really correct. There's actually another layer below Windows, the instrumentation layer, responsible for hooking x86-64 byte code. Of course, once you're dealing with byte code, you're dealing with the processor, not the OS. Thus, our hooking library can hook functions on both Windows and Linux systems. When we add the instrumentation layer, our Java stack looks like Diagram 2.

So what would it look like if we added Linux to the mix? You might think that adding Linux would mean two different stacks, one on top of Windows, another on top Linux. However, this isn't the case. For technologies that run on both Windows and Linux, the stacks would actually reconverge at that layer. Diagram 3 shows what our Java stack looks like with Linux.

Of course, there's only a few UI frameworks that work on both Windows and Linux (see list here), most importantly Java and HTML. Unfortunately, HTML is a markup language rather than a binary specification so we have to adapt to each browser rather than HTML itself. However, we could still create a common set of HTML element objects that interact with each browser implementation through an abstraction layer. It gets even more interesting if you start thinking about server technologies.

To summarize, above the OS layer, most multi-platform technologies will reconverge on a common set of classes. Thus, although we will need to write a Linux layer, we will not need to write a new Java layer or two separate FireFox layers. Don't get me wrong, supporting Linux would still require a significant degree of effort. However, it is a manageable amount of effort because we can build on the layers we already support.

Google Chrome OS

Today, Google announced on their blog that they are working on a OS based on their Chrome browser and Linux. The blogosphere has been expecting this announcement for a couple of years now. It's been pretty obvious that Google was positioning itself to compete against all of Microsoft's core products, adding first Google Apps to compete with Office and then Google Chrome to compete against Internet Explorer. A Google OS is the final piece, taking on Windows.

I find it amusing the excitement that a Google OS generates. It seems to speak more to a dislike of Microsoft than to an excitement about Google. After all, if Google is successful, it will be in a more dominant position than Microsoft ever was, controlling the operating system, productivity applications, email and search (which effectively controls the Internet). That doesn't sound like a particularly desirable outcome. We all know monopolies tend to stagnate. After all, it took FireFox to drive Microsoft to improve Internet Explorer, Java to drive Microsoft to scrap COM and now Google Apps to drive Microsoft to update Office. I would hate to see Google replace Microsoft as another monopoly.

On the other hand, operating systems are a bit of a special case. Having a single dominant operating system leads to innovation at the next layer. OpenSpan only has to develop for Windows currently, which lowers our costs and allows us to focus more effectively. Standards are supposed to alleviate this problem, but standards are equally problematic. I was a web developer when Netscape and Internet Explorer both rolled out their own implementations of HTML 4.0. Having to develop cross-browser scripting code was an absolute pain in the ass. I've had similar experiences dealing with different Java server environments, each with their own little quirks. "Write once, run anywhere," usually means "Write once, debug everywhere." Moreover, standards tend to be produced slowly and are very rarely perfect. Browser and JVM creators are notorious for jumping the gun and rolling out versions that are compliant with an interim standard, but not the final standard. They are also notorious for rolling out innovations that are not compatible with other browser or JVM implementations. Developers are constantly presented with the choice of targeting the lowest common denominator and sacrificing functionality, targeting a specific implementation and sacrificing market share, or targeting multiple implementations and sacrificing time and money.

Of course, Google will argue that they will not be dominant or monopolistic, because the Chrome OS is designed to bring web applications to the desktop. Here's Google's description of the Chrome OS architecture:

"The software architecture is simple — Google Chrome running within a new windowing system on top of a Linux kernel. For application developers, the web is the platform. All web-based applications will automatically work and new applications can be written using your favorite web technologies."

Google's statement reminds me of the Palm webOS (on the Pre), which allows you to build softphone apps that use web technologies. These local apps are built with HTML and javascript, but they still rely on webOS services to interact with the local system. Is this how the Google Chrome OS will work? Or will the Chrome OS only allow users to interact with applications in the cloud, ie. no local storage, etc.? Most likely, the Chrome OS will do both, and some applications will be compatible with Windows, Mac and Linux and some will not.

If Google wants to demonstrate a commitment to open standards, it could roll out a Chrome OS virtualization layer to run applications on Windows. This would actually be a pretty smart strategy, extending the reach of the OS while deflecting potential criticism. Likewise, to gain widespread adoption, providing a Windows virtualization layer to run Windows applications on the Chrome OS will be required. Ultimately, virtualization may make much of this mute, particularly if we move from machine virtualization to OS virtualization (thus eliminating the need for OS licenses). It will also be interesting to see if Google open sources the entire Chrome OS. The Chrome browser is mostly open source (as Chromium), although Google does add some small functionality (mainly branding) on top of the open source implementation.

The most fascinating aspect of this will be Microsoft's eventual response if Google is successful. Right now, Google's search revenue funds free applications like Google Apps, Chrome and the Chrome OS. Google is going to need to make money off of these eventually, as I'm guessing most people don't want advertising on their desktop. In the meantime, however, being free is a really big competitive advantage for Google. Will Microsoft eventually be forced to make Windows free as well? Will Microsoft have to move more aggressively to a cloud model to compete? Whatever happens, Google has succeeded in making the desktop market interesting for the first time in a long time, and it hasn't even released anything yet.

Today or tomorrow I'll follow up this post with some thoughts on how the changing OS market impacts OpenSpan and provide some insights on how our architecture is already positioned for the post-Windows world.