Andrea Capiluppi
email: andrea.capiluppi@brunel.ac.uk

Klaas-Jan Stol
email: klaas-jan.stol@lero.ie

Cornelia Boldyreff
email: c.boldyreff@uel.ac.uk

Exploring the Role of Commercial Stakeholders in Open Source Software Evolution

It has been lately established that a major success or failure factor of an OSS project is whether or not it involves a commercial company, or more extremely, when a project is managed by a commercial software corporation. As documented recently, the success of the Eclipse project can be largely attributed to IBM's project management, since the upper part of the developer hierarchy is dominated by its staff. This paper reports on the study of the evolution of three different Open Source (OSS) projects -the Eclipse and jEdit IDEs and the Moodle e-learning system -looking at whether they have benefited from the contribution of commercial companies. With the involvement of commercial companies, it is found that OSS projects achieve sustained productivity, increasing amounts of output produced and intake of new developers. It is also found that individual and commercial contributions show similar stages: developer intake, learning effect, sustained contributions and, finally, abandonment of the project. This preliminary evidence suggests that a major success factor for OSS is the involvement of a commercial company, or more radically, when project management is in hands of a commercial entity.

1 This happened with Netscape Navigator (then Mozilla) when Netscape Communications Corporation (NCC) released it as open source, but without further evolving it.

Introduction

Governance and control in Open Source Software (OSS) has been dramatically changing [START_REF] Santos | The inextricable role of organizational sponsorship for open source sustainability[END_REF]. The traditional volunteer-based OSS project model is now being accompanied by sponsored OSS, where commercial stakeholders provide effort beyond voluntary programmers. It has been argued that OSS projects have become increasingly hybrid with respect to this type of contributing stakeholders [START_REF] Capra | An empirical study on the relationship between software design quality, development effort and governance in open source projects[END_REF].

Since their inception in the early 1980s, OSS projects were mostly volunteer-based (or Traditional OSS, right end of Figure 1), heavily relying on personal efforts and nonmonetary recognition, and reportedly suffering from communication and coordination problems [START_REF] Crowston | Free/libre open-source software development: What we know and what we do not know[END_REF].

Nowadays, so-called Sponsored OSS projects have also been documented as more similar to Closed Source systems (as in far left of Figure 1). They could be industry-led OSS projects, where a commercial stakeholder plays a major role in the development and decision making, as in the case of the Eclipse project by IBM [START_REF] Merlo | Linear complexity object-oriented similarity for clone detection and software evolution analyses[END_REF][START_REF] Mens | The evolution of Eclipse[END_REF][START_REF] Hou | Studying the evolution of the Eclipse Java editor[END_REF][START_REF] Wermelinger | Analyzing the evolution of eclipse plugins[END_REF].

They can also be industry-involved OSS projects when they are driven by an OSS community, but often have one or several companies or institutions (e.g., universities) among their stakeholders, as in the case of the Moodle Content Management System (CMS) [START_REF] Capiluppi | Engaging without over-powering: a case study of a floss project[END_REF].

Fig. 1. Scenarios of development of OSS projects

Both the industry-led and industry-involved scenarios introduce new challenges to OSS projects: the first is based on one (or a small subset of) critical stakeholder(s), which could eventually halt the project if they decide to abandon it 1 . In the case of Eclipse, for example, IBM staff have been identified as the top contributors, with only a few external developers working on the core system [START_REF] Wermelinger | Using formal concept analysis to construct and visualise hierarchies of socio-technical relations[END_REF]. For Community OSS, especially in the case of large and complex OSS systems, there is a need of proper incentives for different types of stakeholders, with complementary expertise and requirements, in particular when their contributions are relevant to a system's core functionality.

This paper aims to explore these three scenarios and to study whether the involvement of commercial companies can help sustaining the evolution of OSS projects. To that end, the paper presents different analyses of the evolution of a commercial and a traditional OSS systems (Eclipse and jEdit), sharing the same application domain, and one community OSS project (Moodle).

By exploring the type of activities performed by commercial stakeholders, and by comparing the results achieved by similar OSS projects (sharing the same application domain, but with different involvement of stakeholders), this paper explores a research area that only recently started to be covered in the literature [START_REF] Robles | Evolution of the core team of developers in libre software projects[END_REF][START_REF] Robles | Corporate involvement of libre software: Study of presence in debian code over time[END_REF][START_REF] Schaarschmidt | Divide et impera! the role of firms in large open source software consortia[END_REF].

Terminology

Existing literature typically distinguishes between community-managed (also called autonomous [START_REF] Shibuya | Understanding the process of participating in open source communities[END_REF]) and sponsored communities. However, current terminology for this has some issues. For instance, OSS projects that are led by firms are referred to as commercial OSS, whereas an OSS project that involves commercial stakeholders (companies), but is led by an OSS community (consisting of "traditional" community members) is referred to as Community OSS. We argue that both terms are not precisely defined and need further refinement. Commercial OSS suggests that profit is made from the OSS project. The term "Community OSS" does not clearly distinguish projects that involve companies from "traditional" OSS projects (that do not involve companies). Therefore, in this paper we propose the following new terminology for the various models of involvement:

Traditional OSS projects are those projects in which no companies are involved. Industry-involved OSS projects are projects in which commercial firms are involved as contributors, but the project is still managed by the "community".

Industry-led OSS projects are projects that are led by a commercial firms. The wider community can contribute (as with any OSS project), but since a company has control over the project, it defines the evolution strategy.

Together, industry-involved and industry-led projects are Sponsored OSS projects, whereas industry-involved and traditional projects are both forms of Community projects (see Figure 1) as they are led by a community (as opposed to a company).

Structure of this paper

The remainder of this paper is structured as follows: Section 2 presents the goals, questions and metrics of the study. Section 3 presents the research design. Sections 4 and 5 presents the Eclipse and jEdit case studies, respectively. Section 6 focuses on the Moodle system as an example of an industry-involved OSS system, and explores the relevance of the commercial stakeholders, and how they differ from individual developers. Section 7 discusses the results followed by conclusions in Section 8.

Background and Related Work

This section provides a brief overview of relevant background and related studies. Most reports on participation of firms in OSS projects present results from large-scale surveys.

Bonaccorsi and Rossi studied contributions to OSS projects by commercial firms. They conducted a large-scale survey among 146 Italian companies that provide software solutions and services based on Open Source Software [START_REF] Bonaccorsi | Contributing to os projects. a comparison between individual and firms[END_REF]. One of the findings was that approximately 20 per cent of companies were coordinating an OSS project. Furthermore, almost half of the companies (46.2%) had never joined an OSS project. It is important to note that these results were published in 2004, and that these numbers may have changed significantly over the last eight years; we suggest that a replication of this study would be a valuable contribution.

Bonaccorsi and Rossi have further studied (using data from the same survey) motivations of firms to contribute to OSS projects [START_REF] Bonaccorsi | Intrinsic motivations and profit-oriented firms. do firms practise what they preach?[END_REF][START_REF] Rossi | Why profit-oriented companies enter the os field?: intrinsic vs. extrinsic incentives[END_REF].

Bonaccorsi et al. [START_REF] Bonaccorsi | Business firms' engagement in community projects. empirical evidence and further developments of the research[END_REF] have investigated whether and how firms contribute to OSS projects. Their study investigated which activities firms undertake in OSS projects, as well as whether the presence of firms affect the evolution of OSS projects. To address these questions, Bonaccorsi et al. conducted a survey of 300 OSS projects hosted on SourceForge.net. They found that almost one in three of the studied projects had one or more firms involved. In a survey of 1,302 OSS projects by Capra et al. [START_REF] Capra | A survey on firms' participation in open source community projects[END_REF], similar results were found, namely that firms were involved in 31% of the projects. Different types of involvement were identified: (1) project coordination, (2) collaboration in code development, and (3) provision of code. Capra et al. [START_REF] Capra | A survey on firms' participation in open source community projects[END_REF] made a slightly different classification of participation models: the Management model (for project coordination), the Support model (sponsoring through financial or logistic support) and the Coding model (contributing code, bug fixes, customization, etc.). In most cases, it was found that the firms founded the OSS project, but in some cases firms took over by replacing a project's coordinator.

Aaltonen and Jokinen [START_REF] Aaltonen | Influence in the linux kernel community[END_REF] studied the influence in the Linux kernel community and found that firms have a large impact in the project's development.

Martinez-Romo et al. [START_REF] Martinez-Romo | Using social network analysis techniques to study collaboration between a floss community and a company[END_REF] have studied collaboration between an OSS community and a company. They conducted case studies of two OSS projects: Evolution and Mono.

Companies can sponsor OSS projects in different ways. Berdou [4] investigated the dynamics of cooperation in community-led projects that involve paid contributors, and proposed a framework to understand this relationship.

Dahlander and Magnusson [START_REF] Dahlander | Relationships between open source software companies and communities: Observations from nordic firms[END_REF] proposed a typology consisting of symbiotic (winwin), commensalistic (firm gains, community indifferent) and parasitic (firm gains, community loses) approaches to characterize firm-community relationships. These relationships only apply in community-led projects.

The last decade of research in OSS has well established the relationship between firms and OSS projects. This relationship has been shown to have a direct effect on a project's sustainability. However, what kind of effects this relationship has on a project's evolution has not been studied. Therefore, we set out to explore this by means of a comparative case study. The next section outlines the research design.

Research Design

This section presents the research design of the empirical study following the Goal-Question-Metric (GQM) approach [START_REF] Basili | The goal question metric approach[END_REF].

Goal

The long term objective of this research is to understand whether there are (and there likely will be) differences in the maintenance and evolution activities of OSS projects as long as commercial stakeholders join or drive the development.

Questions

This paper addresses the following research questions:

1. Are there differences in the evolution of similar-scoped OSS applications, as long as one (or more) commercial stakeholders play a major role in the development?

2. When considering projects in the same application domain, are different "categories" achieving different results or patterns of maintenance? 3. From an effort perspective, do commercial stakeholders behave similarly to individual developers?

Method and metrics

Given the exploratory nature of this topic, we decided to perform an exploratory multiple case study. Since this topic has not been studied in depth, this multiple case study can be considered as a revelatory case study [START_REF] Yin | Case Study Research: Design and Methods[END_REF]. Rather than seeking to make generalizations with respect to the influence of commercial stakeholders in OSS evolution, we have aimed at exploring this phenomenon with the purpose to identify more precise hypotheses that can be studied in more depth and with different research methods (e.g., surveys).

The choice of the studied projects was grounded in the fact that they are appropriate examples of the three types of involvement models mentioned earlier, and was also supported by the fact that the first author was familiar with these projects through previous studies [START_REF] Capiluppi | Engaging without over-powering: a case study of a floss project[END_REF][START_REF] Capiluppi | From "community" to "commercial" floss -the case of moodle[END_REF][START_REF] Wermelinger | Assessing architectural evolution: a case study[END_REF] as well as ongoing (as of yet unpublished) studies.

Our study is a quantitative analysis of the studied projects, for which two types of metrics are used: code metrics and effort metrics. These are discussed below.

Code Metrics Given the available (public) releases, a set of data was extracted from the studied projects: two systems (Eclipse and jEdit) are implemented mostly in Java, while Moodle is implemented in PHP, and partially relying on OO features, evidenced by a visible number of PHP classes. The terminology and associated definitions for these metrics are extracted from related and well-known past studies, for example, the definition of common and control coupling ( [START_REF] Arisholm | Dynamic coupling measurement for objectoriented software[END_REF][START_REF] Li | Object-oriented metrics that predict maintainability[END_REF][START_REF] Fenton | Software metrics: a practical and rigorous approach[END_REF]).

-Methods (or functions in PHP): the lowest level of granularity of the present analysis. Within this attribute, the union of the sets of OO methods, interfaces, constructors and abstract methods was extracted. -Classes: as containers of methods, the number of classes composing the systems has been extracted. Differently from past studies [START_REF] Merlo | Linear complexity object-oriented similarity for clone detection and software evolution analyses[END_REF], anonymous and inner classes [START_REF] Igarashi | On inner classes[END_REF] were also considered as part of the analysed systems. -Size: the growth in size was evaluated in number of SLOCs (physical lines of code), number of methods, classes and packages. -Coupling: this is the union of all the dependencies and method calls (i.e., the common and control coupling) of all source files as extracted through Doxygen2 . The three aggregations introduced above (methods, classes and packages) were considered for the same level of granularity (the method-to-method, class-to-class and the package-to-package couplings). A strong coupling link between package A and B is found when many elements within A call elements of package B. -Complexity: the complexity was evaluated at the method level. Each method's complexity was evaluated via its McCabe index [START_REF] Mccabe | Design complexity measurement and testing[END_REF].

Effort Metrics A second set of data was extracted based on the availability of CMS servers: this data source represents a regular, highly parsable set of atomic transactions (i.e., 'commits') which details the actions that developers (i.e., 'committers') perform on the code composing the system. Two metrics were extracted:

-Effort: the effort of developers was evaluated by counting the number of unique (or distinct, in a SQL-like terminology) developers in a month. -Output metrics: the work produced was evaluated by counting the monthly creations of, or modifications to, classes or packages. Several modifications to the same file were also filtered with the SQL distinct clause, in order to observe how many different entities were modified in a month 3 .

Industry-led Open Source Project: Eclipse IDE

The Eclipse project has attracted a vast amount of attention by researchers and practitioners, in part due to the availability of its source code, and the openness of its development process. Among the recent publications, several have been focused on the "architectural layer" of this system [START_REF] Wermelinger | Design principles in architectural evolution: a case study[END_REF][START_REF] Hou | Studying the evolution of the Eclipse Java editor[END_REF], extracting the relevant information from special-purposed XML files used to describe Eclipse's features and extensions (i.e., plugins) implementing them, in this way representing some sort of "module architecture view" [START_REF] Hofmeister | Applied Software Architecture: A Practical Guide for Software Designers[END_REF].

As recently reported, the growth of the major releases in Eclipse follows a linearly growing trend [START_REF] Mens | The evolution of Eclipse[END_REF], when studying the evolution of its lines of code, number of files and classes. The study on Eclipse's meta-data indicated that, over all releases, the size of the architecture has increased more than sevenfold (from 35 to 271 plugins) [START_REF] Wermelinger | Design principles in architectural evolution: a case study[END_REF].

The present study is instead performed at the method level, and on two release streams (trunk and milestones). Regarding Eclipse, 26 releases composing the stream of "major" and "minor" releases of Eclipse (from 1.0 to 3.5.1) and some 30 additional releases tagged as "milestones" (M) or "release candidates" (RC), were considered in this study, spanning some 8 years of evolution. For each release, we performed an analysis of the source code with the Doxygen tool. This latter analysis lasted a few hours for the early releases, but it required more than one day of parsing for the latest available releases, mostly due to the explosion in size of the project (490,000 SLOCs found in the 1.0 release of Eclipse, up to more than 3 million SLOCs found in the 3.6 releases 4 ). Overall, it required more than one month to perform the analysis on the whole batch of Eclipse releases.

The remainder of this section presents the results of the analysis of Eclipse. Subsection 4.1 presents the results of the evolution of the size of Eclipse. Subsection 4.2 presents the evolution of Eclipse's complexity.

Results -Eclipse Size

This study considered the "main" releases (3.0, 3.1, etc.), and the "milestone" releases (e.g., 3.2M1, 3.2M2, etc.) and "release candidates" (e.g., 3.3RC1, 3.3RC2, etc.) release streams of the Eclipse project. The overall growth is almost fivefold, while it is also evident from Figure 2 that the main stream of releases has a stepwise growth, the steps being the major releases 5 .

Fig. 2. Growth in the "main" branch of Eclipse

Major releases of Eclipse are regularly devoted to new features, while milestone and release candidates releases are devoted to maintaining existing ones (Figure 3). The milestones stream has a more linear path: plotting the number of methods against the "build date" of the relative release, a linear fit is found with an appropriate goodness of fit (R 2 = 0.98). The step-wise growth for the main release stream, and the linear trend for the milestones release also reflect what was found when studying the evolution of Eclipse at a larger granularity level, i.e. its plugins [START_REF] Wermelinger | Design principles in architectural evolution: a case study[END_REF].

Results -Eclipse Complexity

The study at the method level shows a distribution of the McCabe cyclomatic indexes which is constant along the two streams of releases (main and milestones) of Eclipse. This is visible when assigning the cyclomatic complexity of each method (cc i ) in the four following clusters:

1. cc i < 5 2. 5 ≤ cc i < 10 3. 10 ≤ cc i < 15

cc i ≥ 15

Figure 4 shows the relative evolution of the fourth cluster, and reveals a quasiconstant evolutionary trend (for reason of clarity, the other trends are not displayed, although they follow a similar evolutionary pattern). The amount of highly complex methods (cc > 15, [START_REF] Mccabe | Design complexity measurement and testing[END_REF]) present in the system never reaches the 2% of the overall system. As reported in other works, this shows a profound difference from other traditional Open Source projects, where this ratio (for C and C++ projects) has been observed at around 10% of the system [START_REF] Capiluppi | Studying the evolution of open source systems at different levels of granularity: Two case studies[END_REF].

Results -Eclipse Coupling

The number of couplings (i.e., unique method calls) has been counted for each of the two streams of releases. The set of added, deleted and kept couplings has been evaluated between two subsequent releases in each stream, and plotted in Figure 5. As shown, these findings confirm previous ones [START_REF] Wermelinger | Design principles in architectural evolution: a case study[END_REF] regarding Eclipse's maintenance patterns: in the main stream, a large amount of modifications to its existing connections is made between minor and major releases, reaching more than 60% of new couplings added during the transition between the subsequent versions 2.1.3 and 3.0. On the other hand, the Milestones stream (Figure 6) confirms a recurring pattern, where the milestones show a great deal of added and removed couplings, whereas the Release Candidates (RC's) show a much lower activity in the same activity of coupling restructurings (the amount of shared couplings between two subsequent releases is not shown for clarity purposes).

Results -Eclipse Cohesion

The cohesion of classes or packages was measured by counting the number of elements connected with other internal elements, and then cumulated for all the classes or packages. Figure 7 shows the evolution of cohesion at the package level, and it confirms the observations achieved when evaluating the highly complex methods (Figure 4). Although there is a vast increase in the number of methods and classes, most of the connections are confined within the same package, keeping the cohesion constant throughout the life-cycle until the latest observed release. This measurement is also found higher in the earliest releases (some 73%), and declining sharply until release 3.0, where it stabilizes to some 69 -70% for the last 6 years.

Traditional Open Source Project: jEdit

Given the results from the above study, a community-driven OSS project (i.e., where no commercial company is "sponsoring" the development [START_REF] Capra | An empirical study on the relationship between software design quality, development effort and governance in open source projects[END_REF]) was studied in a similar way to evaluate and compare in some way the quantitative results of Eclipse. Although not exactly implementing all the features within Eclipse, the jEdit project also aims to be a fully-fledged IDE, benefiting from a large number of add-ons and plugins, independently developed and pluggable in the core system. Though any two software systems are always different to some degree, this study was not performed for the purpose of comparing features, but for the sake of observing whether the patterns observed in a very large and articulated project are similarly found in a much smaller project, and whether good practices should be inferred in any direction.

Similarly to the Eclipse project, the 14 releases available of jEdit were therefore collected on the largest OSS portal (i.e., SourceForge), from 3.0 to 4.3.1 (earlier releases do not provide the source code). Being a much smaller project, collecting the information via Doxygen was much quicker, both at the beginning of the sequence (57 kSLOCs, jEdit-3.0) and at the end (190 kSLOCs, jEdit-4.3.1). The 14 considered releases are the ones made available to the community, and span some 10 years of development.

Results -jEdit Size

The second system also shows a linear growth, with an adequate goodness of fit (R 2 = 0.97), albeit with a lower slope than what found in Eclipse, as to summarise a slower linear growth in Figure 8. A similar linear trend is found in the evolution of methods, classes and packages. The most evident difference with the evolution of Eclipse is the pace of the public releases in jEdit: between releases 4.2 and 4.3 some 5 years passed, although the jEdit configuration management system contains information on the ongoing activity by developers.

Results -jEdit Complexity

Regarding jEdit, the evolution of the complexity at the methods' level brings an interesting insight: for this project, it was found that more than 25% of the methods are constantly over a threshold of high complexity, at any time of jEdit's evolution. This complexity pattern has been observed also in other OSS systems [START_REF] Capiluppi | Studying the evolution of open source systems at different levels of granularity: Two case studies[END_REF]. Large and complex methods are typically a deterrent to the understandability and maintainability of a software system, and a vast refactoring of these methods has been achieved in the last two public releases, as visible in the graph, where a significant drop of highly complex methods is achieved even in the presence of a net increase in the number of methods.

Results -jEdit Coupling

The maintenance patterns of jEdit present a more discontinuous profile, with changes between major releases typically presenting large additions of new couplings (see Figure 9, bottom), and minor releases where less of such modifications were made. More importantly, the maintenance of couplings appears not to be planned, where the largest modifications (between 4.2 and 4.3) appear after a long hiatus of five years, and represent a full restructuring of the underlying code architecture, with added and deleted couplings representing three-times and twice as many couplings as the maintained ones, respectively.

Industry-involved OSS Project: Moodle

As per the definition of an industry-involved OSS project, Moodle's development is primarily centered around the OSS community, but various other actors have interest in its development. A number of organizations across the world are directly contributing to the development of Moodle by way of funding or contributing their expertise, and have been defined as "Moodle partners".

Similarly to the other two case studies, we extracted the size, complexity and cohesion of the PHP code contained in the publicly available releases6 : overall we studied some 90 releases of this project. By checking on the official website, it can be observed that Moodle was evolved in one single stream of release until version 1.7: from 1.8 onwards, several branches have been evolved at the same time (e.g., 1.7.x, 1.8.x, 1.9.x etc). For each of these branches we kept the results on size, coupling and complexity separated from the other branches.

Results -Moodle Size

As observed in Eclipse, the evolution of Moodle resembles a step-like pattern (see Figure 10), where the major releases consist of the addition of a large number of files, classes and functions, and the minor releases show smaller additions in all the measured metrics. From release 1.8 onwards, all the various branches maintain the same pattern as well, albeit the growth is intertwined in time with all the other branches (Figures 11 middle andbottom): during the interim releases between minor (e.g., 1.8) and development (e.g., 1.8.1) releases, the growth in number of functions, classes and source files is minimal, while the step-wise growth pattern is observed between minor releases (e.g., between 1.8 and 1.9). Therefore, for this system the increase in size has changed the approach to development, requiring the project to define and maintain various branches at the same time.

Results -Moodle Complexity

Since Moodle is written in the PHP programming language, which is based on procedural and object-oriented constructs, we evaluated the complexity of the functions contained in the source code. This was plotted per release, as above, and the percentage of highly complex functions tracked throughout. The summary in Figure 12 shows how the excessive complexity (i.e., the sum of functions whose McCabe cyclomatic index is > 15, and depicted in the continuous line) has been kept under control even though the system constantly increases the number of its functions (depicted as a continuous line in the same figure). What is quite evident is also the major refactoring that was undertaken between releases 1.x and 2.x. In the latter, a larger number of functions were introduced, in a step-wise growth, while parallel work was done to reduce the amount of complexity in existing and new functions, with a step-wise descent of highly complex functions.

Results -Moodle Coupling

The functions composing the releases of Moodle were analysed in terms of their connections, and which of the connections were added or removed between major and minor releases, and between branches. As done for the previous cases, releases were analysed by the Doxygen engine, extracting all the links between low level entities, that were later lifted to file-to-file dependencies.

As reported for the size growth, it becomes clear that the minor and development releases have become central in Moodle to perform several adjustments, that trail off in proximity of the next release, similarly to what is found in the Eclipse environment (see Figure 13, displaying the 1.7.x and 1.8.x branches of releases). This has evolved in Moodle: the earlier branches (e.g., Moodle-1.1.x or Moodle-1.2.x) did not display long sequences of development (e.g., only Moodle-1.1 and Moodle-1.1.1 have been released within the Moodle-1.1.x branch). With more recent releases, the pattern observed in Eclipse is also visible in Moodle, with longer sequences of development releases (14 development releases in Moodle-1.8.x, 17 in Moodle-1.9.x), in which fewer and fewer couplings are added and removed, until the release is being discontinued and not supported further.

Discussion

The two cases of Moodle and jEdit show that similar issues are faced by the developers: even if companies are involved in development of the Moodle project, they do not drive the development, as for Eclipse. Given it is taken for granted that industry-led OSS projects do not have an issue of long-term sustainability, industry-involved and traditional OSS projects need to address the issue of how to attract and maintain the existing contributors in the development loop. In the following subsections, we analyse how effectively developers and contributors are attracted and maintained within the two projects, and whether lessons learned can be drawn in both cases.

Contributions on the Periphery

In both the Moodle and jEdit projects, the "core" of the system is separated from the "plugins" or "contributors" section. We assume that contributing to the "core" of a project is more time-consuming, and requires more skills, than contributing to the "modules" or the "plugins" sections 7 . Therefore we investigated whether a sustained intake of contributors is achieved in Moodle and jEdit, or whether these projects face an issue in this respect.

Moodle -Two main directories are found in the CMS server: the core 'Moodle' directory (which makes for the public releases, that we consider as "core"), and the 'contrib' folder, organized in 'plugins', 'patches' and 'tools' (but not wrapped in the official releases). As visible in Figure 14 (left), the evolution of the core Moodle system follows the typical pattern of an early (or 'cathedral' [START_REF] Raymond | The Cathedral and the Bazaar[END_REF]) OSS project: few contributors are visible in the first months (mostly the main Moodle developer), with few other contributors being active in a discontinuous way. A further, sustained period is also visible, where the number of active developers follows a growing trend with peaks of over 30 developers a month contributing, and revealing a 'bazaar' phase [START_REF] Capiluppi | From the cathedral to the bazaar: An empirical study of the lifecycle of volunteer community projects[END_REF]. The main issue that is visible in the Moodle "core" system is revealed at around 3/4 of its life-cycle, where the number of active developers start to decline. From the point of view of the sustainability, we posit that this could represent a serious issue in the long-term evolution of this system.

On the other hand, the activity of Moodle has been devoted more and more to the 'contrib' folder, rather than in the 'core': this reflects a more and more distributed participation to the Moodle development, and a low barrier to entry, albeit not all the contributed modules are selected for inclusion in the publicly available releases. The overall distribution of changes throughout the Moodle evolution proceeds on a linear trend (R 2 = 0.78): in recent months, the inflection of productivity in the "core" Moodle has been balanced by the late growth of contributions to the other parts. That reflects a more and more distributed participation to the Moodle development, and a low barrier to entry, but several of the proposed modules have not been selected for inclusion in the main Moodle system. jEdit -The main difference between jEdit and Moodle in the intake of developers is visible in Figure 15 (below): albeit the 'core' (or 'trunk') is separated from the 'plugins', few contributors were added in the latter, following a cyclic development pattern overall. Differently from Moodle, the intake of contributors does not follow a linear pattern: the presence of developers in the "core" declines at around 3/4 of the life-cycle, and so does the number of contributors working on the periphery of the system. This makes jEdit even more brittle to sustainability issues, specifically around the intake of new developers.

Three-layered Contributions

The study of Moodle as an industry-involved OSS project resulted in an in-depth analysis of the types of contributors who actively produce code for the system. Interesting insights were discovered when studying each developer's actual contribution to the code: in a first attempt to categorize the intake, the contributions, and the developers leaving the project, three categories are clearly distinguishable, not based on the amount of effort inputed in the system, but purely on the length of the activity of each developer:

1. Sporadic developers: this refers to the extremely low presence of certain contributors in the development. Within Moodle, 60 developers have been active for just one month; other 70 developers have been active between 2 and 6 (not necessarily consecutive) months. 2. Seasonal developers: as reported recently [START_REF] Robles | Evolution of the core team of developers in libre software projects[END_REF], most OSS projects benefit seasonal developers, i.e., those developers who are active for a short period of time (we are not referring to 'recurring' or 'returning' developers). 3. Stable developers: those developers showing a sustained involvement (say, more than 24 months for the Moodle system). Both seasonal and stable developers can be part of the top 20% developing most of the system, as in the definition of 'generation of OSS developers' given in the past [START_REF] Bonaccorsi | Business firms' engagement in community projects. empirical evidence and further developments of the research[END_REF].

Some of the Moodle partners have been found acting as seasonal developers; the Catalyst partner8 has so far provided a large number of modifications to the core Moodle, by deploying several developers who became active contributors within the community. The profile of the contributed outputs is visible in Figure 16 (bottom), and can be defined as a 'seasonal' effort pattern, meaning a large contribution on a very specific time interval, and lower levels of effort before and after it. Comparing this curve to a selection of seasonal Moodle individual developers (Figure 16, top), a similar pattern is visible: an initial period of low commit rates, followed by a peak were a high level of contributions is observed, finally a leveling-off.

Limitations of this study

We are aware of a few limitations of this study, which we discuss below. Yin [START_REF] Yin | Case Study Research: Design and Methods[END_REF] lists four types of threats to validity, namely, construct, internal and external validity, and reliability.

Construct validity Construct validity is concerned with establishing correct operational measures for the concepts that are studied [START_REF] Yin | Case Study Research: Design and Methods[END_REF]. In this study, construct validity relates to the measures we have used to collect and analyze the data, namely, code metrics such as size, coupling and complexity, and effort metrics such as number of developers and number of modifications made. We argue that these are well established metrics that appropriately represent the concepts being studied.

Internal validity Internal validity is concerned with establishing a causal relationship. In our study, the relationship that we have explored is between the nature of the stakeholders (i.e., commercial versus non-commercial) and the evolution of OSS. The results of this exploratory study suggest that there is, in fact, an influence from the presence of commercial stakeholders. However, changes in evolutionary patterns may not be due to the involvement of commercial stakeholders. Further research is needed to establish the nature of this relationship in more detail.

External validity External validity is concerned with the extent to which findings of a study can be generalized to other settings. A common critique of the case study methodology is that findings cannot be generalized. However, the purpose of conducting case study research is not to look for statistical generalizability, such as aimed for in large-scale quantitative surveys, but rather to seek theoretical generalization [START_REF] Yin | Case Study Research: Design and Methods[END_REF]. In other words, in this paper we have started to explore a theory relating to the influence of commercial stakeholders on the evolution of OSS. We like to emphasize that our study is of exploratory nature, and as such serves the purpose of exploring our initial ideas and defining more focused hypotheses for further research.

Reliability Reliability of a study refers to the degree to which a study can be repeated and attaining the same results. One strategy to increase a study's reliability is to establish an audit trail [START_REF] Guba | Criteria for assessing the trustworthiness of naturalistic inquiries[END_REF]. Our audit trail consists of the extracted data as well as spreadsheets that contain the analysis.

Conclusions and Future Work

The terminology around the OSS phenomenon has been radically changing in the past few years. This research has studied how commercial stakeholders can have an influence on the evolution and maintenance of OSS systems. Eclipse has been studied as an industry-led OSS system, since it is backed by the IBM corporation; the Java IDE jEdit was selected as an exemplar of a traditional OSS system; while Moodle was chosen as an exemplar of industry-involved system, built mostly by the OSS community, although several commercial stakeholders have write-access to it. The public releases of each system, and their configuration management systems (CMS), were jointly analyzed, to determine the best type of information to draw results from.

The study of the releases allowed us to focus on the main points along the evolution of the studied systems. The industry-led OSS system presents several "best practices" of software engineering: low complexity of units, continuous evolution and regular maintenance cycles. The traditional OSS system, in the same application domain, achieves very different results: 1 in 4 units are too complex, discontinuous evolution, and the maintenance is not regularly achieved. Finally, the industry-involved system shows more and more regular patterns of evolution, increasing control of complexity and alignment of its maintenance cycles to multi-branch, large software systems with parallel maintained releases.

On the other hand, the study of the CMSs allowed the effort of the contributors to be tracked along the life-cycle of these systems, with the specific objective of determining issues in the sustainability of OSS systems. Analysing the industry-led project, we posit that it does not present (yet) issues of sustainability, as it is backed by a large corporation. The industry-involved project shows that the amount of active developers and the output produced follow an increasing, linear trend. Factors for these trends were found in the increasing number of contributions and plug-ins, and the presence of commercial partners driving the evolution, that act exactly as typical developers, joining in the projects, producing contributions, and then leaving. As observed, and different from Eclipse, the studied commercial stakeholder in Moodle is a seasonal contributor, after some time trailing off and leaving the project.

The study of the effort in the traditional system shows instead that, even with a sustained number of releases, jEdit has fewer and fewer developers in both the "core" system as well as in the periphery, showing more issues of sustainability than the other two cases.

What these findings demonstrate could have a profound impact on what is considered as "Open Source" development and raises the following questions:

-Is the presence of commercial stakeholders a necessary condition to achieve sustained evolution? -Are "traditional" OSS projects eventually destined to trail off and be abandoned? -Is the lack of adherence to basic software engineering principles an obstacle to OSS development?

These are fundamental questions to be answered by further research studies in order to understand how the OSS phenomenon will change in the future.

Fig. 3 .

 3 Fig. 3. Growth and maintenance patterns in the "milestones" branch of Eclipse.

Fig. 4 .

 4 Fig. 4. Patterns of highly complex methods (McCabe index > 15) in the main branch of Eclipse.

Fig. 5 .

 5 Fig. 5. Distribution of coupling in the main branch of Eclipse.

Fig. 6 .

 6 Fig. 6. Distribution of coupling in the milestones branch of Eclipse.

Fig. 7 .

 7 Fig. 7. Patterns of cohesion of the two branches of Eclipse.

Fig. 8 .

 8 Fig. 8. Evolution of size in jEdit

Fig. 9 .

 9 Fig. 9. Coupling in jEdit.

Fig. 10 .

 10 Fig. 10. Growth of size in the main branch of Moodle (up to release 1.7).

Fig. 11 .

 11 Fig. 11. Growth of size in the parallel branches of Moodle (after release 1.7).

Fig. 12 .

 12 Fig. 12. Evolution of complexity in Moodle (continuous line) and overall increase in number of functions (dashed).

Fig. 13 .

 13 Fig. 13. Added and removed couplings in Moodle (branches 1.7.x and 1.8.x).

Fig. 14 .

 14 Fig. 14. Active monthly contributors in the "core" (left) and in the overall Moodle project (right)

Fig. 15 .

 15 Fig.[START_REF] Dahlander | Relationships between open source software companies and communities: Observations from nordic firms[END_REF]. Active monthly contributors in the "core" and in the "plugins" parts of jEdit

Fig. 16 .

 16 Fig. 16. Output produced by one of the partners (Catalyst, top), as compared to seasonal developers in Moodle

http://www.doxygen.nl, supporting both the Java and PHP languages

In specific cases, specific committer IDs were excluded, when it was clear that they are responsible for automatic, uninteresting, commits; it was also excluded from this metric any activity concerning the 'Attic' CMS location (which denotes deleted source material).

[START_REF] Berdou | Insiders and outsiders: paid contributors and the dynamics of cooperation in community led f/os projects[END_REF] Statistics were collected with SLOCCount, http://www.dwheeler.com/ sloccount/

The overall size growth has been normalized to 1 for easing the reading of the graph.

A list of the releases (with the relative releasing date) since 2002 is available at http:// docs.moodle.org/dev/Releases

This is because writing plugins or additional modules, where the system is modular, should be possible without modifying other files, but just using the system's APIs.

http://www.catalyst.net.nz/

Acknowledgments

The authors wish to thank Dr Fernández-Ramil for his extensive comments on an earlier draft of this paper. We thank the two anonymous reviewers who provided constructive feedback on this paper. This work was supported, in part, by Science Foundation Ireland grant 10/CE/I1855 to Lero-The Irish Software Engineering Research Centre (www.lero.ie).


Jean-Paul Van
email: jean-paul.vanbelle@uct.ac.za

Mark Reed

OSS Adoption in South Africa: Applying the TOE Model to a Case Study

This paper presents a case study on the factors that influence the initial adoption of Open Source Software (OSS) in a large South African organization when implementing an OSS PBX platform. The theoretical foundation for this research draws on a number of academic frameworks and models, thus not only providing a practical illustration but also validating their usefulness in guiding OSS adoption.

Introduction

This paper explores the adoption of OSS in South Africa with a view to finding out how a South African (SA) company went about adopting OSS, uncovering what factors influenced the adoption and contributed to its sustainability in the postadoption period, and investigating how supportive theoretical OSS models are of successful adoption. The OSS adoption was ascertained within the Technology, Organisation and Environment (TOE) framework, with factors drawn from a number of other OSS models as discussed in below.

The research hopefully offers practical insights to organisations who are considering adopting OSS. Researchers may find that it sheds light on the usefulness of some theoretical frameworks and models.

Theoretical Framework

The theoretical framework was beased on the Technology, Organisational and Environmental (TOE) framework, which identifies three contexts in which an organisation functions and therefore may influence its ability to adopt technology and affect the process by which it accepts [START_REF] Lipert | Technological, organizational and environmental antecedents to web services adoption[END_REF] and implements a new technology [START_REF] Zhu | Electronic business adoption by European firms: A cross-country assessment of the facilitators and inhibitors[END_REF]. These contextual factors also influence the organisation's intent to adopt an innovation, and affect its assimilation process as well as the impact of the innovation on organisational performance [START_REF] Zhu | Electronic business adoption by European firms: A cross-country assessment of the facilitators and inhibitors[END_REF].

The technological context refers to the internal and external technologies available to the organisation which have a bearing on its productivity [START_REF] Lipert | Technological, organizational and environmental antecedents to web services adoption[END_REF] and encompasses existing technologies, both those in use within the organisation and the relevant technologies the organisation can draw on externally [START_REF] Zhu | Migration to open-standard inter organizational systems: Network effects, switching costs, and path dependency[END_REF]. They include elements of open source maturity and technology readiness. Dedrick & West [START_REF] Dedrick | Adoption of open source platforms: an exploratory study[END_REF] consider five technological factors, namely compatibility, complexity, relative advantage, trialability and observability. They identify the three most common variables linked to technology adoption as compatibility with existing technologies, relative advantage over current technologies and with complexity negatively influencing adoption. Relative advantage is the measure of how much of an improvement the new technology is relative to the existing one and is primarily measured in terms of cost and reliability [START_REF] Zhu | Migration to open-standard inter organizational systems: Network effects, switching costs, and path dependency[END_REF]. The software cost and risk model determines the cost and the risks of using open source [START_REF] Guliani | Open source for the enterprise[END_REF]. Failure to optimally manage the potential risks and rewards of open source will put IT organisations at an increasingly serious risk in the coming years [START_REF] Driver | Key issues for open-source software in 2007[END_REF].

The organisational context is characterised by a few descriptive measures, i.e. scope, size of the organisation and the slack resources available internally. Organisations have different competitive positions and roles for IT, and a high level of IT intensity has been shown to be proportional to open source adoption [START_REF] Kwan | A conceptual model for enterprise adoption of open source software[END_REF]. The innovation orientation of an organisation is related to the timing of adoption and the triggers prompts pertinent to adoption decision [3]. The centrality of IT to the business strategy is core to the willingness of the organisation to adopt open source [START_REF] Dedrick | Adoption of open source platforms: an exploratory study[END_REF]. Choice set and selection occur as a response to software adoption policy, but more importantly arise within the application context. This context exhibits the strategic significance of the specified system and consequently the equivalent weighted value for features, risk, cost and available products where the predilection of the buyer is restricted by a limited number of available choices [START_REF] Kwan | A conceptual model for enterprise adoption of open source software[END_REF].

The environmental context refers to the arena in which the organisation operates and conducts its business [START_REF] Zhu | Electronic business adoption by European firms: A cross-country assessment of the facilitators and inhibitors[END_REF]. The organisation is influenced by its competitors and by the industry itself [START_REF] Lipert | Technological, organizational and environmental antecedents to web services adoption[END_REF]. Environmental factors encompass factors such as rivalry and relations with buyers and suppliers [START_REF] Zhu | Migration to open-standard inter organizational systems: Network effects, switching costs, and path dependency[END_REF]. A regionally available appropriate skill set reduces the time investment and the cost of using open source [START_REF] Guliani | Open source for the enterprise[END_REF], although few certification programs exist for computer and network support professionals wanting to specialise in open source software [START_REF] Bruggink | Open source in Africa: towards informed decision-making[END_REF]. A useful conceptual framework for exploring the OSS skills is the Open Source Skills and Risk Tolerance model. This ascertains the capacity of the organisation to handle the risks intrinsic in open source adoption and produces a risk tolerance plan and profile [START_REF] Guliani | Open source for the enterprise[END_REF]. However, developer skills may be improved by the intellectual challenge of contributing to software development when they are granted access to source code [2]. Other barriers to the successful adoption of open source are the lack of resources and/or the availability of external technological resources as well as the lack of compatibility with current technologies and skill [START_REF] Holck | Identifying business barriers and enablers for the adoption of open source software[END_REF].

Research Methodology

In this research, a deductive, explanatory and qualitative research approach was taken. A qualitative case study approach was chosen because of the interdependence between variables and the non-measurability/intrinsic complexity of some of the variables. The aim is to provide richer and more subtle explanations than statistics can provide. The case study was a recent implementation of an open source PBX system, Asterisk, in one of the leading and largest medical health administrators in South Africa. The supporting data for the case study comes from semi-structured interviews with nine key decision makers within the organization: the Managing Director (Scheme Administration), MD (IT), Head of IT Infrastructure, Head of Telephony Solutions, the enterprise architect, the principal specialist, the senior manager, the software architect and the solutions architect in charge of the project.

Applying the TOE Model to the Adoption of an OSS PBX Platform in a South African Financial Services Company

The case takes place in one of the largest medical aid administrators in South Africa, with more than 2500 employees. They administer close to one million members and are one of the leaders in their field. They were faced with the important and high-risk decision to replace their PBX system in their 800-seat call centre. Negotiations with a number of proprietary vendors ensued, including their preferred communications provider, but no proprietary vendor could promise them the tight delivery times or required customizations. At that stage, they investigated Asterisk, an open source PBX system. The system was piloted, extensively customized and successfully put in production by the end of 2008. The case study was analyzed using the TOE framework and demonstrates the empirical validity and relevance of the factors outlined above.

Technology factors

Access to source code -The ability to access the source code was a key positive factor mentioned by most respondents in the case study: "The product itself is very basic, we're building around that to create exactly what we want"; "the ability to customize"; and "to be able to be creative" (Developer). They develop, maintain and support the OSS internally and they additionally post fixes for Asterisk PBX source code back into the community.

Complexity -Although the skill set to develop customized solutions around OSS products may require additional resources "the skills that you deploy to customize the solutions need to be a lot more experienced", the software architect did not perceive OSS products to be intrinsically more complex: "they are not more complex, it depends what level you look at it. At a source code level, I don't think they are more complicated." On the other hand, the head of Telephony opined that OSS may often lack a user-friendly GUI to administer it: "the only complexity that OSS PBXs introduce is that they don't have the easy or simplified configuration interfaces like proprietary PBXs".

Cost -The cost factor was never the initial key consideration. The major drives for the adoption were the quick deployment capability and the flexibility the solution provided: "the cost factor over time is not a huge factor, for me it was about getting a solution that can deal with the growth of the business" (MD of Schemes). In fact, management was nuanced about distinguishing between the zero licensing costs and the Total Cost of Ownership "Nothing in life is free. You got to have somebody who is supporting it … a Linux person, an Asterisk person… It's got a different cost of ownership model but, on the whole, in the end, as the maturity of the product grows, it does tend towards to being cheaper over time" (MD of IT). However, the cost savings were significant: "expensive carrier grade switches don't differ substantially in functionality to what Asterisk can do." An internal cost benefit analysis revealed a saving of OSS over proprietary in the region of R30 million (about US$ 4 million) over the 36 month budgeting period.

Compatibility -Because of the existence of standards bodies, compatibility was assured: "in the environment, they work with the de facto standards anyway" (MD of

IT). Critical to building an open source telephony platform was the fact that telephony equipment is produced to open telephony standards and the ability to source non-proprietary telephony components: "If that [standard peripheral devices] didn't exist, open source for this specific application would never have been an option." (Head of Telephony Solutions)

Trialability -This was important as indicated by the IT Infrastructure Manager: "We started playing with it (OSS PBX), and we realized that it was one hell of a product... that actually, this could work for us as an organization…" Reliability -Although initially there were stability problems, in the end they achieved a stable solution: "you just have to keep working at it to achieve the same amount of reliability" (Developer).

Maturity -Digium's commercialization of Asterisk PBX support was an important influencing factor. The fact that a third party organization had built a business around packaging and supporting the OSS solution signalled the broader market acceptance and continuity: "There is a 'keep alive' of the product [since] Digium has built a business around Asterisk. […] This tells me Asterisk will not drift sideways." (MD IT) This was in spite of the fact that they did not use nor intend to use Digium's services.

In this particular case study, some of the other technology factors (e.g. potential project forking, security issues and observability) did not seem to play a role.

Organisational factors

Firm context -Being in the highly competitive financial services industry, the organization is very IT intensive. One of the key differentiating factors in the industry is customer service and the ability to deliver new products and services quickly. The two MDs put it as follows: "Technology plays a big role in [our] positioning [for competitive advantage]" and "Technology is very dominant in our strategic thinking". However, the Senior Manager confirmed that the specific decision to go for Asterisk was not driven by competitive pressure explicitly.

Centrality of IT -IT and the ICT infrastructure is critical to the day-to-day functioning of the business. The communications infrastructure in particular is a critical business infrastructure component, so the replacement decision had a high risk profile. "... when the PBX is down, you are dead … it is the most business critical along the lines of our applications …" (Head of IT Infrastructure).

Open Source attitudes -The organization uses a combination of OSS and commercial applications so there were no critical attitudes to content with: "I don't think they had an attitude about Open Source Software. I don't think they were pro or against it" (Head of IT Infrastructure).

Standards attitudes -This is an important consideration in favour of open source: "I am very comfortable with [open source], they don't just change standards. I mean if you are busy using an API, they are not all of a sudden going to make it incompatible, that is something that happens with Microsoft" (Solutions Architect).

Boundary spanners -These are very important. A number of staff had already gained positive prior experience with OSS implementations. The OSS PBX was introduced to the company by an external telephony consultant, who also supported the solution in the initial deployment phase.

Environmental factors

Vendor Support -Although the existence of an independent support service provider is an important consideration in establishing product maturity, it is not a factor in procuring actual support: "[Digium provides] that enterprise level of support. But we still do it ourselves" (developer).

OSS Support -The need to collaborate with the OSS community was emphasized: "If we hit a major bug we would try and find some helpers … but I don't think we will get it here in [South Africa]. We will have to go on to forums and communities" (Developer).

Firm size -The organization is a large organization with over 2500 employees. The PBX platform serves 800 call centre seats. "Because we are so large, we can throw a lot of resources at it, so it takes a lot of risk out of the equation." (MD of IT)

Technology skills -The lack of skills in the market place made the decision a challenging one: "We just go look for VoIP engineers … they are so difficult to find and that's the risk." (Head of Telephony Solutions) As a result, they mostly developed their own skills by providing hands-on experience and training: "There was a training course that people went on … again, very much a self-learning exercise" (Head of Telephony Solutions). However, the key (Linux and VoIP) skills were available in the market: "OSS would never have been an option if we weren't able to source skills externally and bring them in-house."

Environmental factors that did not play a role in this particular case study were political splintering, legitimacy and availability. Perhaps these factors are more important to adopting organizations of a smaller size.

Conclusion

The TOE framework takes cognisance of the internal and external context in which the company operates and comprehensively covers the adoption process. It served as a useful framework when looking at the full scope of OSS adoption. Although this research involved only a single system adoption in one large organization, almost all of the factors identified in the TOE framework were found to be of significance. Hopefully this research will give other organisations a comprehensive overview of factors to consider when contemplating OSS adoption.


S Lesecq

Julie Foucault

M Correvon

P Heck

J Barrett

S Rea

F Birot

H De Chaumont Gosense

R Banach

J.-M Van Gyseghem

C Jackson Sensl

A Di Matteo

V Di Palma

C Ó'murchú

A Mathewson

INSPEX: design and integration of a portable/wearable smart spatial exploration system

Keywords: surrounding perception, spatial exploration, integrated system, embedded, low-power, portable, wearable, health

The INSPEX H2020 project main objective is to integrate automotive-equivalent spatial exploration and obstacle detection functionalities into a portable/ wearable multi-sensor, miniaturised, low power device. The INSPEX system will be used for 3D real-time detection, location and warning of obstacles under all environmental conditions in indoor and outdoor environments with static and mobile obstacles. Potential applications range from safer human navigation in reduced visibility conditions, small robot/drone obstacle avoidance systems to navigation for the visually/mobility impaired, this latter being the primary use-case considered in the project.

I. INTRODUCTION

In recent years, obstacle avoidance systems for (autonomous) vehicles has been a hot research topic. These systems combine multiple sensing technologies (e.g. LiDAR, radar, IR and visual) to detect different types of obstacles across the full range of possible lighting and weather conditions. The data from these sensors are fused and combined with vehicle orientation (e.g. from an Inertial Measurement Unit (IMU) and compass) and navigation subsystems. These systems are typically large and heavy, and not fully integrated in a unique system. They are power hungry and require large computational capabilities. They are indeed limited to high-end vehicles and robots. Moreover, having GPS and/or IMU based traditional navigation systems is not enough to ensure safe navigation of users. Basically, knowing the exact user location in a highly smart IoT environment is not sufficient to avoid unmapped static and dynamic obstacles under all conditions of visibility.

The objective of INSPEX, a H2020 funded project, is to make obstacle detection capabilities currently implemented in high-end vehicles available as a personal portable/wearable multi-sensor, miniaturised, low power device. The INSPEX spatial exploration system will be used for 3D real-time detection, location and warning of obstacles under all environmental conditions in indoor and outdoor environments with static and mobile obstacles. Potential applications range from safer human navigation in reduced visibility conditions (e.g. for firefighters), small robot/drone obstacle avoidance systems to navigation for the visually/mobility impaired.

INSPEX will integrate its smart spatial exploration system in a regular white cane for the visually impaired and provide 3D spatial audio feedback to the user on obstacle location. This use-case VIB use-case is considered highly demanding in terms of miniaturisation, integration challenges, power efficiency and needs for communication with the smart environment.

The choice as primary use-case for a smart white cane may have societal impacts. Actually, According to the World Health Organization statistics (WHO), 285 million people are visually impaired world-wide [START_REF] Who | Visual impairment and blindness[END_REF]. Note this the number is expected to double by 2040, due to aging and health diseases. Among these VIB people, only 5% are fully autonomous in their daily mobility. This lack of autonomy has partly its origin in the lack of confidence the person has in his/her mobility capabilities, and efficient use of the white cane. Electronic white canes, able to detect obstacles on the whole person height should improve VIB confidence in their mobility capabilities. The paper is organized as follows. Section III summarises the main objectives and challenges INSPEX will tackle. Section III provides an overview of the related work while section IV gives a first attempt of architecture for the INSPEX system. Section V summarises the INSPEX vision.

II. INSPEX OBJECTIVE AND CHALLENGES

To put it in a nutshell, INSPEX main target is to integrate automotive-equivalent spatial exploration and obstacle detection functionalities into a wearable/portable device (Fig. 1). This global objective breaks down in several challenges to be solved: -1. it requires the integration of several range sensor technologies (i.e. LiDAR on chip, MEMS ultrasound, Ultra Wide-Band (UWB) Impulse Radar). Basically, each sensing technology compensates for drawbacks of the other ones [START_REF] Scalise | Experimental Investigation of Electromagnetic Obstacle Detection for Visually Impaired Users: A Comparison with Ultrasonic Sensing[END_REF] to detect obstacles of various types in different conditions. Actually, one technology is not able to provide the allconditions functionality;

2. a processing unit will be integrated in the INSPEX spatial exploration system to fuse the sensor data and build the Occupancy Grid (OG) environment model. An OG is a spatial partition of the external world into a set of cells [START_REF] Moravec | High resolution maps from wide angle sonar[END_REF]. Each cell contains the occupancy probability, i.e. the probability to find an obstacle at the cell location. To get a more robust and accurate estimation of the cell state, several sensors are fused through the Multi-Sensor Fusion (MSF). Standard MSFs use Bayesian fusion [START_REF] Thrun | Probabilistic Robotics (Intelligent Robotics and Autonomous Agents)[END_REF] or evidence combination [START_REF] Elfes | Occupancy grids: A probabilistic framework for robot perception and navigation[END_REF] that require floating point computation. Unfortunately, such implementation is too power costly to be integrated in a portable device. Basically, the OG calculation must be highly efficient for the INSPEX system to meet its integration constraints (low power consumption, accuracy, cost and reliability);

3. the portable/wearable INSPEX system will be immerged in connected environments. As a consequence, it must provide connectivity to smarter environments and become part of the IoT. Context-aware communication capabilities will provide the user with a collaborative fabric of smart objects, giving the ability to determine the context of moving objects and to dynamically blend user experiences;

4. a stringent power management strategy must be implemented to fulfil the system lifespan in terms of energy autonomy. This will be achieved by dynamic adaptation of the number of range sensors used as a function of the available energy, which will imply adaptation at run-time of the obstacle perception algorithm, and as a function of the environmental conditions (e.g. lighting/visibility conditions), providing context-aware autonomous reconfiguration. This power management strategy will be verified using formal methods to ensure its proper design and functioning;

5. the INSPEX system will experience similar use environments to mobile communications devices. Its reliability must be taken into account right at the design phase (design-for-reliability). It will be designed to function under various weather conditions (e.g. rain, snow, sand) over a large temperature range (typically -20°C to 40°C) but also in low visibility conditions (e.g. night, dust, smoke, fog); 6. the architecture will be modular for the system to address several application domains;

7. INSPEX first demonstrator targets the VIB (Visually Impaired and Blind) community (see Fig. 2), and field tests will be conducted. As a consequence, ethical issues must be considered. Moreover, the INSPEX system being a connected device, privacy concerns must be addressed right at the design phase of the system (privacy-by-design). Note that the VIB use-case is seen highly demanding in terms of miniaturisation, integration challenges, power efficiency and needs for communication with the smart environment. The INSPEX system should not exceed 200gr in weight and 100cm 3 in volume. 10 hours of lifetime in continuous use are expected with an initial target for power consumption smaller than 500mW. Information regarding the location of obstacles will be provided via an extra-auricular sound feedback via Augmented Reality 3D Audio interface, taking into account the attitude of the user head to improve the navigation experience by a better obstacle localisation and warning.

III. RELATED WORK

INSPEX main advances will cover miniaturisation and optimisation of sensors to cope with the targeted requirements provided above. Software must be carefully integrated in order to decrease as much as possible its own power consumption. Targeting VIB as primary use-case, the INSPEX system must truly answer user needs, and offer robustness and reliability for the user to trust the system outputs. Lastly, cost may be a strong driver for system adoption.

This section now reviews these different facets of INSPEX.

A. Range Sensing in all-conditions

It is well known (e.g. [START_REF] Scalise | Experimental Investigation of Electromagnetic Obstacle Detection for Visually Impaired Users: A Comparison with Ultrasonic Sensing[END_REF] and references therein) that obstacle detection systems based on ultra-sonic range sensors suffer from limited useful range (typically, < 3 m) and difficul-ties of operating on highly reflective surfaces. Laser-based solutions do not suffer from these limitations, but they can be highly sensitive to ambient natural light and have difficulty identifying transparent or mirror-like surfaces. RF Radar range sensor performance is affected by the electromagnetic backscattering characteristics of the obstacle, namely its Radar Cross Section (RCS). The RCS of any obstacle is very different from its mechanical response (i.e. to ultrasound waves) or optical response (i.e. to LiDAR). Ref. [START_REF] Yamauchi | Fusing ultra-wideband radar and LiDAR for small UGV navigation in all-weather conditions[END_REF] shows that the UWB radar can be used effectively to detect and avoid obstacles through precipitation (rain, snow) and adverse environmental conditions (fog, smoke), thus being fully complementary to LiDAR which is inefficient in such conditions. Typically, RF Radars operating at 8GHz are not sensitive to clothes and light shadowing conditions and can "see" behind such short range obstacles, whereas ultra sound and LiDAR sensors will need mechanically or optically unobstructed conditions to operate. In a nutshell, Ultra Sound, RF Radar and LiDAR are complementary technologies since bringing diversity in obstacle backscattering intensity. Moreover, they offer different tradeoffs in terms of range, power consumption, directivity and packaging constraints. As a consequence, their co-integration will offer the all-condition functionality targeted by INSPEX.

Unfortunately, systems with all-visibility capability that combine visual, IR, LiDAR, radar and/or ultrasonic sensors are confined to large (autonomous) vehicles, large Unmanned Aerial Vehicles or lab prototypes with small autonomy [START_REF] Holz | Towards multimodal omnidirectional obstacle detection for autonomous unmanned aerial vehicles[END_REF], all these applications being able to cope with the high weight, computational load and power budget required for long-range 3D obstacle detection [START_REF] Darms | Perception for automated and assisted driving[END_REF][START_REF] Fausten | Evolution or revolution: architecture of AD cars[END_REF]. No miniaturised, light-weight, low-power solution that integrates all the range sensing technologies targeted by INSPEX (LiDAR-on-chip, MEMS ultrasound, Ultra WideBand Impulse Radar) exists that is suitable for use in the consumer domain for wearable/portable navigation of people, small robots or drones. Two factors contribute to this lack: the size and power budget of existing individual sensors; and the challenges of multiple sensor integration [START_REF] Vaganov | Challenges of complete CMOS/MEMS systems integration[END_REF].

Much of the research activity in the area of wearable/portable obstacle detection has been done in the context of assistive technology for the VIB community [START_REF] Dunai | Obstacle detectors for visually impaired people[END_REF][START_REF] Csapó | A survey of assistive technologies and applications for blind users on mobile platforms: a review and foundation for research[END_REF], drones [START_REF] Koppány | Vision and control for UAVs: A survey of general methods and of inexpensive platforms for infrastructure inspection[END_REF][START_REF] Xiang | Sense and avoid technologies with applications to unmanned aircraft systems: Review and prospects[END_REF] and robotics [START_REF] Pérez | Robot Guidance Using Machine Vision Techniques in Industrial Environments: A Comparative Review[END_REF], and assistive mobility for people with disabilities [START_REF] Rh Krishnan | Mobility assistive devices and selftransfer robotic systems for elderly, a review[END_REF]. However, no solution offers the allconditions functionality with the size, weight and power consumption consistent with a portable/wearable device.

B. Sensor Data Fusion and Occupancy Grid Calculation

Fusion algorithms will fuse the data from, and manage the uncertainties of, the heterogeneous set of range sensor technologies in order to ensure detection of various obstacles (size, shape, material, and colour) in 3D, at different heights and ranges and in all environmental conditions, see Fig. 3.

Many solutions already exist in the literature with pioneer works in [START_REF] Thrun | Probabilistic Robotics (Intelligent Robotics and Autonomous Agents)[END_REF][START_REF] Elfes | Occupancy grids: A probabilistic framework for robot perception and navigation[END_REF]. However, the approaches traditionally implemented in OG calculation require to manipulate probabilities. As a consequence, they require floating-point arithmetics. Real-time MSF computation with a growing number of cells and sensors is challenging. To accelerate MSF, parallel implementation in GPUs [START_REF] Homm | Efficient occupancy grid computation on the GPU with LiDAR and radar for road boundary detection[END_REF][START_REF] Negre | Hybrid sampling Bayesian Occupancy Filter[END_REF] or many-core platforms [START_REF] Rakotovao | Real-time power-efficient integration of multisensor occupancy grid on manycore[END_REF] have been proposed. All these attempts use floating-point representation for probability estimation and fusion. Unfortunately, requiring floating-point support hinders the integration of OG-based MSF on highly constrained embedded platforms. The implementation of OG-based MSF should instead make use of integer computation [START_REF] Rakotovao | Multi-Sensor Fusion of Occupancy Grids based on Integer Arithmetic[END_REF] as much as possible to decrease the power consumption associated with data treatment.

C. Reliable Smart Navigation for People with Special Needs

Navigation for people with special needs (e.g. VIB people, person in a wheelchair [START_REF] Klabi | Advanced User Interfaces For Intelligent Wheelchair System[END_REF]) is not easy at all in the so-called smart cities as cities are mainly planned for sighted persons. Integrating obstacle detection and appropriate feedback together with communication with the smart city in their daily life devices (e.g. white cane, wheelchair) will improve their mobility experience and get people integrated back into society.

To detect a large variety of obstacles (in size, shape, colour, materials), the smart navigation system must embed a mobile detection device that integrates several range sensing technologies in order to improve the performance of obstacle detection, each technology compensating for the drawbacks of others.

Most of today smart white canes only integrate ultrasound technology, either for commercial products (e;g. [START_REF]ultrasound white cane[END_REF][START_REF] Ultracane | ultra-sound white cane, vibration feedback[END_REF]) or in research prototypes (e.g. [START_REF] Scalise | Experimental Investigation of Electromagnetic Obstacle Detection for Visually Impaired Users: A Comparison with Ultrasonic Sensing[END_REF][START_REF] Elfes | Occupancy grids: A probabilistic framework for robot perception and navigation[END_REF]), sometimes together with other range sensors [START_REF] Homm | Efficient occupancy grid computation on the GPU with LiDAR and radar for road boundary detection[END_REF]. Most of these references do not report power consumption figures, nor system lifetime. Moreover, their exploration range is usually quite limited (less than a few meters). These factors have also limited a widespread adoption of ultrasound solutions in other portable devices such as tablets and smartphones. On the other hand, the growth of the Internetof-Things vision pushes Industrials to develop new sensors, actuators and smart devices smaller, more versatile, lower cost, and more power efficient. In this frame, it is clear that proximity sensor for wearable electronic devices would benefit from small and low power features Other solutions based on cameras can also be found (see e.g. [26]). However, image processing presents computational cost (and therefore power consumption) that is not consistent with the INSPEX objective of developing a low power device. Moreover, acceptability of the horseshoe-shaped device proposed in [26] that sits around the user's shoulders will have to be demonstrated.

Navigating in a city is far from safe for VIB people. Even if regulations force architects, city planners and builders to design the city to make it accessible to VIB people, sooner or later, they sustain injuries (especially on the head and chest) due to unexpected obstacles, thus decreasing their confidence in their autonomous mobility capabilities [START_REF] Manduchi | Mobility-Related Accidents Experienced by People with Visual Impairment[END_REF]. Electronic white canes offer an answer because they detect in advance obstacles, not only on the ground, but also over the whole person height, thanks to the range sensor(s) they integrate. However, they do not properly perform in all weather conditions because they integrate a unique range sensor technology for price and power consumption reasons (see Fig. 4). Moreover, as they integrate a unique range sensor technology, they cannot detect all the various obstacles (in shape, size, colour, and material) a person will encounter. As a consequence, even if mobility with an electronic white cane offers safer navigation, it is currently far from fully safe.

D. Affordability of smart white canes

Affordability is one of the adoption drivers. Fig. 4 shows the price of several commercial products. The cheapest one, Smart Cane, integrates ultrasonic sensing. Mini Guide, Palm sonar, K-sonar, Ultra Cane and Mowat are also based on ultrasound range sensors. The most expensive electronic cane integrates a LiDAR.

Thanks to technology advances and integration breakthrough, it will become possible to integrate several range sensing technologies in a small size low power device. Moreover, as these range sensors will target the consumer market, their price should decrease, leading to an integrated smart exploration system with a cost aligned with the price of today products that possess a unique sensing technology. IV. ARCHITECTURE FIRST ATTEMPT AND REVIEW OF MAIN SUBMODULES Integrating in a white cane the INSPEX system offers tremendous challenges in terms of integration, miniaturisation and power management. Actually, the available energy is naturally constrained by the batteries embedded in the system. This requires a stringent optimisation on the various parts that constitute the INSPEX system. Second, the user cannot bear a heavy system nor accept an ugly one, pushing constraints on the integration aspects (size and form factor, weight) even further. Moreover, the system reliability is very important for the user to trust the smart white cane. Lastly, cost has also strong impact on system adoption.

A. Archtechture overview

The spatial exploration system developed in INSPEX for the VIB use-case is made of three devices, namely the (A) Mo-bile Detection Device, the (B) Mobile Device, and the (C) Audio Headset Device, see Fig. 5. Each device will be split in several submodules and components that must be rigorously developed, taking into account their own allowed power requirements and size constraints. The Mobile Detection Device will integrate the different range sensing technologies in order to fully cover the person height, and search "far away" the potential dangerous obstacles (e;g. those moving towards the user with "fast" speed, taking into account the maximal speed of the user). Fig. 6 shows the expected coverage of the range sensors that will be integrated in the INSPEX smart spatial exploration system. Low power context aware communication capabilities will also be integrated. Actually, the OG calculation will be embedded within the Mobile Detection Device integrated in the cane. Therefore, the data throughput required between the cane and the Mobile Device worn by the user is compatible with Bluetooth Low Energy which is currently the best off-the-shelf solution in terms of power consumption and interoperability with the different operating systems (Android, iOS, Windows mobile). Thanks to its Internet connection, the Mobile Device can also offer new services to the user of the INSPEX system by allowing it to access remote point-of-interest databases and navigation services [START_REF] Mcgibney | MapUme: Smartphone Localisation as a Service a cloud based architecture for providing indoor localisation services[END_REF].

The exploration system will come with the integration of software in the hardware to make it truly smart. INSPEX will make use of a co-development approach of the practical system, together with its formal modelling and verification. Key to this is the identification of the system properties whose verification gives the most added value to the development as a whole, especially regarding to its reliability and stability. Identifying such properties will make clear which kind, or kinds, of formal approach is/are best suited to the task. A significant impact on the practicability of different verification approaches comes from the limited computational resources that the lightweight (not only in mass but in energy consumption) INSPEX architecture can support. Although it may decrease the fidelity of environment representation that is possible, it thereby also decreases the verification burden, in that only less complicated computations need to be modelled and verified.

Formal modelling and verification will help improve the safety and security of the functionality of the whole INSPEX system, including the reliability of context aware autonomous reconfiguration associated with the context-aware power manager. This latter will autonomously adapt which sensors will be used by the fusion algorithm, depending on the amount of energy currently available (e.g. some sensors might be no more supplied because they are too power hungry) and on the environmental conditions (e.g. some sensors might be no more supplied because they badly behave in these conditions).

B. Review of main submodules developped in INSPEX

The INSPEX partners bring four state-of-the-art range sensors to the project, namely, a MEMS ultrasound sensor, a short range large field of view LiDAR-on-chip, a long range narrow field of view LiDAR, and an UWB RF radar. The choice for these range sensing technologies is conducted by the capability of the final system to detect a large variety of obstacles (in shape, size, material, and colour) in different environmental conditions (temperature, humidity, luminosity, visibility) and particular situations (holes, stairs). Their organisation will allow the full coverage of the person height to better alarm the user on potential dangers, included at the head height (see Fig. 6).

INSPEX will miniaturise and reduce the power consumption of these sensors to facilitate system integration and meet its requirements in terms of power consumption, size and weight of the global system. Indeed, an initial review of the envisioned architecture showed that the sensors taken from the partners without any modification, possess a too high power consumption. These range sensors will then be integrated with an IMU, environmental sensing, signal processing and power efficient data fusion techniques embedded on a low power microcontroller, wireless communication, and user interface, all in a miniature, low power system designed to operate within wider smart/IoT environments.

1) MEMS ultrasound sensor

MEMS ultrasonic transducers (MUT) are used in many applications, such as non-destructive testing (NDT), speed sensing, collision warning ('sonar walking'), automation, flow metering (Doppler) and medical imaging. There are two types of MUTs, based on their actuation mechanism: capacitive MUTs (CMUTs) and piezoelectric MUTs (PMUTs). PMUTs have a lower power consumption than CMUTs, which can require a polarization voltage of around 200V. PMUTs are based on either bulk piezoelectric ceramic (with poor acoustic coupling to air or liquids) or on piezoelectric thin films (PZT, AlN) allowing them to be integrated into MEMS technology. When arrays of the latter are formed, ultrasound transducers allow the technology limits of conventional bulk ones to be overcome. 2D array MEMS transducers can be miniaturised to produce real-time proximity signals. Moreover, by using pulse-echo Time-of-Flight techniques, ultrasonic MEMS can work over 1m distances with sub-mm ranging accuracy. In INSPEX, a piezo membrane MEMS (PMUT) together with its driving ASIC [START_REF] Matrone | Volumetric CMUT-Based Ultrasound Imaging System Simulator With Integrated Reception and µ-Beamforming Electronics Models[END_REF] will be optimised and integrated in the system.

2) LiDAR-on-chip

Thanks to the huge market of the smartphone and the embedded camera, small size and low power LiDAR are, and will be in the very near future, the best candidates for the autofocus (AF). Range and bandwidth are compatible with the VIB use case that targets obstacle detection within a range less than 1 meter (short range), and within a range of a few meters (3 to 5, long range). Such a technology is compliant with low power and low size requirements. INSPEX will optimise two LiDARs brought to the project by partners. The first one will be a Long range LiDAR with a field of view of 2.2°. Currently the prototype has been demonstrated with a range of up to 21m [START_REF] Gnecchi | SiPM Sensors for ToF Ranging Applications[END_REF]. This is a single channel laser and the objective is to reduce the size by developing a chip based solution for the electronics. In conjunction with the miniaturization of the single channel module in order to increase the field of view, a 64 channel array version will be developed using the same electronics platform as will be used for the single channel version. The second LiDAR is a short range LiDAR with a large field of view based on an off-the-shelf component. Currently this commercial onchip sensor allows to look at a single point in the range of up to 2m and is designed for camera auto-focus solutions. Nevertheless a fully footprint compatible second generation will be developed and integrated in INSPEX. This sensor is looking at 9 independent measurement points with a field of view of 30° and a range of up to 3m. It will allow faster scanning of the near proximity with increased spatial resolution for obstacle detection.

3) Ultra WideBand RF radar

Integrated CW or FMCW RF radars for presence detection already exist in the field of e.g. domestic security on the one side and for obstacle detection in the automotive domain on the other side. In domestic security, the requirement being to detect a presence, a large scale variation of the electromagnetic echo strength is enough to get sufficient detection probability. Such limited bandwidth Doppler radars hardly provide precise range information useable in dynamic obstacle tracking systems. In the automotive field, obstacle detection radar, usually operating at 24 or 77GHz, are optimised for performance (range, angle), at the expense of higher cost, high directivity and power consumption of more than 500mW [32]. UWB RF radars have also been successfully applied in healthcare applications, especially for respiration rate estimation of static humans. In such application, sensitivity to very small movements is the key specification, but the measurement range is not adapted to (moving) obstacle detection needs. Smart white cane solutions integrating an RF Radar do not exist today at product level. At R&D scale, one can only find early demonstrators like in [START_REF] Yamauchi | Fusing ultra-wideband radar and LiDAR for small UGV navigation in all-weather conditions[END_REF]32]. The objective to integrate a UWB RF radar sensor in the INSPEX system with performance of 20m sensitivity range. It will have up to 100Hz refresh rate for high performance tracking of moving targets, 15cm range resolution, 60° azimuth aperture, coarse angle of arrival estimation, and approx.. 100mW of power consumption? The form factor will be compatible with integration in a white cane.

4) User feedback

Many current electronic white canes use haptic feedback (vibration) on obstacles. However, this is limited in its ability to convey complex information, can lead to desensitisation and cognitive overload [START_REF] Sigrist | Augmented visual, auditory, haptic, and multi-modal feedback in motor learning: A review[END_REF]. Other canes give audio feedback via earphones using audio tones that vary in frequency depending on obstacle distance. While this permits richer and more intuitive obstacle information, it demands too much user attention and distracts from the ambient sounds that VIB people especially rely on to be safe while moving and, again, imposes cognitive overload. To benefit from the intuitiveness and the capacity of audio to convey rich information, but without these drawbacks, the INSPEX system will rely on an Augmented Reality Audio system. That uses an extra-auricular pair of earphones and binaural spatialisation algorithms, the user hearing virtual audio from an obstacle. Efforts will be put to take into account the user's head orientation with respect to the position of the obstacles located on their path.

V. SUMMARY INSPEX will develop a spatial exploration and obstacle detection system that will provide today automotive functionalities into a wearable/portable device. Several range sensing technologies will be integrated, and their measurements fused to build an occupancy grid, in order to offer all-conditions capability. Augmented reality audio feedback, taking into account the user's head position will inform the user on potential dangers. Different submodules will be optimised to make the system consistent with its own requirement. As primary usecase, the INSPEX system will be integrated in a regular smart white cane. Tests in laboratory and in real-life conditions will be conducted in order to evaluate the system capability.

Fig. 1 .

 1 Fig. 1. INSPEX main objective.

Fig. 2 .

 2 Fig. 2. INSPEX initial demonstrator.

Fig. 3 .

 3 Fig. 3. Detection of obstacles with heterogeneous range sensors and Occupancy Grid obtained by data fusion.

Fig. 4 .

 4 Fig.4. Smart white cane affordability[START_REF] Who | Visual impairment and blindness[END_REF]

Fig. 5 .

 5 Fig. 5. INSPEX smart integrated system architecture (first attempt).

Fig. 6 .

 6 Fig. 6. Coverage of the different range sensors integrated in the white cane

ACKNOWLEDGMENT INSPEX has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 730953. Its research and innovation activities will start on the 1 st January 2017.