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

DISCLAIMER: There has been quite a bit said already about the challenges that convergence (of voice/data, wireless/wired, vendors, user-experiences, device types, etc.) brings to the telco industry, and how various players are, or are not, adapting to these challenges. The smart folks at Unstrung, Gartner, GigaOm, Telco 2.0 and others have thought, and written, long and deeply about these issues. I speak with some purely personal observations.

I’m an Interweb guy that worked for a big-4 US carrier for a few years, and lived to tell about it. I was one of the “Internet people” there, amongst a majority of “telco people”. Back on the other side, and with a keen appreciation for how closely these two domains are tracking toward one another, I am struck again by the vastness of the schism between them. More significantly, though every carrier gives lip service to convergence, IMS, and the need for change, and everyone sees the writing on the wall, the opportunity for a name player in either space to take small but effective steps to rectify telco-land and Techcrunch-land remains on the table.

• The industries speak past one another in a very fundamental way. Telcos are busy hemming and hawing about the future of telcos and professing change, Internet players are busy thinking they don’t need telcos (or at least not any big ones), and meanwhile, the world moves on and consumers wait longer and longer for all those compelling mobile products and services (Twitter doesn’t count). Lots of web 2.0 (etc.) people talk about the dumb pipe, and lots of telco people talk about how you can never do anything more than watch crappy FLV video without real QoS. The real kicker, though, is that with some notable individual exceptions, these people don’t talk, really. The world of the TechCrunch-inspired web-tech blogosphere and the world of telco lunchroom conversation could not be more different. The situation is markedly more positive in Europe, with some carriers doing interesting things and a lot more dialog, but still a disconnect.
• Carriers need to let their smart people go nuts. Contrary to what seems to be popular belief on the Interwebs, there are in fact lots of smart people at carriers. As a technical guy, some of the most amazing engineers I’ve met in my career are to this day sitting in the bowels of these huge behemoths. The problem is just that — they are sitting in the bowels. This certainly isn’t a challenge unique to telcos, but it is acute given the incredible pressure on the carriers to innovate or get left in the dust. Many of these companies, and their vendor ecosystem, need to take drastic steps internally to identify the hot talent and get it to the helm, at all layers. Nothing worse than smart people stuck maintaining legacy systems, spending months fretting over the same vendor architecture diagrams, or trying to make the case for change to deaf ears.
• Incremental deployment models as risk-avoidance strategies. One of the greatest moments in my software career was when I personally realized the strength of really incremental development models (with the help of all the folks who figured it out in the first place). Without getting into specific processes, the fundamental shift from waterfall, big-bang approaches to more incremental agile methods drastically changed my outlook, my productivity, and my understanding of the market and customer landscape. I’ve never seen a carrier, or a vendor at the carrier’s direction, do this. Certainly it’s not appropriate or possible for some of what a carrier builds, but for the domains in which the carriers are competing with internet software companies, this is absolutely critical. Instead, the real-world tendency is to front-load a new product or service project with so much size and cost that the best possible outcome is a substantially de-featured final result. Why bother? This is precisely why carriers cannot take risks at the level that many Internet software companies can — they wind the stack so far up that they lose the ability to adapt to change, customer feedback, testing results, and the rest. This, more than anything else, is death when it comes to adoptable user-level products and services.
• There are legitimate, compelling services that carriers can provide to web-land. Quality of Service, location, presence, user profiling, billing mediation, and more. Data as well as communications services. These are the services the carriers talk up, but their arguments are valid. These are all services that will contribute to the viability of a whole class of new mobile applications. Look at the archetypal mashup, Google Maps and XXX — where the heck is real-time location data in all of these? Why do all the major video distribution sites still show users lame “buffering…10%, 20%” status bars? However…
• It will take carriers changing their perspective on developer platforms to really see these services adopted. I am a big fan of what Amazon has done with S3 and EC2 — they’ve taken an aggressive (and arguably risky) stance to become a platform for a new wave of web (and more) applications. Carriers do have things to be concerned about — the protection of the network from rogue applications, the need to maintain the integrity of emergency services and legendary (sort of) reliability standards. However, these needs don’t preclude a new level of openness in these platforms — smart engineers and architects are certainly capable of putting in place the necessary mechanisms to securely onboard developers and their applications, protect from attacks, shut off miscreant applications, etc. The root cause here isn’t technical, it’s a confused perception of the level of ownership required. You can make money offering infrastructure services to the application layer, and the potential increases with the value of the service.
• Carriers should be trying to court and enable, not out-innovate, the Internet startups. A carrier-built social network? Some crappy home-built UI for a calendaring application? A beat-down version of a popular internet service finally “allowed” to get on the phone? Carriers should engage the ir communities through aggressive developer outreach and evangelism campaigns (like Amazon’s, what Scoble used to do, or even some brightspots like Cingular’s IMS dev contest), and you’ll quickly see what creative people can do with a few feeds, a few web services, and an on-boarding and support mechanism to get to them easily. Want to use the Flickr API? You’re up in 5. Ever tried getting hooked up to a carrier API?

At the end of the day, if this is all going to get better, and if we’re really going to see the next wave of mobile apps, we need to open the dialog. Why is there such a dearth of carrier discussion at all of the web 2.0 conferences (or, better, let’s have some unconferences)? Why is it only a handful of bloggers that hit these topics regularly? (here’s a great one) Why does the majority of the discussion on the future of mobile services from the blogosphere focus so much on the advertising model and on spectrum positions? There are any number of other topics we should be discussing at the community level, in the same way we discuss the virtues of this or that way to distribute music online, or who got how much VC money.

Others have started the dialog, here’s to keeping it rolling!