Platforms-as-a-Me Too

From ReadWriteWeb, reporting on the Web 2.0 Expo (aka PlebWeb ) on the sudden popularity of Platforms:

The most interesting replies to the question - "what comes next after APIs become ubiquitous?" can be summarized as follows:

Business models
Filtering for information overload
Standards and interoperability
Outsourcing API services
Backlash

They go on to talk about all these areas, and desire some user feedback in the comments - but this is a meaty area and deserves a blog post on its own. (RWW paragraph is indented quote below, our response is normal format)

Business models

Perhaps inspired by a touch of cynicism, many of the people we talked to said that finding business models was the next frontier for an API enabled web.

Nick Gonzales of ad network Social Media said that the early rush to build apps on the Facebook platform should be considered the exception more than the rule. He says it was remarkably easy to build apps on that platform but that hasn't helped developers make money outside of Facebook

One of the issues being that to re-engineer something built on Facebook API's for general web usage is non-trivial. But the overall business model point is well made, especially in the light of Google essentially offsetting costs for SoHo companies on its newly announced platform (using Ad sales to pay for it) which creates major barriers to entry for new players. In essence does this mean that a low-end platform is only really affordable by people who have some form of offset going, via VC funding or other revenue buckets?


Filtering for information overload

It's one thing to smash together different streams of data, but making sure the results are user friendly is another matter. Many people we talked to said they wanted APIs and platforms to increase their capacity for determining relevance.

We think this really is one of the key areas - the "River of Data" so beloved of Web 2.0 pundits is usually a Sewer of Crap in practice, and sifting out the signal from the noises off - the repeats, me-toos, irrelevancies etc - is in our view one of the major requirement on the Information Superhighway now.


Standards and Interoperability

The most obvious answer to this question as far as we're concerned is that the next step is to make ubiquitous APIs standards-based and able to work together.....

.....Florida venture capitalist Dan Rua puts it this way: "after ubiquitous APIs comes category subsystems/adapters, allowing for write once, run with any similar service type abstraction."

Sadly the optimal game theory for any major player is to "defect" and try to establish its approach as the De facto standard - but of course if they all do that, the game is a stalemate and everyone loses. There also seems to be a similar gig with "Voluntary bodies", in that there seems to be more than one competing standards body (or at least overlapping ones) in quite a few standards spaces as well.


Outsourcing API services

We hear whispers about a number of beyond-stealth startups, too, that are aimed at solving the scalability problems faced by some of the most popular APIs on the web. That's not at all a dry matter - commoditization of solutions to the biggest technical bottlenecks in making APIs work would open up a whole new world of possibilities.

Now this is an interesting area, and brings up the impact of the Interspersed Web - where applications are split into much smaller applets, widgets and whatever - and the network becomes the platform, binding them together with a layer of Transcation Messaging. We have done quite a bit of client work on this area recently, and look forward to seeing some interesting new approaches emerge from the shadows.

And to say this is fertile soil for m2m is putting it mildly......


Backlash

We heard this from some people we really didn't expect it from. David Janes, creator of a sophisticated lifestreaming app for groups called Onaswarm summarized his feelings thusly: "How about a return to using well-known protocols (as opposed to APIs) for doing well-understood tasks, i.e. publishing and posting data. E.g. RSS/MetaweblogAPI or Atom/APP...It's insane...I've had more than my fill of working with these APIs." When I pinged him to confirm those lines - he said that it would more accurately explain how he felt about the APIs he's been working with if there were some obscenities sprinkled into his quote. That from a man who has put his hand into the dragon's mouth. If you will.

Similar sentiments were expressed by Len Kirby, engineering director at Flock. Flock is a social browser that brings together a large number of social data streams and functionality from all around the web. None the less, Kirby is no fanboy of the latest wave of APIs and platforms.

He told us that he thinks the next step in fact may be going back to predictability based on finished standards; as opposed to the half-baked protocols of industry luminaries that didn't finish developing proposed standards. Tempering his vitriol just a touch, this manager at a company built on Mozilla technology also shared some sympathy. "Just like any visionaries there's only so much time to make things real and [for example, coming out of] Mozila and RDF there's been a lot of very good things - but time to market rules." Kirby made sure to affirm as well that Flock really does love Mozilla.

This just goes back to the point we made above re standards - too many sub-standard approaches to creating standards are messing things up for standardising standards.


Problem - what Problem?

That said, you won't likely hear any of those voices blogging here at ReadWriteWeb! We think that today's crush of APIs and platforms is just the beginning, that we're at a turning point of innovation. We love it and intend to chronicle the next steps as best we can.

So which quadrant does this put RWW in, in the Broadsight BlogTone 2x2