R Zapata
email: zapata@lirmm.fr

A Sánchez

P Lepinay

A Biologically-Plausible Approach for Mobile Robot Path Planing: The Virtual Lightning Approach

Keywords: Path planning, navigation, collision avoidance, biologically inspired systems

This paper deals with the path planning problem of mobile robots involving in partially known or unknown environments. We describe a biologicallyplausible approach of this problem based on the definition of virtual top view images, obtained by the transformation of real frontal images (visual images or proximetric images).

Introduction

Automatic motion planning deals with finding a feasible sequence of motions to take movable object (the 'robot') from a given initial configuration to some specified goal configuration. Research in path planning for robots has traditionally been focused on finding ways to ensure that a fixed arm will not collide with objects in its workspace as it performs its tasks. However, to be truly flexible, manipulators are mounted upon mobile platforms, giving them not just the ability to manipulate objects in a fixed region, but to interact with their environment in more complex ways, much as humans do. The reigning paradigm of path planning has been the piano movers problem, which concerns moving an object through a set of obstacles without any constraints on the type of movements which can be made. But mobile robots are likely to be based upon carts with wheels for steering and locomotion.

To date, motion planning approaches can be classified into three categories [START_REF] Latombe | Robot motion planning[END_REF]: 1) Roadmap methods, 2) Cell decomposition methods, and 3) Potential field methods.

The roadmap approach (or skeleton approach) consists of capturing the connectivity of the robot free configuration space (C f ) in the form of a network of one -dimensional curves -the roadmap-lying in C f . After a roadmap ρ has been constructed, the path planning is reduced to connecting the start and goal configurations to ρ, and searching ρ for a path. Algorithms based on the visibility graph, the voronoï diagram, and the silhouette (projection of obstacle boundaries) are examples of the roadmap approach. In the cell decomposition approach the free space is represented as a union of cells, and a sequence of cells comprises a solution path. For efficiency, hierarchical trees, e.g., octree, are often used. In the potential field approach, a scalar potential function that has high values near obstacles and the global minimum at the goal is constructed, and the robot moves in the direction of the negative gradient of the potential.

The aim of this paper is to propose a biologicallyplausible approach to path planning. By these words, we mean the replacement of symbolic or geometric representation of the world by "imaged" representations, and then use these virtual images as basis for the pre-execution of the future motion [START_REF] Berthoz | Le sens du mouvement, Editions Odile Jacob [The Brain's sense of movement[END_REF]. This paper is organized as follows. Section 2 described the Virtual Lightning Approach (VLA). This algorithm allows to obtain safe trajectories for a polygonal holonomic robot and the extension to nonholonomic mobile robot is discussed. In the Section 3, we briefly present control motion, i.e., the problem of coupling VLA algorithm with a reactive controller based on the Deformable Virtual Zone Approach (DVZ). Section 4 present experimental considerations and particularly we describe several simulations that prove the potentiality of our approach.

The Virtual Lightning Approach

Morphological methods in artificial vision

Briefly speaking, the vast subject of mathematical morphology [START_REF] Serra | Cours de Morphologie Mathématique[END_REF][START_REF]Mathematical Morphology and its Applications to Image Processing[END_REF]

Extension to path planning

We have extended this approach of image processing to mobile robot path planning and we have proposed an algorithm by implementing mathematical mor-phology somehow "biologically-inspired", and this, along 3 paradigms:

• P1: There is no abstract, nor symbolic nor geometric modeling of the environment in which the robot evolves. The environment representation is a binary image (a top view virtual image) of the world.

• P2: The path planning process is a multi modal simulation of the motion to be carried out by the robot.

• P3: There is a "natural" bridge between the real frontal perception of the world (obtained for instance through distance sensors), and the virtual top view image.

Furthermore, one of the main advantages of this algorithm is to be very fast, property which also could be seen as a biologically plausible result.

The main algorithm (The Virtual Lightning Approach)

In order to describe the main algorithm, we assume that the mobile is a holonomic point robot, and can sense its environment (it perceives distances field in several directions of its space). We will describe the main algorithm (VLA) in 2 steps: moving in a known environment and moving in an unknown one.

1) Moving in a known environment (P1 and P2) This environment is described as a binary image (a bitmap) I which the ones (1's) represent various obstacles and the zeros (0's) the free space in which the robot can move. In the same image, the potential virtual trajectories are also represented as a set P (of pixels) of value l i > 1(one index i for each trajectory). The initial value P 0 of P is the initial configuration S of the robot. At each time step, the robot dilates P in direction of the final configuration G(goal), transforming the virtual image I∪P t into I ∪ P t+1 , where P t+1 is the dilated of P t . In other words, the robot creates an initial "virtual lightning" issued from P 0 and consisting of a set of pixels of value L 0 > 1"moving" towards the goal.

Unfortunately, this initial virtual lightning can meet obstacles. In this case, it separates in two, creating two secondary virtual lightnings (of the values 10l 0 and 10l 0 + 1, respectively) which are dilated parallel to the obstacle until they can move again in the free space (and are therefore dilated toward the goal).

At each collision between a Virtual Lightning and an obstacle, there is a creation of two Virtual Lightnings (of the values 10l i and 10l i + 1, respectively), and so on. At the end of the process, the image has been augmented by a set of pixels of value l j > 1, representing all the lightnings.

2) Moving in an unknown environment(P3).

In this case, the robot builds the environment representation I during its motion.

At time 0, I 0 is initialized at 0 (black image). At each time step t, each distance measured by its proximity sensors is transformed into a pixel of value 1, providing an image S t and the image i t is obtained by the union of the morphological dilatation of S t with the structuring element

B =   1 1 1 1 1 1 1 1 1   and I t-1
. Therefore, we have:

I t = I t-1 ∪ S t .
The robot generates its virtual lightnings in this partial image, moves in this partially known environment and continues, building and incrementing its environment.

The filtering algorithm

At the end of the Virtual Lightning generation process (one of them has reach the goal), the robot enters in the filtering stage consisting in keeping only the successful lightning. This operation is done by "thresholding" the image P end with the sequence of threshold values a 1 = l end , a 2 = floor(l end /10), a 3 = floor(a 2 /10), • • •. Afterwards, it is possible to optimize the process by smoothing the obtained trajectory. This is done by choosing the more distant point M from the successful virtual lightning and running again the process between S and M and between M and G. At this stage, only stays a filtered Virtual Lightning, as an image V mainly composed of 0's and which pixels of value 1's represent the trajectory between S and G.

Trajectory parameterization

The longest process in this approach consists in transforming the image V in a sequence of positions. This is done by the parameterization of V . This process is again based on mathematical morphology. In a first stage, V is slightly dilated in order to ensure its perfect connection (to fill small holes appearing during the VLA phase). In a second stage, the connected components of V (only one here) is extracted. This operation is based on an iterative use of morphological dilatation, starting from S. At each iteration, the difference between the connected component at time t and the connected component at time t -1, allows a parameterization of the set of pixels.

Extension to holonomic non punctual robots

The extension to non punctual robots is a very easy process. Actually, the dilatation operation can simply take into account the size of the robot. In the main algorithm (VLA), the structuring element B can be increased in size to prevent the robot from colliding. This is the same kind of process that is used in cell decomposition methods or in roadmap methods. The transformation of the real robot space into the configuration space is done while taking into account this robot size.

Extension to real robots: The virtual corridor

A common there for many nonholonomic path planning approaches is to divide the problem into two stages. In the first stage, a holonomic planning method is used by producing a collision-free path that ignores the nonholonomic constraints. In the second stage, an iterative method attempts to replace portions of the holonomic path with portions that satisfy the non-holonomic constraints (for example Reeds & Shepp shortest paths [START_REF] Reeds | Optimal paths for a car that goes both forwards and backwards[END_REF]), yet still avoid obstacles. We describe this approach for the case of a car-like robot.

Car-like behavior is described by the following differential system: Assume that a fast holonomic planning method has been selected for the first stage. Suppose that a path τ : [0, 1] → C f has been computed. The path can be iteratively improved as follows. Randomly select two real numbers ξ 1 ∈ [0, 1] and ξ 2 ∈ [0, 1]. Assuming ξ 2 > ξ 1 , attempt to replace the portion of τ from τ (ξ 1 ) to τ (ξ 2 ) with a path segment that satisfies the nonholonomic constraints. This implies that τ is broken into three segments,

   ẋ = cos θ • u 1 ẏ = sin θ • u 1 θ = 1 R • u 2 (
τ 1 : [0, ξ 1 ] → C f , τ 2 : [ξ 1 , ξ 2 ] → C f , τ 3 : [ξ 2 , 1] → C f . Note that τ 1 (ξ 1 ) = τ 2 (ξ 1
) and τ 2 (ξ 2 ) = τ 3 (ξ 2 ). The portions τ 1 and τ 3 remain fixed, but τ 2 is replaced with a new path, τ : [ξ 1 , ξ 2 ] → C f ,that satisfies the nonholonomic constraints. τ must also avoid collisions, τ (ξ 1 ) = τ 1 (ξ 1 ), and τ (ξ 2 ) = τ 3 (ξ 2 ). This procedure can be iterated multiple times until eventually, the original path is completely transformed into a nonholonomic path. The completeness of the algorithm only depends on the completeness of the geometric planner that computes a first collision-free path.

The combination of this transformation of holonomic trajectories to non holonomic ones and of the VLA approach is very easy. At the end of the parameterization phase, the trajectory can be dilated by a substantial structuring element (B= I 25×25 for instance) and from the resulting image is subtracted I. The result, is an image of a collision free corridor (the virtual corridor) in which the holonomic trajectory is transformed in a nonholonomic one.

3 The Control Motion

The control of reactive actions

In previous papers [START_REF] Zapata | A biologically-plausible vision system for controlling mobile robots[END_REF][START_REF] Zapata | Collision avoidance of a 3D simulated flying robot[END_REF], we have defined an algorithm for controlling mobile robots evolving in unknown environments, the Deformable Virtual Zone (DVZ). Let summarize here the principles of this method : the DVZ Ξ represents a deformable zone whose geometry characterizes the interaction between the robot and its environment. The DVZ is the sum of 2 terms:

Ξ = Ξ h + ∆ (2)
where Ξ h is an undeformed protecting zone and ∆ represents a deformation of Ξ h due to the intrusion information in the robot space (denoted by I and sensed by distance sensors).

The undeformed zone depends on a vector π characterizing the motion capabilities of the robot (its translational and rotational velocities for instance):

Ξ h = ρ(π) ( 3 )
The deformation ∆ depends on the intrusion of proximity information and on the undeformed DVZ:

∆ = α(Ξ h , I) ( 4 )
By differentiating equations ( 2) and ( 3) with respect to time, we get:

∆ = ∇ Ξ h α [∇ π ρ] + [∇ I α]ψ (5)
∇ ζ is the derivation operator with respect to the variable ζ and where

φ = ∇ t π = π ψ = ∇ t I = İ
The evolution of ∆ is driven by a 2-fold input vector u = [φ ψ] T . The first control vector φ tends to minimize the deformation of the DVZ. The second one, ψ, is induced by the environment itself (and could, at most, try to maximize these deformations).

Therefore, the complete evolution of the deformation ∆ is modeled by a differential equation of the type:

∆ = A φ + B ψ (6)
The control algorithm consists in choosing the desired evolution of this deformation ∇ = ∆des . A simple and efficient control law is to choose this desired deformation as proportional to the real deformation and its derivative (Proportional and Derivative gains):

∇ = -M ∆ -N ∆ ( 7 )
where the two matrices M and N , are heuristically tuned in order to carry out the avoidance task. The control vector at time t is then defined by inverting equation ( 5) after replacing the derivative of the deformation ∆ by the desired evolution ∇:

φ = A • (∇ -B ψ) ( 8 )
where A • is the pseudo-inverse of A, and is the previous measured uncontrolled control vector (due to the intrusion of information at time t -1 and depending on the unknown behavior of the environment). This control law tends to minimize the function ∇-∆ 2 .

A vision-based stereo-matching algorithm consisting in a spatial stereo-matching of characteristics points of two images (obtained by a left and a right cameras) allows us to get the distance field in the robot front-space and therefore to build the DVZ [START_REF] Torres | Codesign of a vision-based collision avoidance autonomous system[END_REF].

Coupling the VLA and the DVZ

As an alternative of transforming the holonomic trajectory into a non holonomic one, we can easily couple the DVZ approach of reflex actions to the VLA algorithm. Actually, once the parameterized trajectory has been computed and the virtual corridor been generated, it is possible to run the DVZ from one parameterized point to another and to limit the DVZ protecting zone to the virtual corridor. Therefore, the reflex action will be trigged up if and only if unscheduled obstacles appear in the robot environment.

Experimentations

Real experiments

The DVZ approach for controlling reactive behaviors of a mobile robot has been tested on several robots (mobile wheeled vehicles, AUVs, walking robots).

In the future, this will be tested on a car-like small robot equipped with a stereovision system. The idea, is first to use the couple of images obtained by the left and right cameras in order to build the distance field of the front space robot (for collision avoidance purpose) and second to transform the real images into a virtual top view image (for path planning purposes). However, several simulated experiments have been carried out.

Simulation results

1) Context

The VLA algorithm has been experimented in simulation with a holonomic polygonal robot. The experiments have been carried out on a PC Pentium IV computer at 1.7GHz. The software has been developed with MATLAB 6.1. The robot environment is a 10m square room . The obstacles are 25cm thick walls. The different stages of the VLA algorithm are illustrated with different figures.

2) First experiment

One room, 3 walls. The robot world is a priori known. Figure 4 shows the robot in its environment.

Figure 5 shows the corresponding virtual image and the 2 lightnings that have been generated by the algorithm. Figure 6 shows the virtual image P end . Figure 7 shows the ultimate filtering providing the trajectory V . Figure 8 shows the virtual corridor minus the obstacles. Figure 9 shows the parameterized trajectory. Here, we have chosen to parameterize this trajectory with ten intermediate positions.

Next table shows the performance data for this experiment. Figure 9: The parameterized trajectory.

3) Second experiment

This time we assume that the environment is a priori unknown. In the same world, the robot runs 7 times from different start positions (S) toward the same final position (G) and builds its virtual image, using 32 ultrasonic sensors scanning the whole robot space. See Figures 10 to 17

4) Third experiment

This time, the robot encounters a known complex environment (see figures 18 to 22). Next Table shows the performance data for this experiment.

Conclusion and Perspectives

This paper has presented several aspects of the realization of a biologically-based path planner based on mathematical morphology. This investigation is in development, but the simulations that we have obtained allow us to foresee the applicability of this approach to real mobile robots evolving in partially known environments. The VLA algorithm will be tested in the future on a car-like robot equipped with a stereovision system, and coupled with a collision avoidance algorithm able to generate reactive behaviors in a completely unknown environment. The idea, is to use the couple of images obtained by the left and right cameras in order to build the distance field of the front space robot (for collision avoidance purpose) and second to transform the real images into a virtual top view image (for path planning purposes).

  deals with the application settheory for image processing. Numerous topics go from image enhancement to region labelling through parameters and pattern extraction. Mathematical morphology uses two main operations on binary images: dilatation and erosion. Dilatation of a binary image I by a "moving" structuring binary element B consists in determining the set of image points (center of B) such that it exists a non empty intersection with I. Erosion of a binary image I by a "moving" structuring binary element B consists in determining the set of image points (center of B) such that B is included in I. For instance, the dilatation of the image of Figure 1 by the structuring element B = represented in Figure 2. Its erosion by the same structuring element gives the image represented in Figure 3.

Figure 1 :

 1 Figure 1: Original image I.

Figure 2 :

 2 Figure 2: Dilatation of image I by B.

Figure 3 :

 3 Figure 3: Erosion of image I by B

1 )

 1 with |u 1 (t)| = 1 and |u 1 (t)| ≤ 1, where u 1 and u 2 /R are respectively the linear and angular velocity of the car. The study of the shortest paths for a car-like robot has an history. It has first been addressed without considering the presence of any obstacle. The pioneering result has been achieved by Dubins who characterized the shape of the shortest paths when u 1 ≡ 1 (the robot moves always forward). More recently, Reeds and Shepp have provided a sufficient family of 48 shortest paths for the car-like robot moving forward and backward (|u1| ≡ 1). Shortest paths for Dubin's car are a finite sequence of at most 3 pieces consisting of straight line segments or arcs of circle with radius 1. Optimal paths for Reeds & Shepp's car are constituted by a finite sequence of at most five elementary pieces which are either straight line segments or arcs of a circle of radius 1.

Figure 4 :

 4 Figure 4: Original environment.

Figure 5 :

 5 Figure 5: The virtual image.

Figure 6 :

 6 Figure 6: The resulting lightnings.

Figure 7 :

 7 Figure 7: The trajectory V .

Figure 8 :

 8 Figure 8: The virtual corridor.

  .

Figure 10 :

 10 Figure 10: Original environment and sensor information.

Figure 11 :

 11 Figure 11: The virtual image at step 1.

Figure 12 :

 12 Figure 12: The virtual image at step 2.

Figure 13 :

 13 Figure 13: The virtual image at step 3.

Figure 14 :

 14 Figure 14: The virtual image at step 4.

Figure 15 :

 15 Figure 15: The virtual image at step 5.

Figure 16 :

 16 Figure 16: The virtual image at step 6.

Figure 17 :

 17 Figure 17: The virtual image at step 7.

Figure 18 :Figure 19 :

 1819 Figure 18: Initial and final position.

Figure 20 :

 20 Figure 20: The virtual lightnings.

Figure 21 :

 21 Figure 21: The parameterized trajectory.

Figure 22 :

 22 Figure 22: The virtual corridor.

Acknowledgments This paper and the correlated work are partially funded by the Franco-Mexican project M01M01 (Comité ECOS-Nord), and by the French project Psikharpax (appel d'offres ROBEA 2001).


Courtney Miller
email: courtney.miller17@ncf.edu

David Gray Widder

Christian Kästner
email: kaestner@cmu.edu

Bogdan Vasilescu
email: vasilescu@cmu.edu

Why do People Give Up FLOSSing? A Study of Contributor Disengagement in Open Source

Established contributors are the backbone of many free/libre open source software (FLOSS) projects. Previous research has shown that it is critically important for projects to retain contributors and it has also revealed the motivations behind why contributors choose to participate in FLOSS in the first place. However, there has been limited research done on the reasons why established contributors disengage, and factors (on an individual and project level) that predict their disengagement. In this paper, we conduct a mixed-methods empirical study, combining surveys and survival modeling, to identify the reasons and predictive factors behind established contributor disengagement. We find that different groups of established contributors tend to disengage for different reasons; however, overall contributors most commonly cite some kind of transition (e.g., switching jobs or leaving academia). We also find that factors such as the popularity of the projects a contributor works on, whether they have experienced a transition, when they work, and how much they work are all factors that can be used to predict their disengagement from open source.

Introduction

Contributor disengagement in open source is widely known as a costly and critical issue [START_REF] Coelho | Why modern open source projects fail[END_REF][START_REF] Fang | Understanding sustained participation in open source software projects[END_REF][START_REF] Pratyush | Examining turnover in open source software projects using logistic hierarchical linear modeling approach[END_REF], as it can directly affect the sustainability of projects. For example, in a recent study Coelho et al. reported that 41 % of failed open source projects cited a reason involving the developer team, such as lack of interest or time of the main contributor [START_REF] Coelho | Why modern open source projects fail[END_REF]. Such local (project-level) sustainability issues in open source can have cascading effects on the entire ecosystem because of project interdependencies [START_REF] Constantinou | Socio-technical evolution of the Ruby ecosystem in GitHub[END_REF][START_REF] Valiev | Ecosystem-level determinants of sustained activity in open-source projects: A case study of the PyPI ecosystem[END_REF]. So-called "core", i.e., established, contributors are particularly critical for the sustainability of open source projects [START_REF] Fang | Understanding sustained participation in open source software projects[END_REF][START_REF] Zhou | Developer fluency: Achieving true mastery in software projects[END_REF].

There are many reasons why established contributors disengage. Some may be unavoidable, whereas others could perhaps be prevented through interventions or by providing better community support. Likely there are various dynamics in play, including the role of volunteers as compared to corporate employees [START_REF] Jeffrey A Roberts | Understanding the motivations, participation, and performance of open source software developers: A longitudinal study of the Apache projects[END_REF], the role of external events such as family planning and job changes, and the role of perceived purpose, community support, and stress. Effects might include abruptly leaving the project, but also slow disengagement, or causing rippling frustrations through delays or cynicism.

The goal of our research is to better understand disengagement factors and which established contributors are at risk and when; this will enable us to build and validate a Part of this work was carried our during the author's REU program at CMU. conceptual framework and theory. Moreover, we pursue a data-driven approach, operationalizing uncovered factors based on publicly available trace data. This way, we can identify at-risk open source contributors and communities, and help guide resources (e.g., volunteers, sponsors) toward projects and contributors in need, enhancing the sustainability of the overall ecosystem.

We identify potential disengagement factors from literature on turnover and open source retention, cross-validate them with results from a survey among contributors who recently stopped all open source activities on GitHub, operationalize select factors with public trace data, and finally conduct survival modeling among a set of 206 GitHub users to triangulate the survey results.

Among others, we identify the degree to which contributors work outside of typical office hours and to what degree they engage in support activities as important moderating factors. According to Claes et al. [START_REF] Claes | Do programmers work at night or during the weekend?[END_REF], 33 % of open source contributors do not follow typical working hours, but instead work nights and weekends. Our survey shows that contributors who work nights and weekends proportionally tend to disengage for different reasons than those working regular hours. In addition, our survey reveals that the most common reasons for complete disengagement relate to transitions in employment, such as graduating from academia, changing employers, and changing roles.

To validate disengagement factors beyond our survey, we model to what degree hypothesized factors-such as working hours, engagement in support activities, and team size, which can be measured in public trace data of contributor activities-can predict the later disengagement of those contributors. To that end, we use the quantitative statistical method of survival modeling. As a key factor in our model, derived from our survey results, we incorporate transitions identified from public CVs of developers. Specifically, we analyze which contributor populations are more resilient to transitions such as job changes.

We find that working predominantly during office hours and experiencing a transition both increase a contributors risk of disengagement. Conversely, we find that increased levels of activity and working on more popular projects both decrease a contributors risk of disengagement.

In summary, we contribute (1) a survey revealing the reasons behind contributor disengagement; (2) a comparison between different groups of contributors; (3) measures to differentiate between groups, which could be used to help identify at-risk groups and better target support interventions; (4) a novel operationalization of transition data; and (5) a survival model demonstrating which factors are able to predict contributor disengagement.

Related work

Turnover. Prior work has shown that the turnover rate of a project profoundly affects its survival probability [START_REF] Izquierdo-Cortazar | Using software archaeology to measure knowledge loss in software projects due to developer turnover[END_REF][START_REF] Schilling | Who will remain? an evaluation of actual person-job and person-team fit to predict developer retention in FLOSS projects[END_REF] and code quality [START_REF] Foucault | Impact of developer turnover on quality in open-source software[END_REF]. Approximately 80 % of open source projects fail due to contributor turnover related issues [START_REF] Schilling | Who will remain? an evaluation of actual person-job and person-team fit to predict developer retention in FLOSS projects[END_REF]. Even within projects that do not outright fail, contributor turnover has a significant adverse effect on software quality [START_REF] Foucault | Impact of developer turnover on quality in open-source software[END_REF]. On a project level, contributor disengagement results in knowledge loss, which is a particularly expensive issue [START_REF] Izquierdo-Cortazar | Using software archaeology to measure knowledge loss in software projects due to developer turnover[END_REF].

Employee turnover and retention have been broadly studied across many fields [START_REF] Peter W Hom | One hundred years of employee turnover theory and research[END_REF][START_REF] Kim | A meta-analysis of turnover intention predictors among us child welfare workers[END_REF]. In professional settings, early turnover research has focused often on personal characteristics (e.g., ability, age) and employee satisfaction, measured with hiring tests and surveys, whereas later research has explored many more nuanced factors, such as labor market (e.g., job opportunities), non-work values, and organizational commitment [START_REF] Peter W Hom | One hundred years of employee turnover theory and research[END_REF]. Research has shown that, while far from all turnover can be explained by dissatisfaction and similar factors [START_REF] Thomas | An alternative approach: The unfolding model of voluntary employee turnover[END_REF], there are positive and negative factors that can buffer against shocks such as external job offers [START_REF] James P Burton | The buffering effects of job embeddedness on negative shocks[END_REF][START_REF] Daniel | Careers: Mobility, embeddedness, and success[END_REF]. Turnover among volunteers is less explored: Although some research suggests that similar personal and environmental factors influence their decisions to quit [START_REF] Miller | Determinants of turnover among volunteers[END_REF], other researchers point out that satisfaction and achievement, compatible working hours, training, challenging work, and role identity may play particularly strong roles [START_REF] Gidron | Predictors of retention and turnover among service volunteer workers[END_REF][START_REF] Browne | Turnover and retention among volunteers in human service agencies[END_REF][START_REF] Galiette | Do not forget about your volunteers: A qualitative analysis of factors influencing volunteer turnover[END_REF].

Whereas reasons for joining open source [START_REF] Bonaccorsi | Comparing motivations of individual programmers and firms to take part in the open source movement: From community to business[END_REF][START_REF] Rishab A Ghosh | Free/libre and open source software: Survey and study -part 4: Survey of developers[END_REF][START_REF] Lakhani | Why hackers do what they do: Understanding motivation and effort in free/open source software projects[END_REF][START_REF] Jeffrey A Roberts | Understanding the motivations, participation, and performance of open source software developers: A longitudinal study of the Apache projects[END_REF][START_REF] Sonali | Motivation, governance, and the viability of hybrid forms in open source software development[END_REF][START_REF] Von Krogh | Carrots and rainbows: Motivation and social practice in open source software development[END_REF][START_REF] West | Challenges of open innovation: the paradox of firm investment in open-source software[END_REF] and interventions to improve the onboarding experience for new developers [START_REF] Canfora | Who is going to mentor newcomers in open source projects?[END_REF][START_REF] Fagerholm | Onboarding in open source projects[END_REF][START_REF] Hannebauer | On the relationship between newcomer motivations and contribution barriers in open source projects[END_REF][START_REF] Steinmacher | Social barriers faced by newcomers placing their first contribution in open source software projects[END_REF] have been studied in depth, studies of contributor retention are rarer. Prior research has focused primarily on testing basic attributes [START_REF] Constantinou | An empirical comparison of developer retention in the rubygems and npm software ecosystems[END_REF][START_REF] Lin | Developer turnover in global, industrial open source projects: Insights from applying survival analysis[END_REF][START_REF] Midha | Retention and quality in open source software projects[END_REF][START_REF] Schilling | Who will remain? an evaluation of actual person-job and person-team fit to predict developer retention in FLOSS projects[END_REF][START_REF] Pratyush | Examining turnover in open source software projects using logistic hierarchical linear modeling approach[END_REF][START_REF] Valiev | Ecosystem-level determinants of sustained activity in open-source projects: A case study of the PyPI ecosystem[END_REF][START_REF] Zhou | Inflow and retention in OSS communities with commercial involvement: A case study of three hybrid projects[END_REF] . For example, they have shown that retention is higher for contributors that have participated longer [START_REF] Lin | Developer turnover in global, industrial open source projects: Insights from applying survival analysis[END_REF][START_REF] Pratyush | Examining turnover in open source software projects using logistic hierarchical linear modeling approach[END_REF], contributed more code changes [START_REF] Constantinou | An empirical comparison of developer retention in the rubygems and npm software ecosystems[END_REF][START_REF] Lin | Developer turnover in global, industrial open source projects: Insights from applying survival analysis[END_REF], and communicated more [START_REF] Constantinou | An empirical comparison of developer retention in the rubygems and npm software ecosystems[END_REF]. However, there has been a limited amount of prior research has also explored more nuanced factors, like whether a developers gender and social network effect their risk of disengagement [START_REF] Huilian | Going farther together: The impact of social capital on sustained participation in open source[END_REF]. Using surveys, researchers further associated ratings of general dissatisfaction and lack of community identification with higher perceived turnover and turnover intentions [START_REF] Homscheid | Between organization and community: Investigating turnover intention factors of firm-sponsored open source software developers[END_REF][START_REF] Yu | An empirical study of volunteer members' perceived turnover in open source software projects[END_REF]. Zhou et al.'s case study of three projects further suggests that commercial participation can crowd out volunteers [START_REF] Zhou | Inflow and retention in OSS communities with commercial involvement: A case study of three hybrid projects[END_REF].

Long working hours, lack of sleep, and lack of recovery on weekends are often discussed as stressors. Many studies confirm the importance of "mentally switching off" [START_REF] Bannai | The association between long working hours and health: a systematic review of epidemiological evidence[END_REF][START_REF] Binnewies | Recovery during the weekend and fluctuations in weekly job performance: A week-level study examining intra-individual relationships[END_REF][START_REF] Sonnentag | Staying well and engaged when demands are high: The role of psychological detachment[END_REF]. In software engineering, several studies have shown the influence of time-related factors, such as late-night commits and long working sessions being more likely to contain bugs [START_REF] Eyolfson | Do time of day and developer experience affect commit bugginess[END_REF][START_REF] Rodriguez | Empirical study on the relationship between developers working habits and efficiency[END_REF], sleep deprivation reducing code quality [START_REF] Fucci | Need for sleep: the impact of a night of sleep deprivation on novice developers' performance[END_REF], Monday commit comments using more negative language [START_REF] Guzman | Sentiment analysis of commit comments in github: an empirical study[END_REF], and time pressure is often seen as an important stressor [START_REF] Kuutila | Reviewing literature on time pressure in software engineering and related professions: Computer assisted interdisciplinary literature review[END_REF].

Open source practitioners reporting stress. In addition to the academic literature, open source practitioners also spoke out about frustrations, funding concerns, stress, and even burnout. Often, there are high expectations and copious amounts of pressure placed on established open source contributors.

Many stories via blog posts from maintainers who disengaged have a similar narrative that describes the growing pressures and responsibilities they experienced that lead to their disengagement. One such blog post describes how "as [my project's] popularity rose and rose, my drive to continue to create new projects, fell. All while the burden of supporting the needs of the massive user bases of my successful projects and the pressure of maintaining those projects grew." 1In addition to blog posts, there were also participants from the survey we ran who explicitly cited a lack of support as a reason for their disengagement. For example "[The open source project] is increasingly depended upon by other projects, but very few external developers are interested/willing enough to [understand the company] let alone contribute improvements/fixes. The support burden is a good problem to have (people are finding [the project] useful), but it does impose a productivity (and sometimes a motivation) burden." (P35)

Contributors are broadly expected to maintain their projects. Having a seemingly never-ending list of tasks is another commonly cited reason for disengagement among the aforementioned blog posts and survey respondents. As described in a blog post by a now-retired developer, "working long hours for endless months" was a critical reason for their disengagement. 23 Overview: Mixed-Method Research

Our mixed-method empirical study follows a sequential exploratory design [START_REF] Creswell | Designing and conducting mixed methods research[END_REF], combining qualitative and quantitative analysis of survey and GitHub trace data.

Step 1: Survey (Sec. 4). Although the turnover literature (Sec. 2) provides several starting points for potential disengagement factors, there has been only limited research on the actual reasons why open source contributors disengage. Therefore, we decided to ground our research by conducting an open-ended survey among developer who recently disengaged from all public GitHub activities. We furthermore analyze the frequency of self-reported reasons for disengagement regarding whether different populations disengage for different reasons.

Step 2: Survival analysis (Sec. 5). We test to what degree the potential disengagement factors identified statistically explain disengagement. To that end, we operationalize several disengagement factors, including when and what contributors worked on as well as job transitions in historic trace data and public CVs, and use survival modeling [START_REF] Rupert | Survival analysis[END_REF] to test their significance.

4 Self-Reported Reasons for Disengagement (Survey)

Survey Methodology

To ground our analyses, we surveyed a sample of open source contributors who recently disengaged from all public GitHub activities, asking about their reasons.

Recently Disengaged Established Contributors. We invited open source contributors who stopped all public activity on GitHub after being active for at least 18 month. We identified such contributors from GHTorrent [START_REF] Gousios | The GHTorent dataset and tool suite[END_REF] trace data (version 2018-08). We then constructed six-month panels aggregating contributions (commits and issue/pull request events) per person, and selected those contributors who contributed at least 100 commits per six-month period for three consecutive periods, but at most 5 commits in the following period (the five commit threshold allows for some residual activity). This way, we identified a total of 702 contributors who disengaged (i.e., stopped contributing publicly) within the last year and had public email addresses listed on their GitHub profile pages.

We specifically sampled only previously active contributors with at least 100 commits per period across all of GitHub. Previous research has shown that within a single project, there are many different kinds of contributors, with one of the most popular models being the onion model [START_REF] Crowston | Effective work practices for software engineering: free/libre open source software development[END_REF]. With our threshold we target contributors who are likely very active in at least one project, rather than more peripheral or episodic contributors, which may have different motivations [START_REF] Barcomb | Uncovering the periphery: A qualitative survey of episodic volunteering in free/libre and open source software communities[END_REF].

Survey Design. We designed a simple, single-question, open-ended survey, asking "Could you help us understand your reasons for reducing your contributions to GitHub projects?"

We chose the open-ended format to avoid priming the participants to ensure organic but relevant responses. We use the single-question format without external survey software, because it reduces the barrier to participation. We invited all 702 identified candidates and received 151 valid answers (21.5 % response rate). Our response rate is in line with other GitHub surveys, e.g., [START_REF] Gousios | Work practices and challenges in pull-based development: the integrator's perspective[END_REF].

Card Sorting Analysis. We used card sorting, a qualitative content analysis [START_REF] Schreier | Qualitative content analysis in practice[END_REF] method, to analyze the survey answers. Two researchers reviewed the cards and organized them into mutually agreed upon categories using a ground-up process resulting in 17 subgroups. These subgroups were then further grouped into three overarching themes: Technical, Social, and Occupational. Note that many participants cited multiple reasons, resulting in 239 reasons from 151 responses.

Quantitative Analysis. In addition to identifying common self-reported reasons for disengagement from the survey responses, we additionally explore whether different populations report different reasons. Based on the literature and reports from open source practitioners (cf. Sec 2), we specifically investigate whether contributors (a) working mostly "regular" office hours or (b) performing more support activities report disengaging for different reasons.

Working hours: Analyzing GitHub data, we measure what percentage of contributions are made between 7am and 7pm local time, Monday through Friday, captured as indexWorkHours (the slightly wider interval than the traditional 9am to 5pm increases robustness to daylight savings [START_REF] Claes | Do programmers work at night or during the weekend?[END_REF]). To detect the contributor's local time, we adjusted the UTC times in GHTorrent with the average time zone offset for each developer, collected from a small random sample of their commits after cloning repositories locally. We then separate our survey participants into two groups, Office Hours (more likely paid contributors) and Nights and Weekends (more likely volunteers), based on whether they perform more or less relative amount in the office hour window described above than average (average indexWorkHours = 0.6; design following prior research [START_REF] Lin | Developer turnover in global, industrial open source projects: Insights from applying survival analysis[END_REF]).

Support activity: We also measured indexSupport as the percentage of support activities among all activities, i.e., all non-commit GHTorrent events related to managing issues and pull requests. We distinguish between High Support Work and Low Support Work relative to the mean (indexSupport = 0.2).

Note that given the different ways in which we aggregate the survey responses and the relatively small sample size overall, we cannot draw sound statistical conclusions about differences between the (sub)groups. While we report exact numbers, readers should focus on qualitative differences.

Threats to Survey Validity. As usual for surveys, our results may be affected by a selection bias: contributors who did not answer may have had different reasons for disengaging. To identify contributors who had disengaged, we used public GitHub data, which covers much but not all open source activities, as also visible in 10 (of 151) survey responses that indicate changing platforms. Deriving the survival model data from survey participants enabled modeling only contributors confirmed to have disengaged. Note that we consider moving to private repositories (12 answers) still as disengagement from public open source activities. Furthermore, our approach to identify disengagement looks for sudden disengagement (within a six-month window) and results may not generalize to contributors who disengage more gradually. Contributors may also deliberately or unconsciously self-censor in their answers, providing socially acceptable reasons rather than real-a common concern in turnover research [START_REF] Peter W Hom | One hundred years of employee turnover theory and research[END_REF]. Note however, that our survival model (discussed later) is built entirely on historic trace data rather than self-reported answers, and thus reduces this threat.

Results from Survey

In Table 1, we show the survey results. The most common self-reported reason for disengagement was changing jobs to a job that does not support open source work and occupational reasons were generally the most frequent.

Furthermore, we observe differences across populations: Contributors who work nights and weekends tend to disengage for different reasons than those who work during office hours: contributors who worked nights and weekends most commonly cited social reasons, whereas those who worked during office hours most commonly cited occupational reasons; the largest difference is between those who cited Left job where they contributed to OSS, with 19 % and 0 % citing it respectively.

Next, we turn to the aggregation by type of work, noting Contributors who do less support work tend to disengage for different reasons than those who do more: In particular, only 67 % of the More Support Work group cited at least once Occupational reason, compared to 72 % of the Less Support Work group. The difference between these two groups may be because since they are less stressed when major life changes occur (i.e., getting a new job or leaving school), they are better able to cope with transitions.

Finally, we emphasize a surprising result. For all contributors, occupational reasons such as major life changes (e.g., getting a new job or leaving school) were the most cited (with 106 citations), significantly more than lacking peer support or losing interest that are more commonly discussed in the literature. This motivated us to consider transitions explicitly in our survival analysis below.

5 Modeling Disengagement Factors (Survival Analysis)

Survival Model Methodology

We use survival analysis to triangulate the survey results and model the relative strengths of the effects of the three main factors emerging from the survey analysis on the risk of disengagement from public GitHub activity (Work Hours vs Nights and Weekends; High Support Work vs Low Support Work ; and Job Transitions). Survival analysis is a statistical modeling technique that specializes in time-to-event data [START_REF] Rupert | Survival analysis[END_REF], particularly suited for modeling right censored data. In our study, the event is public GitHub disengagement; right censorship can occur for contributors whose last recorded event may be very close to the end of the observation period, for which it is not clear whether they will return to contribute more. In particular, we use a Cox Proportional Hazards regression model [START_REF] Roxbee | Analysis of survival data[END_REF]. The estimated regression coefficients describe each variable's hazard ratio (HR), which is analogous to an odds ratio in for multiple logistic regression analysis. Briefly, an HR > 1 indicates an increased risk of observing the event, and an HR < 1 indicates a decreased risk, relative to a one unit change in a predictor variable (or flipping the value, in case of binary variables), while holding all other predictors constant.

Data. We collect GitHub data on several variables for the open source contributors who disengaged and responded to our survey (the 'treatment' group), as well as for an equal sized 'control' group of contributors who did not disengage. With this design, a survival model estimates which factors are statistically useful for distinguishing groups.

For job transition data, we collect publicly available CV data from contributors by following links on their GitHub profiles. Since our data collection is not yet fully automated, we can currently only assemble a dataset of moderate size, therefore we only collected data for our our survey participants (plus the control group), because their survey answers validate that they actually disengaged. For non-CV data, we use GHTorrent (Sec. 4). We discard 34 participants for which we cannot find CVs or similar information from which we can deduce past transitions, leaving us with a dataset of 206 contributors of which 103 disengaged. By construction, both groups contributed actively for 18 months (at least 100 commits per six-month period for three consecutive periods; Sec. 4); the 'control' group contributors then remained active for at least another six months at similar levels or higher, while the 'treatment' group contributors made at most five commits in the following period, i.e., they disengaged.

Model factors and operationalization. We compute:

-Activity level: Prior work has shown that more active contributors are less likely to disengage [START_REF] Constantinou | An empirical comparison of developer retention in the rubygems and npm software ecosystems[END_REF], hence we control for the average quarterly activity level by counting all activities (commits and support) per person. -Working hours and support: We use the two factors indexWorkHours and index-Support as introduced in Section 4.1 to characterize the degree of work outside regular working hours (more likely volunteers) and the degree of support activities, both identified as stressors by practitioners (cf. Sec. 2). We compute dummy variables indicating being above or below the mean. -Organizational affiliation: -Previous research has shown that on a project scale, having an organizational affiliation can help increase developer retention rates [START_REF] Zhou | Inflow and retention in OSS communities with commercial involvement: A case study of three hybrid projects[END_REF]. We test whether organizational affiliation has the same affect on engagement on an individual scale as it does on a project scale. Using GHTorrent, we record whether contributors had an Organizational Affiliation listed on their GitHub public profile.

-Team size: Turnover research regularly reveals social embedding in a team as an antidote to turnover [START_REF] Fang | Understanding sustained participation in open source software projects[END_REF]. We operationalize this as the number of contributors per project. Since a contributor may be part of multiple projects, we consider only their main projects (for a contributor, taking all projects with the highest number of contributions that together constitute at least 50 % of all contributions) and record the average team size among those projects. 'Teams' comprise everyone who authored at least one commit. -Project popularity: To control for whether contributors are more likely to disengage from small or very popular projects, we use the number of stars a project has on GitHub as a proxy for its popularity (standard measure in GitHub research [START_REF] Dabbish | Social coding in github: transparency and collaboration in an open software repository[END_REF]). We model popularity in addition to activity level because previous research has shown that the popularity of a project influences its survival probability [START_REF] Valiev | Ecosystem-level determinants of sustained activity in open-source projects: A case study of the PyPI ecosystem[END_REF], and we are interested in whether the popularity of a project also affects the survival probability of its contributors on an individual level. For contributors working on multiple projects, we consider the max popularity of the contributor's active projects (see team size). -Transition found: Finally, to operationalize a contributor's transition data, identified as very important in our survey, we went to their linked publicly available CV and created a binary variable that recorded whether there was a transition present in the last year or not. We considered a transition to be either the stopping or starting of a job or educational program.

Model diagnostics. We performed the standard model diagnostics: We log transformed variables with highly skewed distributions, as necessary, to reduce heteroscedasticity [START_REF] Gelman | Data analysis using regression and multilevel/hierarchical models[END_REF]. We tested for multicollinearity using the variance inflation factor (VIF < 3) [START_REF] Cohen | Applied multiple regression/correlation analysis for the behavioral sciences[END_REF]. We also inspected Schoenfeld residual plots to graphically diagnose Cox regression modeling assumptions [START_REF] Patricia | Proportional hazards tests and diagnostics based on weighted residuals[END_REF].

Threats to Model Validity. Regarding the survival model, statistical power is limited by the small sample size, which is limited by our design of modeling only survey participants with public CV data (due to confirming disengagement with the survey and manual effort required, as discussed). Since our treatment group was limited to the survey respondents, our survival model also has the risk of suffering from selection bias. As usual, our operationalization of factors in our survival model can only capture part of the concept to be measured. While we experimented with different operationalizations of our factors to ensure construct validity and robustness, one needs to be careful in generalizing our results beyond our specific operationalizations.

Results from Survival Modeling

Table 2 presents the results from the two survival models created; a base model without the novel transition found variable, and a full model with.

The base model had a goodness of fit of R 2 = 0.21. The controls behave as expected. Total activity had a hazard rate of 0.36, meaning it decreases a contributor's risk of disengaging by a factor of 0.38. Similarly, contributors who work on more popular projects are less likely to disengage (Max number of stars has a hazard ratio of 0.85).

As predicted based on previous research, the workHours dummy affects a contributor's risk of disengaging, having a hazard ratio of 1.56. This suggests that working during business hours more than the average contributor increases the risk of disengaging by a factor of 1.56. Surprisingly, we do not observe any statistically significant effects of doing more support work than average (the highSupportWork dummy), perhaps due to our operationalization or relatively small sample size.

The full model fits the data better (R 2 = 0.25), meaning that adding in the jobTransition variable helped increase the explanatory power of the model. The jobTransition variable has a hazard ratio of 2.48, meaning, as suggested by the survey results, that experiencing a transition significantly increases a contributor's risk of disengagement by a factor of 2.48.

Table 1 .

 1 Self-Reported Reasons for Disengagement in Survey

	Subgroup	Count	Office Hrs	More Support
			vs Nights&We	vs Less
	Occupational reasons
	Got new job that doesn't support FLOSS	37
	Changed role/project	25
	Left job where they contributed to FLOSS	16
	No time: new job	15
	No time: existing job	10
	Left school where they contributed to FLOSS	12
	No time: in school	12
	FLOSS in school, now job doesn't support FLOSS	7
	Too much coding at work	4
	Social reasons
	Lost interest in FLOSS	24
	No time: personal	23
	Lack of peer support	16
	No time: nondescript	15
	Technical reasons
	Issues w GitHub or industry	14
	Individually moved to private repos	12
	Changed platform	10
	Feature complete project	3
			30 20 10	0	10 20 30	30 20 10	0	10 20 30

Table 2 .

 2 Survival models for contributor disengagement. * * p < 0.001, * * p < 0.01, * p < 0.05

		Base model	Full model
	activity	0.36 (0.21) * * * 29.00 * * * 0.36 (0.21) * * * 27.92 * * *
	orgAffiliation	0.90 (0.21)	0.27	0.92 (0.21)	0.17
	maxTeamSize	1.17 (0.08)	3.59	1.17 (0.08)	3.41
	maxNumStars	0.85 (0.05) * * 10.01 * * 0.86 (0.05) * * 9.08 * *
	highSupportWork TRUE 1.29 (0.26)	0.96	1.43 (0.27)	1.74
	workHours TRUE	1.56 (0.21) *	4.52 *	2.20 (0.30) * * 5.59 *
	jobTransition			2.48 (0.31) * * 8.15 * *
	workHours:jobTransition			0.55 (0.42)
	R 2	0.21		0.25

*

https://www.kennethreitz.org/essays/the-reality-of-developer-burnout

https://hackernoon.com/what-is-programmer-burnout-651aa48984ef

Discussion and ConclusionsIn this research, we have looked at the reasons why established open source contributors disengage, using a survey with 151 responses and a survival model to quantify factors which predict disengagement. From the grouped analysis of survey results, we learned that the Nights and Weekends and Office Hours groups tend to cite different reasons for their disengagement, and so do more the Less Support Work and More Support Work groups.Importantly, our study shows that operationalizations of different disengagement risk factors using publicly observable trace data are plausible. For example, since occupational reasons were the most commonly cited, we used online public CVs to operationalize the jobTransition variable; however, other commonly cited reasons from the survey may also be operationalizable. Another commonly cited reason was 'no time, personal circumstance', more specifically people often cited having children or getting married. Such circumstances may be observable on social networking platforms. This suggest that a data-driven systems could be developed to help identify at-risk groups on a significantly larger scale, instead of having to rely on relatively expensive survey data. This information could be useful to different stakeholders, such as open source foundations and other funding agencies, looking to target support interventions. Overall, support interventions targeted more appropriately could significantly increase the sustainability of open source ecosystems.We aim to work on these extensions of the research and more, to better understand the reasons why different kinds of established contributors disengage, since defining the problem is the first step to solving it[START_REF] Bardach | A practical guide for policy analysis: The eightfold path to more effective problem solving[END_REF].

Acknowledgements. This work was supported through CMU's REU in SE, NSF (1318808, 1552944, 1717022, and 1717415), and AFRL and DARPA (FA8750-16-2-0042). We thank our survey participants, and colleagues at CMU, especially Jim Herbsleb, Chris Bogart, Marat Valiev, and Sophie Rosas-Smith.


Oliver Fendt

Michael C Jaeger

Open Source for Open Source License Compliance

Keywords: license compliance, license scanning, component inventory, open source management

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

Elements for an OSS Management Process

The clearing of components and involved licenses is part of an OSS management process that covers the handling of 3 rd party software. As described in [START_REF] Fendt | Industrial Experience with Open Source Software Process Management[END_REF] the following main goals have to be achieved by the OSS management process:

• Assurance that only suited components are approved for integration -after the involved licensing has been determined and understood. • Assurance of license requirement fulfillment -determining the involved licenses and understanding involved terms has the purpose to actually implement those license requirements in order to provide a compliant product or delivery. • Storing and tracking of OSS components. An organization takes advantage from keeping track of 3 rd party software use: on one hand, it serves the purpose of documentation if questions or inquiries arise about OSS usage for example. On the other hand, an organization wants to prevent redundant clearing work and reuse clearing results for future uses of the same component. The management process requires different elements in an organization for its implementation. On one side there are organizational aspects, which can be responsibilities, roles, contact persons and a decision board. These aspects are for example summarized by the OpenChain (https://www.openchainproject.org) standard which describes which basic organization elements should be present.

And of course, a culture that is "open" to the use of open source is a key element of any open source management. Mentioning our organization as an example, we have regular internal events on OSS and a broadly-used web-based training educating all employees not only in software development related roles, but also beyond e.g. procurement and product management. Since its introduction in 2015, several ten thousands have attended the Web-based training so far. As an example for a dedicated role with decision responsibility, "third-party software experts" of the various business units regularly meet to discuss and agree on common approaches, best practices and challenging cases of 3 rd party software usage.

In addition to company-internal activities described here, we also actively engage in world-wide activities of the OSS community. Such engagement is not only limited to reusing OSS components, and re-using OSS clearing results, but also other aspects such as agreeing on standard formats like SPDX (https://spdx.org/) and joining activities like the OpenChain projects that promote a high level of license clearing processes and enable sharing of cleared components This paper focuses on the use of tools and services which are available as open source from the community for implementing license compliance. Despite commercial tools being available, our work shows that OSS tools can be adopted by organizations and provide an effective and open approach. Among many advantages, OSS software allows for modification and adaptation to own needs; can better use the latest innovative approaches from the OSS community; do not require the establishment of a commercial contractual relation; and it allows for using software without spending monetary resources, which is an advantage also for non-commercial organization.

An open source management process needs to count on different artifacts for a successful implementation. These include a tool for analyzing the licenses present in 3 rd party software components, a database that holds license interpretation of used licensing, a catalogue application that keeps track of 3 rd party software in products and services, an application that keeps track of the progress of clearing tasks as well as providing an overview of all involved 3 rd party component w.r.t. clearing status, a source code and component and repository that stores used software for analyses and reference to clearing results, an application which generates the licensing documentation for distribution as well as for internal approval purpose, product OSS code collector, and a code verifier.

The management of software component takes place inside the software engineering process -there are software repositories, dependency management systems and packing tools which already create various software artifacts for distribution. Naturally, the open source management tools must be integrated with the already existing software engineering facilities, for example continuous integration tools.

Figure 1 shows a general setup and context of software management, including basic elements for a software development tool chain. On the left there are different sources for 3 rd party software as well as information about them. All these elements are outside of the organization and are relevant sources for OSS management. In addition to inbound 3rd party software, public repositories and databases holding information about 3rd party software components exist which can hold relevant information for component and license clearing.

In the middle of this diagram, the integration of OSS management tools with existing software engineering tools is outlined: internal repositories and tools for building the software are integrated with clearing tools. Organizational internal repositories for software exist that contain information used for component clearing, but more importantly, checks and analyses tool for a clearing are triggered by the build and software production automation.

In basic terms, the input for managing 3 rd party components, originates from the software building infrastructure. Going further right, the software is prepared for distribution which involves the generation of distribution documentation as well as checks if the license terms are fulfilled. Around all this, organization internal repositories, such as internal git servers, but also artifact servers are not only relevant for software development, but also for OSS management. In additional, a central element is a component catalogue application which acts as a central inventory capturing component usage. It is fed by analysis information of 3 rd party components as well as usage information in products and services.

OSS Software Projects and Tools

For the elements depicted in the figure 1, different OSS tools exist for the implementation of the given elements. We would like to introduce a minimal set for implementing a OSS management process with the goals given above. The first part on the right hand side refers, of course, to OSS published software (e.g. Sourceforge, or nowadays Github or git servers of OSS foundations), but also software package servers, such as those for Linux distributions as well as those for developing software for a particular languages (e.g. Nuget for C# components). In addition, software can be obtained from commercial vendors and as such, represents also inbound 3rd party software.

As a second element that an organization can use are the now growing offerings for information about 3rd party software. Some companies offer concluded licensing information, some analyses and metadata describing how sane the software project is. Moreover, public information relevant for an OSS management process are license (text) collections and interpretations about licenses. A license collection is very useful for identifying license texts as found in OSS. As for the interpretation of licenses, there are also libraries in the form of offering interpretations for licenses, as well as information pages about articles that discuss licenses cases from a legal point of view.

There are a number of open source tools for various aspects of open source license clearing and management. In our organization, the two main OSS tools we use for this are FOSSology (https://www.fossology.org/, https://github.com/fossology/fossology) and SW360 (https://eclipse.org/sw360, https://github.com/eclipse/sw360). FOSSology is a Linux Foundation project which has a meanwhile over 10 year project history providing a solution for license scanning [START_REF] Michael | The FOSSology Project: 10 Years of License Scanning[END_REF]. It has a very precise license scanning facility that allows us to identify licenses as well as copyright information well. SW360 is a project hosted by the Eclipse foundation. It provides both a web application and a repository to collect, organize and make information available about software components.

For the "Assurance of license requirement fulfillment" step in the license clearing process all of the OSS licenses of the approved component have to be thoroughly examined by FOSSology to clearly identify the requirements (license obligations) to fulfill as well as to define the ways of fulfilling the obligations. For the "Storage and tracking of OSS components" step we use SW360. With it, the usage of the approved components are typically registered and uniquely tracked for future reference and reuse. The goal is not only to have a database of already approved OSS components with all their associated information (e.g. suitability ranking, copyright holders, applicable licenses, set of requirements the products have to fulfill derived from the license situation, etc.). An additional goal is also to provide a means for internal (and external) knowledge sharing on how to use, integrate and analyze the component.

Figure 2 shows a high level overview of an integrated compliance tool chain, which represents also a more detailed diagram compared to Figure 1. On the left side, the incoming software is depicted. For successful use of OSS, also contributions to the project should be considered. The right side shows the deliverables, products, or the software which the organization conveys. In the middle part, a collection of elements is shown which play a role license compliance and OSS management. The connection of all the elements together, integrated with build infrastructure provides us with a compliance tool chain.

Related Work

We are part of a vibrant and growing community in the area of open source tools of open source license compliance. Numerous members of this community presented at a forum organized by the German BITKOM organization [START_REF]Forum Open Source 2018 -BITKOM 2018[END_REF] and the community strives to find ways to further foster the ecosystem of OSS-based tools for OSS license compliance and related topics. In addition to our own participation (FOSSology, SW360), other tools include Quartermaster (https://qmstr.org, https://github.com/qmstr/qmstr) and OSS Review Toolkit (https://github.com/heremaps/oss-review-toolkit).

More relevant OSS tools and activities include: ScanCode, another OSS license clearing tool, Tern which analysis containers for their used OSS for compliance (https://github.com/vmware/tern), and ClearlyDefined (https://clearlydefined.io, https://github.com/clearlydefined). ClearlyDefined and its hosting foundation, the Open Source Initiative, are on a mission to help OSS projects by being, clearly defined in terms of compliance relevant information. According to ClearlyDefined, a lack of clarity around licenses and security vulnerabilities reduces engagement and this can lead to fewer user, contributors and a smaller community. Although not being a tool, the Software Heritage project (https://www.softwareheritage.org/) is an important part of the OSS ecosystem. Ideally, it could be a central source that the various tools could use as the central repository of the OSS source code which would be of significant benefit to the entire community.

Summary and Future Work

Modern software engineering seems to be increasingly use OSS including many of the aspects that have been a hallmark of OSS -transparency, improvement, sharing, and collaboration. As open source becomes more and more prevalent in our products, and also in the tools that help create those products, it is logical to also increasingly use open source tools and processes to do OSS license compliance. The open source community on this topic is active and includes well-established tools with a long history such as FOSSology, but also a set of numerous other tools as well. We encourage the community to continue to work together to further extend the scope and the increased use of these tools in practice.

We are firmly convinced that an open source approach is the best way to able to keep up with the fast and ever-faster changing software world. Some of the future directions and areas for future work for the international OSS community are:

• Reuse of (a subset of) clearing results across an external ecosystem, • License compliance in the context of continuous delivery / DevOps ecosystem identification of dependencies, automatic download of the source code packages of the used packages (incl. dependencies), license analysis -and licenses determination, copyrights and automatic generation of license compliance artifacts. To realize a fully functional DevOps setup the license compliance as well as cyber-security processes need to be seamless integrated in the environment • Enhancing automatic container analysis for license compliance with the goal to identify all applicable licenses.

Fig. 1 :

 1 Fig. 1: Context of 3 rd Party Software Management

Fig. 2 .

 2 Fig. 2. Overview of an Integrated Compliance Tool Chain