Terhi Kilamo
email: terhi.kilamo@tuni.fi

Valentina Lenarduzzi
email: valentina.lenarduzzi@lut.fi

Tuukka Ahoniemi
email: tuukka.ahoniemi@iki.fi

Ari Jaaksi

Jurka Rahikkala
email: jurka.rahikkala@vaadin.com

Tommi Mikkonen
email: tommi.mikkonen@helsinki@fi

How the Cathedral Embraced the Bazaar, and the Bazaar Became a Cathedral

Keywords: Open source, development tools, software business

Over the past 20 years, open source has become a widely adopted approach to develop software. Code repositories provide software to power cars, phones, and other things that are considered proprietary. In parallel, proprietary development has evolved from rigid, centralized waterfall approaches to agile, iterative development. In this paper, we share our experiences regarding this co-evolution of open and closed source from the viewpoints of tools, practices, and organizing the development work, concluding that today's bazaars and cathedrals have much more common characteristics than those that separate them.

Introduction

In 1997, Eric S. Raymond [START_REF] Raymond | The cathedral and the bazaar[END_REF] juxtaposed two ways of software development: the cathedral and the bazaar. The differences of the two have from the beginning been in the development approach instead of the source code alone. The cathedral model develops the software within a closed group of developers, and the product is only released in structured intervals; in contrast, the bazaar keeps the development process fast and visible to any interested party all the time.

Originally, the bazaar marked open source, and the cathedral proprietary. Over time, things have changed however, making proprietary development resemble open source software and its development models. In parallel, open source has grown to the level of importance where it has adopted many of the centralized development schemes traditionally associated with proprietary software. Moreover, open source quality increased year after year [START_REF] Del Bianco | The qualispo approach to oss product quality evaluation[END_REF][START_REF] Del Bianco | An investigation of the users' perception of oss quality[END_REF][START_REF] Rudzki | Evaluating quality of open source components for reuse-intensive commercial solutions[END_REF], and producers started to apply similar marketing models of proprietary [START_REF] Del Bianco | A study on oss marketing and communication strategies[END_REF]. As a result, companies started to consider open source as trustworthy of proprietary ones [START_REF] Del Bianco | A survey on open source software trustworthiness[END_REF], and opening proprietary software has become a viable option [START_REF] Kilamo | From proprietary to open source-growing an open source ecosystem[END_REF][START_REF] Kilamo | Open source ecosystems: a tale of two cases[END_REF][START_REF] Sirkkala | Opening industrial software: planting an onion[END_REF].

We approach this evolution with a retrospective view of the past 20 years of software development, and find that the cathedral has turned into "a babbling bazaar" while the bazaar has evolved towards "reverent cathedral-building" [START_REF] Raymond | The cathedral and the bazaar[END_REF].

Background

The origins of open source software can be traced back to 1974, when US Commission on New Technological Uses of Copyrighted Works (CONTU) [START_REF]Final report of the National Commission on New Technological Uses of Copyrighted Works (CONTU)[END_REF] decided that software is a proper subject matter of copyright to the extent that it embodies its authors' original creation [START_REF] Keplinger | Computer software-its nature and its protection[END_REF]. While previously code had been liberally shared among different stakeholders largely ignoring IPR, this was no longer an option, concerning in particular modifying program source code. This initiated the movement to regain the original 'freedoms' of programmers, eventually resulting in forming the Free Software Foundation (https://www.fsf.org).

The early years of open source software revolved around infrastructure software, including operating systems, windowing systems, programming tools and compilers, and other software that is commonly used to operate or program any computer. A key milestone in this era is year 1989, when the first version of the GNU General Public License (GPL) was published. It governs the use of open source software, taking open source to the league of a "serious" software system, where formal governance and ruling existed.

By year 2000, as witnessed by Raymond's essay [START_REF] Raymond | The cathedral and the bazaar[END_REF], the focus was shifting to development models where proprietary software was compared to carefully crafting a pre-designed cathedral and open source was evolving organically based on individuals' desires in bazaars. In parallel, using open source as a part of business and proprietary software gained widespread interest [START_REF] Dibona | Open sources: Voices from the open source revolution[END_REF]. Soon, open source become a viable business model [START_REF] Rolandsson | Open source in the firm: Opening up professional practices of software development[END_REF], and it was adopted by various companies.

Today, open source is characterized by three key elements: (i) code comprising the implementation, (ii) the licence under which the software is distributed, and (iii) the community that maintains the code. Furthermore, open source is viewed through its meritocratic nature of collaboration where anyone can contribute, contributions are judged based on merit and the development is selforganizing [START_REF] Riehle | Open collaboration within corporations using software forges[END_REF]. This characterization does not consider the cathedral and the bazaar metaphor, and over time, the difference between the two has become a fine line -companies extensively participate in open source development [START_REF] Johri | cool" or" monster"? company takeovers and their effect on open source community participation[END_REF] and open source communities and projects are organized and governed [START_REF] Di Tullio | The governance and control of open source software projects[END_REF][START_REF] Sadowski | Transition of governance in a mature open software source community: Evidence from the debian case[END_REF]. The beginning of this transformation was documented by Fitzgerald [START_REF] Fitzgerald | The transformation of open source software[END_REF]; the trend has since continued, making cathedrals embrace bazaars and bazaars to become cathedrals.

Why the Cathedral Embraced the Bazaar?

Pre-open source software industry habits were very similar to the rest of the industry, consisting of large enterprises that had very established ways and elaborated processes, to the brink of a disaster in their inability to adopt new practices [START_REF] Kanter | When giants learn to dance[END_REF]. For software development companies, this meant rigorous inspections [START_REF] Ackerman | Software inspections: an effective verification process[END_REF] to improve quality and process models such as CMM [START_REF] Paulk | The capability maturity model: Guidelines for improving the software process[END_REF], where the organizational capabilities were being improved without paying much attention to the interests of individuals.

Open source development challenged all the above. Since its humble origins, the power of open source has stemmed from programmers who choose to contribute to projects of their interest, not by management control. To support voluntary cooperation across the Globe, various tools were introduced, including source control management tools such as Subversion and later Git. Distributed version control systems have enabled the development through pulling code from repositories to create software locally as a combination of several code sources. The range of components from operating and windowing systems to tiny, almost self-evident snippets have made open source systems an integral part of systems [START_REF] Mikkonen | Software reuse in the era of opportunistic design[END_REF], many of which we do not consider as open source, and these are also visible in software architecture of many systems [START_REF] Lokhman | A coreperiphery-legality architectural style for open source system development[END_REF].

Open source also helped to shape new development processes, such as introducing the pull requests mechanism and the concepts of continuous integration, deployment and delivery, as means for handling new contributions to the code base. Similarly, issue tracking tools such as Bugzilla and review tools such as Gerrit for collaborative handling of issues and reviewing code contributions in turn stem from open source projects. New tools are continuously introduced into the market, with the goal of supporting the developed product and the development process [START_REF] Sbai | Exploring information from oss repositories and platforms to support oss selection decisions[END_REF]. Since these tools have largely been about 'scratching one's own itch', the developers working on proprietary software have quickly realized that these tools really empower the developers. Hence, tools and processes made familiar by open source development are used to distribute the development effort globally, to manage quality, and to enable agile development, manifesting transparency in every development phase. Furthermore, companies do not only apply open source tools and associated methods in their internal development, but also contribute directly to open source projects. To this end, big closed source players such as Microsoft, Google, Oracle, Facebook and Amazon are nowadays major open source contributors, with a large open source codebase of their own [START_REF] Hoffa | Who contributed the most to open source in 2017 and 2018? Let's analyze GitHub's data and find out[END_REF]. For many companies, this has meant a complete transformation from their organizational perspective and operational culture -so-called agile transformation [START_REF] Fry | Large scale agile transformation in an on-demand world[END_REF], increasing transparency and empowering the developers in particular.

Finally, there are also more unscrupulous motives to embrace open source than those above. For instance, large companies may contribute to OSS just because they no longer see viable business around a product, to white-wash their public picture of becoming a Linux/OSS lover, or simply because they have to, as someone accidentally misused a GPL component.

How the Bazaar Turned into a Cathedral?

While anyone can start an open source project without commercial interests, the fact is that many of the projects work well because someone is funding the work. A common model is that an open source project is mainly a product of one company that is hosting the infrastructure needed by the project, contributing the biggest chunk and then inviting others to join in. Naturally, as the company seats most of the maintainer spots, it has a wide influence on what gets in to the main branch of the project and what does not. Typically, the funder has its own interests, although based on contributions also other stakeholders' interests can be identified -for instance, with respect to the Qt framework and open source Qt Project, one can clearly see from the contribution timeline when eg. different phone vendors have had their time in adopting the GUI framework to their own platform-specific needs.

Today, it is easy to find big names in open source software. Linux has risen as the de-facto OS for clouds, servers, and mobile and embedded devices alike, and web browsers are predominantly open source due to the rise of Chromium next to Firefox, and Microsoft letting go of their closed-source implementation [START_REF] Warren | Microsoft is building its own Chrome browser to replace Edge[END_REF]. With Linux at its core, Android now has the largest market share of smartphone ecosystems. Recently Microsoft purchased the largest host of code repositories GitHub (https://blogs.microsoft.com/blog/2018/10/26/microsoftcompletes-github-acquisition/). This rise to a key position in commercial settings has strengthened the corporate role in open source. As the direction of each project has significant commercial meaning, business stakes have become too high for the development to take unexpected turns, following individual developers' itch.

When growing in size and importance, many open source projects have started to lose their bazaar development model. Decision-making has become centralized, and processes are decided within a small group. For instance, in the Linux community, which has been an example of the centralized approach from its start, there is a well-defined governance model instead of everyone directly contributing to the code base. Similarly, open source foundations such as the Apache Software Foundation and the OW2 Consortium have set rigorous "cathedral-like" processes to developers who want to have their software in the foundation -a quality control process to follow, a program of incubation, and an "attic" to keep track of unmaintained projects (https://www.apache.org/foundation/how-it-works.html). In general, it is difficult to imagine any large-scale open source project that goes completely ungoverned.

Finally, stakeholder needs include ensuring the sustainability of the project as several stakeholders have significant business based on key open source software [START_REF] Nyman | Perspectives on code forking and sustainability in open source software[END_REF]. The recognition of IPR and the licence model are such key mechanisms. This has resulted in acts that are based on business reasons rather than the software itself. The selected licence itself acts as a cathedral-building mechanism and the licence and the licencing model can have major business impacts. Especially as not all licences can coexist within the same software, business drivers affect the software [START_REF] Hammouda | Open source legality patterns: architectural design decisions motivated by legal concerns[END_REF].

What to Look for Next?

During the recent years, we have seen open source and proprietary software come closer to each other and at the same time switch places. As a consequence of this convergence, the hybrid nature of open source is thriving. When the open source community starts the development as a bazaar -like Linux for example has -they evolve towards cathedrals as they grow, gain business impact, and need to get organized to support the business stakeholders. On the other hand, communities that originate from business needs move to the opposite direction and adopt in part the bazaar model to get contributions from a wider contributor community. Similarly, the distribution of contributors in open source has turned towards corporate employed contributors instead of a buzzing group of volunteers, and in some of the open source projects, it is not possible for a volunteer to contribute any more [START_REF] Mäenpää | Designing for participation: three models for developer involvement in hybrid oss projects[END_REF] -you can fork individually but not join back as the company managing the software does not embrace contributions from other stakeholders, no matter how good they are. The issue is not only about controlling the individual developers' itch but also a wider perspectivewhat is the general direction of the project?

The modern way of accepting contributions is no longer through a monolithic project model but more from a distributed ecosystem marketplace resembling an appstore of modules/features. Perhaps the most vital communities that truly embrace participation of everyone are the likes of the NodeJS ecosystem (https://nodejs.org), where one can easily reuse or modify existing components, contribute new ones, and mash them together to create new systems [START_REF] Hartmann | Hacking, mashing, gluing: Understanding opportunistic design[END_REF]. These are modern bazaars where "capitalism of code" really rules -the most well-received modules/add-ons thrive and get additional contributors (if allowed), whereas individual hobbyist experiments can still co-exist but will eventually perish. Another example of this is the Microsoft VSCode (https://code.visualstudio.com/) where the actual open source project is the core platform, but the idea is actually not about the OS project (of developing a dull code editor) but about the very inclusive ecosystem where everyone can have a shot at creating an add-on. So, forget cathedral-like strict rules and CLAs (contribution license agreements) and bully-like maintainers, but just create your own "app" to the "store" and let's have the markets decide what will work.

Finally, changes in the value chain have had an impact to open source. Today, in many cases data, open APIs, and cloud services are far more important than the code, which has become a commodity. This attitude is backed by the fact that going for full open source means that one does not need to worry about issues such as licence compatibility, liberating companies from considering them.

Conclusions

By now it is obvious that open source software has realized its fundamental reuse promise. The many facets of software in general, together with the availability of readily reusable open source components in particular, have woven open source so deep in software industry that they are next to inseparable. The different kinds of software endeavors can start from opposite ends of being open or closed, but by now it seems that over time, the benefits of both worlds is something to seek for for both small companies as well as giant enterprises.


Andreas Bauer
email: andi.bauer@fau.de

Nikolay Harutyunyan
email: nikolay.harutyunyan@fau.de

Dirk Riehle

Challenges of Tracking and Documenting Open Source Dependencies in Products: A Case Study

Keywords: Open Source Software, FLOSS, FOSS, Open Source Governance

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

Introduction

The growth of free/libre, and open source software (FLOSS) leads the software industry to new opportunities but also challenges. FLOSS promise significant shortcuts by reusing existing software components in commercial products [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][START_REF] Von Krogh | The Promise of Research on Open Source Software[END_REF][START_REF] Fitzgerald | The Transformation of Open Source Software[END_REF][START_REF] Deshpande | The total growth of open source[END_REF]7]. However, to avoid legal and other risks of using FLOSS in commercial products, such as license noncompliance, software vendors need to manage their FLOSS dependencies. Furthermore, this allows to track known security vulnerabilities introduced by such dependencies, as well as export restrictions and other important metadata.

The management of FLOSS dependencies has grown in an ad-hoc fashion in most companies. The architectural models used for this are often designed to satisfy a managerial perspective and neglect more fine-grained issues such as compliance information of bill of materials (BOM) details. As a consequence, there is a mismatch between an architectural model that supports the management of FLOSS dependencies and the models we found in industry. This leads to costly integration operations to ensure license compliance. Many companies develop own tooling to merge documented license information and generate more comprehensive reports about the use of FLOSS in their products. The lack of consistent concepts in the underlining models also causes manual intervention in the dependency management and license compliance processes, which slows down production. The vast, and still increasing, amount of the commercially used open source components additionally complicates the process of license compliance.

To address this industry-relevant yet underresearched issue, we performed exploratory single-case study research at one large established software vendor. We wanted to identify the challenges companies face regarding software dependency documentation in the context of FLOSS license compliance and tracking. We also studied the ad-hoc solutions to these challenges in the context of the studied company. The main contribution of our paper is a systematic analysis of the challenges related to the tracking and documentation of open source components and dependencies in companies. As a result of our study, the following categories of challenges coupled with their point solutions emerged:

-Data Gathering for the Compliance Process -Usage of FLOSS in Products -Custom Reports -SPDX Support -A Central System to Manage Products.

For each category, we report the current issues discovered in the course of the case study, as well as the solutions found at the studied company supported by the analyzed qualitative data through interview quotes and observatory descriptions. We suggest that the identified challenges and solutions can fit together into a conceptual model that we tentatively call the product (architecture) model, which we will investigate and evaluate in further research aiming for broader generalizability beyond this single-case case study.

Related Work

In previous work, we reported our findings on industry requirements for FLOSS governance tools [START_REF] Harutyunyan | Understanding industry requirements for FLOSS governance tools[END_REF]. We found a hierarchical list of requirements that indicated the following four key categories: Tracking and reuse of FLOSS components, License compliance of FLOSS components, Search and selection of FLOSS components, and Other requirements (security, education, etc.). We then extended our findings in a subsequent journal article [START_REF] Harutyunyan | Industry requirements for FLOSS governance tools to facilitate the use of open source software in commercial products[END_REF] with a new round of qualitative data analysis using five additional interviews, which added the fifth category to the proposed theory focusing on the architecture model for software products. Among other requirements for tooling, it showed that companies develop their own tools to incorporate FLOSS governance relevant information with architectural information to manage software products. In this paper, we follow up on the topic of software dependency documentation in the context of FLOSS compliance, and focus on the challenges companies face in doing this. We did not identify any literature focusing on this specific topic, but found literature on FLOSS governance and compliance more broadly.

Hammouda et al. [START_REF] Hammouda | Open source legality patterns: Architectural design decisions motivated by legal concerns[END_REF] introduced open source legality patterns, which help with architectural design decisions motivated by legal concerns associated with FLOSS licenses. They focus on how the interaction between different components can be managed so that the overall product contains no license violations. The patterns are grouped in the following categories: Interaction legality patterns, Isolation legality patterns, and Licensing legality patterns. An example of an Interaction legality pattern is to switch from static to dynamic linking if a proprietary component depends on a strong copyleft licensed component.

Fendt et al. [START_REF] Fendt | Industrial Experience with Open Source Software Process Management[END_REF][START_REF] Fendt | Open source for open source license compliance[END_REF] conducted practitioner-driven research on FLOSS governance, compliance, and policy. In 2016 [START_REF] Fendt | Industrial Experience with Open Source Software Process Management[END_REF], the authors suggested processes for the successful management of FLOSS use in companies that want to avoid the related legal risks. The proposed processes were designed to serve as best practices and a basis for corporate governance, strategy, policy, and process implementation. In 2019 [START_REF] Fendt | Open source for open source license compliance[END_REF], Fendt et al. followed up with an experience report on their use of open source tools and services for open source license compliance. They used several well-known tools such as SW3601 and Fossology2 , integrated in a complete compliance toolchain.

From a model perspective, the Software Package Data Exchange (SPDX TM ) specification is the de-facto standard to exchange the bill-of-materials of a product. The goal of the SPDX specification is to enable companies and other organizations to share license and component metadata for a software package. This specification was the result of a shared effort from different organizations to address the needs of various participants in software supply chains [17]. The SPDX License List is a key factor for the adoption of the SPDX standard in companies [START_REF] Gandhi | Open data standards for open source software risk management routines: An examination of SPDX[END_REF]. This curated list contains the commonly used open source licenses and enables open source license identification through a unique identifier.

German et al. [START_REF] German | A model to understand the building and running inter-dependencies of software[END_REF] described a method to model dependencies that are required to build and execute a program. The classification criteria for dependencies in this model contain information about a dependency's type (explicit or abstract), if it is optional, in which stage it is required (build-time, run-time, etc.), and the usage method (stand alone, library, and more). The packages in this model are also aware of licenses. Additionally, they suggested a method to visualize the dependency graph of a software package based on their model. It also allowed showing inconsistencies, such as license conflicts between packages. For their analysis, they used packages of a FLOSS distribution (Debian 4.0) and demonstrated how the model could help provide insights into the FLOSS ecosystem.

Research Methods

Given the unexplored nature and the practical relevance of the research topic, we conducted a single-case case study informed by Yin [START_REF] Yin | Case study research and applications: Design and methods[END_REF] to study the software dependency documentation in terms of FLOSS license compliance and tracking. We chose the case study methodology over alternatives (e.g. grounded theory, experiments) because of its suitability for the emerging and complex phenomena that can be best studied in their practical contexts [START_REF] Yin | Case study research and applications: Design and methods[END_REF]. Given the complexities of the corporate FLOSS use, governance, and compliance in general [START_REF] Harutyunyan | Corporate Open Source Governance of Software Supply Chains[END_REF] and of the software dependency documentation issues in particular [START_REF] Harutyunyan | Industry requirements for FLOSS governance tools to facilitate the use of open source software in commercial products[END_REF], we chose a case study company that actively uses open source components in products, while encountering issues in tracking and documenting this use as part of the complete product architecture.

We chose a large multinational enterprise software company with mature FLOSS awareness and use. The company provides services to retail and enterprise customers, and distribute open source and closed source software to them as well. In our search for the appropriate case study company, we leveraged our professional network and a German industry-academia collaboration project that two of the co-authors were part of Software Campus3 . This enabled us to find a company that is a heavy open source software user at a certain FLOSS governance maturity level where the basics are covered but more advanced aspects of such governance are in flux. The latter included our focal research topic -software dependency documentation in terms of FLOSS license compliance and tracking. The company and the interview data are anonymized as per the company's request.

We outlined in the case study protocol [START_REF] Yin | Case study research and applications: Design and methods[END_REF] that our case study was both descriptive and explanatory. It was descriptive in detailing reports of what the current state of open source governance at the studied company was when it came to the software dependency documentation focused on FLOSS license compliance and tracking. It was explanatory in presenting some reasons why certain issues in product architecture and open source software dependency documentation arise. When addressing the descriptive side of our study the main co-author visited the case study company for direct observation of the current practices in their real-life context. As for the explanatory aspect, we conducted interviews with five employees at the case study company to cover the breadth of issues faced by the people in different roles responsible for product architecture and FLOSS tracking and documentation. We interviewed employees with different views on the usage of FLOSS within the company. The first two were FLOSS compliance managers. The third person was a product owner and covered the role of a user of open source. The next person was a product manager. The last person was a developer and in his role responsible for the company's architecture model which was used for FLOSS compliance.

To analyze the conducted interviews, we employed computer-assisted qualitative data analysis (QDA) software (CAQDAS) to ensure the systematic analysis of the data and the traceability of our theory to the data. Informed by Jansen's logic of qualitative survey research [START_REF] Jansen | The logic of qualitative survey research and its position in the field of social research methods[END_REF], we conducted an open (inductive) survey, in which the relevant topics of product architecture and FLOSS tracking were identified through the interpretation of raw data -employee interview transcripts. This approach was in contrast to the other type of qualitative surveysthe pre-structured survey, in which some main topics, dimensions, and categories would be defined before the study, which was not suitable for our exploratory study on this emerging domain.

Results

In this section, we present our results on the challenges of tracking and documenting open source dependencies in products.

As Fendt and Jäger [START_REF] Fendt | Open source for open source license compliance[END_REF] show, the required process to be compliant is more complex than just running a license scanner tool on the codebase. Instead, it should be embedded into a bigger process of FLOSS management. Even a company with mature FLOSS awareness and use does not always have a good solution in place to overcome all the challenges of FLOSS dependency management. This leads to workarounds which often force a manual treatment.

In the following, we describe our findings and discuss their implications on the whole FLOSS license compliance process. The main challenges we found are:

-Data Gathering for the Compliance Process -Usage of FLOSS in Products -Custom Reports -SPDX Support -A Central System to Manage Products.

Data Gathering for the Compliance Process If a developer wants to use a FLOSS component it needs to be approved by the company's open source software office. FLOSS compliance processes are in place to manage the approval of a FLOSS component use. Fendt et al. [START_REF] Fendt | Industrial Experience with Open Source Software Process Management[END_REF] describe that a FLOSS management process inside their company consists of several phases. The first phase is the Request Phase, in which development teams initiate an approval request for a new FLOSS component they would like to use. The FLOSS compliance process of our case study company matches this first phase by requesting the use of a FLOSS component. The usage of only approved FLOSS components helps avoid legal compliance risks introduced by unknown components. In our previous studies about industry requirements on FLOSS governance and compliance tools, we found that companies want to have an automated process of adding new FLOSS components and their metadata into a common architectural model [START_REF] Harutyunyan | Industry requirements for FLOSS governance tools to facilitate the use of open source software in commercial products[END_REF], captured in the following requirement:

"The tool should allow automated adding of FLOSS components and their metadata into the repository using the product architecture model" -Requirement 5.b. [START_REF] Harutyunyan | Industry requirements for FLOSS governance tools to facilitate the use of open source software in commercial products[END_REF] But in reality, users of FLOSS components often have to provide information about a component by hand. This manual step of collecting information is timeconsuming and can slow down the whole approval process. The typical required information for an approval decision includes:

-Licenses and copyright information -Project references, like the homepage URL -Uploaded source code and binaries, or provide location to download them -Clarification if component include cryptographic functionalities -Export Control Classification Number (ECCN) 4-Does the component require a specific runtime, like Java Runtime Environment (JRE).

As a key challenge at the studied company, we find that if a developer is uncertain whether the component in a specific version is already approved, he has to use a similar process by entering all the information about the component into the system used for the approval process. This is time-consuming, according to an interviewee from the case study company: "It's very time-consuming to collect all the necessary information to provide the [FLOSS approval] request" -Product owner (user of open source) Usage of FLOSS in Products Whether a FLOSS component and its license are suitable for a company's product also depends on how the product is to be used. At our studied company they distinguish between the following four usage types: 1) on-premise installation on a client's machine; 2) providing services as a cloud solution, aka. software-as-a-service (SaaS); 3) used as a library to be integrated into other products; 4) internal use only. These usage types are not exclusive and can be combined, e.g. the product is provided as a cloud service and is only available for internal use, which increases the complexity of the underlining architectural model.

One interviewee explained that, once a FLOSS component is listed in the catalog of approved components, every developer can use these components in the limits of the usage type. For example, the Microsoft SQL Server (with an on-premises license purchased without software assurance and mobility right) 5can be bundled and shipped with a product, but you're not allowed to use it in a product that is a cloud service (SaaS).

For a different usage type, FLOSS components used in a product that is only for internal use do not have to go through a costly clarification process. This comes with the fact that internally used software is not distributed and as such, there is no need to ensure license compliance.

"You can download everything, but once it goes into the product that's delivered to customer, you have to ask: Can you use it?" -FLOSS compliance manager Custom Reports We found that at our case study company the management demanded reports for their products which included information about the incorporated FLOSS components. This helped track FLOSS assets and assisted in FLOSS risk management.

To provide reports of FLOSS usage in products, license information has to be combined with the architectural documentation of a product. For that, companies develop their own tools which combine all the necessary information from different sources.

One particular challenge here is to keep reliable references between a FLOSS component, their artifacts, and related data. Inconsistencies in these references lead to manual data clean up work. For example, a scan for FLOSS components would identify multiple already known components but couldn't match them with data from a central FLOSS management system.

"This [specific] report tries to figure out where in our vault is the third part component and it matches with my product. Quite often it happens that it doesn't match even if I have provided the very similar and identical source and binaries." -Product owner (user of open source)

A combined model could help simplify the creation of reports and avoid mismatches of components by inconsistent references. SPDX Support SPDX is the defacto standard to exchange license compliance information. This is especially useful within software supply chains, where suppliers are often expected to provide SPDX documents [START_REF] Harutyunyan | Corporate Open Source Governance of Software Supply Chains[END_REF] alongside the delivered software. Many license compliance tools support SPDX as an exchange format for license compliance information and other metadata. Therefore, companies develop custom tools to be able to consume and produce SPDX documents.

At the case study company, we see the benefits of SPDX and integrated support in their toolchain for it. While SPDX standardizes the exchange of license information, a valid SPDX document can lack information and thus not ensure a complete BOM representation. When the studied company required the BOM from a supplier both parties had to agree on how certain information would be stored in the SPDX document.

"But we learnt that SPDX has no clear prescription, what is required, and what's not, to give you, you can do this and that, and we ended up adding a few own fields for those information we think we need." -FLOSS compliance manager A Central System to Manage Products One interview partner reported that they used a central system to manage their products in which they could incorporate all the information needed for reports and license compliance artifacts. While our interview partner saw high value in having a central system, it did not circumvent all the challenges of license compliance. For example, they reported that relationships between components of a product were represented only as simple dependencies. This simplification produced a high-level view on the composition of a product, which was not enough to generate precise reports on the full product architecture.

"[A central system] is for me not enough [. . . ] we have all the data but the relations between things [are insufficient]" -Product manager As described before, data gathering from different tools and systems to feed the central system tends to be error-prone. A central system to manage products often grew over time from a system that was not designed to ensure license compliance in the first place. Therefore, some aspects of license compliance result in costly operations, which constitutes another major challenge we discovered during our case study.

Discussion

The previous section presents five major challenges the analyzed company has regarding their FLOSS component management processes. In the following paragraphs we present the implications of our findings.

Coping with Amount of FLOSS Dependencies One factor that makes the described challenges even more difficult is the sheer quantity of FLOSS dependencies. FLOSS itself is often built on top of other FLOSS, which results in a snowball effect of dependencies. According to a report [START_REF] Pittenger | Open source security analysis: The state of open source security in commercial applications[END_REF] from 2016, the average commercial product 80% of the code comes from FLOSS. Our interview partners also described that the sheer amount of FLOSS in their products leads to a time-consuming FLOSS license compliance process. To cope with the increasing amount of FLOSS dependencies, the aim is to automate the license compliance process as much as possible.

Considering Product Shipping Information Because the architecture documentation was initially not designed with compliance information in mind, it is difficult to deal with FLOSS in products. As described, costly operations are required to collect and maintain license compliance information. Another effect is that the documentation of a product does not represent the actual shipped product. An example of such a divergence is when a product's feature depends on the purchased product key, like a home vs a professional version of a product. While the product is still the same, the shipped version of the product differs in accessible components. More detailed documentation on how a product is used could allow deriving a BOM which only covers all necessary components of the actual shipped product.

Describing Inter-Dependency Relationships We found that products and their dependencies on FLOSS components and infrastructure are represented in a simplified manner. Besides issues on representing a product in its shipped version, FLOSS licenses may have different obligations dependent on how the component is incorporated in a product. For example, the LGPL license family distinguishes between static and dynamic linking for applying the viral copyleft effect. Information about required runtime environments, which also may introduce additional dependencies, are hard to represent next to architectural and license relevant information. Nevertheless, the studied company relies on this information and has to put additional effort into developing and maintaining custom tools to generate accurate reports and artifacts like the BOM.

Existence of an Underlying Conceptual Model Regarding an architectural model, FLOSS license information must be incorporated in an unambiguous fashion. For example, using unique SPDX license identifier instead of unstructured text to describe the declared license. Our previous studies cover the requirements for automation of the FLOSS compliance process, but those requirements are not fulfilled by tools to the extent which is required [START_REF] Harutyunyan | Understanding industry requirements for FLOSS governance tools[END_REF][START_REF] Harutyunyan | Industry requirements for FLOSS governance tools to facilitate the use of open source software in commercial products[END_REF]. An elaborate representation of inter-dependency relationships should be an inherent part of the architectural model. Also, information for shipping the product as mentioned above should be included in this model. The need for automation and the resulting interoperability of tools suggests there is a need for a general underlying conceptual model representing the product. The consensus on such a conceptual model may also help to avoid the development of company-specific tooling solutions.

Limitations

Since we investigated the challenges of FLOSS dependency documentation and tracking in the context of only one company, we do not claim generalizability for the findings. Acknowledging this common limitation of single-case case studies, we were nonetheless able to deeply investigate this emerging research topic identifying five advanced subtopics that went beyond the previous research on FLOSS license compliance and dependencies. Moreover, to mitigate the anticipated limitation, we were careful to choose a representative company with some familiarity of using open source components in products, but limited awareness when it came specifically to FLOSS component tracking and documentation.

Conclusion

To study the emerging issue of tracking FLOSS components and dependencies in software product architectures, we performed a case study in a multinational enterprise software company as part of an industry-academia collaboration project. In this exploratory study, we conducted and analyzed five interviews with key stakeholders of FLOSS component tracking and documentation in the studied company.

We identified the core challenges of managing FLOSS dependencies and their integration with existing product architecture infrastructures within a company context. We discussed in detail the challenges related to the data gathering for the compliance process, FLOSS usage in products, custom reports, SPDX support, and to the centralized system for managing products.

Our study suggests that underlying the various point solutions that we found at this vendor lies a conceptual model that we tentatively call the product (architecture) model. In future cross-vendor work, we will investigate whether this conceptual model can be expanded to become a unifying model for all open source dependency management.

https://projects.eclipse.org/proposals/sw360

https://www.fossology.org

https://softwarecampus.de/

https://www.bis.doc.gov/index.php/licensing/commerce-control-listclassification/export-control-classification-number-eccn

[START_REF] Gandhi | Open data standards for open source software risk management routines: An examination of SPDX[END_REF] https://www.microsoft.com/en-us/licensing/news/updated-licensing-rights-fordedicated-cloud

Acknowledgements We thank Sebastian Schmid for his generous feedback that helped us improve the paper significantly. We also thank our industry partners that provided their valuable time and expertise for this research project. This research was funded by BMBFs (Federal Ministry of Education and Research) Software Campus 2.0 project (OSGOV, 01IS17045).


Luigi Benedicenti
email: luigi.benedicenti@unb.ca

Emotional Contagion in Open Software Collaborations

Keywords: Emotional Contagion, Software Engineering, Open Software, Affect Theory

Emotional contagion is a mechanism by which affect experienced by one person in a group is transmitted to others in the same group. When this happens, the group dynamic is influenced. This paper provides a method to analyze an Open Software project to determine the connection between emotional contagion and software production in such an environment, if any. The project change management database is mined to extract change comments in chronological order and by user id. Sentiment analysis is employed to determine affect in the change originating from each userid. File changes are tracked to link them together in the same areas, using a temporal and file locality principle. The correlation between affect and area is then used to prove or disprove whether or not emotional contagion influences open software production. Although in this paper the proposed method is applied to only one project, the method is general and can be reused for experimental validation.

Introduction

The application of Affect Theory to Software Engineering is becoming relevant in modern software development that involves collaboration [START_REF] Graziotin | Towards a Theory of Affect and Software Developers' Performance[END_REF][START_REF] Graziotin | On the Unhappiness of Software Developers[END_REF][START_REF] Calefato | Affective trust as a predictor of successful collaboration in distributed software projects[END_REF]. This is particularly relevant in environments in which collaboration occurs remotely, because it is a very wellknown fact that online comments allow and sometimes encourage a less respectful engagement. Open Source Systems (OSS) are a particularly apt instance of this trend. One particularly relevant aspect of Affect Theory in the case of OSS is Emotional Contagion. Emotional Contagion occurs when the affect inherent in a behavior, or in the case of online collaboration a message, is shared with others. The emotional content of the message can alter the affect associated with people who read the message, enacting a propagation of affect that resembles the spread of a contagion [START_REF] Graziotin | What happens when software developers are (un)happy[END_REF].

This paper describes a systematic method to analyze an OSS project to determine whether emotional contagion occurs. This method is relevant to validate the hypothesis that emotional contagion occurs in OSS projects, and to determine the point in time when this happens, to create the opportunity to assess how the emotional contagion may be affecting the development process and the quality of its output. The method presented in this paper is sufficiently general to be repeatable, allowing for comparisons and meta-analyses that can quantify the degree of emotional contagion occurrence in OSS and support future analyses and the creation of new development processes.

Previous Work

There is a growing body of work on Affect Theory applied to Software Engineering [START_REF] Graziotin | Towards a Theory of Affect and Software Developers' Performance[END_REF][START_REF] Graziotin | On the Unhappiness of Software Developers[END_REF][START_REF] Calefato | Affective trust as a predictor of successful collaboration in distributed software projects[END_REF]. The research in this area is an attempt to characterize the influence of affect on software production from different points of view. Although initially the work has concentrated on the correlation between affect and productivity or quality, gradually this focus has been expanded to a more holistic approach that involves attributes of the development process, qualities of the artifacts produced, and well-being of the participant in the process [START_REF] Graziotin | What happens when software developers are (un)happy[END_REF]. Some of the more recent focus of such research is in the agile requirements field [START_REF] Ochodek | Perceived importance of agile requirements engineering practices-a survey[END_REF]. Part of the author's own research has focused on optimization of requirements prioritization methods using decision methods to reduce the occurrence of emotional contagion [START_REF] Alhubaishy | Toward a model of emotion influences on agile decision making[END_REF]. In such a knowledge-intensive activity, cognitive trust plays an important role, but so does affective trust, which encompasses the social perspective of trust [START_REF] Calefato | Affective trust as a predictor of successful collaboration in distributed software projects[END_REF].

In distributed OSS development, interactions are more severely limited, as in most cases opportunities for face-to-face meetings and teleconferences are non-existent. All that remains is, at best, a combination of social networks, email lists, and comments in software repositories. In most cases, in fact, software repositories are all that links together each developer.

The constraints imposed by repository-based online interactions in turn limit the opportunities for cognitive trust, as the information on contributors only comes from a single source. However, given that the source contains a number of artifacts and documented interventions, cognitive trust is not severely impaired. On the other hand, affective trust can only be based on the tone of comments in the repository. This limited amount of information can lead to misunderstandings, creating an environment that is ripe for emotional contagion.

Method Workflow

The development of a method to analyze the influence of affect on OSS development, and in particular the presence of emotional contagion, is grounded in a series of principles and assumptions. These principles and assumptions help define the scope of the method, which is important in determining its applicability. The method presented in this paper works under the assumption that face-to-face interactions among developers are severely limited or non-existent. This assumption is paramount to the definition of the data set for the analysis. Therefore, the applicability of this method on teams in, for example, a company, is not considered.

This method also relies on the locality principle, in that the influence of affect in standard working conditions is mitigated by time and by the location of each change. In other words, recent changes to a common artifact have higher impact than changes distributed over several days and artifacts. This is because most emotions and moods change relatively rapidly (over a period of hours) and the sense of ownership for a specific artifact lowers as the developer's focus shifts.

A further assumption is that there exists a repository that contains a documented evolution of the software being produced. An example of such a repository is GitHub [7].

Given these assumptions and principles, it appears reasonable to limit the scope of the method to situations that do not allow direct face-to-face interaction and that involve a relatively large number of developers. OSS development falls within this scope, and is what this paper focuses on.

The method's workflow, therefore, is as follows.

1. Retrieve data from a repository 2. Sort it by locality 3. Evaluate the affective content of the data 4. Determine if episodes of contagion exist Each of these steps is described below. To illustrate the method, we will use an example that will be further discussed in the next section.

Retrieve Data from a Repository

Data retrieval from a repository is a relatively straightforward operation. To keep things as simple as possible, the retrieval makes use of generally available tools like a text editor and a spreadsheet, and adopts general file formats like text and comma-separated values. Even with these simplifications, the data retrieval procedure remains delicate and needs to be checked for accuracy.

The requirements for the choice of a repository is that it contain the information needed to perform an analysis of the affect of a contribution, in a chronological order, and with an indication of the artifacts that have been changed. At a minimum, therefore, the data needed for the analysis is the date of the contribution, the file(s) affected by the contribution, and a comment explaining the contributions made.

Our primary choice for a repository is GitHub [7]. This repository contains all the needed information, is free for most open software development, and it is very popular, although it might not be considered the most advanced software repository currently available. Another advantage is that the software program that allows interaction with the repository, Git, is a free and open source software available on most platforms, has been proven extensively, and is supported by a large community of developers [START_REF]Git homepage[END_REF].

To retrieve the data from the repository, we first clone it on the local machine. After that, we extract the information we need using Git commands. In particular, the log command can be used to obtain all change information with the exception of the files affected. For that, we need to use the diff command. Depending on the next steps, it might be necessary to further process the data into a format that is readable by the analytical tool. In our case, we have processed the data to create a comma-separated value list that is readable by Wolfram Mathematica, our choice of analytical too [START_REF]Wolfram Mathematica homepage[END_REF].

Sort It by Locality

The sorting by locality is accomplished in two ways. The sorting by date is simple, as we can access the change log and sort it accordingly. The sorting by file is a bit more complex, as a change item can encompass multiple files. In this case, we resort to creating an entry for each file, and then sorting them into separate bins, one per file. This results in a set of bins, one per file, each of which is sorted by date.

Evaluate the Affective Content of the Data

To evaluate the affective content of the data we make use of a sentiment analysis classifier. Because Mathematica provides an existing classifier, we adopted it, keeping in mind that this built-in classifier only works for English words. Sentiment Analysis is an effective tool for the determination of affective content, but it has its limitations. Firstly, the classifier comes with a customizable level of confidence. Secondly, it is based on a machine learning algorithm that depends on the level of training that the classifier has received. Thirdly, sentiment analysis only provides an indication of the type of affect in a sentence (Positive, Neutral, or Negative); but not the intensity of the affect.

This can be problematic in many ways. The customizable level of confidence needs to be declared in any analysis to make it repeatable. Further, the use of a preset classifier means that it is not possible to control the type of training the classifier has received. Our reliance on a general-purpose sentiment analysis tool is a restriction of the usefulness of the method, because to make this repeatable we need to ensure that the same classifier is used on every data set.

Additionally, the classifier result is discrete. The provision of an intensity value for sentiment analysis is not available in most tools, which limits the level of refinement of the analysis.

Determine If Episodes of Contagion Exist

Numerous options exist for this determination. The simplest of these options is to generate a series of affect sequences, which are chronological representations of the changes classified by the sentiment analysis tool for a specific file, and then perform a manual inspection of each generated affect sequence.

Other possibilities include more sophisticated analyses, which involve a pattern recognition algorithm to detect a change in affect following a single change comment (i.e., influencing), or even convolutional analysis with kernels designed to highlight emotional contagion.

Our implementation of this stage is to translate the results of the affect sequence into numerical data: -1, 0, and 1 for positive, neutral and negative values respectively, then integrate these numerical sequences over time, and provide a graphical representation that can be further analyzed.

It is important to note, however, that the preceding data collection and processing is fully repeatable, and that should additional algorithms become available, it would be possible to apply the new algorithms to the same data sets without any loss of generality.

Example

The simple example we present in this section exemplifies the steps presented in the previous section. The example has been chosen purposely to make it as simple as possible, rather than as comprehensive as possible. Thus, this example has limited external validity.

Github has a large number of OSS projects. A small but representative one is opencv [10]. This open source computer vision library has received contributions from more than 1,000 contributors and has a change log with more than 27,000 entries. Although not the largest contribution by any means, it is sizeable enough to prove interesting for this example.

To acquire the original data set, we cloned the GitHub library in a local directory on the research machine (an iMac Pro with 64GB of RAM and a 10-core Intel Xeon W processor). We then extracted the information we needed from the repository with a combination of Git commands, an example of which is below (see Fig. 1). Following the extraction, we prepared the data for ingestion by Mathematica, and then loaded it (see Fig. 2). Sentiment analysis and locality can be applied very simply, when the data is already binned; it is then possible to create an affect sequence (see Fig. 3).

git clone https://github.com/opencv/opencv git log --pretty=format:'"%an","%ad","%s","%b"' > ./GitlogFullDataset.csv ��� ��� dataSet = Import["/Users/lbenedic/Documents/test/opencv/GitlogFullDataset.csv", "CSV", "Numeric" → False] The resulting sequence can be integrated and plotted. In Fig. 4, we show the first 500 data points in the affect sequence and highlight a few instances of emotional contagion found in it. The X axis is time, and the Y axis is the emotional accumulation level.

Discussion

There are a number of restrictions that come from the adoption of principles and assumptions detailed in Section 3. These restrictions affect the applicability of the method and its validity.

In terms of applicability, not all repositories are suitable for this kind of analysis. Repositories where work is checked in by a very small group of developers are unsuitable for analysis because the assumption of low cognitive and affective trust is not true. In general, small communities are able to organize much more tightly, which leads to higher levels of cognitive and especially affective trust. This may happen in larger communities too (consider the level of affective trust offered to longstanding community contributors such as Linus Torvalds, for example), but it is much rarer.

As well, repositories where contributors all work in close proximity will not be suitable as the increased level of communication, especially for face-to-face communications, increases the level of affective trust. If this higher level of affective trust is verified, however, these repositories may be used to detect whether a higher level of affective trust changes the occurrences of emotional contagion.

In terms of validity, internal validity greatly depends on the availability of a large number of check-in information, and the ability of the developers to provide clear commentary with some sort of emotional content (either explicit or implied).

The more difficult form of validity, however, is external validity. Results from a single data set have no external validity and can only be representative of the repository they come from. To obtain a degree of external validity, many repetitions will be needed and a common format for the presentation and archival of results will be necessary. If this happens, then a distribution of results will be created that can be representative of a category of software development falling within the scope of this method.

Conclusions

This paper presented a method to determine whether emotional contagion occurs in OSS development. The method relies on the locality principle, and assumes that inperson interactions are limited, and that contributors rely on the comments in the repository to coordinate their work. The method works by analyzing the emotional content of developers comments in code check-ins to repositories. The example provided shows that the method is able to detect patterns in emotional content showing emotional contagion in a specific repository. The method is limited in its scope and validity by the assumptions made in developing it. As well, its external validity cannot be assessed through a single example. Future work includes further streamlining of the data collection, a modified analysis method that relies on interpolated points to perform convolutional analyses in addition to the standard visual inspection, and a better structured manner to integrate the results from each local file bin.

Fig. 1 .

 1 Fig. 1. GitHub commands for data set extraction (Sample).

Fig. 2 .

 2 Fig. 2. Importing the data into Mathematica.

Fig. 3 .

 3 Fig. 3. Sentiment analysis, sorting, and affect sequence creation.

Fig. 4 .

 4 Fig. 4. Affect sequence plot.

  ��� ��� sentimentSet = MapAt[classifyNoThreshold, dataSetWithDate, {All, {3, 4}}]

		Alexander Alekhin,	Fri 7 Feb 2020 11:22:23 GMT-4. , Negative, Positive ,
		Alexander Alekhin,	Thu 6 Feb 2020 13:38:21 GMT-4. , Neutral, Positive , ⋯ 27 974 ⋯ ,
	���� ��
		Vadim Pisarevsky,	Tue 11 May 2010 17:44:00 GMT-4. , Negative, Positive
		����� ������	���� ����	���� ����	���� ���	��� ���� ��������
	��� ��� sortedByDateSet = Sort[sentimentSet, #1[[2]] < #2[[2]] &]
		Vadim Pisarevsky,	Tue 11 May 2010 17:44:00 GMT-4. , Negative, Positive ,
		Vadim Pisarevsky,	Wed 12 May 2010 07:33:21 GMT-4. , Negative, Positive ,
	���� ��
		⋯ 27 974 ⋯ , Alexander Alekhin,	Fri 7 Feb 2020 11:22:23 GMT-4. , Negative, Positive
		����� ������	���� ����	���� ����	���� ���	��� ���� ��������
	��� ��� emotionToNumber[z_] := z /. {"Negative" → -1, "Neutral" → 0, "Positive" → 1}
	��� ��� sortedEmotionNumberSet = MapAt[emotionToNumber, sortedByDateSet, {All, {3, 4}}]
		Vadim Pisarevsky,	Tue 11 May 2010 17:44:00 GMT-4. , -1, 1 ,
		Vadim Pisarevsky,	Wed 12 May 2010 07:33:21 GMT-4. , -1, 1 , ⋯ 27 973 ⋯ ,
	���� ��	Talamanov, Anatoliy,	Thu 6 Feb 2020 18:12:38 GMT-4. , -1, 1 ,
		Alexander Alekhin,	Fri 7 Feb 2020 11:22:23 GMT-4. , -1, 1
		����� ������	���� ����	���� ����	���� ���	��� ���� ��������
			100			200	300	400	500
		-20
		-40
		-60
		-80
		-100