# Risks and Risk Mitigation in Open Source Software Adoption: Bridging the Gap between Literature and Practice

Øyvind Hauge, Daniela Soares Cruzes, Reidar Conradi, Ketil Sandanger Velle, Tron André Skarpenes

► To cite this version:

Øyvind Hauge, Daniela Soares Cruzes, Reidar Conradi, Ketil Sandanger Velle, Tron André Skarpenes. Risks and Risk Mitigation in Open Source Software Adoption: Bridging the Gap between Literature and Practice. 6th International IFIP WG 2.13 Conference on Open Source Systems, (OSS), May 2010, Notre Dame, United States. pp.105-118, 10.1007/978-3-642-13244-5_9. hal-01056020

HAL Id: hal-01056020

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

Submitted on 14 Aug 2014

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>

Distributed under a Creative Commons Attribution 4.0 International License
# Risks and Risk Mitigation in Open Source Software Adoption: Bridging the Gap between Literature and Practice

Øyvind Hauge, Daniela Soares Cruzes, Reidar Conradi, Ketil Sandanger Velle, and
Tron André Skarpenes

Norwegian University of Science and Technology
[oyvh,dcruzes,conradi,ketilsan,skarpenes]@idi.ntnu.no

**Abstract.** The possible benefits of open source software (OSS) have led organizations into adopting a variety of OSS products. However, the risks related to such an adoption, and how to reduce these risks, are not well understood. Based on data from interviews, a questionnaire, and workshops, this paper reports ongoing work in a multi-national telecom company. The paper has three main contributions. First, it identifies and discusses several risks related to OSS adoption. Second, it identifies steps for reducing several of these risks. Third, it shows how research can be used to increase the visibility of, and involve the employees in, ongoing OSS efforts.

## 1 Introduction

The promise of reduced costs, increased flexibility, and independence from vendors of proprietary products has convinced organizations worldwide into deploying open source software (OSS) products in their production environments and integrating OSS components into their software systems [15,16,19,20]. While a couple of studies have looked at the benefits and drawbacks of such OSS adoption [2,24,35], few have discussed steps for dealing with related risks.

Our primary goal is to identify relevant risks and risk mitigation steps for organizations that adopt OSS products. The secondary goal of the study presented here is to explore the opportunities for increasing organizations' adoption of OSS. This includes identifying potential benefits of an increased OSS adoption. The main research questions investigated in this study are:

* RQ1. What are the perceived benefits of an increased adoption of OSS products?

* RQ2. What are the perceived risks of such an adoption?

* RQ3. What steps may organizations take to reduce these risks?

The study presented in this paper was partially conducted at Telenor, a large international telecommunications company. Telenor's Norwegian IT division has already adopted some OSS products, but it is currently looking into increasing its adoption. However, to avoid the possible pitfalls of OSS adoption, Telenor IT wanted
to identify (1) the benefits of OSS and risks which are relevant to their context and (2) how to deal with potential risks. To support Telenor in finding the answers to these questions, we have conducted a study consisting of semi-structured interviews, a questionnaire with 86 responses, and three workshops.

## 2 Related Literature

OSS can be adopted in different ways. In [19] we show that OSS can be adopted through deploying OSS products, using OSS CASE tools, integrating OSS components, participating in the development of OSS products, providing OSS products, or through using OSS development practices. Grand et al. [18] present a four level model for resource allocation to OSS. In a company perspective, the four levels are (1) a company as a user of OSS software, (2) OSS software as complementary asset, (3) OSS software as a design choice, and (4) OSS compatible business mode. This paper focuses on the **deployment of OSS products** (like operating systems, database servers, application servers etc) within a company at **level 1 or 2** in Grand et al.'s model for resource allocation. The following sections are mainly based on a systematic literature review focusing on OSS adoption [19].

### 2.1 Possible Benefits of OSS

The literature discusses several possible benefits (B) of OSS adoption. However, some of these benefits may be perceived as drawbacks as well [35]. Cost cuts (B1) are, for instance, frequently mentioned as a benefit of OSS adoption, while hidden costs (R1) are mentioned as a risk.

**Cost cuts (B1):** OSS has been claimed to enable costs cuts through for instance reduced license fees, hardware requirement, scaling costs, etc. [2,14,24,33].

**Independence from vendors of proprietary products (B2):** The adopter of OSS may also get increased freedom from vendor lock-in and increased influence on providers of both proprietary and OSS products [2,5,6,23,24].

**Simplified procurement and license management (B3):** The majority of OSS products tend to come with only a few different licenses and without licensing fees. This may simplify the procurement of the software and the licensing of derivative products [23,28].

**Software reuse (B4):** Through adopting software products that are developed, tested, and used by others, we may gain the benefits of software reuse. This includes extra/new functionality, increased R&D and innovation, improved quality (e.g. reliability, security, performance, defect density) and increased productivity [2,5,6,14,25,34]. OSS may also contribute to increased standardization [1,21] or to establishing de-facto standards if no standards exist [23].

**High availability (B5):** OSS products are most often easily available together with source code and trustworthy information about the products' true state [22,23,35].
**Community support (B6):** This openness may lead to increased collaboration between community members [2,24]. The community might also provide free maintenance and upgrades of the software together with user support [5,24,33].

## 2.2 Potential Risks of OSS Adoption

There are also risks (R) related to adopting OSS but not all organizations consider them, as there are organizations adopting OSS without performing any cost/benefit analysis [35]. There are no papers that explicit focus on potential risks of OSS adoption, but the literature mentions several possible drawbacks of OSS adoption.

**Hidden costs (R1):** Adoption of OSS products is not without costs: It may be time-consuming to evaluate them [31]. Adoption may involve user training and configuration [24,31]. We might need to spend resources on community participation [23]. Many organizations would need premium professional support [14,35].

**Lack of products (R2):** While there are many OSS products available, there may still be a lack of products with specific functionality [6,24]. The quality of these products can also be questionable [14,35]. OSS products may furthermore suffer from limited standardization and compatibility with document formats or with versions of other software products [2,24,25].

**Lack of providers, expertise, and support (R3):** Despite the significant adoption of OSS, there may still be a lack of expertise and support for specific products [2,24,31,35]. The lack of professional providers may also introduce unclear liability and uncertainty about the longevity of OSS project as OSS projects may lack roadmaps and documentation [2,24]. Holck et al. hypothesized that this lack of traditional vendor-customer relationship could stop the adoption of OSS [22].

**Customization needs (R4):** It may be necessary to customize the OSS products to fit them into the context in which they are going to be used [1]. When changing an OSS product we may get a maintenance responsibility [36] as these changes must be updated when more recent versions of the software are adopted. When these situations arise, the adopter must decide to follow the new releases or ensure backward compatibility with his own changes [23].

**Licensing issues (R5):** The variety of OSS licenses available is confusing, as there is a lack of guidance on how to interpret them [31]. When adopting OSS and when integrating it into derivative software systems, it may be challenging to combine code under an OSS licenses with proprietary licenses and APIs [23].

## 2.3 Risk Mitigation in OSS Adoption

As there are few publications discussing risk mitigation (RM), this section describes literature on success criteria and enabling versus inhibiting factors of OSS adoption. Some of these issues may contribute to reduce the risks of OSS adoption.

**Employee attitude, awareness, and skills (RM1):** A positive employee attitude towards OSS and the OSS ideology can enforce the adoption of it [4,5,16,25,34]. The
adoption of OSS should also be made visible, so that end users have an awareness of
the technology adoption [6]. Finally, if employees have the necessary skills and
experience with OSS, the probability of a successful adoption will increase [6,16,32].

**Management support (RM2):** Management support is also important for OSS adoption [6,14,16]. Management should provide resources for driving the adoption, and a clear plan for analysis, testing, and pilot projects [6, 13, 16].

**Access to support (RM3):** The quality of the OSS components [29] is an important factor for a successful adoption, and for many adopters it is also necessary to have access to professional support [6,13].

**Success stories (RM4):** It is furthermore an advantage if the products have been successfully adopted by other companies [16]. Lack of such success stories or lack of other users could easily complicate the OSS adoption [2,4].

**No lock-in (RM5):** An organization may have a hard time adopting OSS if they are locked in by industry-wide purchasing agreements and standards for IT or already have a coherent stable IT infrastructure based on proprietary or legacy technology [6,16]. The costs related to moving away from such a lock-in situation can significantly impede the adoption of OSS [4,17,35].

**3 Context and Research Method**

Telenor is currently among the ten largest mobile operators in the world Telenor Norway IT (hereafter Telenor IT) is the information technology and software support division under Telenor's Norwegian branch. It has about 380 employees that together with several external partners develop, maintain, and support more than 500 IT systems. Open Source 2010 is an Telenor IT project aiming at exploring the opportunities of adoption of OSS products like databases, application servers etc.

Telenor IT's motivation for conducting this study was threefold. First, Telenor IT wanted to increase the awareness of OSS and its Open Source 2010 project within the organization. Second, it wanted to get feedback from and involve the employees in the project's work. Third, it wanted to weaken the grip providers of proprietary products have on Telenor, and reduce Telenor's expenses on licensing and support.

This study consisted of four main steps. As part of a **systematic literature review** on OSS in organizations, we reviewed the literature for evidence on the perceived benefits and drawbacks of OSS [19]. Some of the output from this review was used as an input for Section 2. Next, we conducted **semi-structured interviews** with four employees. The respondents had different positions (developer, system specialist, chief engineer, and manager) within different parts of Telenor IT (mobile, landlines, data warehouse & business intelligence, and customer relation management). They had been with the company from two to nine years. The interviews were carried out through 30 minutes face-to-face sessions that were recorded and later transcribed. Based on these interviews, we developed a **questionnaire**. The questionnaire was pre-tested by colleagues at the university and nine employees from different parts of Telenor IT. The questionnaire was written in Norwegian, and the final version
contained 42 open and closed questions (using 5-point Likert scales). However, we will focus mainly on the questions below:

Q1. Which advantages and disadvantages do you see with the use of OSS in Telenor IT? (See Table 1);

Q2. For which reasons do you think Telenor IT should select OSS instead of proprietary products and vise versa? (See Table 2);

Q3. Why should Telenor IT increase its use of OSS? (Open);

Q4. Which risks do you see with increased use of OSS in Telenor IT? (Open);

Q5. If the use of OSS in Telenor IT should be increased, what should do Telenor do to facilitate this? (See Table 3);

Q6. Where would an increased use of OSS be appropriate? (Open).

The questionnaire was conducted with a sample of 140 employees from Telenor IT that were handpicked by our local contact. This sampling technique was used to get a representative sample of employees from all relevant parts of the organization while avoiding employees who were not involved in development and/or support of Telenor's software systems. In total 86 respondents completed the survey, giving a response rate of over 60%. The analysis of the data consisted of descriptive statistics, statistical tests, and grouping of about 200 comments from the open questions.

After the analysis, we held three **workshops**. First, we presented the results from the questionnaire to several employees from various parts of the organization. Second, three project members and three employees with experience from different operating environments participated in a discussion around (1) benefits, (2) risks, and (3) approaches related to increasing the organization's adoption of OSS. These three sessions were performed as "KJ sessions" [3], where each of the workshop participants used post-it notes to write down their concerns and put these notes on a white board. In total 152 post-it notes were collected. Then the participants re-arranged related notes into groups as a collaborative effort. These groups of related issues were then discussed. Finally, we presented these results during a third dissemination workshop, open to all employees at Telenor IT.

# 4 Results

Results presented in this section were grouped according to the research questions (RQ) stated in the introduction. In the following, we summarize the main findings related to these RQs, while keeping a focus on the results most relevant to Telenor.

RQ1. Based on the interviews, questions (Q1, Q2, Q3), and the workshop, we have identified the main perceived benefits (BT) of OSS adoption;

RQ2. Based on the interviews, question (Q4), and the workshop, we have identified several potential risks (RT) related to adoption of OSS;

RQ3. Mainly through the workshop and the interviews, but also questions (Q5, Q6), we have identified steps for (1) facilitating the adoption of OSS and (2) steps for mitigating (RMT) some of the risks related to it.
## 4.1 RQ1: Potential benefits of OSS

**Reduced costs (BT1):** Cost reduction is the most cited advantage of OSS adoption. Table 1 shows that the respondents to the questionnaire agreed (Q1.1). Several respondents stressed the value of reducing the expenses on support agreements and claimed that OSS could contribute to this. One respondent suggested that they could simplify the administration of (proprietary) software licenses. Moreover, Table 2 shows that the respondents expected both development and maintenance costs to be lower with OSS (Q2.1 and Q2.2). Finally, if Telenor could standardize on one OSS platform, the IT department could increase its productivity and reduce costs from running on a more homogeneous and cheaper hardware platform.

**Independence from vendors of proprietary products, and the ability to apply pressure on providers (BT2)** was frequently discussed by interviewees, workshop participants and many of the responses to Q3 (see also Q1.2 and Q1.3). They highlighted in particular the ability to use OSS to apply pressure on their vendors in order to make them lower their license and support fees. As one respondent wrote “[when using OSS, one] *may chose to pay for support if you actually need it (often one does not need it)*” (Q3).

**Attractive and future-oriented technology as a motivational factor for the employees (BT3):** Several popular technologies are offered as OSS, and the interviewees mentioned that using OSS could improve the Telenor brand (Q2.4), be a source of motivation for current employees (Q1.4), and be a way to attract skilled employees. The ability to work with new and open technology was also perceived as being fun by the workshop participants. In fact, quite a lot of attention was drawn to this issue. OSS technology was also considered to be the future for several areas. For instance, one workshop participant wrote that “*OSS is future oriented and it enables access to competency*”. A respondent in the questionnaire wrote that “*OSS is becoming the industry standard in many areas*” (Q3).

**Ease of use through access to information and the source code (BT4):** The respondents suggested that OSS technology was easier to use because of the high availability of the software, its source code, and related information (see also Q1.5, Q2.3, and Q2.5). One workshop participant wrote that because of this availability “[it] is easier to make prototypes and to evaluate the software”. A respondent in the questionnaire wrote: “*it is better to modify what is meant to be modified rather than buying a final package and doing extra development around it [the package]*” (Q3). The workshop participants furthermore believed that the flexibility and openness of OSS could give them better and more innovative solutions. Easy access to technology, development tools, together with the technical support, documentation, and other resources, could further reduce the effort needed to develop and maintain their systems. Having access to the communities behind the OSS products was seen as an advantage, not only to get support, but also to influence the development of the products. One responded: “*OSS products are quite often having active communities*”
with dedicated users who are more than willing to help” (Q3). OSS communities were considered to be more accessible than vendors of proprietary products.

<table><caption>**Table 1.** Potential advantages and disadvantages with OSS in Telenor IT (Q1)</caption><thead><tr><th>ID</th><th>Statement</th><th>Mean</th><th>STD</th></tr></thead><tbody><tr><td>Q1.1</td><td>Reduced licenses costs</td><td>4.56</td><td>0.86</td></tr><tr><td>Q1.2</td><td>Independence from providers</td><td>4.48</td><td>0.88</td></tr><tr><td>Q1.3</td><td>Ability to apply pressure on providers</td><td>4.41</td><td>0.93</td></tr><tr><td>Q1.4</td><td>Motivational factor for the employees</td><td>4.16</td><td>0.99</td></tr><tr><td>Q1.5</td><td>Access to read and modify source code</td><td>4.10</td><td>1.01</td></tr><tr><td>Q1.6</td><td>Confidence and experiences with provider</td><td>3.26</td><td>1.18</td></tr><tr><td>Q1.7</td><td>Existing contracts with providers</td><td>3.19</td><td>1.28</td></tr></tbody></table>

<table><caption>**Table 2.** Reasons for selecting OSS versus proprietary software (Q2)</caption><thead><tr><th>ID</th><th>Statement</th><th>Mean</th><th>STD</th></tr></thead><tbody><tr><td>Q2.1</td><td>Reduced maintenance costs.</td><td>4.15</td><td>1.15</td></tr><tr><td>Q2.2</td><td>Reduced development costs.</td><td>4.05</td><td>1.13</td></tr><tr><td>Q2.3</td><td>Possibility to run pilot-tests (alpha/beta tests) before release.</td><td>3.94</td><td>1.2</td></tr><tr><td>Q2.4</td><td>Improve Telenor's brand and reputation.</td><td>3.76</td><td>1.17</td></tr><tr><td>Q2.5</td><td>Adaptability to existing systems.</td><td>3.68</td><td>1.32</td></tr><tr><td>Q2.6</td><td>Development time.</td><td>3.64</td><td>1.13</td></tr><tr><td>Q2.7</td><td>Influence on provider (add new or changed functionality).</td><td>3.64</td><td>1.43</td></tr><tr><td>Q2.8</td><td>Availability of external expertise and experience.</td><td>3.48</td><td>1.35</td></tr><tr><td>Q2.9</td><td>Availability of support during development.</td><td>3.32</td><td>1.33</td></tr><tr><td>Q2.10</td><td>Available information (manuals etc.).</td><td>3.24</td><td>1.43</td></tr><tr><td>Q2.11</td><td>Functional requirements (adequate functionality)</td><td>3.19</td><td>1.17</td></tr><tr><td>Q2.12</td><td>Non-functional requirements (quality, reliability, security, scalability, performance, usability etc.</td><td>2.95</td><td>1.26</td></tr><tr><td>Q2.13</td><td>Availability of support in production</td><td>2.87</td><td>1.38</td></tr></tbody></table>

## 4.2 RQ2: Potential Risks and Drawbacks

**Lack of support and expertise (RT1):** The lack of a professional provider is not necessarily a problem. However, the lack of support and expert advice, in particular for complex problems, was considered as one of the major challenges with OSS. One of the interviewees feared that they would need to increase their internal resources quite dramatically. Telenor requires professional support 24/7. However, providers of such support are not necessarily available for all OSS products. One workshop participant pointed this out and wrote that “[there are] few/no international support organizations (for instance when you need 24/7 operation)”. Moreover, since the diffusion of OSS products is not always as large as their proprietary equivalents, the workshop participants feared that it could be difficult to get hold of both expert consultants and highly skilled employees.
**Hard to select the right OSS product (RT2):** The respondents expressed an uncertainty related to whether there existed OSS equivalents for some of the largest and most advanced systems they had. The respondents moreover feared that existing OSS products were immature and would miss key functions. One respondent wrote that "there are in some cases no OSS products, or no OSS products which are good enough, for solving certain problems" (Q4). The products may also lack support from a viable community and they may therefore have an uncertain future. Adopting such immature or unsupported products can introduce significant costs further down the road, and it was therefore considered important to find the right products.

**Change and hidden costs (RT3):** OSS products would in most cases be acquired and maintained somewhat differently than proprietary products. Most OSS products are available over the Internet and do not have the same number of providers pushing and supporting the products. These changes may improve the way the organization works but any change introduces challenges, uncertainty, and at least some costs. A workshop participant wrote that "[Telenor] has to find and relate to new partners", something which would include both change and cost. The respondents were uncertain whether the cost savings from reduced licensing and support fees would outweigh the cost related to switching technology and changing the way they worked, as some of them described the total cost of adopting OSS as "foggy". One respondent wrote that "replacing familiar technology" (Q4) could be a potential risk. Replacing existing technology would also make current expertise less valuable.

**Unclear liability and responsibility (RT4):** As of today Telenor's partners have relatively clearly defined responsibilities. Changing these relationships was considered an important challenge. One responded that it could lead to "unclear distribution of roles between provider - customer [Telenor]" (Q4). Most OSS products lack a clear (professional) vendor and the respondents feared ending up in situations with unclear liability, where they were unable to influence the provider, and where they would not get sufficient support. One respondent wrote "[we have] no provider to make responsible in situations with critical errors" (Q4). Such situations could put a significant strain on Telenor's internal resources.

**Uncontrolled adoption and modification (RT5):** Changes, or potential anarchy, related to the acquisition of software was discussed to some length in the workshop. This is because (1) there are a lot of easily available OSS products (in many different versions), (2) there is a lot of hype around many of these products, and (3) they are very easy to modify. Some participants feared that this could lead to uncontrolled adoption and modification of new OSS products. This would give Telenor a diverse and expensive to maintain a software portfolio. One workshop participant wrote that he feared that "one [Telenor employees] selects products because they are OSS, not because they solve our problems". A respondent in the questionnaire feared what he called "product anarchy" meaning that the selected a lot of products without really making sure that they were the right ones.
## 4.3 RQ3: Mitigating the Risks Related to OSS Adoption

**Place responsibility, dedicate resources, and ensure support (RMT1):** To make sure that Telenor IT has the necessary resources to develop, support, and operate OSS based systems, it was considered important to place the responsibility for the adopted products between internal resources and external partners. This was highlighted by several participants in our study. One of them wrote that “[Telenor must] coordinate with development, internal operations, and external [service] providers”. This could involve increasing the internal resources or allocating employees to, not only support OSS solutions, but also to developing new solutions and monitoring the OSS community. It may also involve dealing with new partners, or driving existing partners into adopting new technology. The participants in the study expressed particular concerns about ensuring support for the really difficult problems.

**Start pilot projects (RMT2):** The respondents agreed that it was important not to rush the adoption of OSS, but promoted instead a cautious, stepwise approach to OSS. According to them, Telenor IT had to gain experience with one project at the time through identifying projects where OSS would be give real benefit. These pilot projects could then be used to illustrate the potential and true benefits of OSS within the organization. The respondents acknowledged that pilot projects were important not only to illustrate the potential of OSS products, but also to have a more moderate learning curve and limit the consequences of problems. One workshop participant wrote that “[Telenor should] incrementally introduce OSS and consider new/revise measures based on our own experience”.

**Increase awareness and make the OSS initiative visible (RMT3):** The first thing which could be done, is making the organization's current and planned use of OSS visible to, not only its employees and management, but also its partners (see Table 3). In the workshop one participant wrote that “[Telenor IT must] make the concrete advantages visible”. By identifying successful cases of OSS adoption and making these visible, they may create a positive attitude towards OSS and show that it is a viable option for the future. Moreover, it was considered important to explain why Telenor IT is planning to increase its adoption of OSS.

**Include OSS in strategies supported by top management (RMT4):** Finally, the adoption of OSS should not be left up to chance and the individual employees' taste. A workshop participant wrote that “[Telenor] should not allow the system or project select freely [it should rather] be part of a strategic technological decision”. To ensure that the OSS adoption was planned, it should be part of a strategy where (top) management, developers, operations, and support were involved in the decision making process. It was furthermore considered important to assess the benefits versus the costs in each specific case. Management support was considered important because Telenor IT mainly used OSS products in risk-free development environments. The consequences of failure in production environments is obviously higher, and it was therefore perceived important to ensure the support of management.
<table><caption>**Table 3.** Possible steps for increasing the adoption of OSS (Q3)</caption><thead><tr><td>ID</td><td>Statement</td><td>Mean</td><td>STD</td></tr></thead><tbody><tr><td>Q3.1</td><td>Start one/several pilot projects to show possible effects of OSS</td><td>4.54</td><td>0.85</td></tr><tr><td>Q3.2</td><td>Make the OSS initiative visible for all employees</td><td>4.48</td><td>0.63</td></tr><tr><td>Q3.3</td><td>Make visible the OSS already present in the organization</td><td>4.44</td><td>0.85</td></tr><tr><td>Q3.4</td><td>Top management commitment to the OSS initiative</td><td>4.42</td><td>0.95</td></tr><tr><td>Q3.5</td><td>Make someone responsible for monitoring selected OSS domains</td><td>4.15</td><td>0.93</td></tr><tr><td>Q3.6</td><td>Improve both internal and external knowledge management (e.g. with a Wiki, message boards, mailing lists, blogs or similar)</td><td>4.14</td><td>0.94</td></tr><tr><td>Q3.7</td><td>Hire new employees with OSS experience</td><td>3.96</td><td>0.99</td></tr><tr><td>Q3.8</td><td>Hire external consultants with updated expertise</td><td>3.06</td><td>1.19</td></tr><tr><td>Q3.9</td><td>Restructure the business model of Telenor IT</td><td>2.74</td><td>1.12</td></tr></tbody></table>

## 5 Risks and Risk Mitigation Strategies

Our empirical results confirm many of the findings from the literature review presented in Section 2. Through the literature review and our study we have identified several risks related to the adoption of OSS products. Table 4 shows an aggregation of the results from this study and from the literature, in a first step towards a risk mitigation approach in OSS adoption. Most of these are already presented in Section 2 or 4. The table is divided in three main columns. The first column lists the main risks identified in the study. The second column describes possible steps for mitigating these risks. This is once more based in our study and the papers that implicitly or explicitly discuss these steps. The third column describes other possible steps that were only identified in the literature.

Besides the results shown in Table 4, we identified some general steps for reducing the risks related to adoption of OSS products such as: (1) increasing the employees' skills (hire new or train existing) (RM1), (2) increasing the employees' attitude towards, and awareness of, current adoption of OSS and ongoing OSS initiatives (RM1), (3) ensuring top management commitment to the OSS initiative (RM2), and (4) avoiding going from a proprietary to an OSS lock-in (RM5).

The literature also mentions licensing and customization of the OSS products as potential risks related to OSS adoption. These risks were not discussed in the table or in our results. First, Telenor IT's Open Source 2010 project did not consider licensing issues to be a problem, particularly since Telenor is not going to distribute its software. Issues related to releasing the source code were therefore not relevant. However, it was suggested to seek legal advice to approve a set of OSS licenses, and adopt only products with these licenses. Second, customization needs was not given much attention. One possible explanation could be that Telenor IT focused on software like operating systems, database servers, and application servers. These products constitute a “software infrastructure” and are mainly configured and deployed. Customization problems is perhaps more relevant for other kinds of software products or components.
<table><caption>**Table 4.** Possible risks and steps for reducing these risks</caption><thead><tr><th rowspan="2">Potential risks of adopting OSS products</th><th colspan="2">Possible risk reduction steps</th></tr><tr><th>From the Telenor case</th><th>From the literature</th></tr></thead><tbody><tr><td>OSS products may lack (professional) support. There may be limited access to expertise, and situations involving unclear liability and division of responsibility may occur. (R3+RT1+RT4)</td><td>- Place responsibility at an early stage (RMT1)<br>- Make sure that your service providers support OSS products (find new ones or ask existing ones to extend their service offering) (RMT1)<br>- Increase/dedicate internal resources to OSS (RMT1)<br>- Increase employee skills (hire new or train existing) (RM1+RMT1)</td><td>- Encourage local "OSS champions" [16]</td></tr><tr><td>Hidden costs related to adopting OSS, replacing existing technology, and changing current processes. (R1+RT3)</td><td>- Conduct risk assessments<br>- Execute pilot studies and a planned stepwise adoption (RM2+RMT2)<br>- Adopt (only) products which show a clear added-value and have a proven track record (RM4&5)</td><td>- Evaluate the total costs of ownership of OSS products in your own context [35]</td></tr><tr><td>Hard to select the right product due to (1) lack of products or products with matching functionality and/or quality, and (2) the amount of products and information available. (R2+RT2)</td><td>- Adopt only mature products which give clear benefits (RMT4)<br>- Dedicate personnel to monitoring the OSS community and selecting OSS products (RMT1)</td><td>Research suggests several methods for selecting OSS products like for instance [7,9,30]</td></tr><tr><td>Uncontrolled adoption and modification, due to the high availability of OSS products, their low purchase price, and the access to these products' source code. (RT5)</td><td>- Have a plan/strategy behind adopting the various OSS products (RMT4)<br>- Adopt products which show a clear added-value and have a proven track record (RM4&5)<br>- Standardize on a limited set of technologies/products (RMT4)<br>- Begin with a few products (e.g. operating systems, databases, and server applications)<br>- Require that new products should run on OSS platforms when writing call for tenders and requirements specifications<br>- Keep track of the adopted software<br>- Create guidelines for adoption<br>- Dedicate personnel with responsibilities for OSS adoption (review and monitoring) (RMT1)<br>- Conduct risk assessments<br>- Involve management, development, operation, support, (and external partners). (RMT1)</td><td>- Define a strategy for maintenance and modifications [35]<br>- Set up a central software repository for adopted products [10]</td></tr></tbody></table>
# 6 Limitations of this Study

The sampling for the questionnaire was conducted by our contact person at Telenor. This may pose a possible threat to the validity of our results, since the sample and respondents may have more experience with OSS than the rest of the organization. However, our contact has long experience from the company, we got a high response rate, and the respondents reflect the organization at large. Moreover, when we presented the results at the workshops the audience was allowed to participate, and we did not get any feedback indicating that the results were wrong.

The study benefits from data triangulation through the use of interviews, a questionnaire, and workshops. However, we conduct only four interviews of 30 minutes each. The study would benefit from further, more in-depth interviews.

There are many different OSS products available, and these products do not share the same properties. The same holds for proprietary products. Asking about benefits, risks, and steps for reducing risks related to an increased OSS adoption is therefore somewhat problematic. We must have in mind that the answers reflect the individual respondent's perception of OSS and proprietary products. To get more precise data one would need to compare individual OSS products against specific proprietary products.

# 7 Conclusion and Future Work

Based on an extensive literature review and a study from a telecom company (Telenor IT Norway), we have **identified several risks** related to the deployment of OSS products. However, the paper's main contributions are the **identified steps for reducing these risks**. In addition, we establish a link between our results from a company and results the literature in Section 5. There are limitations associated with the findings from this paper. Nevertheless, we believe the results of this study are a first step towards focusing the research, on risks of OSS adoption, on more measurable approaches for such evaluation. Finally, our study focuses on bridging the gap between OSS research and practice by focusing on topics highly relevant to practitioners. The study is furthermore an example of how researchers and practitioners may benefit from closer collaboration.

As future work we intend to follow the process of adoption of OSS at this company to further investigate and measure the real effect of the adoption of OSS. A particular focus will be directed towards the relationship between the Telenor IT's internal development and support, and their partners. We also acknowledge that many of the risks and mitigation steps described in this paper are similar to the ones described in the literature of adoption/diffusion of general information technology e.g. [12, 26]. This research could also lend research on OSS adoption valuable support (see e.g. [13]). We intend to do more research in order to investigate these issues, so we can focus the OSS research on the issues that are mostly related to the OSS adoption, and not part of the general issues related to general adoption/diffusion of information technology.
References

1. Paul Adams, Cornelia Boldyreff, David Nutter, and Stephen Rank. Adaptive Reuse of Libre Software Systems for Supporting On-line Collaboration. In Joseph Feller, Brian Fitzgerald, Scott A. Hissam, Karim R. Lakhani, and Walt Scacchi, editors, Open Source Application Spaces: Proceedings of the Fifth Workshop on Open Source Software Engineering (WOSSE 2005), pages 1–4. ACM, 2005.

2. Pär. J. Ågerfalk, Andrea Deverell, Brian Fitzgerald, and Lorraine Morgan. Assessing the Role of Open Source Software in the European Secondary Software Sector: A Voice from Industry. In Scotto and Succi [26], pages 82–87.

3. Andreas Birk, Torgeir Dingsøyr, and Tor Stålhane. Postmortem: Never Leave a Project without It. IEEE Software, 19(3):43–45, 2002.

4. Andrea Bonaccorsi, Silvia Giannangeli, and Christina Rossi. Entry Strategies Under Competing Standards: Hybrid Business Models in the Open Source Software Industry. Management Science, 52(7):1085–1098, 2006.

5. Andrea Bonaccorsi and Christina Rossi. Comparing motivations of individual programmers and firms to take part in the open source movement: From community to business. Knowledge, Technology, and Policy, 18(4):40–64, dec 2006.

6. Daniel Brink, Llewelyn Roos, James Weller, and Jean-Paul Van Belle. Critical Success Factors for Migrating to OSS-on-the-Desktop: Common Themes across Three South African Case. In Damiani et al. [8], pages 287–293.

7. David Cruz, Thomas Wieland, and Alexander Ziegler. Evaluation Criteria for Free/Open Source Software Products Based on Project Analysis. Software Process: Improvement and Practice, 11(2):107-122, 2006.

8. Ernesto Damiani, Brian Fitzgerald, Walt Scacchi, and Marco Scotto, editors. Proceedings of the 2nd IFIP Working Group 2.13 International Conference on Open Source Software (OSS2006) - Open Source Systems, June 8-10, Como, Italy, volume 203/2006 of IFIP International Federation for Information Processing. Springer, 2006.

9. Vieri del Bianco, Luigi Lavazza, Sandro Morasca, and Davide Taibi. Quality of Open Source Software: The QualiPSo Trustworthiness Model. In Cornelia Boldyreff, Kevin Crowston, Björn Lundell, and Anthony I. Wasserman, editors, Proceedings of the 5th IFIP Working Group 2.13 International Conference on Open Source Systems (OSS2009) - Open Source Ecosystems: Diverse Communities, June 3-6, Skövde, Sweden, volume 299/2009 of IFIP International Federation for Information Processing, pages 199-212. Springer, 2009.

10. Jamie Dinkelacker, Pankaj K. Garg, Rob Miller, and Dean Nelson. Progressive Open Source. In Will Tracz, Jeff Magee, and Michal Young, editors, Proceedings of the 24th International Conference on Software Engineering (ICSE 2002), May 19th-25th, Orlando, Florida, pages 177–184. ACM, 2002.

11. Joseph Feller, Brian Fitzgerald, Walt Scacchi, and Alberto Sillitti, editors. Proceedings of the 3rd IFIP Working Group 2.13 International Conference on Open Source Software (OSS2007) - Open Source Development, Adoption and Innovation, June 11th-14th, Limerick, Ireland, volume 234/2007 of IFIP International Federation for Information Processing. Springer, 2007.

12. Robert G. Fichman. Information Technology Diffusion: A Review of Empirical Research. In Janice I. DeGross, Jack D. Becker, and Joyce J. Elam, editors, Proceedings of the Thirteenth International Conference on Information Systems (ICIS '92), December 13th-16th, Dallas, USA, pages 195-206, Minneapolis, MN, USA, 1992. University of Minnesota.

13. Brian Fitzgerald. Open Source Software Adoption: Anatomy of Success and Failure. International Journal of Open Source Software & Processes, 1(1):1–23, 2009.
14. Brian Fitzgerald and Tony Kenny. Developing an Information Systems Infrastructure with Open Source Software. IEEE Software, 21(1):50-55, 2004.

15. Rishab Aiyer Ghosh. Study on the Economic Impact of Open Source Software on Innovation and the Competitiveness of the Information and Communication Technologies (ICT) Sector in the EU. Technical report, UNU-MERIT, 2006.

16. Eugene Glynn, Brian Fitzgerald, and Chris Exton. Commercial Adoption of Open Source Software: An Empirical Study. In June Verner and Guilherme Horta Travassos, editors, Proceedings of International Symposium on Empirical Software Engineering (ISESE 2005), November 17th-18th, Noosa Heads, Australia, pages 225-234. IEEE Computer Society, 2005.

17. Sigi Goode. Something for nothing: management rejection of open source software in Australia's top firms. Information & Management, 42(5):669-681, 2005.

18. Simon Grand, Georg von Krogh, Dorothy Leonard and Walter Swap. Resource allocation beyond firm boundaries: A multi-level model for Open Source innovation. Long Range Planning, 37(6): 591-610, 2004.

19. Øyvind Hauge, Claudia P. Ayala, and Reidar Conradi. Open Source Software in Organizations - A Systematic Literature Review. Submitted to Information and Software Technology.

20. Øyvind Hauge, Carl-Fredrik Sørensen, and Reidar Conradi. Adoption of Open Source in the Software Industry. Barbara Russo, Ernesto Damiani, Scott A. Hissam, Björn Lundell, and Giancarlo Succi, editors. Proceedings of the 4th IFIP Working Group 2.13 International Conferences on Open Source Software (OSS2008) - Open Source Development Communities and Quality, September 7th-10th, Milano, Italy, volume 275/2008 of IFIP International Federation for Information Processing, pages 211-222. Springer, 2008.

21. Øyvind Hauge, Carl-Fredrik Sørensen, and Andreas Røsdal. Surveying Industrial Roles in Open Source Software Development. In Feller et al. [11], pages 259-264.

22. Jesper Holck, Michael Holm Larsen, and Mogens Kühn Pedersen. Managerial and Technical Barriers to the Adoption of Open Source Software. In Xavier Franch and Daniel N. Port, editors, Proceedings of the 4th International Conference on Component-Based Software Systems (ICCBSS 2005), February 7-11, Bilbao, Spain, volume 3412/2005 of LNCS, pages 289-300. Springer, 2005.

23. Ari Jaaksi. Experiences on Product Development with Open Source Software. In Feller et al. [11], pages 85-96.

24. Lorraine Morgan and Patrick Finnegan. Benefits and Drawbacks of Open Source Software: An Exploratory Study of Secondary Software Firms. In Feller et al. [11], pages 307-312.

25. Bülent Ozel, Uros Jovanovic, Beyza Oba, and Manon van Leeuwen. Perceptions on F/OSS Adoption. In Feller et al. [12], pages 319-324.

26. Everett M. Rogers. Diffusion of Innovations. Free Press, New York, USA, 5th edition, 2003.

27. Marco Scotto and Giancarlo Succi, editors. Proceedings of The First International Conference on Open Source Systems (OSS2005), July 11th-15th, Genova, Italy, 2005.

28. Nicolas Serrano, Sonia Calzada, Jose Maria Sarriegui, and Ismael Ciordia. From Proprietary to Open Source Tools in Information Systems Development. IEEE Software, 21(1):56-58, 2004.

29. So Young Sohn and Min Seok Mok. A strategic analysis for successful open source software utilization based on a structural equation model. Journal of Systems and Software, 81(6):1014-1024, June 2008.

30. Davide Taibi, Luigi Lavazza, and Sandro Morasca. OpenBQR: a framework for the assessment of OSS. In Feller et al. [11], pages 173-186.
31. Francis Tiangco, Alison Stockwell, John Sapsford, and Austen Rainer. Open-source software in an occupational health application: the case of Heales Medical Ltd. In Scotto and Succi [26], pages 130–134.

32. Kris Ven, Dieter Van Nuffel, and Jan Verelst. The Introduction of OpenOffice.org in the Brussels Public Administration. In Damiani et al. [8], pages 123-134.

33. Kris Ven and Jan Verelst. The Organizational Adoption of Open Source Server Software by Belgian Organizations. In Damiani et al. [8], pages 111–122.

34. Kris Ven and Jan Verelst. The Impact of Ideology on the Organizational Adoption of Open Source Software. Journal of Database Management, 19(2):58–72, April 2008.

35. Kris Ven, Jan Verelst, and Herwig Mannaert. Should You Adopt Open Source Software? IEEE Software, 25(3):54–59, 2008.

36. Kris Ven and Herwig Mannaert. Challenges and strategies in the use of Open Source Software by Independent Software Vendors. Information and Software Technology, 50(9-10):991{1002, August 2008.