Dreaming Of Beetles

Update: Mike Pinkerton, Mac Chrome developer, is writing some interesting tidbits on his blog.

Without being involved with Google or Chromium in any way, these are just stabs in the dark. I would love to hear from those in the know about what is going on.

As I see it, there are three fundamental reasons for the delay:

1) Priorities
Google knows the fastest way to gain market share is to bundle the browser at the OEM stage with the dominant operating system. To do this, they need a compelling case for why the browser should be bundled. This led to several things:

• An extremely aggressive development cycle (I’m not on the dev channel, but know that they are pushing weekly builds).
• One of the fastest Google products to pass through beta (OEM’s are somewhat reluctant to pre-load beta software).

This raises the advertising questions:

So can’t Google just use it’s advertising space to drive adoption?
Yes, but it generally doesn’t work. Chrome made a brief showing on the Google frontpage, breaking the rule of 28 but we know this doesn’t drive much traffic. Visitors to Google are usually looking to search for something, not download a new browser. Evidence of this can be see in ReadWriteWeb’s analysis of the traffic the HTC G1 phone got from a Google link.

Also, you do see adsense ads for Chrome (instead of Firefox) popping up around IE or Firefox related articles. But I don’t think these are driving too much traffic.

2) Technology
I’m sure Chrome is packed chock full o’ technology that I don’t bring up here, but this should be a start:

WinHTTP
With the preview release of Chrome 2.0, we saw Google dump WinHTTP in favor of its own codebase. This is great and all, but leads me to believe that the original codebase was developed in a quick and dirty style in 20% time with MS tools. More on this can be read in this thread where people have combed the codebase and saw how dirty it is.

Sandboxing
This is another area where MS rears its ugly head. According to Nicolas Sylvain, Chrome developer:

The Mac and Linux version of Google Chrome are still in development. They are not ready yet.

We haven’t decided the implementation details of the sandbox on these platforms, but we clearly want something equivalent.

October 2, 2008 3:48 PM

This was in a comment made on this blog post titled “A new approach to browser security: the Google Chrome Sandbox“. It seems this is one of the main bottlenecks.

V8
I thought V8 was the culprit for the longest time until I saw this article – “Building and compiling V8 on Mac OS X“.

3) Look and Feel
These is a third and rather weak argument for the delay. Back to the “Platforms and Priorities” post, Amanda Walker, Software Engineer tells us:

One overriding goal we have had from the start has been to build the best browser we can. When it comes to Mac and Linux versions, this means that our goal is not to just “port” a Windows application to these other platforms–rather, our goal is to deliver Chromium’s innovative, Google-style user interface without rough edges on any of them.

Yes, making Chrome feel native to the Mac is important, but does that take six months? I’m not buying it.

image: Google

Popularity: unranked [?]