Mashup Camp IV Day 1: Why DIY when APIs are available?

This was really Chris Radcliff’s bitch session on why don’t people just use the Eventful API instead of writing their own event functionality over and over again 🙂 but we discussed a number of interesting points that have analogies in any development environment:

Why people write their own functions even if something exists:

• Discoverability, that is, they don’t know that the function exists externally
• Lack of functionality (or perceived lack)
• Lack of control over functionality, which is a sort of subset of the previous point
• Lack of service level agreement
• “Not invented here” syndrome
• Complexity of external APIs

Why people shouldn’t write their own functions, but use one that already exists:

• Someone else maintains the code
• That particular function is not a core competency and not a competitive differentiator
• It takes longer to get up and running if you write it yourself than if you use an existing API

There was an extended discussion of event APIs and functionality in general, which was not really the point of this session, but it’s an interesting case study for looking at the issues. There’s a ton of other examples here: spam filtering, address lookups, geocoding; all of these are readily available from a couple of competing sources. Of course, it’s all a matter of timing: I can recall when we wrote TIFF decompression and display algorithms in the late 1980’s because nothing else existed, something that would never be considered now.

There’s obvious differences in APIs that deliver content versus those that manipulate content with respect to both copyright issues and currency: if an API is maintaining an up-to-date database of information behind the API (like Eventful, which has about 4 million future events in their database at any given time), then it may be much better positioned to deliver the right content than something that you build yourself.