Jesus M Gonzalez-Barahona

Paul Sherwood

Gregorio Robles

Daniel Izquierdo

Technical Lag in Software Compilations: Measuring How Outdated a Software Deployment is

Large software compilations based on free, open source software (FOSS) packages are the basis for many software systems. When they are deployed in production, specific versions of the packages in the compilation are selected for installation. Over time, those versions become outdated with respect to the upstream software from which they are produced, and from the components available in the compilations as well. The fact that deployed components are outdated is not a problem in itself, but there is a price to pay for not being "as much updated as reasonable". This includes bug fixes and new features that could, at least potentially, be interesting for the deployed system. Therefore, a balance has to be maintained between "being up-to-date" and "keeping the good old working versions". This paper proposes a theoretical model (the "technical lag") for measuring how outdated a system is, with the aim of assisting in the decisions about upgrading in production. The paper explores several ways in which technical lag can be implemented, depending on requirements. As an illustration, it presents as well some specific cases in which the evolution of technical lag is computed.

1 From upstream to deployment Many production systems are deployed as collections of FOSS (free, open source software) components. All of them are based on the software produced by the corresponding FOSS projects. And usually, as time passes, those projects deliver new releases with more functionality, more fixed bugs, and in many cases, more overall stability and performance [START_REF] German | Using software distributions to understand the relationship among free and open source software projects[END_REF]. We will use the term "upstream project" for referring to the project originally producing a FOSS component. Upstream projects release, from time to time, versions of the FOSS components they produce and maintain. This release may be continuous, each time a change is done to the code, or discrete, at specific points in time, when the project considers it convenient [START_REF] Michlmayr | Why and how should open source projects adopt time-based releases?[END_REF]. In fact, many projects release in both ways: they release continuously in their source code management system (one release per commit), but they also offer "official" tagged discrete releases. In any case, we will consider the released component as the "upstream released package".

But it is unusual that upstream packages are directly deployed in production systems. Instead of that, packages coming from software compilations, usually referred to as "distributions", are used for deployment. We will refer to the packages released as a part of a software compilation as "distribution packages" (to avoid using "compilation packages", which could be easily mistaken for "package produced as the result of compiling some software"). Distribution packages are produced by adapting upstream packages to the policies and mechanisms defined by the software compilation. That usually makes the deployment of components easier, more coordinated with other components, and in general more uniform. This adaption usually includes changes to the code, with respect to upstream. For example, Debian packages include certain files with information on how to build (produce a binary version from the source code) and install the package, and may include changes to improve or adapt it to the distribution [START_REF] González-Barahona | Macro-level software evolution: a case study of a large software compilation[END_REF].

We propose the following model for the process from the production of a FOSS component to its deployment in production:

-The upstream project produces an upstream package. This will be a new upstream release of the FOSS component. This can be just a commit in a Git repository, or a curated official tagged release. -That new upstream package is used by a software compilation as the basis for a new release of their corresponding distribution package. For producing it, upstream code is used, maybe with some patches applied, and some extra files. -Deployers use a certain release of the distribution package to deploy the FOSS component in production.

A real deployment may include hundreds or thousands of FOSS components, each corresponding to a certain release of the corresponding upstream package.

This model can be applied to deployments in many scenarios, such as: a collection of Debian packages in a virtual machine or container, providing some cloud-based service; a collection of JavaScript libraries used by a web app, installed from npm.org; or a collection of Python packages (or Ruby gems) installed in a certain machine to run a Python (or Ruby) program; a certain Yocto-based distribution deployed in a certain car (Yocto is a Linux-based distribution oriented towards embedded systems); etc.

Technical debt and technical lag

Each deployment scenario has different requirements with respect to their "ideal" relationship with upstream. But in all cases, if no updating action is performed, they stay static, "frozen in the past", while upstream evolves, fixing bugs and adding new functionality. The same happens with software compilations with respect to upstream, if they do not release new updated packages for their components.

Depending on the requirements of the final system, and the resources to maintain it, lags of deployed systems with respect to their software compilations, and to the latest upstream packages, can be larger or shorter. For example, in deployments with a large number of components and high stability requirements, updating even a single new package can be a challenge: the whole system has to be tested, since the updated package could break something, specially if it is a dependency to many other packages [START_REF] Claes | A historical analysis of debian package incompatibilities[END_REF]. Even if upstream developers and compilation maintainers did their own thoughtful testing, some integration bug could be triggered when deployed. A significant amount of effort has to be devoted to upgrading, and tracking the behavior of the system after the upgrade. Besides, in some cases the new version could break some assumption about how it works, affecting the overall functionality or performance. Therefore, every new version has to be carefully examined before it can be deployed.

As time passes, if deployed components are not upgraded, the system misses more and more new functionality and bug fixes: it is not "as good as it could be". This situation is akin to the one described as "technical debt" for software development. The metaphor of "technical debt" introduced in 1992, tries to capture the problems caused for not writing the best possible code, but code that could (and should) be improved later on [START_REF] Cunningham | The wycash portfolio management system[END_REF]. The difference between code "as it should be" and code "as it is" is a kind of debt for the developing team. If technical debt increases, code becomes more difficult to maintain. A similar concept is "design debt", which translates the concept to the design of software components [START_REF] Kerievsky | Refactoring to Patterns[END_REF].

In the case we are considering in this paper, we are not exactly in a technical debt scenario, although the concept could be easily extended to include it. The main differences are:

-The concept does not try to capture that deployment is not done "as it should be done". On the contrary, the system "degrades" just with the passing of time, and not because some code needed to be improved when deployed. -Software development is not really involved, since it only happens upstream, and to a certain extent, in software compilations. Only deployment decisions are considered. -The metaphor of the debt is difficult to understand in this case, since it is not some "debt" being acquired at some spot, which has to be returned later. Our case could be more comparable to a tax, paid for not being updated, in the form of less functionality and more bugs that we could have if updating.

To recognize the differences, we are coining a new term, "technical lag", which refers to the increasing lag between upstream development and the deployed system if no corrective actions are taken. Deployers need to balance the technical lag their systems acquire as time passes, with the effort and problems caused by upgrading activities.

Computing technical lag for a deployment

When measuring technical lag, the first problem is to decide what is the "gold standard" with which to compare. Depending on requirements and needs, the comparison may focus on stability, functionality, performance, or something else.

For example, if there is interest in calculating the technical lag of a Debianbased distribution, with a specific interest in stability, we need to find the standard for stability for Debian-based distributions. One choice could be Debian stable (the Debian release which is currently considered "stable"4 ). In a different case, a system could be interested in being as much up-to-date as possible with respect to upstream, because they are interested in having as much functionality and bugs fixed as possible. In this case, the standard would be the latest checkout for each upstream package.

Once the gold standard is defined, we still need to find out the function to compute the lag between the component in the standard compilation and the deployed component. For example, if the focus is on security, the lag function could be the number of security issues fixed in the standard which have not been fixed in the deployed system. If the focus is functionality, the function could be the number of features implemented in the standard which have not been implemented in the deployed component. Some other interesting lag functions could be the differences in lines of source code between standard and deployed components, or the number of commits of difference between them, if both cases correspond to upstream checkouts.

Therefore, when defining the technical lag for a system, it is not enough to just define the deployment to consider. The standard to compare (or the requirements of the ideal deployment) and the function to calculate the lag between versions of the component need to be defined as well.

Formal definition of technical lag

Assume we have a deployment D composed of a set of certain components C, deployed as packages of a certain software collection, and a certain standard distribution S, composed by the same set of components, but packaged for that distribution. We denote d i as a package in distribution D corresponding to component i, while s i denotes a package in the standard distribution S corresponding to the same component i:

D = {d i : i ∈ C} S = {s i : i ∈ C} (1)
We define the lag function for packages corresponding to a component, Lag(d i , s i ), as the function computing the lag between packages d i ∈ D and s i ∈ S, for a given component i ∈ C. Lag is defined for all pairs (d i , s i ), as long as s i is more up-to-date than d i , and zero in other cases. Lag has the following properties, which result in the technical lag of a deployment being a non-negative real number. For Lag to be useful, it should fulfill the "lagging condition": computing a larger value for distribution packages "lagging behind". That is, the more distant d i is from s i , for some lag requirements, the larger Lag(d i , s i ) should be.

We define the lag aggregation function, LagAgg, as the function used to aggregate the package lags for a set of components.

Finally, we define the technical lag for the deployment D with respect to the standard distribution S as the aggregation of the lags between the deployed and the standard distribution packages:

T echLag(D, S) = LagAgg(Lag(d i , s i )∀i ∈ C) (2)
When the aggregation function is summation, technical lag is defined as:

T echLag(D, S) = i∈C Lag(d i , s i ) (3)
This definition captures how technical lag depends on:

the distribution selected as the standard distribution to compare the function used to calculate the lag for each of the components in the deployment the aggregation function for the lags of the deployed components

Calculating lag between packages

After the formal definition of the concept, this section will illustrate with an example how the lag can be computed for a certain component, how results differ depending on the distribution selected as the gold standard, and how they however make sense from a practical point of view. For simplicity, we will work with packages for which upstream is working openly in a Git repository. This allows us to model upstream as following a continuous release process, with each commit in the master branch of the Git repository being a release.

We selected components packaged for Debian, because it is a very popular distribution, basis for many other popular distributions, such as Ubuntu. It is common to find Debian or Ubuntu packages in real deployments, both of cloud and embedded systems, to mention just two domain areas. Debian provides the Debian Snapshot Archive5 , which offers for each component a very complete collection of all packages that have been in Debian distributions in the past. This collection includes not only packages in Debian stable releases, but also in Debian unstable and Debian testing, that -because of their nature-may include many interim versions. For each package in the Debian Snapshot archive, its version tag and the date of its release are available. This allows for easy plotting of the evolution of the technical lag of those packages, either just over time, or grouping by releases, as will be shown in the figures in this section.

The selected illustrative cases are the acl and Git packages. In the case of acl, we have found 24 packages in the Debian archive (released from 2005 to 2012), while for Git we have found 192 (from 2005 to 2016). Only since 2010 Debian Git packages correspond to the "current" Git package, the popular source code To estimate the technical lag of each Debian package, we will assume that it is deployed as such, and compared with the current upstream master HEAD checkout at the time of the study (Oct. 2016). Therefore, following the notation in the previous section: d i is each of the Debian packages considered; s i is the latest upstream continuous release (defined as the HEAD of the master branch in the upstream Git repository); and LagAgg is summation.

As Lag, we computed four different functions, to offer different lagging criteria6 :

-different_lines and different_files: number of different lines or files, including those that are present only in d i or s i . -diff_commits: number of commits, following the master branch of the upstream Git repository, needed to go from the most likely upstream commit corresponding to d i to the commit corresponding to s i . -normal_effort: total normalized effort for the commits identified when computing diff_commits. We define normalized effort (in days) for an author as the number of days with at least one commit between the dates corresponding to two commits in the master branch. We define total normalized effort (in days) as the sum of normalized effort for all the authors active during the period between two commits.

The first two lag functions capture how different is the deployed component is from the component in the standard distribution (in our case, the most recent Fig. 2. Lag functions applied to Debian Git package releases, by release date commit upstream). The last two functions capture how many changes (or, to some extent, effort in changing) were applied to the component in the standard distribution since the upstream release used to build the deployed package.

To provide some context, we computed as well common_lines and common_files, which is the number of lines an files in common between D i and C i (lines exactly the same). Those are not really Lag functions, since they do not fulfill the lagging condition: both grew larger when d i and s i were closer.

Figures 1 and2 show the evolution of the lag over time, considering the release time of Debian packages. Each chart shows the value of lag (using one of the lag functions mentioned above) for the release time of each Debian package. For all the four "Lag" functions, it can be seen that they are almost monotonically decreasing over time, clearly converging to zero as time approaches the release time of s i (the rightmost values). For acl, there is a clear step in 2009, which corresponds to major changes in the component, as will be shown later. For Git the change around 2010 is due to the different packages being tracked (see above, that means that only the data from 2010 onwards is really meaningful). After that point there are some spikes and steps, notably two large spikes in late 2015 and early 2016. But in general, the trend in all charts is clearly decreasingly monotonic.

Figures 3 and4 are more revealing, because they have into account two common practices in Debian: labeling package releases (in part) with upstream version tags, and releasing slightly modified versions for stable distributions.

The first is observed by the different colors and lines in the charts: all Debian packages corresponding to the same major release have been depicted in the same color, and linked with lines. Now, when we look at the charts for acl in Figure 3, we see how the step in 2009 corresponds to a change in version (from pink to red), which did a major refactoring of the code. That is clearly appreciated in the functions showing common and different lines. In the case of Git, the transition The second practice is observed for Git in Figure 4: the red horizontal lines on the right correspond to new releases of "old" packages, fixing some important bugs, since they are still maintained after a long time for some stable distribution. That helps to explain the spikes we saw in Figure 2: those d i are really "out of order" packages.

In all the figures for the same component, the different functions show similar trends. There are differences, but probably any of them would provide enough information for evaluating if the lag is large enough to justify an update of a deployed package.

Discussion and conclusions

Software compilations for FOSS components are usually complex and large, and decisions about when to upgrade specific deployed packages, or whole deployed distributions, is not easy. The complexity of dependency management [START_REF] Mancinelli | Managing the complexity of large free and open source package-based software distributions[END_REF][START_REF] Wermelinger | Analyzing the evolution of eclipse plugins[END_REF][START_REF] Bavota | How the apache community upgrades dependencies: an evolutionary study[END_REF], or their significant evolution over time [START_REF] González-Barahona | Macro-level software evolution: a case study of a large software compilation[END_REF] are reasons both to delay upgrading (because of the potential problems), and to consider it (because of the added Fig. 4. Lag functions applied to all releases of the Debian Git package, by release date, organized by version functionality and improved code). The same way that the complexity in dependencies, or the some parameters of their evolution [START_REF] Gala-Pérez | Intensive metrics for the study of the evolution of open source projects: case studies from apache software foundation projects[END_REF] can be measured, we are exploring the concept of technical lag to measure their "degradation" over time with respect to some "ideal" gold standard.

Defining this degradation requires identifying the "ideal" packages to deploy (the "gold standard" to compare), and finding distance metrics (lag functions) to compare deployed software with that standard collection. To be useful, these metrics should track characteristics linked to requirements of the deployed system. As it was discussed in the first part of this paper, a system interested in stability may define very different metrics and gold standard than one interested in maximum functionality. In this paper we have just explored one kind of ideal distribution (the latest available upstream code), and two kinds of metrics: those based on differences in source code (in terms of lines or files), and those based on the number of changes (either the number of commits or the normalized effort). However, many other could be explored.

In particular, the exploration of criteria to define "gold standards" for general or specific scenarios seems promising. Complete industries, such as automotive, embedded systems or cloud, could be interested in finding standard collections with which to compare any deployment, in a way that they may decide better when and what to upgrade, given a set of requirements.

The definition of lag functions requires careful exploration as well. Some of them may be difficult, because the needed information may be heterogeneous, and distributed. But some seem feasible: the number of bugs fixed, or security advisories addressed; the number of new features implemented; improvements in performance, etc. (obviously, when there are ways of collecting that information). This makes us think that there is a lot of work to do in this area, and that we have not even collected all the low hanging fruits.

In this paper, we have considered that distribution packages are directly deployed in production, and therefore make no real difference between the packages in a distribution, and those packages when deployed. In the real world, packages may be deployed with some differences with respect to the distribution packages used. For example, some patches could be applied to fix known bugs. However, this does not make the model less general: the patched packages can be modeled as a new distribution, based on the "original" one, and all the above considerations will apply.

As a kind of a conclusion, we propose technical lag as useful concept to deal with large FOSS deployments. As real-world systems are increasingly built by assembling large collections of FOSS components, it is evident the need of techniques for managing their complexity. In some areas, such as dependency management or architectural evolution, research has been producing results for many years. But there is little evidence that may help in the system-wide maintenance procedures, including those relatively easy, such as when and what to upgrade. With this paper we propose a new line of research, trying to provide support practitioners in may fields of the industry.

Although we are focused on FOSS compilations, it is interesting to notice that the concept of technical lag can in theory be extended to non-FOSS components. However, in practical terms that may be difficult, except if source code and other related information needed to estimate lag is present. This can be the case in some special cases, such as when a company deploys systems composed by a mix of FOSS and proprietary components, but it has access to all the needed information for proprietary ones.

Fig. 1 .

 1 Fig. 1. Lag functions applied to Debian acl package releases, by release date

Fig. 3 .

 3 Fig. 3. Lag functions applied to all releases of the Debian acl package, by release date, organized by version

See https://www.debian.org/releases/ for a description of the different Debian releases.

http://snapshot.debian.org/

For computing different and common lines and files, we used the Python3 difflib module.

Acknowledgments and reproduction package

The work of Jesus Gonzalez-Barahona and Gregorio Robles has been funded in part by the Spanish Gov. under SobreVision (TIN2014-59400-R), and by the European Commission, under Seneca, H2020 Program (H2020-MSCA-ITN-2014-642954). The research described in this paper was started thanks to a contract funded by Codethink.

All the code and data needed to reproduce the results in this package is available from a GitHub repository 7 (checkout as of December 2016).


Carl-Eric Mols
email: carl-eric.mols@sonymobile.com

Krzysztof Wnuk
email: krzysztof.wnuk@bth.se

Johan Linåker
email: johan.linaker@cs.lth.se

The Open Source Officer Role -Experiences

Keywords: Open Source Governance, inner-source, maturity models

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

Introduction

Several companies have discovered and utilized the extensive benefits that Open Source Software (OSS) brings to their product development activities and processes.

As any OSS adoption is an organizational change and often a cultural shift, there is a need for supporting role that ensures these transformations are smooth and directed towards achieving higher maturity models in operating with OSS [START_REF] Mols | The open Source Maturity model[END_REF].

In this paper, we present the Open Source Officer Role and discuss the experiences from establishing this role in three organizations. We outline the most important challenges that the role installation brings and outline the research agenda for further research activities.

2

The Open Source Officer Role Description

The Open Source Officer (OSO) role at Sony Mobile is a response for the need to support governance, organizational development and education activities that increase Sony Mobile's ability in OSS-based development and business. The role connects the management, legal/IPR and software organizations around the open source operations, see Figure 1. It provides an important communication point for these three organizations, ensures that the processes and activities are synchronized and the potential questions are timely resolved. The OSO interfaces with executive management and participates in the daily work of the Open Source Board which scope and responsibilities can be set for a single business organization or the entire corporate. The OSO officer reports directly to the Head of Open Source Software and interfaces with software developers, architects, managers and lawyers working directly in the same organization and also roles responsible for the IPR questions. At the same time, it can happen that OSO works directly with corporate legal organizations on matters that are impacting several business units, e.g. license committee or inner-source governance organizations. The sourcing organization plays an important role here as it is responsible for negotiating contracts with component suppliers for the non-OSS components and for hardware components that come with software that can be proprietary and/or OSS. The sourcing organization has the task to secure that suppliers are fulfilling the obligation of the OSS licenses (are OSS compliant) in the delivered software. It also can support the search and selection of the best sourcing strategy (with the OSS as the priority) given the set of functional and quality requirements that a given component should deliver.

Scope of operations and main working areas include:

Governance and support systems -The Open Source Officer is a part of Open Source Operations and in charge for governance and support, including processes etc.

Education -the officer identifies the education needs in an organization as well as ensures that needed education is provided to the organization.

Developer Engagement -The OSO leads and mentors the software organizations in the engagement in OSS projects (maturing and taking on their responsibilities). The organizations take the formal responsibility for the OSS engagement activities.

Business Models -although having no direct responsibility, the OSO should engage in business strategy development discussions to influence, support, and advice business entities to enable a full advantage of using OSS in generating and sustain business.

Leadership and Culture -The OSO can support and advice in the creation of organization and leadership culture that is suitable for ensuring extensive benefits from OSS. The actual task of creating an organization is the top management responsibility.

Key Competences include:

Strong leadership skills are required as a central part of the role is to develop and manage governance and support systems as well as the education program required to advance in the open source maturity.

Communication skills -strong written and verbal English skills are required as the role involves communication with local and global organizations -including company external organizations, e.g. purchasing a training course from an external company.

Functional and technical skills -good change management skills are required as the role supports the changes in the mindset of individuals, support required transformation of organizational structures as well as influence the culture of the organization. Good understanding of OSO that is reaching beyond the basic copyright issues or OSS compliance, business and market logic implications as well. Good understanding on the fundamentals of software engineering.

Technology knowledge -the OSO need to be a very good generalist and understand the technological aspects of software as well as other aspects. This is particularly important for OSOs not originating from software organizations.

Key Responsibilities include: Engage actively in the Open Source Board operations -the Open Source Board is the governing function for Open Source within the company or a business unit. The two main tasks for the board involve: 1) Maintaining the corporate policies set by the executive management regarding OSS operations and ensuring that the documentation is up to date, and 2) Vetting and approving contribution proposals and ensuring that both business needs and IPR are taken into consideration. Ensure that Open Source related processes and trainings are provided -that includes ensuring that the processes are defined, documented and implemented in relevant organizations and that the training is provided. Act as an interpreter between engineers and lawyers -ensure that OSS related questions gets timely answered and that engineers and developers are proactive and positive about using OSS components without unnecessary license related fears. Act as the company's external interface in Open Source related questions -especially for the questions related acquisitions and compliance of the released products. Act as an internal management consultant -that reacts to any request for help or support about the OSS operations or knowledge. Authorities -the OSO has a deciding voice as one of the members of the Open Source Board and can propose changes to OSS related directives and processes.

Experiences from three software-intensive organizations

Company A is the develops software-intensive products for global market in a matured market where several strong vendors established their position. The company joined the OSS ecosystem in 2007 and within three years dropped all other platforms and based all the product on this OSS platform. The company is currently on level 4 in of OSS maturity [START_REF] Mols | The open Source Maturity model[END_REF]. The scope and responsibility of the OSO role is described in Figure 1 and in Section 2. One important remark is that the OSO in this case does not take the responsibility for compliance or running OSS-related software projects.

Company B is a direct competitor to company A and apart from software-intensive embedded systems the company is also active in several other business units that produce home electronics, automotive, chemical and heavy industry. Our analysis is based on an interview with the OSO from the same business unit as company A. The main difference at company B is that OSO is also responsible for a group of about 80 developers that maintain the critical components based on OSS code that are reused in several business units. The OSO is a project manager for these activities. Another difference is that the OSO acts as an authority regarding legal and IPR questions and have no dedicated OSS-knowledgeable lawyer to closely collaborate with. Company C manufactures trucks, buses and engines for heavy transport applications for a global market and experienced an increased dependence on software and is currently transforming into a software-intensive product development organization. The OSO role differs in two aspects: 1) the OSO is also a project manager that is responsible for running OSS-based software projects (not the core part like at company B) and 2) the OSO needs to have the required technical knowledge about software and its architecture to support the transformation to a software-intensive company. Related work. Kemp [3] suggests the introduction of an OSS Compliance Officer (OSSCO) with the responsibility of developing and implementing the OSS governance mechanisms, agree on an internal OSS strategy (e.g., expressing where and why to use OSS) and oversee that it is followed, mainly from the possible IP leakage and compliance issues. Much of the responsibilities of an inner-source champion [START_REF] Stol | Key factors for adopting inner source[END_REF] align with the role of an OSSCO as proposed by Kemp [START_REF] Kemp | Open source software (OSS) governance in the organisation[END_REF] and with the OSO role.

Conclusion and Future Work

In this experience report we have described the role of an Open Source Officer (OSO) . The OSO role offers a central authority and champion that can help an organization to both introduce and mature in their use of OSS. The presented role description is based on knowledge and experience gained from Sony Mobile and confronted with interviews at two other large organizations that use OSS in their products. Future work will further investigate how the role description may fluctuate in organizations with differing characteristics, but also how the surrounding organizational structure of the OSO can be defined, e.g., in regards to OSS governance board.

Fig. 1 .

 1 Fig. 1. The Open Source Officer role and the other roles that it interfaces in the organization.

Acknowledgements. This work was funded by the ITEA2 project 12018 SCALARE, and by the IKNOWDM project [grant number 20150033] from the Knowledge Foundation in Sweden.


Akinori Ihara
email: akinori-i@is.naist.jp

Daiki Fujibayashi
email: fujibayashi.daiki.eq3@is.naist.jp

Hirohiko Suwa
email: h-suwa@is.naist.jp

Gaikovina Raula
email: raula-k@ist.osaka-u.ac.jp

Kenichi Kula

Matsumoto
email: matumoto@is.naist.jp

Understanding When to Adopt a Library: A Case Study on ASF Projects

Software libraries are widely used by both industrial and open source client projects. Ideally, a client user of a library should adopt the latest version that the library project releases. However, sometimes the latest version is not better than a previous version. This is because the latest version may include additional developer effort to test and integrate all changed features. In this study, our main goal is to better understand the relationship between adoption of library versions and its release cycle. Specifically, we conducted an empirical study of release cycles for 23 libraries and how they were adopted by 415 Apache Software Foundation (ASF) client projects. Our findings show that software projects are quicker to update earlier rapid-release libraries compared to library projects with a longer release cycle. Moreover, results suggest that software projects are more likely to adopt the latest version of a rapid-release library compared to libraries with a longer release cycles.

Introduction

A software library is a collection of reusable programs, used by both industrial and open software client projects to help achieve shorter development cycles and higher quality software [START_REF] Mccarey | Knowledge reuse for software reuse[END_REF]. Many of these libraries are open source software and are readily available through online repositories such as the GitHub1 repository. To incorporate bug fixes and new features, open source library projects often release newer and improved versions of their libraries. Based on user feedback, libraries evolve faster to reach the market, making it difficult for client projects to keep up with the latest version.

Ideally, a client user of a library should adopt the latest version of that library. Therefore, it is recommended that a client project should upgrade their library version as soon as possible. However, the latest version is not always better than previous versions [START_REF] Kula | Trusting a library: A study of the latency to adopt the latest maven release[END_REF][START_REF] Mileva | Mining trends of library usage[END_REF], as adoption of the latest version may include additional developer efforts to test and integrate changed features [START_REF] Mäntylä | On rapid releases and software testing: A case study and a semi-systematic literature review[END_REF][START_REF] Plate | Impact assessment for vulnerabilities in open-source software libraries[END_REF][START_REF] Tufano | When and why your code starts to smell bad[END_REF]. Developers of client projects may be especially wary of library projects that follow a rapid-release style of development, since such library projects are known to delay bug fixes [START_REF] Daniel Oyetoyan | A decision support system to refactor class cycles[END_REF]. Recent studies investigated the dependency relationships between evolving software systems and their libraries [START_REF] Kula | Trusting a library: A study of the latency to adopt the latest maven release[END_REF][START_REF] Kula | Visualizing the evolution of systems and their library dependencies[END_REF][START_REF] Yano | Verxcombo: An interactive data visualization of popular library version combinations[END_REF]. These tools makes it possible for developers to clarify and visualize these dependencies and aim to guide developers who are selecting possible candidate libraries for an upgrade.

In this study, our main goal is to better understand the relationship between the adoption of library versions and the library release cycle. Specifically, we conducted an empirical study of the release cycle of 23 libraries and how they were adopted by 415 Apache Software Foundation (ASF) client projects. These 23 libraries were used by over 50 software projects of our target ASF client projects. To guide our research, we address the following two research questions:

RQ1: Does the release cycle of a library project influence when it is adopted by a client project?

Recent studies [START_REF] Mäntylä | On rapid releases and software testing: A case study and a semi-systematic literature review[END_REF][START_REF] Plate | Impact assessment for vulnerabilities in open-source software libraries[END_REF][START_REF] Tufano | When and why your code starts to smell bad[END_REF] have found that open source software often has many issues soon after its release. Often these libraries are reactive in fixing issues based on user feedback. In other words, these software may be harmful in the early period after the release. Therefore, for RQ1, we would like to understand the effect of client project adoption on shorter release cycles.

RQ2: Does the release cycle of a library project influence whether the latest version is adopted by a client project?

Recent studies have shown that the newest version of a library is not always adopted by many client projects. For example, client projects may decide not to adopt the latest version to avoid untested bugs, especially if the library project has a shorter release cycle. Therefore, for RQ2, we would like to understand the effect of adopting the latest client project on shorter release cycles.

Our findings show that software projects are quicker to update earlier rapidrelease libraries compared to library projects with a longer release cycle. Moreover, results suggest that software projects are more likely to adopt the latest version of a rapid-release library compared to libraries with a longer release cycles.

Background and Definitions

Motivation

Related work such as Almering et. al [START_REF] Almering | Using software reliability growth models in practice[END_REF], Goel et. al [START_REF] Goel | Software reliability models: Assumptions, limitations, and applicability[END_REF] and Yamada et. al [START_REF] Yamada | S-shaped reliability growth modeling for software error detection[END_REF] all investigate when a software is ready to be used. These works use the Software Reliability Growth Model (SRGM) of the software evolution process to grasp the process of the convergence of defects discovered in software as the 'growth curve of the S-Shape (Sigmond curve)'. Similarly, Mileva et. al [START_REF] Mileva | Mining trends of library usage[END_REF] evaluated a library by its library usage by clients.

Building on this work, we conducted an exploratory investigation of when developers adopted versions of a library. Fig. 1 shows the release date (broken lines) for the library log4j and the number of ASF projects (solid lines) which have adopted the new library version in a time series. The figure shows users of the popular log4j library, mined from 797 software projects. From this work, we highlight two points: (1) library adoption is not organized, with no clear patterns of migration and (2) in many cases the latest version is not always selected as the default option. For instance, in Fig. 1 we can see ver.1.2.14 is still being used by some client projects (red dotted circle), even though the latest version is ver.1.2.17.

! " #! #" $! $" %! %" &! &" $!!#!#!# $!!#!&$# $!!#!'!( $!!###$) $!!$!%#) $!!$!)!" $!!$#!$% $!!%!$#! $!!%!"%# $!!%!(#' $!!&!#!* $!!&!&$" $!!&!'#% $!!&#$!# $!!"!%$# $!!"!)!( $!!"#!$) $!!*!$#& $!!*!*!& $!!*!($$ $!!)!##! $!!)!&%! $!!)!'#' $!!)#$!* $!!'!%$" $!!'!)#% $!!'#!%# $!!(!$#' $!!(!*!' $!!(!($* $!#!!##& $!#!!"!& $!#!!'$$ $!#!#$#! $!##!%%! $!##!)#' $!####!" $!#$!$$% $!#$!*#$ $!#$!(%! $!#%!##' $!#%!"!' $!#%!'$* $!#%#$#& $!#&!&!% $!#&!)$$ $!#&##!( $!#"!$$) $!#"!*#) $!#"#!!" $!#*!#$% $!#*!"#$ !"#$%&''()'"*%& #+$+' #+$+( #+$+#$ #+$+#% #+$+#& #+$+#" #+$+#",
In this paper, we define the "release cycle" as the time until a new version is released. As a cycle, usually a project will have a fixed release timing from as quickly as 1 day to a span of across several years. Due to agile development trends, we assume that the release cycles may become faster. For instance, the Google Chrome project and the Mozilla Firefox project are working on rapid release to develop a new version in 6 weeks [START_REF] Khomh | Do faster releases improve software quality?: An empirical case study of mozilla firefox[END_REF]. A rapid-release cycle is beneficial in that it can fix a bug and make a new component quickly. Sometimes, these projects can be reactive in bug fixing, for example, projects can get feedback from users soon after their release [START_REF] Mccarey | Knowledge reuse for software reuse[END_REF]. However, this rapid release style creates an influx of releases, which is likely to further confuse users on when to adopt a new version. Therefore, our motivation is to investigate when and how software projects adopt a new library relative to their release.

Library Adoption and Release Timings

Fig. 2 describes the evolution and adoption of a library during different release cycles. We use this figure to explain how we measure the timing of adoption relative to each release, including the relative definition of the latest release. This example shows a project S and two libraries (A, B ). Library A has released versions A1 and A2, with A2 being the latest version. Similarly, Library B has released versions B1, B2, B3 and B4, with B4 being the latest version.

This example also shows library adoption. Specifically, we see that project version S3 imports the library A1, which is not the latest version at this point in time. This is because at this time, A2 was available for selection. S3 also imports library B3, which is the latest version at this time. However, we see that in the near future B4 will be released.

Empirical Study

Adopting the latest versions has the added benefits of new features, but adapting the latest version may also risk having untested bugs or removed features. Therefore, the goal of this study study is to understand the impact of the release cycle on the developers decision whether to wait for the next library release or quickly adopt the latest version.

Data Preparation

Table 1 shows the top 23 of 4,815 libraries which the 415 software projects used. In total, these 23 libraries were used by over 50 software projects. These libraries were originally extracted from 415 projects of 797 ASF projects which are using MAVEN dependency tool on July 21, 2016. To analyze the library adoption and release timings, we extracted histories of library dependency information.

Our dataset comprises of JAVA programs managed by the MAVEN dependency tool. MAVEN stores explicitly in meta information files (POM.xml). The meta information contains the libraries' names and the version number in which the software is adopted. By tracking the history of the POM.xml in a version control system, for any software, we can know when and which library version has been adopted.

Clustering Libraries by Release Cycle

In order to evaluate the impact of the release cycle, the rank and grouping of libraries based on their release cycles is needed. Hence, for each library, we compute and assign a [START_REF] Breiman | Machine Learning[END_REF] variable importance score for each library. We then use the Scott-Knott test [START_REF] Scott | A Cluster Analysis Method for Grouping Means in the Analysis of Variance[END_REF] to group libraries into statistically distinct ranks according to their release periods. The Scott-Knott test is a statistical multicomparison procedure based on cluster analysis. The Scott-Knott test sorts the percentage of release periods for the different libraries. Then, it groups the factors into two different ranks that are separated based on their mean values (i.e., the mean value of the percentage of release periods for each library). If the two groups are statistically distinct, then the Scott-Knott test runs recursively to further find new groups, otherwise the factors are put in the same group. The final result of the Scott-Knott test is a grouping of factors into statistically distinct ranks. Table 2 shows the 6 categories (ie., C1, ..., C6) in which each of the 23 studied libraries were categorized. Based on these 6 groupings and the dataset, we are now able to address the research questions in our results.

Results

RQ1: Does the release cycle of a library project influence when it is adopted by a client project?

To answer RQ1, we use the clustered libraries groupings to compare release and adoption times. As a result, we make the following observations:

Observation1-All top frequent libraries are not released in one year. The boxplot in Fig. 3 shows the distribution of the periods between releases in each library. The libraries are sorted by the number of adopted software projects. While some library projects (e.g.,jetty-server, jackson-mapper-asl, mockito-all) often release new versions in one year, other library projects (e.g., commons-cli, servlet.api, commons-logging) often release new versions after more than one year. In particular, releases for the commons-cli project were = -,*,0),=%4%*,>304)? !"

!" !"#$#%# !# &'%#$#"()# !$ &)(#$#"*"# !% )&%#$#&*+# !& !!&## !' ""!&##
!!"#$#%&# !# '(&#$#%)*# !$ )!&#$#%'!# !% ++%#$#+)'# !& ,',&##

!'

,%%'## delayed for a consideration time.

Observation2-While older and established projects often release new versions after more than one year, beginner projects often release new versions in three months. Through our analysis, we found the different features between quick-release projects and late-release projects. Table 2 shows the working period with GitHub for each library project. Traditional projects that have worked for 10 years often release new versions after more than one year.

Observation3-While software projects have adopted the quickrelease libraries soon after the release, they have not adopted the late-release libraries as quickly. The boxplot in Fig. 4 shows the distribution of the adopted periods for our target projects in each library. We found that software projects have adopted the quick-release libraries (sixth group). In other words, they often adopt new versions soon after their release. On the other hand, software projects have adopted the late-release libraries (1st-2nd). This means that they do not adopt new versions quickly after the release.

In the group of the quick-release cycle, the adopted time of the mockito-all library is longer than the other libraries. To understand the reason, we analyzed software projects which adopted the mockito-all library. As we can see in Fig. 3, there are some outliers for mockito-all. Those are some versions which took a long time to release a new version. In particularly, version 1.9.0 was released approximately 1 year after releasing version 1.8.5. Also, version 1.10.0 was released approximately 2 years after releasing version 1.9.5. While waiting for the version 1.10.0, many software projects started using the mockito-all library just before releasing the version. In addition, although the Velocity library was adopted in a comparatively quick-release project, most software projects adopted the Velocity library a relatively long time after the release. The results show that many projects still started adopting the Velocity library after the project released the newest version on November 29th, 2010. Therefore, to answer RQ1, we find that: Software projects are more quickly updated than rapid release libraries compared to library projects with a longer release cycle.

RQ2: Does the release cycle of a library project influence whether the latest version is adopted by a client project?

To answer RQ2, we use the clustered libraries groupings to investigate whether the latest version of a library was adopted. As a result, we make the following observations:

Observation4-Software projects do not always adopt new library versions in their projects.

Fig. 5 shows the percentage of the newest or previous versions which software projects adopted from each library. The black and gray bars show the newest adopted version and the previous version applied to the software projects. We found 8%-85% of software projects adopted the new library versions. The commons-cil library often adopted the newest version to the software. On the other hand, the jetty-server library was often adopted the previous version to the software.

Observation5-While the quick-release library often adopts the newest version to the software, the late-release library often adopts the previous version to the software.

85% of the commons-cli library changes were applied to the newest version. This library project has released only 4 new versions during our target period (16 years). This number of releases is fewer than for the other library projects. Furthermore, one of the versions contained a new feature and maintenance bug fixes. The other two versions contained dozens of bug fixes. From this analysis, the project just maintained the initial a stable version.

On the other hand, only 19% of the servlet.api library changes were applied to the newest version although it is a late-release library. This library project has released only 7 new versions during our target period. To understand this strange result, we analyzed the history of applying the library. We found that version 2.5 is the majority even if the project released newer versions. 92% of the jetty-server library changes were applied to the previous version. This library project has released 267 new versions with most release intervals ranging from 0 to 20 days during our target period. 267 new versions show a clear contradiction to the commons-cli library and servlet-api library. Furthermore, we found that version 6.1.26 is the majority, even if the project released newer versions. In sum, to answer RQ2, we find that: Software projects are more likely to adopt the latest version of a rapidrelease library compared to a library with a longer release cycles.

Conclusions and Future Work

In this study, we revealed the relationship between the release cycle and the time it takes to adopt a library. Our results suggests that the shorter the release cycle, the shorter the time to be adopted, and that the rapid-release library will be adopted faster even in the same release cycle. Also, for libraries with majority versions, it is difficult to adopt the latest version. We find that it is especially difficult to generalize the reason for adopting a previous version. We think that the reasons are clarified by analysis of the released version. In detail, we believe that reasons will be clarified by analyzing the number of bug fixes and the number of added functions to the released version. These factors are important when selecting a library although there are still many challenges in finding other factors.

In this study, we considered the adoption situation only by the adoption time and whether the version is the newest adoption or a previous adoption of the OSS library. We confirmed that the version was adopted, but we did not also consider the state after adoption. When downgrading a version, we think that the reason should be extracted from the commit log. Further research is needed to confirm this. Also, there are cases where users changed to a version whose adoption was skipped or a library with the same function.

Fig. 1 .

 1 Fig. 1. Adoption trends based on client usage

Fig. 2 .

 2 Fig. 2. Release cycle and adoption period

3 .

 3 The release cycle of each library by boxplot. The target libraries are sorted by clustering (broken lines) from C1 to C6. The top figure shows the clustering number and the median of the release cycle days. .5>1-).?526+@

Fig. 4 .

 4 Fig. 4. The boxplot shows the adoption time of each library. The target libraries are sorted by clustering (broken lines) from C1 to C6.The top figure shows the clustering number and the median of the adoption time [days].

Fig. 5 .

 5 Fig. 5. Figure showing the adoption status rate of each library. The black bar means the adoption rate of newest version. The gray bar means the adoption rate of previous version. As showing by rate, the vertical axis means 100%

  Future work will include how to analyze these cases and to clarify what influence what this has on library selection.

Table 1 .

 1 Ranking of library users

	Rank	Library	Num Rank	Library	Num
	1 junit		305	16 easymock	67
	2 commons-logging	167	17 jackson-mapper-asl	60
	3 log4j		153	18 commons-cli	55
	4 slf4j-api	145	19 jackson-core-asl	53
	5 commons-lang	130	20 mail		53
	6 commons-io	122	21 velocity	52
	7 slf4j-log4j12	109	22 jcl-over-slf4j	52
	8 servlet-api	99	23 mockito-all	52
	9 commons-collections	98
	10 commons-codec	96	....	.....	....
	11 commons-httpclient	83
	12 guava		81	....	.....	....
	13 ant		73
	14 xercesImpl	69	....	.....	....
	15 jetty-server	68 4815 axis2-transports	1

Table 2 .

 2 Clustering by library release cycle and each library start of the release date

	Library	Date	Library	Date
	Cluster 6	Cluster 1
	commons-cli	Nov.6,2002 log4j	May.1,2002
	Cluster 5	guava	Sep.15,2009
	servlet-api	Sep.25,2001 commons-httpclient Aug.31,2001
	Cluster 4	slf4j-api	Mar.8,2006
	commons-logging	Aug.13,2002 slf4j-log4j12	Mar.8,2006
	commons-collections Apr.2,2002 jcl-over-slf4j	Mar.8,2006
	Cluster 3	mockito-all	Feb.28,2008
	commons-codec	Apr.25,2003 jackson-core-asl	Jan.14,2009
	commons-io	Jul.2,2007 jackson-mapper-asl Jan.14,2009
	Cluster 2	xercesImpl	Mar.29,2009
	mail	Feb.22,2000
	easymock	Aug.8,2001
	commons-lang	Nov.25,2002
	junit	Dec.3,2000
	xercesImpl	Jan.30,2002
	velocity	Jul.7,2002
	ant	Jul.19,2000

https://github.com

& 6 * ' ) ! & ' . -! 1 * +

Acknowledgments

This work was supported by the JSPS Program for Advancing Strategic International Networks to Accelerate the Circulation of Talented Researchers: Interdisciplinary Global Networks for Accelerating Theory and Practice in Software Ecosystem and the Grant-in-Aid for Young Scientists (B) (No. 16K16037).


Hanna Mäenpää
email: hanna.maenpaa@cs.helsinki.fi

Terhi Kilamo
email: terhi.kilamo@tut.fi

Tommi Mikkonen
email: tommi.mikkonen@tut.fi

Tomi Männistö
email: tomi.mannisto@cs.helsinki.fi

Designing for Participation: Three models for developer involvement in Hybrid OSS projects

Keywords: Open source, hybrid open source, community management

This paper reports governance practices of three profit oriented companies that develop OSS software with the help of their respective open development communities. We explore how the companies allow development contributions from external stakeholders, and what knowledge they let out of their internal software development activities. The results lay ground for further research on how to organize openness of the software development process in hybrid setups where the needs of different stakeholders are partly competing -yet complementary.

Introduction

Open Source Software (OSS) projects are based on peer-production, self-organization of individuals, and consensus-based decision making [START_REF] Benkler | Coase's penguin, or linux and the nature of the firm[END_REF]. They offer equal opportunities for both long-term members and newcomers in contributing to the development of the software product [START_REF] Riehle | Open collaboration within corporations using software forges[END_REF]. In the OSS environment, interactions and development decisions can take place in the absence of market-based or managerial models [START_REF] Benkler | Coase's penguin, or linux and the nature of the firm[END_REF]. Still, active communities that are independent of commercial influence are rare. When companies engage with OSS communities, their corporate direction must be aligned to that of the community's peer production-based approach [START_REF] Dahlander | How do firms make use of open source communities?[END_REF]. In this hybrid environment, the Bazaar truly meets the Cathedral [START_REF] Raymond | The cathedral and the bazaar[END_REF], and the forces that drive the collaboration are partly defined by both.

Hybrid OSS collaborations can form around various kinds of software products [START_REF] Bosch | From software product lines to software ecosystems[END_REF], emerging organically when companies become interested in existing OSS projects or when the projects are initiated by companies themselves by releasing software source code out with an OSS-compliant license. This can be done with the aim of attracting external contributors, increasing the innovative capability of the company or by attracting a niche market that could later be expanded [START_REF] West | The role of participation architecture in growing sponsored open source communities[END_REF][START_REF] Dahlander | How do firms make use of open source communities?[END_REF]. Engagement with OSS communities can be a means for strengthening brand awareness [START_REF] Dahlander | How do firms make use of open source communities?[END_REF]. The strategy can be especially important for small and medium sized companies, helping to diversify their product offerings, taken that the companies have sufficient resources and technological competencies for building effective and reciprocal collaborations [START_REF] Colombo | Open innovation and within-industry diversification in small and medium enterprises: The case of open source software firms[END_REF]. As Hybrid OSS communities consist of a mix of companies and independent developers with varying motivations [START_REF] Gonzalez-Barahona | Trends in free, libre, open source software communities: From volunteers to companies[END_REF], finding a mutually beneficial collaboration model poses various challenges.

Several calls exist for further research on management practises in the hybrid OSS arena (De Noni et al., 2013) [START_REF] De Noni | The evolution of oss governance: a dimensional comparative analysis[END_REF]. [START_REF] Linåker | Requirements engineering in open innovation: a research agenda[END_REF] pinpointed the governance structures in open environments and the openness of the software product development process as interesting topics for future endeavors [START_REF] Linåker | Requirements engineering in open innovation: a research agenda[END_REF]. Hussan et al. ( 2016) invite research on practical implementations of the software development process to complement the current work in the academic landscape [START_REF] Munir | Open innovation in software engineering: a systematic mapping study[END_REF]. To address these calls, we investigate how three profit-oriented companies develop OSS-based products with their respective open source software development communities. We compare how they allow external contributors to access their development process and what knowledge they let out of the priorities and decisions that shape the future of the software. With this, we hope to provide new understanding on how the hybrid OSS development model can be formed and managed at the practical level and which factors can be used as design elements when organizing the community's collaboration model.

The rest of the paper is structured as follows. Section 2 describes typical characteristics of hybrid OSS communities, shedding light on the different styles of governance that companies can employ towards their communities. Section 3 presents our research approach for studying the collaboration practices of the case companies that are introduced in Section 4. Section 5 presents our findings, whereas sections 6 and 7 discuss and conclude the work.

Previous Work

Governance of OSS projects involves the means that are in place to steer the efforts of an autonomously working developer community [START_REF] Markus | The governance of free/open source software projects: monolithic, multidimensional, or configurational?[END_REF]. The governance structure of a community should support collaboration in between the stakeholders, to enable efficient work coordination, and to create an environment where motivation of participants is fostered so that the community can operate in a sustainable manner [START_REF] Markus | The governance of free/open source software projects: monolithic, multidimensional, or configurational?[END_REF]. It is not straightforward to create a productive and happy community -its boundaries and affordances must be consciously designed and managed [START_REF] Dahlander | How do firms make use of open source communities?[END_REF]. This can take form in different governance configurations that can be mandated from a governing organization or emerge and evolve slowly as a result of a collective learning process [START_REF] De Noni | The evolution of oss governance: a dimensional comparative analysis[END_REF].

While in community-driven projects decision-making power is distributed among the communitys members, in hybrid set-ups a strong leader for the development project can emerge in the form of a non-or for-profit organization. This host can act as a sponsor, providing for the infrastructure needed for developing the software [START_REF] Gonzalez-Barahona | Trends in free, libre, open source software communities: From volunteers to companies[END_REF]. This role allows the host to control the community's activities to an extent [START_REF] West | The role of participation architecture in growing sponsored open source communities[END_REF]. Here, the host entity can define on what premises stakeholders can hold various positions, as well as what privileges and responsibilities these roles bring [START_REF] West | The role of participation architecture in growing sponsored open source communities[END_REF]. Implementing these decisions requires careful consideration of the versatile motivations of the contributors: if the community's members feel their values are being compromised or that their opinions are not being heard, their motivation can deteriorate [START_REF] Shah | Motivation, governance, and the viability of hybrid forms in open source software development[END_REF][START_REF] O' Mahony | The governance of open source initiatives: what does it mean to be community managed?[END_REF]. Distributing knowledge and decision-making power aptly can help to achieve a symbiotic state where the community sees the company as an active co-developer of the software, rather than a "parasitic" business owner that outsources its selected tasks to the crowd [START_REF] Dahlander | A man on the inside: Unlocking communities as complementary assets[END_REF].

Policies and Practices

The governance model of a community can vary from free-form and spontaneous to institutionalized, well defined and hierarchical [START_REF] De Laat | Governance of open source software: state of the art[END_REF]. While the history of an OSS project is reflected in the ways the community functions, fundamentals of how the community can form and evolve are largely defined by the license of the software source code [START_REF] West | The role of participation architecture in growing sponsored open source communities[END_REF]. A fully open licensing strategy increases the projects ability to attract new developers [START_REF] West | The role of participation architecture in growing sponsored open source communities[END_REF], increasing the attractiveness of the software product in the eyes of its potential users [START_REF] Toral | Virtual communities as a resource for the development of oss projects: the case of linux ports to embedded processors[END_REF]. However, if the open development community is strong, this strategy may risk the host's influence on the software product [START_REF] West | The role of participation architecture in growing sponsored open source communities[END_REF][START_REF] Shah | Motivation, governance, and the viability of hybrid forms in open source software development[END_REF], possibly creating an unclear legal relationship between the company and its contributors [START_REF] Wolfson | Look before you leap: Legal pitfalls of crowdsourcing[END_REF]. This risk can be managed by keeping selected software assets proprietary to the company, creating a gate for the external developers [START_REF] Shah | Motivation, governance, and the viability of hybrid forms in open source software development[END_REF]. This allows the company to limit the open communitys possibilities to modify and re-use the software and also to choose in which aspects of the development process it wants the open community to participate in [START_REF] Shah | Motivation, governance, and the viability of hybrid forms in open source software development[END_REF].

In autonomous OSS projects, a set of freely accessible online tools are used to coordinate work, discuss its goals and deliver contributions [START_REF] Mockus | Two case studies of open source software development: Apache and mozilla[END_REF][START_REF] West | The role of participation architecture in growing sponsored open source communities[END_REF]. These sociotechnical systems constitute boundary objects of the community, helping its members to create personalized views on the status quo of the project. Principles according to which contributors should engage them can be implicitly known and embedded in the functionality the software platforms provide. Also, written guidelines and contributor agreements are used to establish how the community should work and what culture it should be built upon. When the development tools and related communications are openly accessible, the processes of requirements engineering, quality assurance and release management become transparent to the public. This, on its part, allows the external stakeholders to understand and practically influence the decisions that shape the software product. In this context, describing means for practical boundary-setting comprises the main contribution of this paper.

Research Approach

Case studies investigate phenomena in their natural context [START_REF] Yin | Case study research: Design and methods[END_REF] and aim to generate case-grounded theory that can be extended, confirmed, or challenged through replication in future studies [START_REF] Yin | Case study research: Design and methods[END_REF]. For this aim, we describe a mixedmethod case study of practices that three for-profit companies use in building commercial OSS software in collaboration with their respective, hybrid developer communities. With this, we aim at answering the following research questions:

-RQ1: How can a software process be organized to allow a hybrid OSS collaboration model? -RQ2: What factors can be used to affect openness of the collaboration model?

West and O'Mahony (2008), emphasize the role of accessibility of tasks and transparency of knowledge as important building blocks of the participation architecture in OSS communities [START_REF] West | The role of participation architecture in growing sponsored open source communities[END_REF]. Inspired by this, a research instrument of nine questions (See Table 1) was composed. First five questions (A-E) address accessibility, whereas the four additional questions (F-I) address what knowledge host companies let out of their internal development process.

Answers to these questions were sought by exploring of freely available online documentation, such as the project's wikipedia and contributor agreements. Validity of the findings was evaluated by interviewing an employee of each case company, using the nine question research instrument as a basis for semi-structured interviews. Each answer was coded with a three-step scale from 0 to 2 where number zero represented that the matter is unconditionally closed from the open community. Number one was set to describe that the topic was open to the community to a limited degree. Number two was set to represent that the matter is fully open to the development community to know about or act upon independently. This triangulation of sources and viewpoints, is hoped to increase validity and fitness of the study design for replication in different environments [START_REF] Yin | Case study research: Design and methods[END_REF].

Case Companies

This study focuses on the collaboration practices of three profit-oriented companies that base their businesses on products created in close collaboration with OSS communities. We describe how the companies have arranged their software development processes to allow receiving contributions from external stakeholders. The first case company, Qt Company Ltd., acts as a single vendor for the Qt software, a framework that can be used to develop applications for desktop computers, embedded systems and mobile devices. The Qt project was established in 1991 and was first incorporated by its original developers in 1993. After several commercial acquisitions, the current set-up emerged in 2014. Qt is distributed as free3 commercial versions. While the source code of Qt is open for anybody to view, the commercial license grants full rights to develop and disseminate proprietary Qt applications. The company offers support and complementary software assets for its paying customers. Size of the community that develops the Qt framework is approximately 400 persons while the number of application developers ramps up to approximately a million.

The second case company, Vaadin Ltd. produces an application development framework that can be used to build interactive web applications that run on most operating systems and browsers. The software (Later: Vaadin) is offered with the Apache 2.0 license. It was initially developed as an add-on for an existing OSS product in 2002 from which an independent release was made in 2006. The development project has since been hosted by a company that offers online training, consultancy and sub-contracting of application projects. Development of Vaadin is dominated by the host company, and an application developer ecosystem of approximately 150 000 individuals exists. This is complemented by a developer community which has produced approximately 600 add-ons for the software.

Our third case is the Linux-based operating system Sailfish OS for mobile devices. Its history originates from a software that was released from Nokia as open source in 2011. The current host of Sailfish OS is Jolla Ltd, a startup that sells both proof of concept mobile devices and distributor licenses for the OS. The technical architecture of Sailfish OS is layered and parts of the software, including user interface libraries, are proprietary to the host company. The rest of the layers entail work from several OSS communities, such as Qt and the independent, community-driven project Mer. The Mer software alone comprises of packages that are using various FOSS licenses such as GPL, LGPL, BSD, and MIT. The company uses several crowdsourcing tactics for acquiring feedback about the quality of Sailfish OS. Even with only three projects, the cases reveal the versatility of possible governance configurations.

Findings

The Qt, SailfishOS and Vaadin open source communities were found to share significant similarities. For all, a central company acted as a host for the project, sponsored development platforms and participated in development tasks. All hosts advocated for dissemination of the software and arranged communitybuilding activities. In all cases, the host company controlled contents, scope and timing of the software releases. All shared the practice of coupling an external, peer production driven development community with a company internal development process that was exposed to outsiders to a limited degree. Differences were found in which tasks external contributors can participate in and which parts of the development process was transparent for outsiders. Table 1 and Figure 1 summarize these differences.

Access to Development Tasks

Host companies welcomed code contributions from the open community to varying degrees. In the Qt project, any person could access the workflow coordination tool 4 and assign oneself for a task. Also the tool that supported the code review process 5 was freely accessible. An approval from two humans was required for accepting a code contribution. Typically the code reviewers were, but were not required to be dedicated maintainers of the software. Partial automation of the testing process facilitated the work of code reviewers. Vaadin Ltd. presented a more restrictive approach. The work flow coordination tool 6 was accessible for all, yet the company required code authors to write extensive test cases for their submissions. From there, the code was reviewed by dedicated employees of the host company. This arrangement limited community-drivenness of the development process considerably. Jolla Ltd. did not offer access to work flow coordination tools of the complete Sailfish OS software. Instead it directed contributors to the Mer project's issue management tool 7 . From there, developers themselves needed to identify which part of the software's architecture their improvement considered, which required the developers to be moderately knowledgeable in terms of the software architecture before being able to contribute. A significant part of the development process was kept private by the host company, which did not let out knowledge about the status of the code integration process. To yield input from nontechnical users, the company deployed a question and answer forum where users of the software could report and triage defects related to the user experience of the software, yet without any guarantees on the uptake or their work.

Influencing Development Priorities

As Qt and Vaadin received most of their requirements from users of their software, their internal development efforts were directed towards fulfilling the needs of their paying customers. In the Qt project, the openly accessible, detailed workflow management system 8 made development priorities clearly distinguishable. Development of Vaadin was largely carried out under the terms of the host company, however input for feature-level priorities were sought from the community by voting on a pre-selected set of features. In the Sailfish project, the development was driven by technical debts that become inherited from the software architectures reliance on the external, independent OSS projects. The situation was largely focused on ensuring that the lower levels of architecture would support decisions made for the proprietary user interface layer.

Becoming an Actionable Developer

Practices on who can accept code contributions varied in between the projects. In the Qt project, both the core developer-and maintainer teams consisted of stakeholders of many organizational affiliations. These roles could be achieved through gaining individual merit and were open for anyone to pursue. In the case of Vaadin, the role was considered to be open for the community members, yet in practice the strict requirements for contributions made it very hard to enter the role. In the case of Jolla, the MerOS -community was genuinely community driven, welcoming many types of contributions from outsiders. However, the Mer consisted only a fraction of the Sailfish OS, and the host company's software developers occupied the many of the key positions in the community.

Discussion and Implications

The various hybrid OSS collaboration models assumed by the companies reflect the mission of the company and its business models. While origins of the project plays a role in how a hybrid community's governance model is built [START_REF] Schaarschmidt | How do firms influence open source software communities? A framework and empirical analysis of different governance modes[END_REF], licensing, technical architecture and development tools provide a framework in which the participation architecture of a community can be built [START_REF] West | The role of participation architecture in growing sponsored open source communities[END_REF]. Based on our study, we can provide some implications for the factors that can be used to affect the ways in which a host company can manage its boundaries in terms of accepting contributions from open communities.

The participation of external stakeholders can be restricted by licensing [START_REF] West | The role of participation architecture in growing sponsored open source communities[END_REF] or by regulating access to the source code by keeping selected software assets proprietary to the company [START_REF] Shah | Motivation, governance, and the viability of hybrid forms in open source software development[END_REF]. Employing a distributed repository strategy proved effective in limiting the possibility of less knowledgeable hobbyists to take up development tasks. Opportunities for becoming a developer can be limited to a specific group of people by requiring a certain level of personal merit and initial or complementary contributions. At an extreme, contributors may be subject to a personal selection by members of the community or even by the host company before becoming an actionable developer.

An important design factor is what tasks a certain role withholds and who are allowed to perform them. Prioritization of tasks can at be the sole responsibility of the host company, or of a selected group of people such as maintainers who have gained their position through personal merit. At an extreme, prioritization can be open to anybody who can access the socio-technical systems or it can be acquired from unrelated, non-technical users by establishing e.g. online customer communities. In all cases, the host company can always define which input from the community it will use in its internal processes.

Community-drivenness requires a critical mass of external contributors [START_REF] Dahlander | Penguin in a new suit: a tale of how de novo entrants emerged to harness free and open source software communities[END_REF]. This requirement can be eased by partial automation of the development process such as requirements prioritization or quality assurance. Even though testing and integration processes are supported with automation, it can be required that the final decisions are made in consensus by humans. Limiting this set of people provides a means for adjusting community drivenness of these processes. In this context, strength of the initiation rite for acquiring a certain role could be an interesting topic for future research.

Considering the level of openness: While the Qt company clearly pushed openness to the extreme, its community was found to be the most mature of the three we studied. While Qt started as a community-created project -although arguably with business reasons to do so -the company-created Vaadin project migrated to the open development model only after the it had gained a competitive edge. Sailfish, the newest entrant to the OSS market, was found to be very restricted when dealing with contributions that come from outside of the company. Vaadin represented the middle ground, although they put even more weight on the developers' views regarding direction of development and maturity of the product. In align with Schaarsmidt et al. [START_REF] Schaarschmidt | How do firms influence open source software communities? A framework and empirical analysis of different governance modes[END_REF], we find that these company-created projects seemed to maintain more control when compared to their community-driven counterparts.

Limitations. This study dealt with three OSS development communities that were selected to be as different as possible in terms of both age and purpose of their software products. Therefore, the generalizability of the results is limited and further research on projects that are both more similar in nature and of a larger scale is required. The question of representativeness limits the possibilities to generalize the study results. However, this limitation neither invalidates the findings nor prevents future studies from replicating the approach to evaluate whether they apply fully or partially in other types of hybrid OSS communities.

Conclusions

In this paper, we have investigated how hybrid OSS communities can be built to acquire contributors from company -external individuals. These communities, relying on open source software but mixing commercial and volunteer-based activities in their operations, have become an important way to create software systems for various contexts.

Based on the findings, it is clear that companies that use the hybrid OSS development model can act in different ways, leveraging either closed or open practices to their business interests. A trend in the cases we have studied, it seems as the community matures, the level of openness increases, fostering community-driven peer production. However, the number of companies in the study is far too low to propose conclusive results.

The role of the open development community and the principles according to which individuals can meaningfully participate in the development are essential design factors of the hybrid OSS development model. How these should be defined and managed requires careful consideration on how much knowledge and influence should be released to the open development community, how different roles and privileges can be gained and how autonomously the community should be allowed to steer the development of the software product.

Table 1 .E 1 F 1 G 0 H 0 I 0 Fig. 1 .

 1110001 Fig. 1. Comparison of the three models.

GPL,LGPLv3

Jira

Git issues