3 ms·

You get it. That's exactly the point. Go ahead and make a new API, no problem, but don't break the apps we built over the last N years while Flickr was hiberna

You get it. That's exactly the point. Go ahead and make a new API, no problem, but don't break the apps we built over the last N years while Flickr was hibernating.

neilk 14y ago
Would you be willing to accept the same strictures yourself, to software you have written? You are never allowed to sunset bad ideas or stop supporting them - at least, not until a government committee says so?
- dodyg 14y ago
  Forget about the developers perspective and consider the users of the software that consume the API itself. Their applications will suddenly stop working and we cannot assume that they can obtain the upgraded version of their software (for various reasons).
  - davewiner 14y ago
    That's right. Most of the development done with Flickr was finished a long time ago, and the apps are deployed and there's no one around to deal with deprecated APIs. That's of course assuming that it's possible to do with a new API what you could do with the old one. We've seen with Twitter that's not necessarily true. But thanks Dody for thinking of users. That's often pretty far down the priority list for developers, esp at big companies.
- davewiner 14y ago
  Yes, of course. And I did it with RSS 2.0, froze the format so we'd all have something to shoot for. http://cyber.law.harvard.edu/rss/rss.html#roadmap http://cyber.law.harvard.edu/rss/rss.html#roadmap
  - neilk 14y ago
    Perhaps I've misunderstood, but that does not seem comparable. * You decided when the spec should be frozen. You're asking Flickr to give away control over their specs. * Freezing a spec incurs no ongoing cost to you. You're asking Flickr to maintain current services indefinitely. A comparable situation would be to put Userland under the control of some external entity, which had the right to impose obligations on you to (for instance) keep the data available in current formats forever.

You get it. That's exactly the point. Go ahead and make a new API, no problem, but don't break the apps we built over the last N years while Flickr was hibernating.

neilk 14y ago

Would you be willing to accept the same strictures yourself, to software you have written? You are never allowed to sunset bad ideas or stop supporting them - at least, not until a government committee says so?

dodyg 14y ago
Forget about the developers perspective and consider the users of the software that consume the API itself. Their applications will suddenly stop working and we cannot assume that they can obtain the upgraded version of their software (for various reasons).
- davewiner 14y ago
  That's right. Most of the development done with Flickr was finished a long time ago, and the apps are deployed and there's no one around to deal with deprecated APIs. That's of course assuming that it's possible to do with a new API what you could do with the old one. We've seen with Twitter that's not necessarily true. But thanks Dody for thinking of users. That's often pretty far down the priority list for developers, esp at big companies.
davewiner 14y ago
Yes, of course. And I did it with RSS 2.0, froze the format so we'd all have something to shoot for. http://cyber.law.harvard.edu/rss/rss.html#roadmap http://cyber.law.harvard.edu/rss/rss.html#roadmap
- neilk 14y ago
  Perhaps I've misunderstood, but that does not seem comparable. * You decided when the spec should be frozen. You're asking Flickr to give away control over their specs. * Freezing a spec incurs no ongoing cost to you. You're asking Flickr to maintain current services indefinitely. A comparable situation would be to put Userland under the control of some external entity, which had the right to impose obligations on you to (for instance) keep the data available in current formats forever.