SpectatorBytes

Starting in early 2004 during my tenure at AOL, I with others began to advocate opening up the AOL Instant Messenger (AIM) platform. The goal was to accelerate product development by using third party developers who could work with the open platform. We had seen the valuable ecosystem of third party applications and sites Amazon was creating and thought AIM would benefit greatly from a similar approach. Because of the walled-garden culture upon which AOL had been built, it took a couple of years before we were able to “open” AIM, and when we did it, we may have not open it enough.  While AIM’s remains a strong platform on the Web, its ecosystem of applications does not rival that of Facebook, Twitter or Wordpress. As a result, it has become evident to me that merely “opening” a platform does not automatically lead to success, the degree of openness is just as critical.

Upon my arrival at AOL, several leading technologists in the organization, who shared their thinking with me, identified AIM as one of the company’s most valuable assets. These technology thought leaders referred to it as a “messaging” platform. Messaging in this context did not mean communications, but rather “real-time” transport of data. Sharing files via AIM is a good example of this. Live chat is another one. In addition, AIM’s presence engine was consistently praised and was in high demand by outside parties who wanted access to that capability. At that point, AIM generated revenues via fees from Wireless carriers and advertising, which were in no way commensurate with the reach and scale of the platform. This is what prompted us to explore an “open” strategy. We wanted to further build scale and enable innovative functionality.

As we further explored opening AIM, we identified potential additional uses of the platform. Most of the use-case examples centered on the existing desktop application paradigm. Could we have a radio product developed which could link to the application? Could we use a third party developer to add video chat to the client? Could other applications leverage presence to enhance their services and drive incremental AIM usage? In looking back, while these questions were good, the use-cases we focused on the most involved retaining control over the main mode of consumption (the AIM client) and fostering the creation of services to add value to that client-driven experience. While our focus on user experience seemed reasonable at that time, we may have unintentionally capped the potential value of “opening” the platform by limiting the number of potential use-cases. AIM APIs were not designed to enable 3rd party developers complete freedom to create new user experiences but rather focus them on simply enhancing the existing experience.

Flashforward to today, Twitter embraced a “fully open” approach and has built a strong ecosystem of third party applications in a short period of time. While the value of Twitter and its ecosystem still remains a subject of much debate, one thing has become clear: Twitter has rapidly become one of the leading social media platforms as well as the leading real-time information engine on the Web. Both of these things seem pretty valuable and their open approach has played a key role in making that happen. Third party developers have used Twitter’s open API to develop solutions, which enable a broad set of  use-cases/user experiences,  from sharing links, to uploading videos and photos, to conducting real-time searches, to following categories of individuals, etc.  I venture to guess that many of the use-cases were not initially envision by the Twitter team when they first developed their core product. However, the success of their open efforts has taken them into new areas of functionality and opportunities to create value.

Early this year, it was reported that Jack Dorsey had conceived the idea of Twitter out of fascination with AIM status updates. This led me to consider what would have happened if we had fully opened AIM’s platform and enabled developers to create completely different user experiences leveraging the existing messaging infrastructure. Would AIM have become what Twitter is today? While contemplating this question is interesting, the important lesson is that the power of “open” platforms emanates primarily from enabling the creativity of the external marketplace to create new user experiences and thus new opportunities to capture value. Open platforms allow 3rd parties to finance innovative new products which leverage the existing technology infrastructure and thus foster the creation of rich ecosystems of applications. Eventually, these ecosystems create significant competitive advantage for a product platform as new applications begin to be built on top of other applications.

However, opening a consumer product platform often appears to be risky from a business perspective, especially for entrenched competitors who have fought hard to establish their position and user base. Companies, which fully open their platforms, run the risk of inadvertently giving away too much of their asset value. Thus, managing an open platform requires a clear understanding as to where the ultimately sources of value will be (e.g., data monetization, advertising network opportunity, etc.). One also should keep in mind that revenue opportunities for open platforms take some time to materialize (Think Facebook and Wordpress).

Having said that, the benefits of open platforms are easily seen from a user perspective (after all, more functionality/applications is better than less), and from a product development perspective — where being able to tap third party creativity to discover new user experiences (as we have also seen from the iPhone app store) can add significant value to a platform. Hence, my bias is increasingly towards opening more rather than less.

We are still in the early days of “open” consumer Web platforms and the rules of the road are still taking shape. I will try to codify these rules as I see them emerge.

It would be good to hear where you land on the openness scale.