There’s lots of interesting activity in the platform-play world these days, and all the recent Facebook stuff is a good excuse to talk about it.  Platform strategies have been written about extensively over the years, but it seems like a new gen of web 2.0-style players have gotten the platform bug.  While most web 2.0 strategies include an API component, by platform we mean the extension of a core API/dev offering to include the larger ecosystem of applications, tools, developers, and partners around it.  Here are a few interesting examples (my opinion) of some of the recent platform strategies coming out of what we might loosely call Web 2.0:

• Social networking platforms (Facebook).  This is all over the blogosphere, so let’s just say it’s interesting that they are taking this kind of aggressive position to grow their business as, arguably, a hedge against the obselescence that eventually plagues most pure social network plays.  Acknowledging that a one-stop social network is not a long-term strategy, better to be a provider of social network infrastructure that the more niche networks can leverage as the usage model moves past the “hang with your friends” paradigm and heads down the long tail of community interests.  This is a bold, and impressive, move for Facebook.
• API management & mediation platforms (Mashery).  The offering here is really interesting — as a developer who’s always focused on APIs, the concept is compelling. I’d argue however that the most effective positioning for this kind of an offering at this stage of the industry is in regards to the enterprise.  Enterprises spend a lot of money on software, use big integrators, and deploy lots of fat enterprise packages — huge (usually bloated) J2EE infrastructures, for example.  Though there’s a separate argument around all of that, there is a gap in the market represented by an enterprise’s need to efficiently leverage existing web services from the public web, but not being able to stomach the SLAs that are typically associated with them.  Enterprises can’t afford critical business processes to go down when a web 2.0 API they are using goes down, no matter how cool it is.  If an enterprise had a way to leverage the functionality of all of the great API services that are out there, but could could get enterprise-class SLAs (security and data protection, uptime, supportability, version management, etc.) around them, they would pay for it.  No amount of internal ESB infrastructure, and no amount of external mashup tools like Pipes or CSF-powered NetworkedMashups, will do this on their own.  This is somewhat analogous to the enterprise open source movement — how companies like Cygnus have moved through the world and exemplified, for a different class of services anyway, by things like IBM’s Enterprise Linux strategies.  Take the best stuff from the community and repurpose (wrap) it for the enterprise, and get paid handsomly for that added value. Many others have argued for this as well, and I wonder how this does or doesn’t factor into Mashery’s (and others) view of the world.
• Web application infrastructure services (Amazon).  Not much new to say here, other than that personally I’m an admirer of the fact that they made a risky and forward-looking move in this regard — always exciting to see entrenched players placing bets.  Are the services perfect?  No, but lots of folks are being productive with them.  It will be interesting to see how Amazon’s earnings in this space unfold and how the strategy evolves — lots of folks are looking to them to prove out whether this kind of a model can be profitable in the long-term, even when it’s based on pre-existing core assets. 
• Widget syndication platforms (Clearspring).  Clearspring is still under the radar a bit with their upcoming community offering, so the full strategy is not totally revealed, but there is a tremendous opportunity in managing the deployment and traceability (which seems to be a primary focus of Clearspring’s) of dynamic, micro-application content as delivered into all kinds of container environments.  Widgets is almost a limiting word — the general opportunity space isn’t just web-based widgets but includes dynamic content modules within virtual environments (SL, WoW, etc.), on in-dash automotive systems, on mobile device homescreens, and many more outlets.  While there are players at some level in each of these domains, their unification for the purposes of multi-channel micro-application/content distribution and multi-pronged online campaigns will be the killer.  There is a lot to be gained by whomever can figure this out and come to the table with the compelling toolset and support ecosystem as we move beyond MP3 players and photo viewers, and this seems to be at least some of what Clearspring is up to. 
• Carriers as mobile internet application platforms.  I’ve written about some of this before.  I’m a big believer in the potential for carriers to move in a platform direction, rather than remaining so focused on controlling the handset UE and the associated revenue streams.  There are compelling services carriers can offer to the next generation of mobile web applications (and we’re not just talking about better J2ME APIs and HTTP headers), if they would just get off the pot and start doing some of this stuff.  Parlay/X, SDP, IMS and the rest have got them churning on their own weight rather than focusing on the principles of real platform ecosystems.  There are platform services that developers will pay to access, and we could figure out exactly how much if someone would do some experimentation and give it a shot in an incremental way.  Full openness may not be the right strategy, but without market testing some initial examples the carriers have no choice but to keep doing what they’re doing.  “More of the same” is never a good move for a pressured segment.  I’ve always thought that the MVNO space is where we might see more of this type of thing, and who knows, maybe this is what Google has in mind. 
• The micro platform as Trojan Horse.  In addition to the big plays, there are any number of what I call micro-platforms — extremely focused solutions to extremely focused, and sometimes transient, problems.  A favorite example is addthis.com.  While things like this may not be the drivers of the transformation of the industry, they add substantial value and, without a lot of overhead, build for these companies a real ecosystem.  The smart ones then leverage this ecosystem — not only users and developers but press, investors, advertisers, etc — for expanded solutions over time.  It’s easy to forget, but search as trojan horse, whether it was intended that way at the time, was more or less how Google all got started.  Single-purpose internal platform, single-purpose external platform, multi-purpose external platform, FOG.

Parting thoughts: two great “classic” pieces on platform strategy for your reading pleasure:

• Those Harvard folks on two-sided networks, but you gotta pay for it
• Our old pal Joel Spolsky on platforms, free from the blogosphere