Currently, there is little understanding about how di erent types of software ecosystems must be governed for the preservation and improvement of ecosystem health. This paper explores the de nition of software ecosystems and provides a classi cation model for software ecosystems. The classi cation model is applied to 19 cases previously explored in software ecosystem literature, and governance tools are observed for the di erent types of ecosystems. The governance tools are summarized in a governance model that, when used correctly, serves ecosystem coordinators in determining strategies to maintain and ultimately improve software ecosystem health.
While in the early days of software engineering a software product was the
result of e ort of an independent software vendor to create a monolithic product,
modern software strongly relies on components and infrastructure from third
party vendors or open source suppliers [
Just as participants in a value chain of physical products, partners in a
software value chain maintain ongoing business relationships. Up to the late 80s,
vertically integrated companies delivered complete system stacks [
At the highest level of abstraction, software ecosystems are collections of organizations that are related through software or a software related concept. Please also note that software ecosystems are subsets of business ecosystems. If we were to take all organizations in the world and de ne queries on it to create speci c collections of organizations, we could for instance use the query \Toyota". This would provide us with all the suppliers, partners, customers, and resellers that do business with Toyata and their relationships. The collection of organizations and relations gives us access to the business ecosystem of this particular company, i.e., the Toyota ecosystem. The same can be done for software concepts, to get the software scope instead of the generic business scope. A non-exhaustive list of software concepts is provided with examples: { Standards - XML, BPM, OSGi, J2EE, Corba, SEPA, etc. { Products - OpenO ce, Microsoft Word, SAP BusinessOne, Grand Theft
Auto, etc. { Hardware - Playstation 3, HTC Diamond, PDAs, BMW 5 series, etc. { Platforms - .Net, Facebook, Android, OS X, etc.
The list can be used to identify types of ecosystems (again, non-exhaustive) and to name speci c instances, such as the \OS X Ecosystem". Several notes must be made with this list. The rst issue concerns inclusion and exclusion criteria or, put di erently: at what point does a collection of organizations and relations become a business ecosystem instead of a software ecosystem. The answer to this question can be made complex, but it can be simpli ed by determining the aim of the research or \query" that is done within a speci c business ecosystem. If the query is not speci cally software related (`What companies use SEPA for all their business transactions and how are these companies related?') the resulting set is a business ecosystem. If the query is software related (`What software providers have already adopted SEPA as the main language for their APIs and how do these organizations relate to each other?') the resulting set can be used to compose a software ecosystem.
A second issue with software ecosystems is the type of participant. In a commercial ecosystem participants are easy to determine: they are typically organizations that aim to survive and thrive, whether it is a one-man company or a large ecosystem orchestrator, such as SAP, Microsoft, or Facebook. In the scope of open source ecosystems participants can range from foundations (e.g., the Eclipse Foundation), to commercial organizations (e.g., RedHat), to independent developers (e.g., David Heinemeier Hanson for the Rails ecosystem). The question on what constitutes a participant in a software ecosystem depends on the following criteria: is it relevant for the research question, is it contributing to the ecosystem in a meaningful (but not necessarily signi cant) way, and is the contribution software related?
One question that is often asked is whether customers are part of the software ecosystem. If we draw the analogy to biological ecosystems, customers are the `plankton' that keep the ecosystem alive and well, which by de nition includes them into the ecosystem. A smart query can be created, however, that excludes customers altogether, such `what organizations build Apps for Android and how are they related to each other?' The extended answer to the question if customers are part of the ecosystem thus is: it depends on the query. The term `plankton' in this context is highly appropriate: without a (potential) market of su cient size it is risky for third-parties to join or co-create an ecosystem.
The second challenge that is handled in this work is the de nition of a series
of governance tools for platform leaders, i.e., parties that can determine the
future of the ecosystem. Software ecosystem governance is de ned as procedures
and processes by which a company controls, changes or maintains its current
and future position in a software ecosystem [
This paper continues with a description of the survey research in Section 2. In Section 3 several terms related to software ecosystems, such as biological, digital, and business ecosystems are discussed and contrasted against software ecosystems to provide perspectives on the de nition of software ecosystems. Section 4 provides the table with the survey results of this work and a classi cation model is extracted to classify and categorize software ecosystems by their de ning characteristics. Four types of ecosystems are further studied in Section 5, where di erent governance tools are identi ed through the survey of ecosystems and summarized in the software ecosystem governance model for health preservation and improvement, after we nalize with a short discussion and conclusion in Section 6.
The main research question of this research is whether there exist common types
of software ecosystems and whether these ecosystems have similar factors in the
domain of governance, such as life threats, growth challenges, who is in control,
etc. To identify and select software ecosystems, two criteria were used: rst the
de nition of software ecosystems was followed closely, and if an ecosystem did
not adhere to this de nition, it was not selected. Secondly, the ecosystems were
selected from papers as described in common software ecosystem literature [
The survey was stopped at the current number, because of time constraints
and for the sake of brevity. We therefore do not claim completeness: the
contribution of this work lies in the rst classi cation of software ecosystems and in
the identi cation of common concerns for the governance of these ecosystems.
For each ecosystem a list of 16 questions was answered by performing
document and web site study. Each of the ecosystems was checked by at least one
other researcher for correctness. These sixteen questions were extracted from
the work on open software enterprises [
In this section the comparison with other kinds of ecosystems is made. We start with the comparison with biological ecosystems and then move to the supercategories of ecosystems that can contain software ecosystems: business ecosystems and digital ecosystems. We nalize with a de nition of software ecosystems.
Considering the software ecosystems domain \borrows" part of its name from
the domain of (biological) ecosystems, there are some relationships between the
two, as others have established [
Dhungana et al. [
The comparison to biological and natural ecosystem is easily made, but analogies only stretch so far. The main di erence between software and natural ecosystems is that biological ecosystems are mainly studied to observe in uences from external factors, whereas software ecosystem dynamics are analysed mainly with the aim of growth and success. Software ecosystems are also made up of participants harboring intentionality, whereas the beings in a biological ecosystem have no means to consciously be part of the ecosystem. The largest di erence between participants in software ecosystems and those in natural ecosystems, however, is that in software ecosystems participants can consciously decide to exit the ecosystem or even destroy it.
Software ecosystems are perhaps a new concept, but business ecosystems have
been around much longer. Since the 90s, James F. Moore has used the concept
in multiple outlets, but most famously in his book entitled \The Death of
Competition" [
It must be noted that the concept has primarily found ground in the
technical community. Furthermore, Moore is already referring here to \central
companies", a concept that is later reformulated to \platform leaders" by Cumano
and Gawer [
The notion of platform leaders quickly leads to the typical three roles that are mentioned in contexts of business ecosystems: platform leaders, niche players, and bridge players. platform leaders are typically orchestrators that largely determine the growth of an ecosystem. A speci c type of platform leader is the dominator, a platform leader that quickly swallows up large parts of the ecosystem, such as IBM did in the 80s, and more recently Twitter, that, by doing a number of strategic acquisitions, made new entrants into the Twitter ecosystem reluctant to join. The niche players are those parties that use technology from the platform leaders to approach certain niche markets and are typically smaller, but still highly successful. An example of a niche player in a software ecosystem is for instance a provider of technical drawing software for heating in buildings, built on top of AutoCAD. The adagium `get big, get niche, or get out' is a popular rewording of the platform leader-niche player phenomenon. Finally, the bridge player is a player that bridges certain ecosystems. An example of such a player in a number of software ecosystems is PhoneGap, a platform that enables the release of software applications in di erent mobile ecosystems with one version of the software code.
Software ecosystems have been the subject of much debate before the concept
was de ned formally. They have always been seen as yet-another-instance of
business ecosystems and have been studied in that way with much merit [
A digital ecosystem is de ned as a distributed adaptive open socio-technical
system with properties of self-organisation, scalability and sustainability [
Several scholars conducted in-depth studies to explain ties between companies
in software ecosystems. These studies range from strategic level [
Three shared concepts stand out in these de nitions: (1) actors, organizations
and businesses, (2) networks and social or business ecosystems, and (3) software.
Based on these shared concepts Jansen, Finkelstein, and Brinkkemper [
A software ecosystem is a set of actors functioning as a unit and interacting with a shared market for software and services, together with the relationships among them. These relationships are frequently underpinned by a common technological platform or market and operate through the exchange of information, resources and artifacts.
Software ecosystems are usually governed and steered by one or more coordinating parties who pro t when the ecosystem thrives. Typically, these coordinators also control the `underpinning technology' on which the ecosystem is based, such as a commercial company that builds a software platform. There are also less traditional ecosystem coordinators, however, such as consortia behind open source platforms or even single developers who may have in uence on the ecosystem. Software ecosystem coordinators are de ned as bene ciaries of software ecosystem growth who have instruments available to in uence the development of the platform or the surrounding ecosystem. Typically they are also (partly) responsible for the further development of the underpinning technology.
The role of software platforms in software ecosystems is undeniable. If
an ecosystem is to be formed around anything, the controlling entity needs to
allow a degree of freedom for value creation of which the controlling entity
receives only a small part [
In table 4 the software ecosystems that were studied for this work are listed, along
with the four classi cation factors. The classi cation factors were extracted from
sixteen properties that were extracted from the work by Baars and Jansen [
Typology and classi cation models have been created for business
ecosystems. The model of Boons and Baas [
Base Technology - The de nition of a software ecosystem suggests that in general there will be some technology underpinning the ecosystem. The survey in this paper suggests that all software ecosystems are underpinned by a technology. The types of technology found here are a software platform, a software service platform, and a software standard. Most software ecosystems in the survey are underpinned by one software platform, such as AutoCAD, Ubuntu, or Wordpress. Some software ecosystems are even underpinned by multiple software platforms, such as the Microsoft ISV ecosystem, which is underpinned by Microsoft CRM, Sharepoint, Exchange, and many other underlying platforms. The third type of base technology for software ecosystems is a software service platform, where an online service is provided around which other ecosystem participants can gather, such as the Force.com platform and the HubSpot platform, 1 The full survey can be found here:
http://www.softwareecosystems.org/empirical/governancesurvey/
Underpinning Coordinators Extension market
Accessitechnology bility
AutoCAD plug-ins platform privately owned a list of extensions paid
Ubuntu platform consortium multiple extension markets for free
Android platform privately owned a commercial extension market screened
iOS platform privately owned a commercial extension market paid
Eclipse platform consortium an extension market screened
XBMC platform consortium multiple extension markets for free
Joomla platform consortium a list of extensions screened
GX platform privately owned an extension market screened
Ruby platform consortium multiple extension markets for free
Ogre3D platform consortium a list of extensions screened
MS ISV Partners platforms privately owned a commercial extension market paid
Wordpress service platform consortium an extension market screened
HubSpot service platform privately owned a commercial extension market screened
SalesForce service platform privately owned a commercial extension market screened
Spotify service platform privately owned an extension market screened
World of Warcraft service platform privately owned multiple extension markets for free
XBRL standard consortium a list of extensions paid
Open Design All. standard consortium a list of extensions paid
OSGi standard consortium a list of extensions paid
which are only available online and cannot be installed individually on a
customer's server. Finally, an ecosystem can be underpinned by a software standard,
such as the XBRL ecosystem or the Open Design Alliance, which bases most
of its technology around AutoDesk's DWG standards. Please note that some
technologies are based on other technologies and therefore may have an overlap
with those ecosystems. The case of Joomla, for instance, relies on a database,
a web server, and an operating system and its participants are all also
participant (sometimes unknowingly) in these other ecosystems. Furthermore, please
also note that we abstract from the technology used for platform extension (i.e.,
API, service call, plug-ins, apps). For an extensive discussion on extension
patterns the work of Jansen et al. [
Coordinators - The coordinators of an ecosystem are perhaps the largest in uence on governance: the owners have full control over the tools and methods that are used to increase the success of an ecosystem. A software ecosystem is either owned by a community or owned by a private party. An ecosystem that is controlled by a community is the Eclipse ecosystem. The Eclipse consortium controls the ecosystem and represents the wishes and commands of the consortium members, ideally. An ecosystem in which the technology is privately owned by a commercial party with typical commercial interests, usually exerts more control over the ecosystem. An example of a commercially controlled ecosystem is the iOS ecosystem, where Apple (the private owner of the underpinning technology) for instance determines what types of applications are accepted to the application store.
Extension Markets - Many of the software ecosystems are centralized around a market of extensions, also known as app stores or app markets. A software ecosystem can have no extension market, a simple list of extensions, an actual extension market, a comercial extension market, and multiple extension markets. When a software ecosystem has no explicit extension market, components may be available through known third-parties. An example of this is the AutoCAD ecosystem, where there is a short list of components on the Autodesk community site, but there exist many more extensions available only through third-parties that do their own marketing. A more mature way of handling extensions is a list of extensions. The methods of getting on the list are determined by the accessibility of the extension market. An example of the extension list is provided on the site of the three dimensional graphics platform Ogre3d, where developer contributions to the ecosystem are listed on a simple web page. The next level of extension market actually enables parties to distribute and even sell their extensions on the market. An example of this is the Firefox Extensions market, where third parties can o er their extensions, without having to pay the Firefox consortium. A commercial extension market is used by the owner to make money, with the obvious examples being the Android App Market and the iOS App Stores. Finally, some ecosystems, such as the XMBC and World of Warcraft ecosystems, have multiple extension markets. In the case of the World of Warcraft software ecosystem, the maker of the game did not want to create their own add-on store and left it to the market to create solutions for that. Several development hubs and add-on markets have been created, such as \curse.com" and \wowace.com".
Accessibility - Accessibility to an ecosystem is one of the de ning factors for an ecosystem: the ability to join an ecosystem and its barriers to entry determine what types of participants will play a part in it. For software ecosystems three accessibility possibilities have been identi ed: open source, screened but free, and paid. An open source ecosystem is one where it is possible to add contributions to a project, create and publish components in the extension market, etc., without any barriers. An example of such an open source ecosystem is the Rails ecosystem, where developers can simply add components (gems) to the community without anyone performing another check. Typically, however, a committee performs some quality control to make sure that a developer's contribution is of the right quality, such as with Eclipse Plug-ins and plug-ins for the Chrome browser. The most restricted is an ecosystem for which must be paid. An example of such an ecosystem is the iOS ecosystem, where a developer must pay a small amount before being able to publish applications in the extension market of Apple. When combining these four quali ers the following de ning sentence results:
The [NAME] software ecosystem is based on a fsoftware platform, software service platform, software standard g and is coordinated by a fprivately owned entity, community g with fno extension market, a list of extensions, an extension market, a commercial extension market, multiple extension markets g to which participants can submit extensions ffor free, after a screening, after making a payment g.
For example, the Apple iOS software ecosystem is described as follows: The Apple iOS software ecosystem is based on a software platform and coordinated by a privately owned entity with a commercial extension market to which participants can submit extensions after making a payment.
It must be noted that several quali ers were excluded, but may play a de ning role in describing a software ecosystem. One of those candidates was stickiness, based on the characteristics \network e ects", \switching costs", and \multihoming". The main problem with stickiness, i.e., how hard it is for participants in an ecosystem to switch to another, is that it can only be de ned in continuous scales instead of discrete terms as the quali ers do now. A second quali er that was excluded was entry barriers, which are highly dynamic and can change frequently. Another factor that de nes an ecosystem that was left out of the de ning statement is the number of markets that the ecosystem brings together. Most software ecosystems concern only two markets, such as AutoCAD users and AutoCAD plug-in builders. For other ecosystems, however, this is much more complex, such as for a mobile ecosystem in which extension builders, phone users, hardware providers, phone service companies and a central platform coordinator are brought together in one ecosystem. Finally, the market size has been excluded because a considerable (potential) market is considered a prerequisite for any software ecosystem.
Observation 1: Standards are a special kind of ecosystem. When studying the data, some patterns can be discovered. To begin with, standards are an interesting foundation for an ecosystem: multi-homing (i.e., the use of multiple standards) is always possible, they are generally managed by consortia with paid memberships, and standards are usually promoted using showcases as opposed to an extension market for software platforms.
Observation 2: Market ownership tells the story. Typically, in case a private entity manages the platform the ownership of the market lies in the hands of that entity. As a consequence, when there are multiple extension markets the platform is typically managed by a community (with the exception perhaps, of Android, which has multiple extension markets and a commercial one). If the extension market is a \commercial" market, i.e., money can be made by selling an extension in the market, it is always owned by a private party. When an ecosystem has multiple extension markets, they are typically openly accessible and do not require a fee up front. When extenders need to pay for an extension market to get their extensions in there, switching costs are typically high.
Observation 3: Freely accessible ecosystems also allow multi-homing. All ecosystems encountered that do not have a paid membership or entry barrier, as a logical consequence typically also allow multi-homing.
Observation 4: Extension lists have relatively high entry barriers. When an ecosystem coordinator manages a list of extensions instead of an extension market, it is typically hard to get onto the list. For most community-managed ecosystems getting onto the list means the extension needs to be approved by the core team of developers. For privately managed ecosystems, it requires approval of the platform leader and frequently involves joining the partner program.
Observation 5: Service platforms are always in the hands of privately owned parties. Due to the running costs of an online service, online service platforms are always managed by commercial organizations. Even Wordpress.com, which is based on the open source content management platform Wordpress, is managed by Automattic, a commercial entity that contributes to the Wordpress community actively.
Coordinators of software ecosystems have little insight into the governance tools
that are available to them. In this section a governance model for ecosystem
health preservation and improvement is presented, that provides ecosystem
coordinators with a set of tools for maintaining and improving the health of
the ecosystem, by stimulating growth, economic activity, and robustness of the
ecosystem. For each of the ecosystem health aspects, being robustness, niche
creation, and productivity, governance tools are provided. These governance
tools are provided for four di erent kinds of ecosystem coordinators. Software
ecosystem governance is de ned as procedures and processes by which a
company controls, changes or maintains its current and future position in a software
ecosystem [
forms are typically large open source products, but sometimes, such as in the case of IntelliCAD, closed source products that are managed by a consortium. Coordinators of such communities have to deal with independent individuals and organizations that use the platform for their own means, and these coordinators have to make sure the platform and its development process remain
Software (service) platform
Community Private Entity Expand applicability Expand applicability nMake strategy explicit Make strategy explicit
Create APIs Do co-development Dev. complementary platforms
Develop new business models
Form consortium ss CGrreoawtecosnusbogrrtoiuumps tesnu FRoarismeaellniatrnycbeasrriers b Stabilize APIs oR OMpaeken cuopngsoovrteiurnmanecxeplicit iittycv PCOarregrtaaictneipizkaentedoewinvlecddoagnyetsehsutsbs u d o r P
Create partnership model Do marketing Grow profits Partner development programs Form alliances Stabilize APIs Raise entry barriers Make partners explicit Propagate operation knowledge Organize dev days Collaborative marketing Create sales partner program Create new sales channels
Community Expand applicability Make strategy explicit Form subgroups Form consortium Grow consortium Raise memberships Form alliances Make consortium explicit Open up governance Start certification program Create showcases Create knowledge hubs
Standard
Private Entity
Expand applicability
Make strategy explicit
Form subgroups
Protect the standard legally
Do marketing
Raise memberships
Evolve platform
Make partners explicit
Start certification program
Create showcases
Collaborative marketing
Create new sales channels
active and healthy [
In regards to robustness, community coordinators must make sure the community remains as lively and stable as possible, to provide a strong core to which third parties can commit safely. In the beginning, community coordinators can form a community to formalize the way in which contributors and third-parties can assist in keeping the ecosystem healthy. Once the consortium is explicit, it can be grown by attracting new members. Furthermore, subgroups can be created to bring together domain specialists in an ecosystem, thereby further mobilizing the community itself. To make the ecosystem more stable, a community can further raise the barriers of entry, to create a critical mass of dedicated core members who are fully committed to the platform: in the case of the Eclipse platform several companies are providing millions of dollars in development for the platform, simply to be a strong steering member in the Eclipse ecosystem. Next to that, ecosystem coordinators can form alliances with other ecosystems to create further complimentaries and subgroups within the ecosystem. Furthermore, by stabilizing the API, the platform can become a slowly evolving core of functionality for the community. Finally, the consortium must be made explicit to show the world who are key members of the organization. As a nal step, the consortium can open up governance, to have the consortium govern itself through the years.
With respect to productivity, community managers have several tools available to make the ecosystem create more value. A typical tool to use is to raise awareness and activity surrounding the platform by organizing development days and by organizing and participating in contests that require the use of the platform. Finally, the creation of knowledge hubs enables participants in the community to share and nd knowledge, thereby making them more productive and e ective.
Privately owned software platform - Private owners of software platforms, such as Microsoft, Apple, and Autodesk, want to maximize their value by penetrating the market as deeply as possible. This penetration is reached mostly by associating with domain speci c parties that leverage the platform within the ecosystem to create value for customers that would have never been reached without these domain experts (i.e., niche players). Coordinators of these platform-based ecosystems are similar to communities in that they too want to continuously increase the use of the platform, however, the main di erence is that these coordinators want to maximize their pro t as well. When looking at niche creation, all the same tools can be used as community coordinators do: expand the applicability of the platform, make the strategy explicit, create APIs, do co-development with partners, and develop or contribute to complimentary platforms. Coordinators of commercial platform ecosystems, however, can also create niches and business opportunities by introducing new business models for third parties. A relevant example is that of the commercial extension markets that are on the increase, which enable third parties to make pro ts from customers they previously could not reach.
To increase robustness, the private company can do several things to create
stability and stimulate activity in the ecosystem. Typically, these start with the
development of a partnership model that enables third parties to participate
and create value in the ecosystem according to set roles and positions in the
ecosystem. Furthermore, the general strengthening of the hub and ecosystem
by doing marketing, raising prices, and growing pro t stabilizes the ecosystem
signi cantly (within limits). Partners with potential or weak partners can play
a strong role in (de)stabilizing the ecosystem, so the introduction of a partner
development program can strengthen weak participants and bring high
potentials closer to the ecosystem. An example of this is when Microsoft pays for
the development of new extensions in their Windows Mobile Application
Market. Also, the forming of alliances with other hubs in ecosystems, the raising of
entry barriers, and the propagation of software operation knowledge (i.e., how
the software and its extensions run at customers) throughout the ecosystem can
raise quality and stability [
With respect to productivity, coordinators of a privately owned platform can also organize development days to increase activity. Furthermore, collaborative marketing and sales can be done, to emphasize that smaller extending third parties have a respectable relationship with the platform leader. Finally, the creation of new sales channels to enable more revenue for the ecosystem participants can play a big part in productivity of the ecosystem.
Software standards are di erent from software platforms in that they represent not a platform or a software artifact, but a set of standardized interfaces to enable communication and exchange of information across di erent organizations. These standards organizations guard the standard and grow the ecosystem around it. Governance of these ecosystems is di erent in several aspects: the core of the ecosystem is knowledge, not a software platform. It is highly uncommon for a privately owned organization to set a standard, however examples are the DWG format of Autodesk, previously Adobe's PDF format, and Microsoft's O ce le formats. In the data set we did not nd many commercial organizations managing a standard, so the fourth column in gure 1 is mostly based on literature.
Community Driven Standard - Most standards are driven by a thriving community of participating organizations, all with di erent aims with the standard but with a common goal. Examples of such organizations are W3C, ISO, and many others. To create niches for a standard, its applicability can be extended to include new domains. Furthermore, when a standards organization makes its strategy explicit to the community, participants become aware of why and how the standard will bene t them and whether they are in direct con ict with the community or not. Finally, the establishment of subgroups is bene cial for the creation of new niches in which the standard can be applied.
In regards to robustness, di erent tools can be applied to increase it, such as the formation of a formalized consortium, the growing of the community, or the raising of memberships to strengthen the community organization and ensure its continuation in the future. The formation of alliances with other (complimentary) standards or platforms may also be bene cial, as it encourages further adoption of the standard. Also, the community can open up the governance of the consortium, for instance by establishing how decisions within the consortium must be made. Finally, a certi cation program enables an ecosystem coordinator to raise quality standards and establish certain partners as being highly valuable for the ecosystem.
In regards to productivity, it is hard for the standards organization to determine tools for increasing adoption and use of the standard. However, two tools that are available and widely used are the use of showcases of how the standard has bene ted the organization that uses it, and also the creation of knowledge hubs to inform participants from di erent domains about the use of the standard.
privately owned software standards, such as the Microsoft O ce File Format and the DWG File Format of Autodesk, used for the exchange of the 3D drawings. The way in which these ecosystems are formed and stimulated are similar to those owned by a community or consortium, with the only exception that the standard is typically partly closed and protected by intellectual property laws, to leverage the advantages of owning a widely used standard, such as the sale of APIs and libraries for the reading of such libraries. In regards to niche creation, private coordinators can apply the same tools as communities: expand applicability, make the strategy of the standard explicit, and form subgroups.
To increate robustness, the standard can be legally protected by using user licenses and intellectual property law. Furthermore, robustness is determined by the strength of the standard, so raising usage fees and doing abundant marketing for it will increase market penetration and stability. Also, the evolution of the standard keeps the standard relevant and outmanoeuvres competition. Finally, the usage of a partner program and possibly partner certi cation, further stabilizes the ecosystem.
In regards to productivity, knowledge hubs must be created, showcases can be used to show the e ect of using the platform, and collaborative marketing enables standards users to leverage their partnership with the standard ecosystem coordinator. Also, the ecosystem coordinator can assist by creating new sales channels, for instance by connecting niche players with potential customers in speci c domains.
The governance model as presented leads from the results from the survey,
and to a small extend from standards literature. The model does not, however,
claim to be complete. To achieve completeness, a structured literature survey
needs to be conducted, which is considered future work. The model can then to
be extended with the coring and tipping methods of Cusumano and Gawer [
This paper presents a model for classifying software ecosystems and hopes to present a de facto standard for presenting cases and survey results on software ecosystems. The model has been kept deliberately simple, but aims to illustrate the de ning characteristics of software ecosystems. With this model software ecosystem researchers can quickly gain insight into the characteristics that de ne any particular ecosystem. The classi cation model has been used to identify four di erent classes of software ecosystems. For each of these classes governance tools have been identi ed and presented in the software ecosystem governance model for health preservation and improvement.
At the current stage it is hard to claim completeness of both the classi cation model and the governance model for ecosystem health preservation and improvement. Part of the future work is to further evaluate the model with ecosystem coordinators and to perform a more extensive survey of software ecosystems for improved validation of the models. Now that a list of governance tools has been created, the applicability of the tools and the dependent situational factors must be determined. In the future we hope to create a software ecosystem governance maturity model that provides guidelines for improving software ecosystem governance, depending on the maturity of a software ecosystem and other situational factors.