4 ms·

Where does the extend come in? Not that I ever used reader but the article doesn't seem to mention any extensions to RSS other than a thing called "bundles" whi

Where does the extend come in? Not that I ever used reader but the article doesn't seem to mention any extensions to RSS other than a thing called "bundles" which I have never heard of. Did reader have a lot of specific extensions that make it hard to build a competing product?

itafroma 14y ago
Google Reader has a number of features that are above and beyond simple RSS/Atom parsing: * Starring * Sharing amongst other Google Reader users * Smart sorting of feed items * Marking as read * Indefinite retention on feed items Most of these, by themselves, are not hard to replicate (maybe the sorting is, indefinite historical archive definitely is if you haven't already started), but all these "extensions" to RSS/Atom parsing, so to speak, were exposed via an (albeit undocumented) API that spawned a whole ecosystem of feed readers that rely on it, because a major selling point for the past several years has been "syncs with Google Reader".
- magicalist 14y ago
  None of those are extensions of RSS, they're just features of the reader. By your criteria, any reader that doesn't just display the unparsed xml is "extending" RSS. The key to the "extend" step is that it has to be done in a way that disadvantages others by breaking interoperation when they used to be able to. Not only did RSS (and Atom) feeds continue to work across all feed reader clients, but you can also export many of the features you list in a straightforward and unobfuscated format (and via API, as you note).
  - itafroma 14y ago
    The Google Reader API providing those features is the extend of embrace, extend, extinguish, not merely the features isolated away from the feed parsing (which is I why I put "extensions" in scare quotes). Feed readers, due to market demand, have coded to the API—which provides features above and beyond what you can get from simple feed parsing and are only available from Google—instead of the otherwise-interoperable RSS, Atom, and OPML specs. So while yes, potential competitors could replicate those features (just like Netscape could—and often did—replicate IE-specific extensions to HTML and CSS with their own versions), it can't be done in a competitive manner. As a user, if all my feeds, activity, friends, and retention are within Google's infrastructure, there's no point in switching to another solution that provides all those things—or worse, merely sticks to the simple standard of OPML—unless I'm forced to (just like very few people coded to Netscape's implementation because most were using IE). That's the essence of embrace, extend, and extinguish: adopt a simple standard (RSS, Atom, and OPML), extend it beyond that spec in a way competitors weren't and the specs don't support (the API that adds starring, retention, etc. to the mix of simple feed parsing), then watch as competitors who don't adapt to your new "standard" fail (if you were developing a feed reader and didn't support Google Reader's API, good luck with that).
    - magicalist 14y ago
      First, it's rather ridiculous to assert that an API provided specifically, albeit unofficially, to allow syncing of the state of features with other feed reader programs somehow disadvantages those other readers. It was a service that existed, and other feed readers used it. Feedly has plans to provide a similar API, and it will likely be available to many feed readers because most of the work is done in creating it, not reading from it. They aren't trying to crush the market through a non-standardized service, they're just fulfilling a need. Besides, Reader API support itself is still just a feature. You would need something like interleaving non-standard entities into RSS feeds for an equivalent to "extend". That is the kind of thing that the phrase refers to, as it fundamentally breaks what is supposed to be a standard that all parties can code against. RSS has continued to work fine. If what you were saying were true, then, for instance, browser add-ons would be anti-web. Differentials in javascript engine performance would be anti-web. Different locations for the forward and back buttons would be anti-web. The closest analog in the browser would be browser sync. It's already becoming a feature that users look for, as it is quite convenient to have your browser history and bookmarks on your phone and computer synced. Soon it will likely be essentially required for a browser to have a sync system if they want to survive in the browser market. So far all of the browsers sync systems are non-interoperable. Are they all using this feature as an effort to extend the standards of the web in a way that disadvantages the other browsers in the hopes of stomping out the competition? No, and in fact, browser UI behavior is explicitly not standardized to allow that kind of differentiation. The important part is that they can consume and display the web correctly, so that it remains available to all, which leaves them plenty of room to compete on features.
      - itafroma 14y ago
        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.

itafroma 14y ago

Google Reader has a number of features that are above and beyond simple RSS/Atom parsing: * Starring * Sharing amongst other Google Reader users * Smart sorting of feed items * Marking as read * Indefinite retention on feed items Most of these, by themselves, are not hard to replicate (maybe the sorting is, indefinite historical archive definitely is if you haven't already started), but all these "extensions" to RSS/Atom parsing, so to speak, were exposed via an (albeit undocumented) API that spawned a whole ecosystem of feed readers that rely on it, because a major selling point for the past several years has been "syncs with Google Reader".

magicalist 14y ago
None of those are extensions of RSS, they're just features of the reader. By your criteria, any reader that doesn't just display the unparsed xml is "extending" RSS. The key to the "extend" step is that it has to be done in a way that disadvantages others by breaking interoperation when they used to be able to. Not only did RSS (and Atom) feeds continue to work across all feed reader clients, but you can also export many of the features you list in a straightforward and unobfuscated format (and via API, as you note).
- itafroma 14y ago
  The Google Reader API providing those features is the extend of embrace, extend, extinguish, not merely the features isolated away from the feed parsing (which is I why I put "extensions" in scare quotes). Feed readers, due to market demand, have coded to the API—which provides features above and beyond what you can get from simple feed parsing and are only available from Google—instead of the otherwise-interoperable RSS, Atom, and OPML specs. So while yes, potential competitors could replicate those features (just like Netscape could—and often did—replicate IE-specific extensions to HTML and CSS with their own versions), it can't be done in a competitive manner. As a user, if all my feeds, activity, friends, and retention are within Google's infrastructure, there's no point in switching to another solution that provides all those things—or worse, merely sticks to the simple standard of OPML—unless I'm forced to (just like very few people coded to Netscape's implementation because most were using IE). That's the essence of embrace, extend, and extinguish: adopt a simple standard (RSS, Atom, and OPML), extend it beyond that spec in a way competitors weren't and the specs don't support (the API that adds starring, retention, etc. to the mix of simple feed parsing), then watch as competitors who don't adapt to your new "standard" fail (if you were developing a feed reader and didn't support Google Reader's API, good luck with that).
  - magicalist 14y ago
    First, it's rather ridiculous to assert that an API provided specifically, albeit unofficially, to allow syncing of the state of features with other feed reader programs somehow disadvantages those other readers. It was a service that existed, and other feed readers used it. Feedly has plans to provide a similar API, and it will likely be available to many feed readers because most of the work is done in creating it, not reading from it. They aren't trying to crush the market through a non-standardized service, they're just fulfilling a need. Besides, Reader API support itself is still just a feature. You would need something like interleaving non-standard entities into RSS feeds for an equivalent to "extend". That is the kind of thing that the phrase refers to, as it fundamentally breaks what is supposed to be a standard that all parties can code against. RSS has continued to work fine. If what you were saying were true, then, for instance, browser add-ons would be anti-web. Differentials in javascript engine performance would be anti-web. Different locations for the forward and back buttons would be anti-web. The closest analog in the browser would be browser sync. It's already becoming a feature that users look for, as it is quite convenient to have your browser history and bookmarks on your phone and computer synced. Soon it will likely be essentially required for a browser to have a sync system if they want to survive in the browser market. So far all of the browsers sync systems are non-interoperable. Are they all using this feature as an effort to extend the standards of the web in a way that disadvantages the other browsers in the hopes of stomping out the competition? No, and in fact, browser UI behavior is explicitly not standardized to allow that kind of differentiation. The important part is that they can consume and display the web correctly, so that it remains available to all, which leaves them plenty of room to compete on features.
    - itafroma 14y ago
      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.