Towards a Reference Framework for Open Source Software Adoption Lucía Méndez Tapia Universitat Politècnica de Catalunya (UPC) c/Jordi Girona, 1-3, E-08034 Barcelona, Spain Advisors: PhD. Claudia P. Ayala and PhD. Lidia López Abstract. Nowadays, the use of Open Source Software (OSS) components has become a driver for the primary and secondary information technology (IT) sector, among other factors, by the openness and innovation benefits that can give to the organizations, regardless of its business model and activities’ nature. Nevertheless, IT companies and organizations still face numerous difficulties and challenges when making the strategic move to OSS. OSS is aligned with new challenges, which mainly derive from the way OSS is produced and the culture and values of OSS communities. In fact, OSS adoption impacts far beyond technology, because it requires a change in the organizational culture and reshaping IT decision-makers mindset. Therefore, this research work proposes a framework to support OSS adopters (i.e., software-related organizations that develop software and/or offer services relate to software) to analyze and evaluate the impact of adopting OSS as part of their software products and/or services offered to their customers/users, mainly in terms of their software related activities. Keywords: Open Source Software, OSS adoption strategies, business model, innovation. 1 Introduction The use of Open Source Software (OSS) components by the software industry has growing steadily [1]. Organizations are increasingly becoming OSS components adopters (hereafter 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 rely at some extent in OSS infrastructure [2]. One of the main motivations for adopting OSS are related to the lower licensing cost schema, productivity growth and short time to market of software products (originated in the savings and reductions of effort and working time of the personnel), and the facilities to avoid vendor/consultant lock-in [3]. Progressively, organizations have realized other attractive benefits such as the promotion of content dissemination (with high importance to develop knowledge), and the capacity to create and deploy the software as a public good (relevant for example, to standardize the implementation of common processes among government entities). OSS is commonly characterized by the community support to the software development process, the incorporation of agile and collaborative development methods, the possibility to access to common source code and to adapt it to specific needs [4], [3]. In addition, there exist a variety of OSS in very diverse domains. Michael Blechar at Gartner group stated that “OSS can be a major enabler of productivity and savings. IT organizations that are mature in OSS adoption have the potential to be 5 to 10 times more productive and responsive than those that do not” [5]. 2 Research Problem Empirical data shows that software-intensive organizations (i.e., private or public organizations extensively use or develop software) are adopting OSS in very diverse ways [6]: deploying OSS products in their operation environment as end users (e.g., deploying OpenOffice.org, Linux, and JBoss) [7]; using OSS tools in their software development environment (e.g., Eclipse or Subversion) [8]; using software development practices, often associated with OSS communities, within a company or consortium of companies (e.g., using practices like code sharing, peer reviewing, and user contribution) [9], [10]; and integrating OSS components into their own software systems (this integration may involve modifying, extending, or wrapping the OSS component) [11]. According to estimations, in 2016 as high as 95% of all commercial software packages will include OSS components [1]. Another survey reports [2] that 78% of organizations run its operations (or part of them) in OSS, 66% build its customer software on OSS, 88% expected to increase its participation in OSS projects, and 93% of the OSS use increased or remained the same in the last year. Thus, OSS adoption impacts far beyond technology and it might require a change in the organizational culture and reshaping IT decision-makers mindset. The way in which OSS adoption affects and shape business models is becoming object of increasing attention [12]. Leveraging OSS adoption strategies is a challenging task per se, as it implies reconciling these strategies in the organization from very different perspectives [13]. The importance of OSS adoption has been identified in practice by researches like [6], [14], [15], and [16]. However, there is a lack of support to help organizations to assess the impact of OSS adoption [17], and it is estimated that 55% of OSS adopters have no formal policy or procedure for OSS consumption [2]. In this context, IT companies and organizations are still facing numerous difficulties and challenges when making the strategic move to OSS. Most these challenges derive from the way OSS is produced and the culture and values behind OSS. 3 Research Goal Taking into account the problem described above, 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, [18] has modeled 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 [18] 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. Therefore, this research work aims to complement the work done in [18] by considering a further business assessment of the OSS adopter ecosystem when approaching a specific OSS adoption strategy. 3.1 Objective This research work aims to: Propose a framework to support OSS adopters (i.e., software-related organizations that develop software and/or offer services relate to software) to analyze and evaluate the impact of adopting OSS as part of their software products and/or services offered to their customers, mainly in terms of their software related activities. 3.2 Research Questions The main objective has been broken down into the following research questions that lead the development of this research.  RQ1. What is the current state of the art and practice of software related organizations that adopt OSS? o RQ1.1 Which are the main current OSS adoption strategies followed by software related organizations? o RQ1.2 Which are the main risks and challenges of software related organizations when adopting OSS? The goal of RQ1 is to know the state of the art and practice of OSS adoption. It is important to know how the organizations are adopting OSS, which are the difficulties encountered along the adoption process, the organizational weaknesses, the threats and risks involved, and the actions taken to solve these problems.  RQ2. How to relate OSS adoption strategies to the characteristics of the OSS adopter organizations? o RQ2.1 How to characterize and describe OSS adoption strategies? o RQ2.2 How to characterize and describe OSS adopter organizations? o RQ2.3 How to organize and represent relevant OSS adopter information (e.g., organizational goals, tactics) to understand the impact and risks of OSS strategies over the adopter organizations? OSS adoption involves several aspects. However, as mentioned above, there is a lack of approaches that help to reconcile them. Thus, RQ2.1 is focused on how to characterize and describe current OSS adoption strategies. A set of strategies were already presented in [18]. I will base my initial work on these strategies but I will need to confirm the status of these strategies or to suggest others in case I find evidence of their usage in the industrial practice (i.e., the result from RQ1). The characterization of organizations that adopt OSS is approached by RQ2.2. RQ2.3 set the foundations for the integration of these two characterizations.  RQ3. How to analyze the impact of the OSS adoption strategies in the OSS adopter organizations? o RQ3.1 How to analyze the impact of the identified risks into the OSS adopter organizations? o RQ3.2 How to get and analyze the cost-benefit and cost-effectiveness of OSS adoption strategies in the context of OSS adopter organizations? o RQ3.3 How to identify patterns of OSS adoption strategies’ impact on OSS adopters? One of the main relevant aspects that hamper the adoption of OSS is the lack of support to analyze the impact of the OSS adoption [19]. Therefore, an important part of this research work focuses on envisaging a way to support organizations to analyze the impact of the risks of OSS adoption (RQ3.1) as well as cost-benefit and cost-effectiveness that help organizations to take informed decisions regarding the adoption of OSS (RQ3.2). I believe that studying such impact I could try to identify some potential patterns that help organizations to predict potential OSS adoption impacts (RQ3).  RQ4. How to integrate the results from RQ2 and RQ3 into a usable framework that support software related organizations to adopt OSS? This is oriented to envisage a framework that comprehensively encloses successful approaches got in the context of the previous RQs aimed to serve as a useful guide for organizations that need to adopt OSS.  RQ5. Is it possible to validate the resulting framework? In order to evaluate the usefulness of the intended framework from RQ4. I need to gather data to understand positive and negative aspects of the resulting framework. This RQ refers to the design and execution of empirical machinery aimed to gather data related to the usefulness of the resulting framework. 4 Target Audience The target audience of this work are software related organizations that develop software, and/or offer services relate to software. This research work is aimed to support adopter organizations to assess the impact of OSS components adoption on their software development processes from a business perspective. In addition, as I will use diverse approaches from diverse areas to investigate, conceptualize, analyze and improve OSS components adoption (e.g., empirical software engineering, organizational modelling, and graph theory), I think that researchers might also benefit from the expected evidence of my research work. 5 Research Method This research will be conducted under principles and methods from the Empirical Software Engineering arena [20]. This is given by the fact that a usual problem of the Software Engineering discipline comes from the lack of empirical evidence to support research hypotheses and the subsequent evaluation of the proposed solutions [20], [21], which greatly hamper the proposals’ industrial uptake. The research approach will stand on two phases: Formative and Summative, as show in the Fig. No. 1. The activities related to RQ1-RQ4 are called formative activities as they are aimed to form and shape the expected framework, while the activities related to RQ5 are called summative tasks as their goal is mainly to assess the applicability of the resulting framework in a real setting. This research work is developed according to the Design Science Methodology approach proposed by [22], in order to solve the knowledge problems (the lack of knowledge about the world), and the world problems (the difference between as-is and to-be). The empirical cycle and engineering cycle are needed to solve these two problem types. The Design Cycle has three steps: Step 1 - Problem investigation, Step 2 - Treatment design, and Step 3 - Treatment validation. The Design Cycle is part of a larger cycle: the Engineering Cycle which are a rational problem-solving process. The execution sequence is the followed in Systems Engineering: begins with several iterations through the Design Cycle, in order to describe, specify and validated conceptually the problem and its possible treatments; later, one or more iterations of the Engineering Cycle are made; each iteration works with the previous knowledge about the problem and the treatment; the evaluation in the Engineering Cycle is done after the implementation. The Fig. No. 1 shows the research methodology: Steps 1 to 3 (Stages 1 to 4) integrate the Formative Phase (which will serve as the origin and evolution of the ideas and concepts that will articulate the intended framework), and the step 4 (Stage 5) integrates the Summative Phase (which will be used to evaluate the whole framework). The partial results obtained for Stage 1 to Stage 3 will be validated as part of its corresponding stages, and the final validation will be performed with the entire framework. I will Fig. No. 1 Research Methodology perform case studies as instruments to shape the solution obtained through the engineering cycle. 6 Current Status 6.1 RQ1: What is the current state of the art and practice of software related organizations that adopt OSS? A Systematic Literature Review (SLR) is being developed to update the previous work [6]. This study includes periodic actualizations (one per year), in order to obtain a comprehensive overview of the current state of the art and practice of the adoption of OSS in organizations. The Fig. No. 2 shows the SLR stages. An identification of risks and challenges of OSS adoption is performed, to complete the OSS adoption strategy models from [18]. From the papers in SLR last stage, the risks and challenges of OSS adoption are being identified. 6.2 Q2: How to relate OSS adoption strategies to the characteristics of the OSS adopter organizations? According to the context of literature of SLR last stage, the strategies from [18] have been confirmed, and two additional variations has been identified. Fig. No. 2 SLR Stages I identified the factors and their corresponding models for characterizing OSS adopter organizations and their ecosystem in terms of goals and stakeholders. This characterization was described in [23]. With the objective to build a bridge between OSS adoption strategies and OSS adopter organizations, I defined a mapping area, with three components: goals, processes and risks. The first mapping sub-area corresponding to goals was already defined and applied in the context of Ericsson Telecomunicazioni, Italy (TEI). It was first reported and published as part of [24] and a revised version of the approach was published in [23]. 6.3 RQ3: How to relate OSS adoption strategies to the characteristics of the OSS adopter organizations? I worked with the mapping sub-area corresponding to goals, and organize them into 3 catalogues: ‘Generic Business Goals’, ‘Generic OSS Goals’, and ‘Specific OSS Adoption Strategy Goals’. To manage appropriately the numerous and complex meaningful relationships among these goals, I applied the business model classification [12], which proposes six business model types to show the ‘evolution’ of an adopter organization that works with Open Innovation as part of this business model. Each business model type, hence called ‘stage’, has a specific set of characteristics that define the organization over time. Based on this business model descriptions, I proceeded to classify each goal of three catalogs, assigning one of this 6 types. From an incremental point of view, an OSS adopter organization can ascend from one level to another if its capacities are sufficiently developed. Even more, the adopter can start operations with a business model directly catalogued as any of upper levels. I defined an initial set of metrics for the assessment of the impact of the goals, corresponding to the goal mapping area defined in T2.3. These initial metrics and the idea behind them [23] are derived from the concept of degree centrality [25]. 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. Two metrics has been defined: Goal Impact Factor (GIF) to quantify the importance of a specific goal, based on the number and level of goals to which it influences, and Goal Grouping Factor (GGF) to quantify the importance of a specific goal based on the number and level of goals that support it. 7 Contributions and uniqueness The contributions and uniqueness of this research work are mainly related to:  Support to analyze and evaluate the impact of adopting OSS components, through a framework that can be applied regardless the nature or activity of the adopter organization.  Provision of a way to characterize and analyze OSS adopters and OSS component adoption strategies; it allows to organize and represent relevant information (e.g., organizational stakeholders requirements, goals, processes, risks, business models) for understanding the impact and risks in the context of the adopter.  Support for the creation of a mapping area, where the relationships between business and OSS component adoption strategies are established at different levels (i.e., goals, processes and risks).  Decision making support for selecting the OSS component adoption strategy that better fits to the adopter purposes. References 1. Driver, M., Hype Cycle for Open-Source Software, Technical Report. (2013) 2. BlackDuck, The 2015 Future of Open Source Survey. www.blackducksoftware.com/future- of-open-source, last visited in Jan-2016. 3. Goldman, R., Gabriel, R. P.: Innovation happens elsewhere - Open source as business strategy. Morgan Kaufmann. (2005) 4. Gary, K., Enquobahrie, A., Ibanez, L., Cheng, P., Yaniv, Z., Cleary, K., Kokoori, S., Muffih, B., Heidenreich, J. Agile Methods for Open Source Safety-Critical Software. In Software: Practice and Experience. Year 2011 Vol 41 Issue 9. pp. 945-962. (2011) 5. Blechar, M. Grid: The ROI on COTS. Journal of the Global Grid Community. Vol. 1, No.12. (2002) 6. 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) 7. Ven, K., Verelst, J. And Mannaert, H. Should You Adopt Open Source Software? IEEE Software, 25 (3), 54–59. (2008) 8. Ayewah, N., Hovemeyer, D., Morgenthaler,J. D., Penix, J., Pugh, W. Using Static Analysis to Find Bugs. IEEE Software 25(5), 22-29. (2008) 9. Wesselius, J. H. The Bazaar inside the Cathedral: Business Models for Internal Markets. IEEE Software 25(3), 60-66. (2008). 10. Stol, K., Fitzgerald, B. Inner Source- Adopting Open Source Development Practices in Organizations: A Tutorial. IEEE Software 32(4), 60-67. (2015) 11. Ayala, C., Hauge, Ø., Conradi, R., Franch, X., Li, J. Selection of third party software in Off- The-Shelf-based software development - An interview study with industrial practitioners. Journal of Systems and Software 84(4), 620-637. (2011) 12. Chesbrough, H. W.: Open Business Models – How to thrive in the new innovation landscape. Harvard Business School Press. (2006) 13. Osterwalder, A.: The Business Model Ontology - A proposition in a design science approach. Université de Lausanne. Ecole des Hautes Etudes Commerciales. (2004) 14. Ayala, C., Franch, F., López, L., Morandini, M., Susi, A. Using i* to Represent OSS Ecosystems for Risk Assessment. iStar 2013, 73-78. (2013) 15. Glott, R., Haaland, K., Bannier, S., Franch, X., López, L., Ayala, C., Costal, D., Sussi, A., Morandini, M., D3.2 Final Business Model Risk Requirements Report. RISCOSS Project. (2013). 16. Morgan, L., Finnegan, P. Beyond free software: An exploration of the business value of strategic open source. Journal of Strategic Information Systems. Elsevier. (2014). 17. 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). 18. 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) 19. Chou, S., He, M. The factors that affect the performance of open source software development - the perspective of social capital and expertise integration. In Information Systems Journal. 21, 2. pp. 195-219. (2011). 20. Kitchenham, B., Dybå, T., Jørgensen, M. Evidence-Based Software Engineering. ICSE 2004: 273-281. (2004) 21. Basili, V., Elbaum, S. Empirically Driven SE Research: State of the Art and Required Maturity, Invited Talk, ICSE 2006, Shanghai. (2006). 22. Wieringa, R. Design Science Methodology for Information Systems and Software Engineering. Springer. (2014). 23. Méndez, L., López L., Ayala C., Annosi, M. Towards an OSS Adoption Business Impact Assessment. In Lecture Notes in Business Information Processing, Vol 235. pp 289-305 (2015). 24. Costal, D., López, L., Morandini, M., Siena, A., Annosi, M., Gross, D., Méndez, L., Franch, X., Susi, A. Aligning Business Goals and Risks in OSS Adoption. 34th International Conference on Conceptual Modeling (ER 2015). (2015). 25. Newman, M. E. J. Networks – An introduction. University of Michigan and Santa Fe Institute. Oxford University Press. (2010).