While writing this little id3v2 library, the first I've written that I plan to release and support, I've been thinking about a few of the issues people have when writing libraries and APIs. Here's a few I like:

1. Writing an API is hard.
2. Unit testing is critical, which means
3. Test code coverage analysis is also critical.
4. Don't release the official 1.0 early. Wait until the API entropy slows but
5. Get people to test the early versions and give feedback.
6. Give people what they need, not what they want. That means you'll have to
7. Listen to your users, but
8. You can't please everyone, so you have to
9. Be able to make intelligent compromises.
10. Empathize with your users by using the API yourself in an application.
11. Don't bite off more than you can chew; start small.

There are some other issues for dealing with data "in the wild". You can't just throw an exception when you get bad data, you should be expecting it. So you have to have a way to represent it that tells the API user "hey, this is bad".

It reminds me of the discussions around malformed syndication feeds and what feed readers should do with them. When developers started thinking more about the users and less about themselves, they realised that reading malformed feeds was a good idea. But the API should still indicate it's malformed.

The good news about id3v2? The last version is four years old. In high tech terms that's ancient, the specification entropy has slowed and it doesn't look like it's going anywhere. This reduces risk and the need for agility.

Despite its age, id3v2 is actually gaining in popularity. It's the de facto tagging format for mp3, so companies will trust it. It has hardware support. It's used in popular music players and online music stores. It's everywhere. It's amazing that there isn't a free Java implementation out there that's still supported.