Marketing Ninja

Yesterday I wrote about history bracing to repeat itself by forcing developers to pick one widget API over another for social networks like LinkedIn, Facebook, MySpace, and others. Facebook is the only platform that has a truly open API for widget developers at the moment, but that hasn’t stopped people from trying to develop third-party content providers for popular social networks.

To summarize what I went over yesterday, with the upcoming release of Google’s API for Orkut and MySpace’s platform, which may or may not be releasing it’s open platform in the coming weeks, third-party application developers now have to weigh their options when deciding what platform to support.

• Do I go with MySpace because it has the largest audience?
• Do I go with Facebook because it has the most developed API and the most buzz?
• Do I go with Orkut because it’s backed by Google, which may mean that it will have the most longterm viability?
• Do I go with LinkedIn because it has the most business users, who are more likely to spend money than the younger audiences on Facebook and MySpace?

Quick factual note: LinkedIn has indeed announced that it’s going to launch it’s own third-party application API, although it’s going to keep out the goofiness of Facebook applications.

The bottom line is: should you trust any single one of these social networks with your business?

Not if you don’t have to.

A quick history lesson. In the early 1990s Professor Douglas Schmidt came up with a radical idea: to develop a framework to encapsulate all of the common low-level business objects in the POSIX and Win32 OS APIs into a common object-oriented wrapper facade.

Professor Schmidt’s idea came to fruition through the development of the Adaptive Communication Envrionment (ACE), which not only encapsulates all of the common OS resources into OO classes (threading, processes, synchronization mechanisms), but also simulates some OS features that aren’t traditionally available on particular operating systems (ACE simulates POSIX condition variables on Windows using the Win32 “event” API). ACE effectively allows developers to build software that can manipulate operating-system level resources in a platform-independent way.

When I had my revelation yesterday after reading Dave McClure’s post about social network monetization, I immediately recognized another application of Schmidt’s wrapper facade concept.

Develop a Web 2.0 Middleware Service – a Common Set of API calls that can be applied to any social network

Why not create an Adaptive Communication Environment for Web 2.0 APIs for social networks? Here’s what this “Web 2.0 Middleware” would do:

• Encapsulate common data objects found on all social networks (Profiles, Friends, etc..) into a handful of robust abstract data types
• Simulate uncommon data objects to add additional functionality for social networks. For instance, develop a Middleware-standard equivalent of the Facebook Newsfeed for MySpace/LinkedIn/Orkut, thus you can effectively extend the utility of existing social networks
• Implement a common data tier which can intelligently differentiate users from each social network; perhaps even allow for cross-network friending and publication.
• Handle all social network authentication processes intelligently without specific instructions from the applications; the application designers would provide their API keys for the respective interfaces and the middleware would be able to rout all of the proper inputs and outputs to and from the corresponding social networks dynamically.
• Invert control away from the third-party application and handle all communications with the social network platforms, return to the application only when that communication has been executed. Inversion of control is a standard property of frameworks.

How would the middleware be implemented? What would it’s interface be like?

Here’s a couple of places to start:

• A good place to start would be to adopt Facebook’s current API as the standard, since there has already been a considerable amount of time and money invested into developing Facebook applications. Why force developers to learn yet another API when we can simply develop our objects around the current defacto standard? This would not only eliminate the initial learning curve to adjust to the middleware, but it would also effectively allow application developers to plug their existing Facebook applications into MySpace & LinkedIn with no refactoring.
• The middleware should only adopt the current Facebook API and not the entire lifecycle of Facebook’s API because to do so would give Facebook an unfair competitive advantage over the other social networks. After the adoption of the current F8 API, the constant growth and expansion of the middleware’s API would be determined solely by the middleware developers and users.

I have a lot of ideas regarding whether the middleware should be developed as a stand-alone client library, but that has its own problems. Unlike ACE which only needed to be programmed in one language, C++, a web 2.0 middleware would need to be able to support the mirth of languages used by web developers. Ruby-on-Rails, PHP, .NET, Java, Python, and lord knows what else.

So the question would be then how would you develop a multi-platform solution that can handle all of these different languages, server configurations, and operating systems without needing to be rewritten in each and every supported language?

I do not have a certain answer to that question. That’s the real engineering challenge behind this concept. Personally, I’d just develop the middleware as a proxy web service, build a business around allowing application developers to use it, and charge app developers a premium on bandwidth once they go beyond a marginal amount of usage.

On that note, have a good weekend. Time to try out my new 22′ monitor with some Team Fortress Classic 2.

Edit: If there’s any resonant interest I’ll write another post covering some of the obvious problems this middleware approach would have, like the instability of the underlying platforms, and some more business/software modeling ideas. Leave a comment or shoot me an email via the contact form.

If you enjoyed this post, make sure you subscribe to my RSS feed!