6 ms·

I'm still irritated with Google Reader story. How long is this one going to be around, year, two? I think Google should start pledging a number of years they wi

I'm still irritated with Google Reader story. How long is this one going to be around, year, two? I think Google should start pledging a number of years they will support a service, why should the developer be taking most of the risk?

ewolf 14y ago
There never was any official Google Reader API. Every developer was aware of the risk he was taking when using an unoffical and undocumented API.
mgkimsal 14y ago
That's actually a good point. Giving people a "minimum guaranteed time" for APIs and services would give a lot more confidence to people looking to build on them, and also keep data portability at top of mind when building on those services.
- polskibus 14y ago
  I'm pretty sure they already know the minimum time they want to keep a certain service afloat. Would they really lose much if they publicly announced a date, after which they would reevaluate a service? I think I'm giving Google free PR advice here... damn you Google!
- arkem 14y ago
  Some of Google's API do have this, it'll be in their terms of service under "Deprecation Policy". The deprecation policy is a promise that if the service is going to be discontinued you'll have at least X notice. The examples I can think of off hand are all Google App Engine related but I wouldn't be surprised if some of the Drive APIs have the same thing.
yanw 14y ago
Reader didn't have a documented API, and the differences between it and this only begin there. Move on.
- jerhinesmith 14y ago
  I'm not the OP, but I don't think he was necessarily talking about the Google Reader API (rather just the service). If you're getting hung up on documented/undocumented APIs, pick any one of the deprecated examples from this list (http://googlecode.blogspot.com/2011/05/spring-cleaning-for-some-of-our-apis.html http://googlecode.blogspot.com/2011/05/spring-cleaning-for-s...) and substitute it in for Google Reader.
  - polskibus 14y ago
    I was talking about the service, it doesn't really matter for the user if it's in a form of API or not. I do "PAY" google with my wasted brainpower when I see ads they serve (adblock possibility aside). Seriously though, there's nothing free but it works both ways, it's only fair and long lasting when both sides treat the arrangement as a contract.
    - tomkarlo 14y ago
      How is that arrangement a contract? If you came to Starbucks every morning and bought a cup of coffee, would you consider that to be creating some kind of contract with them?
  - yanw 14y ago
    https://news.ycombinator.com/item?id=5403668 https://news.ycombinator.com/item?id=5403668
- anon1385 14y ago
  Oh so Google never cans a free service that has an official documented API? Google Translate? Google Search API? >Move on. Yes, let's just forget about all the stuff Google does that sucks and pretend it never happened.
  - capo 14y ago
    I doubt anything will change your opinions about Google: https://news.ycombinator.com/threads?id=anon1385 https://news.ycombinator.com/threads?id=anon1385 https://news.ycombinator.com/submitted?id=anon1385 https://news.ycombinator.com/submitted?id=anon1385 Carry on, I guess.
616c 14y ago
They plan on charging people for Drive space, so I see the underlying storage as a Dropbox competitor while the convenience of online collaboration tools and document editing meant to push them out, as it is heavily integrated into other Google services. https://support.google.com/drive/bin/answer.py?hl=en&answer=2375123 https://support.google.com/drive/bin/answer.py?hl=en&ans...
tomkarlo 14y ago
Isn't this the risk any time you build on top of someone's API? At least with Google Drive they have a clear revenue story - compare that to say, Twitter.
notatoad 14y ago
Don't build a business or product that relies on a proprietary API with no service agreement. APIs with no service agreement are okay if they're well-documented and have multiple providers, proprietary APIs are fine if they have a service agreement. Something like this should not be used as the base for your product, it should only be used as a means to provide an extra feature to an existing service. This is allows you to integrate your real-time web application with drive, it's not a foundation to build your real-time service on top of. Just because google shut down reader doesn't mean that this applies to their APIs more than any other company's. If you build something that relies on an API that can disappear at any time, you have nobody to blame but yourself.
hugofirth 14y ago
Ugh - people should just LET READER GO. Here we have what looks like a cool, well documented, API to a powerful service supported by a major company and instead of talking about the cool things we could build with it we seem to be indulging in that most deplorable and pointless of past times - the fan boy cat fight. This is still called "Hacker" news correct? FYI the translate API is paid - not retired. The rates are very low and free for limited use. Furthermore CalDAV was one of the worst things I have ever had the displeasure to work with - why are we mourning that ? Now - can we please talk about something worthwhile like ... Oh! ... the OP /rant
- Samuel_Michon 14y ago
  "Ugh - people should just LET READER GO." Yeah, it's been 6 whole days! Some people really dwell in the past, don't they? I don't see what the big deal is, especially since Google has already given us something way better, which will replace RSS, Twitter, Facebook, and probably email – in a couple of months everyone will be using Google+ and we'll have forgotten all about Reader.
  - ancarda 14y ago
    How is Google+ a replacement for RSS?
    - camus 14y ago
      he was being sarcastic ;)
  - hugofirth 14y ago
    You talk like its a person - it's a damned service ... Plus my point was that the demise of Reader had nothing to do with the OP, and that its continued discussion in any post containing the letter G was pathetic, detracting from more interesting conversations we could and should be having - like the one about the possibilities of the new Drive API... I'm tired of the railroading and the assumption that a for-profit organization has some sacred duty to think about anything more than its bottom-line. That Google thinks beyond its bottom line quit often (Glass, Cars etc...) is to its credit - IMO that it does not do so all the time (Wave, Buzz, Video, Reader etc...) is NOT to its discredit.
guptaneil 14y ago
The self-fulfilling prophecy[1] is a powerful phenomenon. If Google pledges 3 years support, then I will assume it's going to be killed in 3 years and not even bother trying to build a business on it, even though Google only means that as a minimum. If everybody assumes the same, then the API probably will end up dead in 3 years, because nobody is using it. On the other hand, since Google makes no such pledge, I don't feel like this API has an expiration date. Instead, I look at this as Google's latest product, and I might want to be the first to integrate it into my service, because it could be the next big thing. If enough people think that way, then the API will thrive and stick around. Sure, the API could still disappear, but any startup built on it has a greater chance of dying before the API does. Google's problem right now is that it has pissed off a vocal minority with the Google Reader shutdown, so any announcement is being met with pessimism and mistrust. 1: http://en.wikipedia.org/wiki/Self-fulfilling_prophecy http://en.wikipedia.org/wiki/Self-fulfilling_prophecy
- polskibus 14y ago
  No expiration date is just an evil omission. The risk is of obsolescence is there, whether they state the date or not. Making the risk visible to everyone makes the situation clearer for everyone. All that is needed is a table like http://support.microsoft.com/lifecycle/?ln=en-gb&c2=1173 http://support.microsoft.com/lifecycle/?ln=en-gb&c2=1173

ewolf 14y ago

There never was any official Google Reader API. Every developer was aware of the risk he was taking when using an unoffical and undocumented API.

mgkimsal 14y ago

That's actually a good point. Giving people a "minimum guaranteed time" for APIs and services would give a lot more confidence to people looking to build on them, and also keep data portability at top of mind when building on those services.

polskibus 14y ago
I'm pretty sure they already know the minimum time they want to keep a certain service afloat. Would they really lose much if they publicly announced a date, after which they would reevaluate a service? I think I'm giving Google free PR advice here... damn you Google!
arkem 14y ago
Some of Google's API do have this, it'll be in their terms of service under "Deprecation Policy". The deprecation policy is a promise that if the service is going to be discontinued you'll have at least X notice. The examples I can think of off hand are all Google App Engine related but I wouldn't be surprised if some of the Drive APIs have the same thing.

yanw 14y ago

Reader didn't have a documented API, and the differences between it and this only begin there. Move on.

jerhinesmith 14y ago
I'm not the OP, but I don't think he was necessarily talking about the Google Reader API (rather just the service). If you're getting hung up on documented/undocumented APIs, pick any one of the deprecated examples from this list (http://googlecode.blogspot.com/2011/05/spring-cleaning-for-some-of-our-apis.html http://googlecode.blogspot.com/2011/05/spring-cleaning-for-s...) and substitute it in for Google Reader.
- polskibus 14y ago
  I was talking about the service, it doesn't really matter for the user if it's in a form of API or not. I do "PAY" google with my wasted brainpower when I see ads they serve (adblock possibility aside). Seriously though, there's nothing free but it works both ways, it's only fair and long lasting when both sides treat the arrangement as a contract.
  - tomkarlo 14y ago
    How is that arrangement a contract? If you came to Starbucks every morning and bought a cup of coffee, would you consider that to be creating some kind of contract with them?
- yanw 14y ago
  https://news.ycombinator.com/item?id=5403668 https://news.ycombinator.com/item?id=5403668
anon1385 14y ago
Oh so Google never cans a free service that has an official documented API? Google Translate? Google Search API? >Move on. Yes, let's just forget about all the stuff Google does that sucks and pretend it never happened.
- capo 14y ago
  I doubt anything will change your opinions about Google: https://news.ycombinator.com/threads?id=anon1385 https://news.ycombinator.com/threads?id=anon1385 https://news.ycombinator.com/submitted?id=anon1385 https://news.ycombinator.com/submitted?id=anon1385 Carry on, I guess.

616c 14y ago

They plan on charging people for Drive space, so I see the underlying storage as a Dropbox competitor while the convenience of online collaboration tools and document editing meant to push them out, as it is heavily integrated into other Google services. https://support.google.com/drive/bin/answer.py?hl=en&answer=2375123 https://support.google.com/drive/bin/answer.py?hl=en&ans...

tomkarlo 14y ago

Isn't this the risk any time you build on top of someone's API? At least with Google Drive they have a clear revenue story - compare that to say, Twitter.

notatoad 14y ago

Don't build a business or product that relies on a proprietary API with no service agreement. APIs with no service agreement are okay if they're well-documented and have multiple providers, proprietary APIs are fine if they have a service agreement. Something like this should not be used as the base for your product, it should only be used as a means to provide an extra feature to an existing service. This is allows you to integrate your real-time web application with drive, it's not a foundation to build your real-time service on top of. Just because google shut down reader doesn't mean that this applies to their APIs more than any other company's. If you build something that relies on an API that can disappear at any time, you have nobody to blame but yourself.

hugofirth 14y ago

Ugh - people should just LET READER GO. Here we have what looks like a cool, well documented, API to a powerful service supported by a major company and instead of talking about the cool things we could build with it we seem to be indulging in that most deplorable and pointless of past times - the fan boy cat fight. This is still called "Hacker" news correct? FYI the translate API is paid - not retired. The rates are very low and free for limited use. Furthermore CalDAV was one of the worst things I have ever had the displeasure to work with - why are we mourning that ? Now - can we please talk about something worthwhile like ... Oh! ... the OP /rant

Samuel_Michon 14y ago
"Ugh - people should just LET READER GO." Yeah, it's been 6 whole days! Some people really dwell in the past, don't they? I don't see what the big deal is, especially since Google has already given us something way better, which will replace RSS, Twitter, Facebook, and probably email – in a couple of months everyone will be using Google+ and we'll have forgotten all about Reader.
- ancarda 14y ago
  How is Google+ a replacement for RSS?
  - camus 14y ago
    he was being sarcastic ;)
- hugofirth 14y ago
  You talk like its a person - it's a damned service ... Plus my point was that the demise of Reader had nothing to do with the OP, and that its continued discussion in any post containing the letter G was pathetic, detracting from more interesting conversations we could and should be having - like the one about the possibilities of the new Drive API... I'm tired of the railroading and the assumption that a for-profit organization has some sacred duty to think about anything more than its bottom-line. That Google thinks beyond its bottom line quit often (Glass, Cars etc...) is to its credit - IMO that it does not do so all the time (Wave, Buzz, Video, Reader etc...) is NOT to its discredit.

guptaneil 14y ago

The self-fulfilling prophecy[1] is a powerful phenomenon. If Google pledges 3 years support, then I will assume it's going to be killed in 3 years and not even bother trying to build a business on it, even though Google only means that as a minimum. If everybody assumes the same, then the API probably will end up dead in 3 years, because nobody is using it. On the other hand, since Google makes no such pledge, I don't feel like this API has an expiration date. Instead, I look at this as Google's latest product, and I might want to be the first to integrate it into my service, because it could be the next big thing. If enough people think that way, then the API will thrive and stick around. Sure, the API could still disappear, but any startup built on it has a greater chance of dying before the API does. Google's problem right now is that it has pissed off a vocal minority with the Google Reader shutdown, so any announcement is being met with pessimism and mistrust. 1: http://en.wikipedia.org/wiki/Self-fulfilling_prophecy http://en.wikipedia.org/wiki/Self-fulfilling_prophecy

polskibus 14y ago
No expiration date is just an evil omission. The risk is of obsolescence is there, whether they state the date or not. Making the risk visible to everyone makes the situation clearer for everyone. All that is needed is a table like http://support.microsoft.com/lifecycle/?ln=en-gb&c2=1173 http://support.microsoft.com/lifecycle/?ln=en-gb&c2=1173