Image Credit

Or why Chrome OS is a missed opportunity

The internet wires have been glowing after Google’s recent Chrome OS announcement. Not much is known about the yet-to-be-released operating system, apart from it being Linux-based, quick booting, and likely to use a modified version of the Chrome browser as its user interface. People are assuming, quite logically, that if the interface is a web browser, the principle aim of Chrome OS is to encourage the use of web applications in place of installed software.

In this post we’ll argue that pushing people towards web applications (with a web-only OS) is an inferior strategy to pulling them in with new and more innovative products. We’ll also argue that the principle drivers for creating better web apps can only come from inside the browser rather than outside. In other words, we’ll argue that Chrome OS represents a missed opportunity.

Some Background Info
If you already know the width of an address bus is not measured in inches, you can probably skip this section, which goes over some basic concepts relating to operating systems.

In the most abstract sense, an operating system just manages a computer’s resources. It allows IO devices such as keyboards, disks and modems to interface with the system. It schedules software to run on the CPU, and it can control which resources are accessible by which programs. The core functionality of operating systems hasn’t evolved much in the 50 odd years they’ve been in existence. They’ve become better – more robust and flexible – but they basically do the same things they have always done.

Most of the obvious innovation has been with user interfaces, which offer a (generally graphics-based) way of interacting with the underlying OS. It’s important to point out that an operating system and its associated UI are distinct components. Some operating systems, such as Microsoft Windows, bundle the core OS and the UI into one package, whereas others, such as Linux, allow different user interfaces to be run on top of a separate OS. This is what Google apparently aims to do with Chrome OS: use the Chrome browser as a graphical interface on top of the core Linux OS.

Why is all this relevant? Well, it becomes very relevant when you start thinking about platforms. Whereas the notions of an OS and a UI are pretty clear, the definition of a platform is much more vague. Depending on the context, an application’s platform can be the operating system, the user interface, or, crucially, a higher-level concept which sits on top of the first two.

Web Applications – Where is the platform?
For web apps, the browser is the platform, not the operating system or user interface. This is the underlying reason why the browser concept has been such a success. The same web page can be viewed by different makes of browser, each running on different operating systems and different hardware. The browser ‘abstracts away’ the differences between how individual systems operate – and presents a common platform upon which web sites and web applications can be built.

So, from the standpoint of innovating web applications, there is not much point in designing an operating system around the browser, because any enhancements will be specific to that platform. It could be argued that if the enhancements were truly useful, they might find their way into other OS/browser combinations – but this is an unlikely scenario, not least because Chrome OS will be one of very few platforms where the browser acts as the front-end to an operating system. Just about everywhere else, the browser is just another installed application, and has no special relationship with the underlying OS.

Innovation comes from Inside the Browser
Improvements in browser technology come from a number of sources. There are the various working parties which suggest improvements to the core technologies used by all browsers (HTML, Javascript, XML, CSS, etc). Then there are the browser makers, who sometimes unilaterally add functionality which is sometimes adopted by the other browsers (innerHTML) - and finally there are the application and framework developers, who create their own scripts which can occasionally become so widely used they get absorbed into the browser itself (JSON parsing, getElementsByClassName).

Out of these three routes, the last one has a key difference. The scripting route to innovation is unique in that it exposes new functionality which is generally available to all browsers immediately. Working party recommendations refer to future implementations - that’s not to say these suggestions are not useful or highly transformative – but it takes time for the browser makers to gradually absorb the suggestions (and not all of them do). A similar situation occurs with unilateral improvements to browsers: until there is widespread cross-browser support, the new functionality is generally not used in large-scale deployments.

The scripting route represents a democratic way of improving browser technology. The most useful functionality rises to the top and is then frequently implemented natively in the browser core.

Pull vs Push
Google has led the way on many fronts in web development, with much of the innovation coming via the scripting route: Gmail demonstrated that it was possible to create a useful browser-based application without using constant page refreshes. And Google Maps blew developers away when it showed what could be achieved by cleverly using Javascript in conjunction with background server calls. These examples helped convince users and developers alike that it would be possible to create truly complex web applications in the future. In other words, they pulled people towards this nascent technology with the promise of functional richness and platform-independent availability. Chrome OS will have no such impact, it pushes people towards the web without actually making the web any better.

It’s ironic that in the blog post announcing Chrome OS, Google actually included the phrase ‘operating systems that browsers run on were designed in an era where there was no web‘. Going back to the previous point that operating systems haven’t really evolved in 50 years, they could have actually said that such systems were designed in an era where there wasn’t much of anything.

We must that remember that the first computer users – IBM’s original customers – were big businesses, governments and research institutions. They used their machines to crunch numbers and query databases full of statistics. This is the era in which operating systems were born, and in which they have basically remained. Software was very specific, and if information had to be shared between programs, a group of dedicated programmers would work out a common file format that would suit both producer and consumer.

Our world is very different. Whilst number crunching applications still exist, both enterprises and individuals are now using their computers principally for communicating and sharing information which has obvious human meaning. The web has made this so much easier, but operating systems still view the world in terms of processes, files and IO streams. Even if a user knows that you can’t put a ‘person’ into a folder containing ‘places’, the operating system doesn’t – it’s just data - a given program may know the difference, but in a truly interoperable world, it’s desirable to have such concepts distinguishable at the platform – not just application – level.

The Fat Lady’s Still in the Limo
If Google really wanted to expand the market for web applications, they would pull users towards that market with enhanced functionality and interoperability, not just providing them with with a free OS, designed for cheap computers, which just gets them rapidly online.

Take mashups - a ugly term to describe a very simple ‘technology’. Some people may find it remarkable that a web page can be divided into various regions which are then populated with information from disparate sources. One can only assume that such people would have gone into fibrillation in the late sixties/early seventies when the cinematic fashion was to divide the screen into sections each showing separate images.

That’s not innovation. Innovation is dragging a user from your Twitter stream (regardless of the client you’re using) and dropping the icon into the address field of a new email, or into a friends folder in Facebook. Innovation is having exactly ONE lists of contacts, which you use for work, friends and family. Innovation is being able to share this list with any application in a structured and selective manner. Innovation is making all of your information available to all of your software tools, within a common semantic framework: no you really can’t drop ‘Bob’ into the ‘my favorite cities’ folder (regardless of what application you’re currently using).

Missed Opportunity
The fact that operating systems deal in primitives which do not fully reflect how we now use computers is really not an issue. The browser is the new the platform, not the OS - and this just means there is not much point trying to add web-focused functionality to a layer that is simply abstracted away by the browser. Google may have other reasons for creating Chrome OS, but improving the web application environment can’t be one of them - or, if it is, it won’t go very far.

Google had (and still has) great scope for pulling people further towards web applications by providing a platform-wide framework for interoperability. So far the web has been great at displaying information – but it’s still pretty poor at allowing users to structure and share information in a generic, selective, and (an at least rudimentary) semantic manner.

We are faced with a great opportunity. Whilst the whole web application ecosystem is still in a pretty primordial state, there’s a window to lay down a well-designed and robust layer of open interoperability. As time passes, this window will gradually close, as various interested parties each create their own schemas, each incompatible with each other, as per the usual script.

If Google really wanted some serious progress in web applications, they should consider creating a general-purpose client-side framework for the interchange of structured and semantically distinguishable information. This is what people need, this is what people want. And if things go well, and such a platform were to gain general acceptance, it might eventually be absorbed into the very fabric of the browser – to the benefit of us all.

Now that would be real innovation.