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.
Subscribe to Linux Email News Alerts
Subscribe via RSS
