Today's API Guessing Game

Intro with Joshua’s digitized voice (from 1983’s WarGames) asking “shall we play a game?

I’ve spent the better part of the past couple of days playing a game. I was chasing down some odd polling behavior observed in one of our internal prototype applications. It ultimately turned out to be some bad assumptions I made around how some code I wrote should behave. The rate limiting policy around one of the open APIs I was using was obfuscated.

The scenario reminded me of a challenge I faced earlier in my career at Netscape. We were trying to figure out how Netscape/Mozilla open source should function (early on in Mozilla’s life… pre-independence from AOL; e.g. 1998). We struggled managing corporate needs, sometimes around confidentiality, in the context of open source. Mozilla wouldn’t work if things that impacted the open source software on the Netscape-side of the engineering house weren’t openly discussed. As predicted, innovation suffered when significant code contributions being made by Netscape weren’t transparent. Netscape was faced with staying quiet about its intentions, or being open with them. Open sourcing the code (e.g. having an “open” API) wasn’t enough. The process by which the code/API was to evolve and function had to be open.

Netscape/AOL weren’t able to let go of key, though seemingly small, aspects of the project and innovation waned. Mozilla/Firefox didn’t explode until there was a formal transition from AOL to Mozilla Foundation many years later. While Firefox has pushed the industry forward in bounds since then, there were years of browser industry confusion and impedance due to a non-committal controlling interest.

The parallel I’m drawing between Netscape/Mozilla’s history and today’s “open” web APIs is that there are key players chokeholding the rest of the industry with inadequately supported, poorly communicated, API access policies. Access policies, while sometimes documented, are highly irregular and poorly communicated. The result is a developing ecosystem around these APIs that has to decide whether or not to play the API access guessing game. When a developer using some of today’s open APIs wakes up and rolls out of bed each morning they wonder “will my application work today?” That’s untenable in the long term.

Just as it was Netscape’s right to control the bits it wanted to, Kings of today’s API hill have a right to do whatever they want. To those who’ve been successful at creating unyielding demand; hats off! Use that power wisely however, and learn from history’s mistakes.

To APIs crying uncle due to the operational overload of their popularity I recommend moving to an event driven API access model (ala Gnip). When that’s simply not possible (though I’d argue it always is) use something like SUP to minimize constipation in the rest of the digestive system.

If you’re throttling access to your API because you don’t know what your business model is, hurry up, get it sorted, and communicate intentions. If you don’t, industry will find a way to pass you by.