Chrome OS is Google’s latest entry into the consumer space. It is designed to be an operating system that runs on customized hardware and provides the user with only a state-of-the art browser running HTML-5 and some plugins. The tech (and mainstream) media has seen no shortage of opinions about its meaning and future impact on the industry. Unfortunately, I think most people have missed some of the key implications of Chrome OS.
[As a disclosure, I am a former Google employee, having worked there from 2002 to 2008, but I don’t have any inside information on this project. In fact I didn’t even know of its existence before I left.]
Google has two main aims with this project:
- To use the Google brand and buzz about its “game-changing OS” to push for new and better web apps using nascent technology. This lets Google reduce its customers’ dependence on local apps it does not control.
- Once a lot of these apps are deployed and become heavily used, the mass market will force owners of closed systems like the iPhone to implement support for HTML-5, the latest version of HTML, and rich web interfaces. Coupled with net neutrality (which Google currently strongly supporting) this will allow Google to circumvent uncooperative devices and network providers, and access consumers currently hidden behind locked system.
Here is a more detailed analysis:
People are switching to netbooks in droves. Ever since the advent of AJAX and Web 2.0, a great number of things that people used to do using local apps are being done by web-based applications. This transformation is by no means complete; it is clear that many interfaces are not refined and much critical functionality is absent, but the trend is undeniable.
Modern operating systems have very rich interfaces that give application developers and users a great deal of power. This is great in some ways — it lets you write awesome local applications, and offers great performance. However, as Spiderman’s Uncle Ben said, “With great power comes great responsibility.” A rich interface provides ample opportunities for unforeseen consequences, bugs, viruses and other bad things.
As power and performance becomes less important (computers are getting faster, and word processing isn’t getting any more CPU intensive), it is becoming more difficult to justify all the extra responsibility. Although hardware and user-facing software has changed incredibly over the past three decades, operating systems are remarkably stagnant — virtual memory really hasn’t changed much in 15 years, and from the user’s perspective, file systems haven’t changed much since the days of UNIX, in the 1970s.
People these days mostly use their computers for a few key things: Internet browsing, dealing with email, writing documents, writing spreadsheets, playing music, watching video, and editing photos. As increasing numbers of people join the online world (especially in developing countries), users need to stay as happy with their Internet-related experiences. More happy users lead to more searches and more advertising revenue.
Google needs to ensure that the web and everything people use to access the web stays as open as possible. If closed ecosystems dominated by unfriendly companies, such as Apple (and its iPhone), and Microsoft (with Windows desktop and mobile) gain power, Google won’t have unfettered access to the end-user. To do challenge them, Google needs to reduce switching costs and make users indifferent about which computing devices they use by commodifying them. The Chrome OS plan is to entice users to move as much data as possible into the “cloud”, making the data and apps transparently follow the user onto whatever device he or she happens to be using.
Google realizes that if this momentum towards cloud-based computing stalls, it will be in a difficult position — it will depend on others for its access to customers. So success of Chrome OS is not really about whether a lot of people use Chrome OS!
Instead, success (or failure) will be measured by the creation of new and better web apps using HTML-5 and HTML-5-related technology. This will allow Google to reduce dependence on local apps it does not and cannot control. (By the way, HTML-5 is the latest version of HTML, and will allow web sites to add offline storage — the ability to store data in your browser for use when disconnected from the internet — better video playback and graphics support, along with interaction between different documents.)
Let me repeat this: Success is not about whether a lot of people use Chrome OS. It’s about whether a lot of people end up using Web applications. This is a simple conclusion, really, but very profound. Even if everyone ends up using some other OS, as long as all the apps they use are web-based, Google wins, because its products can compete on a level playing field. Instead of building special applications that run on your OS and store files through proprietary methods, a web application will run on any device, making them the same from the consumer’s perspective. Critically, enhancements proposed in HTML-5 will allow them to run offline as well as online. (In fact, Chrome OS, being open source, will probably be forked into a less proprietary system distributed by any number of parties. Even if this hurts the user base of Google Chrome, Google wins.)
Obstacles facing Chrome OS:
One of the largest looming issues for Chrome OS is the planned lack of local file system support. For various reasons (some copyright-related) most people store their music and movies locally on their hard drives. Removing local filesystems will reduce the difficulty of using the system but will pose huge problems for movies, photos, and music. Unless a decent web-based solution for this problem is invented soon, Chrome OS’ usefulness might be limited. The dearth of good photo editing solutions online is really no different than the poor quality of web applications — they will need to improve.
Moving down this path implies the users’ data will almost completely be stored primarily in the cloud. Having all their data concentrated in one location might give users pause: What if the service is unavailable when the data are needed? What if the service goes out of business or is hacked? These perceptions will need to be handled effectively.
What about Android?
Android, Google’s operating system for mobile phones, is going to be BIG. Google desperately needs to prevent the iPhone from building increasing global market dominance in its current form. Android already provides a better hardware abstraction layer, better testing, limited interfaces, better security and includes a full-fledged browser. It satisfies pretty much all of the requirements set out by the public docs of Chrome OS, and already includes support for local applications. In two years, there will be an even larger group of Android apps available. Looking at why Google wants to create a new OS and not simply co-opt (or even fork) Android provides the most convincing evidence of my hypothesis yet — that Google is more concerned about the proliferation of web apps than the wide adoption of Chrome OS.
Here are motivations people have raised for separating Chrome OS and Android:
- Too many uses of Android will slow development on the OS internally. This may have a little bit of truth, but I think it’s not a good reason. Linux survives multiple changes to the source code from all kinds of people doing all kinds of different things with it, and it doesn’t slow down development that much. This is certainly true now that Linux is stable, but is probably true of its earlier, less solid stages too.
- People use touch-screen devices differently than keyboard-and-mouse-only devices. This may be true, but what evidence is there that touch-screens won’t be on most netbooks within two years? If one wants to build a browser-based device, one should keep in mind that a touch screen is far more useful than a mouse.
- Android isn’t ready for use on desktops. It’s too hard to get to work on different processors. This is a weaker argument — a lot of people have already ported Android to Atom processors, and there doesn’t seem to be much trouble getting it to run.
- Adding a very different hardware platform will make UI and app design too hard. This is a pretty good argument. Supporting widely disparate hardware is not going to be trivial for app developers — the wide distribution in Android version and hardware configurations is already causing some angst. There’s no need to insist that all applications run on an Android notebook.
- Android is for things with small screens you can make calls on. Chrome OS is for other things. Also a decent argument. In the next few years, Google Voice, Skype, and pervasive Internet will mean that phone and video calls will certainly be made from notebooks. Besides, any optimization you would make to Chrome OS to speed up browsing could easily be made to the Android codebase. Most of Android’s codebase is not designed to deal with calls, but with enhanced security, easy application development, and maximization of battery life — all things that Chrome OS will need.
While Google would really love to have a large user base, even a Chrome OS with few users will not be a failure. The number of installs is secondary to the number of web-based applications that it fosters. Google will do everything in its power to make this happen. This includes building better web apps and cloud-based storage tools itself, and using its brand to scare other companies into building apps (for fear of missing out when Chrome OS gets big).
If Google promoted Android instead of Chrome OS, this strategy would not work; developers would simply focus on building Android apps. Android apps would help Google’s phones and make Android netbooks work nicely, but would not help Google penetrate other established and closed ecosystems. Getting the same apps to work across platforms is the key to success because it allows hardware commodification and easy migration paths between the systems.
And this is why Google is building Chrome OS.
Vijay Pandurangan worked for Google for six years, designing and implementing some of the core systems infrastructure for the company as well as parts of the ads system. He now runs a consulting firm called Olima Ventures and is an angel investor. You can read his blog here and follow him on Twitter here.
Mobile developer or publisher? VentureBeat is studying mobile marketing automation.
Fill out our 5-minute survey
, and we'll share the data with you.