Inner Source – to Excel on Developer Initiatives Master’s thesis in Master Programme Software Engineering QI WANG Department of Computer Science and Engineering CHALMERS UNIVERSITY OF TECHNOLOGY AND UNIVERSITY OF GOTHENBURG Gothenburg, Sweden 2016 Master’s thesis 2016:10 Inner Source – to Excel on Developer Initiatives QI WANG Department of Computer Science and Engineering Chalmers University of Technology and University of Gothenburg Gothenburg, Sweden 2016 Inner Source – to Excel on Developer Initiatives © QI WANG, 2016. Supervisor: Regina Hebig, Department of Computer Science and Engineering Dan Berg, PDU Packet Core of Ericsson Examiner: Eric Knauss, Department of Computer Science and Engineering Master’s Thesis 2016:10 Department of Computer Science and Engineering Chalmers University of Technology and University of Gothenburg SE-412 96 Gothenburg Telephone +46 31 772 1000 Cover: Inner Source, Open source for the enterprise (https://cloudramblings.me/2013/11/08/inner-source-open-source-for-the-enterprise/) Gothenburg, Sweden 2016 iv Abstract This thesis improves and studies the Inner Source Development environment in Eric- sson. Inner Source Development focuses on cooperation among developer, manager and customer, and collaboration among developers. This thesis starts with 7 semi- structured interviews with developers and managers from different teams in Ericsson. The aim of semi-structured interviews is to know the requirements of stakeholders and their opinions on existing tools used in Ericsson and on the market. The thesis presents a comparison among 5 different tools: Eforge, OpenALM, Gerrit, Gitlab and Github Enterprise from 4 aspects: searching, sharing, collaboration and other quality issues. With the interview result and the comparison, the original plan to improve the Inner Source Development environment was to import Github Enter- prise or Gitlab EE. However, with some obstructions of funds and pilot plan, this plan was rejected and turned into improving the existing tool: Gerrit. Gerrit is im- proved on 2 aspects: searching function and complete information of project. Three new function were developed and deliveried to Gerrit Open Source community. The largest challenges in this thesis are understanding of large amounts of code, different ways controlling of modified system, communication problems because of jet lag and lack of time to test. The study provides a table of comparison among 5 tools. Keywords: Inner Source Development, Requirement Specification, Open Source De- velopment v Acknowledgements This thesis work was cooperated with Ericsson and Chalmers University of Technol- ogy and University of Gothenburg. The author would like to thank the supervisors: Dr. Regina Hebig, Mentor Dan Berg and the examiner: Dr. Eric Knauss for his valuable feedback and guidance. The author would like to express her thanks to the technical guiders: SW Configuration Manager Stellan Bondesson in Ericsson in Gothenburg, Gerrit Developer Hugo Ares in Ericsson in Montreal, the explaination and support from Github: Hakan Axtelius, Bas Peters and Sten and Sven Stolk, and environment configuration support: Magnus Mörtberg and his colleague (Vlad). The author also would like to thank all the interview partners and participants in- volved in discussions. Qi Wang, Gothenburg, October 2016 vii Contents List of Figures xi List of Tables xiii 1 Introduction1 1.1 Problem..................................1 1.2 Purpose..................................2 1.3 Research Questions............................2 1.4 Research Approach............................3 1.5 Thesis summary.............................3 2 Background5 2.1 Inner Source Development........................5 2.1.1 Stakeholders............................6 2.1.2 Benefits..............................8 2.2 Relative Work............................... 10 2.2.1 Challenges of adopting Inner Source and Open Source..... 10 2.2.2 Factor to adopt Inner Source................... 13 2.2.3 Common features of Inner Source Development........ 15 3 Iteration 1: Requirement Research 17 3.1 Methodology............................... 17 3.1.1 Semi-structured interview.................... 17 3.1.2 Comparison among existing platforms.............. 18 3.2 Data Analysis............................... 19 3.3 Result................................... 20 3.3.1 Semi-structured interviews.................... 20 3.3.2 Literature Background...................... 21 3.3.3 Requirement............................ 22 3.3.4 Comparison............................ 25 3.4 Discussion................................. 29 3.5 Evaluation................................. 30 4 Iteration 2: Implementation 31 4.1 Methodology............................... 31 4.1.1 Group discussion......................... 31 4.1.2 Use Cases............................. 32 ix Contents 4.1.3 Code analysis........................... 32 4.1.4 Validation............................. 32 4.1.5 Evaluation............................. 33 4.2 Result................................... 33 4.2.1 Group discussion......................... 33 4.2.2 Use cases............................. 34 4.2.3 Validation............................. 40 4.2.4 Development........................... 41 4.2.4.1 Feature 1 - Use Case 1................. 41 4.2.4.2 Feature2 - Use Case 2-3................ 44 4.3 Evaluation................................. 47 5 Discussion 49 5.1 Discussion for Research Question.................... 49 5.1.1 RQ 1-How does inner source development support team work? 49 5.1.2 RQ1.1-What are the needs of stakeholders on inner source development?........................... 49 5.1.3 RQ2-How to improve the inner source development environ- ment?............................... 50 5.2 Validity.................................. 50 5.3 Challenges................................. 51 6 Conclusion 53 6.1 Limitation................................. 54 6.2 Future work................................ 54 Bibliography 55 A AppendixI A.1 Get Config.................................I A.1.1 Request..............................I A.1.2 Response.............................I A.2 Set Config................................. III A.2.1 Request.............................. III A.2.2 Response............................. III x List of Figures 2.1 Comparison of integration scenarios (Taken from [6]).........6 2.2 The onion model representing the community structure of a typical ISS project (taken from [28])......................7 3.1 Experiment with Tiered Levels Of Developer Involvement (Taken from [46])................................. 22 4.1 Help button prototype........................... 35 4.2 Project search bar prototype....................... 36 4.3 New project creation button........................ 37 4.4 Project creation page prototype...................... 37 4.5 Project page (homepage blank prototype)................ 38 4.6 An example for homepage......................... 39 4.7 Filters of project searching prototype (The second category of lan- guage dropdown list is taken from Github.com)............ 40 4.8 Original Search Bar............................ 41 4.9 Initial design of search operators..................... 42 4.10 Keyboard Shortcuts help popup panel.................. 42 4.11 Operator Help Button with search bar.................. 43 4.12 Operator popup panel........................... 44 4.13 An example of the operator description................. 44 4.14 Original project main page........................ 45 4.15 Design of project homepage blank.................... 46 4.16 Operator list and description (old demo)................ 47 xi List of Figures xii List of Tables 2.1 Challenges in integrating OSS in product development (Taken from [38])..................................... 11 2.2 Overview of relevance of challenges to OSS, infrastructure-based Inner Source and project-based Inner Source (Taken from [38])....... 13 3.1 Overall list of all the requirement.................... 23 3.2 Comparison among different platforms................. 28 xiii List of Tables xiv 1 Introduction Inner Source development is defined as applying Open Source development within a closed organization [2]. Inner Source concepts are similar to open source, except Inner Source is bounded by an organization or a company. Inner Source platforms are tools embodying Inner Source concepts to help users be involved in projects, share projects, submit contributions, search, and join other projects. Open Source Software development is now very common and has achieved great suc- cess in both industry and academia. Several outstanding hackers (including Bruce Perens and Eric Raymonf), initiated the Open Source concept in 1998 [1]. Open Source software refers to software projects where the source code was publicly pub- lished and available to be reviewed, contributed, and even used by other developers. Huge amounts of open source projects were published on different platforms, and the amount is still growing. In 2016, Nithya boldly stated that all companies were using open source or would use open source in the future [3]. Stakeholders took many benefits from Open Source development. However, organizations and companies are continuously looking for more solutions to manage projects. Open Source development is internet-wide for users, i.e., anyone who has access to the Internet is free to open source projects. This has various risks for organiza- tions and companies who build their products in Open Source. There is no secrets in Open Source world, for some profit organizations, Open Source may