On Hacker News the question of when should a platform vendor deprecate an API. Reminds me of a question a dentist once asked me. Which of your teeth should you floss? Only the ones you want to keep. (He answered his own question, witty fellow.)
So the answer for the platform vendor is really simple.
If you want to deprecate an API, maybe you shouldn't be in the API business at all? Because when you deprecate, the developers will wonder, next time, when you will pull the rug out from under their work.
They will have to guess how much use the API will get. And how much is enough for you? How can they possibly gauge that? Maybe next year someone else will be in charge. Maybe they won't like or understand the API. Maybe they don't really tell us the reason they're deprecating. Maybe use has nothing to do with it? Maybe they have a chance for some cred within your organization, and having their name on some "new" technology is a way to do that?
It's a funny game. Really imho the only APIs you can trust are ones that no one owns, where there isn't a single vendor implementing it. That was one of the reasons why I froze RSS in 2002. I wanted to build on it, and didn't want to go back and have to continually re-implement the same functionality because some company or working group at the W3C wanted to rip up the pavement.
Great point. When you froze RSS in 2002 I thought it was a bad idea. Time has proven you right :)
It was basic common sense. If you wanted something that couldn't fit into a namespace, then you were basically trying to change the name of a built-in value. I couldn't think of another reason, I don't think there is one. If you want to do that, why do you need to call it RSS ? Just give it another name and have a party. That's what the roadmap says. It doesn't say you can't fuck around with RSS, it says you can't do and it and call the result RSS.
BTW, at that time I had already seen what happened with XML-RPC as it was turned into SOAP. And SOAP had the decency not to call itself XML-RPC.
Without being able to deprecate APIs, how do we go about fixing or evolving API specifications? What's a good way for API providers to learn from how developers are actually using (or not using their APIs) and make appropriate changes over time?