When the Facebook platform debuted last year it was touted as the next big thing. Media, VC, startups and big companies shared the enthusiasm for its future. And no wonder: Facebook enabled access to 50 million users. You no longer needed to bring the audience to your app. Instead your app could be delivered to one of the largest audiences around the web. And not just delivered, but injected into a massive social network.

While it started great, it turns out things are not that simple. Three fundamental issues surfaced:

  1. Technical: Should the app be just a teaser that leads users to their site or should it be a duplicate and have full functionality?
  2. Business: If e.g. New York Times builds a Facebook app, will it be economic for them (since there's little revenue in Facebook)?
  3. Provider costs: Does it pay for Facebook to maintain the platform? As a business with a huge valuation, Facebook needs to maximise profit.

With these issues out in the open for the last year, the platform is suddenly not so compelling. How could this great idea go wrong?

The Technology Behind the Platform is Solid

There is little doubt Facebook's platform is revolutionary. Overnight it opened access to a massive audience. Big companies and startups just needed to write an app, submit it to the gallery and they have access.

From the development view the platform is good. Sure there are quirks, but people can build apps. Security and scaleability are wired into its core and there are APIs and libraries in popular languages.

Teasers vs. Native Apps

Right now there are two types of Facebook applications: teasers and native apps. A teaser exposes partial functions of the application and offers users a click to leave Facebook to go to another site. Native apps are developed to run on Facebook.

The problem is, any existing site wants to build a teaser application. Most sites make money on ads and they have existing ad infrastructure in place and all they need is traffic. This is a product management nightmare because it isn't clear what info should be exposed. And the user experience is bad because users dislike jumping between Facebook and other sites.

Some companies built copies of their apps that live entirely on Facebook and mimic the functionality of the real one. This solution creates both engineering and marketing problems. Maintaining a duplicate code base is costly, and messaging users to come to the website or Facebook page is confusing. And the issue of monetization on Facebook remains.

The applications that live only on Facebook are clear winners. These are custom-designed for the platform.

Show Me The Money

Unlike Apple, Facebook did not build an infrastructure for paid applications. The only way to monetize the apps is via advertising. Yet social networks aren't natural for targeted ads. Certainly ads are served in pages, but their effectiveness has still to be determined .

Specifically, if talking about a large news site like New York Times, there's no way it can match its native ads on Facebook. New York Times sells high-CPM ads and has polished its targeting mechanism. Plain Facebook ads can't match that.

An app is free to serve more ads on its own Facebook pages, but then the reader will be seeing two types of ads and the ratio of ads to content becomes unbearable.

It would be an advance if Facebook would enable companies to plug in their own ads into the sidebar areas, but currently there's no such infrastrucure. We're not seeing clear and comparable monetization on Facebook as it exists on original sites.

The User Problem

Out of thousands of applications, only a handful gain sizable audience. Whose fault is this? Again this isn't a simple issue. How many apps can a user want? The apps that win audiences initially get progressively bigger, making it harder for new apps. Because there's no pay-to-play, there's a lot of noise.

Users have too much choice. What seems like a great idea (let users choose the apps) quickly leads to this: users try a few apps and conclude that apps aren't interesting. Users are confused with the amount of choice.

What's the solution? Not really clear, but the current situation can't last much longer.

Platforms Are About Risk Management

With the platform not working out well for either Facebook or its users, the company is taking action. The changes are aimed at simplification and toning down the apps.

At this point it will be a welcome change for the users, but application makers will feel screwed just a year after the fanfare and all the money spent on building the apps. Providers have done nothing but good for this platform, making things work quickly.

Platforms, Web Services and APIs are not just money makers. Platforms come with responsibility. Amid the never-ending marketing war, the rush and pressure tends to push out stuff that's half-baked.

Perhaps it's time to take a lesson from the 90s. Back then, when companies bought libraries from software vendors, these came with commitment. Solutions were customer-driven because people paid to use them. Vendors worked hard to make things backwards compatible. Platform providers understood and respected the risk people took relying on their systems, and they assumed responsibility because they were paid.

Perhaps if Facebook charged for access to its audience, things would be more businesslike. Once again, free comes back full circle and backfires.

Conclusion

The Facebook platform was certainly a big event in technology. As the first open system to enable access to a huge audience, it's a triumph. But its future is clouded because of its business infrastructure, improper user education, and almost anarchic delivery of the applications. With the imminent changes, larger players will have even less incentive to plug in.

Only time will tell what it means for the futrure of the platform. Hopefully Facebook leadership will find the right path.