Google Could Learn from Shakespeare
Last night I attended a performance of Hamlet at Shakespeare in the Park. For all those who don’t know, Shakespeare in the Park is a free performance given throughout the summer in an outdoor theater in Central Park. Tickets are given out to those who wait on line for hours on the morning of the show (for more info, click here). The play was great and the actors were amazing. Like many Shakespeare plays, the producers/directors put their own spin on the classic. Last night’s performance had a very modern take on Hamlet. The soldiers were holding guns. Background sounds of combat filled the air with planes and bombs. The settings may change but the Shakespearian themes stay true.
The interesting thing happened at the end when the story was completely altered from other versions of Hamlet that I’ve seen. I don’t want to give away what happened, for those who might see it, but I found it interesting that the words of Shakespeare stayed the same but this interpretation almost contradicted those words. It was fine. It’s nice to see a different spin on Shakespeare.
This scenario made me think of the current openness trend on the web. Every major company is opening their site up for others to use through APIs. The concepts of data portability and connecting content (Open Social, Facebook going open source, etc..) seem to be building towards an architecture of the web that will allow developers to create applications that are not possible today. These sites, the Googles and Facebooks of the world, think they can write the words to the play and understand how these words will be used in practice. The developers, however, will create the play and will end up interpreting the words as they see fit, even if it’s contradictory to what was originally intended.















Don’t confuse releasing an API with “going open source.” Facebook isn’t open source; they released an API for developers to use. The distinction is huge.
An API isn’t exactly source code. It is the ability to call functions within the platform the API was designed for. It is, essentially, a protocol for doing things.
For example: Facebook didn’t release their algorithms for how it figures out who your friends might be. But they might have given the ability to developers to call their findPotentialFriends function. I don’t know how findPotentialFriends is implemented and Facebook sure isn’t telling me. They’re simply making me a promise: if you call this function with the parameters we tell you to call it with, we’ll give you information in return.
In that sense, it is still very much a closed garden. Facebook dictates how and when you can use their API. If they don’t like a particular application, they can shut your API key off. If they don’t think anyone will use a feature they can deprecate it. Actually, even if they KNOW people are using a feature, if they think it will take too much money away from them they can stop developers from calling specific functions.
A closed API isn’t a democracy. A closed API is a dictatorship: you use it on the terms of the owner at the owners good-will, and the owner can stop you from using it at any time.
Facebook actually has gone open source (http://www.techcrunch.com/2008/06/02/facebook-turns-platfrom-open-source-via-fbopen/). The code might not be completely available like other sites, but according to Techcrunch, it’s open source.
I stand corrected.
Pretty cool that they’ve released their code. When I went to read about Platform I thought it was just a comprehensive API, not the whole kitten-kaboodle.