A framework for software ecosystem governance

(1)

OZP, Universiteit Utrecht

A framework for software

ecosystem governance

(2)

2

Abstract

The term ‘software ecosystem’ (SECO) is an emerging term and the field of research is relatively young. For software producers, both for independent software vendors (ISVs) and for not-for-profit software producers, understanding and managing one’s software ecosystem can lead to lowering risks and increasing revenue and profit.

In order to provide an overview, this research starts off with a description of the current state of research and the definition of relevant terms. Defining governance and the related terms is done in more detail, resulting in a complete framework for software ecosystem governance modelling. The developed framework is then filled in for two real-world examples.

(3)

3

Introduction

Governance in the field of software ecosystems (SECOs) can help a company achieve its goals, make better use of available resources and can ultimately lead to an increase in revenue and lower risks (Jansen, Software Ecosystems for Product Software, 2010). However, since it is a relatively new field, many organizations do not know how to effectively manage their SECO, or how to make their SECO explicit to begin with. Proper formalization for software ecosystem governance is lacking and there are many challenges to overcome for software vendors in regard to software ecosystems (Jansen, Finkelstein, & Brinkkemper, 2009).

This analytical research, based on two case studies, is an attempt to help formalize some of these challenges an organization has to overcome when formalizing software ecosystems and the

governance strategy affiliated with the SECO. Specifically, this research tries to formalize a number of aspects related governance structure, such as responsibility (Qumer, 2007) and measuring

effectiveness (Chulani, Williams, & Yaeli, 2008).

The structure of this report is as follows: firstly, the approach towards this research is explained. After that, an overview of the current state of relevant research is given and relevant terms such as (corporate) governance are defined. Based on that, a framework is presented. This framework is then filled in for two companies, for which case studies on UNIT4 and the Eclipse Foundations are used. The organizations are then compared and lastly the limitations of this research and

recommendations for future research are mentioned.

Research approach

The result of this research constitutes a framework for software ecosystem governance. Based on this framework, comparisons can be made between different software producing organizations. The research problem that was identified is that there is no de facto standard in terms of software ecosystem governance modelling. In fact, the definition of “software ecosystem governance” in itself has seen many different interpretations. With more formalization and a higher amount of case studies to base theorems on, researchers can begin to formulate ways for organizations to govern their software ecosystem in an effective, efficient and profitable way.

In order to build the framework, a literature study was done to compose a list of different

governance tools, and structural components associated with governance strategy. Two case studies were then conducted, to find out to which degree two real-life organizations currently employ governance, if this governance is based on formalization, who is responsible for governing the ecosystem, et cetera. Using design research the framework was filled in and optimized. An expert review is required to fully validate its accuracy.

Based on two case studies the framework was filled in. These case studies were done in three steps: firstly, a description of the case was made from an observing point of view. After that, the companies were interviewed. In these interviews assumptions were validated or denied and new information was revealed. Lastly, information derived from the prior steps was summarized and conclusions were drawn (Jansen, Case Study Research).

(4)

4 The interviews were done with two managers, both of which have at least 8 years of experience within software companies. One of them is ecosystems director Europe for the Eclipse Foundation and the other one is manager of the small and medium business-oriented part of UNIT4. These interviews both consisted of a number of open questions which can be found in Appendix A.

Current state of research

Although not a lot of research has been done in the specifics of comparing the ecosystem

governance performed by open source software vendors to that of closed source software vendors, the software ecosystem research field has seen some very interesting articles over the recent years. In this chapter some terms and definitions are explained to illustrate the context in which the reported research has taken place.

Open source and closed source

The software vendors researched in this report all create and develop product software. They are divided into two different categories: open source vendors and closed source vendors.

The term ‘open source’ has become quite a buzzword in recent years, even though the concept has been around since the 1950s, when IBM released the source of its operating systems. In their 2010 presentation on open source business models Brinkkemper and Jansen defined the term in the following way: Open source software is distributed with its source code. This, however, does not just mean access to the source code. The distribution terms of open source software must comply with the criteria established by the Open Source Initiative (Brinkkemper & Jansen, Open Source and Open Source Business Models, 2010).

The criteria established by the Open Source Initiative (OSI), founded in 1998, include rules to counter discrimination, establish author integrity and enforce license constraints. Combined, these rules are referred to as the Open Source Definition (OSD). The Initiative is the community-recognized (or de facto standard) body for reviewing and approving OSD-conformant licenses (Open Source Initiative). Commonly found examples of open source software vendors include Eclipse, Mozilla and Red Hat. Contrarily, closed source software or proprietary software is software that is owned by an individual or a company (usually the one that developed it). There are almost always major restrictions on its use, and its source code is almost always kept secret (Linux Information Project, 2005). This is considered a more traditional approach to software development and has proven successful for many companies such as IBM and Microsoft.

An important difference to observe between open source software and closed source software is the transfer of rights. When you buy proprietary software you receive a license to use the software, but you do not gain ownership of the product. With open source software this is not necessarily the case. Eclipse software, for example, can be incorporated in a software vendor’s own products, which may then be sold for profit. The licenses affiliated with Eclipse allow this kind of ownership, whereas this would be forbidden by default for proprietary software.

Software ecosystems

The research illustrated in this report focuses on software ecosystem governance. To understand the importance of this concept, one first has to understand what a software ecosystem actually consists

(5)

5 of. Jansen, Finkelstein and Brinkkemper define a software ecosystem as a set of businesses

functioning as a unit and interacting with a shared market for software and services, together with the relationships among them (Jansen, Finkelstein, & Brinkkemper, 2009).

Bosch defines a software ecosystem as a system consisting of the set of software solutions that enable, support and automate the activities and transactions by the actors in the associated social or business ecosystem and the organizations that provide these solutions (Bosch, 2009).

These definitions are highly similar, except for their level of abstraction. Where Bosch defines the elements in the ecosystem as software solutions, Jansen et al maintain a level of abstraction by taking businesses as the atomic entity of which ecosystems are made up. For this reason, in this research the definition of Jansen et al is used.

A software ecosystem can be looked at from different abstraction or scope levels. Boucharas, Jansen and Brinkkemper define three perspectives in their 2009 article on software ecosystem modelling. At the software supply network scope level, the objects of study are the actors and their relationships. At the SECO scope level the objects of study are the Software Supply Networks (SSNs) and their different relationships. At the SECOs scope level the objects of study are the SECOs themselves, and the relationships among them (Boucharas, Jansen, & Brinkkemper, 2009).

From this definition we can conclude that the most basic element of a software ecosystem,

regardless of the level of scope, is a software supply network (SSN). This can be defined as a supply chain of software products. The entity representing the scoped software product is placed in the middle. On either sides of this entity the software products that depend on the scope or on which the scope depends are placed, allowing a relatively basic overview of software supply dependencies.

Governance

To be able to define software ecosystem (SECO) governance, the definition of the broader concept of governance and specifically corporate governance must first be made clear.

Governance in general refers to the act of governing. Merriam-Webster’s dictionary defines governing as “to exercise continuous sovereign authority over; especially: to control and direct the making and administration of policy” (Merriam-Webster). Governance is present in every aspect of society, from governing a multi-country body such as NATO, UN or EU to the governing of one-person businesses. Any foundation, organization, body or corporation of any size that has any type of decision to make has to deal with the act of governing at some point in time.

Corporate governance

This implication leads to a sub-definition of governance, specifically aimed at business organizations. Sir Adrian Cadbury first defined corporate governance as “the system by which companies are directed and controlled”, as to not exclude all the external elements involved (Cadbury, 1992). However, recently, more detailed and specific definitions are being used. The Organisation for Economic Co-operation and Development (OECD) endorses the following definition for corporate governance: “Procedures and processes according to which an organization is directed and controlled. The corporate governance structure specifies the distribution of rights and

(6)

6 shareholders and other stakeholders – and lays down the rules and procedures for decision-making.” (European Central Bank, 2004). This definition was coined in the European Central Bank’s annual report for 2004.

There are a number of obvious key words in the ECB’s definition. Firstly, governance implies direction and control. Both of these are executed in an on-purpose fashion. This means that governance is not something that just happens; it is something that is actively pursued and controlled. Secondly, it specifies the distribution of rights and responsibilities among different participants. This means that corporate governance is not just a definition regarding processes, rules and procedures, but it also defines who is responsible for which part of any decision that is to be made within an organization. The definition can be further specified into corporate governance for Information and

Communication Technology (ICT). This is defined as “the system by which the current and future use of ICT is directed and controlled. It involves evaluating and directing the plans for the use of ICT to support the organisation and monitoring this use to achieve plans. It includes the strategy and policies for using ICT within an organisation." (Standards Australia, 2005) by Standards Australia. To simplify, it is the system by which companies decide how to use their ICT capabilities to extend their business strategy and objectives. The way in which a company positions itself within a specific software ecosystem can be seen as a subset of the broader idea of ICT governance.

Software ecosystem governance

Some research has already been done in the attempt to formalize governance approaches specifically within software development organizations. Two notable examples are ‘agile software governance’ by Qumer (Qumer, 2007) and ‘software development governance’ by Chulani et al (Chulani, Williams, & Yaeli, 2008). While Qumer’s model focuses on maximizing business value by the business alignment and application of agile software development methods, Chulani’s model helps software development organizations to achieve their strategic goals by establishing the structural component and measurement component of governance (Cheng, Jansen, & Remmers, 2008). However, neither of these models goes into detail about software ecosystem governance in specific. The definition of software ecosystem governance I use for this research is: “Procedures and

processes by which a company controls, changes or maintains its current and future position in a software ecosystem on all different scope levels.”

This definition fits right into Qumer’s ‘Agile responsibility, accountability and business value

governance model’. It can be seen as a small but significant part of the ‘integrated agile governance’ aspect of an organization.

Similarly, the definition can be seen as a small, SECO-only version of Chulani et al’s ‘control and measure mechanisms’ as brought up in their 2008 paper. This model illustrates the different

relationships between governance, strategy, management structure and processes, as can be seen in Image 1.

(7)

7

Image 1 - Chulani et al's 'control and measure mechanisms' (2008)

There is a difference between governance and governance structure. The definition for SECO governance used in this paper only refers to the processes and procedures involved. The SECO governance structure, however, refers to the distribution of rights and responsibilities among the stakeholders associated with the software vendor, and the rules and protocols that need to be followed in order to make decisions regarding the software ecosystem.

(8)

8

Comparing software ecosystem governance and structure

In order to compare software ecosystem governance and governance structures, a framework must be developed. This framework is composed of both governance and governance structure. The governance segment covers processes, procedures and tools used to execute governance strategy, and the governance structure segment covers responsibility, control and measurement associated with governance strategy.

SECO governance

In terms of SECO governance, there are a number of governance tools that an organization may use in order to maintain or change its position within an ecosystem.

For example, an organization can create a partnership network in order to expand its software ecosystem, or to make it more explicit. There are varying degrees in which governance is involved. For example, a way of governing a partnership network would be to moderate the network, to set up rules and processes to which partners must adhere and to penalize or remove partners who fail to comply. Other governance tools associated with partnership networks are the procedures involved in acquiring new partners, the degree of division within the network itself (does it consist of layers, tiers, levels, etc?) and defining the entry requirements a potential partner must meet.

Contribution to other ecosystems can be manifested in several different ways. For example, there is the setting up of new suppliers, ceasing operations with current suppliers, changing the ratio by which current suppliers are used and ceasing cooperation with current customers. All of these decisions do not only affect the company’s own ecosystem, but the ecosystems of the associated supplier/customer as well.

Other than these two major governance tools, there are a number of other tools that can be used. An organization can choose to create a development standard or even go as far as to enforce this development standard on its partners. It can also opt to create licenses which can be reused by other actors in the ecosystem. Both of these examples result in a stronger, more formalized governance policy, because they allow the organization to have more control over its ecosystem. Creating active user groups is another good example in this regard. If an organization creates user groups itself, it has more control over the quality and direction of the feedback. User groups may organize

themselves without the initiative coming from the organization, but that way, the organization does not have a high degree of governance in that respect.

SECO governance structure

There are important questions that an organization needs to answer to be able to fully understand its governance structure. These questions affect the explicitness, both of the ecosystem itself and of the associated governance strategy, the responsibility, measurement and degree of knowledge sharing. Explicitness of the ecosystem

 Is the software ecosystem made explicit within the organization?

o Is there documentation explaining the current state of the ecosystem?

These questions relate to the explicitness of the software ecosystem in general. These are vital questions to the potential success of an ecosystem, because without making the ecosystem explicit, there cannot be an explicit governance strategy.

(9)

9 Explicitness of the governance strategy

 Is the software ecosystem governance strategy made explicit within the organization? o Are processes and procedures formalized?

o Are there formalized and documented rules?

 How is business strategy translated into software ecosystem governance strategy? These questions relate to the explicitness of the governance strategy. With an explicit governance strategy, organizations are able to refer to rules, procedures, protocols and formalized processes when dealing with an ecosystem, which leads to more control over the position in the ecosystem. This ultimately leads to more potential benefit gained from the ecosystem.

Responsibility

 Where in the organization does SECO governance take place? (European Central Bank, 2004) (Qumer, 2007)

o Who does the decision making unit consist of? o Is this decision making unit made explicit?

o Does the decision making unit report to the Board of Directors?

Responsibility is an important factor in ecosystem governance. Without appointed members of the organization being responsible for the ecosystem, correct execution of the governance strategy cannot always be guaranteed. Ecosystem governance could easily become “just a job on the side”, being snowed under by the member’s/members’ main tasks.

Measurement

 Is the effectiveness of the ecosystem measured? (Chulani, Williams, & Yaeli, 2008) o Which parts of it are measured?

o Which key performance indicators (KPIs) are being used?

o How are the goals that the organization wishes to achieve with the SECO defined? In order to determine the organization’s benefit from its ecosystem, the ecosystem effectiveness must be measured. This can be done by applying various key performance indicators (KPIs) to specific segments of the ecosystem. Analyzing the current state of the ecosystem and prospecting the future state can lead to higher return on investment.

Knowledge sharing

 Does the organization share its knowledge on any of the aforementioned subjects with other companies within the ecosystem? (Jansen et al, 2010)

Knowledge sharing is not necessarily a vital aspect of a successful governance strategy. For a for-profit corporation, sharing knowledge of the ecosystem is, in many cases, effectively similar to shooting oneself in the foot. For a not-for-profit organization, however, sharing knowledge may actually be an aspect of core business.

(10)

10

Framework

Based on the aforementioned ecosystem governance tools and the questions that arise when discussing governance structure, the following framework can be used to compare software ecosystem governance strategies, as can be seen in Table 1:

Fra mew o rk fo r s o ft w ar e e co sy stem g o ve rn an ce s tr at eg y

Software ecosystem governance Concept

Y/N – Elaboration

Creating a partnership network - Degree of moderation

- Degree of division in tiers, levels, etc - Acquiring new partners

- Formalization of entry requirements

Coordination of contribution to other ecosystems - Setting up new suppliers

- Changing the ratio of current suppliers

- Ceasing cooperation with suppliers or customers - Using intermediaries

Creating a development standard - Enforcing a development standard Creating a partner directory

- Degree of moderation Creating a customer directory

- Degree of moderation Creating active user groups

- Degree of moderation

Creating reusable software license(s)

Category Software ecosystem governance structure Concept

Y/N – Elaboration Ecosystem

explicitness

Is the software ecosystem explicit?

- Is there documentation describing its current state?

Governance explicitness

Is the software ecosystem governance strategy explicit? - Are processes and procedures formalized?

- Are there formalized and documented rules?

How is business strategy formalized to governance strategy?

Responsibility Where in the organization does SECO governance take place? - Who does the decision making unit consist of?

- Is this decision making unit made explicit?

- Does the decision making unit report to the Board?

Measurement Is the effectiveness of the software ecosystem measured? - Which parts of it are measured?

- Which KPIs are used? - How are goals defined?

Knowledge sharing

Does the organization share its knowledge with other companies?

Table 1 - Framework

The framework, as depicted above, consists of an upper half which is filled in with concepts related to software ecosystem governance, and a bottom half which is filled in with concepts related to software ecosystem governance structure. Furthermore, the bottom half is sorted by category, in

(11)

11 order to provide a good perspective of the current state of affairs within an organization in regard to a certain aspect of software ecosystem governance structures.

The framework can be filled in by providing an answer to every concept. This is either in the form of yes or no, or an elaboration in natural language. For example, the concept ‘Creating reusable software licence(s)’ can be answered with yes if the specific company does indeed create a reusable software licence.

A more specific concept, such as the degree of moderation of an active user group, requires explanation in natural language, rather than a yes or a no. This can be done by providing a short explanation together with the framework, and noting a statement in the explanation that concerns a question in the framework with (1), (2), (N). The question can then be ‘answered’ in the framework using the same notation.

With this framework, organizations are able to get an overview of the state of their current software ecosystem governance strategy. Researchers can compare different companies with each other, and, based on best practice, derive which parts of strategy are viable and which ones are not.

(12)

12

Case studies

In this part of the report the case studies performed on UNIT4, SAP and the Eclipse Foundation are described. These case studies were done in the form of unstructured interviews.

UNIT4

UNIT4 N.V. is a Dutch software company that mainly provides enterprise software and related professional services. Its headquarters are located in Sliedrecht, The Netherlands. In 2010 the company employed 4,200 FTE and its total revenue was just over €420 million (UNIT4, 2010). The company’s best-known products are Agresso Business World ERP Suite and Coda Financials. For this research I interviewed UNIT4 Netherlands’ director for small and medium businesses, Mr Johan Arensman, MSc. His task is to overview and manage the regional division of UNIT4 that focuses on providing small and medium businesses (SMB, Dutch: Midden- en kleinbedrijf, <50 FTE) with UNIT4 software.

Acquisitions

Several significant acquisitions have taken place in recent history. The first one of these took place in 1998, when UNIT4 took over three companies with significant market share in the health care and wholesale sectors. In the beginning of the new millennium UNIT4 took over Agresso, a Norwegian software company, which was the company’s first major step towards internationalization. In 2006 Spain was added to the list by a number of local takeovers, and in 2008 the biggest takeover in UNIT4’s history was realized when CODA became a part of the company (UNIT4).

UNIT4 does not have any formalization regarding expanding the company. The ultimate goal when planning an acquisition is always to increase the company’s scale of operations and to become or remain a top 3 player in a specific sector. However, this is usually realized by taking relatively small steps. Expanding to (for example) China is not (yet) a realistic option for UNIT4, simply because the market size there is far beyond UNIT4’s experience. The ultimate responsibility for acquisitions lies with the Board of Directors of UNIT4 international.

The significant acquisitions from the past can be divided into two different categories: takeovers of companies with knowledge of sectors in which UNIT4 is not present (enough), and takeovers of companies in countries where UNIT4 is not operating (significantly).

An example of acquiring a company from a new sector is the takeover of Acoso, which allowed UNIT4 to expand its business into the accountancy and health care sectors. The greater idea behind

acquiring a company, rather than setting up UNIT4 in a new sector, is that the added benefit of (potential) customers being familiar with the already active company is of great importance. Expanding into a new sector without any acquisitions is only done when there are no satisfying opportunities for a takeover. The decision to actually acquire another company is based on the market share this company has, the return on investment (ROI) involved, and the technology that the company possesses. There are no formal rules for any of these factors, except for the fact that UNIT4 aims to be a top 3 player in every sector it has operations in.

On the other hand, examples of acquiring companies to expand internationally are the acquisitions of Agresso (Scandinavia), CCS, Lopac and Amedia (Spain). The strategy behind these moves is a

(13)

13 active) being saturated. Even though this is not formalized, the strategy that UNIT4 uses when choosing where to expand to resembles Johanson et al’s Uppsala model. After the acquisition of Agresso, which meant a significant market share in Norway and Sweden, Denmark was seen as a logical follower because of the cultural similarities.

Suppliers and customers

On an international level, UNIT4 depends on several supplies. These include major enterprises such as Microsoft and Oracle, but also smaller companies such as the hosting companies that run the Software-as-a-Service (SaaS) solutions UNIT4 provides.

UNIT4 recognizes that it is important for a company of its size not to be dependent on only one supplies, to prevent any supplier from being ‘too influential’ over the company. However, again, this is not formalized in any documentation or rule set. UNIT4 organizes a yearly meeting for all of its directors, where concerns regarding dependency (amongst other things) can be mentioned. The ultimate responsibility for this lies with the Board of Directors, who can decide to involve a new supplier to spread the dependency.

As for customers, UNIT4 sells its software to companies of any size. Since its products are rather broad and influence many different business processes, UNIT4 creates significant value by making the enterprise resource planning more efficient and effective. For the small and medium company division the revenue model involves a yearly payment to renew software licenses, both for locally installed software and SaaS solutions. As of May 2011 UNIT4 serves over 19,000 customers

(customers who have paid license fees in the past 12 months) in the SMB segment, with an average FTE of 15 each.

UNIT4 has created user groups, in order to provide opportunities for UNIT4 software users to share experiences and ideas to improve their understanding and use of the UNIT4 solutions. The

groups organise workshops, meetings and social events around shared interests. These groups exist for both the Agresso users and the CODA users (UNIT4).

Partnerships

To sell its products to medium and small businesses in The Netherlands, UNIT4 has contracts with several local resellers who are each assigned to a specific region within the country. This is the only partnership model UNIT4 currently uses, and the responsibility for this lies with Mr Arensman. The decision to use resellers rather than attempting to sell the software themselves was based on the difference in cost per acquisition. It is very expensive to employ salesmen who have to travel all around the country while operating from the headquarters in Sliedrecht, compared to allowing local IT vendors to resell UNIT4 products. After all, consultancy, implementation and training are still relatively complex processes that require a lot of contact with a customer.

Reseller contracts are renewed yearly and, based on market analysis performed by UNIT4, have formal goals in terms of new customers, licenses sold and total revenue generated. If these goals are met, the reseller gets a higher discount on UNIT4 products in the next year (thus increasing its own margin and therefore profit). In 2009 most of these targets were not met due to the global financial crisis, and many resellers lost a percentage of their margins when the 2010 contracts were signed. New resellers are acquired based on the market share and the amount of potential customers in

(14)

14 certain areas of the country. There are no formalized thresholds, every decision is considered

individually. Conclusions

The filled-in framework looks like this in the case of UNIT4, as can be seen in Table 2:

Fra mew o rk fo r s o ft w ar e e co sy stem g o ve rn an ce s tr at eg y

UNIT4

Yes (1) No (2) No Coordination of contribution to other ecosystems

- Setting up new suppliers

- Ceasing cooperation with suppliers or customers - Using intermediaries Yes (3) (4) (5) Yes Creating a development standard

- Enforcing a development standard

No N/A Creating a partner directory

No N/A Creating a customer directory

No N/A Creating active user groups

Yes (6)

Creating reusable software license(s) No

UNIT4 Ecosystem

explicitness

No No

No No No N/A

(7) (8) No Yes

Yes (9) (10) (11) Knowledge sharing

Does the organization share its knowledge with other companies? No

Table 2 - UNIT4 framework

One can conclude that UNIT4 is not yet in a mature phase when it comes to software ecosystems and SECO governance. Currently, governance takes place at the very top level of the organization when it comes to decisions that are going to affect the company’s core business internationally, and at the

(15)

15 highest level of a national branch of the organization when a decision is only going to affect the activities in that specific country. However, none of this is actually formalized. The SECO is not explicit and there is no formal documentation describing policies or protocols. Inherently, there is no formalized documentation about SECO governance, either.

The company does use one of the listed governance tools: the creation of a partnership network. As discussed in an earlier paragraph, UNIT4 has contracts with several Dutch resellers who are each assigned to a specific region within the Netherlands. However, there is very little formalization when it comes to partnerships, other than the reseller contracts that are being renewed each year.

There is a very low degree of moderation. If a reseller does not manage to sell the target amount of products, this is essentially ‘their problem’ and UNIT4 will renegotiate the contract or even terminate it, but there are no moderation tools being used while a contract is still running (1).

UNIT4’s partnership system does not have a division in tiers, levels or any such construction. Every reseller is the same, except for the contracts that are being signed. Goals are defined based on “what seems realistic”, based on analyzing previous results and doing extensive market research (11). These goals are also used as a measurement tool, to see if the reseller manages to sell the target amount of products (9)(10).

Acquiring new partners is a vital aspect of UNIT4’s partnership strategy (2). However, the acquisition of a new reseller is done by ‘gut feeling’. If market share is lacking or dropping in a specific area of the Netherlands, potential candidates are being selected based on having affinity with IT reselling, and interviews are conducted. Based on those interviews, a winner is selected. There is no protocol or documentation for this procedure.

The effectiveness of the ecosystem in itself is not measured, other than the effectiveness of the partnership system, and contributions to other ecosystems are not coordinated .The sub-attributes of contribution coordination (new suppliers, ratio, ceasing cooperation) are in fact used, but again without any formalization (3)(4)(5). Also, there is no form of a reusable software license created by UNIT4. However, the organization does host User Groups in which users are invited to share experiences, join workshops and increase their understanding of UNIT4 business software. These user groups are moderated extensively, with UNIT4 answering questions in a knowledge base, organizing meetings and workshops, and handling questions and feedback (6).

Lastly, knowledge on any of the aforementioned attributes is not shared with other companies within the ecosystem.

Better understanding of its own software ecosystem and the ways to control its own position is definitely an area where UNIT4 can make many improvements. By making the ecosystem explicit and appointing a staff member to modelling the ecosystem, pointing out its strengths, weaknesses, the opportunities that UNIT4 has in the current situation and the factors that may pose a threat, the organization can gain a stronger position among its competitors and its ecosystem effectiveness can increase.

(16)

16

Eclipse Foundation

The Eclipse Foundation is a not-for-profit organization whose projects are focused on building an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software (Eclipse Foundation). Originally founded by a consortium of IT companies in 2001, Eclipse now is a stand-alone corporation with 40 staff employees around 950 dedicated developers.

All of Eclipse’s products are free to use under the Eclipse Public License, which is approved by the Open Source Initiative. Many of the member companies have dedicated programmers working with Eclipse code. Examples of this are companies that use Eclipse code in their own software, or use Eclipse to add software value to their existing products. Out of the roughly 950 dedicated developers, 800 are not actually employed by the Foundation but by member companies. This results in a highly knowledgeable community of developers with varying personal and corporate interests, allowing the Eclipse platform to be expanded in many different directions.

Currently Eclipse has a variety of products available, for example an integrated development environment (IDE) for Java developers, a PHP development environment and a collection of modelling tools.

For this case study I interviewed Mr Ralph Mueller, Ecosystems Director within the Eclipse Foundation. His role is to manage the expansion of the Eclipse ecosystem within Europe. Eclipse ecosystem

The Eclipse ecosystem is very explicit. This can be seen through various instances, like the Eclipse Plug-in Central (EPIC), Eclipse Live, the Eclipse Membership model and EclipseCon.

There is a very distinct difference between companies with a membership model such as Eclipse, and companies with a partnership model such as UNIT4 or Microsoft. The latter implies that there is a keystone company and a dominator company, where one company has a lot of influence over the other, for example by allowing them to resell or whitelabel products. This is not the case with Eclipse, where a membership model is used to ‘help members help themselves’. The members themselves are the ones who set up the rules, as opposed to a traditional partnership model where the company with the model decides everything. Reselling and whitelabeling are allowed, but a partnership model for this is not needed because Eclipse is not-for-profit.

As for Eclipse’s membership model, the Foundation has a five-tier membership model with a very large member base, consisting of many different IT companies like Motorola, Research in Motion (RIM), IBM, Oracle and Nokia. Potential members can choose which type of member they would like to become. Each member type has different privileges and different obligations. Since many of these companies provide the developers that develop Eclipse projects, one could say that the Foundation uses its members as suppliers. However, the members are also customers, because they use the Foundation’s benefits to strengthen their own products or services.

The plug-in central is a marketplace-like platform where everyone can contribute with any kind of plug-in or add-on for Eclipse. This is free for everyone with a Bugzilla account. Also, everyone can download any plug-in, free of charge. This can be seen as an ecosystem in itself: the suppliers are the

(17)

17 people who write extensions for the platform, and the clients are the people who then download and use the products.

Industry Working Groups (IWGs)

The Eclipse Foundation also facilitates so-called Industry Working Groups or IWGs. These are established to facilitate the collaboration between their members. The collaboration should be intended to focus, promote and augment Eclipse technologies to meet the needs of specific industries. This can be done in the form of developing materials for a specific community or joint marketing programs to promote Eclipse in a specific industry. Unlike Eclipse’s open source projects, participation in an IWG is only open to Eclipse members (Eclipse Foundation, 2010).

Governance

The Eclipse Foundation feels that all of the separate Eclipse projects should be governed by the people who are working on them. Because Eclipse is an open source, not-for-profit platform, there is no profit goal to which the ecosystem should be directed. There is no coordination from inside the Foundation, there is no council of directors telling the individual project leaders what to do and how to do it.

The membership system is largely governed by itself. The Board of Directors designed the tiered system as it is when the membership system was launched, and since then, not much governance has taken place. The Foundation reserves the right to remove any member, or reject any

membership application, but since the Foundation was created this has never happened. In fact, the Eclipse ecosystem has produced innovation in areas where the Foundation did not expect it.

The other community services Eclipse provides, such as Eclipse Live and the Eclipse Plug-In Central require very little governance as well. For example, the only requirement for plug-ins to be added to the Plug-In Central is “it has to work with Eclipse”. Because Eclipse is an open platform, there is nobody to say whether a plug-in is ‘in line’ with the company’s roadmap. One has the right to use the software however one wants, and this includes writing and sharing plug-ins and extensions.

As for the Industry Working Groups, there are a few rules by which the IWGs are governed. For example, all code content must be developed as part of an open source project, and any third party content used by an IWG must be submitted to Eclipse under the Eclipse terms of use. Another constraint is that only members are allowed to join the IWGs. However, there is no constraint on which members can join the Group set up by Eclipse; this is up to the Group’s Steering Committee. Measuring effectiveness

The Foundation measures its effectiveness through a number of key performance indicators (KPIs). These are, for example, measuring the growth of membership to see if the ecosystem is developing in the way the organization had in mind. Another way to measure the ecosystem’s effectiveness is to measure the amount of downloads for the various plug-ins and add-ons available through the Plug-in Central. Because of the organization’s not-for-profit profile, there is no way of measuring

effectiveness by conventional KPIs such as return on investment (ROI). Conclusions

(18)

18 Fra mew o rk fo r s o ft w ar e e co sy stem g o ve rn an ce s tr at eg y

Eclipse

Yes (1) Yes (2) (3) Coordination of contribution to other ecosystems

- Ceasing cooperation with suppliers or customers - Using intermediaries (4) No No No No Creating a development standard

Yes Yes Creating a partner directory

Yes (5) Creating a customer directory

No N/A Creating active user groups

Yes (6)

Creating reusable software license(s) Yes

Eclipse Ecosystem

explicitness

Yes Yes

Yes Yes Yes (7)

(8) (9) Yes Yes

Yes (10) (11) (12) Knowledge sharing

Does the organization share its knowledge with other companies? Yes

Table 3 - Eclipse framework

The first obvious conclusion that can be derived from the case study is that the Ecilpse Foundation is in an advanced stage of ecosystem maturity. The organization has a very explicit ecosystem with four people who are responsible for managing the ecosystem and applying its governance. These people are situated directly under the Board, with one of the Ecosystem Directors working with the

Foundation full-time (8)(9).

Furthermore, the ecosystem is fully documented and formalized, and there are a number of

protocols for many situations, such as application procedures for new members, roadmaps for future development, etc. To a degree, there is a formalized way of translating Eclipse’s business strategy to

(19)

19 a SECO strategy. The idea behind the Foundation is that it serves as a not-for-profit platform to ‘help members help themselves’, and the SECO is designed with this philosophy in mind (5).

An important factor about the Eclipse ecosystem is that its effectiveness is measured in an objective way. The Ecosystem Directors for the different regions have a number of key performance indicators (KPIs) by which they can see how well the ecosystem is performing. Some of these KPIs include amount of new members joined, amount of members who do not renew their annual membership and amount of downloads from the Eclipse Plug-In Central (10)(11). Goals are defined based on the results achieved in previous years and continuous market analysis (12). Furthermore, the acquisition of new members is governed in a very light sense. Only organizations where ethical questions might pose a problem are screened, but other than that, every organization is welcome as long as it follows the rules the Foundation has set up (2).

As said, the Eclipse Foundation has a formalized and very effective membership network. As far as the organization is concerned, there is a clear distinction between a partnership model and a

membership model. In a partnership model, the idea is that two parties make agreements that serve them both, with one party being a keystone player and the other party being a dominator. This is not the case for the Eclipse membership system, where ‘members are helped to help themselves’. In a way this could be seen as a ‘traditional’ partnership where Eclipse is a keystone player.

There is not a very high degree of governance within the membership system (1)(5). Most of the tiers that are active now were set up when the membership system itself was set up. Over time, two extra tiers have been added. These tiers each have separate entry requirements (3), but other than that, the system pretty much governs itself. This is mainly because Eclipse is not-for-profit and there is no ‘greater goal’ for the Foundation other than to serve its members. Within reason, there is no real reason not to let members do as they please to help each other and themselves.

In this sense, elements of a traditional software supply network (SSN) could be seen as member contributions. If a member company provides Eclipse with programmers, the member company can be seen as a supplier. At the same time, these programmers are used to improve Eclipse’s

functionalities, in order to serve the member companies better. The member companies can therefore also be seen as customers. In that respect, the coordination of contributions to other ecosystems is not strictly governed. Again, because of Eclipse’s not-for-profit status, there is no reason for the Foundation to deem certain projects unneeded or unnecessary. Exceptions to this, for obvious reasons, are projects that provide moral objections or projects that violate intellectual property (IP) rights.

Another important governance tool is the creation of a reusable software license. Eclipse uses the Eclipse Public License (EPL) for its software (Eclipse Foundation). This is an Open Source Initiative-approved free software license.

Finally, since the Foundation is completely open source, any knowledge shared by a member within the ecosystem can and will be shared with the other members (4). It is up to the sharing company to determine how much of its knowledge it wishes to share. For knowledge sharing, Industry Working Groups are a very effective tool. These groups can also be seen as active user groups, but with a goal greater than just ‘delivering feedback’. Once again, there is no real reason for a lot of governance or

(20)

20 moderation within these groups, because members are supposed to help each other help themselves (6).

Comparing the organizations

The framework can now be filled in with two companies in the columns on the right, as can be seen in Table 4: Fra mew o rk fo r s o ft w ar e e co sy stem g o ve rn an ce s tr at eg y

UNIt4 Eclipse

Yes (1) No (2) No Yes (1) Yes (2) (3) Coordination of contribution to other ecosystems

- Ceasing cooperation with suppliers or customers - Using intermediaries Yes (3) (4) (5) Yes (4) No No No No Creating a development standard

No N/A

Yes Yes Creating a partner directory

No N/A

Yes (5) Creating a customer directory

No N/A

No N/ Creating active user groups

Yes (6)

Creating reusable software license(s) No Yes

Eclipse UNIT4 Ecosystem

explicitness

Yes Yes No No Governance explicitness

Yes Yes Yes (7) No No No N/A

(8) (9) Yes Yes (7) (8) No Yes

Yes (10) (11) (12) Yes (9) (10) (11) Knowledge sharing

Does the organization share its knowledge with other companies? Yes No

(21)

21 Overall, a few very interesting conclusions can be drawn. First of all, it is not a big surprise that the closed source, for-profit software vendor does not share any knowledge about the ecosystem, and that the open source, not-for-profit organization does.

It is worth mentioning that the two organizations can be seen as Raymond’s cathedral and bazaar (Raymond, 1999), albeit a closed-source cathedral. Within Eclipse, all of the processes are publicly available, all the documentation can be viewed by everyone and software can be resold by anyone, much like Raymond’s bazaar where code is developed in a bottom-up way.

On the other hand, code is developed from a top-down perspective within UNIT4, where the majority of revenue is generated through maintenance and support. This is much like a closed source version of Raymond’s cathedral.

Because of a closed source vendor’s typical top-down approach, it is strange to see how a potentially very profitable field such as software ecosystems has not been made explicit at all. UNIT4 could easily gain more control over its position within the SECO that it is currently in, in case of effective spending of time, money and effort.

An important similarity can be found in the creation of a partnership network (or membership network in the case of Eclipse). Both vendors seek to bind other organizations to them, in order to achieve their own business goals. In the case of UNIT4 the goal is simple: more profit. Resellers are contracted in order to increase revenue generated through licenses. In the case of the Eclipse Foundation, the goal is to serve as a platform where members can help each other and themselves. The degree of how vital the network is to the organization is very different, though. Without UNIT4’s partnership network, the amount of revenue generated would decrease, but not by a very significant amount. The company would still be able to perform its core business in an effective and profitable way. However, as for the Eclipse Foundation, without the membership network a very important aspect of the organization would cease to exist. Facilitating an ecosystem is part of the company’s core business, rather than ‘just something to get a little more revenue’.

Discussion

In this chapter, the research results are discussed based on the limitations, future research and conclusions that can be drawn.

Limitations

The first and foremost limitation of this research is the lack of expert reviews to validate the framework presented. Expert reviews are needed to verify the accuracy of the model, and, in order to adopt this model for future research, four to six experts who work with software ecosystems on a daily basis need to edit and eventually approve this framework.

Another one of the limitations for this research is the quantity of case studies. Two case studies are not enough to allow for any deduction of theorems, and more case studies are needed to confirm or deny the differences and similarities that this research points out.

In that regard, another limitation is the lack of a for-profit open source software vendor. Several of the differences between the Eclipse Foundation and UNIT4 can be attributed to the fact that the

(22)

22 Eclipse Foundation is an open source software producing organization, but some of them are

undoubtedly inherent to the fact that Eclipse is not-for-profit. To fully illustrate the difference between open source organizations and closed source organizations, case studies have to be done within the open source and closed source communities to compare the different types of

organization within each community.

Lastly, due to a rather limited timeframe a relatively small scope was used for the literature research. For a master thesis or an actual research project more time and a broader scope should be used for a better approach on defining the different terms used in this research.

Future research

First of all, more case studies are required to allow for formalization of software ecosystem

governance. The basis for this research is relatively thin and with more researches similar to this one, theorems could be derived, tested and approved. This would transform the field of SECO governance from analytical, where researches study ‘best practices’, to a situation where organizations take established theorems into account when developing a SECO governance strategy.

In general, however, the field of SECO is a relatively new one and more research on for example SECO modelling, business strategies versus SECO strategies, the architectural and social implications of SECOs, and SECO optimization is required. With the development of the International Workshop on Software Ecosystems (IWSECO) and its association with the International Conference on Software Business (ICSOB), a solid platform for future research is established.

Conclusions

This research has provided a basic framework by which software ecosystem governance and

software ecosystem governance structure can be compared. In order to extract all the data required to fill in the framework, in-depth interviews with companies must be held.

It is too soon to consider this framework as a ‘set in stone’ basis for everything SECO governance-related. In order to fully verify its accuracy and confirm its potential, a series of expert reviews must be carried out.

As for the case studies, the difference between an open source and a closed source software producer is definitely visible and resembles the cathedral and bazaar metaphor. To be able to fully understand the details of the difference and to be able to generalize findings, more case studies are required.

(23)

23

Works Cited

Bosch, J. (2009). From Software Product Lines to Software Ecosystems.

Boucharas, V., Jansen, S., & Brinkkemper, S. (2009). Formalizing Software Ecosystem Modeling. Brinkkemper, S., & Jansen, S. (2010). Introduction to Product Software.

Brinkkemper, S., & Jansen, S. (2010). Open Source and Open Source Business Models.

Cadbury, A. (1992). Financial Aspects of Corporate Governance. London: Gee and Co Publishing Ltd. Chaffey, D. (2009). E-Business and E-Commerce Management: Strategy, Implementation and Practice . Prentice Hall.

Cheng, T.-H., Jansen, S., & Remmers, M. (2008). Controlling and Monitoring Agile Software Development in Three Dutch Product Software Companies.

Chulani, S., Williams, C., & Yaeli, A. (2008). Software development governance and its concerns.

Proceedings of the 1st international workshop on Software development governance (pp. 3-6). Leipzig: ACM.

Eclipse Foundation. (n.d.). About the Eclipse Foundation. Retrieved June 6, 2011, from Eclipse.org: http://www.eclipse.org/org/#about

Eclipse Foundation. (2010, September 12). Eclipse Industry Working Group Process. Retrieved June 12, 2011, from Eclipse.org:

http://www.eclipse.org/org/industry-workgroups/industry_wg_process.php

Eclipse Foundation. (n.d.). Eclipse Public License. Retrieved June 26, 2011, from Eclipse Foundation: http://www.eclipse.org/org/documents/epl-v10.php

European Central Bank. (2004). Annual Report. Frankfurt. Jansen, S. Case Study Research.

Jansen, S. (2010). Software Ecosystems for Product Software.

Jansen, S., Brinkkemper, S., Luinenburg, L., & Souer, J. (2010). Shades of Gray: Opening up a Software Producing Organization with the Open Software Enterprise Model. Journal of Systems and Software, special issue on Software Ecosystems .

Jansen, S., Finkelstein, A., & Brinkkemper, S. (2009). A Sense of Community: A Research Agenda for Software Ecosystems.

Linux Information Project. (2005, July 3). Proprietary Software Definition. Retrieved April 26, 2011, from Linux Information Project: http://www.linfo.org/proprietary.html

Merriam-Webster. (n.d.). Governing - Definition. Retrieved June 30, 2011, from Merriam-Webster Dictionary: http://www.merriam-webster.com/dictionary/govern

(24)

24 Open Source Initiative. (n.d.). The Open Source Definition. Retrieved April 26, 2011, from Open Source Initiative: http://opensource.org/docs/osd

Qumer, A. (2007). Defining an Integrated Agile Governance for Large Agile Software Development Environments.

Raymond, E. S. (1999). The Cathedral and the Bazaar. O'Reilly.

Standards Australia. (2005). AS8015-2005 - Australian Standard for Corporate Governance of Information and Communication Technology (ICT).

UNIT4. (n.d.). Geschiedenis. Retrieved May 25, 2011, from UNIT4.nl: http://www.unit4.nl/over-unit4/geschiedenis

UNIT4. (2010). UNIT4 Annual Results 2010. Sliedrecht.

UNIT4. (n.d.). User Groups. Retrieved July 3, 2011, from UNIT4: http://www.unit4software.co.uk/services/user-groups

Xu, L., & Brinkkemper, S. (2005). Concepts of Product Software: Paving the Road for Urgently Needed Research.

(25)

25

Appendix A – Interview questions

Questions used in the case studies:

- What is your definition of a software ecosystem?

- What is your definition of IT governance? And software ecosystem governance? - How do you translate your business strategy to SECO strategy?

- How is the company’s software ecosystem currently composed?

- Which major changes have taken place over the past years? How were these initiated? - What do you currently do to confirm or edit your position within the SECO? Is there any

formalization regarding this process?

o Where in the organization does this take place?

- How do you measure the effectiveness and efficiency of the organization’s IT governance, and SECO governance?

o Who is responsible for this?

- Do you use key performance indicators (KPIs) to determine the goals you wish to achieve through the use of SECO?

A framework for software ecosystem governance

OZP, Universiteit Utrecht