In an interesting, lenthy blog post, Marc Andreessen takes a look at Internet platforms and APIs:
One of the hottest of hot topics these days is the topic of Internet platforms, or platforms on the Internet. Web services APIs (application programming interfaces), web services protocols like REST and SOAP, the new Facebook platform, Amazon's web services efforts including EC2 and S3, lots of new startups talking platform (including my own company, Ning)... well, "platform" is turning into a central theme of our industry and one that a lot of people want to think about and talk about ... However, the concept of "platform" is also the focus of a swirling vortex of confusion -- lots of platform-related concepts, many of them highly technical, bleeding together. This post is my attempt to disentangle and examine the topic of "Internet platform" in detail. Let's start with a basic definition: A "platform" is a system that can be programmed and therefore customized by outside developers -- users -- and in that way, adapted to countless needs and niches that the platform's original developers could not have possibly contemplated, much less had time to accommodate.
This is followed by a good, more concise definition: "The key term in the definition of platform is 'programmed'. If you can program it, then it's a platform. If you can't, then it's not." Marc then gets into detail by breaking platforms down into three fundamental approaches or levels:
- Level 1: Access API "A Level 1 platform's apps run elsewhere, and call into the platform via a web services API to draw on data and services -- this is how FlickrTrack this API does it." The vast marjority, but not all, of the 515 APIs listed on ProgrammableWeb fall into this category. Marc argues that the issue with these is that "the entire burden of building and running the application itself is left entirely to the developer" requiring both technical expertise and financial resources.
- Level 2: Plug-in API "This is the kind of platform approach that historically has been used in end-user applications to let developers build new functions that can be injected, or "plug in", to the core system and its user interface." Non-Internet examples include Photoshop and Firefox. The best online example of this is hottest "platform" going: the Facebook PlatformTrack this API.
- Level 3: Runtime Environment: "In a Level 3 platform, the huge difference is that the third-party application code actually runs inside the platform -- developer code is uploaded and runs online, inside the core system. For this reason, in casual conversation I refer to Level 3 platforms as 'online platforms'." Examples include Marc's own NingTrack this API and Salesforce.comTrack this API.
There lot's to chew on in Marc's post and the conversation was picked-up by Josh Catone at Read/WriteWeb and VC Fred Wilson. Check-out the lengthy comment stream following Fred's post responding to his question "With providers like Amazon increasingly providing the infrastructure to host, deploy, and scale a web app, and with rapid development tools like Ruby, and with the web as your runtime environment, isn't it possible to do much of what a Level 3 platform provides directly on the web?"