# Towards an OSS Adoption Business Impact Assessment

Lucía Méndez Tapia, Lidia López, Claudia P. Ayala, María Carmela Annosi

## ► To cite this version:

Lucía Méndez Tapia, Lidia López, Claudia P. Ayala, María Carmela Annosi. Towards an OSS Adoption Business Impact Assessment. 8th Practice of Enterprise Modelling (P0EM), Nov 2015, Valencia, Spain. pp.289-305, 10.1007/978-3-319-25897-3_19. hal-01442290

HAL Id: hal-01442290

https://inria.hal.science/hal-01442290

Submitted on 20 Jan 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# Towards an OSS Adoption Business Impact Assessment

Lucía Méndez Tapia¹, ², Lidia López¹, Claudia P. Ayala¹
María Carmela Annosi³

¹Universitat Politècnica de Catalunya (UPC)
c/Jordi Girona, 1-3, E-08034 Barcelona, Spain
emendez@lsi.upc.edu, {llopez, cayala} @essi.upc.edu

²Universidad del Azuay (UDA)
Av. 24 de Mayo 7-77 y Francisco Moscoso, Cuenca, Ecuador
lmendez@uazuay.edu.ec

³Ericsson Research – Ericsson AB,
I-84016, Pagani, Italy
mariacarmela.annosi@ericsson.com

**Abstract.** Nowadays, the adoption of Open Source Software (OSS) by organizations is becoming a strategic need in a wide variety of application areas. Organizations adopt OSS in very diverse ways. The way in which they adopt OSS affects and shapes their businesses. Therefore, knowing the impact of different OSS adoption strategies in the context of an organization may help improving the processes undertaken inside this organization and ultimately pave the road to strategic moves. However, there is a lack of support for assessing the impact of the OSS adoption over the business of the adopter organizations. Based on the goal-oriented characterization of some OSS adoption strategies, in this paper, we propose a preliminary approach to assess the business impact of the OSS adoption strategies over the adopter organizations. The proposal is based on the Business Model Canvas and graph theory notions to support the elicitation and assessment of the impact of each goal over the adopter organization. We illustrate the application of the approach in the context of a telecommunications company.

**Keywords:** Open Source Software, Goal-oriented, OSS adoption strategies, Business Model Canvas.

## 1 Introduction

Open Source Software (OSS) has become a strategic asset for a number of reasons, such as short time-to-market software delivery, reduced development and maintenance costs, and its customization capabilities [1]. Therefore, organizations are increasingly becoming OSS adopters, either as a result of a strategic decision or because it is almost unavoidable nowadays, given the fact that most commercial software also relies at some extent in OSS infrastructure [2]. Organizations might adopt OSS in very diverse ways [3]. The way in which organizations adopt OSS affects and shapes their businesses [4]. Leveraging OSS adoption strategies with the organization context is a challenging task per se, as it implies reconciling them from very different perspectives [5]. However,
there is a lack of support to help organizations to assess the impact of OSS adoption [6]. Organizational modelling can provide a way to define the organization's goals and to serve as the context in which processes operate and business is done. In line with this idea, López et al [7] model diverse OSS adoption strategies as dependency goals between OSS communities and the adopter organizations. These models describe the consequences of adopting one such strategy or another: which are the strategic and operational goals that are supported, which are the resources that emerge. In order to assess which is the OSS adoption strategy that better fits the organization needs, they introduce the notion of model coverage, which allows to measure the degree of concordance among every strategy with the model of the organization by comparing the respective models. However, the approach taken in [7] does not focus on a crucial aspect that need to be taken into account: OSS-based solutions are not developed, and do not exist, in isolation, instead, they exist in the wider context of an organization or a community, in larger OSS-based business ecosystems, which include groups of projects, companies that may be competitors, OSS communities, regulatory bodies, customers, etc. Thus, in this paper, we complement the work done in [7] by considering a further business assessment of the OSS adopter ecosystem when approaching a specific OSS adoption strategy. Hence, the research question that guide this work is:

***RQ1: How to assess the impact of the OSS adoption strategies presented in [7] over the business of an organization?***

This research question explores how the goals stated by the OSS adoption strategies stated in [7], further affect the business of an organization. The resulting approach uses the Business Model Canvas approach [8] to organize and link the diverse kinds of goals of an organization; as well as graph theory notions to realize the impact of each goal over the whole organization. This paper aims to detail the preliminary elements of this approach and its application to a real case.

The rest of the paper is structured as follows: Section 2 introduces the background required to envisage the resulting approach. Section 3 details the foundations and elements of the proposal. To illustrate the application of the proposal, Section 4 details its application in a big telecommunications company: Ericsson Telecomunicazioni (Italy), one of the RISCOSS EU-funded project industrial partners (www.riscoss.eu). Finally, Section 5 presents the conclusions and the future work.

## 2 Background

This section briefly characterizes the goal-oriented OSS adoption strategies [7] used as the basis of this paper; and describes the basic elements of the Business Model Canvas [8] used to articulate the elicitation and assessment of the impact of the different OSS adoption strategies over the adopter organizations.
## 2.1 OSS Adoption Strategies

The concept of strategy comes from the Greek 'strategos' to denote 'leadership'. For organizations, the strategy denotes a set of actions taken to achieve their business goals [9]. In terms of OSS adoption, each adopter organization should define its own OSS adoption goals and determine the actions involved to achieve these goals (i.e., to define the strategy to be followed to fulfill its business model).

Lopez et al [7] describe six different OSS adoption strategies in terms of models that can be used as a reference for understanding and assessing the impact of the OSS adoption strategies on the OSS adopter organization, as well as complementing the OSS adopter organizational model. These strategies were characterized using *i* modeling language, a goal and agent oriented framework formulated for representing, modelling and reasoning about socio-technical systems [10]. We use these OSS adoption strategies as the basis of the approach presented in this paper. A textual description of each OSS adoption strategy is provided below:

* **OSS Acquisition:** refers to use existing OSS code without contributing to its OSS project/community.

* **OSS Integration:** involves the active participation of an organization in an OSS community in order to share and co-create OSS.

* **OSS Initiative:** is oriented to initiate an OSS project and to establish a community around it.

* **OSS Takeover:** is focused on investing some resources to lead an existing OSS project/community.

* **OSS Fork:** means to create an own independent version of the software that is available from an existing OSS project/community.

* **OSS Release:** implies that the organization releases software as OSS but does not care whether an OSS community takes it up or forms around it.

## 2.2 The Business Model Canvas

In order to enable the elicitation and assessment of goals related to the OSS adopter ecosystem and those related to the different OSS adoption strategies, we used the Business Model Canvas [8]. We chose it as it is a well-known tool that covered a wide spectrum of operational and strategic elements of a business model and successfully helped us as the basis to articulate the elicitation and assessment of the different goals involved in OSS adoption.

The Business Model Canvas has nine business model building blocks that describe the organization and how it works [9]. These blocks are:

* **Value propositions:** the bundle of products and services that create value for a specific Customer Segment.

* **Customer segments:** groups of people or organizations an enterprise aims to reach and serve.

* **Channels:** describes how a company communicates with and reaches its Customer Segments to deliver a Value Proposition.
* **Customer relationships:** describes the types of relationships a company establishes with specific Customer Segments.

* **Key resources:** describes the most important assets required to make a business model work. Key resources can be physical, financial, intellectual, or human.

* **Key activities:** describes the most important things a company must do to make its business model work.

* **Key partnerships:** describes the network of suppliers and partners that make the business model work.

* **Cost Structure:** describes all costs incurred to operate a business model.

* **Revenue streams:** represents the cash a company generates from each Customer Segment.

## 3 A Goal-Oriented Approach to OSS Adoption Business Impact Assessment

This section describes the foundations of the main elements of the proposed approach to assess the business impact of the OSS adoption strategies stated in [7] over the OSS adopter organizations

To answer our research question and conceive the resulting approach, we needed to deal with three essential issues:

1) *Elicitation of relevant goals:* how to discover and refine business and ecosystem related goals that are relevant in OSS adoption processes?

2) *Goal Alignment:* how to align each OSS adoption strategy's goals from [7] to the OSS adopter business and ecosystem related goals?

3) *Goal Impact Assessment:* how to assess and estimate the impact of the OSS related goals over the whole organization?

Sections 3.1, 3.2 and 3.3 focus on explaining how we dealt with the elicitation of relevant goals, goal alignment and goal impact assessment respectively.

### 3.1 Elicitation of Relevant Goals

OSS adoption might deeply affects the business of an organization, mainly because OSS-based solutions are not developed, and do not exist, in isolation, instead, they exist in the wider context of an organization or a community, in larger OSS-based business ecosystems, which include groups of projects, companies that may be competitors, OSS communities, regulatory bodies, customers, etc. As mentioned above, there is a lack of support for assessing this complex situation. Thus, to support the elicitation and assessment of relevant goals in OSS adoption processes, we suggest to classify them into:

* **Generic Business Goals:** related to the external environment and the strategic organizational components.
* **Generic OSS Goals**: related to OSS adoption goals that any organization might want to achieve independently from the adoption strategy chosen.

* **OSS Adoption Strategy Goals**: related to those goals that depend directly to the adoption strategy, as assumed in [7].

On the other hand, we also suggest to characterize goals using a common goal level classification from [11] that characterize them as: strategic, tactical and operational to denote another important aspect of the nature of the goals. Table 1 presents the main characteristics of each goal level.

<table><caption>**Table 1.** Characterization of Goal Levels</caption><thead><tr><th rowspan="2">Goal Level</th><th colspan="4">Characteristics</th></tr><tr><th>Scope</th><th>Impact</th><th>Related to</th><th>Period</th></tr></thead><tbody><tr><td>Strategic</td><td>Broad</td><td>High</td><td>Organizational environment</td><td>Long term</td></tr><tr><td>Tactical</td><td>Middle</td><td>Middle</td><td>Transform the strategy in actions</td><td>Medium term</td></tr><tr><td>Operational</td><td>Limited</td><td>Low</td><td>Implement the strategy</td><td>Short term</td></tr></tbody></table>

Next subsections describe how these set of goals were elicited and might serve as reference catalogues to help organizations to elicit their own specific goals. We used the Business Model Canvas [8] as an umbrella to elicit and articulate the goal alignment.

### 3.1.1 Generic Business Goals

These goal were identified considering the following factors:

* **Macro-environment**: external factors that impact in the business and on which the OSS adopter has a little or none influences. Concretely related to: political, economic, social, technological, environmental, legal, demographic and regulatory issues [12], [13]. For instance, some public organizations are affected by the governmental policy of using OSS whenever possible [3].

* **Micro-environment**: it refers to factors that have a direct contact to the organization itself and to all the challenges that come from inside the organization [14]. For instance, assessing the micro-environment, we should realize the existence of competitors (i.e., entities that collaborate with the organization and at the same time are competitors in other lines or products [15]), thus shaping the corresponding goals.

* **Strategic Elements of the Organization**: this embraces issues such as the mission, vision, and business strategy of the organization [16], as well as the competitive strategies [17] and business models [4], [8] put in place in the organization.

Table 2 shows the resulting list of generic business goals, which can be applied regardless of the nature or economic activity of the OSS adopter. These goals were codified and mapped to the corresponding Business Model Canvas building block, and assigned to the hierarchical level (S for strategic, T for tactical, and O for operational).
<table><caption>Table 2. Generic Business Goals</caption><thead><tr><th>Canvas Building Block</th><th>Code</th><th>Generic Business Goals</th><th>Level</th></tr></thead><tbody><tr><td rowspan="2">Customer Segments</td><td>BG01</td><td>To consolidate / improve market position</td><td>S</td></tr><tr><td>BG02</td><td>To expand coverage of supply to new markets with existing services and / or new</td><td>S</td></tr><tr><td rowspan="3">Value Proposition</td><td>BG03</td><td>To offer brand / status</td><td>S</td></tr><tr><td>BG04</td><td>To offer a product/service with high quality</td><td>S/T</td></tr><tr><td>BG05</td><td>To offer an innovative product/service</td><td>S/T</td></tr><tr><td rowspan="4">Channels</td><td>BG06</td><td>To deliver the product or service to customers</td><td>S</td></tr><tr><td>BG07</td><td>To enable the after sales service</td><td>S</td></tr><tr><td>BG08</td><td>To enable customers to multichannel purchase of products or services</td><td>S</td></tr><tr><td>BG09</td><td>To build customer loyalty (to establish long-term relationships)</td><td>S</td></tr><tr><td rowspan="3">Customer relationships</td><td>BG10</td><td>To establish, maintain and expand customer relationships</td><td>S</td></tr><tr><td>BG11</td><td>To know the customer's profile for personalization purposes</td><td>T</td></tr><tr><td>BG12</td><td>To provide quality customer care</td><td>S</td></tr><tr><td rowspan="2">Revenue Streams</td><td>BG13</td><td>To improve revenues resulting from one-time customer payments</td><td>S</td></tr><tr><td>BG14</td><td>To improve revenues resulting from ongoing payments</td><td>S</td></tr><tr><td rowspan="5">Key Resources</td><td>BG15</td><td>To implement a strategy to obtain a source of differentiation</td><td>S</td></tr><tr><td>BG16</td><td>To maintain/innovate the infrastructure</td><td>S</td></tr><tr><td>BG17</td><td>To develop a capacitation plan</td><td>S</td></tr><tr><td>BG18</td><td>To achieve and maintain a differentiation factor</td><td>S</td></tr><tr><td>BG19</td><td>To achieve and maintain competitive advantage</td><td>S</td></tr><tr><td rowspan="10">Key Activities</td><td>BG20</td><td>To establish barriers to entry for potential new competitors</td><td>S</td></tr><tr><td>BG21</td><td>To approval of any use/licensing in or licensing out of software</td><td>T</td></tr><tr><td>BG22</td><td>To ensure quality IT services</td><td>S</td></tr><tr><td>BG23</td><td>To implement and distribute software product and licenses to customers according to corporate policies.</td><td>O</td></tr><tr><td>BG24</td><td>To optimize the production processes</td><td>T</td></tr><tr><td>BG25</td><td>To strengthen Research, Development and innovation (R&D&i)</td><td>T</td></tr><tr><td>BG26</td><td>To establish / consolidate software as (part of) a competitive advantage</td><td>S</td></tr><tr><td>BG27</td><td>To ensure the quality level of software adopted</td><td>S</td></tr><tr><td>BG28</td><td>To establish strategic alliances for ensuring provisions</td><td>S</td></tr><tr><td rowspan="6">Key Partnerships</td><td>BG29</td><td>To establish strategic alliances for ensuring input logistics (supply chain)</td><td>S</td></tr><tr><td>BG30</td><td>To guarantee the data confidentiality level among the cooperator and competitor roles when they are played with the same organization</td><td>S</td></tr><tr><td>BG31</td><td>To ensure the law's accomplishment (licensing, intellectual property ownerships, patents, and others)</td><td>S</td></tr><tr><td>BG32</td><td>To obtain (long term) agreements with external services</td><td>T</td></tr><tr><td>BG33</td><td>To have a licensing schema for operating/distributing/selling software</td><td>T</td></tr><tr><td>BG34</td><td>To achieve cost advantages through economies of scale and economies of scope (according to the good or service and customer segment)</td><td>S</td></tr><tr><td>Cost Structure</td><td>BG35</td><td>To implement a strategy to reduce costs</td><td>S</td></tr></tbody></table>
### 3.1.2 Generic OSS Goals

Generic OSS goals are related with adopting OSS in general, independently of the adoption way. The list of generic goals presented in Table 3 was based on literature related to the business role of OSS [1], [4], [18], and innovation [19]. These goals were also codified and mapped to the corresponding Canvas building block, and assigned to the hierarchical level (S for strategic, T for tactical, and O for operational).

<table><caption>**Table 3.** Generic OSS Goals</caption><thead><tr><th>Canvas Building Block</th><th>Code</th><th>Generic OSS Goals</th><th>Level</th></tr></thead><tbody><tr><td rowspan="2">Customer Segments</td><td>OG01</td><td>To change customer and market perceptions</td><td>S</td></tr><tr><td>OG02</td><td>To create a new markets</td><td>S</td></tr><tr><td rowspan="10">Value Proposition</td><td>OG03</td><td>To ensure availability</td><td>T</td></tr><tr><td>OG04</td><td>To ensure robustness</td><td>T</td></tr><tr><td>OG05</td><td>To ensure security</td><td>T</td></tr><tr><td>OG06</td><td>To facilitate the adaptation of software systems to business dynamic</td><td>S</td></tr><tr><td>OG07</td><td>To improve the corporate / enterprise image or brand</td><td>S</td></tr><tr><td>OG08</td><td>To incorporate the best practices in the business area for primary processes</td><td>S</td></tr><tr><td>OG09</td><td>To work in concordance to specific ethical, moral, and political statements</td><td>S</td></tr><tr><td>OG10</td><td>To achieve ubiquity for the product or product platform</td><td>S</td></tr><tr><td>OG11</td><td>To incorporate the innovation in products/services</td><td>S</td></tr><tr><td>Customer Relationships</td><td>OG12</td><td>To involve to end-users with the obtain feedback information process</td><td>T</td></tr><tr><td>Revenue Streams</td><td>OG13</td><td>To establish the revenues resulting from OSS component support</td><td>S</td></tr><tr><td rowspan="10">Key Resources</td><td>OG14</td><td>To incorporate technical personnel to deal with OSS internal support</td><td>S</td></tr><tr><td>OG15</td><td>To improve security control</td><td>T</td></tr><tr><td>OG16</td><td>To improve quality (performance, security, flexibility and interoperability</td><td>S</td></tr><tr><td>OG17</td><td>To reduce the time to market</td><td>S</td></tr><tr><td>OG18</td><td>To avoid vendor/consultant lock/in</td><td>S</td></tr><tr><td>OG19</td><td>To incorporate best software development practices</td><td>T</td></tr><tr><td>OG20</td><td>To change the pricing practices</td><td>T</td></tr><tr><td>OG21</td><td>To have a licensing schema for operate/ distribute/sell OSS</td><td>S</td></tr><tr><td>Key Partnerships</td><td>OG22</td><td>To achieving a degree of interaction with the community for a continued support to OSS component</td><td>S</td></tr><tr><td>Cost Structure</td><td>OG23</td><td>To reduce costs / make savings</td><td>S</td></tr></tbody></table>

### 3.1.3 OSS Adoption Strategy Goals

Each OSS adoption strategy (fully described in [7]) taken as a basis in this work, has a set of relationships between the OSS adopter and the OSS community that provide the OSS. However, these relationships need to be further assessed to elicit business and ecosystem related goals. Therefore, we defined a process to elicit these goals from each OSS adoption strategy.
A process for eliciting goals from the OSS adoption strategy models

The i* language used to model the OSS strategies is composed of a set of constructs, which can be used in two types of models. The Strategic Dependency (SD) Model allows the representation of organizational actors and the strategic dependencies among them. A Dependency is a relationship between two actors: one of them, named depender, depends for the accomplishment of some internal intention on a second actor, named dependee. The dependency is characterized by an intentional element (Dependum). The main Intentional Elements are: Resource, Task, Goal and Softgoal. A softgoal represents a goal that can be partially satisfied, or a goal that requires additional agreement about how it is satisfied. The Strategic Rationale (SR) Model represents the internal actor's rationale, allowing the representation of the actor's goals and their decomposition [20].

Fig. 1 shows an excerpt of the OSS Integration strategy model from [7]. In order to improve the understandability of the model, in Fig. 1, the elements' names correspond to descriptions instead of the identifiers originally used in [7]. We use this model as a basis to explain the process followed for extracting goals from each OSS adoption strategy models.

<figure><img src="image_2.png" /><figcaption>Fig. 1. Excerpt for the OSS Integration strategy model.</figcaption></figure>

For each OSS adoption strategy model, we produce the set of specific OSS goals
following the process detailed below:

1) Identifying what the OSS adopter organization needs from the OSS community. For this purpose, we derived the goals from the dependencies where the OSS adopter is the depender. As we are interested on goals, there are two cases, according to the kind of intentional element characterizing the dependence:
a) The dependum is a goal or softgoal, the dependum is an OSS specific goal. The goals and softgoals associated to this dependency inside the OSS adopter rationale are also considered as OSS specific goals. For example dependencies "Acceptance as contributor" and "Help obtained".

b) The dependum is a task or resource. In this case, the specific goals are only the goals and softgoals associated to this dependency inside the OSS adopter rationale. For example, "Technical Quality", connected to the dependency with resource "User documentation".

2) Identifying the goals that the OSS adopter must achieve to satisfy the OSS community needs. In this case, the dependency considered are the ones where the OSS adopter is thee dependee and the dependum is characterized by a goal or softgoal:

c) The specific goals are the goals and softgoals associated to this dependency inside the OSS adopter rationale. As example, the community has the goal "Supporting activities held", that impacts over the internal task "Give support to activities" (i.e. "to provide any kind of support to the community not related to reporting bugs and providing patches"), which enables us to find the goal "OSS Community Contributed".

3) Identifying the internal strategic goals that are not directly related to the dependencies with the OSS community. The OSS adoption strategy models presented in [7] contains two types of information: the high-level goals attained by the strategy and the low-level task and resources that are requirements for an adequate application of the OSS adoption strategy. We only include the high-level goals in the process. In the particular case of OSS Integration adoption strategy, there are no additional goals to find because all explored dependencies in the steps 1 and 2 are related with the high-level strategy goals.

Table 4 shows the result of applying the process previously detailed to the OSS adoption integration strategy partially shown in Fig. 1.

<table><caption>**Table 4.** OSS Specific Goals of Integration OSS Adoption Strategy</caption><thead><tr><td>OSS Adoption Strategy Specific Goals</td><td>Step</td></tr></thead><tbody><tr><td>IG01 Benefit from co-creation taken</td><td>b</td></tr><tr><td>IG04 Technical Quality</td><td>b</td></tr><tr><td>IG05 OSS component used</td><td>b</td></tr><tr><td>IG11 Help obtained</td><td>a</td></tr><tr><td>IG12 Acceptance as contributor</td><td>a</td></tr><tr><td>IG08 OSS Community contributed</td><td>b, c</td></tr><tr><td>IG09 According OSS community practices</td><td>b</td></tr><tr><td>IG02 OSS Involvement</td><td>b</td></tr><tr><td>IG07 OSS component evolves towards desired features</td><td>a, c</td></tr><tr><td>IG06 Quality of the evolved OSS component</td><td>a, c</td></tr><tr><td>IG03 OSS evolution influenced</td><td>a, c</td></tr></tbody></table>

## 3.2 Goal Alignment

To reconcile and map the diverse elicited goals from the previous stage, we : a) defined a process of goal mapping aimed to assess all potential relationships among goals and;
b) define the influence paths from the relevant relationships found in the goal mapping matrix in order to visualize and process the potential impact of the goals.

### 3.2.1 Goal Mapping Process

The type of goal relationships in each Business Model Canvas building block is many-to-many: one *generic OSS goal* may contribute to one or more *generic business goals*, and one *generic business goal* can be supported by one or more *generic OSS goal*; a similar relationship exists among *OSS adoption strategy goals* and *generic OSS goals*.

Therefore, the goal mapping process consist on relating the whole set of goals from (i.e., the generic business goal, OSS generic goals, and OSS adoption strategy goals) to assess their implications for each Business Model Canvas building block. Meaningful relationships are marked to proceed to their further assessment while non-meaningful ones are just discarded (see example in Section 4.2.1). The goal mapping matrix help to identify meaningful relationships that need to be further assessed by the organization.

### 3.2.2 Influence Path

To understand and process the relationships found through the goal mapping matrix, we built a graph where the nodes are the goals and the edges are the dependency/contribution links. Thus, we identify a set of influence paths that help us to trace the impact of relevant goals (see example in Section 4.2.2) and to apply graph theory notions for the subsequent goal impact assessment.

## 3.3 Goal Impact Assessment

Last, to assess the impact of the elicited goals over the organizations we apply some concepts from the graph theory [21]. The objective is to quantify the importance of a goal (represented as a node) based on the support that it provides to other goals, as well as the support needed from other goals.

The goal influence is the relation between goals that indicates that one goal is supporting the achievement of another goal. From the organization's point of view, the importance of a goal is given, among other factors, by the number of goals that it influences. The influence level depends on the levels of the supported goals (Strategic, Tactical or Operational): higher level goals are more important than lower ones. If we represent the goals as nodes, and the influence of a goal over another goal as a directed edge, the importance of a node can be calculated in terms of degree centrality [21].

There are two ways to know the goal importance of a given goal: the first one depends on the number of goals it is supporting (here the goal acts like a support provider), and the second one depends on the number of goals supporting it (here the goal acts like a support consumer).

To assess the importance of goals acting as support providers, we propose the calculation of the *Goal Impact Factor (GIF)* to quantify the importance of a specific goal, based on the number and level of goals to which it influences. We assign for example, the weight factor of 1 (the maximum value) to the impact over a strategic
business goal; 0.75 to the impact over a tactical business goal; and 0.5 (the minimum value) to the impact over an operational business goal. These values can be modified according to the specific criteria of the organizations. The GIF for any node i, through its influence path, is calculated as follows:

$$GIF(i) = 1 * SGI + 0.75 * TGI + 0.5 * OGI \quad (1)$$

Where SGI is the total number of Strategic Goals Impacted, TGI is the total number of Tactical Goals Impacted, and OGI is the total number of Operational Goals Impacted. Taking any goal (i) in the directed influence path, the SGI, TGI and OGI are calculated as the number of nodes from node i (itself included), to the goals at the end of each influence path; each node is counted only one time. The results are normalized in relation to the total number of nodes in the graph.

To assess the importance of goals acting as support consumers, we applied the Goal Grouping Factor (GGF) to quantify the importance of a specific goal based on the number and level of goals that support it. The weight factor is applied in the same way than in GIF. The GGF for any node i, through its influenced path, is calculated as follows:

$$GGF(i) = 1 * SGG + 0.75 * TGG + 0.5 * OGG \quad (2)$$

Where SGG is the Strategic Goal Grouped, TGG the Tactical Goal Grouped, and OGG the Operational Goal Grouped. Taking any goal (i) in the directed influence path, the SGG, TGG and OGG are calculated as the number of nodes from i (itself excluded), through each influence path, to the goals that are not supported by others (self-sufficient goals); each node is counted only one time. The results are normalized in relation to the total number of nodes in the graph.

The quantification of the goal importance using GIF can help to:

a) identify the goals with higher impact over the business, helping to establish priorities in the resources assigned to the related tasks;

b) compare the impact of one OSS adoption strategy over another, comparing the sum of GIF of all self-sufficient goals of each strategy; this comparison can support the OSS strategy selection.

On the other hand, when we use GGF, the obtained value reveals the number and level of goals that are its contributors; in this sense, the GGF can help to establish the general schedule for the goals achievement, as part of the business plan.

# 4 An Example of Application of the Approach: The TEI Case

This section details the application of the approach described above, in the context of TEI (Ericsson Italy at Pagani, TEI), one of the RISCOSS project industrial partners.

TEI is part of Ericsson, one of the world's leading telecommunication corporations. Ericsson produces hardware (telecommunications infrastructure and devices) as well as the software to run it. The company's mission is to empower people, business and society at large, guided by a vision of a sustainable networked society. One of TEI's
roles within the Ericsson ecosystem is to provide OSS alternatives to support efficient third party products handling. Therefore, it is important for TEI to adopt OSS components following the adoption strategy that is most suitable to the organization needs.

Based on a preliminary assessment of TEI, the most suitable strategy for them was OSS adoption integration strategy [7]. The example presented in this section refers to this specific strategy, and focus on a specific Business Model Canvas building block, named Value Proposition area.

## 4.1 Elicitation of Relevant Goals for TEI

The elicitation of relevant goals was supported by the list of Generic Business Goals (Table 2), Generic OSS Goals (Table 3), and OSS Strategy Goals (Table 4), that acted as catalogues of goals that were customized to the specific circumstances, needs and expectations of TEI.

Table 5 shows an excerpt of the resulting TEI's Business Model Canvas-based elicited goals.

<table><caption>**Table 5.** Canvas-based elicited goals for TEI (Value Proposition area)</caption><thead><tr><th>Code</th><th>Business Goal</th><th>Level</th></tr></thead><tbody><tr><td>BG03</td><td>To offer reputation</td><td>S</td></tr><tr><td>BG04</td><td>To offer a product/service with high quality</td><td>S</td></tr><tr><td>BG05</td><td>To offer an innovative product/service</td><td>S</td></tr><tr><th>Code</th><th>OSS Goal</th><th>Level</th></tr><tr><td>OG03</td><td>To ensure availability</td><td>T</td></tr><tr><td>OG04</td><td>To ensure robustness</td><td>T</td></tr><tr><td>OG05</td><td>To ensure security</td><td>T</td></tr><tr><td>OG06</td><td>To facilitate the adaptation of software systems to business dynamic</td><td>S</td></tr><tr><td>OG07</td><td>To improve the corporate / enterprise image or brand</td><td>S</td></tr><tr><td>OG08</td><td>To incorporate the best practices in the business area for primary processes</td><td>S</td></tr><tr><td>OG09</td><td>To work in concordance to specific ethical, moral, and political statements</td><td>S</td></tr><tr><td>OG10</td><td>To achieve ubiquity for the product or product platform</td><td>S</td></tr><tr><td>OG11</td><td>To incorporate the innovation in products/services</td><td>S</td></tr><tr><th>Code</th><th>OSS Integration Strategy Goal</th><th>Level</th></tr><tr><td>IG01</td><td>Benefit from co-creation taken</td><td>S</td></tr><tr><td>IG04</td><td>Technical Quality</td><td>T</td></tr><tr><td>IG05</td><td>OSS component used</td><td>T</td></tr><tr><td>IG11</td><td>Help obtained</td><td>T</td></tr><tr><td>IG12</td><td>Acceptance as contributor</td><td>S</td></tr><tr><td>IG08</td><td>OSS Community contributed</td><td>T</td></tr><tr><td>IG09</td><td>According OSS community practices</td><td>O</td></tr><tr><td>IG02</td><td>OSS Involvement</td><td>S</td></tr><tr><td>IG07</td><td>OSS component evolves towards desired features</td><td>T</td></tr><tr><td>IG06</td><td>Quality of the evolved OSS component</td><td>T</td></tr><tr><td>IG03</td><td>OSS evolution influenced</td><td>S</td></tr></tbody></table>

It can be observed that some of the customizations over the catalogues to satisfy TEI's needs were:
* The generic business goal BG03 "To offer brand / status" was modified to "To offer reputation", to better accommodate it to the TEI context.

* The level of generic business goals BG04 "To offer a product/service with high quality" and BG05 "To offer an innovative product/service" were taken to strategic (i.e., level S) due the higher importance to the TEI's business performance.

* The level of OSS specific goals of Integration OSS adoption strategy IG02 "OSS Involvement" and IG03 "OSS evolution influenced" were decided to be strategic (i.e., level S) due the higher importance of the OSS community for TEI.

## 4.2 Goal Alignment

To perform the goal alignment, we built the goal mapping matrix followed by the influence paths. Next subsections summarize the results.

### 4.2.1 Goal Mapping Process

We obtain the goal mapping matrix in Table 6 by applying the Cartesian product of all TEI's relevant goals (see Table 5) related to the Value Proposition area. Due to space restrictions, the table only includes the goals related to the quality of code, one of the tactical goals for TEI. Only meaningful relationships are marked with an arrow. Please note that those cells in grey color just denote reflexive relations that are not applicable.

<table><caption>**Table 6.** Goal Mapping Matrix</caption><thead><tr><th></th><th>Code</th><th>BG03</th><th>BG04</th><th>OG03</th><th>OG04</th><th>OG05</th><th>OG07</th><th>IG01</th><th>IG04</th><th>IG011</th><th>IG06</th></tr></thead><tbody><tr><td>Code</td><td>Level</td><td>S</td><td>S</td><td>T</td><td>T</td><td>T</td><td>S</td><td>S</td><td>T</td><td>T</td><td>T</td></tr><tr><td>BG03</td><td>S</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>BG04</td><td>S</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>...</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>OG03</td><td>T</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>OG04</td><td>T</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>OG05</td><td>T</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>OG07</td><td>S</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>...</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>IG01</td><td>S</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>IG04</td><td>T</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>IG11</td><td>T</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>IG06</td><td>T</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>
### 4.2.2 Influence Paths

Based on the relevant relationships assessed from Table 6, we built the corresponding influence path, as shown in Fig. 2. This figure graphically shows the potential influence of goals over the diverse levels of the organization.

<figure><img src="image_3.png" /><figcaption>Fig. 2. Influence path</figcaption></figure>

## 4.3 Goal Impact Assessment

In the case of TEI, assuming that the influence path of the Fig. 2 was the entire graph, the total number of nodes should be 10. Applying the formula (1), *GIF (IG11)* "Help Obtained" is 7.75 normalized as 77.5%; and *GIF(IG01)* "Benefit from co-creation taken" is 6.25, normalized as 62.5 per cent. Therefore, IG11 has more impact than IG01 in the organization business goals.

Working in the same way with the influence path of the Fig. 2 and the total number of nodes, we can apply the formula (2) to obtain *GGF(BG04)* "Offer high quality products" is 5.5 normalized as 55%; and *GGF(IG01)* "Benefit from co-creation taken" is 2.25 normalized as 22.5%. This means that BG04 requires more support (that is, the contribution of more goals) than IG01.
# 5 Conclusions and Future Work

In this paper, we propose a complementary approach to [7], aimed to assess the business impact of a specific OSS adoption strategy over the OSS adopter organization. In order to give an answer to our research question, we:

1. use the Business Model Canvas as an umbrella to organize and elicit goals for enabling their subsequent analysis.

2. manage the many-to-many relationships, among business and OSS-related goals, using a mapping goal matrix and influence path (a directed graph) that allow us to adopt some concepts from the graph theory to assess the resulting goal relationships.

3. define some preliminary metrics (GIF and GGF) for supporting the estimation of the goal influence and goal relevance.

Although preliminary, this approach has shown potential to support organizations to realize goal influences that affect their business and help them to take informed decisions.

The future work is mainly addressed to improve the metrics that can be applied from the elicited goals and their relationships, as well as to improve the set of relevant goals that the approach suggest to elicit, taking into account risks that might have an impact on the business of the organizations.

# Acknowledgements

This work has been performed in the context of the RISCOSS project, funded by the EC 7th Framework Programme FP7/2007-2013, agreement number 318249. Lucía Méndez's work is supported by a SENESCYT (Secretaría de Educación Superior, Ciencia, Tecnología e Innovación) grant from the Ecuatorian government.

# References

1. Goldman, R., Gabriel, R. P.: Innovation happens elsewhere - Open source as business strategy. Morgan Kaufmann. (2005)

2. BlackDuck, The 2015 Future of Open Source Survey. www.blackducksoftware.com/future-of-open-source, last visited in Jul-2015.

3. Hauge, O., Ayala, C., Conradi, R.: Adoption of open source software in software-intensive organizations – A systematic literature review. In Information and Software Technology, 52, 11, 1133–1154 (2010)

4. Chesbrough, H. W.: Open Business Models – How to thrive in the new innovation landscape. Harvard Business School Press. (2006)

5. Osterwalder, A.: The Business Model Ontology - A proposition in a design science approach. Université de Lausanne. Ecole des Hautes Etudes Commerciales. (2004)

6. Franch, X., Susi, A., Annosi, M. C., Ayala, C. P., Glott, R., Gross, D., Kenett, R. S., Mancinelli, F., Ramsamy, P., Thomas, C., Ameller, D., Bannier, S., Bergida, N., Blumenfeld, Y., Bouzereau, O., Costal, D., Dominguez, M., Haaland, K., López, L., Morandini, M., Siena,
A.: Managing Risk in Open Source Software Adoption. In Proceedings of International Joint Conference on Software Technologies (ICSOFT), pp. 258-264 (2013)

7. López, L., Costal, D., Ayala, C., Franch, X., Annosi, M., Glott, R., Haaland, R.: Adoption of OSS components: a goal-oriented approach. In Data & Knowledge Engineering (2015)

8. Osterwalder, A., Pigneur, Y.: Business Model Generation. John Wiley & Sons. (2010)

9. Mintzberg, H., Ahlstrand, B., Lampel, J.: Strategy Safari: A Guided Tour Through the Wilds of Strategic Management, The Free Press, New York. (1998)

10.Yu, E.: Modelling Strategic Relationships for Process Reengineering. PhD. Thesis. Toronto. (1995)

11.Kotler, P., Berger, R., Bickhoff, N.: The Quintessence of Strategic Management – What You Really Need to Know to Survive in Business. Springer-Verlag. Berlin (2010)

12.Dess, G. G., Lumpkin, G. T., Eisner, A. B.: Strategic Management - Creating competitive Advantages, 5th Ed. McGraw-Hill/Irwin. (2010)

13 Team FME: PESTLE Analysis, strategy skills. (2013)

14 Porter, M.: Competitive Advantage. New York: Free Press (1985)

15.Brandenburger, A.M., Nalebuff, B.J.: Co-opetition. Bantam Doubleday Dell. New York. (1996)

16.Kaplan, R.S., Norton, D. P.: Strategy Maps. Harvard Business School Press. (2004)

17 Porter, M.: Competitive Strategy. Techniques for analyzing industries and competitors. The Free Press. (1980)

18.Lundell, B., Lings, B., Syberfeldt, A.: Practitioner perceptions of Open Source software in the embedded systems area. In the Journal of Systems and Software. pp. 1540–1549 (2011)

19.Morgan, L., Finnegan, P.: Open Innovation in Secondary Software Firms: An Exploration of Managers’ Perceptions of Open Source Software. In DATABASE for Advances in Information Systems, 41(1), 76–95 (2010)

20.Yu, E.: Social Modeling and i*. Conceptual Modeling: Foundations and Applications. In Lecture Notes in Computer Science, Volume 5600, 2009, pp 99-121 (2009)

21.Newman, M. E. J.: Networks – An introduction. University of Michigan and Santa Fe Institute. Oxford University Press. (2010)