Page 2 of 3   « previous page   next page »

Of course, substantially ignoring community requirements, especially those with wide support, is also a mistake. Aside from the fact that doing so will damage credibility with the community, one has to ask if there isn't a grain of truth in the collective knowledge of the community.

The same follows for “downstream” activities like usability reviews. Open source users are not shy about voicing usability opinions. Let's follow this line of reasoning a bit to see where it leads. If you are developing open source software and intend to use it in a commercial product, it makes sense that users of the open source software have something relevant to say about the usability for a portion of your commercial product (note that here we are talking about user tools, not frameworks). In effect, then, you are getting free usability reviews from people who are probably at least reasonable approximations of your commercial end users. Given the iterative nature of open source and the fact that is it developed in the public view, such early feedback can be very useful to avoid costly design flaws typically found during beta cycles.

Platforms for Action
While certainly not all (or perhaps even most) open source makes the distinction, Eclipse projects, and hence DTP, very self-consciously have both platform and tooling components. The politically correct way of phrasing this for Eclipse Foundation projects is “extensible frameworks and exemplary tools.” By Eclipse Foundation standards, the frameworks (or platform) are expected to be vendor-neutral and open to easy extension, using both standard Java (object-oriented) mechanisms and Eclipse-specific mechanisms such as extension points. Thus, an Eclipse project serves two masters: those who want to build on it as a platform (typically called “extenders” or more confusingly “adopters”) and those who wish to use the tools for standard tasks (typically called “end users”).

The dynamics of end user interactions are familiar to most, since companies contributing to Eclipse are typically also delivering commercial software to their customers. The landscape is generally familiar to the companies and their employees participating in such projects and complicated only by the consideration of how much tooling to put into open source – end users want more, while companies want to charge based on a product.

This is hardly the case for the platform aspect. The dynamics of platform ecosystems are more complex than those of tools. Building on the work of Rochet and Tirole [11], Evans and Schmalensee [4] and Evans, Hagiu and Schmalensee [5] distinguish the single-sided (or one-sided) and two-sided (or multi-sided) business. A single-sided business caters only to one customer type for a product developed, whereas a two-sided business caters to two types of customers for a product.

Crucially, in a two-sided business, there is a systemic interdependence between the sides, resulting in the need for success on both sides and a subtle interplay of cause/effect relationships in the system. A great example of a two-sided business is the newspaper:

Consider the newspaper. Like one-sided business, it has a supply chain. It has to buy paper, for example, and it must have distributors. But unlike a linear business, it faces two sets of customers who are quite different from one another. One the one side, it faces advertisers, who care about the number and type of readers who view their ads. On the other side, it faces readers, who mainly care about articles about news, sports, arts, and other features. The newspaper provides a services to both of these customers and charges them for it.

The newspaper's success depends less on wringing the last penny out of its supply chain and more on nurturing the community of advertisers and readers. It must consider the interdependence of these two groups of customers at every turn.

– Evans and Schmalensee [4], p.13-14. (italics added)

Likewise, a software platform, such as those delivered in Eclipse Foundation projects, is a two-sided business. The platform needs to attract and balance both extenders, who are building on the platform, and end users who use the platform. If there is not a critical mass of interesting extensions for a given platform, the end user community will not grow. If there is not a sufficiently appealing end-user community, potential extenders will not adopt the platform. Hence, we have a deep and fundamental interdependence between these two groups that is not present in the tooling case. Although the relationship is circular, it is not an impossible situation: there are ways to build and nurture platform ecosystems, and Evans and Schmalensee [4], Evans, Hagiu and Schmalensee [5], Gawer and Cusumano [6] describe them.

There are two key points here. First, as demonstrated in the literature cited, platforms can be a powerful way of driving business. Second, nurturing platforms requires a very different understanding and strategy than that for tools. The distinction between one- and two-sided businesses is not commonly understood yet; therefore, organizations that do understand and leverage these concepts can have an advantage in platform development.

Innovation in Open Source?
Recently there has been much interest in leveraging the user community for early identification of innovation opportunities. From a theoretical perspective, Von Hippel's recent work [13] has been widely cited. Von Hippel proposes “lead users” who form a category willing to experiment with and extend products offered. He also details a number of cases where companies have been able to leverage the work of these lead users for early identification of innovation opportunities and market direction. On the applied side, Seybold [12] advances the notion of “co-design” between companies and customers based on her consulting firms' long experience in the field.

Page 2 of 3   « previous page   next page »