Reminds me a lot of MS's strategy of adding incompatible features to existing standards.
Reminds me a lot of MS's strategy of adding incompatible features to existing standards.
Embrace & Extend is a well known, very destructive mechanism for subverting standards.
Enhancing existing standards with experimental extensions is a well known very useful mechanism for improving widely used standards.
As with anything to do with technology you need to look at the details to determine exactly what is happening on a case-by-case basis.
Just saying "that sounds like MS" isn't useful without examining the details. For example, many of Microsoft's extensions to HTML were very useful (eg, XMLHTTPRequest), whereas others weren't. It's a case-by-case thing, and asserting this is always bad is a very shallow interpretation.
TL;DR: Details matter. Experimenting by extending standards isn't always bad.
If you ignore IBM's and Sun's massive FUD campaigns against OOXML, and actually compare the specs, you'll find that OOXML is not anywhere near as bad as they claimed, and in many ways is better than ODF. ODF does have nicer markup--I'd much rather read or write by hand an ODF file. On the other hand, ODF is incomplete in major areas, and other areas are imprecise. (Sun and IBM actually tried to use this as a point in their FUD campaign, slamming OOXML for having too much detail).
Weirdly, Microsoft seem to have incompatibly forked their own OOXML format and are in no rush to fix that now that they've seen off the competitive threat posed by ISO standardisation of a competing format.
It wasn't because they were nice or had the consumer's best interest at heart. They just wanted PCs to be faster, because they had a monopoly that sat atop PCs. So they benefit when PCs get faster, get replaced and stay ahead of would-be competitors.
And I truly hope I can be as sloppy as Microsoft and build a software that reaches only 95% market share.
You need to remember that before you were born "stuff happened".
That happened later once the usefulness of XmlHttpRequest was noted and other browsers added it directly to their JS support before it was formally specified.
So this is exactly the way to extend (by using clean extension points) that Google was using with SPDY. This is different than, say, implementing a <marquee>-Tag directly into the HTML renderer which doesn't provide a nice extension point.
Google wants the whole web experience to be faster. They don't benefit in locking you in. I imagine Apache/Nginx/etc will all have SPDY support in due time (while still defaulting to HTTP or a hybrid setup) and it will be yet another nice enhancement to the web experience.