Business Ecosystems as Institutions of Participation: A Systems Perspective on Community-Developed Platforms

Steven Muegge

Business Ecosystems as Institutions of Participation: A Systems Perspective on Community-Developed Platforms

November 2011

Steven Muegge

The architecture of Linux, the Internet, and the World Wide Web are such that users pursuing their own "selfish" interests build collective value as an automatic byproduct.... These projects can be seen to have a natural architecture of participation... By consistent effort (as well as economic incentives ...), it is possible to overlay such an architecture on a system that would not normally seem to possess it.

Tim O'Reilly

Abstract

This article introduces a systems perspective on community-developed platforms and the institutions that structure participation by individuals and companies. It brings together the past research about technology platforms, company participation in business ecosystems, and individual participation in developer communities, and links these codependent subsystems through resource flows, interconnected institutional arrangements, and shared governance. To achieve this synthesis, it draws on conceptual arguments from a broad range of sources, including Elinor Ostrom's research program on the economics of sustainable commons governance, Tim O'Reilly's practitioner essays about the architecture of participation, and prior management research on modularity and design, resource dependence, and systems thinking. The resulting “systems of systems” perspective is parsimonious and insightful for entrepreneurs, managers, and community leaders.

Introduction

High-impact innovation, once thought to be the province of corporate R&D labs, is now known to occur in many settings outside the boundaries and exclusive control of traditional business firms. Technology-intensive business organizations, from specialized startups to diversified multinational enterprises, increasingly self-identify as participants within business ecosystems, adopters and patrons of open platforms, and stewards and promoters of innovation communities – trends well-known to readers of the OSBR and the TIM Review. There exists today growing bodies of knowledge about platforms, ecosystems, and communities, but these bodies of knowledge are not well connected and have developed in different directions. Platforms research has tended to emphasize the closed or partially-open platform architectures controlled by platform leaders such as Apple, Microsoft, and Amazon. Business ecosystems research has often focused narrowly on keystone organizations, particularly the strategies by which profit-motivated platform leaders can sustain and leverage a lucrative privileged position, and the strategies available to firms aspiring to become platform leaders, but less is known about ecosystems anchored around not-for-profit keystone foundations and platforms that the keystone can nurture but not control. Research on innovation communities has typically attended closely to the mechanisms of value creation, particularly the processes of free and open source software development, but often with less attention to and connection with adoption, commercialization, and the mechanisms of value capture. The Apache Software Foundation, the Linux Foundation, and the Eclipse Foundation are three prominent examples of systems comprised of a community-developed platform, a commercial ecosystem of for-profit companies and other organizations, and a meritocratic developer community of individuals who maintain and extend the platform. These components interact and co-evolve to produce high-impact innovation. Nonetheless, much past scholarship has too often examined platforms, communities, or ecosystems in isolation, rather than examining the broader context in which each of these subsystems are collectively embedded or the interactions between these subsystems.

In this article, the engine driving innovation on community-developed platforms is presented as a resource cycle from the business ecosystem, to the developer community, to the community-developed platform, and back to the business ecosystem. The developer community is the locus of value creation, the business ecosystem is the locus of innovation commercialization and value capture, and the platform sits between as a shared commons resource: the outbound product of the developer community and inbound open innovation for the economic actors of the business ecosystem. The resource cycle of innovation is driven by institutional characteristics of the platform, community, and ecosystem, and by keystone actions of the governance foundation. Collectively, these multilevel institutions of participation and keystone actions motivate participation in subsystems and resource flows between subsystems. Later sections introduce and elaborate on each of these concepts.

An integrated “systems of systems” perspective complements previous work in at least two ways. First, by raising the level of analysis, it joins these various bodies of knowledge as each addressing aspects of a larger partially-decomposable system. Second, by introducing the language and concepts of institutional theory and prior research on the economics of commons governance, it focuses attention on aspects of the system that are unaddressed or under-addressed by other perspectives. An elevated level of institutional analysis provides practitioners with a common vocabulary for effective communication and discussion with others, and a conceptual framework for thinking clearly about the interactions between platforms, business ecosystems, developer communities, and the polycentric governance structures that comprise a governing keystone foundation.

This article is organized in seven sections. This first section has introduced the topic and key concepts. The next four sections develop the “systems of systems” perspective, starting with the platform, next adding the business ecosystem and its relationship to the platform, then the developer community and its relationships to the platform and ecosystem, and finally the keystone foundation and its network of relationships with other subsystems. Collectively, these four sections develop an integrated systems perspective on participation, value creation, and value capture. The sixth section discusses the contribution of this work, emphasizing the practical implications for various stakeholders. The seventh section concludes and looks ahead to the future. Illustrative examples throughout the article are drawn from the author's field research on the Eclipse Foundation, platform, ecosystem, and community (Box 1), and other systems of distributed innovation.

Box 1. The Eclipse Foundation, platform, ecosystem, and community

The illustrative examples in this article are drawn from the author's recent field research on the Eclipse ecosystem – a setting likely familiar to many readers of this journal. Eclipse Foundation staff have been active contributors to the OSBR, with articles by Don Smith and Mike Milinkovich in the inaugural issue of July 2007, Ian Skerrett in January 2009, Mike Milinkovich again in January 2010, and Ian Skerrett again in January 2011. In last month's inaugural issue of the TIM Review, Carleton Professor Michael Weiss illustrates several concepts with a case study of Eclipse.

The Eclipse field setting includes all the components discussed in this article: a community-developed platform, a business ecosystem, a developer community, and not-for-profit keystone governance foundation. According to the bylaws of the Eclipse Foundation, Eclipse exists “to advance the creation, evolution, promotion, and support of the Eclipse Platform and to cultivate both an open source community and an ecosystem.” In the January 2010 issue of the OSBR, Executive Director Mike Milinkovich writes: “This duality is built into our bylaws, our organization and, I would assert, our DNA”. Likewise, the characteristics of vendor neutrality, extensibility, and accessibility are embedded into the Eclipse Foundation's legal identity. According to Eclipse Foundation staff, “This really is the best of both worlds: the openness, transparency and meritocracy of open source with the resources and commitment of corporations both large and small” (Smith and Milinkovich, 2007).

At the time of this writing, the Eclipse Foundation comprises 174 member organizations, 1057 individual committers, and 273 projects. Eclipse software assets are community-developed open source software that can be freely obtained, used, modified, and redistributed. The Eclipse software platform is comprised of modular extensible frameworks for building software and a family of tools and runtimes built on those frameworks. The most well-known Eclipse tool is the Eclipse Java IDE – often called the dominant IDE for software developed in the Java programming language. Eclipse is structured to deliberately encourage companies to incorporate Eclipse software assets into their own in-house software and commercial products. Through well-defined extension points and application programming interfaces (APIs), software developers can use Eclipse tools to create new plug-in components to extend Eclipse tools and frameworks in new ways. This month, the Eclipse community celebrates its tenth birthday at EclipseCon Europe 2011.

The scholarly research that underpins this article was a multi-year field study of the Eclipse Foundation, community, platform, and ecosystem. In addition to the findings reported here, the research also examined the origins and meaning of the ecosystem concept, the characteristics of each institutional structure and their interdependencies, tensions between participants and the management of those tensions, the motivations for company participation, and the institutional features that enable, promote, and sustain company and individual participation. The research design was a nested multilevel explanatory case study that collected data on individual participation in Eclipse open source projects, company participation in the Eclipse ecosystem, and the interactions of individuals and companies within Eclipse governance structures, including the board of directors, the foundation staff, and the cross-project governing councils. Data sources included direct observation of participants and participant communications, extensive archival data, and interviews with individual participant informants at multiple levels of analysis. The research was multidisciplinary in the sense of drawing on several scholarly disciplines, including strategic management, organization theory, institutional economics, and analogy with natural ecology to better understand and explain phenomena that cross traditional disciplinary boundaries.

Platforms

A platform is a set of technological building blocks and complementary assets that companies and individuals can use and consume to develop complementary products, technologies, and services. Innovators that build on top of platforms can reuse the non-differentiating assets that are core to the platform to focus their effort and attention on assets that will differentiate the innovator's offer from others.

The technological building blocks of a platform could in principle take many different forms, such as electronic hardware, schematic designs, specifications, online services, or knowledge assets, but many prominent platforms today are implemented largely in computer software. Complementary assets increase the value of the technological building blocks, often by decreasing the associated costs or risks of adoption and use. For example, important complementary assets may include the facilities for distributing platform assets, the communications infrastructure enabling user-to-user support, and a structured process for accepting new contributions. At a 2008 talk at Carleton University, Eclipse Foundation Executive Director Mike Milinkovich described the Eclipse platform as the combined base of technologies, architectures, designs, and assets used to build market offers, components, products and services, legal and licensing frameworks, and processes which anchor economic community – a view consistent with this perspective.

Two findings from prior research on platforms are especially salient. First, we know that platforms vary widely in level of openness, where openness is a multidimensional construct including not only the property rights of the platform assets – that is, the rules by which others can use, modify, and redistribute the assets – but also the processes of maintaining and extending the platform assets. Any particular platform may be more open in some respects and more closed in others, and the number of possible permutations is large. Second, we know that platforms are hubs for both value creation and value capture, and the dynamics of each of different.

From an institutional perspective, a platform that is at least partially open for use and adoption is a commons resource, and participation in maintaining and extending a platform is collective action – notions useful for linking the platform to the subsystems of value creation and value capture. (Box 2 introduces the research behind these concepts). Conceptually, the notions of platform value creation and platform development are closely related, as are the notions of platform value capture and the property rights for distribution and use. On the value capture side, platforms that are widely adopted by organizations and individuals can become the anchor of what practitioners are calling “business ecosystems” – examined in the next section.

Box 2. Elinor Ostrom's research program on sustainable commons governance

Elinor Ostrom shared the 2009 Sveriges Riksbank Prize in Economic Sciences in Memory of Alfred Nobel for "analysis of economic governance, especially the commons." Ostrom's work challenged economic orthodoxy that collective action is rarely sustainable and investigated the antecedents and determinates of successful collective action around commons resources. A commons, interpreted broadly, is a shared resource potentially subject to social dilemmas.

In traditional economic thought, three “classic” models of collective action together comprise the conventional theory of the commons: Mancour Olson's The Logic of Collective Action (1965), Gareth Hardin's “The Tragedy of the Commons” (1968), and the Prisoners' Dilemma game of analytic game theory (Poundstone, 1992). All predict that collective action cannot be sustained without strong property rights or a coercive state. Hardin famously writes: “Ruin is the destination toward which all men rush, each pursuing his own best interest in a society that believes in the freedom of the commons. Freedom in a commons brings ruin to all.” Ostrom argued that although these models can be useful in helping to conceptualize some of the incentives in simple situations, they have been overused as realistic models of much more complex and dynamic situations.

Three decades of empirical studies have found that collective action problems can sometimes by solved by voluntary action. These studies have focused mainly on systems of shared natural resources such as groundwater basins, irrigation systems, grazing systems, fisheries, and forests, but also urban goods such as policing and education. In some of these systems, resource users did self-organize and succeed in preventing severe over-harvesting of resources they depended on, and although these institutions did not always succeed, neither did private or state ownership. More recently, Ostrom's methods have been applied to the scholarly study of knowledge commons, such as software and other digital assets, where the dilemmas threatening sustainability are under-production and enclosure rather than over-utilization dilemmas of the traditional commons.

Business Ecosystems

Business ecosystems are a practitioner-driven phenomenon where organizations and individuals typically self-identify as an ecosystem, both in their own internal discourse and in the brand identity they convey to others. Although practitioners differ on definitions, they generally agree that companies within a business ecosystem interact both cooperatively and competitively to co-evolve capabilities around a platform. The scholarly management literature has examined business ecosystems from at least four different perspectives: i) as an industry structure anchored around a technology platform; ii) as a context conducive to open innovation; iii) as an innovation community that extends membership to organizations as well as individuals; and iv) as an innovation network of ties and relationships between firms. These perspectives are complementary: each provides a different vantage point and conceptual lens to bring into sharp focus some aspects of the business ecosystem that are unaddressed or under-addressed by other perspectives.

An institutional perspective on business ecosystems instead emphasizes the rules, norms, and enforcement characteristics that structure interaction and participation. Also, institutional theory provides a precise language for formally specifying the business ecosystem as an organizational field: the set of all organizations that, in the aggregate, constitute a recognized area of institutional life. The organizational field is a well-defined research construct in organization studies. In scholarly social science research, organizational fields connect organization studies to the wider macrostructures of societies and world systems.

Bringing together all of these ideas and adapting a popular definition from James Moore (2006), a business ecosystem is the field of economic actors whose individual business activities, anchored around a platform, share in some large measure the outcome of the whole ecosystem. This definition makes three specific and deliberate refinements to Moore's definition. First, the notion of an organizational field provides definitional precision and clarity, links to previous management scholarship, and reduced likelihood of confusion between the business ecosystem and developer community construct (introduced in the next section). Second, it explicitly identifies the platform as the anchor point of the ecosystem and the nexus of entwined participant outcomes. Third, it replaces Moore's language of “shared fate” with the notion of “shared outcomes” to remove any suggestion of predetermination: outcomes are interdependent and co-evolving but not fixed in advance. From this perspective, the Eclipse ecosystem includes a broad set of organizations and individuals conducting business transactions with products, services, and technologies anchored around the Eclipse platform. Some ecosystem participants become members of the Eclipse Foundation, while others do not. Some ecosystem members become active in the maintenance and extension Eclipse software, while others do not.

Activity within a field is structured by an institution – the set of formal constraints, informal constraints, and enforcement characteristics that structure interaction (Box 3). Prior research on business ecosystems has had little to say about the institutional factors associated with participation, and this gap in our collective understanding was one of the motivations for this research. In the author's field research, companies were observed to participate in the Eclipse ecosystem in a wide variety of different ways, and each case company participated in ways that strengthened or transformed its business model. All of the case companies gained access to capabilities required for their business models (Bailetti, 2009); interestingly, capabilities obtained from governance activities and activities undertaken to maintain and extended the platform were often as important as the consumption of platform assets as inbound open innovation. Some companies performed a portion of their R&D within the Eclipse developer community, through some combination of employing Eclipse committers and by contributing assets to the platform. A few companies invented new business models, anchored around Eclipse, that would not otherwise have been viable. The direct link between the platform and business ecosystem was one of resource flows: consumption of platform assets by ecosystem companies, and contribution of company assets to the platform. Equally important were indirect links through the Eclipse developer community – the topic of the next section.

Box 3. Institutions

An institution is a set of formal constraints, informal constraints, and enforcement characteristics that structures human interaction in a way perfectly analogous to the rules of the game in a competitive team sport (North, 1993). Some aspects of an institution may be codified and explicit while others are tacit and are taken for granted. Some aspects may be unnoticed and unquestioned by participants.

One outcome of Elinor Ostrom's research program (Box 2) was the Institutional Analysis and Design (IAD) framework, which arose from the need to specify and compare diverse collective action situations. IAD focuses attention on three broad categories of institutional variables: i) underlying factors of the rules in use, attributes of the community, and attributes of the resource; ii) the action arena of actors in an action situation; and iii) outcomes. The earliest applications of IAD were to guide case study research and to enable cross-case comparisons. Later applications employed IAD for meta-analysis, experimental designs in the laboratory and in the field, mixed method studies, agent-based simulation models, and large sample studies. More recently, researchers have employed IAD to study sustainable “knowledge commons”, including digital information, libraries, and other knowledge resources.

The IAD framework was the central organizing framework guiding data collection and analysis for the author's research on the Eclipse field setting (Box 1). The details of that analysis are outside of the scope of this introductory article, but the key point is that the IAD framework provided a way to describe and specify the Eclipse institutions structuring individual and company participation.

Developer Communities

A developer community is the community of individuals, organized as a meritocracy, who collectively maintain and extend the platform. This definition is consistent with the research on open source software developer communities and the broader research on community innovation. Like the business ecosystem, the developer community operates within an institution – a developer community institution that structures the activity of individuals who maintain and extend the community-developed platform.

Within a community meritocracy such as the the Apache Software Foundation or the Eclipse Foundation, it is individuals, not the companies employing those individuals, that have merit and status (Skerrett, 2009). Organizations, of course, may be influential within the larger system, but their influence within the community is indirect through the individuals that they employ. Within Eclipse, for example, commit privileges and other community roles attach to an individual rather than an individual's employer: an individual's roles and responsibilities in the developer community do not change if that individual changes employers or other organizational affiliations; likewise, a contributor is said to receive no special community status from any particular organizational affiliation. According to the Eclipse development process (EDP), the activities to create and maintain Eclipse platform software are structured into Eclipse projects – the “main operational unit at Eclipse” and the context in which Eclipse software development occurs. The committers on a project – the individuals with write access to the project's resources and a vote in project matters – have the exclusive authority to nominate and elect new committers to that project within the rules of the EDP. Eclipse contributors are the much larger group of individuals who contribute code, fixes, tests, documentation, or other work to an Eclipse project, but have not been elected as committers. Eclipse practitioners speak also of other Eclipse communities, which are said to include organizations as well as individuals (Skerrett, 2011). For example, there is the community of Eclipse users and the community of Eclipse adopters. This section focuses narrowly on the developer community, which is comprised exclusively of individual committers and contributors.

Three findings from prior research on developer communities are especially salient. First, we know about a wide variety of motivations and incentives for individual participation, including career and personal development, self-determination, peer recognition, identification, self-promotion within the social structure, and belief in the inherent value of free software, and we know that participants differ widely in their self-reported rankings of the importance of different factors. Second, we know that many open source software developers are employed by companies to develop open source software as part of their formal job assignment. On projects with active company involvement, interested companies may employ most or even all active developers. Third, prior research identifies some of the institutional factors associated with participation in developer communities. Baldwin and Clark (2006), argued that the architecture of a software code base is a critical factor that lies at the heart of the open source development process. Employing a series of increasingly sophisticated game theory models, Baldwin and Clark showed that increasing modularity and option value has two effects on the software development process: it increases the incentives of developers to get involved and remain involved in the development process, and it decreases the amount of free riding in the equilibrium. Both effects promote growth of the developer community. Evidence from subsequent empirical studies has supported a deep and positive connection between modularity and participation. West and O'Mahony (2008) examined twelve open source projects initiated by corporate sponsors and found that sponsors consider three design dimensions that together create a specific participation architecture: i) production (the 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). Community institutions offering greater transparency (the ability to obtain and use assets, and observe activities and decisions) and accessibility (the ability to change code, participate in project activity, and create derivatives) are better able to attract external participants and grow.

Figure 1 brings together all of these ideas along with the findings from prior sections to propose a cyclical relationship between a community-developed platform (P), a business ecosystem (E), and a developer community (C). The developer community and the business ecosystem are structured by institutions of rules, norms, and enforcement characteristics, both sharing the platform as a commons resource, and a governance foundation (F) that provides the functions of both community governance and an ecosystem keystone. These subsystems are bound together though co-dependencies for resources, shared actors, and multilevel and nested interactions. (Box 4 summarizes some additional conceptual arguments underpinning the structure depicted in Figure 1).

Figure 1. Resource cycle of participation (situating extant theory)

The engine driving innovation on community-developed platforms is a resource cycle from the platform, to the business ecosystem, to the developer community, and back to the platform (labeled R_PE, R_EC, and R_CP, and indicated by the thick black arrows of Figure 1). The developer community is the locus of innovation creation and platform value creation, and the business ecosystem is the locus of innovation commercialization and platform value capture. The platform is the outbound product of the developer community and inbound open innovation for the economic actors of the business ecosystem.

In research on the Eclipse field setting, the author found that resources for the Eclipse developer community originated largely from the for-profit companies comprising the Eclipse ecosystem (R_EC). The most important of these resources was the effort and attention of individual contributors paid by companies to contribute to Eclipse projects. Individuals within the Eclipse developer community maintained and extended the Eclipse platform through contributions (R_CP): writing and testing software, creating documentation and other resources, and other project activities. The economic actors of the business ecosystem used, extended, and commercialized the assets of the Eclipse platform to create and capture economic value (R_PE) – and in doing so, entwined their own business outcomes with the outcomes of the ecosystem. A second set of reciprocal resource flows moved in the direction opposite to the main resource cycle of production (R_PC, R_CE, and R_EP, indicated by the thin black arrows of Figure 1). For example, the platform provided software development tools to the developer community (R_PC), the developer community was a source for capabilities – including information, customer leads, and experienced developers – for ecosystem companies (R_CE), and some companies within the ecosystem contributed directly to the platform by donating software that had been developed outside of Eclipse (R_EP) .

Two other sets of resource flows were observed, which are also shown in Figure 1. A third set of governance relationships connected the Eclipse Foundation to each of the other subsystems. A fourth set of external resource flows connected each subsystem with the exogenous environment. The next section examines governance and governance relationships.

Box 4. Conceptual linkages

To link these subsystems together into an integrated systems perspective, the author's research program draws on ideas and conceptual arguments from various academic, practitioner, and interdisciplinary sources.

The first source is the research program of Elinor Ostrom and her colleagues on commons governance and institutions for collective action (Box 2), especially the Institutional Analysis and Design (IAD) framework (Box 3).

Second is the practitioner writing of Tim O'Reilly on architectures of participation. In a series of essays, presentations, and blog posts, O'Reilly argues that systems that successfully attract user contribution possess an architecture that links the design of the technical system and the organization of the community of users (e.g., O'Reilly, 2004). 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.

Third is the scholarly research of Professors Carliss Baldwin and Kim Clark on design rule theory. Baldwin and Clark draw on well-established ideas in architectural design, engineering design, and software engineering to argue that 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 architectural design, organizational design, and industry structure in an interconnected multilevel complex adaptive system. The design rules at each level are reflected in the design rules of the other two levels. This research contributes to the small scholarly literature, along with Baldwin and Clark (2006) and West and O'Mahony (2008) cited previously, that has begun to operationalize O'Reilly's arguments as the basis for a theory of participation.

Fourth is systems thinking, a perspective on business and management that emphasizes cyclical feedback loops, varying time delays between actions and outcomes, and complex interactions, rather than the linear “event-driven thinking” of cause and effect and of independent and dependent variables that is more common in management theory and practice.

Fifth is resource dependence, a “classic” management theory dating from the 1970s in which the survival and performance of organizations depends on the ability to acquire and maintain resources through reciprocal resource exchange relationships with other organizations.

Governance

The governance foundation in Figure 1 is at once both an open source software foundation (Xie, 2008) and a business ecosystem keystone (McPhee, 2010). Prior research on developer communities and business ecosystems has treated these roles separately, but for community-developed platforms, they are inseparable.

In the author's research on the Eclipse field setting, the Eclipse Foundation provided governance and services to both the community and ecosystem, and stewardship for the platform as gatekeeper of Eclipse quality through the project review process required for a project to declare a software release for public consumption. As noted in Box 1, recognition of these multiple roles is explicit in Eclipse governance documents and evident in practitioner discourse. From its member organizations, the Eclipse Foundation obtained the financial resources for operation. From the developer community, it obtained the effort and attention of individuals who contribute to governance activities. Where there were tensions between the community and ecosystem, the Eclipse Foundation actively managed these tensions and harnessed them in ways that ultimately improved the system. Keystone actions by various governance structures – for example, to promote awareness of the platform, grow the user and adopter base, and provide services to benefit member companies – promoted participation and resource flows.

Practitioner Implications

Systems thinking around community-developed platforms is not new. In the author's research, many references to “positive feedback loops” were observed in Eclipse community discourse. Likewise, Eclipse Foundation staff spoke of an “Eclipse virtuous cycle” (Milinkovich, 2008) in which some vendors that consume platform technology choose to re-invest a portion of their profits back into developing the platform in anticipation of future benefits. What is new and useful here, however, is the precision and clarity with which the constructs and relationships are specified, the empirical grounding in rigorous field research, and solid theoretical underpinnings that join the scholarly literatures on platforms, communities, and business ecosystems.

This systems-level model makes at least four contributions. First, it provides a conceptual framework for thinking clearly about distributed innovation and it provides a vocabulary for clear communication with others. It distinguishes explicitly between the developer community and the business ecosystem, the different roles that each plays in the larger system, and the differing motivations of participants. Second, it focuses attention on the interactions between subsystems, not only on the subsystems themselves. Sustainability or growth of this system requires operation of each node and each segment of the resource cycle between nodes. For example, merely growing a large business ecosystem around a community-developed platform may not be sustainable unless the institutions structuring activity and the actions of the keystone also motivate an adequate flow of resources from the ecosystem to the developer community. Third, it clarifies the role of governance. The governance foundation of a community-developed platform is both an open source foundation and an ecosystem keystone, attending to the differing needs of both the community and ecosystem without benefiting one to the detriment of the other. Fourth, there may be tensions between the participants of the community and ecosystem, but the governance foundation can actively manage those tensions and harness them to improve the system.

Individuals looking to contribute to a developer community and entrepreneurs looking to join an established ecosystem can use these insights to make better informed decisions about participation. Managers of participating companies can use these insights to make better informed decisions about resource allocation. Community leaders and foundation staff, and top management teams looking to launch new systems of distributed innovation, can employ these insights for thinking clearly about effectively promoting participation.

Conclusion

Much has been written separately about platforms, business ecosystems, and communities, without linking these subsystems together into a systems-level perspective of distributed innovation. This article has argued that business ecosystems can be usefully understood as institutions of participation that are linked to developer communities and community-developed platforms through resource flows, interconnected institutional arrangements, and shared governance. It extends and contributes to a nascent stream of management research working to develop a general theory of participation in systems of distributed innovation.

A “systems of systems” perspective contributes to both research and practice. For management researchers, it provides a data collection and analysis framework for empirical study of the institutions of company and individual participation, theorizing about the relationships between communities, ecosystems, platforms, and governance foundations, and comparing the institutional arrangements of different field settings. It joins several formerly disparate literatures and provides definitional clarity. For practitioners, it provides an alternative perspective for thinking clearly about distributed innovation and it provides the vocabulary to clearly communicate these thoughts with others.

Further research will seek to more clearly specify the institutional features that enable and promote company and individual participation and motivate the resource cycle between nodes, and to better understand the circumstances under which those arrangement are effective. The present model contributes a framework in which to situate and interpret those results.

Share this article:

Cite this article: