3 ms·

I'm starting to think that maybe you don't really understand what the embrace, extend, extinguish (hereafter EEE) strategy is. The whole purpose is to intention

I'm starting to think that maybe you don't really understand what the embrace, extend, extinguish (hereafter EEE) strategy is. The whole purpose is to intentionally provide something that others can hook into such that it's unfavorable for competitors not to adapt to what you're providing. The pedantic distinction you're making—that, in order for it to be an extension it has to be embedded into the original spec and that add-ons don't count—just doesn't hold water either: one of the most prominent cases of EEE was Microsoft's development of ActiveX done allegedly done specifically to break compatibility with the plugin system already in place by Netscape et al. But more directly, modern browser add-ons aren't EEE because they aren't billed as a spec and no one add-on implementation has become the de-facto standard. Firefox, Chrome, and to a lesser extent Safari all have add-on implementations that are relatively competitive with each other. Features implemented as part of an EEE strategy are always billed as "just a feature". But they have real consequences to a competitive marketplace. This is why the loss of Google Reader is so impactful: companies like Feedly—who is still just working on a Google Reader API-compatible implementation of sync and other Reader features—now have only a few months to fill the void that everyone in the space took for granted for years.

magicalist 14y ago
You'll have to be more specific for how you would define "embrace, extend, and extinguish", then, because it's difficult to parse from your comments anything more than that a feature has to have consequences in a market place for it to fit the "embrace, extend, extinguish" mold (it also doesn't help that the author also offered nothing to back up the comparison other than the fact that NewsGator no longer offers a feed reader). ActiveX is actually a pretty bad example, as it was outside of web standards and only has impact because of the close ties to the OS and the advantage Microsoft therefore got there. It is therefore a pretty good example of some of Microsoft's lower level anticompetitive acts, but it's a poor example of "embrace, extend, and extinguish" (even if only for the fact that NPAPI was itself essentially being made up as Netscape went along at the time). No, the canonical examples of the phrase, coming from US v Microsoft itself, refers to Microsoft's attempts to make Sun and Netscape irrelevant when it came to Java and the web, respectively. The plan was to embrace the standards of each, bringing support in as core OS features, and then literally extending the standards with new APIs, tags, etc to add features that developers would want. This would put pressure on those companies that in time they might not be able to keep up with (or they would spend all their time reimplementing Microsoft's features and lose their images as the trailblazers) because the formerly-standardized content they used to be able to consume with their programs would become unreadable and/or unrunnable without the extensions. What's worse, Microsoft often designed APIs that were closely aligned with Windows APIs, specifically to make it easy to implement there, and difficult to implement efficiently elsewhere. In other words, they broke the standards in a way that if you didn't implement the extensions, you couldn't consume the content that was supposedly compliant with that standard. You aren't adding a feature that users want and so other clients need to compete, you're adding features to the content standard so that other clients cannot function without them, and you're doing it while pretending loudly that your extension is just part of the standard. So, no, a service that makes the client better and that users soon demand does not fit the bill (and, again, we're talking about an API specifically existing for making it easier to interoperate on those features). Yes, it had a market impact in that many users wanted support in any feed reader, and, now going away, there will be a loss of functionality if someone doesn't reimplement it. That's often the way with features. But it's a poor analog for the actions of monopolists past.

magicalist 14y ago

You'll have to be more specific for how you would define "embrace, extend, and extinguish", then, because it's difficult to parse from your comments anything more than that a feature has to have consequences in a market place for it to fit the "embrace, extend, extinguish" mold (it also doesn't help that the author also offered nothing to back up the comparison other than the fact that NewsGator no longer offers a feed reader). ActiveX is actually a pretty bad example, as it was outside of web standards and only has impact because of the close ties to the OS and the advantage Microsoft therefore got there. It is therefore a pretty good example of some of Microsoft's lower level anticompetitive acts, but it's a poor example of "embrace, extend, and extinguish" (even if only for the fact that NPAPI was itself essentially being made up as Netscape went along at the time). No, the canonical examples of the phrase, coming from US v Microsoft itself, refers to Microsoft's attempts to make Sun and Netscape irrelevant when it came to Java and the web, respectively. The plan was to embrace the standards of each, bringing support in as core OS features, and then literally extending the standards with new APIs, tags, etc to add features that developers would want. This would put pressure on those companies that in time they might not be able to keep up with (or they would spend all their time reimplementing Microsoft's features and lose their images as the trailblazers) because the formerly-standardized content they used to be able to consume with their programs would become unreadable and/or unrunnable without the extensions. What's worse, Microsoft often designed APIs that were closely aligned with Windows APIs, specifically to make it easy to implement there, and difficult to implement efficiently elsewhere. In other words, they broke the standards in a way that if you didn't implement the extensions, you couldn't consume the content that was supposedly compliant with that standard. You aren't adding a feature that users want and so other clients need to compete, you're adding features to the content standard so that other clients cannot function without them, and you're doing it while pretending loudly that your extension is just part of the standard. So, no, a service that makes the client better and that users soon demand does not fit the bill (and, again, we're talking about an API specifically existing for making it easier to interoperate on those features). Yes, it had a market impact in that many users wanted support in any feed reader, and, now going away, there will be a loss of functionality if someone doesn't reimplement it. That's often the way with features. But it's a poor analog for the actions of monopolists past.