February 2013 Download this article as a PDFAbstract

Technology entrepreneurs are increasingly building businesses that are deliberately anchored in platforms, communities, and business ecosystems. Nonetheless, actionable, evidence-based advice for technology entrepreneurs is scarce. Platforms, communities, and ecosystems are active areas of management research, but until recently, each has been studied in separate research programs, with results published in different venues, and often examined from the perspectives of incumbent managers or policy makers rather than entrepreneurs and new entrants.

This article re-examines these phenomena from the perspective of technology entrepreneurs facing strategic choices about interconnected systems of platforms, communities, and business ecosystems, and decisions about the nature and extent of participation. It brings together insights from a wide range of published sources. For entrepreneurs, it provides an accessible introduction to what can be a complex topic, identifies a set of practical considerations to be accounted for in decision-making, and offers a guide for further reading. For researchers and graduate students seeking practical and high-impact research problems, it provides an entry point to the research literature and identifies gaps in the current body of knowledge, especially regarding the system-level interactions between subsystems.

Introduction

Technology entrepreneurs in the global information economy share at least three common challenges. First, with limited resources, confronting all of the well-known liabilities of attempting something new, success often depends on access to specialized knowledge and resources that lie outside the entrepreneur's ownership or control. In a hypercompetitive environment, buying or building may not be attractive or even viable options. Second, success often critically depends on the innovations and actions of others who complement the entrepreneur's offer. Prior experience with the customer and supplier relationships of a traditional supply chain is inadequate preparation for the challenges of managing complementors. Third, these critical assets and complementors – as well as suppliers, customers, and competitors – can be located anywhere in the world. The environments in which technology entrepreneurs operate are at once global and densely interconnected.

Platforms, communities, and business ecosystems can provide partial remedies to these and other problems. By building products and services on platform assets developed by others, a technology entrepreneur can focus R&D effort on building differentiating capability. By engaging communities of passionate people, a technology entrepreneur can learn more effectively about individual wants and needs, benefit from user innovations, and channel the creative energy of the community towards useful endeavours. By operating a business within a networked ecosystem of interdependent and codependent businesses with partially aligned incentives, a technology entrepreneur can achieve more, learn faster, and reach farther than otherwise possible, while sharing some of the risks and costs with others.

Fortunately, we know quite a bit about each of these systems and are learning more every day. There are growing bodies of knowledge about platform architecture and business strategy, community innovation and the design and management of communities, and the dynamics and strategies of business ecosystems. Unfortunately, technology entrepreneurs are not benefiting from this knowledge as much as they could be. There are several reasons for this. First, much of what is written addresses one of these systems only – either platforms, communities, or ecosystems – but the real-world systems of interest to technology entrepreneurs often come bundled together with multiple parts: community-developed platforms, business ecosystems anchored around shared platforms, and user communities that complement the market offers of a business ecosystem. In fact, all three systems are commonly bound together as one larger system. For example, an entrepreneur who decides to develop a software product or service on the Eclipse platform of software tools and development frameworks is also choosing to couple their outcomes with the Eclipse developer community that maintains and extends the Eclipse platform (Smith and Milinkovich, 2007; Skerrett, 2008), and the Eclipse ecosystem of companies that produce complementary products and services and employ many of the software developers in the Eclipse community (Milinkovich, 2008; Muegge, 2011). Similarly, neither a mobile application developer nor a provider of an online service are choosing “just” a platform or community or ecosystem, but rather a bundled system that includes instances of all three subsystem types. The research and practitioner literature rarely considers these systems together or attends closely to their interactions. (A few recent important exceptions are discussed later). Second, the knowledge is scattered in many places – practitioner books, specialized scholarly books, book chapters, journal articles, and other online sources – and it is time-consuming and effort-intensive to assemble these pieces together, transform this incomplete mosaic into actionable knowledge, and to stay current with ongoing developments. Third, the perspective taken in the literature is typically not that of an entrepreneur but rather some other stakeholder. The concerns of the established platform leader (Gawer and Cusumano, 2002; 2008), the community designer (Bacon, 2009; Kraut and Resnick, 2011), or the ecosystem keystone company (Iansiti and Levien, 2004a; 2004b) may be quite different from those of the resource-limited entrepreneur facing a constrained choice of which existing systems to align themselves with.

This article aims to address all three obstacles by bringing together insights from these disparate sources and presenting their prescriptive implications in a form that is both comprehensible and useful to technology entrepreneurs. The perspective is that of the technology entrepreneur, facing choices about interconnected systems of platforms, communities, and business ecosystems, and the decisions of whether or not to participate in an existing system, and the nature and extent of participation.

The body of this article is structured in five sections. The first section develops the conceptual argument that platforms, communities, and business ecosystems can be understood as different levels of analysis in a complex multilevel hierarchical system, and that architecture is the unifying concept that links the three levels. It begins from Tim O'Reilly's assertion that systems designed with the right architectural characteristics – what he calls an architecture of participation – are more likely to attract contributions from others. The second, third, and fourth sections each examine one of the three system levels: platforms, communities, and business ecosystems, respectively. Each of these sections provides a brief and selective review of research that is salient to the perspective of the technology entrepreneur, highlighting contributions published in the TIM Review. The fifth section presents a compilation of the collective “lessons learned” for technology entrepreneurs. A full synthesis of the platforms, communities, and business ecosystems literatures is beyond the scope of this article, but the results thus far are nonetheless instructive. A final section concludes with a call to researchers and new graduate students to continue and extend this line of enquiry.

Architecture

Table 1 provides definitions of platform, community, and business ecosystem as organizational forms that structure different levels of organization in an interconnected world. According to this view, a platform is a particular organization of things (technologies and complementary assets), a community is an organization of people, and a business ecosystem is an organization of economic actors. Each co-exists with familiar traditional forms at the same level of organization: for example, proprietary products and services as systems of things, companies, government groups, and not-for-profits as organizations of people, and industries and industrial organizations as structures of economic actors. In previous decades, as described by Chandler (1962) and Porter (1980) and others, these traditional forms were dominant: companies developed proprietary products and services through closed internal R&D processes, and competed within industries of similar companies developing substitute products and services. In today's interconnected world, platforms, communities, and business ecosystems are viable ways of organizing that co-exist with rather than replace these traditional forms.

Table 1. An architecture at three levels*

Level of Organization
(Type of Actor)

Organizational Forms in an
Interconnected System

Traditional Organizational Forms at the Same Level of Organization

Organization of economic actors

Business ecosystem: a field of economic actors whose individual business activities, anchored around a platform, share in some large measure the outcome of the whole ecosystem.

- Industrial organization

Organization of people

Community: a voluntary group of people with common interests and a similar sense of identity. Communities can take many different forms. Two are particularly relevant here:

  1. Developer community: a community of people, organized as a meritocracy, who collectively maintain and extend a platform
  2. User community: a community of people who use and consume a platform or the products, technologies, and services built on a platform

- Firm (in the strategy and economics literature) or an organization (in the management and human resources literature) – a privately-held or publicly traded business

- Government organization

- Not-for-profit organization

Organization of things

Platform: a set of technological building blocks and complementary assets that companies and individuals can use and consume to develop complementary products, technologies, and services.

- Integral (non-modular) product or service

- The outcome of a closed innovation R&D process

*These definitions closely follow those of Muegge (2011), which are adapted from various sources cited in this article and my own research with practitioners.

 

In engineering design, architecture refers to a high-level design of the over-all way in which the major components of a system fit together. System architecture is important in engineering design for several reasons: it may be technically difficult to accomplish and requires a broad skill set, it often determines (or places upper bounds on) systems performance and (lower bounds on) cost, and it may be difficult (or impossible) to change later thus imposing path dependence. More recently, the notion of architecture has been applied more broadly to subsume what has been called organizational structure when referring to systems of people and industrial organization when referring to systems of economic actors. Various practitioners and researchers have independently observed that the structures at these levels of organization are deeply connected.

Publicist Tim O'Reilly coined the expression “architecture of participation” to describe “the nature of systems that are designed for user contribution” and introduced it in a series of talks, essays and blog posts (e.g., O'Reilly, 2004; 2005). Within such systems, users pursuing their own selfish interest build collective value as an automatic byproduct, and systems get better the more people use them. Management researchers have described O'Reilly's writing as a collection of heuristics – experience-based techniques for problem solving and design that may be effective much of the time. Box 1 provides a summary of some specific practitioner heuristics found in O'Reilly's writing.

Box 1. Architecture of participation heuristics

A close reading of O'Reilly's essays, articles and presentations, and blog posts at the O'Reilly Media websites published between 2006 and 2008 identified 13 architecture of participation heuristics. Some may be generally applicable to many systems; others are specialized to particular contexts.

  1. Small modular applications.
  2. Well-defined application interfaces, minimally specified, that place few constraints on interoperability with other applications.
  3. Transparency of design: the internal design of the system is open to be examined.
  4. A small core and well-defined extension mechanism, also described as a tightly-controlled cathedral surrounded by an open bazaar.
  5. Rival ideas and solutions compete with one another in a free market for ideas.
  6. Low barriers to entry for new users.
  7. Contributions from outside the community are welcomed, and outside contributions compete on a level playing field with contributions from within the community.
  8. User value, as assessed by users, is the criterion for selecting one solution rather than a different one.
  9. Users have the credible capability to fork the project, providing strong incentives for developers to be responsive to users.
  10. Participation is automatic; contribution is the default behaviour of using the system, and no extra effort is required to contribute.
  11. Users trust the system.
  12. Dial-tone: users can do something themselves that previously required a professional operator, analogous to direct-dialling a telephone call rather than placing a call with the assistance of an operator.
  13. Value is extracted from what users already do without requiring behaviour change.

Management researchers have made some progress towards placing these practitioner arguments and heuristics on a theoretical foundation. Architectural modularity features prominently in the design rule theory of Baldwin and Clark (2000), linking the microstructure of designs, organizations, and industry structures deep “in the very nature of things”. Modularity in design alters the mechanisms by which designs can change. This enables design evolution – a value-seeking process with strong parallels to biological and ecological processes – and links the architecture of systems of things, people, and economic actors in an interconnected multilevel complex adaptive system. The design rules at each level are reflected in the design rules of the other two levels. Modularity simultaneously multiplies and decentralizes design options (Baldwin and Clark, 2000):

“The multiplication occurs because changes in one module become independent of changes in other modules. Decentralization follows because, as long as designers adhere to the design rules, they are free to innovate [independently] without reference to the original architects or any central planners of the design.”

The context in which designs and design processes are lodged operates on designs “like a force” (Baldwin and Clark, 2000):

“In particular, economies with capital markets offer large, direct rewards to value-creating enterprises, and commensurately large incentives for human beings to cooperate for the purpose of creating economic value… Metaphorically, they ‘pull’ designs in the ‘direction’ of higher market value.”

The specifiable, verifiable, and predictable interfaces between technology building blocks determine the efficient placement of firm boundaries (Christensen et al., 2001; Christensen and Raynor, 2003) – whether firms can viably specialize on providing a component of a larger system or must integrate over a larger system to be operationally effective (Langlois and Robertson, 1992; Sanchez and Mahony, 1996). A business ecosystem of modular specialized firms becomes a viable industry structure around a modular platform.

Platforms

Platforms are typically subject to positive feedback loops through network effects in use (Katz and Shapiro, 1985) and increasing returns in supply (Arthur, 1994; 1996) that tend to amplify early advantage: the more people who use platform products, the more incentives there are for complementors to introduce more complementary products (Cusumano and Gawer, 2002). Gawer (2009a) writes: “Platforms that make it past a certain tipping point tend to become really hard to dislodge. In a sense, as platforms' market share grows, so also grow their own barrier to entry.”

An early body of work in platform strategy examined platform leadership, defined by Cusumano and Gawer (2002) as the ability of a company to drive innovation around a particular platform technology at the broad industry level. In this view, platform leaders are “companies that drive industry-wide innovation for an evolving system of separately developed pieces of technology”. Complementors (Brandenburger and Nalebuff, 1996) are companies that make ancillary products that expand the platform’s market. Some companies occupy multiple roles; for example, Intel and Microsoft are both platform leaders and complementors. Platform leaders employ the four levers of platform leadership to maintain and extend a leadership position (Gawer and Cusumano, 2002; 2012): i) scope (decisions of which complements to make in-house and which to deliberately leave to other companies; convey a vision of the larger system); ii) product technology (decisions of modularity, interfaces, and how much information to disclose; build the right architecture and connections); iii) relationships with external complementors (decisions around consensus and control, cooperation and competition, and handling potential conflicts of interest; build a coalition for co-creation); and iv) internal organization (co-evolve the platform while maintaining a central position). Platform leaders face three types of problems (Cusumano and Gawer, 2002): i) how to maintain the integrity of the platform in the face of future technological innovation and the actions of other companies; ii) how to let the platform evolve while maintaining compatibility with past complements; and iii) how to maintain platform leadership.

A smaller literature examines the strategies for platform complementors. Cusumano and Gawer (2002) offer five managerial prescriptions for platform complementors: i) focus on products that the platform leader is unlikely to offer; ii) be aware that changes occur rapidly, thus work on continuous communication, seek early information, and pay attention to actions of the platform leader; iii) react quickly to demands of the platform leader (to provide no provocation or incentives for the platform leader to become a direct competitor); iv) create products that enhance the value of the core product (thus benefiting the platform leader); and v) work with groups inside the platform company that are likely to offer the most neutral stance to promote the platform (rather than groups that would perceive the complementor as a threat). Weiss and Gangadharan (2010) examine the platform strategies of complementors providing software mashups and mashable components.

Because all platforms require complementary innovations to be useful, no platform is fully under the control of its originator (Gawer and Cusumano, 2008). Nonetheless, some platforms are more tightly controlled than others. West (2003) reflects on the tension between appropriability and adoption evident in the “hybrid” platform strategies of Apple, IBM, and Sun Microsystems:

“To recoup the costs of developing a platform, its sponsor must be able to appropriate for itself some portion of the economic benefits of that platform. But to obtain any returns at all, the sponsor must get the platform adopted, which requires sharing the economic returns with buyers and other members of the value chain. The proprietary and open source strategies correspond to the two extremes of this trade-off. In making a platform strategy for the 21st century, leading computer vendors face a dilemma of how much is open enough to attract enough buyers while retaining adequate returns.”

Selecting the level of platform openness is a crucial decision for firms that create and maintain platforms (Eisenmann et al., 2009). Opening a platform can spur adoption by harnessing network effects, reducing users' concerns about lock-in, and stimulating production of differentiated goods that meet the needs of user segments. At the same time, opening a platform typically reduces users' switching costs and increases competition among platform providers, making it more difficult for them to appropriate rents from the platform. Schilling (2009) identifies three dilemmas facing firms that liberally diffuse technology to would-be competitors: i) they relinquish the opportunity to capture monopoly rents when and if their technology emerges as a dominant design; ii) once relinquished, control can be very hard to regain; and iii) potential for fragmentation of the technology platform. In the computer industry, movement towards open platforms was driven by an increasingly competitive business environment and the pragmatic pursuit of profits (West, 2003).

Baldwin and Clark (2006) argue that the architecture of a software code base is a critical factor that lies at the heart of the open source development process. Drawing on their previous work on design rules, they argue that designs have option-value because a new design creates the right but not the obligation to adopt it. A modular design allows for experimentation and changes within modules without disturbing the functionality of the whole system. The authors then use a series of increasingly sophisticated game-theory models of developer behaviour to show that increased modularity (and thus increased option value) has two effects on the software development process. First, it increases the incentives of developers to get involved and remain involved in the development process. Second, it decreases the amount of free riding in the equilibrium – that is, using with contributing. Both effects promote growth of the developer community, suggesting that modular design is important to the success of open source development projects. Evidence from empirical studies of software platforms supports a deep and positive connection between modularity and design evolution (MacCormack et al., 2001; MacCormack et al., 2006; LaMantia et al., 2008).

Platform contributions published in the TIM Review have included Muegge and Milev (2009) on measures of modularity, the May 2010 issue on platforms for communication-enabled applications (CEA), Poole (2010) on open government platforms as an engine of economic development, and Noori and Weiss (2013) on the strategies of platform owners to manage complements.

Communities

“Community” is a term with many different meanings. In a broad survey of the research on community, West and Lakhani (2008) observe:

“a welter of overlapping literatures and terms: innovation communities, knowledge producing communities, online communities, scientific communities, technical communities, user communities, virtual communities, or communities of practice. That doesn't even include the disparate uses of 'community' in sociology, where ... some 100 different definitions have been used.”

For the purposes of this article and the definition provided in Table 1, community membership is comprised exclusively of individual people; community members may also be members of other organizations, but those organizations are outside the community. Bacon (2009) associates community with a shared core belief, a sense of belonging, a collection of shared processes, and a social economy whose currency is social capital rather than financial capital: “At the heart of how this movement works is communication”. Community membership is always voluntary: new members can join, and existing members can exit.

Within the vast research literature on communities, two particularly salient streams are community innovation and open source software communities. The first stream examines how communities outside the boundaries of firms often play a role in creating, shaping, and disseminating technological and social innovations and providing valuable support to others. Eric von Hippel's research on user innovation (von Hippel, 1988; 2001; 2005) and Henry Chesbrough's research on open innovation (Chesbrough, 2003; Chesbrough and Appleyard, 2007) both feature prominently. Boudreau and Lakhani (2009) examine the circumstances under which companies should organize outside innovation as collaborative communities rather than competitive markets. Baldwin and von Hippel (2011) examine the circumstances favouring single-user innovation and community-user innovation over producer innovation.

The second salient community stream is open source software and the communities of developers and users that form around successful open source software projects. West and O'Mahony (2008) examined the communities surrounding 12 open source projects initiated by corporate sponsors and a comparison group of five projects originating from autonomous communities. According to West and O'Mahony (2008), sponsors consider three design dimensions that together create a specific participation architecture: i) production (they way that the community conducts production processes); ii) governance (the processes by which decisions are made within the community); and iii) intellectual property rights (the allocation of rights to use the community’s output). The authors distinguished between two dimensions of openness: transparency (allowing outsiders to follow and understand a community’s production efforts) and accessibility (allowing external participants to influence the community’s production efforts). Projects with more transparent and accessible production, governance, and intellectual property were more likely to attract external participants and to grow communities.

Two recent books have proposed sets of constructive design propositions for communities. Kraut and Resnick (2011) apply theories from psychology, economics, and the broader social sciences to propose a set of evidence-based design claims for building successful online communities. Schweik and English (2012) reflect on the results of a five-year multimethod research program, including quantitative tests of more than 40 hypotheses with large sample datasets of projects and individuals, to propose a set of actionable design principles for sustainable community-developed software projects. Box 2 provides examples of design propositions from both sources.

Box 2. Community design propositions

Two recent books have proposed sets of community design propositions.

Kraut and Resnick (2011) proposed a set of design claims for building online communities. Design claims are a device to translate theory to design alternatives that achieve community goals. They can be non-comparative (Alternative X helps/hinders achievement of goal Y under conditions Z) or comparative (Alternative X1 is more effective than X2 at achieving goal Y under conditions Z). The claims are organized into five design challenges: i) starting a new community, ii) attracting and socializing new members, iii) encouraging commitment, iv) encouraging contribution, and v) regulating misbehaviour and conflict. The first three of 35 claims for encouraging contribution are provided here as examples (ch. 2, pp. 26-27):

  1. Making the list of needed contributions easily visible increases the likelihood that the community will provide them.
  2. Providing easy-to-use tools for finding and tracking work that needs to be done increases the amount that gets done.
  3. Compared to asking people at random, asking people to perform tasks that interest them and that they are able to perform increases contributions.

Schweik and English (2012) proposed a set of 13 prioritized design principles for sustainable community-developed open source software projects. The first two recommendations at the initiation stage (before first release) are provided here as examples (ch. 13, p. 304):

  1. Put in the hours. Work hard toward your first release.
  2. Practice leadership by administering your project well, and thinking through and articulating your vision as well as your goals for the project. Demonstrate your leadership through the hard work noted just above, and by working toward the vision and goals you have established for the project.

Community contributions published in the TIM Review have included Smith and Milinkovich (2007) on the Eclipse community, Skerrett (2008; 2009; 2011) on open source software communities, and Weiss (2011a) on control and diversity.

Business Ecosystems

Moore (1993) introduced the term “business ecosystem” into popular management parlance in a McKinsey Award-winning article in Harvard Business Review. Moore argued for an ecological approach to management, where the modern business is viewed not a member of single industry, but rather part of a business ecosystem that crosses a variety of industries. A follow-up book (Moore, 1996) described the business ecosystem as “an economic community supported by a foundation of interacting organizations and individuals – the organisms of the business world”. The ecosystem includes customers, suppliers, competitors, and other stakeholders, who “coevolve their capabilities and roles, and tend to align themselves with the directions set by one or more central companies”. Moore (2006) argued that business ecosystems are a distinct organizational form – a mode of organizing economic production that differs from markets and the organizational hierarchies of firms. Alternatively, a business ecosystem can also be understood as a network of specialized and complementary opportunity niches – both known and yet to be discovered.

Later scholars further developed these ideas. Iansiti and Levien (2004a; 2004b) adapted language from ecology to propose that firms occupying influential hub positions (i.e., network nodes that are highly connected to other nodes) can adopt either a keystone role or a dominator role. Keystones exercise leadership to their own benefit, but also to the benefit of other ecosystem members. Keystones create platforms of services, tools, or technologies that other members of the ecosystem can use to enhance their own performance. Dominators instead adopt the short-term tactic of maximum value extraction, without attending to ecosystem health.

Adner (2012) recently proposed a “wide lens” strategy toolkit for managers seeking to assess, build, or reshape ecosystems. Adner's application cases are well-resourced multinational enterprises; nonetheless, some of the management problems addressed by Adner's tools and frameworks are conceptually similar to the problems faced by technology entrepreneurs.

Business ecosystem contributions published in the TIM Review include Bailetti's (2008) inaugural Technology Innovation Management (TIM) lecture on the business ecosystem approach to commercialization of technology products and services, Milinkovich (2008) on ecosystem development, Carbone (2009) on business models and ecosystems, Hurley (2009) on the opportunities that ecosystems provide to creative entrepreneurs, Bailetti (2010a) on how technical entrepreneurs benefit from business ecosystems, Bailetti (2010b) on growing the revenue of small technology companies, Weiss (2010) on ecosystem keystones, Weiss (2011b) on the economics of software product development collectives, and Satsangi (2012) on evaluating alliance options. Mike Milinkovich, the Executive Director of the Eclipse Foundation, offers the following practical advice on ecosystem strategy (quoted by Weiss, 2011):

“Define very precisely what your competitive differentiators are for your customers or you’re going out of business. Focus all possible energies there, and acquire everything else from open source software, or help build it in open source software. Or in other words: pick your niche; co-evolve the platform in collaboration with other actors in the ecosystem.”

Despite the prevalence of real-world systems that combine platforms, communities, and business ecosystems, larger field settings and the multilevel interactions between subsystems have received less attention than each of the organizational forms themselves. Important exceptions include Milinkovich (2010) on the connection between community-developed open source software and the business ecosystems that commercialize that software, my own systems model of community-developed platforms (Muegge, 2011), Nyman and Lindman (2013) on code forking in open source software, and Schweik (2013) on the sustainability of open source software commons – all published in the TIM Review. Muegge's (2011) systems model considers the platform, developer community, and business ecosystem as codependent subsystems linked by interconnected institutional arrangements, resource flows, and governance structures, and a multilevel systems architecture linking the organization of technologies, people, and economic actors. Gawer and Cusumano (2012) examine the platform and ecosystem together from the perspective of the platform leader. Weiss and Gangadharan (2010) examine the role of platforms in ecosystems from the perspective of the complementor.

Implications for Technology Entrepreneurs

Table 2 is a compilation of prescriptive lessons learned for technology entrepreneurs facing various strategic decisions regarding platforms, communities, and business ecosystems. Table 3 is a recommended reading list for learning more about platforms, communities, and ecosystems. Also note that the author maintains a website of research and practitioner resources, including references to all sources cited in this article.

Table 2. Summary of lessons learned for technology entrepreneurs

Level

Lessons Learned*

Platform

Technology entrepreneurs deciding whether or not to adopt an existing platform:

  • Choose a platform with higher modularity and option value; platforms with higher modularity and option value are more likely to attract developer contributions.

Technology entrepreneurs producing platform complements:

  • Focus on products that the platform leader is unlikely to offer.
  • Expect rapid change: work on continuous communication, seek early information, and pay close attention to the actions of platform leaders.
  • React quickly to the demands of the platform leader; do not provoke others to become competitors.
  • Create products that enhance the value of others' products.
  • When working with potential competitors, work with groups and individuals within the firms who are likely to offer the most neutral stance to promote the platform.

Technology entrepreneurs in a platform leadership position:

  • Employ the four levers of platform leadership to maintain and extend a leadership position: i) scope; ii) product technology; iii) relationships with external complementors; and iv) internal organization.
  • Recognize the tension between adoption and appropriability when choosing the appropriate degree of platform openness (transparency and accessibility).
  • Attend deliberately to the three problems of platform leadership: i) maintain the integrity of the platform in the face of future technological innovation and the actions of other companies; ii) let the platform evolve while maintaining compatibility with past complements; and iii) maintain platform leadership.

Technology entrepreneurs aspiring to become platform leaders:

  • Be cognisant of the differences between a product strategy and platform strategy
  • Design an architecture of participation, with high modularity and well-defined interfaces, that is easy to build on and extend by others, performs a valued function, and where contribution is the default behaviour for users. Employ practitioner heuristics (Box 1).

Community

Technology entrepreneurs deciding whether or not to participate in an existing community:

  • Choose a community with higher transparency and accessibility of: i) production; ii) governance; and iii) intellectual property; projects that are more transparent and accessible are more likely to attract external participants and to grow communities.
  • Employ evidence-based design propositions (Box 2) when assessing a community.

Technology entrepreneurs seeking to grow and nurture a community:

  • Employ evidence-based design propositions (Box 2) when designing or reshaping a community.

Business ecosystem

Technology entrepreneurs deciding whether or not to participate in a business ecosystem:

  • Choose an ecosystem where the organization(s) at the hub position behaves as a keystone (fostering value creation) rather than a dominator (extracting value only). If possible, choose an ecosystem with a membership-based vendor-neutral keystone.
  • Choose a healthy ecosystem with high productivity, robustness, and niche creation.
  • Choose an ecosystem with institutional features that motivate resource flows from economic actors in the business ecosystem to developer communities and platforms.
  • Employ wide lens tools and frameworks to assess ecosystem risks and opportunities.
  • Participate in multiple ecosystems as a diversification and risk management tactic.

Technology entrepreneurs seeking to grow and nurture a business ecosystem:

  • Behave as a keystone (rather than a dominator) by deliberately nurturing the platform, creating value within the ecosystem, and sharing the value with other participants.
  • Employ wide lens tools and frameworks to reshape and orchestrate the ecosystem.

*Lessons learned for technology entrepreneurs are compiled from various sources cited throughout the article.


Table 3. Recommended reading

Level

Author (Year)

Source

Contribution

Platform

Cusumano & Gawer (2002)*

Article: Sloan Management Review

Platform leadership: ability to drive innovation around platform technology at the broad industry level. Platform leaders use four levers of platform leadership to maintain and extend a position, and face four problems of platform leadership.

West (2003)

Article: Research Policy

Firms introducing platforms and standards face a tension between adoption (encouraging use by others) and appropriability (earning returns).

Baldwin & Clark (2006)

Article: Management Science

Open source software codebases that are more modular or have more option value increase the incentives for developers to join and remain involved in a project.

Community

West & O'Mahony (2008)

Article: Industry & Innovation

Projects with more transparent and accessible (i) production, (ii) governance, and (iii) IP are more likely to attract external participants and to grow communities.

Bacon (2009)

Book: The Art of Community

Experience-based practitioner advice on building and growing communities.

Kraut & Resnick (2011)

Book: Building Successful Online Communities

Evidence-based design claims for building online communities. Five levers of community change. Five community design challenges.

Schweik & English (2012)**

Book: Internet Success

Actionable design principles for sustainable community-developed software projects; results of >40 hypothesis tests with large-sample data sets.

Business ecosystem

Moore (1993)

Article: Harvard Business Review

Business ecosystems. Advocates an ecological approach to management.

Moore (1996)

Book: The Death of Competition

Expanded treatment of Moore (1993); sharper definition of business ecosystem.

Iansiti & Levien (2004a)***

Article: Harvard Business Review

Roles: keystone, dominator, niche player. Keystone strategy. Ecosystem health.

Moore (2006)

Article: The Antitrust Bulletin

Business ecosystems are an organization form, as important as markets and firms.

Adner (2012)

Book: The Wide Lens

Wide lens tools and frameworks for assessing, building, and reshaping ecosystems.

Multilevel system architecture

Parnas (1972)

Article: Communications of the ACM

Introduced influential ideas about modularity, information hiding, and interfaces.

Simon (1996)

Book: The Sciences of the Artificial

Hierarchical systems; near-decomposability; emergent properties; design science.

Baldwin & Clark (2000)

Book: Design Rules, Volume 1

Architectural modularity links designs, tasks, and industry structures in a complex adaptive system; design rules; design operators; design evolution.

O'Reilly (2005)

Book chapter: Open Sources 2.0 (ch. 7); blog posts at oreillynet.com

Systems with an architecture of participation attract user contributions. Users pursuing their own selfish interest build collective value as an automatic byproduct.

Baldwin & Woodard (2009)

Book chapter: Platforms, Markets and Innovation (ch. 2)

Joins the research literatures on platforms with the literature on architecture.

*Platform Leadership (Gawer and Cusumano, 2002) is an expanded treatment of the material in Cusumano and Gawer (2002).
**Schweik (2013) summarizes the main results (including the design principles) of Schweik and English (2012) in an open access format.
***The Keystone Advantage (Iansiti and Levien, 2004b) is an expanded treatment of the material in (Iansiti and Levien, 2004a).

 

Conclusion

In the global information economy, the actions and outcomes of a technology entrepreneur are deeply interconnected with the actions and outcomes of others. By making these connections explicit, in strategy formation and in business model design, an entrepreneur can more efficiently interpret new information, more effectively identify opportunities and evaluate alternative courses of action, and more clearly link actions and expected outcomes.

This article has re-examined platforms, communities, and business ecosystems from the perspective of the technology entrepreneur. It brought together insights from various scholarly and practitioner sources to present evidence-based lessons learned for technology entrepreneurs facing choices about whether or not to engage with existing systems of platforms, communities, and business ecosystems, and decisions about the nature and extent of participation within these systems. Contributions include a precise working vocabulary and conceptual framework for thinking about and discussing collaboration (Table 1), a compilation of evidence-based prescriptive lessons learned from prior research (Table 2), and a guide for further reading and private study (Table 3).

This article concludes with a call to researchers – especially to graduate students seeking high-impact topics for thesis and dissertation research in technology management and in business – to extend this line of research in three ways. First, by studying field settings at multiple levels of analysis – not only platforms of technology building blocks, communities of developers and users, and ecosystems of economic actors, but also their interactions and multilevel dependencies. Second, by explicitly considering the perspective of the technology entrepreneur. Third, by framing research questions around managerially relevant problems faced by entrepreneurs in the field. Technology entrepreneurs are a source for much innovation and a driver of economic growth and prosperity for individuals, firms, regions, and nations (Bailetti, 2012). Research that improves the magnitude and likelihood of entrepreneurial success can have broad-reaching impact.

Share this article:

Cite this article:

Rate This Content: 
10 votes have been cast, with an average score of 1.9 stars

Keywords: architecture of participation, business ecosystem, community, platform, technology entrepreneurship

Comments

The article wonderfully captures the challenges future innovation organisations face when working out what course its technology/engineering function needs to take to deliver value to the the firms customers.

Breadbasket