’s unwise decision

*** Please read’s response below *** has changed their API; for those who are not programmers, an API (application programming interface) is a set of routines that allow a program to make requests to another program or web service. In and of itself, changing an API is not a bad thing and, in many cases, can be quite beneficial. For instance, adding new features to an API can allow programmers more options for interracting with the product.

However, the changes that made were not backwards compatible and caused software that used the API to break. The open source music player Banshee for instance still displays recommended tracks from, but is unable to play these tracks. When a user attempts to listen to a recommended track, he or she is greeted with the message "GStreamer resource error: NotFound" on the terminal or in the error log. In light of this error, displaying the tracks at all is rather pointless.

I realize that I am behind the times as this change ocurred in March, but I have just tried listening to through banshee for the first time this week. I had initially thought that this was a problem with my installation of Banshee, or with the software in general. I want to reiterate, the problem is not with Banshee – or any other music player that is experiencing similar issues – the problem is the fault of

Modifying APIs is okay, but these modifications should always maintain backwards compatibility unless there is an extremely good reason for not doing so: weak security where security is crucial, poor scalability, bad performance. Also, if many programs use an API, the developers of the API should allow the deprecated version to function for at least 6 months while projects have a chance to be modified to support the new methods. These changes should also be clearly announced as soon as – or, preferably prior to – them happening. This alteration seemed to have happened almost overnight and with very little warning given the number of surprised people in the forums. claims that they were required to make these changes due to new licensing agreements with the music industry. But, for once, I will not take the opportunity to lay blame at the industry’s feet. did not have to cave in and willingly commit a serious programming mistake. Worse, they let their user base down by breaking their music players.

Unsurprisingly,’s music player still works according to reports. I cannot verify this fact as I prefer to use a more full-featured music player and have never tried theirs. Call me paranoid, but this almost sounds like an excuse to limit choice and lock users into using’s player or web interface to play music hosted with them. This especially seems true in light of the fact that the scrobbling portion of their API is still in tact. Scrobbling is the method users’s software employs to send data about the songs they listen to back to

Because the streaming portion of the API (the part that sends data to users) was made backwards incompatible, but the scrobbling portion (that collects data from users) was left in tact, I have seen many complaints that is just using their customers to collect data without caring about their experiences using the service. I do not completely agree with this, as if licensing was truly the cause for the change, they would likely only need to limit what they sent to users, not what users sent back to them. However, that does not make this practice any more ethical. Programmers need to be able to trust that APIs are not going to change on a whim with little or no notice.

This decision of’s seems to sketchy and has undermined the trust that many users and developers have placed in their service.

Further reading:


  1. Russ Garrett says:


    I’m responsible for these recent API changes at and I’d just like to straighten a few things out:

    Firstly, that radio API has never been publicly documented – it was designed with our client in mind. All the apps which were using the old API had reverse-engineered an old version of our client. We had turned a blind eye to this, but it’s worth noting that we *never* officially supported this API for third-party use.

    Back in March, we announced a new, supported and documented API:

    You can see the documentation here:

    Now it’s true that the new API has more restrictions than the old one (only subscribers can stream using it), but this is because we have to pay for every track we stream. The old API was being used by hundreds of streamrippers and other unsavoury clients, which were costing us money, both in royalties and in the hardware used to support the old API. It was also much harder to track clients using the old API.

    I hope that makes it clearer why we made this change. We’d normally never break old APIs, but we didn’t have any choice in this case.

  2. cball says:

    Thank you for providing the official reason behind the changes and for clarifying my misunderstandings based upon forum discussions.

  3. [...] Ball explains one way the change is noticed by users: “The changes that made were not backwards compatible and caused software that used [...]

  4. [...] Ball explains one way the change is noticed by users: “The changes that made were not backwards compatible and caused software that used [...]

  5. Its like you read my mind! You seem to know so much about this, like you
    wrote the book in it or something. I think that you can do with
    a few pics to drive the message home a bit, but other
    than that, this is excellent blog. A fantastic read. I will certainly
    be back.

Leave a Reply