It's apparently browser engine day today. After Mozilla and Samsung announcing Servo, Google has just announced it's forking WebKit into Blink. Like WebKit, Blink will be open source, and it will also be used by other browser makers - most prominently, Opera has already announced it's not using WebKit, but Blink. Update:Courtesy of MacRumors, this graph illustrates how just how much Google contributed to WebKit. Much more than I thought. Also, Chrome developer Alex Russell: "To make a better platform faster, you must be able to iterate faster. Steps away from that are steps away from a better platform. Today's WebKit defeats that imperative in ways large and small. It's not anybody's fault, but it does need to change. And changing it will allow us to iterate faster, working through the annealing process that takes a good idea from drawing board to API to refined feature."

In addition to making the web platform faster and more secure, improving the web platform also means adding new capabilities and features. To fulfill our good citizenship mission, we need to be careful to add new features to the web platform in a transparent, responsible, and compatible manner. We measure success as moving the open web platform forward as a whole, not just as moving one implementation forward.

In practice, we strive to ensure that the features we ship by default have open standards. As we work on features, we track their progress in the web standards community with the Chromium Features Dashboard, which lets us be transparent about the status of each feature and about how we make decisions about which features to enable by default for the open web.

Compatibility risk is one of the most important decision criteria for enabling new web platform features by default.

Factors that decrease compatibility risk (in rough order of magnitude):

Other vendors shipping compatible implementations
A mature specification in the relevant standards body
Positive signals from other browser vendors
Small API footprint

In practice, the following tiers are good rules of thumb to know that the feature is on the right track (ordered by increasing risk to compatibility and therefore decreasing order of desirability):

Two other browser engines already ship roughly interoperable implementations in stable or experimental channels. In this situation, the feature is already a de facto standard. If a de jure standard does not yet exist, we should help create one.
One other browser engine ships a roughly interoperable implementation in a stable or experimental channel, we believe the feature to be stable, and we’ve consulted with the appropriate standards body.
The appropriate standards body considers the feature ready for implementation. For example, the W3C issuing a Call for Implementations or publishing a Candidate Recommendation of the feature would meet this guideline.
The specification for the feature has been accepted by the appropriate standards working group (e.g., a First Public Working Draft in the W3C) and we’ve received positive feedback from other browser engines about the feature’s feasibility and value.
We hope to work with other browser vendors to develop a common approach to shipping experimental features. For example, Mozilla has already embarked on a similar policy. As part of this process, we may revise our approach as we gain more experience with it or to align with other browser vendors.