The ?killer app? is a term for those of a geekish lean that describes the ultimate application out there that you simply can?t live without. It is typically used identify a utility or program that provided countless opportunities to create new things, or tweak out your computer, or give you immense flexibility over content consumption. If was a mark of good standing if your application was tossed around in the question, ?Is this the killer app?? I dreamed I could write something remotely close to this.
By most references, VisiCalc was the first killer app since it open the doors to spreadsheets for the average user on a computer. Around the time I was getting into computers (the glorious age of DOS 5.2 of 14.4K baud modems), you could look to archive tools, such as PKZip, as the killer app that allowed people to move large sizes or numbers of files around with minimal hassle. Around this time I also found QModem to be my own killer app, since it allowed me to connect to my local BBS with plenty of custom scripting options [yep, I scripted out my own ZModem downloads before the protocol came standard 8^D].
But on the edge of the social portal I think lies the next, or potentially current, killer app, the API. For those not familiar with term, API is an acronym for Application Programming Interface. In simple terms, it is a programming library that the creator of a program has opened up to allow other programmers to interact with the core of the system, or the data within it. For example, in the process of updating the CCG Toolkit, I chose to create web services to be used as an API to view the Tournament Card Registry data. That way, anybody that knew how to consume a web service (or had a program that did so), could easily get at card data and rulings for their cards.
Firefox became immensely popular due to its plug-in interface, which was made possible by an API that allowed programmers to create nearly any kind of ?widget? that would load with Firefox and allow the end user to do more with their browser. The Flock browser took the best plug-ins it could find and integrated them natively into the browser to enhance the user?s browsing experience.
Twitter is probably the best example of leveraging the API to its advantage. By itself, Twitter is simply a protocol for displaying status updates and passing on other people?s statuses you find interesting. The interface was incredibly simplistic: a web page. You had to various searches if you wanted to check out what else was going on in the ?twitterverse.? That all changed with the release of the Twitter API. Now every programmer under the sun could create a desktop or web based application that did all the fancy searching/sorting/following that you wanted. You could create widgets on top of the Twitter API in order to display your recent status updates, or trending topics on your blog page.
The beauty of this is that Twitter developers themselves only had to focus on the infrastructure and the protocols to be used. They can then let the creativity of developers and the demand of the users dictate which applications bubble to the surface and are used. As a result there are huge amount of twitter clients out there on every platform imaginable. By doing this, usage of Twitter itself has increased without the actual developers of Twitter having to worry about aesthetics, UX, or even platforms specifics, something that has plagued desktop applications for a long time.
Facebook has an API. Various Google Apps (including Calendar and Maps) have APIs. MySpace has an API. My favorite programming site, StackOverflow, has recently released an API and is hosting a contest to see who can build the most awesomeness out of it. I could go on and on.
So while people are getting less and less tied down to a specific platform for their data and day to day interactions (I use a Windows 7 box at home, an iPod Touch while I?m out and about, and have an XP box at work), the killer app has to keep up with this. Since keeping up with the plethora of platforms out there is insane, the killer app has had to take itself one level deeper, to the core of the code itself, or the API. The new killer app is really an API on top of a framework that is going to generate users across any platform somebody is willing to write for, without troubling the original developer at all.
I guess the next question that arises, does the API need to come first for your product, or do you generate the product and use the API to seal the deal?