6 ms·

I'm one tinfoil hat away from believing this isn't just about discontinuing unprofitable products, but a concerted effort to kill off support for open standards

I'm one tinfoil hat away from believing this isn't just about discontinuing unprofitable products, but a concerted effort to kill off support for open standards (RSS, CalDAV, what's next?) and turning the Google universe into a Facebook/Apple style walled garden called Google+. Evil plan or not, the days of Google as the champion of the open web are over.

kirushik 14y ago
Obviously, the next step is XMPP federation protocol support crippling in GTalk: https://www.fsf.org/blogs/sysadmin/google-backslides-on-federated-instant-messaging-on-purpose https://www.fsf.org/blogs/sysadmin/google-backslides-on-fede...
est 14y ago
At such pace, Google will take out Google Takeout.
MatthewPhillips 14y ago
That ship sailed a long time ago. I see it as when they gave up on Friend Connect / OpenSocial as when they sort of gave up on the idea of open-first, and instead started focusing it competing feature-for-feature. Mozilla is the champion of the open web these days. Google started their proprietary NaCl and Dart projects because they claimed you couldn't make JavaScript any faster than it currently is. And now Mozilla is embarrassing them with emscripten and asm.js.
- derefr 14y ago
  You know, I keep seeing this "proprietary NaCl" statement around, and having played with it myself, I have a bit of a soapbox. There's nothing proprietary about NaCl: all the specs are open, and Google actively wants Mozilla and others to support them. To be charitable, though, I guess what most people mean by "NaCl is not open like Javascript" is that it's low-level--compiled binaries instead of readily-accessible script. And that's true; it exposes less to the user--and although it would be perfectly possible for every NaCl module to be debuggable through the browser with embedded symbols, just like Javascript is, it hasn't happened yet. But you know, NaCl isn't for that, as far as I can tell. It's not a thing to write the business-domain logic of your web app in. It's far too clunky to develop with, if that were the intent. Instead, what NaCl seems perfectly suited as, to me, is an architecture for writing pluggable scripting-language virtual machines. In other words, to give freedom of choice to use a backend other than V8 to write your web app against. Java-in-the-browser, Ruby-in-the-browser, Erlang-in-the-browser; any of those would be possible, and just as transparent+useful as Javascript-in-the-browser (in fact, V8 itself could be lifted out to being just another NaCl module.) And since the site would deliver the "runtime" for the scripts itself[1], any compatible browser could pull it down and execute it, instead of waiting for IE, Firefox, Chrome, etc. to all adopt the new language before anyone can start using it (a Sisyphean wait.) There's already one perfect example of how this all would work: Adobe Flash. Flash is, in Chrome at least, an NaCl (PPAPI) module. Now, Flash isn't a shining example of openness--but using a custom interpreter is not where it goes wrong.[2] You can easily imagine Flash without that problem: a world where you can have <script type="text/actionscript"> and the Flash runtime will reach in and execute that code, just like the Javascript runtime reaches in and executes your JS. --- [1] This doesn't necessarily have to be true, though. The browser can come with default language runtime modules, and then the webapp can suggest a site-specific runtime module, but the browser doesn't have to take that suggestion. Which is exactly the way a thing that is considered "open" on the web works: fonts! Think of an NaCl module as being no more or less than a custom @font-face rule for the execution of a script. [2] Flash goes wrong by embedding its programs into proprietary binary asset packages [SWFs]; goes wrong again by drawing everything onto a single canvas, not allowing for anything like DOM manipulation; and then goes wrong a third time by having only one de-facto implementation with no open standard.
  - samastur 14y ago
    What do you mean by specs are open? Published fully or developed communally? Fully published is obviously better than not, but is rarely enough. Openness is not a binary choice.
    - derefr 14y ago
      Developed communally, as part of the Chromium project. Not as a vendor-neutral working group or anything of the sort yet, mind you. But there's no reason it wouldn't move to become that if any other vendor was actually interested in coordinating on it--they're not hiding their cards inside Google's walled garden or anything.
      - MatthewPhillips 14y ago
        You're incorrect, that's not how NaCl or Dart were developed. They were developed in secret years before released. They're alpha versions had all of the fundamentals established when finally presented to the public.
        derefr 14y ago
        I don't see how the way in which something is developed before its first release has any bearing on whether its current development is community-driven. Everything was designed in secret at some point: within the head of whoever was thinking about it, before they decided to start talking about it.
        MatthewPhillips 14y ago
        > I don't see how the way in which something is developed before its first release has any bearing on whether its current development is community-driven. You don't? Go look at the nacl commit logs and count how many non-Google employees are contributing. That it was developed in secret is precisely the reason for this (not because they are against outside contributors today). If you develop a supposedly open technology in secret it either needs to be 1) really good or 2) really popular. XHR is successful because it fits into both. Whatever you may feel about NaCl, Microsoft, Apple and Mozilla don't think it's good.
- lucian1900 14y ago
  NaCl (in particular PNaCl) is merely a different approach. I would call asm.js crazy, but that's just me. Something similar could be said about Dart, but there the language itself is not so interesting (merely not insane). The VM is potentially the language-independent bytecode and stdlib in a browser we've all been waiting for. While Google have been behavin evil-ly lately, in particular related to Google+, NaCl and Dart are not examples of this.
  - pcwalton 14y ago
    Why is asm.js crazy?
  - hosay123 14y ago
    Nacl is not merely a different approach, it's a wholly backwards incompatible approach based on techniques that tried and failed in the 80s (try searching for ANDF).
    - mkr-hn 14y ago
      A lot of things were tried in the past, but they fail for a variety of reasons. Some are picked up later and work because the fatal problems were addressed. I couldn't find much on ANDF. Can you be more specific about why it failed?
  - ville 14y ago
    To clarify, Dart VM is not a bytecode VM: http://www.dartlang.org/articles/why-not-bytecode/ http://www.dartlang.org/articles/why-not-bytecode/
- michaelwww 14y ago
  > Google started their proprietary ... Dart project because they claimed you couldn't make JavaScript any faster than it currently is No, they didn't. Google started Dart because they had a bunch of Java programmers who were having good success building JavaScript web apps such as Gmail with Google Web Toolkit. They thought to formalize it with Dart instead of using a hacked up Java dev environment. I have a client who needed a web app fast, so I took a chance on Dart and did it in half the time. The client doesn't even know I'm doing it in Dart. I'm shipping the minified js file which works on all modern browsers because the Dart team set out to bring jQuery up to a higher level. There's a bright side to all the dislike and misinformation about Dart though, because it gives me a competitive edge.
  - mistercow 14y ago
    >The client doesn't even know I'm doing it in Dart. I'm shipping the minified js file which works on all modern browsers because the Dart team set out to bring jQuery up to a higher level. I would feel very uncomfortable about that unless it's the sort of client that doesn't really have the tech background to assume you're writing it in JS in the first place. I think if someone is paying to have software written for them, they have a right to have some control over what language it's written in and what libraries it uses. After all, if they need to hire someone else to maintain it or add to it later on, they're going to have a far easier time finding a JS developer to do that than a Dart developer (at least for now). And, of course, you have the right to charge twice as much to do it in JS if it's going to take you twice as long.
    - michaelwww 14y ago
      I agree with you, but this client really doesn't care, only that it is done quickly and it works. They're pretty happy and are lining up more work for me. I'd say the greatest experience I had with it besides real types, code completion and intellisense, is that it ran first time on iPad (Safari, Chrome, FF), Mac and Windows FF and Chrome. I had a slight problem with IE9 and 10, but nothing too hard to fix. The client had paid someone to do it in ActionScript/Flash but the project had to be cancelled when Flash on mobile was mostly deprecated. I didn't look at the ActionScript code, but later found out there is a lib for that (haven't tried it and won't unless I have to someday) http://www.dartflash.com/ http://www.dartflash.com/
- mistercow 14y ago
  >Google started their proprietary NaCl and Dart projects because they claimed you couldn't make JavaScript any faster than it currently is I don't remember them saying that. I remember them saying that JS has insurmountable performance problems, but that's very different from saying that JS is as fast as it can get. As for asm.js, it's another approach to the same problem. An insurmountable problem for a VM usually means that there's a limit to how well the VM can reason about arbitrary code. The clever thing about asm.js is that it gets around that by just restricting the language rather than inventing a new one. The clever thing about Dart is that you would rather write in it than kill yourself. And yes, of course asm.js is meant to be written by compiling via emscripten, but that means trading far more dynamicness for speed than you would with Dart.
- acdha 14y ago
  I was with you on the first paragraph but the second goes off the rails on the second sentence. It's hard to say that Google isn't also championing the open web unless you claim that Chrome isn't a Google product - NaCL and Dart are interesting experiments but it's not like Google hasn't poured a TON of expensive, high-quality time into creating an industry-leading JavaScript engine (along with CSS, HTML5, etc. support) and put a similar amount of time into evangelism, developer outreach, etc. Even if Google cancelled Chrome tomorrow, the entire open web community would owe them a debt of gratitude for administering the coup de grace to IE's reputation as the only significant desktop browser and pushing Mozilla to heavily invest in performance and the user experience – they cared about them before but as we can see now, setting your goal as “better than IE” was still too low. There were a bunch of nice things which happened around that time – Firefox, Safari, iPhone, etc. – but the thing which really opened the desktop market moving was Chrome shipping a radically fast, user-friendly browser which you could install even on typical corporate IT-mismanaged desktops and which you never needed to think about updating. Web standards advocates had spent years preaching using standards first and fallbacks for compatibility and related ideas but the rise of Chrome seems to be what got the mainstream web developer to really internalize that idea and start coding with the assumption that the browser would improve before they revisited a site.
monkeypizza 14y ago
For years I've used gchat & status (& temporarily used buzz) as a light social network for friends, and it worked great. But now they've made it so mouseovers on the status don't work as well, and generally cramped up the design so status messages aren't as visible... could be part of the same plan.
Andrenid 14y ago
This is actually the final step for me. I've been an avid Google fan since the early days. I use all the Google services, I use Chrome religiously, I convince family/friends to switch to Chrome from IE, and I've always been convinced Google is the one we're supposed to look up to for how things should be done. Yeah they've made mistakes, and G+ is a clusterfuck of brilliant talent thrown down a horrible path of closed socialness and realname ridiculousness... but overall I always thought they were still on the right side of "Don't Be Evil". I'm totally convinced this quiet attack on RSS is a not-so-subtle attempt to push people into G+, and even though I casually use G+ (about the same as I casually use FB or Twitter), G+ is NOT a replacement for RSS, and it's not how I want to keep track of all the sites I read. I don't want to "like" them or add them to my social networks. I just want to read their shit. Simple. RSS doesn't care if you're logged in. RSS doesn't care if you use your real name. RSS doesn't care if you're accessing it from work, home, or anonymously via an internet cafe. And that's exactly how it should be. Throw in the Picasaweb crap they're doing now too, FORCING you to use G+ Photos (which is a horrible horrible experience), and I'm done. I've just installed Firefox on all my home computers and my phone, for the first time since Chrome came out, and will be looking for a new RSS aggregator.
- zanny 14y ago
  I don't get where this sentiment comes from. Ever. They are a publicly traded multi-billion dollar company. Even if they hold onto their startup-esque purism for a decade after their founding, they of course fall from grace into the profit motive pitfall because that is how the investor driven market capitalism system works. Never put blind faith in a corporate entity, because they all transition from consumer-driven-product-with-creative-vision to maximize-stockholder-returns-and-short-term-profit. It is how you do business in the big leagues. Google just had the lucky case of having a slow transition, probably due to good decisions in the early years. I get that HN has this startup culture where creative people come up with "cool things" to sell, and are product oriented rather than profit oriented (though a lot of them seem to love the idea of selling the business off to a big business like Google, walking away with the pocket change, and watching it flounder into obscurity under corporate oversight...) but big business isn't run by people who have product vision, they have profit vision, and these companies are the amalgam of hundreds of managers and overseers that don't have collective vision and can thus only drive it towards what they can all agree on - making higher returns. It happens to the best of them.
Kiro 14y ago
RSS is a broken standard so I would be happy if you were right.
- chris_j 14y ago
  What is it about RSS that is broken and what would you like to see replace it?
  - acdha 14y ago
    Atom: see http://www.intertwingly.net/wiki/pie/Rss20AndAtom10Compared http://www.intertwingly.net/wiki/pie/Rss20AndAtom10Compared for details but it basically boils down to RSS having gaps and inconsistencies which are compounded by the spec being essentially fossilized and David Winer being famously difficult to deal with.
- jms18 14y ago
  Yes, RSS 2.0 has a bunch of problems. That is why this -- http://www.ietf.org/rfc/rfc4287 http://www.ietf.org/rfc/rfc4287 -- was developed. IETF standards have a history of longevity, and I suspect this format will be around a very long time.
michaelwww 14y ago
I'm not understanding all the people saying this kills RSS. There are plenty of RSS readers out there.
- mcintyre1994 14y ago
  Agreed. If an open standard was relying entirely on a company not to 'kill' it, it was already dead as an open standard.
diegocg 14y ago
If google wanted to kill RSS they would stop supporting RSS in their products.
digikata 14y ago
I've actually been wondering if there's a pattern to these closures related to some scaling issue on the Google infrastructure. Google tends to build services tightly integrated with a common fabric. Scaling issues might cause the design of smaller services to take more than their share of resources. Consider that Reader and other small services needing event and data synchronization, were often started by independent "20%" teams, earlier on in google's infrastructure build out. So maybe services at a higher priority are needing those resources. Or maybe they're looking at upgrading the "google fabric" in an incompatible way and if you have to redesign fundamental assumptions through the code of smaller services, you might stop and take a hard look at seeing if a large rewrite is worth it.

kirushik 14y ago

Obviously, the next step is XMPP federation protocol support crippling in GTalk: https://www.fsf.org/blogs/sysadmin/google-backslides-on-federated-instant-messaging-on-purpose https://www.fsf.org/blogs/sysadmin/google-backslides-on-fede...

est 14y ago

At such pace, Google will take out Google Takeout.

MatthewPhillips 14y ago

That ship sailed a long time ago. I see it as when they gave up on Friend Connect / OpenSocial as when they sort of gave up on the idea of open-first, and instead started focusing it competing feature-for-feature. Mozilla is the champion of the open web these days. Google started their proprietary NaCl and Dart projects because they claimed you couldn't make JavaScript any faster than it currently is. And now Mozilla is embarrassing them with emscripten and asm.js.

derefr 14y ago
You know, I keep seeing this "proprietary NaCl" statement around, and having played with it myself, I have a bit of a soapbox. There's nothing proprietary about NaCl: all the specs are open, and Google actively wants Mozilla and others to support them. To be charitable, though, I guess what most people mean by "NaCl is not open like Javascript" is that it's low-level--compiled binaries instead of readily-accessible script. And that's true; it exposes less to the user--and although it would be perfectly possible for every NaCl module to be debuggable through the browser with embedded symbols, just like Javascript is, it hasn't happened yet. But you know, NaCl isn't for that, as far as I can tell. It's not a thing to write the business-domain logic of your web app in. It's far too clunky to develop with, if that were the intent. Instead, what NaCl seems perfectly suited as, to me, is an architecture for writing pluggable scripting-language virtual machines. In other words, to give freedom of choice to use a backend other than V8 to write your web app against. Java-in-the-browser, Ruby-in-the-browser, Erlang-in-the-browser; any of those would be possible, and just as transparent+useful as Javascript-in-the-browser (in fact, V8 itself could be lifted out to being just another NaCl module.) And since the site would deliver the "runtime" for the scripts itself[1], any compatible browser could pull it down and execute it, instead of waiting for IE, Firefox, Chrome, etc. to all adopt the new language before anyone can start using it (a Sisyphean wait.) There's already one perfect example of how this all would work: Adobe Flash. Flash is, in Chrome at least, an NaCl (PPAPI) module. Now, Flash isn't a shining example of openness--but using a custom interpreter is not where it goes wrong.[2] You can easily imagine Flash without that problem: a world where you can have <script type="text/actionscript"> and the Flash runtime will reach in and execute that code, just like the Javascript runtime reaches in and executes your JS. --- [1] This doesn't necessarily have to be true, though. The browser can come with default language runtime modules, and then the webapp can suggest a site-specific runtime module, but the browser doesn't have to take that suggestion. Which is exactly the way a thing that is considered "open" on the web works: fonts! Think of an NaCl module as being no more or less than a custom @font-face rule for the execution of a script. [2] Flash goes wrong by embedding its programs into proprietary binary asset packages [SWFs]; goes wrong again by drawing everything onto a single canvas, not allowing for anything like DOM manipulation; and then goes wrong a third time by having only one de-facto implementation with no open standard.
- samastur 14y ago
  What do you mean by specs are open? Published fully or developed communally? Fully published is obviously better than not, but is rarely enough. Openness is not a binary choice.
  - derefr 14y ago
    Developed communally, as part of the Chromium project. Not as a vendor-neutral working group or anything of the sort yet, mind you. But there's no reason it wouldn't move to become that if any other vendor was actually interested in coordinating on it--they're not hiding their cards inside Google's walled garden or anything.
    - MatthewPhillips 14y ago
      You're incorrect, that's not how NaCl or Dart were developed. They were developed in secret years before released. They're alpha versions had all of the fundamentals established when finally presented to the public.
      - derefr 14y ago
        I don't see how the way in which something is developed before its first release has any bearing on whether its current development is community-driven. Everything was designed in secret at some point: within the head of whoever was thinking about it, before they decided to start talking about it.
        MatthewPhillips 14y ago
        > I don't see how the way in which something is developed before its first release has any bearing on whether its current development is community-driven. You don't? Go look at the nacl commit logs and count how many non-Google employees are contributing. That it was developed in secret is precisely the reason for this (not because they are against outside contributors today). If you develop a supposedly open technology in secret it either needs to be 1) really good or 2) really popular. XHR is successful because it fits into both. Whatever you may feel about NaCl, Microsoft, Apple and Mozilla don't think it's good.
lucian1900 14y ago
NaCl (in particular PNaCl) is merely a different approach. I would call asm.js crazy, but that's just me. Something similar could be said about Dart, but there the language itself is not so interesting (merely not insane). The VM is potentially the language-independent bytecode and stdlib in a browser we've all been waiting for. While Google have been behavin evil-ly lately, in particular related to Google+, NaCl and Dart are not examples of this.
- pcwalton 14y ago
  Why is asm.js crazy?
- hosay123 14y ago
  Nacl is not merely a different approach, it's a wholly backwards incompatible approach based on techniques that tried and failed in the 80s (try searching for ANDF).
  - mkr-hn 14y ago
    A lot of things were tried in the past, but they fail for a variety of reasons. Some are picked up later and work because the fatal problems were addressed. I couldn't find much on ANDF. Can you be more specific about why it failed?
- ville 14y ago
  To clarify, Dart VM is not a bytecode VM: http://www.dartlang.org/articles/why-not-bytecode/ http://www.dartlang.org/articles/why-not-bytecode/
michaelwww 14y ago
> Google started their proprietary ... Dart project because they claimed you couldn't make JavaScript any faster than it currently is No, they didn't. Google started Dart because they had a bunch of Java programmers who were having good success building JavaScript web apps such as Gmail with Google Web Toolkit. They thought to formalize it with Dart instead of using a hacked up Java dev environment. I have a client who needed a web app fast, so I took a chance on Dart and did it in half the time. The client doesn't even know I'm doing it in Dart. I'm shipping the minified js file which works on all modern browsers because the Dart team set out to bring jQuery up to a higher level. There's a bright side to all the dislike and misinformation about Dart though, because it gives me a competitive edge.
- mistercow 14y ago
  >The client doesn't even know I'm doing it in Dart. I'm shipping the minified js file which works on all modern browsers because the Dart team set out to bring jQuery up to a higher level. I would feel very uncomfortable about that unless it's the sort of client that doesn't really have the tech background to assume you're writing it in JS in the first place. I think if someone is paying to have software written for them, they have a right to have some control over what language it's written in and what libraries it uses. After all, if they need to hire someone else to maintain it or add to it later on, they're going to have a far easier time finding a JS developer to do that than a Dart developer (at least for now). And, of course, you have the right to charge twice as much to do it in JS if it's going to take you twice as long.
  - michaelwww 14y ago
    I agree with you, but this client really doesn't care, only that it is done quickly and it works. They're pretty happy and are lining up more work for me. I'd say the greatest experience I had with it besides real types, code completion and intellisense, is that it ran first time on iPad (Safari, Chrome, FF), Mac and Windows FF and Chrome. I had a slight problem with IE9 and 10, but nothing too hard to fix. The client had paid someone to do it in ActionScript/Flash but the project had to be cancelled when Flash on mobile was mostly deprecated. I didn't look at the ActionScript code, but later found out there is a lib for that (haven't tried it and won't unless I have to someday) http://www.dartflash.com/ http://www.dartflash.com/
mistercow 14y ago
>Google started their proprietary NaCl and Dart projects because they claimed you couldn't make JavaScript any faster than it currently is I don't remember them saying that. I remember them saying that JS has insurmountable performance problems, but that's very different from saying that JS is as fast as it can get. As for asm.js, it's another approach to the same problem. An insurmountable problem for a VM usually means that there's a limit to how well the VM can reason about arbitrary code. The clever thing about asm.js is that it gets around that by just restricting the language rather than inventing a new one. The clever thing about Dart is that you would rather write in it than kill yourself. And yes, of course asm.js is meant to be written by compiling via emscripten, but that means trading far more dynamicness for speed than you would with Dart.
acdha 14y ago
I was with you on the first paragraph but the second goes off the rails on the second sentence. It's hard to say that Google isn't also championing the open web unless you claim that Chrome isn't a Google product - NaCL and Dart are interesting experiments but it's not like Google hasn't poured a TON of expensive, high-quality time into creating an industry-leading JavaScript engine (along with CSS, HTML5, etc. support) and put a similar amount of time into evangelism, developer outreach, etc. Even if Google cancelled Chrome tomorrow, the entire open web community would owe them a debt of gratitude for administering the coup de grace to IE's reputation as the only significant desktop browser and pushing Mozilla to heavily invest in performance and the user experience – they cared about them before but as we can see now, setting your goal as “better than IE” was still too low. There were a bunch of nice things which happened around that time – Firefox, Safari, iPhone, etc. – but the thing which really opened the desktop market moving was Chrome shipping a radically fast, user-friendly browser which you could install even on typical corporate IT-mismanaged desktops and which you never needed to think about updating. Web standards advocates had spent years preaching using standards first and fallbacks for compatibility and related ideas but the rise of Chrome seems to be what got the mainstream web developer to really internalize that idea and start coding with the assumption that the browser would improve before they revisited a site.

monkeypizza 14y ago

For years I've used gchat & status (& temporarily used buzz) as a light social network for friends, and it worked great. But now they've made it so mouseovers on the status don't work as well, and generally cramped up the design so status messages aren't as visible... could be part of the same plan.

Andrenid 14y ago

This is actually the final step for me. I've been an avid Google fan since the early days. I use all the Google services, I use Chrome religiously, I convince family/friends to switch to Chrome from IE, and I've always been convinced Google is the one we're supposed to look up to for how things should be done. Yeah they've made mistakes, and G+ is a clusterfuck of brilliant talent thrown down a horrible path of closed socialness and realname ridiculousness... but overall I always thought they were still on the right side of "Don't Be Evil". I'm totally convinced this quiet attack on RSS is a not-so-subtle attempt to push people into G+, and even though I casually use G+ (about the same as I casually use FB or Twitter), G+ is NOT a replacement for RSS, and it's not how I want to keep track of all the sites I read. I don't want to "like" them or add them to my social networks. I just want to read their shit. Simple. RSS doesn't care if you're logged in. RSS doesn't care if you use your real name. RSS doesn't care if you're accessing it from work, home, or anonymously via an internet cafe. And that's exactly how it should be. Throw in the Picasaweb crap they're doing now too, FORCING you to use G+ Photos (which is a horrible horrible experience), and I'm done. I've just installed Firefox on all my home computers and my phone, for the first time since Chrome came out, and will be looking for a new RSS aggregator.

zanny 14y ago
I don't get where this sentiment comes from. Ever. They are a publicly traded multi-billion dollar company. Even if they hold onto their startup-esque purism for a decade after their founding, they of course fall from grace into the profit motive pitfall because that is how the investor driven market capitalism system works. Never put blind faith in a corporate entity, because they all transition from consumer-driven-product-with-creative-vision to maximize-stockholder-returns-and-short-term-profit. It is how you do business in the big leagues. Google just had the lucky case of having a slow transition, probably due to good decisions in the early years. I get that HN has this startup culture where creative people come up with "cool things" to sell, and are product oriented rather than profit oriented (though a lot of them seem to love the idea of selling the business off to a big business like Google, walking away with the pocket change, and watching it flounder into obscurity under corporate oversight...) but big business isn't run by people who have product vision, they have profit vision, and these companies are the amalgam of hundreds of managers and overseers that don't have collective vision and can thus only drive it towards what they can all agree on - making higher returns. It happens to the best of them.

Kiro 14y ago

RSS is a broken standard so I would be happy if you were right.

chris_j 14y ago
What is it about RSS that is broken and what would you like to see replace it?
- acdha 14y ago
  Atom: see http://www.intertwingly.net/wiki/pie/Rss20AndAtom10Compared http://www.intertwingly.net/wiki/pie/Rss20AndAtom10Compared for details but it basically boils down to RSS having gaps and inconsistencies which are compounded by the spec being essentially fossilized and David Winer being famously difficult to deal with.
jms18 14y ago
Yes, RSS 2.0 has a bunch of problems. That is why this -- http://www.ietf.org/rfc/rfc4287 http://www.ietf.org/rfc/rfc4287 -- was developed. IETF standards have a history of longevity, and I suspect this format will be around a very long time.

michaelwww 14y ago

I'm not understanding all the people saying this kills RSS. There are plenty of RSS readers out there.

mcintyre1994 14y ago
Agreed. If an open standard was relying entirely on a company not to 'kill' it, it was already dead as an open standard.

diegocg 14y ago

If google wanted to kill RSS they would stop supporting RSS in their products.

digikata 14y ago

I've actually been wondering if there's a pattern to these closures related to some scaling issue on the Google infrastructure. Google tends to build services tightly integrated with a common fabric. Scaling issues might cause the design of smaller services to take more than their share of resources. Consider that Reader and other small services needing event and data synchronization, were often started by independent "20%" teams, earlier on in google's infrastructure build out. So maybe services at a higher priority are needing those resources. Or maybe they're looking at upgrading the "google fabric" in an incompatible way and if you have to redesign fundamental assumptions through the code of smaller services, you might stop and take a hard look at seeing if a large rewrite is worth it.