Google Chrome? pure strategy. Google’s business model is dangerously dependent on the browser, and the browser is 80% controlled by a competitor known to play hard. Said competitor could have dealt a fatal blow to many Google services by crippling the browser’s JavaScript in the name of security (read: kill XSS that is so critical to deliver Google’s services). It’s natural for Google to looked for alternatives and bypass the danger. One was the Flash API. Chrome is another one. For now it is used to influence developments at other browsers, but it is also an insurance policy that gives Google a foothold in the market in case things start fragmenting and we go back to the AOL/Compuserve era of incompatibilities and mutual exclusions.

I’m not entirely sure what you were saying about technical vs. non-technical decisions, but I think that it’s hard to classify decisions as one or the other. For instance, each candidate for GNOME DVCS was probably good enough technically, but Git was chosen for sound non-technical reasons.

http://sayspy.blogspot.com/2009/03/why-python-is-switching-to-mercurial.html

“Probably because it’s the vcs they used first”

Correction: probably because it’s the vcs they used second, and because they knew better than to ever consider the first for anything ever again. :-D

Next, correcting a few comments:

#2: “The reason khtml was chosen for webkit _was_technical. I was faster, had smaller memory footprint, and the code was cleaner. I think the last point was actually the most important.
Also Gecko was tied a lot to Firefox, and Xulrunner was not in a very good condition at that time.”

This last sentence is flat-out wrong. When khtml was chosen for webkit, as best as I recall (I wasn’t involved in Mozilla in those days), Firefox was either Phoenix or Firebird or m/b or some other extremely nascent project, but it *definitely* was not Firefox. XULRunner didn’t even exist as an idea then, either; it’s a fairly new idea that grew out of the success of Firefox and Thunderbird, as best as I recall.

“Google want to have the browser to behave like an application. Things like selecting multiple files for upload, copy/paste (between windows in the browser and native applications)”

I think it’s incredibly naive to think that multiple-file upload wouldn’t have come to browsers if Google hadn’t moved (not least because, to the best of my knowledge, Chrome supports none of these right now!). I’m not familiar with that part of HTML5 or with its history, but I would wager good money the web forms spec included multi-upload from its earliest days, and with three of the four big browser names behind it Google’s assistance would have been entirely superfluous if it were aimed at that end. Copy/paste works right now outside of bespin/canvas-like solutions, and those weren’t on anyone’s radar, even Google’s, a few months back. I don’t know the history of webcams or geolocation in browsers, but I don’t think the web needed Google involvement in browsers to drive either (although, to be honest, I don’t remember anything on webcams except for a camera: proposal that was on Planet Mozilla several months back that hasn’t progressed very far beyond there).

#8: “Admittedly, chrome’s v8 in the webkit and google’s javascript tests did own webkit & gecko pretty good.”

Depends how you choose your benchmarks, TraceMonkey beat v8 (and then-Squirrelfish) on SunSpider when it was released. It did not beat v8 on the v8 benchmarks; draw your own conclusions from that.

The true history, as far as I can tell Apple started the JS perf wars with the SunSpider benchmark and their optimizations to the engine predating Squirrelfish; Mozilla responded with the engine in Firefox 3 that beat that, Apple responded with Squirrelfish that beat that, Mozilla continued it with TraceMonkey that beat that, Google burst in with v8 that beat that on some benchmarks but not others, Apple updated Squirrelfish to Squirrelfish Extreme that again won on some things but not others, at some point Microsoft decided to focus on what improvements they could wring from JScript for IE8 to not look abysmal, and now everyone’s churning away from where they are now. Oh, and you can bet your bottom dollar IE9 will include a JavaScript (sorry, “JScript”) JIT.

#9: “If MS and Mozilla get ticked off at Google for some reason they could essentially destroy Google.”

I’m skeptical. MS has legal entanglements that will make it very very difficult for them to consider any such things, let alone carry them out. Mozilla to a good extent depends on goodwill for its spread and increasing market share, not to mention the revenue situation according to the published financial reports. That said, I can understand preparing for the worst, so I can’t really fault them on this case if it figured in their considerations — but it still seems a pretty weak case for devoting, say, a couple dozen people full-time to the undertaking.

#13: “After getting their asses kicked by V8, Microsoft and Mozilla started focusing on fast Javascript engines.”

Bull. Mozilla had been saying for awhile that they were going to vastly speed up their JS engine, and TraceMonkey beating v8 on SunSpider when the latter was announced is hardly “getting their asses kicked”. There certainly was no “[starting to] focus” on JS performance in Mozilla that v8 precipitated.

Gnome 3.0
http://live.gnome.org/ScratchPad

I must say I am still running F9, as the current just works, and the new features where not important to me.

I think it is much better to have the technical side sorted out now, rather than later, even if it means the end user thinks nothing is happening in each release.

The M$ model is ship bugged software, get markedshare, fix the most annoying bugs.

The Linux model have always been, get it right from the start, and I think that is what Gnome is doing right now.