Keywords

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: Sect. 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, Sect. 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, Sect. 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).

López 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. (1)

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

  2. (2)

    Goal Alignment: how to align each OSS adoption strategy’ goals from [7] to the OSS adopter business and ecosystem related goals?

  3. (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 1. Characterization of goal levels

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 co-opetitors (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 2. Generic Business Goals

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 3. Generic OSS goals

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].

Figure 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.

Fig. 1.
figure 1

Excerpt for the OSS Integration strategy model.

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

  1. (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 dependum:

    1. (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”.

    2. (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. (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:

    1. (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. (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 4. OSS specific goals of integration OSS adoption strategy

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 Sect. 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 Sect. 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\left( i \right) = 1*SGI + 0.75*TGI + 0.5*OGI $$
(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\left( i \right) = 1*SGG + 0.75*TGG + 0.5*OGG $$
(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:

  1. (a)

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

  2. (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 5. Canvas-based elicited goals for TEI (Value proposition area)

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 6. Goal Mapping Matrix

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.

Fig. 2.
figure 2

Influence path

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 meaning 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. 1.

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

  2. 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. 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.