Associate models are powerful tools for large software ecosystem orchestrators to manage clusters within its ecosystem. At present, however, it remains unclear how these associate models are used in practice and of what elements such models consist. Without an overview of what associate models consist of, the concept of software ecosystem orchestration will remain elusive. In this paper, a conceptual overview is presented that describes the structure of an ecosystem associate model. The conceptual overview consists of the roles ful lled by the participant within the associate commitment, including the dimension of the role as well as resulting bene ts, requirements and costs. Furthermore, the conceptual overview enables a categorization into di erent forms of associate model governance, entry barriers and goals for the three respective models. With the conceptual overview, software ecosystem orchestrators can develop their own associate models and attain insight into the forces that are at play in their own software ecosystem.
Software vendors and platform owners act within a network of actors relevant
to their business, called a software ecosystem. A software ecosystem is de ned
as \a set of actors functioning as a unit and interacting with a shared market
for software and services, together with the relationships among them"[
Software ecosystem orchestrators frequently choose to engage into a set of partnerships in the search for mutual bene ts. Some large software ecosystem orchestrators expand this principle to a larger scale by creating a cluster of organizations around themselves. Clusters, in this sense, are a number of actors that are grouped together. Organizations, such as software vendors, platform owners and open source associations use associate models to manage these clusters of participants in their ecosystems. In this paper, two of these methods are discussed in the form of partnership models and membership models.
A partnership model is owned by a software vendor or platform owner to sustain, manage, cluster and expand their partner ecosystem and therefore the number of actors within this ecosystem. A partnership model o ers organizations the possibility to engage into a partnership with a major software vendor or platform owner. In this model, the partner ful lls one or more roles that brings a certain set of prede ned bene ts. To be able to obtain or retain a role, the partner has to comply to a certain set of requirements and possibly has to pay fees to the cluster owner. Open source associations and platform owners o er a similar model to sustain, manage, cluster and expand their software ecosystem. Because of the di erent legal form of those organizations, actors within these clusters are members that are part of the membership model. Partnership and membership models are examples of big clusters of participants within one or more areas of the software ecosystem, or a subsystem of this ecosystem, referred to as associate models.
The emphasis of this paper is on the structure of associate models within the software industry and the identifying characteristics of commitments within those models. Few previous research exists within this speci c part of the software ecosystems research area. Understanding the structure of these associate models will improve the understanding of the implications of owning or participating in such a cluster can have. Also, the presented results are valuable for software ecosystem orchestrators when setting up their own a late model. The results presented in this paper are formulated around a conceptual overview that captures the structure of an associate model. Three case studies of large software ecosystem orchestrators owning an associate model, that are representative for those within the industry, provide support for the ndings presented in this paper. The cases will also be used to identify the main di erences between a partnership and a membership model through classi cation.
This paper continues with a description of the research approach in section two, in which we will elaborate on the research methods we employed as well as the data collecting process. In the third section, we present the result of a literature review, which gives an overview of what is already known about associate models. The created conceptual overview that captures the structure of associate models is presented in section ve. Section six provides an overview of the gathered data out of the three case studies, followed by a classi cation of these three cases in chapter seven. In section eight we draw the draw conclusions and provide suggestions for future research.
The main research question of this article is as follows; \What are the
identifying characteristics of a commitment within an associate model?" To be able to
answer this research question, a combination of literature review and case
studies is carried out. The gathered data from literature review and documentation,
large software ecosystem orchestrators provide on their cluster (e.g. website,
contracts), of multiple associate models form the basis for a conceptual overview.
This conceptual overview is created to describe the general structure of an
ecosystem participant cluster. The conceptual overview is created by applying design
science [
Associate models, owned by three large software ecosystems, that are
representative for those owned within the software industry, are used as cases for
this paper. Each case study did start out with studying available documentation
on the respective ecosystem participant cluster (e.g. website, contracts). Later,
a semi-structured interview has been conducted with a representative of each
of the cluster owners. For these semi-structured interviews we employed an
interview protocol to provide guidance during the session. The three models are
compared to identify the main similarities and di erences between them. We
chose for a multiple case design [
Software ecosystems exist around one particular software vendor or platform
owner. Jansen et al. [
A software vendor can have a wide range of goals with its ecosystem.
Popp [
Organizing a large amount of participants around an organization in a cluster
is a practice that happens not only within the software industry. The clustering
of participants is also a common phenomenon in other business areas, like the
automotive industry [
Because of the character of an ecosystem participant cluster, it requires a
governance structure to keep it manageable. The ecosystem participant cluster
consists out of multiple levels or roles in which the participants are clustered. Within
this cluster, every participant has one or more roles with prede ned
requirements, bene ts and costs. While in practice multiple associate models from
different software vendors, platform owners or open source associations di er from
each other, the main principles behind it are the same. Based on this, the core
structure of the di erent models used in practice are similar or consist of the
same core elements. With this observation and to illustrate this, a conceptual
overview is created to give a visual representation of the typical structure of an
associate model owned and utilized within the software industry. The model is
created on a type level, in Uni ed Modelling Language using modelling
techniques similar to those used in [
Figure 1 contains a conceptual overview that describes the structure of an associate model within the software industry. Such a model is described by a name, a description and an owner. Every associate model can be classi ed by a model type. The type that classi es the model in uences the primary structure and restricts the commitment possibilities that exist within the o ered model. The associate model consists of partnerships or memberships with organizations wishing to engage in them.
An organization can engage in one or multiple commitments with the model owner in which it ful lls a role. Each partnership or membership has a unique contract which is a commitment between two legal entities, the model owner and the organization that engages in the commitment. In practice this means that, for every role an organization ful lls within an associate model, a separate contract will be signed by both legal entities. A role within the associate model is characterized by a name and a description and can have zero, one or more dimensions. This can be best explained by an example. A software vendor owns a partnership model that is hierarchical, the primary structure consists of three levels (i.e. bronze, silver and gold). Within these levels there is a next level of decomposition, a horizontal one in which partners are organized by their respective functions (e.g. system integrator, value-added reseller). This means there are partners that ful ll a role as a bronze level system integrator and other partners ful ll the role of a gold level system integrator.
Furthermore, every single role has a set of prede ned bene ts for an organization. On average, a wide range of bene ts is o ered or expected, ranging from marketing bene ts or coaching to getting access to the source code of software products for the highest level partners or members within some models. To receive those bene ts, a set of requirements have to be met by the participant in order to be eligible to ful ll or to retain a certain role. The requirements that an organization has to meet may be de ned by some of the speci c organizational characteristics of the participant. Geographic location or total corporate revenue for example might in uence the requirements to be met. Furthermore, requirements for a system integrator might di er from those of a value-added reseller even if they have the same level or role within the model.
An organization that is willing to become part of a cluster within the partner or software ecosystem pays to be eligible to ful ll a certain role. Exceptions to this are educational and community memberships, in which participants get small bene t from or contribute to the community of organizations that are active within the parts of the ecosystem that are targeted with the associate model. Usually, an annual fee has to be paid at the contract renewal date, however, model entrance fees as well as additional fees might be applicable. In some cases, speci c characteristics of the organization might a ect the costs for engaging in a partnership or membership. Companies with di erent geographic locations or a di erent total corporate revenue might pay di erent fees, as stated in prede ned tables or scales.
Three large software ecosystem orchestrators, each possessing their own associate model, that are representative for those within the software industry, have been selected as case studies for this paper. Each case study started out with studying the documentation on the respective model that is publicly available (e.g. website, contracts). With the gathered knowledge out of documentation, the conceptual overview and the literature review as a basis, a semi-structured interview was conducted with an expert from each of the three organizations to gather additional information with regard to their associate model. For this, we utilized an interview protocol to provide guidance during the session. The topics of interest within these case studies include; model structure, bene ts, requirements, entry barriers and goals strived for by the model owner. The case studies are used to further evaluate the conceptual overview as well as to gather additional information about the three respective models.
SAP is a major player within the global enterprise application software market with their platform, products and services. The partner ecosystem is a substantial component of the SAP software ecosystem and is managed by their own partnership models. Those include a global partnership model and several region-speci c partnership models. The global partnership model is constructed around ten di erent function-based roles targeting speci c type of partners, like service providers, software partners and value-added resellers. Within some of these roles dividing partners further into market- or function-based categories is possible, this is however not regarded as a second dimension within the model. Furthermore, the model contains one, more general, umbrella role; the SAP PowerEdge Partner Program. In the SAP partnership model, partners can ful ll more than one function-speci c role. The partnership model is documented on di erent parts of the SAP website. Internal documents and contracts are not publicly accessible.
Each role has a speci c set of bene ts, requirements and costs. Upon request small changes to these sets can be made. Bene ts and requirements per role are targeted on speci c needs for the type of partner that ful lls a role. Requirements involve completing a certi cation process for services, tools or software solutions that are somehow related to SAP or the SAP platform. Bene ts range from marketing bene ts to revenue sharing agreements with SAP, SAP incorporating a solution within their products or getting access to the SAP customer ecosystem, to sell products or to o er additional services. The partnership model is utilized by SAP to reach various goals, ranging from extension of the partner ecosystem, product or platform development and co-innovation to monetizing on the partner ecosystem and extending market reach. SAP actively monitors the performance of their partners, so that good performing partners can progress from certi cation partners to, for example, resellers.
Apart from the annual partnership fee, the certi cation process can be regarded as a main entry barrier for the model. A partner has to devote resources to create a product that is eligible to successfully pass the certi cation process. Furthermore, potential partners are screened on their involvement in or with other platforms. This means that a partnership with SAP becomes a main part of the business, but on the other hand that also means a partner can lock himself out of participating in another partnership model within the industry that has a similar policy.
The Open Design Alliance is best described as an association of developers. The nonpro t organization develops the Teigha platform, a platform for CAD and other technical graphics applications. ODA is a member-driven organization and their membership model, that consists of over 1200 members, is the core of the organization. Organizations that want to obtain or use the Teigha platform have to enter the membership model. The membership model of the ODA can be best described as a layered model without a second level of decomposition. The model consists of ve unique levels. The main bene t of each level is targeted at the amount of access members have to the Teigha platform. Ranging from the inhouse use of the platform to access to obtaining access to the source code and no restrictions in the way the platform is used or incorporated. Additional bene ts for each level are mainly targeted at the amount of in uence a member has on the development of the platform or the way in which it wishes to contribute to the development. Each organization that wants to become part of the model can only apply for one membership level and customizations to these levels upon request will not be made.
Apart from the educational membership, which is designed to stimulate research, every membership level requires an annual membership fee to be paid. When a new member desires to enter the membership model it has to pay a one time only membership model entrance fee. The additional entrance fee can be regarded as a raised entry barrier for the membership model, the Open Design Alliance did however opt for this approach to stimulate members to engage into long-term commitments. By making all the documentation on the membership model publicly available, the ODA aims to make the membership model and its principles as accessible as possible.
The main goal the ODA has with their membership model is the expansion of the Open Design Alliance software ecosystem. Another goal ODA has with their membership model is the development of their platform, a product related goal. The majority of membership model fees ow back into development and in cooperation with members new features or additional functionality can be incorporated into the platform. The ODA aims for a certain level of empowerment between members and platform owner as well as creating a supportive community around the platform.
The Eclipse Foundation is a member supported corporation that provides a platform, tools and services for the Eclipse software ecosystem. There are multiple ways for organizations to contribute to the development of one or more Eclipse platforms or solutions. They can make donations ( nancial or resources), can become a corporate sponsor or can become a more prominent part of the Eclipse software ecosystem by becoming a member. If an organization wishes to become a member it will take part in the Eclipse Membership Program.
The Eclipse Membership Program consists of ve di erent levels. The membership model is based on the open source maturity curve. This maturity curve predicts the way in which an organization intensi es their involvement in an open source community over time as it evolves and develops as an organization. Because of this, every next membership level can be considered as superior to the previous one. Therefore, it is highly unlikely that an organization will occupy more than one membership level. Prede ned membership levels will not be customized upon request of a potential member, they can only choose to not be publicly listed as a member.
Bene ts per membership level range from contributing to the platform or Eclipse solutions, to in uence in the overall governance of the Eclipse Foundation, since Strategic members get one seat within the board of directors. Furthermore, higher level members can bene t from industry speci c working groups in which fellow members cooperate and co-innovate the Eclipse platform to suit industry speci c needs. To maintain or occupy a higher membership level, an annual fee has to be paid. For most membership levels additional requirements have to be met. Organizations will, for example, have to release a solution, with incorporation or extension of the Eclipse platform, within twelve months after becoming a member, or will have to devote a certain number of full-time developers to the development of the Eclipse platform or tools. To lower entry barriers for certain levels, requirements or annual membership fees are adjusted to speci c organizational characteristics like the total number of employees or total corporate revenue. The main goals the Eclipse Foundation has with their membership model are further expanding the Eclipse software ecosystem, the development of the Eclipse Foundation platform and tools as well as getting a higher level of involvement from actors within the software ecosystem.
To compare the three associate models, as presented in the case studies, a
classication table has been created. A number of characteristics for associate models
has been derived from the conceptual overview, the interview protocol and the
content of the case studies as well as the software ecosystem goals described by
Popp. [
Table 1 contains a classi cation of the three studied associate models. It gives an overview of the di erent characteristics of each of the models, ordered within di erent categories. As became clear in the case studies, the structure of di erent associate models can be described by one conceptual overview, regardless the type of platform o ered (e.g. open or closed source), the type of the model (e.g. partnership or membership model) or the primary structure of the cluster.
Both open source platform owners posses an associate model in the form of a membership model, while SAP owns a partnership model. The membership models have a layered primary structure that is based on increasing involvement of organizations in their contribution to open source projects. This is most explicit in the Eclipse model, which is entirely constructed based on an open source maturity curve. While the layered models are based on contribution to the platform, SAP manages their model out of a business performance point of view. By monitoring the performance of their partners they can choose to up-scale the partnership agreements from a certi ed partnership to a reseller agreement. This possibility should enrich bene ts for both parties in the form of, for example, sharing revenues. Because of this, partners do not progress through levels or roles, they rather evolve within their existing role.
The other di erences in characteristics between the three associate models are caused by the di erences in primary structure between the respective clusters. The function-based partnership model has a richer set of roles because it has to suit a wide range of business needs, for di erent kinds of organizations as well as for themselves. For this reason, partners can ful ll more than one role in a partnership model when they provide a broad range of services. In the Eclipse membership model this is theoretically possible as well. This, however, will not happen because higher levels are regarded as superior to previous ones.
One of the important categories of characteristics, besides the structure of the model, are the identi ed entry barriers. Each role or level a participant ful lls or occupies within an associate model comes with certain costs. All model owners charge the participants acting within their model with an annual fee, except for the educational and community roles or memberships that are free of charge. In addition to the annual fees, ODA includes one time only membership entrance fees into their model, to both protect their intellectual property and to stimulate members to opt for a long-term commitment.
Furthermore, contributing resources is regarded as a main entry barrier. In both membership models resources will have to be contributed to product and platform development. In the Eclipse model, for example, it can be required for a participant to contribute a number of full-time developers to platform development. The same in a di erent form goes for the SAP partnership model. To be able to become a partner, an organization has to certify their product or service so that they comply with guidelines provided by SAP. Organizations will have to devote resources in order to do so. Devoting resources to co-innovation with SAP is also a possibility. An additional entry barrier for the SAP partnership model is a result of their model governance. Organizations can lock themselves out of the model by having a high level of involvement with another large software ecosystem (for example as a reseller), while a lot of involvement with SAP can lock them out of models o ered by competitors of SAP.
All three software ecosystems aim for a wide range of goals with their ecosystem participant cluster. For all three organizations, network related goals are a main reason to own an ecosystem participant cluster, to utilize this cluster to expand their software or partner ecosystem and therefore the number of actors within this ecosystem. For ODA, their membership model is the core of their business, which makes the model even more prominent to achieve goals. For the membership models, the main goals are product related goals. Both ODA and Eclipse strive to utilize their membership model to develop and innovate their platform. For ODA membership fees ow back into development, while members also actively contribute, by for example, creating new functionality on top of the existing platform. Higher level Eclipse Foundation members contribute full-time resources to the development of the Eclipse platform. In the SAP partnership model, product related goals are less prominent, however, co-innovating with partners to strengthen SAP o erings is a goal strived for.
Financial motives for Eclipse and ODA do exist, because of the membership fees, for SAP those are more prominent. They monetize on their partnership model by receiving annual fees, but apart from that they strive to create additional revenue streams. Those revenue streams can be a direct result from partner performances within a certain role but can apart from that also be created by reseller or revenue sharing agreements. Market related goals are most relevant for SAP as well. SAP utilizes their partnership model in an attempt to increase market presence through the ecosystem of their partners. Furthermore, they can enter markets leveraging their partners.
The main reason for the identi ed di erences comes with the di erent legal form, the type of platform and the business model of the three respective organizations. As a consequence, the associate models have a di erent position and target area within the organization and parts of the ecosystem. SAP is a pro t organization, while both ODA and Eclipse are a non-pro t association with members. As a consequence, the membership models o ers a set bene ts that covers a wider range. Bene ts are not limited to platform, nancial or strategic related bene ts. Rather bene ts stretch a wide range, including in uence in the actual decision making process within the association. Because of the difference in organizational structure, ODA and Eclipse membership levels are not customizable, while the roles in the SAP partnership models are. Open source associations are slim organizations that aim to reduce administrative pressure by containing a rigid governance regarding customizations.
In this paper, we addressed two ways in which a large software ecosystem orchestrator can manage clusters within its ecosystems, through partnership and membership models. These models can be utilized to achieve di erent goals, depending on their business model. associate models consist of a set of commitments between model owner and participant. Although partnership and membership models di er from each other, their overall structure is the same. By applying design science, a conceptual overview has been created to capture the structure of associate models. In every commitment within such a model, a participant fullls one or more roles with a prede ned set of bene ts, requirements and costs. Roles have zero, one or more dimensions enabling participants to engage into multiple levels of commitments with the model owner. Although the conceptual overview has been created based on multiple partnership and membership models, not limited to the three case studies presented in this paper, more research is needed to further evaluate and validate the conceptual overview.
The created conceptual overview, the interview protocol and ndings from the literature review did provide the basis for multiple associate model characteristics, that form the basis for a classi cation. Since the characteristics have been selected independently from the actual content of the case studies these characteristics can be used to classify other associate models utilized within the industry. Di erences in structure between the three studied associate models are identi ed, the membership models are layered, while the partnership model is role-based. The way in which participants develop within the model overtime differs. Within the membership models, participants progress through levels, while in the partnership model participants evolve within their existing role. Financial motives, the devotion of resources and a high level of involvement with another platform, are main entry barriers for the associate model that can keep potential participants from participating. Furthermore, the way in which large software ecosystem orchestrators strive to achieve goals with their associate models di ers. The generalizability of identi ed di erences between partnership and membership models is limited because of the small number of case studies employed and because the information does not come from an independent source. However, the majority of di erences identi ed are a result of organizations di ering from each other in legal form, di erent business models and the type of platform they posses. Strategical decisions in uenced by these factors re ect back in the characteristics of the associate model and the set of commitments it consists of.
Although previous research exists on associate models, especially partnership models, little research exists out of a participants' perspective. Since participating in an associate model a ects or changes the business model of a participant, further research has to be edged on advantages, risks perceived as well as disadvantages, resulting from participating within an associate model. This also includes goals and expectations, organizations have with participating within such a cluster. Furthermore, studying the community-e ect within these associate models out of a model owner' perspective may help improving the collaboration between actors within this cluster.