Marc Andreessen recently posted a popular analysis of Internet "Platforms", which categorizes platforms by level into "good", "better", and "best" (levels 1 through 3).  As you might suspect, he ranks his company Ning in the "best" category, while most other social platforms end up in the lowest category and only Facebook lands in the middle category.

Internet platforms are a topic we know something about here (who can forget the "one platform to rule them all" conversation between Tim O'Reilly and Bill Gates at MIX06?)  Unfortunately, I think there are some problems with Marc's analysis.

APIs and Runtimes Are Soooo Retro

Marc hinges his analysis on the idea that platforms are about APIs.  Lowest level is an API, middle level is an API that integrates with the site's UI, and highest is an API that is hosted on the site's infrastructure.  He says, "That's how Dad did it, that's how America does it, and it's worked out pretty well so far."  This is a clear allusion to platforms like Windows, where the platform vendor builds network effects and stickiness by getting developers to adopt proprietary APIs.

The problem with this argument is that everyone has seen the movie already, and they know how it ends.  Lock-in via proprietary APIs might work for narrow enterprise-oriented scenarios, but it doesn't work at Internet scale and diversity.

Data is the New Platform

The Internet works because people integrate at the data level, rather than having a mess of competing and incompatible "APIs".  People like Greg Linden and Sam Ruby understand this.  The stickiness in a Facebook comes from the richness and volume of the data stored in their systems.  Amazon has data about past purchases that can be used to suggest purchases, and EBay has data that helps you decide whether a buyer or seller is trustworthy.  The API doesn't matter, as long as it's simple and the data is good.

Marc nods in this direction by lumping REST architectures into his lowest level of APIs, but he places this at the bottom of the heap, hardly worth mentioning.  This is exactly backward.  The most important and most interesting platform scenarios can all be accomplished using simple web standards techniques for data manipulation -- starting with semantic html and microformats, on to GET and POST, JSON, and then only when absolutely necessary to an RPC pattern.  The rule here is that simpler is better.

When data is the platform, you don't categorize things the way Marc does.  A better categorization would be:

• How big/rich is the data/profile store?
• How sticky is the data?  For example, migrating all of your invoices out of salesforce.com would be impossible without migrating a major portion of your CRM.
• How many easy ways are there to make data flow into the system?  This is where APIs come it, but simpler is better.
• Is the data more valuable when mined in aggregate?  For example, does it help provide better ad targeting?

UX Integration Matters

Again, Marc nods toward important points here, but focuses too much on the technology and makes the point backwards.  He cites the ability to integrate directly with Facebook's UI as a "better" category of integration.  And who wouldn't want to be able to stick their stuff on Google's web page (oh wait, you already can), or integrate with Windows Live Messenger (already can).  But the vast majority of scenarios can already be handled in simple and standard ways (a good name for this pattern might be "syndication oriented architecture").  The web already has an API for extending the web's UI -- it's called HTML+CSS.  A couple of very big fish might be able to get away with proprietary "plug-in APIs", that extend the chrome or but I am skeptical.

Data Locality Matters

Marc defines a level 3, "best" platform as one where your code runs on the same infrastructure as the site.  At first, your reaction might be, "So what? I can get cheap PHP hosting from loads of places".  However, when data is the platform, you often want to be able to run your code as close to the data as possible.  This is why many customers Amazon's S3 needed EC2, for example.  But the fact that you can only run your code on one vendor's infrastructure is an artificial barrier, not a feature.  Some social networking vendors can and do allow people to host their own data and code.  It's obvious what benefit a Ning or Salesforce.com would get from keeping your data and code on their servers; it's less obvious what the benefit to you is.  There are only two real reasons such an arrangement would be a benefit for you

• If your data, aggregated with data from lots of other customers of the provider, can provide some additional intelligence.
• If the provider gets dramatic economies of scale beyond what you could get on your own.  In the case of a Ning or a Salesforce.com, this one is dubious.  There are only a handful of companies who buy electricity and bandwidth in enough volume to offer hosting cheaper than Amazon.  Companies like Yahoo!, Google, and Microsoft.

Summary

I am sure Marc understands all of this.  Data is the true platform, and if he can convince people that there is value in taking dependencies on his UI and infrastructure, it will add to the "stickiness" of his data.  But you have to ask yourself if his levels 2 and 3 really are an improvement for you, and is this really the way the industry will evolve?