Vivek Nallur
email: vivek.nallur@scss.tcd.ie

Amal Elgammal
email: amal.elgammal@scss.tcd.ie

Siobhán Clarke Futurecities

Smart Route Planning Using Open Data and Participatory Sensing

Keywords: participatory sensing, open-data, open-source, smart-cityrouting

Smart cities are not merely the infusion of technology into a city's infrastructure, but also require citizens interacting with their urban environment in a smart and informed manner. Transportation is key aspect of smart cities. In this paper, we present a smart route planning open-source system; SMART-GH utilizes open data and participatory sensing, where citizens actively participate in collecting data about the city in their daily environment, e.g., noise, air pollution, etc. SMART-GH then augments the routing logic with sensor data to answer queries such as 'return the least noisy route'. SMART-GH enables citizens to make smarter decisions about their daily commute, and subsequently improve their quality of life.

Introduction

There are a plethora of route-planning applications available to citizens today. Web-based applications (e.g., Google Maps, Live Maps, Yahoo! Maps, etc.), specialized device-based applications (e.g., TomTom, Garmin, etc.) and smartphonebased apps (e.g., iOS Maps, Google Maps, etc.), all allow a user to plan a route from one point to another, calculating the fastest possible route, or shortest route. There are some that even offer to calculate the fastest route using 'current' traffic data. However, all of these applications rely on a centralized source of data, usually controlled by a single entity.

As cities get smarter, and more sensors are available in the urban environment, route planning can be augmented to use this sensor data. For example, elderly citizens, parents with young children, etc. would like to know which streets have the least air pollution or least noise, along their route? Currently, there are two roadblocks to answering such questions: (i) how do we get sensor data about city-scale locations into the hands of the citizens? and (ii) how can this aggregated data be utilized by individuals?

As an answer, this paper presents a case-study of an application that combines participatory sensing [START_REF] Goodchild | Citizens as sensors: the world of volunteered geography[END_REF], open-data from government sources, and inte-Assistant Professor, Faculty of Computers and Information, Cairo University

grates it with open-source routing libraries to provide a smarter route. An application that provides a social good, if created without participatory sensing, would require considerable investment in a sensor network from either the government, or an enterprise. Even if this were feasible, smart-city applications due to their pervasive nature, raise issues of privacy [START_REF] Gallagher | Operation Auroragold: How the NSA hacks cellphones worldwide[END_REF] from government databases.

Not only does open-source software and open-data help in the provision of a social good, but it also alleviates some of the privacy issues that are inevitable, in a smart-city application. The rest of this paper is organized as follows: Section 2 introduces concepts of aggregating city-level data, while Section 3 presents the structure and behaviour of our smart-city application. Discussion and future work are addressed in Section 4, followed by concluding notes in Section 5.

2 Participatory Sensing, Open Data and Smart Cities 2.1 Opportunistic/Human-Centred/Urban/Participatory Sensing Traditionally, wireless sensor networks have been used by researchers and city administrators to collect data about specific aspects of, and specific locations, in a city. This method has the obvious disadvantages of: (i) being expensive to deploy, (ii) high maintenance cost due to field-damage, and (iii) requiring owner permission for installation Given the penetration of smartphones [START_REF] Zheng | Spotlight: The rise of the smart phone[END_REF], and the possibility of using smartphones as sensors, at least two of the three disadvantages above can be eliminated. Ethically, the third disadvantage continues to persist, but can be alleviated through education and transparency. Citizens must be motivated to donate data to the city, and thereby help create a city-level aggregation of the desired data. However, most citizens are only motivated to participate, if they perceive a benefit to contributing their time and data [START_REF] Goodchild | Citizens as sensors: the world of volunteered geography[END_REF]. We posit that such sensor data, made available by individuals, can be leveraged easily and harnessed to provide a social good. For example, individuals with breathing difficulties can use localized pollution data to determine how to plan their commute to work. In this paper, we describe a case-study of a novel application that leverages open-data contributed by individuals, and allows them to reap the benefits of such contributions by enabling smart route planning, which incorporates participatory as well as open data sources into the routing algorithm.

Open Data

Many public institutions and governments release data being generated from their research and data gathering bodies. The EU releases its data from the EU Open Data Portal 1 . Ireland does not yet have a centralized portal that covers all departments, but it has announced a national action plan 2 that lays out a roadmap for open-data to be released. Most open-data available in Ireland is through city councils' websites. Dublin city council releases data available on Dublin city through its Dublinked initiative 3 . Use of open-data is expected to provide macro-level insights into various aspects of a government, and a city's life. In particular, from this paper's perspective, it allows us to leverage existing environmental data that is available about Dublin City, and incorporate it into routing decisions. Note: the use of Dublin city in this paper is merely illustrative, and the system that will be described is in no way tied to any particular city.

Smart Cities

The term smart city is frequently used to connote the use of information technology by city authorities, in various domains ranging from smart-grids to wastemanagement to intelligent-transport, etc. to enable a better quality of life for citizens. The basic idea is that cities could (and should) actively leverage the latest technologies, to make informed decisions at the macro-level, and enable citizens to make intelligent individual choices about city resources. About 180,000 people move to cities everyday and it is predicted that by 2050, about 70% of the world's population will be living in urban agglomerations [START_REF]World Health Organization. Urbanization and health[END_REF]. This will result in huge pressure on resources such as energy, water as well as exacerbate problems of congestion, waste-management, etc. In Dublin alone, the cost of congestion is estimated at 4.1% of the GDP [START_REF]Smarter cities for smarter growth[END_REF]. In such a scenario, judicious and smart use of technology to ease problems in transport, healthcare, energy-usage and waste-management, etc. is of utmost importance. However, current technical solutions cannot simply be transplanted into a city, typically due to the following problems:

-Multi-ownership: Different parts of a city's infrastructure are owned by different agencies, and hence technical solutions developed by one are not necessarily interoperable with others. Also, different agencies have different goals, and it is difficult to create a system that can account for all possible goals -Scale: Most decision-making mechanisms do not scale to city-scale entities, when information and goals are effectively de-centralized -Availability of fine-grained and yet aggregate data: To be able to take decisions at a city-scale, fine-grained and up-to-date data needs to be made available on a continuous basis. This is currently difficult to achieve. Either data is not available, or decision-makers are flooded with data, but do not have a macro-level perspective. In this paper, we focus on a smart-city application that circumvents the data availability issue. This application assumes that there will be no single data stream, allows individuals to contribute data, and then uses the aggregated data to provide a service back to individual citizens.

Issues

Smart-City applications tend to use technologies that are pervasive in nature. That is, sensors and sensor-networks that surround the user throughout the day. A smartphone is a perfect example of a sensor-based device that is both, uniquely identifiable as well as pervasively present. A smart-city application that uses participatory sensing is uniquely positioned to identify individuals and their habits, in ways that the user did not anticipate. In such a situation, it is imperative that the application make extra efforts to ensure that user-privacy is protected.

While governments are sometimes willing to open up data sources, there have been criticisms [START_REF] Kitchin | Four critiques of open data initiatives: The Programmable City[END_REF] about their intent in doing so. A major critique is the utility of releasing raw data, when the citizen is unable to interpret such data and make informed decisions. Helbig et al. report that most government websites are essentially data dumps with little thought given to usability, quality of data, or consequences of use [START_REF] Helbig | The dynamics of opening government data: A white paper[END_REF]. In such cases, open-data merely becomes a way for public authorities to pay lip-service to openness, without actually achieving anything concrete.

Smart GraphHopper

Our smart-city application called Smart GraphHopper4 (Smart-GH for short) uses GraphHopper5 , which is an open-source routing library that uses Open-StreetMap (OSM). The original GraphHopper can be used to plan either the fastest, or shortest routes6 in the same way as its commercial counterparts (GoogleMaps, etc.). GraphHopper uses the length and maxspeed data embedded inside the OSM to calculate routes. However, Smart-GH extends GraphHopper to allow citizens to compare routes by evaluating different available sensor data, e.g., noise data, air pollution data, etc. It also enables better distributed deployment capabilities.

Participatory Sensing: A smart-city application relies on city-wide data. Participatory data could be a key enabler in providing the application with a large set of data points. For this purpose, we use NoiseTube [START_REF] D'hondt | Participatory noise mapping works! An evaluation of participatory sensing as an alternative to standard techniques for environmental monitoring[END_REF], which is a mobile app, developed by Vrije Universiteit Brussel. NoiseTube uses sensors on smartphones and measures the ambient noise in the user's surroundings.

Open Data: Air quality monitoring data is available from Dublin City Council's Dublinked portal 7 . The city council maintains fixed sensor stations covering the major areas of Dublin city (centre, north, south, east, west).

In the next sub-sections, the structure, behaviour and technological choices to build and deploy Smart-GH are discussed in more detail. Noise data is stored on mobile phones as XML files that can be automatically uploaded to the server. Researchers in Trinity College Dublin (TCD) installed NoiseTube on their smart phones and started collecting noise data during their daily commute. Using NoiseTube's API, Smart-GH periodically pulls data about noise levels on Dublin's streets.

Air pollution data from Dublin City Council is available as a set of excel sheets, which were converted into csv format. Smart-GH currently supports three file formats: xml, json, and csv. These file reading mechanisms are inserted via a plugin mechanism, and can be extended to handle any other file-format, as desired.

Parsing and Filtering: For each sensor-type, the config file lists the name of a datasource, parser and a filter. The Parser is responsible for connecting to the datasource (web service returning json, or csv files), and collecting all the relevant data. The Filter is used to prevent fluctuations in the day-to-day collection of sensor data, from affecting the final value. The currently used filter is exponential weighted moving average, however any other filtering mechanism may also be simply plugged in, via a config file. There is a default no-op filter .

Reverse-Geocoding: Typically, each sensor reading is linked to a GPS location. To link them to the relevant OSM map ways (e.g. streets, roads, etc.), the Parser needs to obtain concrete way-ids for each GPS location in the respective files, a process known as Reverse-Geocoding [START_REF] Cayo | Positional error in automated geocoding of residential addresses[END_REF]. For this, the Parser calls a geocoding web service8 , which takes a GPS-coordinate as input and returns concrete OSM way-ids.

Data Storage: The OSM information is now associated with the sensor value, and stored as a hash in Redis. This is done for both, the noise as well as the air pollution sensor. However, collecting the air pollution sensor data is less computationally intensive, since the sensor locations are fixed and Reverse-Geocoding becomes a one-off process.

Figure 1

Marrying the Sensors to Routing

As discussed above, Smart-GH extends the typical usage of GIS applications by integrating sensor data from various sources, which will then be used as the Fig. 3: UML component diagram of Smart-GH basis of routing decisions. Smart-GH utilizes the GraphHopper routing engine for route planning. GraphHopper is a fast, efficient routing library that implements various routing algorithms, which given two (up to five) GPS locations, can calculate either the fastest or the shortest route, connecting these points. The fastest/shortest route is calculated based on speed limits/distance tags associated with OpenStreetMaps (OSM) ways (streets, roads). The problem of finding a fastest or shortest route becomes a minimization problem: minimum total time or minimum distance, respectively.

Enabling routing based on collected sensor readings required extension of the original GraphHopper library. First, the communication protocol was modified to allow arbitrary sensor types to be included as the user's preferred routing mechanism. In this case, 'noise' and 'air-pollution' are two additional values that are available to the user. Second, we modified the existing algorithms to perform routing based on stored sensor readings in Redis, instead of OSM tags. Figure 3 shows a UML component diagram of Smart-GH after augmenting it to enable smart routing. As shown in the figure, Smart-GH constitutes four components: 'Sensing', 'Database', 'Routing' and 'Web app'. The 'Sensing' and 'Database' represent the data sensing and parsing component and Redis database, as explained previously in Section 3.1.

Figure 4 presents a screenshot of the Smart-GH web interface, which visualizes a Bike route from Smithfield to School street(two places in Dublin), where the weighting is selected as 'Least Noisy', by dynamically visualizing noise data as a heatmap overlay. GraphHopper has a very simple (and limited) web interface that allows a user to only query for the fastest driving (car) route between two GPS locations. An Android App9 has also been developed for SMART-GH. Both apps have been designed and developed to meet the following functionalities:

-Enable the user to request sensor-based weights on routes. Current options for Dublin city are: fastest, shortest, least noisy, least air pollution. We maintain a city configuration file for each city, capturing, among others, the types Fig. 4: Screenshot of Smart-GH web interface of sensors available for this city. Based on available sensor data for each city, the web-interface is automatically configured to include the weighting specified in the relevant city config file. The appropriate config file is parsed based on the loaded map. For example, since dublin.osm map is loaded in Figure 4, dublin.config is parsed accordingly. Since dublin.config has two sensors corresponding to noise and air pollution data, the interface is amended to the drop-down list as shown in Figure 4.

-Support more than one vehicle type on the same running session. As shown in Figure 4, car, bike and foot are supported. These configuration parameters are specified in Smart-GH config file.

We modified the interaction model between the components to be asynchronous and stateless, and then wrapped the routing algorithms into Restful Web Services (WS). This allows the system to be scaled horizontally, to meet increased (web)traffic.

4 Discussion and Future Work

Performance

The deployment configuration shown in Figure 5 shows the sensor datastore on a separate machine, with Redis serving up the data. One of GraphHopper's biggest strengths is speed. Due to its unique caching strategy, it is able to provide routes over long distances (> 100km) very fast. Accessing sensor data, is an outof-process procedure, and is therefore much slower than if only OSM tags are Fig. 5: UML deployment diagram of the distributed deployment of Smart-GH via WSs used. However, in a smart-city usage scenario, route demand is rarely greater than 100km, while access to sensor data provides much more value. Also, due to data-retention/privacy laws, it might not be possible to always hold sensor data on Smart-GH's servers. We believe that flexibility afforded by an out-ofprocess access to a datastore is an acceptable trade-off to the performance-loss of in-process routing.

Security/Privacy

Participatory Sensing, in some ways, depends on the kindness of strangers to be effective. To acquire a critical mass of data and ensure continuous updates, it is essential to gain the trust of citizens by ensuring data anonymity and security. Even with an innocuous application like NoiseTube that makes no conscious effort to uniquely identify its users, it is fairly easy to correlate usernames (from the data collected) to the routes they have taken, and thus find out where they work, and reside. In the data-processing performed by Smart-GH, we strip away all user information, and work only with street locations and noise-levels. For a smart-city application, privacy is an aspect that must be explicitly and aggressively engineered in, since the default protocol of releasing open-data does not ensure this. Given that our entire software chain is made of open-source components, it is easy to verify that the data is anonymized, as early as possible.

Sensor-X

Currently, Smart-GH knows all the sensor-types that are present in a city. Although, for a new sensor-type, a new parser and filter can simply be plugged in through the config file, the routing algorithm still needs to know which sensor data it is dealing with. In the ideal case, users must be able to extend Smart-GH to handle different sensors without having to modify the routing algorithm. This will allow different subsets of users in a city to add different kinds of sensors (and corresponding data) without having to contact Smart-GH developers. In other words, the application should be self-extending.

Conclusion

Smart cities use digital technologies to enhance performance, well-being and improve the quality of living. This will inevitably require the active participation of citizens. Transport, Energy, Healthcare, Water and Waste are key areas of smart cities' concerns. Smart-GH uses raw open-data collected about air quality, as well as noise measurements collected by individuals, and aggregates them to produce actionable information in the transport domain. This, we believe, is in the highest tradition of open-source and open-data where small individual contributions are combined to produce a social good. Citizens usually invest a substantial chunk of time in commuting, and enabling citizens to improve the quality of this time would directly improve their well-being, and their quality of life. To the best of our knowledge, Smart-GH is the first GIS system that adds such benefits to the traditional usage of common GIS applications.

V 3 . 1

 31 Processing DataSmart-GH supports both volunteer data as well as open data. The three essential elements required for any sensor data to be integrated into Smart-GH are: (i) location in the form of GPS coordinates, (ii) value read by the sensor and (iii) timestamp. Smart-GH requires each city to have a config file, that lists all the sensor-types that are available. In this case, Dublin city has two sensor types: (a) Noise (b) Air Pollution.

Fig. 1 :

 1 Fig. 1: UML sequence diagram of sensor data reading and parsing

  Figure 2 presents a finer-grained UML component diagram of this sensing component.

Fig. 2 :

 2 Fig. 2: UML component diagram of Smart-GH sensor data reading and parsing

https://open-data.europa.eu/en/data/

http://www.per.gov.ie/minister-brendan-howlin-td-publishes-irelands-first-opengovernment-partnership-national-action-plan/

http://www.dublinked.ie/

https://github.com/DIVERSIFY-project/SMART-GH

https://github.com/graphhopper/graphhopper/

In this paper, we refer to the original GraphHopper as GraphHopper, and to our extensions to transform it into a smart and distributed GIS system as Smart-GH.

http://dublinked.com/datastore/datasets/dataset-279.php

http://services.gisgraphy.com/street/streetsearch

https://github.com/DIVERSIFY-project/SMART-GH/blob/master/SMART-GH-Android/platforms/android/ant-build/CordovaApp-debug.apk

Acknowledgment

This work was partially supported by the EU Project Diversify FP7-ICT-2011-9


Davide Tosi
email: davide.tosi@uninsubria.it

Luigi Lavazza
email: luigi.lavazza@uninsubria.it

Sandro Morasca
email: sandro.morasca@uninsubria.it

Marco Chiappa
email: marco.chiappa@gmail.com

Surveying the Adoption of FLOSS by Public Administration Local Organizations

Keywords: Public Administrations, FLOSS adoption, Survey, Italy

Background. The introduction of Open Source Software technologies in the Public Administration plays a key role in the spread of Open Source Software. The state of the art in the adoption of Open Source Software solutions in the Public Administration is not very well known even in areas like Lombardy, which is Italy's largest and most developed region. Goal. The goal of the investigation documented in this paper is to obtain a clear picture about the introduction of Open Source Software technologies in the Public Administration, the obstacles to their adoption, and the willingness of stakeholders to proceed with their introduction. Method. We carried out a qualitative and quantitative survey that was submitted to a representative part of the Public Administrations in Lombardy.

Results. The analysis of the qualitative and quantitative information shows that several Public Administrations are already using Open Source Software technologies, though not in all application areas. The savings are one frequently cited incentive to the adoption of Open Source Software. However, one obstacle is the fact that a comprehensive law on software in the Public Administration has not yet been approved. Conclusions. Our analysis provides results that indicate a common understanding of incentives, obstacles, and opportunities for Open Source Software technologies in Public Administrations.

Introduction

Transparency, reuse, and participation are the final goals of Open-Government, based on the four technological cornerstones [START_REF]Action Plan Italiano[END_REF] : Open Source Software, Open Format and Open Data [START_REF] Berners-Lee | There's gold to be mined from all our data[END_REF] in a context of infrastructure and hosting that is as Open as the Open Cloud [START_REF]Open Cloud Manifesto[END_REF].

In the last few years, there is a slowly increasing interest by Italian public and private entities in the world of Free-Libre Open Source Software (FLOSS) [START_REF]The Open Source Definition[END_REF]. On the one hand, the increasing level of FLOSS product quality is also increasing the trust that end users have in FLOSS products. On the other hand, the need for budget cuts to contain costs and expenditures of public and private entities provides new motivations for the adoption FLOSS at the expense of commercial proprietary software products.

The global importance of FLOSS worldwide has also led to the proposal and approval of a number of laws whose goal is to regulate and possibly favour the use of FLOSS in the Public Administration Local Organizations (PALO). For instance, at the Italian national level, Decree No. 267/2000 [START_REF]Testo unico delle leggi sull'ordinamento degli enti locali[END_REF] and directive 19 /12/2003 [6] have been adopted to regulate the use of software in PALO.

The Region of Lombardy, with Law Proposals on "Rules on information technology pluralism and adoption of open formats and standards for digital documents in the information society of Lombardy" and on "Provisions on access, publishing and re-use of public data and the regional administration in open format using free software and the Internet" has given a strong signal of openness to FLOSS and Open Data [START_REF] Berners-Lee | There's gold to be mined from all our data[END_REF][START_REF] Bizer | Linked Data -The Story So Far[END_REF]. To obtain concrete outcomes for the effort spent by the Region of Lombardy and the political Regional Council groups, it is necessary to continuously promote the activities related to FLOSS and Open Data with large projects, for instance with the definition of an Observatory on best practices in the use of FLOSS and the publication of Open Data.

This paper describes the execution of a qualitative and quantitative survey for assessing the state of the art in the introduction of FLOSS in the PALO in Lombardy. Specifically, the survey addressed a fairly large sample of the PALO of the Region of Lombardy, as it included municipalities that account for about one-fifth of the population of the region. The survey investigates the degree of use of FLOSS technologies in the region, the obstacles to its introduction, and the willingness of stakeholders to introduce FLOSS. The analysis of the quantitative data from the survey confirmed the qualitative data.

Lombardy is by far Italy's largest region in terms of population and arguably the most economically and technologically advanced region of the country too. So, the large-scale introduction of FLOSS technologies in Lombardy would amount to a large-scale introduction of FLOSS technologies in the country and would propel the introduction of FLOSS in the other parts of Italy.

Several surveys have been carried out worldwide to monitor and understand the diffusion of FLOSS. A fairly comprehensive systematic literary survey concerning the adoption of FLOSS in software-intensive organizations (not necessarily PA) can be found in [START_REF] Hauge | Adoption of open source software in softwareintensive organizations-A systematic literature review[END_REF]. The adoption of FLOSS in Venezuela was studied and reported in [START_REF] Maldonado | The process of introducing FLOSS in the PA: the case of Venezuela[END_REF] . The factors that affect the adoption of FLOSS in public organizations was studied in [START_REF] Rossi | Adoption of FLOSS in public organizations: factors of impact[END_REF]. Although not addressing PA, the framework provided in [START_REF] Rossi | Adoption of FLOSS in public organizations: factors of impact[END_REF] can be used to explain several of our findings, thus showing that the concerns that affect the adoption of FLOSS in PA are not dissimilar from those affecting industrial contexts.

The remainder of this paper is organized as follows. Section 2 describes the methodology adopted to conduct the quantitative and qualitative survey. Sections 3 and 4 report on the results of the qualitative and quantitative results, respectively. We discuss the results and conclusions in Section 5.

Methodology

The survey about the adoption of FLOSS by PALO in Lombardy was based on a) the qualitative analysis of a sample of medium-large organizations and b) the quantitative analysis of all organizations located in Lombardy. Thus, we obtained both qualitative semantically valuable -though not immediately generalizableinformation as well as objective and statistically representative data, though possibly less detailed and contextualized.

Qualitative analysis was performed in PALO already acquainted with FLOSS. A questionnaire containing semi-structured open questions was used as a basis for collecting opinions and indications concerning FLOSS from people in charge of IT development and operation. The interviews carried out by means of the qualitative questionnaire aimed at understanding and describing the procedures and best practices used to launch development or migration projects based on FLOSS and at determining the factors that affect (either positively or negatively) the adoption of FLOSS. Accordingly, the interviewer concentrated on understanding the critical factors that characterize the adoption of FLOSS, how risks are managed, and what guidelines are followed in the adoption of FLOSS. In any case, the interviewer also explored additional issues that would be raised during the interviews. The interviews were performed in the municipalities of Bollate, Brescia, Cinisello Balsamo, Milano, Monza, Vigevano, and the Province of Lecco, which range from approximately 36,500 to approximately 1,350,000 inhabitants.

The quantitative analysis was carried out via a questionnaire containing 35 closed-answer questions, defined on the basis of the results obtained by the qualitative analysis. The objective was to exhaustively check the situation of PALO in Lombardy, so, the questionnaire was sent to all the municipalities in Lombardy. The questionnaire was implemented via the FLOSS platform LimeSurvey [www.limeservice.com], which greatly helped users in the filling out the questionnaire and researchers in data collection and analysis. The questionnaire addressed specific issues concerning FLOSS, e.g., the pros and cons of adopted FLOSS solutions, the FLOSS tools being used, the cost of management and the more frequently used open source licenses. The invitation to answer the questionnaire was sent to all the 1536 municipalities in Lombardy on September 9, 2012. Two reminders were sent on October 17 and November 20. The questionnaire was closed on December 31, 2012. 451 questionnaires were returned, of which 256 compiled completely. The received answers were checked to eliminate typos and inconsistencies due to possible misinterpretations.

The received answers account for municipalities with a total of 1,927,189 inhabitants (about 19% of total Lombardy inhabitants), therefore they are a statistically relevant sample. Also the population distribution in the respondent municipalities matches the population distribution in Lombardy municipalities, which is characterized by many municipalities with medium-sized population. While data of this survey refer to 2012, we believe it is still a valid picture of the current situation of Lombardy. Due to the election of a new regional President and Council (mid 2013), the adoption process of FLOSS was slowed down considerably.

Results of the qualitative analysis

Seven professionals in charge of IT development and operations were interviewed. They provided a quite clear and complete view of FLOSS and the pros and cons of adopting FLOSS in a PALO. They reported a clear propensity to use FLOSS. However, they also highlighted the importance of carefully and completely analysing the requirements of the problem at hand to achieve the best solution, be it open source or proprietary.

The adoption of FLOSS in the Italian PA began quite recently, and the process of migrating to FLOSS is still largely unexplored. This situation is probably caused by a very little knowledge of FLOSS and the implications of adopting FLOSS. Moreover, most software platforms in use by the PALO are proprietary monolithic applications that appear difficult to replace or even to integrate with FLOSS. In particular, it appears difficult to integrate FLOSS-based CRM (Customer Relationship Management), DMS (Document Management System), ERP (Enterprise Resource Planning) or network and service monitoring. On the contrary, it seems that the adoption from scratch of completely new platforms and applications can be pursued both via open and proprietary solutions. In the latter cases, the decision to what extent OSS should be adopted is driven by several factors:

• Personal curiosity of IT people with respect to open solutions that could break the "de facto standard" created by multinational companies like Microsoft; • The political orientation of the administrations; • Technical considerations concerning qualities like usability, reliability, etc.

Interviewees also stressed that the process of adopting FLOSS is very different for server-side and client-side software. Using FLOSS on the servers is easier -being transparent to both PA employees and citizens-even though installing, configuring and managing OSS software (like Linux, or an open source email server, or an open source Content Management System supporting the municipal Web portal) requires a bigger effort than the proprietary alternatives.

When client software is concerned, the situation is very different. Although mature applications that could be used instead of the proprietary counterparts -like Open office or Gimp-are available, PA employees are not willing to change, and training people to use the new software is a long and expensive process. Moreover, since proprietary file formats (like .doc document files) are widely used by both the PA and the citizens, a seamless and correct conversion of a huge amount of documents is also necessary but difficult to achieve. Finally, the lack of resources makes it difficult to carry out education and dissemination initiatives to promote the usage of FLOSS, especially in schools and in public organizations where cultural "digital divide" is greatest [START_REF] Friso | How Open Source Software Products Can Support Teaching in Italian Schools[END_REF].

The advantages of FLOSS for the PA and the factors that are perceived to limit the adoption of FLOSS, according to the interviewees, are listed in Table 1 (in order of decreasing importance).

To overcome the problems listed above, several interviewees advocated regionwide guidelines and rules that drive the adoption of FLOSS in PALO. Such rules and guidelines should also clarify national laws and dispositions [START_REF]Testo unico delle leggi sull'ordinamento degli enti locali[END_REF]6]. Funding of projects addressing the adoption of FLOSS is also deemed necessary.

Results of the quantitative analysis

The IT and Data Centre departments of the interviewed PALO are medium-sized departments, with an average of 46 client machines (with a maximum of 1900 client machines) and an average of 3 server machines at the infrastructural level (with a maximum of 70 server machines). The Milan municipality is the one with the highest weight in this survey. Out of 218 municipalities that responded to question "Do you already Adopt Free and Open Source Software (FLOSS) in your Organization?" 38% does not use any type of FLOSS, while 50% (108 respondents) use FLOSS. The remaining (13%) does not know or gives no response. Out of 108 PALO that adopt FLOSS solutions, the majority declares to use FLOSS software only partially on desktop computers and servers. Very few PALO use FLOSS on desktop computers and servers more than proprietary software solutions. Nine PALO declare to have tested Software FLOSS only on pilot projects.

As clearly shown in the chart of Figure 1, the most common FLOSS solutions are in the software category: "Browser" (20.13%), with a strong preference for the Mozilla Firefox browser, or in the category: "Productivity Software" (17.90%) with a preference for the OpenOffice package. Very adopted are also: Data Base Management Systems (11.63%), with an equal distribution between MySQL and PostgreSQL, Operating System (10.51%) such as Linux, Mail Client (10.29%) such as Zimbra or Mozilla Thunderbird. The qualitative survey shows clearly that solutions for Network and IT Services Monitoring, CRM systems (Customer Relationship Management), DMS (Document Management System), ERP (Enterprise Resource Planning) and Networking Systems are slightly adopted in PALO. This situation is in contrast with the policy of transparency and dematerialization that PALO should or would like to pursue. As for Operating Systems on PC Clients and Servers, there is a clear predominance of proprietary solutions (i.e., Microsoft Windows): 198 out of 210 operating system installations are based on Microsoft solutions from a client point-of-view (4 Linux distributions and 2 MacOS systems); as for server machines, 191 out of 242 are Microsoft installations (41 Linux distributions and 0 MacOS systems). However, proprietary solutions adopted on Server are out of date (i.e., Windows Server 2003): this means that the monolithic infrastructure designed several years ago are not constantly updated and maintained. Proprietary solutions adopted on PC Clients (such as Windows XP) are often obsolete as well, since the regular upgrade of the proprietary OS is too expensive for the finances of the municipal administrations.

The considerations listed above are confirmed by the desire of mayors and IT municipal managers to increase the use of FLOSS software in their organizations. 54% of respondents would like to adopt new FLOSS solutions, while only 9% are not interested in adopting FLOSS (31% do not know, and 6% do not answer.)

Fig. 1. Micro categories of adopted FLOSS Solutions

A significant proportion of respondents (18%) would like to migrate all of their proprietary software to FLOSS systems, while 74% are interested in migrating only some specific FLOSS solutions (3% do not know, and 5% do not answer.)

However, the migration processes and the ability to access the source code of the adopted solutions are not considered by IT managers as a way to improve their IT department significantly. Only 20% of respondents, in fact, think that access to the source code of the software used by the municipal organizations may be a mechanism to improve the quality of their IT department, while 32% do not see any relation between the access to the source code and the quality of the IT department (40% do not know, and 8% do not answer.)

To identify the strengths and weaknesses in the adoption of FLOSS solutions for the Lombardy PALO in particular, the interviewed PALO were asked to express specific opinions about some qualitative factors of FLOSS solutions: Table 2 summarizes the results for each quality factor expressed both as percentage and absolute values. Among the different quality factors, the aptitude to customize FLOSS solutions compared with proprietary solutions is considered strategic. Out of 218 respondents, 88% completely agree (or agree) that FLOSS is easier to customize than proprietary Software. Another strategic factor for FLOSS is the ease of integration of the FLOSS Software with proprietary software (44.40% completely agree or agree). The openness of the source code is not enough to adopt FLOSS products: lower prices than the equivalent proprietary solutions are sought (41.67% completely agree or agree). For 36.57% of the respondents, it is difficult to find specialized companies to support the migration to FLOSS and for 41.2% of the respondents, it would be too expensive and too long to train their employees to use FLOSS software. In addition, the respondents think that the proprietary software is easier to use, safer and more reliable than FLOSS [START_REF] Lavazza | An Empirical Investigation of Perceived Reliability of Open Source Java Programs[END_REF]. It is interesting to note that, although a significant percentage of IT managers believe that FLOSS is more secure, (25.68%), more reliable (23.85%) and with a higher overall quality (17.44%) than equivalent proprietary and closed software solutions, only 11% of respondents claim to buy new hardware (PC desktop, laptops, etc.) with the Operating System and the main SW packages already installed and then replace the software over time with equivalent FLOSS solutions. In alternative, they directly buy the hardware without pre-installed software to provide the IT staff with the possibility of installing and configuring FLOSS solutions from scratch. 65% of respondents buy new hardware with pre-installed proprietary Operating Systems and software packages, then add FLOSS solutions over-time whenever new specific needs rise in the PALO. In all cases, the pre-installed software (licensed with the hardware) is not replaced. The Microsoft monopoly in licensing new hardware with their Operating Systems and Office suite increases the hesitation in migrating to FLOSS solutions when the software is purchased with the hardware.

The choices on the purchase of software are more influenced by IT managers (17.78%) that decide which Software solutions purchase. In the decision process, consultants who work with the administration can have an important role (13.78%), such as end-users who, with their needs, indirectly push the administration to make certain choices rather than others (14.44%). With an average of almost 4 suppliers and a total of 664 suppliers, which the Public Administrations rely on to supply Software solutions, the responding PALO said they were too dependent on their suppliers in 23.59% of cases, while they declare their freedom from their suppliers in 47.18% of cases. This indicates how the organizations still feel free to act in their own internal choices regardless of the supplier, while confirming the outsourcing of development and maintenance of the solutions in use. For example, in 54.88% of cases, respondents say they rely regularly and frequently on external suppliers for maintenance of their software, while only 34.36% say they do it sporadically.

In 21% of cases, software solutions are released by vendors as "turnkey" products without requiring ad-hoc customizations and personalization. However, in 46.15% of cases, sporadic customization activities of the solutions adopted are requested by the PALO. Frequent tasks of customization are needed by 7.18% PALO. During the customization of the software solutions, the contribution of the FLOSS community is evaluated by 42.56% of the respondents as "good", in line with the quality perception PALO IT managers have about the contributions made by developers of proprietary software solutions (51.28%). It is important to notice that 2.05% of the respondents declare an insufficient support provided by FLOSS communities. The value increases to 3.08% in case of the support provided by developers of proprietary software solutions.

In 2011, the total budget spent by the IT departments of the 140 respondents was equal to € 7.7M (million) with an average value of € 55k (thousand) and a peak of € 2M. Analysing the data point with the highest value (i.e., budget > € 100k) and comparing these data with the responses to question "Does the PALO adopt FLOSS?" and the number of inhabitants of the related PALO, we can observe that:

• Only 12 municipalities have an expense of the IT department > € 100k per year;

• The total expenditure of the 12 municipalities is about € 4.5M for their IT departments with € 377k in average, covering 58.45% of the total expenditure; • The total number of inhabitants of the 12 analysed municipalities is equal to 628,000 inhabitants (the IT expenditure grows linearly with the number of inhabitants), covering 32.60% of the total number of people reported in Table 1; • 10 out of 12 municipalities under analysis adopt FLOSS solutions, while only 2 municipalities do not use FLOSS (one of these is the municipality with the highest IT departmental expenditure).

In 23.16% of cases, IT managers declare that the total expenditure, in 2011, for their IT department is too high, while 50% of the IT managers claim that the total expenditure was reasonable. Only 1% of the IT managers say that the total expenditure is too low. In any case, 40% of respondents state that they will focus on a reduction of their total IT expenditure in the next two years, while for 26.84% of respondents, a contraction in the IT budget is perceived as not necessary.

59.41% of the respondents to question "Do you feel a need for addressing (directives / laws) at the regional level on the adoption of Open Source Software in PA?" advocates the adoption of a directive or law on the issues of FLOSS. Only 17.65% of the respondents do not see any legislation as necessary. Very similar is the distribution of respondents about a regional directive / law related to Open Data.

Conclusions

The results yielded by the qualitative analysis were substantially confirmed by the quantitative analysis performed in the subsequent phase of the investigation. It is therefore possible to conclude that:

• A relevant fraction of the interviewed PALO is already using FLOSS; • In general, both FLOSS and proprietary software are used. However, the usage of FLOSS is dominant with respect to proprietary software only in 10% of the PALO that participated in survey; • Sophisticated FLOSS solutions, e.g., for CRM, DMS or ERP, are rarely used in PALO. On the contrary, OS, CMS, productivity suites and Web browsers are more widely used; • Operating Systems are mainly proprietary. 17% of the interviewed PALO uses Linux on servers, and only 2% on clients; • Money saving is an important driver for the adoption of FLOSS, which is generally considered of lesser quality than proprietary software by people in charge of IT operations; • 60% of the interviewees are waiting for a Regional law that prescribes how to adopt FLOSS and how to publish Open Data. To this end, the creation of a regional board for monitoring FLOSS and supporting its adoption is advocated.

Table 1 .

 1 Reported Pros and Cons in adopting FLOSS

	Pros	Cons.
	1 Money savings	Need for training
	2 Security and stability of applications	Resistance to change
	3 Open and standard data formats	Difficulty to find professionals that can support the
		adoption and/or migration process
	4 Continuous technological update	Difficult integration with proprietary software
	5 Support by FLOSS development communities No funding from the regional administration
	6 Possibility of customizing and reengineering	Very specific PALO needs are not addressed by
	FLOSS	FLOSS
	7 -	Difficult conversion to/from proprietary formats

Table 2 .

 2 Opinions about Qualitative Factors of Software FLOSS

	Fully	Agree Disagree Fully	No opinion /
	agree	disagree	No answer

Acknowledgements

The research presented in this paper has been partially funded by the FP7 Collaborative Project S-CASE (Grant Agreement No 610717), funded by the European Commission and by project "Metodi, tecniche e strumenti per l'analisi, l'implementazione e la valutazione di sistemi software," funded by the Università degli Studi dell'Insubria. We are grateful to all IT Managers whom participated to the survey and to Fabio Pizzul and Regional Group of the Democratic Party.


X Franch
email: franch@essi.upc.edu

R Kenett

F Mancinelli
email: fabio.mancinelli@xwiki.com

A Susi
email: susi@fbk.eu

D Ameller
email: dameller@essi.upc.edu

M C Annosi

R Ben-Jacob

Y Blumenfeld

O H Franco

D Gross
email: gross@fbk.eu

L Lopez
email: llopez@essi.upc.edu

M Morandini
email: morandini@fbk.eu

M Oriol
email: moriol@essi.upc.edu

A Siena
email: siena@fbk.eu

The RISCOSS Platform for Risk Management in Open Source Software Adoption

Keywords: Open Source Projects, Open Source Software, OSS, Open Source Adoption, Risk Management, Software Platform

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

Introduction

Risk management is a necessary and challenging task for organisations that adopt open source software (OSS) in their products and in their software development process [START_REF] Li | A State-of-the-Practice Survey of Risk Management in Development with Offthe-Shelf Software Components[END_REF] [START_REF] Hauge | Risks and Risk Mitigation in Open Source Software Adoption: Bridging the Gap between Literature and Practice[END_REF]. Risk management in OSS adoption can benefit from the huge amounts of data that are publicly available about the adopted OSS components, as well as data that describes the behavior of OSS communities. The complexity and heterogeneity of the involved data sources, the need to integrate this data with contextual information related to the organisation and its ecosystem, and the convenience of combining different expertise involved in the assessment, call for adequate tools in support of all the phases of risk assessment, from data gathering, to data statistical analysis, to the correlation of these data to the organisational strategic and business risks and assets.

In this paper, we present RISCOSS (www.riscoss.eu), a platform and related assessment methodology for managing risks in OSS adoption [START_REF] Franch | Managing Risk in Open Source Software Adoption[END_REF]. It defines several interfaces to a portfolio of identified measurement and risk management techniques, allowing new techniques to be plugged in if they implement these interfaces and follow well-documented protocols. RISCOSS builds upon a highly configurable data model that allows customization to several types of scopes to support different risk assessment perspectives. It implements two working modes: exploration, where the impact of decisions may be assessed in advance; and continuous assessment, where risk variables (and their consequences on business goals) are monitored, analysed and reported. This allows RISCOSS to support a holistic decision making process inside the adopter organisation.

Related Work

Several long-term projects, corporate programs and research initiatives have similar aims than the approach supported by RISCOSS. In Table 1 we summarize the characteristics of the most related European projects that propose methodological approaches and tool support for measuring several aspects of OSS projects, mainly to evaluate the quality of the OSS components and the communities behind them. In particular we refer to the projects with objectives:  FLOSSMetrics (www.flossmetrics.org): constructing, publishing and analysing a large scale OSS database with metrics on OSS development;  QualiPSO (qualipso.icmc.usp.br/OMM/): improving the quality & maturity of OSS projects;  QualOSS (www.libresoft.es/research/projects/qualoss): defining a method to assess the robustness and evolvability of OSS projects;  ALERT (www.alert-project.eu): improving the quality of the software acting on the overall bug resolution process in OSS collaborative environments;  OSSMETER (www.ossmeter.com): supporting the process of discovering, comparing, assessing and monitoring the health, quality, and activity of OSS;  MARKOS (www.markosproject.eu): provides an integrated view on OSS projects, focusing on software functional, structural and license aspects.  SQO-OSS (www.sqo-oss.org): proposing methods and a supporting platform for OSS code quality and community measurement and analysis.  U-QASAR (www.uqasar.eu): providing a quality assurance methodology to assess the quality of software development projects for Internet applications. All these approaches and platforms focus on the gathering and analysis of OSS data but they are not specifically oriented to inform about the risks derived from these data nor to suggest possible mitigation strategies at the technical and business level.

Table 1: European projects focusing on OSS data analysis

Companies and other organizations may also implement similar programs in their development cycles. For instance, we can refer to Codeface, an extensible platform developed by Siemens (http://siemens.github.io/codeface) that aims at gathering data from different OSS sources, to analyse them and to present them to the analyst in a configurable dashboard to support decision-making. The Black Duck suite (https://www.blackducksoftware.com) provides a set of tools for the automated governance and compliance of OSS across the application development lifecycle. From the quality assessment point of view, we can mention the Software Quality Assurance and Trustworthiness (SQuAT) programme at the OW2 consortium aimed at enhancing the perceived reliability of near 50 mature projects in the OW2 code base (http://www.ow2.org/view/About/SQuAT). Some approaches target specific aspects as license assessment, e.g. Palamida (http://www.palamida.com), which provides tools to verify if there is any intellectual property violation in a project adopting OSS; White Source (http://www.whitesourcesoftware.com) provides a solution for companies that need to manage their open source assets to ensure license compliance and reduce risk.

Several recent works face with mining and analysis of OSS projects mainly to assess or predict their quality. For example, in [START_REF] Gousios | The GHTorent Dataset and Tool Suite[END_REF] the GHTorent project is presented that had the purpose of collecting data related to different aspects of the quality of the source code for all public projects available on Github. In the area of defect prediction for quality improvement, Peters et al. [START_REF] Peters | Better Cross Company Defect Prediction[END_REF] introduce guidelines to be used in the building of software quality predictors in case of scarcity of data while D'Ambros et al. present a comparison between the different prediction approaches [START_REF] D'ambros | An Extensive Comparison of Bug Prediction Approaches[END_REF]. Zhang present in [START_REF] Zhang | Towards building a Universal Defect Prediction Model[END_REF] a study for the specification of a universal defect predictor. Gamalielsson et al. [START_REF] Gamalielsson | The Nagios Community: An Extended Quantitative Analysis[END_REF] define the health of an open source ecosystem as an important decision factor when considering the adoption of an OSS component. In [START_REF] Lavazza | Predicting OSS trustworthiness on the basis of elementary code assessment[END_REF] the trustworthiness of OSS projects are predicted through the study of the Elementary Code Assessment. RISCOSS can benefit from these studies since it can integrate such quality models and techniques in the risk analysis platform. Adhering to the position defended by Noll et al. [START_REF] Noll | A Qualitative Method for Mining Open Source Software Repositories[END_REF], RISCOSS calls for human-based qualitative analysis as a necessary component. Some authors define several risks that are associated with adopting an OSS component: project health [START_REF] Piggot | How Healthy Is My Project? Open Source Project Attributes as Indicators of Success[END_REF], economic loss and adverse effects on the business processes of the organizations [START_REF] Petrinja | Comparing OpenBRR, QSOS, and OMM Assessment Models[END_REF], the lack of effective and timely OSS community support for dealing with possible integration problems [START_REF] Ayala | OSS Integration Issues and Community Support: An Integrator Perspective[END_REF]. Hauge et al. [START_REF] Hauge | Risks and Risk Mitigation in OSS Adoption: Bridging the Gap between Literature and Practice[END_REF] discuss several risks related to OSS adoption and identifies steps for reducing several of these risks. RISCOSS has a holistic perspective that integrates all of these elements in a platform to managing risks related to OSS adoption.

RISCOSS Main Functionalities

The main objective of the RISCOSS platform is that of facing the problem of managing risks in a holistic way, supporting the data gathering from the environment of the adopting organisation and from the organisation itself, the analysis of this data for the purpose of OSS risks identification and impact analysis, and the presentation of the data for decision making [START_REF] Franch | Managing Risk in Open Source Software Adoption[END_REF]. Moreover, the RISCOSS platform is designed to support two main operative modes. On the one side, it supports the analyst in performing an explorative analysis and assessment of the OSS ecosystem (in terms of communities and components), for example assessing the convenience of integrating an OSS component in the solution. On the other side, the platform implements a continuous assessment cycle that allows detecting the emerging risks related to OSS choices once, for example, an OSS component has been integrated inside a project.

Based on these basic requirements, some functionalities are proposed which are linked according to the workflow depicted in Fig. 1:  Set up of the risk management platform. When an organization decides to adopt RISCOSS, the platform gathers the needed information to set up a risk management plan (in particular, to determine the key risk indicators), in order to configure the platform infrastructure to the organizational needs. This functionality allows initialising all the knowledge base of RISCOSS having it tailored for the particular organisational environment, including the representation of the business ecosystem where the organisation lives.  Identification of the risk assessment level and perspective (Elicit scope). This use case offers the possibility to define a new scope of risk management (see Section 4). Every time one such scope is modified (remarkably, when it is created, e.g. a new project starts, a new OSS component is adopted), it is necessary to set up an organisational view and risk management resources and functionalities for it.  Risk assessment. At any moment, the user may require explicitly risk assessment

Tool Architecture

The section introduces the basic RISCOSS platform architecture (see Fig. 4). The central element is a content management tool, XWiki, which is the unifying element of the platform and covers three basic responsibilities: (i) Offering an interface to the user for dialoguing with the RISCOSS platform: as such, XWiki offers and organizes the required forms and dashboards, maintains documents, and supports, as a wiki tool, collaborative work as needed. (ii) Integrating other tools that perform functionalities required by the platform: XWiki is the umbrella that coordinates these tools, gathering the results of their computation to feed internal data structures, accessible from the tools in a blackboard architecture fashion, and allowing other tools to initialise their calculations. (iii) Accessing the reusable knowledge of the platform, namely the model patterns, data, form templates created by experts. The platform defines families of tools that are integrated into XWiki by means of well-established interfaces:  Questionnaire tool. The tool gathers from decision-maker and experts of a given organisation the information related to the characteristics of the organisation and the initial scopes.  Goal and risk modelling tools. The questionnaires are used, among other things, to create models that represent the ecosystem of the organization, with organizational goals stated using i* [START_REF] Yu | Modelling Strategic Relationships for Process Reengineering[END_REF], and risks models bound to them considering risks that are related to software quality, community behaviour or OSS licenses. This allows making explicit the consequences of in the OSS ecosystem.  Risk reasoning engines. In particular:

-Logical reasoning tools. These tools perform model analysis and reasoning in order to allow for risk identification and management. The reasoning tool currently implements model label propagation [START_REF] Nilsson | Problem-solving Methods in Artificial Intelligence[END_REF] techniques and disjunctive logic algorithms [START_REF] Leone | The DLV System for Knowledge Representation and Reasoning[END_REF] in order to identify and mitigate the risks that can occur given specified environmental situations -Statistical reasoning tools. RISCOSS relies, among others, on the implementation of Bayesian Network based components that are used to reason about the correlation between the measures obtained by the analysis of the OSS communities and the strategic and business risks of the OSS adopters. These tools rely on a strong interaction with experts and analysts to allow for an assessment and revision of the correlations between the identified measures and the strategic and business risks.  Measuring and monitoring framework composed of several Risk Data Collectors. These tools measure risk indicators and feed XWiki with the obtained values, and also monitor, detect and communicate anomalous situations from the risk management point of view. To do so, this framework needs to: 1) obtain data from the selected data sources (such as license or code quality analysis tools or blogs, forums and mailing lists of the communities); 2) implement basic statistical analysis, for example to compute statistical distributions of data [START_REF] Kenett | Modern Industrial Statistics: with applications in R, MINITAB and JMP, 2nd Edition[END_REF] t activities porting the rogeneous ment of the impact of the risks to the strategic and business goals of the organisation. We are currently deploying the platform in several contexts (large company with complex organizational structure, public administration, SME IT provider, and a community hosting ca. one hundred OSS projects) to improve its functionalities and knowledge.

Fig. 5

 5 Fig. 5. RISCO

  et al.

	Project	Techniques	Knowledge Models	Tool support
	FLOSS	Databases and analysis	Model of data to describe the	Tools to retrieve data from
	Metrics	techniques to produce	characteristics of the	OSS repositories and
		OSS project reports	different OSS projects	produce statistics
	QualiPSO	Integration of data	A software maturity model	A platform integrating tools
		from OSS repositories	with three levels for projects	to analyse the source code
		and statistical analysis	categorization	and the bug tracking systems
	QualOSS	Checklist for data	A quality model including	Tools to store checklist data
		retrieving and	characteristics, metrics and	and perform analysis of data
		statistical analysis	indicators
	ALERT	Integration of data from	Ontologies to support	Components able to gather
		OSS repositories; statis-	extraction and integration of	data from OSS sources and
		tical analysis and recom-	different data sources	services for report visualiza-
		mendation techniques		tion and recommendation
	OSSMETER Integration of data	Model for OSS forge descrip-	Execution of project metrics;
		from OSS repositories	tion; models for the descrip-	storage and analysis of the
		and statistical analysis	tion of OSS quality attributes	data and metrics
	MARKOS	Integration of data	Ontologies to support the	Tools to perform code
		from OSS repositories;	representation of concepts	analysis and license conflict
		license analysis	related to code and licenses	analysis
	SQO-OSS	Integration of data	Model for OSS quality based	Integration of metrics;
		from OSS repositories	on source code and OSS	analysis of the data through
		and data analysis	community characteristics	an array of algorithms
	U-QASAR	Data gathering on the	Models describing software	Platform to obtain an objec-
		progress and quality of	quality and contexts	tive value of the software
		software development		development process quality

Acknowledgement. This work is a result of the RISCOSS project, funded by the EC 7th Framework Programme FP7/2007-2013, agreement number 318249.


Oscar Franco-Bedoya
email: ohernan@essi.upc.edu

Open Source Software Ecosystems: Towards a Modelling Framework

Keywords: Modeling, Software Ecosystem, Framework, Open Source Software

Open source software ecosystem modelling has emerged as an important research area in software engineering. Several models have been proposed to identify and analyse the complex relationships in OSSecosystems. However, there is a lack of formal models, methodologies, tool support, and standard notations for OSS-ecosystems. In this paper we propose a general framework for support the OSS-ecosystems modelling process. This framework will allow the representation, synthesis, analysis, evaluation, and evolution of OSS-ecosystems. Design science methodology is proposed to create several artefacts and investigating the suitability of these artefacts in the OSS-ecosystem context.

Introduction

Software ecosystem modelling (SEM) is one of the most studied areas in the software ecosystem domain [START_REF] Jansen | Business network management as a survival strategy: A tale of two software ecosystems[END_REF]. However, currently there is no established modelling standard for software ecosystems. Nonetheless, there exists a need for modelling software ecosystems because:

-Complexity. Software ecosystems are among the most complex systems ever created by human [START_REF] Mens | In: Studying evolving software ecosystems based on ecological models[END_REF], and models may help understanding them. -Traceability. The software industry is constantly evolving and is currently undergoing rapid changes [START_REF] Yu | Understanding software ecosystems: A strategic modeling approach[END_REF]. Models help in tracing the historic software ecosystem changes. -Communication. Models help to represent the complex network of symbiotic relationships between entire social actors, open source communities and commercial software companies, etc. [START_REF] Yamakami | A three-layer view model of oss: Toward understanding of diversity of oss[END_REF].

Ecosystem stakeholders need a common language to communicate their ideas. In the particular case of OSS Software Ecosystems, to our knowledge, there are no contributions in the literature regarding how to model OSS-ecosystem support the representation and analysis of the specific relationships between OSS-ecosystem actors. The aim of the present work is to make a characterization of OSS-ecosystems, and to propose a specific framework for modelling OSS-ecosystems. This framework will be able to: represent, evaluate, evolve and analyse OSS-ecosystems.

Related Work

Software Ecosystems

The field of biological ecosystems has inspired several ecosystem domains. The business ecosystem (BECO) term was coined by Moore in 1996 [START_REF] Moore | Predators and prey: a new ecology of competition[END_REF]. The term digital business ecosystems (DBECO) was obtained by adding digital in front of business ecosystem [START_REF] Stanley | The ABC of digital business ecosystems[END_REF]. the matured concept of DBECO was exposed by Briscoe that defined DBECO as distributed adaptive open socio-technical systems, with properties of self-organization, scalability and sustainability, inspired by natural ecosystems [START_REF] Briscoe | Digital Ecosystems[END_REF]. The term software ecosystem (SECO) has been coined by Messerschmitt and Szyperski to refer to "a collection of software products that have some given degree of symbiotic relationships" [START_REF] Messerschmitt | Software Ecosystem: Understanding an Indispensable Technology and Industry[END_REF], [START_REF] Mens | In: Studying evolving software ecosystems based on ecological models[END_REF]. However, in contrast to natural ecosystem, there is no common definition of software ecosystem. It can be defined and interpreted in different ways, depending on the point of view [START_REF] Mens | In: Studying evolving software ecosystems based on ecological models[END_REF]. Some of the most accepted definitions of SECO are:

-A software ecosystem is "a set of actors functioning as a unit and interacting with a shared market for software and services, together with the relationships among them" [START_REF] Jansen | Business network management as a survival strategy: A tale of two software ecosystems[END_REF]. -A software ecosystem is "a collection of software projects which are developed and evolve together in the same environment" [START_REF] Lungu | Visualizing gnome with the small project observatory[END_REF]. -A software ecosystem is " a set of software solutions that enable, support and automate the activities and transactions by the actors in the associated social or business ecosystem and the organizations that provide these solutions" [START_REF] Bosch | From software product lines to software ecosystems[END_REF].

Open Source Software Ecosystems

According to our knowledge of the literature, there are only a few definitions of OSS-ecosystem. These are provided by Wynn [START_REF] Boudreau | In: Assessing the Health of an Open Source Ecosystem[END_REF] and Hoving et al. [START_REF] Hoving | Python: Characteristics identification of a free open source software ecosystem[END_REF]. Both authors define OSS-ecosystem based on the Iansiti and levien concept of business ecosystem (BECO) [START_REF] Iansiti | The keystone advantage: what the new dynamics of business ecosystems mean for strategy, innovation, and sustainability[END_REF]. This mean that the shared market, organizations, capital, are the main actors that support the open source software community.

In addition Jansen highlights the role of the developers in the OSS community and the freely nature of resources in its definition [START_REF] Hoving | Python: Characteristics identification of a free open source software ecosystem[END_REF]. These concepts are a weak metaphor of natural ecosystem terms. However, the transfer of knowledge has essentially limited itself to a reuse of terms [START_REF] Mens | In: Studying evolving software ecosystems based on ecological models[END_REF]. In order to support our proposal, In Table 1 we have integrated the different concepts of ecosystems: OSS-ecosystems are complex artefacts that require a specific characterization in order to model its elements and relationships. The variety of ecosystem described above have common roles, (e.g. partners, users, developers, resellers, software products and services, etc.). However, in the OSS-ecosystems there are several conceptual and structural particularities, e.g., principles, community join process, goals, governance, legalities, among other concepts. A characterization conducted to evaluate similarity between commercial SECOs and OSSecosystems is described in detail in sections below.

Software Ecosystem Models

In the literature several specific models and meta-models have been proposed to identify and analyse the relationships between software ecosystems members. The work of Yu and Deng [START_REF] Yu | Understanding software ecosystems: A strategic modeling approach[END_REF] and Lopez et al. [START_REF] López | Modelling and applying oss adoption strategies[END_REF] use i* models to model the strategic dependencies between OSS-ecosystem actors. Boucharas et al., [START_REF] Boucharas | Formalizing software ecosystem modeling[END_REF] and Jansen et al., [START_REF] Jansen | Business network management as a survival strategy: A tale of two software ecosystems[END_REF] present the software ecosystem modelling (SEM) technique, which includes the product deployment context (PDC) and software supply networks (SSN) diagrams. A framework for sustainable software ecosystem management was discussed by Dhungana et al, [START_REF] Dhungana | Software ecosystems vs. natural ecosystems: learning from the ingenious mind of nature[END_REF]. Other authors like [START_REF] Morgan | Exploring value networks[END_REF] and [START_REF] Mattmann | Developing an open source strategy for NASA earth science data systems[END_REF] represents the OSS-ecosystem actors and relationships using conceptual maps.

Research Methodology

We structure our research in terms of design science since it involves creating new artefacts and acquiring new knowledge, using an engineering cycle as main cycle and internal iterations with engineering activities and the empirical cycle Wieringa [START_REF] Wieringa | Design science as nested problem solving[END_REF]. In our project the engineering cycle and the empirical cycle consist of five phases:

-Problem investigation. To investigate the nature of the problem we need to solve and to know which actions can help solve this problem.

-Treatment design. To design the solution for the identified problem, in this phase it is necessary to evaluate several alternatives for each designed solution. -Design validation. Before we construct the framework's components, we validate the designs to assure that the selected designs satisfy the criteria for the framework components. -Treatment implementation. To realize the solution specification for the problem we will develop the framework, some components will be conceptual components and others software components. -Implementation evaluation. Wieringa defines evaluation as the use of artefacts in context. We will validate the framework use case studies validation.

OSS-Ecosystem Modelling Framework

The ecosystem terminology defined by Mens [START_REF] Mens | In: Studying evolving software ecosystems based on ecological models[END_REF] and Lopez [START_REF] López | Modelling and applying oss adoption strategies[END_REF] show that there are several differences between commercial SECOs and OSS-ecosystems. Sustainability in an OSS-ecosystem is related to the number of ecosystem community members [START_REF] Franco-Bedoya | Queso: A quality model for open source software ecosystems[END_REF]. On the other hand, in a commercial SECO it depends mainly on economic factors. The adoption strategies and the adoption risks derived by using OSS products in a company affect organizations business models [START_REF] López | Modelling and applying oss adoption strategies[END_REF]. In general, the most of the risks for adopting OSS components in an OSS-ecosystem are related to the licenses heterogeneity. Governance commercial software ecosystems are typically governed by a decision maker that decides how the ecosystem should evolve, while OSS-ecosystems often have a much more exible decisional structure [START_REF] Mens | In: Studying evolving software ecosystems based on ecological models[END_REF]. The community is the organizational unit in OSSecosystems. In contrast, hierarchy structures are common in commercial SECO.

An OSS-ecosystem modelling framework has to support: visualization, synthesis, analysis, evaluation and evolution of OSS-ecosystem models. In this section we provide a brief overview of the tools that support these activities. Our goal with this framework is to offer suggestions and ideas to researchers and practitioners in the field of OSS-ecosystem modelling. The framework that we propose is shown in Figure 1.

OSS-Ecosystem Model Synthesis

The purpose of this activity is to answer the question: How is it possible to generate a specific OSS-ecosystem model only from OSS-ecosystem data sources?.

Figure 2 shows a layered view of the components for this activity. At the bottom, there are several types of OSS-ecosystem data sources. Jansen defines three types [START_REF] Jansen | Measuring the health of open source software ecosystems: Beyond the scope of project health[END_REF]: project web sites, ecosystem hubs and aggregation sites. We added two other kinds of data sources: (1) social media sites such as Twitter, Facebook, etc. (2) strategic data from people related to the OSS-ecosystem obtain using specialized surveys. The OSS-ecosystem communities, typically provide open access to all data sources. The extraction of data is done with dedicated tools developed by the OSS-ecosystem researchers. Occasionally it is done by the use of specialized tools. E.g. Spanish LibreSoft group provides FLOSSMetrics to extract data from repositories and then they are stored in a set of databases [START_REF] Goeminne | Analyzing ecosystems for open source software developer communities[END_REF]. However, most of these tools are not reusable in other experiments, even in the same OSS-ecosystem. The availability of the data depends of the OSS-ecosystem.

OSS-Ecosystem Evaluation

OSS-Ecosystem Analysis

OSS-Ecosystem Synthesis

OSS-Ecosystem Evolution

QuESo

Because of this, we propose to define an extensible REST API. This is a set of web services to be implemented by each OSS-ecosystem community. This interface would allow obtain information related to the OSS-ecosystem.

Our aim is to motivate the development of this API by the OSS-communities providing them with a framework for modelling, analysing and monitoring their own OSS-ecosystem. The framework synthesis engine has two extraction components, similar to Goemmine et al. [START_REF] Goeminne | Analyzing ecosystems for open source software developer communities[END_REF]. Moreover, It uses the OSS ontology defined by Lòpez et al. [START_REF] López | Modelling and applying oss adoption strategies[END_REF], social network analysis (SNA), self-modelling techniques and predefined OSS-ecosystem models to identify the OSS-ecosystem actors and relationships in a specific OSS-ecosystem (e.g. Eclipse, Gnome, etc. . Finally, the synthesis components will generate an i* OSS-ecosystem model.

OSS-Ecosystem Model valuation

This component will enable the monitoring of the OSS-ecosystem health. To prove the feasibility of the approach we propose develop this component based on an existing technologies named SALMonOSS [START_REF] Oriol | Assessing open source communities' health using service oriented computing concepts[END_REF] and QuESo [START_REF] Franco-Bedoya | Queso: A quality model for open source software ecosystems[END_REF] developed in our research group.

Framework Synthesis Engine

OSS-Ecosystem Data Sources

OSS-Ecosystem projects Site

OSS-Ecosystem Model Analysis

If there is a defined OSS-ecosystem model, what type of data or functionality should be changed in the OSS-ecosystem to satisfy the proposal model? Figure 4 shows the main components for this activity. To answer this question we will use: an OSS-ecosystem ontology, the expert system engine and the case base reasoning (CBR). The rules defined in the ontology allow reasoning about the class instances and their relationships obtained from the OSS-ecosystem data sources.

The expert system engine will be used to register the knowledge obtained from the software ecosystem experts about specific OSS-ecosystem models. Finally, we will use CBR reasoning to select strategies for propose possible changes in the initial OSS-ecosystem model defined.

OSS-Ecosystem Model Evolution

The OSS-ecosystem are dynamics and complex artefacts. Similar to the natural ecosystem the actors, roles, dependencies, resources, relationships, etc., changed frequently over time. The question is: Once a specific OSS-ecosystem model has been created, how its continuous evolution along time can be done?. The software ecosystem evolution is stored in the OSS-ecosystem repositories. Since the software environment involves human beings (developers and users). This makes it possible, in principle, to interact with them in order to find out how and why a software project has evolved over time, and making it easier to alter the way in which the ecosystem will evolve in the future. [START_REF] Mens | In: Studying evolving software ecosystems based on ecological models[END_REF]. With the tools defined in our framework and with the information stored in the OSS-ecosystem repositories, We will be able to visualize the changes in the OSS-ecosystem model structure, interactions, health, releases, resources, etc., all this from a social technical perspective. E.g. OSS-communities, legalities, partners, platform, technologies and projects.

OSS-Ecosystem Analyser

Conclusions and Future Work

In this paper we have presented a general framework for representation, synthesis, analysis, evaluation and evolution of OSS-ecosystems. We believe that ecosystem modelling is a promising research direction and we plan to continue working on it. Our focus is would be defining methodologies, languages, formal syntax and semantic rules for modelling software ecosystem based on the models and metamodels described in the literature. In a first stage, we are working in the QuESo quality model validation and its integration with SALMonOSS framework.

Fig. 1 .

 1 Fig. 1. OSS-ecosystem modelling framework

Fig. 4 .

 4 Fig. 4. OSS-Ecosystem Model Analysis

Table 1 .

 1 Open Software Ecosystem Definition

	Definition	Sources		Examples
	An OSS-ecosystem is a SECO placed in a	Iansity	and	Other OSS ecosys-
	heterogeneous environment	Levin BECO	tems,	commercial
				SECOs,Government,
				Market rules, etc.
	Its boundary is a set of niche players	Jansen SECO Partners, Re-sellers,
				Platform provider,
				etc.
	The keystone player is an OSS community	Lungu SECO Contributors, passive
	around a set of projects in a common plat-			users, data sources,
	form			etc.

  QuESo is a quality model for assessing the quality of OSS ecosystems. QuESo have been organized in three dimensions: (1 those that relate to the platform around which the ecosystem is built,[START_REF] Mens | In: Studying evolving software ecosystems based on ecological models[END_REF] those that relate to the community of the OSS-ecosystem and (3) those that are related to the ecosystem as a network of interrelated elements, such as projects or companies. We are using QuESo to define the key health indicators (KHIs) to be monitored by SALMonOSS. the SELAs and the software ecosystem level fulfilment (SELF are composed by KHIs).

	i* Software Ecosystem Model	Software Ecosystem Level Agreement SELA	Software Ecosystem Level Agreement SELA	QuESO Quality Model
	Code Version Repository -SALMonOSS. The general idea is to adopt principles and methods from the Bug Tracker IRC Mailing List Ecosystem hubs Projects Index Social Media Twitter Wiki Aggregation Sites Aggregate Ecosystem Information OSS-Ecosystem Member REST API Data Extractor Data Postprocessor Natural Language & Text Mining Processor Social Netwotk Analysis OSS-Ecosystem Case models i* Model Fig. 2. OSS-Ecosystem Model Synthesis service oriented computing field (SOC). Particularly, we propose to adapt the concepts of quality service and service level agreement, and propose to reuse the existing body of knowledge and techniques from SOC monitor-ing.Figure 3 shows the OSS-ecosystem evaluator. SALMonOSS is an OSS-ecosystem health monitor component able to: (1) monitor a list of ecosystem health indicators along time (2) link the gathered values with client's needs by operationalization of conditions in software ecosystem agreements (SE-LAs) and (3) engineer a portfolio of methods and techniques that supports OSS ecosystems (e.g. OSS selection, proactive adaptation, etc.). evaluator service client OSS-ecosystem model evaluator service REST SALMonOSS Monitoring Service SOAP Software Ecosystem Level Fulfillment (SELF) Software Ecosystem Level Fulfillment (SELF) -QuESo. SECO-model Fig. 3. OSS-Ecosystem Model Evaluation	Expert OSS-Ecosytem

Acknowledgments

This work is a result of the RISCOSS project, funded by the EC 7th Framework Programme FP7/2007-2013 under the agreement number 318249. We would also like to thank the contribution of EOSSAC project, founded by the Ministry of Economy and Competitiveness of the Spanish government (TIN2013-44641-P).