A Power Perspective on Software Ecosystem Partnerships

Abstract

To address today’s market demands for continuous enhancement of systems capabilities, software producing organisations have increasingly formed or joined software ecosystems. In these complex and networked settings, they define partnerships to complement each other’s features, acquire new skills, divide R&D costs and share customers. Such business model entails mutual dependence on companies for survival and effectiveness. It creates a flow of influence among them and makes the ecosystem resemble power-law distributions. Drawing on established concepts from Social and Behavioural Sciences, we performed an exploratory case study of six software companies to investigate their power-dependence relationships in an ecosystem environment. A prime result of this research is showing that it is possible to understand how power and dependence influence the behaviour and coordination of partner firms within a software ecosystem.

1 Introduction

Software companies have increasingly recognised that product and process innovation alone are no longer sufficient to successfully market their technology. To stay competitive in current fast-moving economy, they have adopted innovative business models by changing the dominant logic of doing business [26]. The emergence of cloud platforms, the explosion of data and the development of new avenues for information have led these firms to gradually build proprietary software ecosystems around their products. In parallel, free software is a promising platform for open-source software ecosystems, which are leveraged by active collaboration of community developers.

These ecosystems result from the strengthening of multiple, bi-lateral alliances among complementors. As competitors in the IT industry and collaborators in joint development initiatives, software firms have embraced coopetition, i.e. relationships between companies that cooperate in some activities while compete in others. They are constantly facing the interplay of power and dependence, which are driving forces of their partnerships. The power exerted by companies in business-to-business contexts influences business models for value co-creation as well as market dominance. Hence, power is a critical aspect of interfirm relationships in business networks [19].

This paper reports on an exploratory case study that analysed power-dependence relationships between partners in proprietary software ecosystems. We interpret this phenomenon in light of established work from Social and Behavioural Sciences theorists, using a conceptual framework of multiple facets of power. Furthermore, we discuss our findings from the perspective of ecosystem governance and health [1].

Our contribution is twofold. First, we describe different power types and a structured way of modelling power directions in a dyad. We then analyse the power flows in the partnerships and their outcomes in the ecosystems. Second, we offer empirically grounded knowledge and raise a theoretical discussion that is relevant for future research on software ecosystems [9], as a growing field in software engineering (SE).

The rest of the paper is structured as follows: in Sect. 2, we present the research fundamentals. In Sect. 3, we detail the research design. Section 4 describes the results, while Sect. 5 discusses these findings. Finally, in Sect. 6, we conclude the paper, with implications and future work of this research.

2 Background

2.1 Software Ecosystems

The notion of software ecosystem adopts concepts from business and biological ecosystems to analyse the dynamics of today’s software industry [2]. For Jansen and colleagues [13], a software ecosystem consists in a set of businesses functioning as a unit and interacting with a shared market for software and services, together with relationships among them. It represents a disruptive open business model strategy that proposes novel ways for a central firm to collaborate with partners, and for them to create and capture value from the network [26].

According to Campbell and Ahmed [3], one can describe a software ecosystem from a business, architecture and social dimension. The business dimension comprises factors such as vision, innovation and strategic planning. It involves the definition of business strategies (e.g. profit and revenue models) and partnership model (e.g. membership models serving participants). The architecture or technical dimension focuses on technological aspects of the ecosystem. It is concerned with products from third parties, generally developed and integrated through a common platform. Finally, the social dimension consists in the relationships among software firms/developers in the associated social ecosystem. It includes the motivations to build alliances, rules for social interaction, and opportunities to show and enhance actor’s capabilities [17].

There are two main types of software ecosystems: proprietary and open source [17]. In a proprietary ecosystem, the source code and other artefacts produced are protected and new players usually need to be certified to join the network. It is the case of iOS ecosystem, in which external developers guarantee a steady flow of apps for Apple’s iPhone, or SAP ecosystem, in which a thriving community of resellers enables SAP to be Europe’s largest software company. In its turn, an open-source ecosystem has a generally flexible certification criteria and actors who participate independently from receiving revenues from their activity. Android is an open source ecosystem, with participants that develop apps or plug-ins for the software platform.

Actors in software ecosystems play different roles, with specific duties. The keystone or orchestrator is a company, community or independent entity responsible for running a technological platform, creating and applying rules (e.g. quality standards), and managing the participation of actors. Niche player is a company, person or entity that complements the platform by developing specific features that customers require. Value-added reseller (VAR) is a company that makes profit from selling ecosystem products. Finally, users acquire and use an ecosystem solution or service to carry out their business or perform personal activities [9, 17].

The keystone is the main responsible to orchestrate ecosystem members and coordinate development efforts on top of the software platform. Moreover, this firm is responsible for software ecosystem governance, which involves the creation of procedures to control, maintain, or change the ecosystem [1]. It includes business and technical aspects such as management of the platform and interfaces, definition of a sustainable business model, and development of partners [25]. A successful governance strategy leads to a healthy software ecosystem. It brings a growing number of opportunities for participants and a great ability to innovate by transforming inputs into new products and services with lower costs [1, 10, 12].

2.2 Power and Dependence

According to Emerson [8], power is not a property of an actor or group. It derives from the existence of a relationship, which implies on specifying over what/whom power is exercised. The power of an actor A is thought to be the inverse of the dependence of an actor B, bringing the idea of a power-dependence relationship: the power of A over B is equal to, and based upon, the dependence of B upon A.

Lawler [16] considers power as a structurally based capability of an actor. Hence, an actor can rely on a power capability (PC) to exert influence over another party. This PC can be positioned according to French and Raven taxonomy [20], which is formed by five core power types or bases: coercive power, expert power, legitimate power, referent power and reward power. We depict these forms of power in Table 1.

Table 1. Main types of power [20].

The total amount of power in a relationship is not fixed, but variable [16]. It means that power is a contingent and dynamic construct, which is constantly negotiated in the course of a relationship [15]. Hence, there may occur shifts of existing power, e.g. one party gains power while the other’s power remains constant. Such dynamism results from changes in an actor’s sources of power. They represent tangible or intangible resources or outcomes that he exploits to affect the behaviour of another actor [6]. Any change in the availability or demand for such power sources may affect power distribution in a dyad (i.e. interaction between a pair of firms).

The analysis of power is a means to explain behaviour and balance a dyad. When mutual dependence differs, there is a power advantage for one party, e.g. if A acts as less dependent and more powerful, B may comply with requests from A, since B is less able to resist. By tactically manipulating his PCs, an actor can obtain a power advantage and rebalance a relationship. Too imbalanced dyads may be dysfunctional, since a powerful actor may pursue short-term exclusive interests. This actor may also appropriate a larger portion of overall benefits accruing from the dyad [4]. In addition, certain forms of power may not sustain long-term development of the relationship, as there shall be undesirable exchange conditions and levels of uncertainty for one party.

Emerson’s definition is a common operationalisation of power in studies on inter-organisational settings, with increased academic interest in recent years [18]. These studies primarily draw on the power base theory from French and Raven, which was originally presented in the book ‘Studies in Social Power’, in 1959, and is one of the most adopted conceptualisations of power [7]. These authors underpin the conceptual framework that we use in this paper to analyse power-dependence relationships between studied companies in a software ecosystem.

3 Research Method

This research analyses the interplay of power and dependence in software ecosystems. We translate this goal in the research question: how power and dependence manifest in partnerships between companies participating in a software ecosystem? To answer it, we performed an exploratory case study, which is appropriate when there is little evidence about a phenomenon and researchers seek new hypotheses [22]. The qualitative data collected enabled us to examine specific aspects of the phenomenon, such as situations when a firm gains power, and decisions that reduce the dependence of a partner. The study involved six companies that participate in a software ecosystem.

3.1 Data Collection

We collected empirical data through semi-structured interviews, which provided an in-depth understanding of the exercise of power and the consequent notion of dependence in an ecosystem. The interview protocol¹ covered partnership strategies, technical and social issues. We guaranteed that the same basic structure was followed in each interview, although we asked new questions according to interviewees discourse. To map other partnerships and ecosystems, we used a snowball sampling and asked interviewees to recommend other firms and participants based on their expertise.

The case study started with the CRM Software Company, where we interviewed the CEO and a developer. This company is a Microsoft VAR and has partnerships with the software firms here named as Data Integration Company, E-mail Marketing System Company, Financials Software Company and Insurance Software Company. We also interviewed the CEOs of the Insurance Software Company and Financials Software Company to enrich partnerships information provided by the CRM Software Company. In addition to the interviews, we adopted the analysis method from Romano and colleagues [21] to examine web-based qualitative data. We retrieved data from the websites of these firms to analyse their product portfolio, partners, marketplace and news pages. We also searched IT news portals, since most of these firms have an international operation that makes them subject of evaluations from such websites.

3.2 Data Analysis

Initially, one researcher generated the interview transcripts and another researcher verified them to validate the text, clarify interviewees’ expressions and discuss the findings. This procedure turned the findings more concrete by reducing misunderstandings. In addition to interviews data, we collected evidence from firms’ portals and news websites. We adopted Thematic Analysis (TA), which is one of the most common methods for synthesising evidence in SE and particularly useful in case studies [5]. TA aims to identify, analyse and report patterns within data. This coding procedure generated themes and sub-themes related to the ecosystem scenario, such as ‘technological platform’ and ‘software product management’. This structure helped us to organise the data set in rich detail, preparing it for a conceptual analysis.

In this subsequent step, we relied on our theoretical framework, without which TA would have limited interpretative strength. We used an abductive reasoning and adopted established theories from Social and Behavioural Sciences (c.f. Sect. 2) to describe our findings. We considered Emerson’s statement that power resides in the other’s dependency [8] to examine the power-dependence relationships, here represented by the partnerships. We identified the power capabilities (PC) [16] held by partners, which enabled us to denote situations of power exercise in the ecosystem. We just considered PCs identified by our data analysis, since we are not performing a general investigation of the companies in their segments. It means we only listed PCs supported by collected evidence. This decision increases the validity of our study, since we kept a clear chain of evidence while drawing our conclusions. We labelled each PC with the code PowerType_CompanyCode_Number, where PowerType means the form of power exercised by the firm (cf. Table 1), CompanyCode indicates the firm (CA - CRM Software Company, CB - Data Integration Company, CC - E-mail Marketing System Company, CD - Financials Software Company, CE - Insurance Software Company and CF - Microsoft) and Number is the number of the PC (01, 02, and so on). For instance, LE_CA_02 means the second power capability of legitimate power type exercised by the CRM Software Company over an ecosystem partner.

We created schemes to represent the use of power capabilities by companies in a software ecosystem. A directed arrow indicates an activity that expresses a form of power exercised by a firm in a given situation of the partnership. In addition, the schemes indicate the correspondent source(s) of power used by partner companies.

3.3 Case Companies

The CRM Software Company (CA) was founded in mid 90 s. It has 30 employees and serves about 400 customers from IT and financials markets in Benelux. The firm’s business model completely depends on Microsoft: it is a VAR of Dynamics CRM. It adapts the product to different verticals by offering templates (functional modules), toolbox (solution to build such templates) and connectors (solution that enables data exchange between Dynamics CRM and other systems). It has focused on software integration via connectors to act as niche player in multiple software ecosystems.

The Data Integration Company (CB) was founded in 1995 and is a leading provider of CRM integration solutions worldwide. The company built an ecosystem around an integration platform, which has over 1.200 partners. Integration providers get access to 12.000 clients from diverse markets after joining the partner program as VARs or system integrators. They build their solutions on the platform or sell existing ones. Its Microsoft partner program provides standard connectors for Microsoft Dynamics.

The E-mail Marketing System Company (CC) is a 10-year-old company with 40 employees. The company provides solutions for the marketing domain and has over 2.700 customers. Based on its e-mail marketing system, it raised an ecosystem of over 130 partners. It particularly invests in integration partners, e.g. firms that develop connectors that allow clients to send newsletters from their ERPs or CRM systems.

The Financials Software Company (CD) has existed for more than 30 years. It is a market leader for cloud accounting in Benelux, with 500 employees and a portfolio of products for financial, accountancy and related domains. It has an expanding software ecosystem around its solutions, with more than 160.000 clients. A third party can join this network after becoming an app centre partner. Generally, partners build extensions in the form of connectors that the firm will later offer in its online marketplace.

The Insurance Software Company (CE) is a 30-year-old firm with 180 employees. It provides a cloud-based and modular SOA insurance system, with policy and claim handling modules, for Netherlands, UK, Belgium and South Africa markets. It has gradually created an ecosystem as a means to go forward in Netherlands competitive software industry. It focuses on its competencies and relies on small implementation partners who provide complementary features and consultants who sell its products.

Finally, Microsoft (CF) was founded in 1975 and it is the world’s largest software vendor in terms of revenue. Its Microsoft Dynamics solution consists in a line of ERP and CRM applications. Dynamics CRM focuses on sales, marketing, and service sectors, relying on an ecosystem of 640.000 partners who use a .NET-based framework to build customisations. Microsoft certifies these firms as VARs and enables them to access cutting-edge technologies and potentially reach a base of 40.000 customers.

4 Results

This section answers the research question by describing how power and dependence manifest in partnerships within a software ecosystem setting. Our analysis takes the perspective of the CRM Software Company as VAR of Dynamics CRM ecosystem and niche player of other ecosystems, in which it provides connectors for Dynamics CRM. We adopt the three-dimensional view of software ecosystems from Campbell and Ahmed [3] to describe power distribution in the partnerships and introduce the power capabilities of the companies based on French and Raven power forms [20].

4.1 Business Dimension

The business dimension involves the creation of an ecosystem vision, which generally consists of disseminating product and platform goals to inspire participants to follow them. This dimension embraces the definition of an innovation strategy to support the continuous improvement of processes and products. It also includes the creation of a strategic plan to understand how, when and who will perform the goals [3, 23]. In particular, the keystone may open up governance policies and allow the community to influence them. In this case, this firm gives power to partners as they start to participate in ecosystem decision-making process [14].

The studied networks are in an expanding phase and their initial keystones (Data Integration Company, E-mail Marketing System Company, Financials Software Company, Insurance Software Company and Microsoft) are in charge of ecosystem governance. It differs from open ecosystems, where this duty is generally shared in a committee (e.g. product managers, partners and users). Keystones define how much power is left to members and how much they keep for themselves. Frequently, studied firms not just provide partners with a comprehensive view of the platform and product roadmaps, but also share decision rights. For instance, the Data Integration Company has a voting system for partners to make trade-off decisions that a product manager does. They register feature requests to improve integration tools and assess the value of other partners’ ideas. The keystone then shows its dependence on partners to fulfil untapped needs and leverage ecosystem innovation, as perceived in the arguments of the Financials Software Company CEO: “to what extent I want to be a certain product (or) leave it to others? I said (this) when he (marketing director) asked me how to build this ecosystem: ‘create space; if (partners) don’t have space, they gonna suffocate and there is no money for anybody; nobody is gonna work with (the ecosystem)”.

Partners such as the CRM Software Company obtain the legitimate power to influence management plans of the ecosystem (LE_CA_01). By sharing this power with external actors, studied keystones allow partners to adjust ecosystem focus, e.g. technologies to develop, features to include in future release. Hence, keystones benefit from the convergence of development efforts in the network. Figure 1 shows this power.

Fig. 1.

Legitimate power (LE) of the CRM Software Company over keystones

4.2 Social Dimension

The social dimension of an ecosystem involves the factors promotion, utilitarianism and knowledge sharing. Other aspects related to this perspective are recognition from peers, reputation, learning and sense of code ownership, for instance [2, 3]. The keystone must explore these factors and not simply open a platform to obtain extensions from third parties. The success of a software ecosystem depends on how adequately a firm engages with other peers and creates a collaborative and innovative environment.

By structuring a software ecosystem and positioning itself as a keystone, a firm reinforces its expert power, i.e. superior abilities or information. The recognition of such expertise by external actors may generate a feeling of membership and desire to join the network. The reliance of the CRM Software Company on the vast know-how and robust products of Microsoft (EX_CF_01) motivated the firm to define Dynamics CRM as a foundation for its solutions. It also trusts the platform and tools of the Data Integration Company (EX_CB_01) to develop connectors for SaaS, cloud or hybrid scenarios, as cited by the CRM Software Company CEO: “They (Data Integration Company) are a market leader in connectors”. Partners’ knowledge is critical for the firm, which previously had to develop connectors from scratch, using web services.

Despite the expertise of the E-mail Marketing System Company, Financials Software Company and Insurance Software Company, respectively, in e-mail marketing (EX_CC_01), finances control (EX_CD_01) and policy/claim handling (EX_CE_01), they depend on the CRM Software Company to extend their product portfolio. The CEO of the Insurance Software Company CEO explained the importance of complementors to fuel the ecosystem with specific features: “we have organisations such as CRM Software Company around us that provide additional functionality to our own (, which is) not that special need that we want to develop ourselves”. The need for the expertise of partners was also mentioned by the Financials Software Company CEO: “these are the areas that we don’t cover with our own product – this is where we are going to find apps; you won’t be able to do it without an emergent ecosystem”.

The dependence of these companies gives power to the CRM Software Company. Hence, this firm expresses its expert power on CRM (EX_CA_01). It links Dynamics CRM with other solutions via connectors, resells this product and enables clients to optimise it with a toolbox and templates. “For certain verticals you have to adapt it (Dynamics CRM); we got 4 templates (and) developed an editor where you can build templates; there is a need for CRM and they (partners) don’t want to build it themselves; we build this connection; we got expertise in this product; it is integration; connector sales”, detailed the CRM Software Company CEO.

This context describes the role of expert power in a partnership, which involves the knowledge a firm has in a given domain, product or technology, as shown in Fig. 2.

Fig. 2.

Expert power (EX) of the CRM Software Company and keystones

Microsoft and other keystones may directly promote ecosystem participants via an associate model, which enables them to obtain and manage partners. In a proprietary ecosystem, a partnership model defines roles and duties that external actors may play in the network while they manipulate software artefacts and information [24]. This instrument specially states the benefits resulting from the adoption of the platform and presents strategies to generate value from the partnership. By creating incentives, the keystone highlights ecosystem utility and fosters partners’ engagement. In their turn, partners enable the keystone to offer complements and access new technologies [23].

We perceived that all firms have the ability to generate advantages for a partner, which denotes their reward power. Microsoft benefits the CRM Software Company with Dynamics CRM VAR certification (RW_CF_01), which involves technical support in product deployment and maintenance, and commercial support via licensing, pre-sales and marketing actions. Moreover, it lists the solutions of the CRM Software Company at Microsoft Pinpoint, a wide marketplace for clients to search applications and services based on Microsoft technologies. “This one (Dynamics CRM ecosystem) has 40.000 customers”, explained the CEO of the CRM Software Company.

Microsoft ecosystem also offers a key asset to partners: Microsoft’s strong image as one of the world’s most valuable and successful firms. “CRM is a bigger ecosystem; if they (partners) say ‘this is CRM Software Company add-on’, no one knows the firm; if they (clients) see Microsoft logo, they click and buy”, argued the CEO of the CRM Software Company. This niche player recognises Microsoft’s referent power (RF_CF_01), using such reputation to promote its sales (Fig. 3). This visibility is far more relevant than that of small-to-medium partners of the CRM Software Company such as the E-mail Marketing System Company or Insurance Software Company.

Fig. 3.

Referent power (RF) of Microsoft over the CRM Software Company

An indirect benefit from Microsoft VAR certification is enabling the CRM Software Company to reach other networks. The firm was certified as system integrator in the software ecosystem of the Data Integration Company, which has a Microsoft partner program (RW_CB_01). This keystone provides partners with an API and integration tools as well as developers to support connectors’ construction. In addition, the Data Integration Company enables partners to access an online marketplace and promotes their expertise by publishing customer stories involving the extensions. The CRM Software Company developer reinforced the success of this ecosystem: “(It) is a new platform; there are lots of partners developing connectors for it”.

The E-mail Marketing System Company grants an integration partner certification (RW_CC_01) to the CRM Software Company. It does campaigns about the CRM Software Company connector on its website, where customers can buy it and receive further assistance. Similarly, the Financials Software Company certifies the CRM Software Company as app centre partner (RW_CD_01). The benefits include free access to APIs, participation in workshops and developer resources. It also publishes partners extensions at an apps centre, enabling them obtain new customers: “they have business apps from third parties and we are one of them; (its) online (platform) is an accountancy program (with) 160.000 customers”, described the CRM Software Company CEO. In addition, the Financials Software Company organises business events to foster interaction among niche players.

In Fig. 4, we represent the dynamics of reward power in the relationship between keystones and the CRM Software Company in the software ecosystems.

Fig. 4.

Reward power (RW) of keystones over the CRM Software Company

The Insurance Software Company presents partners’ products to potential clients in pre-sales (RW_CE_01), as cited by its CEO: “in our portfolio, these products are lined up just as our own products are; we sell (CRM Software Company) efficiency, compliance or commercial possibilities”. The partner receives a purchase order, with an agreement per client, or it may be hired as contractor in joint sales. In this specific relationship, the CRM Software Company offers a kickback fee (RW_CA_01) once there are recommendations/potential sales generated by this partner. The CEO of the Insurance Software Company described this agreement: “if a partner does something on his own, he provides a kickback and you get a small percentage of (the business deal)”. Figure 5 shows reward power forces in the relationship between the Insurance Software Company and the CRM Software Company.

Fig. 5.

Reward power (RW) of the CRM and Insurance Software Companies

The studied keystones obtain reward power by increasing the dependence of niche players on opportunities accruing from ecosystem customer base. The CRM Software Company CEO described this context: “you are depending but on the other side you are using big marketing machine ecosystems of very big companies; (and) the marketing is done by those players; we are here on their website”. In its turn, the CRM Software Company gains power once creating a dependence in the Insurance Software Company with respect to monetary payment for deals this partner promotes.

However, the Insurance Software Company has the right to cease all opportunities offered to a partner if his extensions do not satisfy acceptance criteria. Since these features may pose a risk to the image of the system and affect company’s reputation, the partner can be removed from the ecosystem. The CEO of the Insurance Software Company draws an analogy to explain this practice: “the quality of our partners is a risk to our brand; if you have a low battery quality, you have an issue (for the whole car); all cars (have) rubbish (and) there is only one part that has been replaced, which is rubbish; it has been a natural situation”. Such careful quality control may involve the substitution of partners who offer low quality features. This penalty denotes the coercive power of the Insurance Software Company (CO_CE_01) (Fig. 6).

Fig. 6.

Coercive power (CO) of Insurance Software Company over CRM Software Company

4.3 Technical Dimension

It is imperative that the keystone coordinates the contributions of multiple and varied actors from a technical perspective. Hence, the technical dimension embraces software platform management in terms of domain engineering, products’ commonalities and variabilities, among other issues. Such open software enterprise model also requires changes in software product management processes [14], e.g. on a tactical-operational level, the keystone shall inform partners about policies related to quality requirements, certification and intellectual property (IP) of products in the ecosystem.

Such rules that guide the partnerships involve implicit and explicit rights of the companies, which configure their legitimate power in the ecosystem. The ownership of Dynamics CRM provides Microsoft with full control of changes over system functionality. Thereby, value-added resellers cannot change core features of Dynamics CRM (LE_CF_01). This means that the CRM Software Company can only develop extensions. Frequently, the company has to explain to clients that their customisation requests cannot be satisfied. “We are only partners; we can’t just change (Dynamics) CRM; (it) is a Microsoft product”, argued the CEO of the CRM Software Company.

The expertise of the CRM Software Company in CRM domain enables it to determine how each connector will be built (LE_CA_02), as indicated by its CEO: “the whole thing about connectors is defined by us”. The firm is in charge of requirements and technologies specification, whereas partners generally have short influence on connectors’ development due to their usual lack of knowledge in CRM. “The [CRM Software Company] owner is very convincing saying ‘we are the specialists, we will dictate what the requirements are’; Insurance Software Company isn’t a CRM specialist”, cited the developer of the CRM Software Company.

In particular, the E-mail Marketing System Company obtained the right to specify the scope of the connector since it paid the CRM Software Company to develop it (LE_CC_01). It demanded the CRM Software Company to follow a requirements document. “They had a document (with) how the connector should work; it was mainly a connector that was placed (by us) into their requirements to get it working”, described the CRM Software Company developer.

Although the CRM Software Company uses the platforms and app stores of partner ecosystems to build and offer the connectors, it owns the intellectual property of connectors. Thereby, it has the prerogative to control the evolution of connectors (LE_CA_03), as argued by the CEO: “the plan is to phase it (E-Mail Marketing System Company connector) out, because we want to bring down our portfolio; we have a lot of little products and we want to focus on a couple of things”.

While the CRM Software Company defines how connectors are built and maintained, the Data Integration Company demands that the final version of the connectors go through a certification procedure (LE_CB_01). This prerogative stems from the Data Integration Company ownership of the technology and marketplace used by the CRM Software Company. It also results from the fact that connectors will be available in other firms’ sales channels, carrying the mark of the Data Integration Company.

Similarly, the Financials Software Company controls the submission of partners’ extensions to the apps centre via a lengthy quality review (LE_CD_01). “They (partners) submit the application referral, (which) is reviewed by market and tech departments; we request them to do a demo (to) see how it works (and) publish (in the) apps centre”, detailed the Financials Software Company CEO.

The Insurance Software Company imposes a code restriction to partners. It has the right to define degrees of access to source code of its system (LE_CE_01). Hence, the CRM Software Company only deals with the system via interfaces: “so far we have not let partners into our code base; they can adjust or add codes; change parameterisation; (but) not customise”, cited the Insurance Software Company CEO. It denotes the legitimate power of the firm to manage system architecture in the ecosystem.

In Fig. 7, we represent the interplay of legitimate power forces among studied software companies. For instance, it shows that the CRM Software Company cannot apply its power to define connector requirements (LE_CA_02) over the E-mail Marketing System Company. This is a right of this partner due to his payment for the connector (LE_CC_01). Therefore, the E-mail Marketing System Company supersedes the right of the CRM Software Company to define development details.

Fig. 7.

Legitimate power (LE) of keystones and CRM Software Company

5 Discussion

The previous section described the forms of power and respective sources used by the companies in investigated partnerships. The representation of power enabled us to understand their relationships from multiple views, such as knowledge recognition and use (expert power), rights and roles definition (legitimate power), and benefits sharing (reward power). This analysis of what directs power configuration is a relevant input to propose effective business strategies and define suitable governance mechanisms in a software ecosystem environment. Our findings reveal that certain power capabilities allow partnerships to flourish. The keystones’ strategy of sharing decisions provides niche players with the legitimate power to influence changes in product and platform plans [1]. In turn, this strategy fosters innovation in the ecosystem. The keystone firms could also nurture value creation by exercising a specific reward power: support partners with low implementation costs and even provide financial resources [25]. In addition, external players would have an important incentive to join and stay in the network. By adopting this strategy, keystones would reinforce their role and power position in the expanding software ecosystems.

The legitimate power of keystones and niche players to control the platform and complementary products reflect their rights, as rules that govern partnerships. For instance, keystones have the right to perform quality evaluations of extensions built by partners, who accept this rule due to their dependence on the ecosystem. However, keystones must ensure that these standards and certifications do not decrease the productivity of niche players. It is not the case of the Data Integration Company, whose legitimate power to review partners’ connectors implies on a lengthy certification process. Similarly, the Insurance Software Company has the power to restrict the access to core code of the insurance system, which constraints the development of complements and may affect ecosystem productivity [12].

If certain exercises of legitimate power may cause conflicting relationships, the use of coercive power can compromise the success of the business model adopted in the ecosystem. The coercive behaviour of a keystone may promote the migration of a niche player to another network where he could obtain similar opportunities but with less intimidating rules. The survival rate of participants then decreases, affecting ecosystem robustness [10]. We observed that the Insurance Software Company simply substitutes a partner once the quality of his features may threaten the reputation of the firm and hamper the development of its referent power. Instead of exercising such negative form of power over partners, it should define mechanisms for them to properly develop complements (e.g. open platform, with published interfaces, or integration services) and guarantee their approval (e.g. quality requirements for a release).

Studied keystones also invest in the use of reward power. They provide a firm such as the CRM Software Company with a partner certification. This often involves the promotion of partner products in online sales channels or via recommendations to clients. Such capability provides partners with business prospects, increasing their market share. It reveals a governance mechanism to attract and retain firms in the network over time by offering benefits that are critical for small players. A specific reward power of the Financials Software Company is a key asset for a software ecosystem to thrive: it creates incentives for partners to close new deals via workshops and business events for ecosystem members. This keystone increases the connections among participants once it fosters networking. Thereby, it strengthens the structure of the network, which contributes to the robustness of the ecosystem [10].

By offering a technological platform, keystones enable third parties to fuel the ecosystem with additional functionality. Through this strategy, partners can show their expert power in the network. In particular, keystones such as the Data Integration Company and E-mail Marketing System Company reinforce the expertise of niche players by publishing successful cases about their complements. They promote the knowledge available in the ecosystem and diffuse innovation among members [10].

Big players such as Microsoft naturally hold referent power. The strong business reputation is a significant power capability for a keystone as it creates a feeling of respect and admiration for the firm. To develop their referent power, other keystones may highlight their growing position in the market as well as the attractiveness of their platforms and economics of their network [11]. Such promotion strategies rely on external actors recognising the status of both the firm and the ecosystem.

In Table 2, we provide an overview of our case study analysis. It presents the different types of power and their observed outcomes in a software ecosystem.

Table 2. Forms of power used by companies and outcomes on the software ecosystems.

6 Conclusion and Future Work

The in-depth analysis of power-dependence dyads is a useful lens for researchers to explore ecosystem partnerships. From the view of practitioners, it is a valuable tool for firms to have insights on how to affect the resources flow, obtain a higher position in the ecosystem or manage the degree of dependence on competitors. By analysing power distribution, keystones can also define governance strategies that enable them to use existing power to effectively manage the ecosystem [11].

Studied keystones foster ecosystem success by leveraging complementors: they exalt partners’ expert power and exercise reward power by raising business in the network. Besides, they often do not use the influence resulting from their status to apply coercive power. They also avoid using power to take actions solely in their favour and get a bigger slice of the pie, which could harm ecosystem performance.

The findings represent our interpretation of partners’ reality. To support credibility, we used multiple sources of data and discussion of results among authors. Together with details about data collection and analysis, these strategies also ensured reliability.

In future studies, we plan to (i) increase the number of participants per company (e.g. obtain more input from technical staff about power in partnerships) and (ii) verify our findings in final interviews (respondent validation). Our broad goal is to develop a substantive theory to describe power exercise by software ecosystem partners.