Nikolay Harutyunyan

Andreas Bauer
email: andi.bauer@fau.de

Dirk Riehle

Understanding Industry Requirements for FLOSS Governance Tools

Keywords: Open Source Software, FLOSS, FOSS, Open Source Governance, FLOSS governance tools, company requirements for FLOSS tools

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Commercial use of FLOSS is on the rise as more companies realize the benefits of using FLOSS components in their products, going beyond the commonplace use of FLOSS development tools [START_REF] Deshpande | The total growth of open source[END_REF][START_REF] Fitzgerald | The transformation of open source software[END_REF][START_REF] Krogh | The promise of research on open source software[END_REF][START_REF] Riehle | The economic motivation of open source software: Stakeholder perspectives[END_REF][START_REF] Riehle | The commercial open source business model[END_REF]. In 2017 a report by the European Commission estimated that using FLOSS saves the European economy an estimated EUR 114 billion per year directly and up to EUR 399 billion per year overall [START_REF]European Commission: The economic and social impact of software & services on competitiveness and innovation (SMART 2015/0015)[END_REF]. However, companies also need to govern and regulate their use of FLOSS components to avoid common threats, such as FLOSS license non-compliance, copyright and patent infringement, that can result in litigation, cease and desist claims or product recalls [START_REF] Black | Open Source Security and risk analysis[END_REF][START_REF] Radcliffe | The 2017 Open Source Year in Review[END_REF][START_REF] Riehle | Erfolgsmethoden der Open-Source-Governance und-Compliance[END_REF][START_REF] Ruffin | Using open source software in product development: A primer[END_REF]. In the context of this paper, we define FLOSS governance as the set of processes, best practices and tools employed by companies to use FLOSS components as part of their commercial products while minimizing their risks and maximizing their benefit from such use. FLOSS governance processes and tools can apply to the commercial use, contribution or leadership of FLOSS projects. We limited the scope of this paper only to the commercial use of FLOSS components, intentionally excluding governance considerations of FLOSS contribution or leadership by companies. This is in line with our earlier definition of FLOSS governance. Such focus allowed us to generate an in-depth theory covering the earliest maturity phase of industry involvement with open source that is of highest practical relevance to most companies today and novel to the growing open source research [START_REF] Hauge | Adoption of open source software in software-intensive organizations-A systematic literature review[END_REF].

Despite the practical relevance of the issue, research has been slow to address the use of FLOSS in products. The existing literature is limited to general FLOSS governance research [START_REF] Aksulu | A comprehensive review and synthesis of open source research[END_REF][START_REF] Bonaccorsi | Why open source software can succeed[END_REF][START_REF] Cruz | Evaluation criteria for free/open source software products based on project analysis[END_REF], to research of the governance of open source communities and their development practices [START_REF] De Laat | Governance of open source software: state of the art[END_REF][START_REF] Lattemann | Framework for governance in open source communities[END_REF][START_REF] Riehle | Controlling and steering open source projects[END_REF][START_REF] Sadowski | Transition of governance in a mature open software source community: Evidence from the Debian case[END_REF], and to FLOSS license compliance related governance [START_REF] Emde | Open Source License Obligations Checklists (version 5)[END_REF][START_REF] Gangadharan | License Compliance Issues in Free and Open Source Software[END_REF][START_REF] Gangadharan | Managing license compliance in free and open source software development[END_REF][START_REF] German | License integration patterns: Addressing license mismatches in component-based development[END_REF][START_REF] German | Understanding and auditing the licensing of open source software distributions[END_REF][START_REF] German | A sentence-matching method for automatic license identification of source code files[END_REF][START_REF] Di Penta | Identifying licensing of jar archives using a code-search approach[END_REF][START_REF]Software Package Data Exchange (SPDX)[END_REF][START_REF] Wang | Open source software adoption: A status report[END_REF]. However, past research has not comprehensively addressed FLOSS governance requirements and best practices in industry. A particularly practical aspect of FLOSS governance is its automation through tooling, which ensures increased efficiency and better integration into the development process. Focusing on the specific aspect of FLOSS governance tooling, we addressed this gap by asking the following research question:

RQ: What are the core industry requirements for FLOSS governance tools needed to facilitate the use of FLOSS components in commercial products?

The research method employed is an adaptation of the grounded theory method [START_REF] Charmaz | Constructing grounded theory[END_REF][START_REF] Corbin | Basics of qualitative research: In: Techniques and procedures for developing grounded theory[END_REF] called the QDAcity-RE method for structural domain modeling using qualitative data analysis [START_REF] Kaufmann | The QDAcity-RE method for structural domain modeling using qualitative data analysis[END_REF]. We chose this novel, yet promising research method because it enables using qualitative data analysis (QDA) to develop a theory that can be specifically cast as a requirements specification. Answering our research question, we aimed to cast our theory as a list of common industry requirements for FLOSS governance tools. This format is well-understood in the industry and can, therefore, ensure a high practical value of our research results. Data gathering and analysis were performed using formal semi-structured interviews, researcher notes, and materials review. We interviewed 15 FLOSS governance and compliance experts from 10 diverse companies chosen through theoretical sampling of more than 140 companies.

There are few reports on commercial adoption of FLOSS that are cast as lists of requirements focusing on technical and managerial aspects of using FLOSS in proprietary products [START_REF] Wang | Open source software adoption: A status report[END_REF]. However, neither academic nor practitioner literature offers a detailed list of industry requirements for FLOSS governance or its tooling that goes beyond a high-level of abstraction [START_REF]OpenChain Specification[END_REF]. In this paper, we addressed this research gap with our main contribution the theory of industry requirements for FLOSS governance tools. Our theory indicated four key categories of FLOSS governance tool requirements in no particular order:

• Tracking and Reuse of FLOSS components • License Compliance of FLOSS components • Search and Selection of FLOSS components • Other requirements (security, education, etc.)

We then broke down each of these categories into detailed requirements and sub-requirements.

To evaluate our theory, we analyzed marketing materials and demos of 6 widely used and representative FLOSS governance tools. We compared the key tool features with our suggested theory and evaluated our proposed requirements confirming many of them. In future publications, we also plan to address other aspects of FLOSS governance in high detail, including industry best practices for FLOSS supply chain management and license compliance.

Related Work

The early research on FLOSS governance in companies was part of the broader research on the commercial use of FLOSS development tools and components [START_REF] Aksulu | A comprehensive review and synthesis of open source research[END_REF][START_REF] Hauge | Adoption of open source software in software-intensive organizations-A systematic literature review[END_REF]. In a systematic literature review on FLOSS adoption in industry, Hauge et al. identified only a limited amount of research focusing on FLOSS component selection by companies [START_REF] Cruz | Evaluation criteria for free/open source software products based on project analysis[END_REF][START_REF] Deprez | Comparing assessment methodologies for free/open source software: OpenBRR and QSOS[END_REF][START_REF] Hummel | Code conjurer: Pulling reusable software out of thin air[END_REF][START_REF] Umarji | Archetypal internet-scale source code searching[END_REF] and knowledge sharing within FLOSS communities [START_REF] Krogh | The promise of research on open source software[END_REF][START_REF] Lakhani | How open source software works:"free" user-to-user assistance[END_REF][START_REF] Sowe | Understanding knowledge sharing activities in free/open source software projects: An empirical study[END_REF]. Hauge et al. [START_REF] Hauge | Adoption of open source software in software-intensive organizations-A systematic literature review[END_REF] did not identify any academic studies focused on the actual industry practice of using FLOSS components in products, thus suggesting that further research is needed on this topic. Our literature review confirmed this research gap prompting us to conduct this study of 10 industry-representative companies.

We set our research scope and that of the related work review to the commercial use of FLOSS components in products and industry requirements for FLOSS governance tooling. We explicitly excluded FLOSS governance related to industry contribution to or leadership of FLOSS projects. We did not identify literature explicitly focused on FLOSS governance tool requirements. However, we found indirect references to the topic that we used as a starting point for our research. We derived three key categories of FLOSS governance requirements that can be addressed through tooling:

• Tracking and Reuse of FLOSS components [START_REF] Helmreich | Best practices of adopting open source software in closed source software products[END_REF][START_REF] Popp | Best Practices for Commercial Use of Open Source Software[END_REF][START_REF]Tools for Managing Open Source Programs[END_REF] • License Compliance of FLOSS components [START_REF] Emde | Open Source License Obligations Checklists (version 5)[END_REF][START_REF] Gangadharan | License Compliance Issues in Free and Open Source Software[END_REF][START_REF] Gangadharan | Managing license compliance in free and open source software development[END_REF][START_REF] German | License integration patterns: Addressing license mismatches in component-based development[END_REF][START_REF] German | Understanding and auditing the licensing of open source software distributions[END_REF][START_REF] German | A sentence-matching method for automatic license identification of source code files[END_REF][START_REF] Di Penta | Identifying licensing of jar archives using a code-search approach[END_REF][START_REF]Software Package Data Exchange (SPDX)[END_REF][START_REF] Wang | Open source software adoption: A status report[END_REF] • Search and Selection of FLOSS components [START_REF] Cruz | Evaluation criteria for free/open source software products based on project analysis[END_REF][START_REF] Deprez | Comparing assessment methodologies for free/open source software: OpenBRR and QSOS[END_REF][START_REF] Hummel | Code conjurer: Pulling reusable software out of thin air[END_REF][START_REF] Semeteys | Method for qualification and selection of open source software[END_REF][START_REF] Umarji | Archetypal internet-scale source code searching[END_REF] Tracking and Reuse. With the growing availability of high-quality FLOSS components, software developers increasingly use FLOSS components in commercial products. FLOSS governance policies in many companies require developers to track and document such FLOSS use [START_REF] Helmreich | Best practices of adopting open source software in closed source software products[END_REF][START_REF] Popp | Best Practices for Commercial Use of Open Source Software[END_REF]. This enables the well-structured management and reuse of FLOSS components that have been added into product software. Umarji et al. [START_REF] Umarji | Archetypal internet-scale source code searching[END_REF] suggest using FLOSS governance tools to create and maintain libraries of reusable FLOSS components. Our findings confirm this as one of the industry requirements for FLOSS governance tools.

Other requirements focus on supply chain management [START_REF]OpenChain Specification[END_REF], automated management of bill of materials [START_REF]Software Package Data Exchange (SPDX)[END_REF], maintenance of FLOSS component metadata in product architecture models [START_REF] Riehle | License in Software Product Governance[END_REF], etc. Our theory confirms and captures these requirements.

License Compliance. Wang and Wang present a number of requirements for industry adoption of FLOSS. Some of these requirements can be translated into industry requirements for FLOSS governance tools. The authors suggest a managerial requirement for license compliance that includes understanding different FLOSS licenses and documenting their terms [START_REF] Wang | Open source software adoption: A status report[END_REF]. Our theory suggests that industry requires the use of FLOSS governance tools for documenting company interpretation of most common and used FLOSS licenses and their implications. This requirement is also confirmed by industry associations, such as The Open Source Automation Development Lab eG, which in 2017 attempted to standardize FLOSS license obligations through checklists and own license describing language that can eventually be used in a FLOSS governance tool [START_REF] Emde | Open Source License Obligations Checklists (version 5)[END_REF].

Other industry requirements for compliance tools include automated FLOSS license scanning [START_REF] Gangadharan | Managing license compliance in free and open source software development[END_REF][START_REF] German | License integration patterns: Addressing license mismatches in component-based development[END_REF], automated FLOSS code detection in company's codebase and in its supply chain using source code and binary scans [START_REF] German | Understanding and auditing the licensing of open source software distributions[END_REF][START_REF] Di Penta | Identifying licensing of jar archives using a code-search approach[END_REF][START_REF]Software Package Data Exchange (SPDX)[END_REF], checking FLOSS license compatibility when mixing licenses [START_REF] German | A sentence-matching method for automatic license identification of source code files[END_REF] etc. We confirm all these requirements through expert interviews and formalize them in our theory, while recognizing the technological complexity of fulfilling these requirements by the currently existing tooling.

Search and Selection. Umarji et al. [START_REF] Umarji | Archetypal internet-scale source code searching[END_REF] surveyed a sample of 69 programmers. Their research suggested that software developers require and use tools for the search and selection of FLOSS components. The majority of the survey respondents said they used general-purpose search engines with some also using project hosting sites and code-specific search engines. Our expert interviews confirmed the requirement for search and selection of FLOSS components. A requirement in our proposed theory formalizes this industry need.

Other industry requirements for search and selection of FLOSS components focus on the automated identification of software families and types of FLOSS communities [START_REF] Semeteys | Method for qualification and selection of open source software[END_REF]. Our theory did not confirm the industry requirement for the tool-assisted software family identification, but did confirm the need for the tool-assisted identification and evaluation of FLOSS communities.

Many other requirements are suggested in both academic literature and practitioner white papers. However, in this section, we combined and presented the literature related to only several key requirements due to our narrow scope.

Research Method

We conducted a two-step study that consists of:

1. Deriving a theory based on our understanding of key industry requirements for FLOSS governance tools through expert interviews 2. Evaluating our understanding of industry requirements through marketing materials and demos of existing FLOSS governance tools Our research approach is represented in Figure 1 and explained below.

For theory building, we conducted 15 interviews with ten industry-leading companies to understand their requirements for FLOSS governance tools.

We employed an adaptation of the grounded theory [START_REF] Charmaz | Constructing grounded theory[END_REF][START_REF] Corbin | Basics of qualitative research: In: Techniques and procedures for developing grounded theory[END_REF] method called the QDAcity-RE method for structural domain modeling using qualitative data analysis [START_REF] Kaufmann | The QDAcity-RE method for structural domain modeling using qualitative data analysis[END_REF]. Corbin & Strauss [6] or Charmaz [START_REF] Charmaz | Constructing grounded theory[END_REF] define the grounded theory method as one that consists of systematic, yet flexible guidelines for collecting and analyzing qualitative data to construct a theory from that data. Kaufmann & Riehle [START_REF] Kaufmann | The QDAcity-RE method for structural domain modeling using qualitative data analysis[END_REF] accept this definition, but extend the method to a more structured, traceable and iterative one providing guidelines for data collection, creation and application of a code system. This enabled us to use the QDAcity-RE method for requirements engineering based on our industry expert interviews. The result is a partial theory of industry requirements for FLOSS governance tools cast as a requirements specification.

For theory evaluation, we reviewed marketing materials and demos of 6 widely used FLOSS governance tools. We used the QDAcity-RE method and qualitative data analysis to derive the common features they offer to meet industry needs for automating FLOSS governance.

Assuming that the tool vendors as a whole understand industry needs and offer tools that address these needs, we compared the common tool features to our partial theory of industry requirements. We evaluated which tool features match the industry requirements in our proposed theory and which ones do not. We used this evaluation to demonstrate that our theory represents the current state of industry requirements for FLOSS governance tools. To the extent that our theory agrees with tool features, we put the work of industry product managers onto a sound scientific base of theory development based on the user's perspective.

Theoretical Sampling

For theory building, we chose ten companies sampled from our industry network of about 140 companies with advanced FLOSS governance practices. The companies in our sample have advanced understanding of FLOSS governance and use internal and/or external governance tools. We conducted polar theoretical sampling to cover a diverse and representative set of companies. Polar sampling aims to choose companies with highly varying characteristics. We considered diverse dimensions including types of business models, customer types, company size, market position and company maturity. The resulting sample of companies includes small, medium and large companies with both enterprise and retail customers and varying business models. The list of companies and their essential characteristics are presented in Table 1. Company names are anonymized per their request. For theory evaluation, we chose 6 widely used and prominent FLOSS governance tools that represent the broader spectrum of FLOSS governance tools [START_REF]Tools for Managing Open Source Programs[END_REF]. Not all tools compete but have some overlap in their functionalities, like support for license scanning or component repository management. To reduce bias, we made sure that our selection differs in these dimensions:

• By the license under which a vendor makes its tool available. The sampling contains tools that are licensed under permissive and copyleft type open source licenses, and proprietary closed source licenses.

• By the delivery model of a tool. A critical factor for companies is the ability to choose whether a software tool is available as cloud-based service or can be used on-premise, depending on aspects like costs, customization, and security. • By the scannable artifacts. For scanning of license information, tools can analyze source code or binary artifacts. Scanning of binary artifacts is necessary if the source code of dependent components is not available. In contrast scanning of source code artifacts provide better results.

We also consider other dimensions for the theoretical sampling (maturity of a tool, automation and integration into the development process, and additional audit service by experts), but to offer more depth we focus on the three key dimensions presented above. The list of tools and their key characteristics are presented in Table 2.

Data Gathering and Analysis

For data gathering, we mainly used semi-structured interviews conducted by one or two researchers with FLOSS governance experts or responsible coworkers from the sampled companies. In seven companies we interviewed one expert, in one company we interviewed two experts, and in two companies we interviewed three experts. In total, we conducted 15 interviews. When possible, we recorded and transcribed the interviews. In three cases we took notes. We also studied additional materials both public and private about these companies and their FLOSS governance practices. We developed key questions and an interview guideline for the semi-structured interviews and kept them stable, except for few iterative adjustments from company to company, throughout the whole data gathering process. The interviews were exploratory in line with our grounded-theory-based research method.

For data analysis, we followed the QDAcity-RE method performing iterative and incremental qualitative data analysis (QDA) supported by the MaxQDA software. We developed two separate coding systems for the theory building using expert interviews and for the theory evaluation using tool marketing materials and demos.

During the QDA coding process, we iteratively refined the code system. Reaching theoretical saturation [START_REF] Kaufmann | The QDAcity-RE method for structural domain modeling using qualitative data analysis[END_REF], the code system became the basis for our theory. Individual codes correspond to low-level tool requirements in our requirements specification. Both for theory building and evaluation, our code systems consist of hierarchical codes. We did not apply the top category codes in our QDA. We followed the QDAcity-RE method's QDA process as follows:

• Open coding. We created a basic set of codes from which the hierarchy is built. Open codes are direct annotations of primary materials and link to them for data-theory traceability. • Axial coding. We built a code system by deriving more abstract concepts and categories from open codes, thus developing the axes of the code system. • Selective coding. We applied the codes to the gathered data and chose which codes are important and which are not. We adjusted the coding system by removing the irrelevant codes and by adding the ones that emerged when applying the axial codes.

Research Results

This section presents our partial theory of industry requirements for FLOSS governance tools, followed by the evaluation of the suggested theory through feature analysis of existing FLOSS governance tools. Section 4.1 presents our theory cast as a requirements specification for high practical relevance. Section 4.2 presents our evaluation of the theory.

Theory of Industry Requirements for FLOSS Governance Tools

We limited our scope to FLOSS governance tools related to the commercial use of FLOSS components, explicitly excluding companies' contribution to or leadership of FLOSS projects. We only present the requirements that have been directly derived or inferred from our data, thus excluding the ones that have been presented in the literature, but not confirmed by our industry study. The result is a partial theory that covers the key requirement categories and requirements based on our sample. Analyzing 15 expert interviews, researcher notes and company materials, we derived the following high-level industry requirements for FLOSS governance tools: Virtually all companies track their use of FLOSS components in order to efficiently manage FLOSS integration into their products, as well as to enable cost-saving reuse of FLOSS components already used by the company's other developers. Efficient FLOSS component management ensures a company's ability to maintain and produce upon customer request an up-to-date bill of materials. FLOSS license compliance is a central aspect and key tool requirement category to the companies we studied.

Companies strive to automate license compliance, license scanning and license management. Some companies employ continuous integration/deployment and thus require appropriate license compliance tools that can be integrated in their development process. Tool requirements for license compliance go on to encompass automated license interpretation, license identification and documentation, etc. An expert from Company 7 mentions the tool requirement for automating FLOSS license scanning and identification of other FLOSS component metadata (Requirement 2.2), as well as the requirement for automating component approval (Requirement 2.4):

"We have a full toolset that goes through and scans the code, that pulls out all the license information, the authorship [copyright] information, and runs that through our process for verification, for compliance, for compatibility and so forth." (Company 7)

Another expert talks about the need to find and document the unidentified FLOSS components and licenses (Requirement 2.

3): "We need this [license scanning] tool to re-check if any of the developers are not handling [FLOSS components] in the way [the management] wants, to better do it because we have no possibility to check it in a clear way if you have no tool." (Company 3)

Search and Selection of FLOSS components

3.1. The tool should help users search for FLOSS components.

3.2.

The tool should help users select best FLOSS components.

The tool should help users estimate the cost of using an FLOSS component.

Companies need to FLOSS governance tools to efficiently search and select the right FLOSS components, which translates into tool requirements on evaluating different component candidates and estimating the cost of their usage. One interviewee talks about the role of tools in FLOSS component selection process (Requirement 3.2): "When you move on from a strategic decision to component selection like with components of open source projects to be used, then we have a process that we require the projects to name all the open source components to assess that they want to use, that they assess the license, that they check the license, and that they document that and that again this assessment is communicated to upper management and signed off that." (Company 2)

Other requirements

4.1. The tool should help users detect and prevent security vulnerabilities in product's FLOSS components.

The tool should help users document and communicate company's FLOSS governance strategy, policies and best practices. 4.3. The tool should help users get training on FLOSS governance and compliance when using open source software in products and contributing to open source projects.

The detailed subcategories of requirements for Tracking and Reuse of FLOSS components are demonstrated in Table 3. The detailed subcategories of requirements for License Compliance of FLOSS components are demonstrated in Table 4. The detailed subcategories of requirements for Search and Selection of FLOSS components are demonstrated in Table 5. e. The tool should allow automated finding of open source software that is part of the supplied proprietary software using commonly accepted data exchange standards (such as SPDX). f. The tool should allow automated finding of open source software that is part of the supplied proprietary software using binary or source code scanning.

2. The tool should help users report the use of FLOSS components in a product architecture model. a. The tool should allow creating a product architecture model to systematically record use of FLOSS components, their metadata and component dependencies. b. The tool should allow manual recording of metadata of the used FLOSS components. c. The tool should allow confirming the metadata of FLOSS components identified automatically. d. The tool should allow modifying the metadata of FLOSS components identified automatically. e. The tool should allow removing the metadata of FLOSS components identified automatically. f. The tool should allow automated reporting of a newly used FLOSS component within the build process and/or continuous integration process. g. The tool should allow reporting undeclared use of FLOSS components and their metadata.

Evaluation

This section presents the evaluation of our suggested theory using the feature analysis of existing FLOSS governance tools. We analyzed marketing materials and demos of six widely used FLOSS governance tools. The analysis resulted in the following list of common key features related to FLOSS use in products:

• Component Tracking & Reporting: support for bill of materials, component inventory, knowledge base (external inventory), license obligation reporting, and commonly accepted data exchange standard support; • Scanning / License Checking: support for licenses identification, copyright identification, code origin identification, and license management; • Policies: support for applying/ensuring FLOSS policies;

• Security: support for security vulnerability detection;

• Development Integration & Automation: support for integration into continuous integration and deployment.

To ensure the depth of evaluation, we focus on two main requirement categories: Tracking and Reuse of FLOSS components and License Compliance of FLOSS components. We chose these categories because these requirements are fundamental to any software company according to the analysis of the industry interviews and tools support of these requirements as base functionalities.

Tracking and Reuse of FLOSS components. The identification of FLOSS components and their licenses in a given software product or component is a core functionality of all sampled tools. All the high-level requirements of the category 1 in the proposed theory are matched by the features of the sampled tools. For example, Black Duck Software enables its users to identify the used FLOSS components (Requirement 1.1) in both the source code and in binaries (with lesser precision):

" [Black Duck However, none of our studied tools completely fulfill some of the following low-level requirements: Requirement 2.1.b (automated standard interpretation of common FLOSS licenses), Requirement 2.3.h (automated license checking within continuous integration), Requirement 2.5.b (automated assignment of FLOSS compliance tasks), Requirement 2.5.c (automated audit of product's bill of materials before distribution). One reason is the complex computational nature of the complete automation of compliance tasks. An empirical study by German et al. [START_REF] German | Understanding and auditing the licensing of open source software distributions[END_REF] showed that a deeper understanding of licensing issues requires human expertise, which limits the automation of some license compliance tasks. Moreover, most companies don't allow complete automation of compliance as they require a human actor to be responsible for legal matters, even if they use semi-automated tooling.

Our limited evaluation demonstrates that the high-level requirements of our theory do match the features offered by industry leading FLOSS governance tools. The evaluation shows that existing tools satisfy most of the low-level requirements by the industry, but not others, such as requirements of complete automation.

Discussion

Our main contribution is the requirements specification presented in Section 4.1 and its evaluation in Section 4.2.

We recognize that our research results are limited, but novel and practice relevant. They present only a partial theory on the issue. However, we lay groundwork for future studies into FLOSS governance tool requirements, that will hopefully expand our requirements specification theory. Our work leads us to propose the following research questions for future research:

RQ1: What are other detailed FLOSS governance tool requirements beyond Tracking and Reuse of FLOSS components, License Compliance of FLOSS components and Search and Selection of FLOSS components?

RQ2: How can FLOSS governance tool requirement theories be better evaluated or validated? RQ3: How to engineer FLOSS governance tool requirements of the future addressing missing features and industry needs before companies become aware of them?

6

Research Limitations

The study faces several limitations including those to internal validity and to external validity:

Internal validity. Qualitative data research realized by one researcher has inherent subjectivity and bias. Even though we followed the research method constructs carefully, there is bias associated with method interpretation and application to our specific context. To address this limitation, we had a second coder analyze our data and improved our original QDA coding with that of the second coder. The high inter-coder agreement between the original coding and the second coder coding suggests an adequate quality of our code system and by extension an adequate quality of the derived theory [START_REF] Lombard | Content analysis in mass communication: Assessment and reporting of intercoder reliability[END_REF].

External validity. The resulting theory is based on the data gathered from the experts of the ten companies we interviewed. We cannot claim broad generalizability of the findings, even though we followed a careful theoretical sampling to ensure the applicability of our results. This limitation can be tested with further validation studies.

Conclusion

This paper presents a study of ten industry companies with advanced FLOSS governance practices. Our study concluded in a partial theory of FLOSS governance tool requirements by the industry. Also, we provide a detailed hierarchical list of these industry relevant requirements. As such it offers unique insight into industry understanding of FLOSS governance tools and their expectations from them, alongside existing tools and their features.

The data gathered through semi-structured interviews and materials collection was analyzed using the novel adoption of grounded theory methodthe QDAcity-RE method. We cast our theory as a requirements specification making it applicable and practice relevant to the companies willing to employ these requirements. Finally, we evaluated our findings using six industry leading FLOSS governance tools and the analysis of their features matched with the requirements of the suggested theory.

The study of the missing features of existing tools is out of scope of this paper but it can be a valuable part of further research. Further research can also focus on the reasons why tool providers do not fulfill the unsatisfied requirements of our theory (e.g. full automation of compliance) and how such problems can be solved.

Fig. 1 .

 1 Fig. 1. Theory Building using Industry Requirements and Theory Evaluation using Tool Features

1 .

 1 Tracking and Reuse of FLOSS components 1.1. The tool should help users identify the use of FLOSS components in their code base. 1.2. The tool should help users report the use of FLOSS components in a product architecture model. 1.3. The tool should help users update FLOSS components and their metadata. 1.4. The tool should help users maintain a bill of materials of the FLOSS components used in a product. 1.5. The tool should help users reuse FLOSS components that have already been used in a product.

Table 3 . 1 .

 31 Tracking and Reuse of FLOSS components requirements 1. The tool should help users identify the use of FLOSS components in their code base. a. The tool should allow reading in an existing code base. b. The tool should allow automated finding of open source licenses in an existing code base. c. The tool should allow automated finding of open source software checked-in and used by a company developer. d. The tool should allow automated finding of open source software not checked-in, but used by a company developer.

3 .

 3 The tool should help users update FLOSS components and their metadata. a. The tool should allow automated updates of FLOSS components to their newest available versions. b. The tool should allow to back up the current versions of FLOSS components before updating them. c. The tool should allow automated identification of changed metadata including FLOSS component license and copyright information. d. The tool should allow automated history recording of FLOSS components and their metadata.

4 . 5 . 3 . 4 . 5 .

 45345 The tool should help users maintain bill of materials of the FLOSS components used in a product. a. The tool should allow creating a formal bill of material using a commonly accepted data exchange standard (such as SPDX). b. The tool should allow automated generation of a formal bill of materials using company's product architecture model. c. The tool should allow developers to add identified and reported metadata on used FLOSS components into the formal bill of materials. d. The tool should allow developers to update the formal bill of materials. e. The tool should allow automated generation of a bill of materials instance in a structured textual format. f. The tool should allow automated generation of a bill of materials instance in a commonly accepted data exchange standard (such as SPDX) format. The tool should help users reuse FLOSS components that have already been used in a product. a. The tool should allow creating a centralized and company-wide accessible FLOSS component repository. b. The tool should allow automated adding of FLOSS components and their metadata into the repository using the product architecture model. c. The tool should allow automated updating of FLOSS components repository using the product architecture model. d. The tool should allow all company developers to access the FLOSS components repository. e. The tool should allow searching in the FLOSS component repository. f. The tool should allow finding the company developers who used an FLOSS component from the repository. Table 4. 2. License Compliance of FLOSS components requirements1. The tool should help users interpret open source licenses. a. The tool should allow user to document open source license interpretations using a formal language or notation supported by the tool. b. The tool should provide automated standard interpretation of the most common FLOSS licenses in company's license repository or license handbook. c. The tool should allow users to modify license interpretation of the most common FLOSS licenses in company's license repository or license handbook. d. The tool should allow users to add license interpretation of the FLOSS licenses of the used FLOSS components to company's license repository or license handbook. e. The tool should allow users to change license interpretation in the license repository or license handbook. f. The tool should allow developers to request license interpretation of a FLOSS license of an FLOSS component s/he wants to use in a product. g. The tool should allow open source program office to discuss license interpretation requests. h. The tool should allow open source program office to fulfill license interpretation requests. 2. The tool should help users document the identified licenses of the used FLOSS components in the company's open source license repository or license handbook. a. The tool should allow creating an open source license repository. b. The tool should allow developers, lawyers and managers to read the open source license repository. c. The tool should allow automated inventorying of known open source licenses from the product architecture model. d. The tool should allow users to add new open source licenses into the open source license repository. e. The tool should allow users to remove obsolete open source licenses from the open source license repository. f. The tool should support the commonly accepted data exchange standards (such as SPDX). g. The tool should allow users to search open source license information in the open source license. The tool should help users find and document the unidentified licenses of the used FLOSS components in company's open source license repository or license handbook. a. The tool should allow software package scanning to find the open source licenses unidentified previously through product architecture model. b. The tool should allow source code scanning for the internally developed code to find the origin of used, but unidentified open source code and its license. c. The tool should allow source code scanning for the FLOSS components taken from FLOSS projects to find the origin of used, but unidentified open source code and its license. d. The tool should allow binary scanning for the FLOSS components that are part of the supplied proprietary software components to find the origin of used, but unidentified open source code and its license. e. The tool should allow automated inventorying of the open source licenses identified because of binary and source code scanning. f. The tool should allow manual changing the automatically identified open source licenses. g. The tool should allow removing the automatically identified open source licenses. h. The tool should support binary and source code scanning integration into the build process and/or continuous integration process. i. The tool should allow finding and documenting copyright notices, export restriction information and other compliance-related metadata for FLOSS components used in a product. The tool should help users approve the use of a FLOSS component in a product based on FLOSS license compliance guidelines. a. The tool should allow creating white lists of company-approved FLOSS licenses according to company policy. b. The tool should allow creating black lists of company-blocked FLOSS licenses according to company policy. c. The tool should allow updating white and black lists of FLOSS licenses. d. The tool should allow creating license interpretation-based rules for automated recommendation on component use approval according to company policy. e. The tool should allow developers to request approval of FLOSS components with previously unassessed licenses. f. The tool should allow lawyers to approve or block use of FLOSS components due to license incompatibility with company policy. g. The tool should allow automated recording of FLOSS license approval decisions in company's open source license repository. The tool should help users distribute a product that is compliant with the FLOSS licenses of the FLOSS components used in that product. a. The tool should allow automated generating of FLOSS license obligations for each product using product architecture model and open source license repository. b. The tool should allow automated assignment of tasks that will ensure compliance with FLOSS license obligations. c. The tool should allow automated audit of product's bill of materials before distribution. d. The tool should allow manual audit of product's bill of materials before distribution. e. The tool should allow adjusting product's bill of materials before distribution.

3 .

 3 The tool should help users estimate the cost of using an FLOSS component. a. The tool should allow automated cost estimation of FLOSS component integration and maintenance in a product. b. The tool should allow automated risk assessment of FLOSS community discontinuing its development of the FLOSS component and automated cost estimation of internal maintenance of the FLOSS component. c. The tool should allow users semi-automated estimation of the benefit of using an FLOSS component compared to proprietary and in-house development alternatives.

Table 1 .

 1 Theoretical sample of companies

	Company	Company domain	By business model	By type of customer	By size (employees)
	Company 1	Consulting	SP-OS, SDS	Enterprise	Medium
	Company 2	Automotive	SDS	Enterprise	Small
	Company 3	Automotive	SDS	Enterprise	Large
	Company 4	Enterprise Software	SP-OS	Enterprise, retail	Medium
	Company 5	Enterprise Software	SP-CS	Enterprise, retail	Medium
	Company 6	Enterprise Software	SP-OS, SP-CS, MC, GT Enterprise, retail	Large
	Company 7	Enterprise Software	SP-OS, MC, GT	Enterprise, retail	Medium
	Company 8	FLOSS Foundation	OSF	Enterprise, retail	Small
	Company 9	Hardware and Software	OP	Enterprise	Large
	Company 10	Legal	MC	Enterprise, government	Large
	Legend for

Table 1 :

 1 SDS= Software development service, SP-OS= Software product vendor for open source software, SP-CS= Software product vendor for closed source software, GT= Governance tool providers, MC= Management consulting, OSF= Open source foundation, OP= Other products incorporating software

Table 2 .

 2 Sampling of governance tools

	Tool	Tool provider	By license	By delivery model	By scannable artifacts
	Black Duck	Black Duck Software by Syn-	Proprietary	Cloud-based	Source and binary code
	Hub	opsys
	DejaCode	nexB	Apache 2.0	Cloud-based, on premise	Source and binary code
	FOSSology	FOSSology FLOSS project	GPL-2.0	On premise	Source and binary code
	FOSSA	FOSSA	Proprietary	Cloud-based, on premise	Source code
	OSS-Review-	OSS-Review-Toolkit (ORT)	Apache 2.0	On premise	Source code
	Toolkit	FLOSS project
	WhiteSource WhiteSource Software	Proprietary	Cloud-based, on premise	Source and binary code

2. License Compliance of FLOSS components

  One interview partner mentions this requirement for this use case (Requirement 1.4): "So, we do have tools to keep track of different components or licenses we're using. If you get requests or requirements from customers to provide a list of used [FLOSS] components and licenses, we use this tool to track those and push those requirements into our [development] process.2.1. The tool should help users interpret open source licenses. 2.2. The tool should help users document

" (Company 7)

Another expert suggests a requirement to enable tracking and reusing FLOSS components (Requirement 1.5): "What we have there at the moment is that [for] half of the company we have essential database or half of the company uses that central database of components and their licenses."

(Company 2)

the identified licenses of the used FLOSS components in the company's open source license repository or license handbook

  .2.3. The tool should help users find

and document the unidentified licenses of the used FLOSS components in the company's open source license repository or license handbook

  . 2.4. The tool should help users approve

the use of a FLOSS component in a product based on FLOSS license compliance guidelines

  . 2.5. The tool should help users distribute

a product that is compliant with the FLOSS licenses of the FLOSS components used in that product.

Table 5 .

 5 3. Search and Selection of FLOSS components requirements 1. The tool should help users search for FLOSS components. a. The tool should allow automated search of available FLOSS components using publicly available data. b. The tool should allow automated comparison of available FLOSS components using publicly available data. 2. The tool should help users select best FLOSS components. a. The tool should allow automated health assessment of open source communities using publicly available data. b. The tool should allow automated maturity assessment of open source communities using publicly available data. c. The tool should allow automated corporate dependence assessment of open source communities using publicly available data. d. The tool should allow automated maturity assessment of open source communities using publicly available data. e. The tool should allow automated responsiveness assessment of open source communities using publicly available data.

  Hub enables to] fully discover all open source in your code" (Black Duck Hub)However, not all detailed (low-level) requirements from the proposed theory are supported by existing tool features. Requirement 1.1.d, for example requires tools to allow automated finding of open source software not checked-in but used by a company developer. This requirement is not entirely supported by any of the studied tool because of its technological complexity. FOSSology is an open source license compliance software system and toolkit. As a toolkit you can run license, copyright and export control scans from the command line. As a system, a database and web UI are provided to give you a compliance workflow. License, copyright and export scanners are tools available to help with your compliance activities."(FOSSology)

	FOSSA helps explore and report relationships between modules incl. the open source ones (Requirement 1.2):
	"[FOSSA allows its user to] explore relationships between modules and if/how dependencies are included in
	your build" (FOSSA)
	Black Duck Hub also has features for BOM maintenance (Requirement 1.4) and for FLOSS component reuse
	(Requirement 1.5):
	"We provide a license obligation report, including an easily consumable bill of materials (BOM) that you can
	deliver to your customers and/or internal stakeholders." (Black Duck Hub)
	"[Black Duck Hub enables to] eliminate uncertainty and promote reuse [of FLOSS]" (Black Duck Hub)
	License Compliance of FLOSS components. All the studied tools support FLOSS license compliance features.
	They fulfill offer fulfilling requirements, such as license interpretation, license identification and documentation,
	FLOSS component approval etc.
	FOSSology covers several requirements related to FLOSS license compliance (Requirement 2.2, 2.3):
	"

Acknowledgments. We would like to thank Hannes Dohrn, Michael Dorner, Maximilian Capraro, Andreas Kaufmann and Shushanik Hakobyan for their generous feedback that helped us improve our paper. We would also like to thank our industry partners that provided their valuable time and expertise for this research project.


M Vafopoulos

S Rallis
email: strallis@gmail.com

I Anagnostopoulos

V Peristeras
email: v.peristeras@ihu.edu.gr

D Negkas

I Ska- Ros

A Tzani

Mining and linking open economic data from governmental communities

Keywords: Open Data, Open Systems, Government, Economy

In this paper, we propose a model conceptualization (Linked Open Economy -LOE) capable of exploiting the massive amount and variety of open economic data that are gradually becoming available by governments and open source communities. The main aim is to unleash the power of open data and open source systems and create a common ground to serve as a catalyst in providing more efficient answers in important economic activities.

Introduction

In order to ensure transparency and provide valuable means of innovation, many governments demand from their public authorities to open their data (e.g. data.gov.uk), as well as to support their provision and maintenance with crowd-source independent repositories and open-source systems (like CKAN 1 etc.). Towards this end, there are also many organized initiatives and projects. To name a few, the IBP 2 promotes public access to accountable budget systems, thus allowing citizens to in-vestigate whether central governments manage properly procedures in respect to public finances. Similarly, the Open Budgets3 , the Big Data Europe 4 and the Your Data Stories5 H2020 projects provide a scalable platform for public administrations to publish and preserve open economic data under open-source support (e.g. GitHub). A comprehensive review of other similar initiatives can be found in [START_REF] Vafopoulos | Linked Open Economy: Take Full Advantage of Economic Data[END_REF].

Our proposed model

There are several standards, controlled vocabularies and ontological schemes for achieving semantic linking between open data. In the economy domain, the most important are: i) the GoodRelations ontology [START_REF] Hepp | Goodrelations: An ontology for describing products and services offers on the web[END_REF], ii) the Public Contracts ontology [START_REF] Nečaský | Linked data support for filing public contracts[END_REF], iii) the Organization ontology , and iv) the vCard ontology . All above ontologies and schemas are cross-linked with several domain-independent controlledvocabularies such as FOAF , DC Terms , SKOS [START_REF] Miles | SKOS core: simple knowledge organisation for the web[END_REF], and DBpedia.

Based on the above (data and interoperability standards), we propose the Linked Open Economy (LOE) model (see Fig. 1), which is an economy-driven rather than a data-or statistics-driven approach. The model has been designed to better balance the trade-off of, being as generic as to be scalable to future open data categories, and as specific as to be compatible with existing initiatives. Furthermore, its top-level conceptualization interlinks the main publicly available data for the economy, as well as it models the flows incorporated in public budgeting, procurement and subsidies/aid. Detailed information about LOE modeling, as well as its main classes and properties can be found at https://github.com/LinkedEcon/LinkedEconomyOntology-ELOD.

Application case study: Greek public procurement

The Central Electronic Registry of Public Procurement (KHMDHS) (eprocurement.gov.gr) is the official procurement portal of the Greek government which contains information on all public contracts for goods, services, and public works worth more than €1,000. It was established to reinforce transparency and effective management of public procurement. According to the Linked Economy Ontology (hereafter under the elod prefix), the basic model consist of: elod:DecisionDomain In this dataset the "tenders" concept is available. In order to model this part of the LOE flow, we use the pc:Contract class. The main parts are the following:

• the contracting authority which issues a contract,

• the CPV code which characterizes the products or services,

• the specified price of the contract including the currency specification, and • the tender to whom a contract is awarded.

elod:SpendingDomain

The main components are:

• the authority which pays for the products or services,

• the sponsor who is paid for the offered products or services,

• the CPV code which characterizes the products or services, and • the expense amount including the currency specification.

Organization classes

The essential elements of the organization are given by the vat Id, the name, the vat Id type, and the country registered at.

elod:PriceDomain In the same sense as above, we use the gr:Offering class as well as the following:

• gr:BusinessEntity: This class represents the organizations. It is one of the four classes used for their modeling.

• gr:SomeItems: This class contains the information of a service or product.

• elod:SpendingItem: This class represents decisions that involve spending actions.

• gr:UnitPriceSpecification: This class represents a conceptual entity that specifies the price asked for a service or product. It specifies the price, the currency and whether the price includes VAT or not.

In order to combine and compare products which belong to a gr:Offering from different instances of elod:PriceDomain class we use the class elod:CPV in the second level of our modeling. For example the instances of gr:Offering class in KHMDHS Data set are linked to an elod:CPV instance, the same connection exists in eprices Data set as well. Thus, we can extract information based on a common elod:CPV instance from different elod:PriceDomain resources.

The basic part of elod:CPV instance is: • The unique code of cpv and the property which specifies it is elod:cpvCode.

•

The Greek and English name of this category by using the properties elod:cpvGreekSubject and elod:cpvEnglisSubject.

Conclusions

LOE can be used to i) enable information exchange between open source systems, ii) integrate open data from heterogeneous sources and iii) publish semantic and linked data related to economic activities. It can also be connected to market processes as analytically described in [START_REF] Vafopoulos | Linked Open Economy: Take Full Advantage of Economic Data[END_REF] where the generic LOE model is introduced. At the end of this short paper, we depict a SPARQL query for an open API endpoint (http://143.233.226.49:8890/sparql). This query asks for retail tomato prices from the official Greek Price Observatory and compares them with wholesale prices provided by the Central Market of Thessaloniki / KATH (in three different qualities) for a specific day. Retail stores with the highest and the lowest prices are also provided. Finally, the query returns the price paid for a specific public contract for tomatoes, thus combining information from governmental communities and market itself.

Beyond government and public authorities, we do believe that LOE can provide high valuable insights to other domain stakeholders (e.g. citizens, developers, researchers, journalists, companies etc.), who can use it as an establish and compact common ground to get and compile valuable economic information.

Fig. 1 .

 1 Fig. 1. The Linked Open Economy (LOE) model.

ckan.org

internationalbudget.org/

OpenBudgets.eu

BigDataEurope.eu

YourDataStories.eu

Acknowledgments

This paper is supported by the project "Open Journalism -OpJ", which has received funding from the Digital News Initiative (DNI) Innovation Fund.


Gustavo Pinto
email: gpinto@ufpa.br

Igor Steinmacher
email: igorfs@utfpr.edu.br

Marco Gerosa
email: marco.gerosa@nau.edu

Leaving Behind the Software History When Transitioning to Open Source: Reasons and Implications

Maintenance of software history is regarded to be one of the most relevant features of Version Control Systems (VCS) and is wellknown to be indispensable for software developers. However, transitioning from proprietary to open source software poses a challenge: keeping the software history might make available years of historical records and internal matters from the company that built the software. On the other hand, removing the software history may disturb the development and may be harmful to new contributors. We conducted a survey with open source software projects that made this shift to investigate (1) the reasons why they removed the software history and (2) the challenges that developers face with the lack of availability of software history. Among the results, we found that the most common reason for removing the software history is because it is entangled with proprietary code (the fact that the history contains sensitive information appears next). Interestingly, most core developers believed that the lack of software history is, in the worst case, "a very minor inconvenience."

Introduction

Maintaining software history, or commit history, is one of the main benefits of Version Controls Systems (VCSs). Developers refer to the software history not only when they need to navigate through changes related to their tasks, but also to learn from previous mistakes or to decide what to do next [START_REF] Tao | How do software engineers understand code changes?: An exploratory study in industry[END_REF]. Indeed, a recent survey evidenced that software history is indispensable for developers: 61% of the respondents said to examine history up to a few times a day [START_REF] Mihai Codoban | Software history under the lens: A study on why and how developers examine it[END_REF]. Practitioners also report acquiring knowledge when examining software history [START_REF] Pham | Creating a shared understanding of testing culture on a social coding site[END_REF]. In particular, the recent introduction of social coding hosting websites made software history of open source software projects more accessible and understandable. As a consequence, even end users are taking advantage of the software history [START_REF] Sandeep | On the benefits of providing versioning support for end users: An empirical study[END_REF]. Researchers also leverage software history to conduct several studies, for instance, regarding the impact of co-changes on software maintenance activities [START_REF] Oliveira | Unveiling and reasoning about co-change dependencies[END_REF], to estimate defects [START_REF] Steff | Co-evolution of logical couplings and commits for defect estimation[END_REF], or to fix bugs [START_REF] Bachmann | The missing links: Bugs and bug-fix commits[END_REF].

However, when open-sourcing their projects, several companies chose not to open the commit history. If decision makers decide to keep the software history with information from the entire development process, they might share sensitive data that is only supposed to be accessed by internal members of the software company (e.g., database passwords). However, if decision makers decide not to keep the software history, they might introduce an additional burden for the software development team (e.g., when dealing with maintenance tasks) or even for new contributors interested in joining the new open source project.

This kind of trade-off is relevant since many software companies, even those that were well-restrictive when it comes to publishing their software artifacts, are now releasing their former proprietary projects under open source licenses. As a notable example, in 2015, Apple released Swift, a programming language designed to be the successor of Objective-C on mobile platforms, under Apache 2, an open source software license. A quick search on HackerNews4 -a developeroriented news aggregator -reveals that there are more than 200 news regarding proprietary software projects that became open source 5 .

To shed some light on the trade-offs of keeping the software history, we surveyed proprietary software projects that made the shift to open-source and did not open the software history. We selected 50 projects by searching at news aggregators, mailing lists, or README files (details in Section 2.2). To understand the reasons and challenges of working with a non-trivial, yet history-free open source project, we posted questions in the project issue trackers or mailing lists. Based on the responses, we characterized a variety of reasons that explain the lack of software history, such as: "[the history] contains sensitive information," "housekeeping needed," and "licensing and legal reasons." Still, regarding the challenges associated with the lack of software history, although some respondents acknowledge the importance of such history, they reported to have very few problems with it, as one maintainer mentioned, "I'm probably the person most likely to access it, and I'd estimate that I use it only a few times per year ".

In summary, this paper makes the following main contributions:

-The reasons that lead project maintainers to leave behind the software history when transitioning to open source; -The discovery that some project maintainers do not value software history as predicted by the literature.

Method

In this section, we describe our research questions (Section 2.1), the projects studied and how we found them (Section 2.2), and our survey design and application (Section 2.3).

Research Questions

To guide our research, we investigated the following important but overlooked research questions: RQ1: Why some projects do not open the software history when going open source? Why: Although one might believe that the reasons behind the removal of the software history are straightforward (e.g., to protect sensitive data about the company), this research question is intended to bring evidence to confirm or refute this belief, as well as to uncover additional reasons.

RQ2: What are the challenges associated with the lack of software history? Why: To understand the hidden challenges triggered by the lack of software history. This better understanding can, in turn, motivate researchers and tool makers to improve existing VCS tools in order to mitigate these challenges, or even to avoid the need of leaving behind the software history.

Studied projects

We selected a set of active and non-trivial proprietary software projects that recently (i.e., no later than 2014) became open source. To identify these projects, we used a convenience sampling approach: we searched in mailing lists, blog posts, and newsletters for indication of whether a proprietary project became open source. We double checked the first commit(s) for anything indicating whether the source code was imported all at once or not. Such commit usually has an informative message and a high number of additions. For instance, the first commit from project deepvariant was named "Initial release of Deep-Variant", and had 49,522 additions (0 deletions) in 270 files. 6 We started this search in June 2016 and proceeded until we found 50 instances of proprietary projects that deleted their software history when transitioning to open source. Among them were IndexTank from LinkedIn, caravel from Airbnb, msbuild from Microsoft, and Haxl from Facebook. Throughout this process, we found only eight projects that kept the software history. We sent open questions to the 50 selected projects and received answers from 35 projects, which had been considered for this study; the list of the 35 projects is available at Table 1. Although the list of studied projects is not exhaustive, it contains a variety of projects, with relation to their domains, programming language use, and size in terms of lines of code. Figure 1 depicts some characteristics of the studied projects.

Survey

To better understand the reasons for the removal and the problems related with the lack of history, we designed a survey aimed at gathering insights about the importance of the lack of software history. We asked four open questions: Q2. Did the core developers face any kind of problems when trying to refer to the old history? If so, how did they solve these problems? Q3. Did the newcomers face any kind of problems when trying to refer to the old history? If so, how did they solve these problems? Q4. How does the lack of software history impact understanding and evolution of software?

We sent the questionnaire by creating issues in the issue trackers of the selected projects. This approach has been successfully employed in recent related work (e.g., [START_REF] Avelino | A novel approach for estimating truck factors[END_REF]). Projects Tensorflow and Scratch closed the issues, suggesting other means to send research inquiries. 78 We, therefore, approached these projects through their mailing lists (tensorflow indeed replied our research inquiries through the mailing list: http://bit.ly/2qR3Mm1). When doing so, one mailing list user contacted us, asking: "If you'd like another proprietary project that went open source and left behind its history, card.io did that," which we promptly accepted. In total, we collect answers from developers of 35 open source projects (totalizing 41 answers; we received up to four answers per project). For the majority of projects (project ChakraCore is the only exception), the respondents were within the top-10 most active ones.

To compile the survey results, we qualitatively analyzed the answers following coding procedures [START_REF] Strauss | Basics of Qualitative Research : Techniques and Procedures for Developing Grounded Theory[END_REF]. The qualitative analysis was conducted independently by the first two authors, followed by a consensus meeting. To enrich some of the findings, we opted to use some quotes throughout the results section. Among similar opinions, we chose to quote only the one we considered the most representative for each case. While analyzing the answers, we observed that the lack of software history occurs for several reasons (some respondents described more than one reason):

Entangled with proprietary code (11 occurrences). We found that some projects became open source by open-sourcing a small part of a bigger project.

As one respondent mentioned "Extracting just the subfolder would have been difficult, and older versions would not have built." Another respondent summarized this process as: "first get something working, and then disentangle it from your own proprietary code, configuration, etc." The same respondent also suggested that this might be a common pattern in OSS projects.

Contains sensitive information (11 occurrences). Some projects had hard-coded sensitive information (e.g., credentials of a remote database) in the source code, e.g., "DeepVariant was originally developed within Google, using our internal systems. [...] the earliest commits may contain information we cannot share, so upon releasing DeepVariant we squashed the history." Although one could simply delete the commits that alter this information, one respondent mentioned that they "have to do an audit of the change descriptions to make sure the descriptions are appropriate for being published publicly," which they were unwilling to do. As another respondent said: "Going through potentially thousands of commits, realistically, means no one will take on the heroic task of even open-sourcing the product." Thus, the only way to effectively remove this sensitive information is removing the entire software history.

Housekeeping needed (7 occurrences). As Fogel already anticipated [START_REF] Fogel | Producing Open Source Software: How to Run a Successful Free Software Project[END_REF], prior to releasing a proprietary software as open source, one needs to exert some effort toward improving code quality and documentation, as stated by one respondent: "We cleaned out embarrassing or inappropriate comments, brought the code up to OSS standards, and generally improved code hygiene, robustness, and security." However, it was unexpected that the amount of refactoring required would prevent the software history from being useful, as another respondent said: "the amount of reorganization that happened *just before* open-sourcing meant that it would be harder to track the history than to just understand the current state." Of less importance (4 occurrences). Contrary to recent studies (e.g., [START_REF] Mihai Codoban | Software history under the lens: A study on why and how developers examine it[END_REF]), some developers believed that the software history does not deserve such importance. One respondent suggested that "two of the primary motivations for keeping history are egos and understanding bug fixes. [our project] was low on ego, and we were careful to comment non-trivial or subtle bug fixes, so those two historical artifacts weighed less heavily." Another respondent highlighted another aspect of this lack of importance: "remember that often something started as one person's random weekend project. Keeping a pristine history might not have been a priority." License and legal reasons (4 occurrences). We also found non-technical and legal reasons. As one respondent mentioned: "[Deleting the software history] also made it much easier to get the lawyers at our parent company to agree to open source it-instead of having to review the entire history for safety, they could review just the current state." Another reason is that some now open source applications rely on proprietary code. Therefore, to maintain license compliance, the developers have to maintain that code internally. Ultimately, one respondent summarized this reason: "Legal and policy reasons created incentives to release less source." Did not use a VCS before (3 occurrences). Some projects became open source shortly after their bootstrap. Thus, there was no need to use any VCS, as one respondent said, "there simply was no formal software history kept, and direct cooperation between experienced developers was sufficient to develop it to a releasable state." For these projects, the first commit at GitHub was their first use of a version control system.

Used another VCS before (3 occurrences). One respondent said that "Before moving to GitHub, TensorFlow was developed on a system other than Git, and transferring history was not straightforward." Moreover, same respondent suggested that the effort needed for migrating the software history from one VCS to another does not outweigh the benefits of keeping it: "[the] value [of keeping the software history] was at best unclear, so we didn't do it."

4 RQ2: What are the challenges associated with the lack of software history?

Most of the project maintainers reported that they had few problems with the lack of software history; as one respondent mentioned: "none of the core developers has wanted or needed to go look back through the history." Another respondent stated that "based on practical experience, a history [of ] more than a year is used very rarely", which might explain this behavior. Moreover, another respondent suggested that institutional knowledge, i.e., the combined knowledge of the many contributors to a project, can be an effective substitute for formal software history, for instance: "communication between developers, documentation in and outside of the source code, and the easily understood idiomatic expressions of the Python language were/are sufficient to maintain project coherency."

Even though these comments are in sharp contradiction with recent related work [START_REF] Mihai Codoban | Software history under the lens: A study on why and how developers examine it[END_REF], it does not suggest that the software history is unimportant. Indeed, some respondents acknowledged its importance (e.g., "We very much agree that the software history is extremely useful for developers"). Still, ten respondents suggested that the original software history is internally maintained, as one respondent highlighted: "we still use the non-git system internally and can refer to history if we need to." However, the respondents also suggested that the internal software history is not actively used, as one respondent indicated: "The old history is still available internally. I'm probably the person most likely to access it, and I'd estimate that I use it only a few times per year." Nevertheless, maintaining two software histories for the same project might require additional effort, which can make it difficult to track down the origins of the code.

Similarly, we found that maintainers do not think that the lack of software history is a significant problem for newcomers; all respondents shared this belief. However, most of the respondents said that they are not aware of any problems. Some newcomers may have faced problems, but not reported them, or gave up contributing. Project maintainers often suggested different ways that newcomers can mitigate this problem, as one respondent mentioned: "they have the code to look at and also code which is non-obvious should anyway have comments, else they could ask people who worked on the code before it was released."

Finally, regarding software evolution, we found a remarkable uniformity among the respondents; all of them believed that the lack of software history does not greatly impact software evolution and understanding. In the worse case, one respondent characterized the lack of history "as a very minor inconvenience." Even more interestingly, one respondent said that software history of an active project loses importance over time: "For a fast-moving project, history from more than half a year ago is not particularly valuable for development."

Along with this line of thought, Codoban et al. [START_REF] Mihai Codoban | Software history under the lens: A study on why and how developers examine it[END_REF] observed that software developers need better tools to visualize software history. We believe that this lack of tools to properly visualize software history might create the perception that it is "not particularly valuable for development." Ultimately, we observed that the burden the lack of history may cause is "certainly not enough to outweigh the costs of making it public," which is particularly relevant to the software projects under study.

Implications & Limitations

In this section we discuss some implications of our findings, and state the limitations of this work.

Implications

Based on our findings, we discuss some implications for stakeholders. We observed that some respondents mentioned a lack of tools to ease the migration between version control systems, for instance: "I think this one may have been moving between source code repository technologies (SVN to Git) and the tools did not work well enough." Researchers and tool builders can propose a new set of tools to better support the transition between VCSs. Additionally, we observed that a common way to open-source a software project is by extracting only a small part of an existing project. However, this activity might be extremely difficult to conduct without appropriated tool support. As a result, developers leave behind the software history. Researchers can explore better techniques to extract only parts (or features) of the software while keeping only the relevant software history. Since some respondents mentioned that old software history is not particularly valuable for development, VCS designers can also propose lightweight VCSs, in which only the N most recent changes are kept, where N is based on project's activity or user choice. Programming language designers can also introduce programming language constructs that keep track of the evolution of certain parts of the code.

Limitations

As any empirical study, this one has limitations and threats to validity. First, we selected our projects by searching blog posts, newsletters, and README files; the first author manually conducted this process. Due to the qualitative nature of this approach (and the timeliness of a proprietary project becoming open source), one could find different projects. Moreover, we used GitHub's issues to send out our questionnaires. Such public participation can also be a threat since anyone could answer our questions. To mitigate this threat, we verified whether the respondents were active project members. We found that the majority of the respondents were among the top-10 most active contributors (only one respondent was not in the top-10). However, nine respondents do not appear as a contributor of the studied project. This might happen because the software history was removed and their contributions might have been removed as well. By comparing the user's affiliation and the project's affiliation on GitHub, we confirmed the affiliation of five of them. The remaining four did not state any affiliation. Also, we observed that some open source projects do not use issues for discussions. We, therefore, got in touch through the mailing list. Still, we certainly did not discover all challenges and reasons behind the lack of software history. Replications are necessary to fully understand the phenomenon. To facilitate replication, we made available the list of studied projects and the responses received in our survey on the companion website: http://bit.ly/dataset-oss2018.

Related Work

Some studies focus specifically on GitHub's features, which allow developers to track activities and form detailed impressions of social and technical abilities [START_REF] Marlow | Impression formation in online peer production: Activity traces and personal profiles in GitHub[END_REF][START_REF] Tsay | Influence of social and technical factors for evaluating contribution in GitHub[END_REF]. Community size, interest, and activeness have also being explored [START_REF] Pinto | More common than you think: An in-depth study of casual contributors[END_REF][START_REF] Steinmacher | Almost there: A study on quasi-contributors in open-source software projects[END_REF]. Moreover, there is a recent growth of studies targeting proprietary projects under development in social coding websites. Kalliamvakou et al. [START_REF] Kalliamvakou | Open source-style collaborative development practices in commercial projects using GitHub[END_REF] examined how proprietary software projects use GitHub. They found that these projects apply practices such as reduced communication, independent work, and selforganization. Some research has investigated how proprietary projects adopt OSS-related practices to mitigate challenges related to the lack of communication and awareness [START_REF] Riehle | Open collaboration within corporations using software forges[END_REF][START_REF] Sharma | A framework for creating hybrid-open source software communities[END_REF]. More recently, we conducted some studies to understand how the contributions from employees (the ones hired by a software company) differs from volunteers (the ones the contribute in their free time) [START_REF] Luiz | Who drives companyowned oss projects: Employees or volunteers? In V Workshop on Software Visualization[END_REF][START_REF] Pinto | Who gets a patch accepted first? comparing the contributions of employees and volunteers[END_REF]. Regarding licensing, some studies investigated licenses inconsistencies and violations [START_REF] Daniel M German | Understanding and auditing the licensing of open source software distributions[END_REF][START_REF] Daniel A Almeida | Do software developers understand open source licenses?[END_REF][START_REF] Manciola Meloca | A study of nonapproved open-source licenses[END_REF], and other focus on license evolution [START_REF] Di Penta | An exploratory study of the evolution of software licensing[END_REF][START_REF] Vendome | License usage and changes: a large-scale study on github[END_REF][START_REF] Vendome | Machine learning-based detection of open source license exceptions[END_REF].

The closest work is an in-depth investigation of the contribution characteristics of Company-Owned OSS projects that kept the software history [START_REF] Pinto | On the challenges of open-sourcing proprietary software projects[END_REF]. However, to the best of our knowledge, there is no study targeting the impact of the lack of the software history on proprietary projects that made the shift to open source software.

In this paper, we challenge an important belief related to the importance of software history. After the identification of a set of projects that left behind their entire software history after transitioning to open source, we deployed a survey to better understand (1) the reasons that lead to this removal and (2) the hidden challenges that arose due to its lack. We found eight reasons that might justify the decision of removing the software history, such as "entangled with proprietary code," "housekeeping needed," and "license and legal reasons." More interestingly, however, is the fact that when asked whether the lack of software history might impact understanding and evolving of the software, some respondents believed that the lack of history does not place any significant burden on developers.

For future work, we plan to better understand the newcomers' perception of the lack of software history and contrast our results with the analysis of projects that kept the history when migrating to open source.

Fig. 1 .

 1 Fig. 1. Characteristics of the analyzed projects

Table 1 .

 1 The list of projects studied. Project card.io has no issue id because the maintainer personally got in touch with us by email. To see the response online, one needs to concatenate the project's URL + /issues/ + the issue id, resulting in, for instance, github.com/Microsoft/msbuild/issues/621.

	Projects	URL	Issue Id
	msbuild	github.com/Microsoft/msbuild	621
	ChakraCore	github.com/Microsoft/ChakraCore	1280
	heron	github.com/twitter/heron	1018
	caravel	github.com/airbnb/superset	470
	fbctf	github.com/facebook/fbctf	49
	Tensorflow	github.com/tensorflow/tensorflow	2361
	jsaction	github.com/google/jsaction	11
	card.io	github.com/card-io/card.io-dmz	-
	openwebrtc	github.com/EricssonResearch/openwebrtc	611
	manta	github.com/joyent/manta	14
	triton	github.com/joyent/triton	202
	Dshell	github.com/USArmyResearchLab/Dshell	87
	buffer-ios	github.com/bufferapp/buffer-ios-image-viewer	42
	django-knowledge github.com/zapier/django-knowledge	70
	warp-ctc	github.com/baidu-research/warp-ctc	42
	codecombat	github.com/codecombat/codecombat	3775
	djinni	github.com/dropbox/djinni	253
	superpowers-core github.com/superpowers/superpowers-core	143
	GameMaker	github.com/gandrewstone/GameMaker	2
	opentoonz	github.com/opentoonz/opentoonz	640
	magento2	github.com/magento/magento2	5654
	IndexTank	github.com/linkedin/indextank-engine	43
	ShareLatex	github.com/sharelatex/web-sharelatex	282
	Haxl	github.com/facebook/Haxl	52
	reason	github.com/facebook/reason	651
	redex	github.com/facebook/redex	164
	torchnet	github.com/torchnet/torchnet	28
	torch	github.com/facebook/fb.resnet.torch	86
	draft-js	github.com/facebook/draft-js	555
	pinball	github.com/pinterest/pinball	74
	decoda	github.com/unknownworlds/decoda	33
	mrjob	github.com/Yelp/mrjob	1356
	deepvariant	github.com/google/deepvariant	36
	fsharp-support github.com/JetBrains/fsharp-support	6
	escape	github.com/ankyra/escape	4
	3 RQ1: Why some projects do not open the software
	history?

https://news.ycombinator.com/

https://hn.algolia.com/?query="isnowopensource", accessed on Jan 8th, 2018.

https://github.com/google/deepvariant/commit/8b84eab

https://github.com/LLK/scratch-flash/issues/1112

https://github.com/tensorflow/tensorflow/issues/2361

Acknowledgments

We thank our respondents and the reviewers. This work is supported by CNPq #406308/2016-0; PROPESP/UFPA; and FAPESP #2015/24527-3.