Apostolos Kritikos
email: akritiko@csd.auth.grwww

Theodoros Venetis
email: venetheo@csd.auth.grwww

Ioannis Stamelos
email: stamelos@csd.auth.grwww

An Empirical Investigation of Sentiment Analysis of the Bug Tracking process in Libre Office Open Source Software

In this work we are studying the sentiment in Open Source Software projects and more specifically in the process of bug reporting, to investigate the human factor, namely, the feedback from the community (end-users, developers, testers, etc.). One of the characteristics for which Open Source Software has gained attention, over the years, is the fact that it is continuously being tested and maintained by its community of volunteers. Sentiment analysis, a rapidly growing field, can enrich software evaluation with a social aspect. Results suggest that FLOSS projects' bug reports can potentially constitute a rich emotionally -imbued information source.

Introduction

Since the beginning of Open Source Software, the community around a FLOSS project is one of the greatest strengths of open source software development over closed source development. Eric S. Raymond [START_REF] Raymond | The Cathedral and the Bazaar[END_REF] highlights this strength; "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone". In the community of an Open Source Software project we find developers who usually contribute both in the development and test process. In addition, community members can also be people who do not possess development skills but use the project as end users and contribute to testing. Cerone et. al. [START_REF] Cerone | Analysis of collaboration effectiveness and individuals' contribution in FLOSS communities[END_REF] stress the importance of defining qualitative metrics for indicators of collaboration effectiveness within Open Source Software communities.

In this paper we will be analyzing the sentiment from bug reports posted to Bugzilla. The proposed methodology is being applied to various major versions of the Open Source Software project Libre Office.

The rest of the paper is organized as follows: Section 2 provides background information for the basic terms discussed in this work. Section 3 presents scientific work done by other researchers relevant with the aim of this paper. Section 4 analyzes our case study plan. Section 5 provides the statistical analysis conducted to the data we collected. In Section 6 we discuss the findings on our statistical analysis, while Section 7 speculates on threats to validity. Finally, in Section 8 we conclude our work by summarizing our findings and we refer to possible future work. Please note that all the original data for this scientific work are available at http://users.auth.gr/akritiko/datasets/kritikosOSS2020_dataset.zip.

Background

This section presents an overview of the research state of the art on sentiment analysis (also known as opinion mining).

Sentiment analysis (often referred to as opinion mining) is the process of determining the polarity of an input text. It can be performed mainly at three different levels of granularity [START_REF] Liu | Sentiment analysis and opinion mining[END_REF]: document-level analysis, classifying the sentiment expressed in a whole document as positive, negative or neutral; sentence-level analysis, which determines the sentiment per sentence in a document; aspect-level analysis, which delivers more fine-grained results and is based on the idea that an opinion consists of a sentiment and a respective target, which typically refers to an entity or a specific aspect of it.

The approaches mainly used for deducing the sentiment expressed in a document is the lexicon-based [START_REF] Taboada | Lexiconbased methods for sentiment analysis[END_REF] and the machine learning-based [START_REF] Pang | Opinion mining and sentiment analysis[END_REF] approach. Besides these two, there is a third one that involves the deployment of ontology-based methodologies for performing aspect-level sentiment analysis [START_REF] Kontopoulos | Ontology-based sentiment analysis of twitter posts[END_REF].

Related Work

In the software engineering domain, there have been the following relevant approaches for studying emotions and related factors in Open Source Software projects. Guzman et al. [START_REF] Guzman | Sentiment analysis of commit comments in GitHub: an empirical study[END_REF] study emotions expressed in commit comments of several open source projects and analyze their relationship with different factors. Rousinopoulos et al. [START_REF] Rousinopoulos | Sentiment Analysis of Free/Open Source Developers: Preliminary Findings from a Case Study[END_REF] attempt to analyse the evolution of the sentiment of developers of a Open Source Software project (openSUSE Factory) by applying sentiment analysis techniques on the e-mails sent to the mailing list of the project. Similarly, Garcia et al. [START_REF] Garcia | The role of emotions in contributors activity: a case study on the GENTOO community[END_REF] perform sentiment analysis on the e-mail archives of another FLOSS project (Gentoo) and attempt to investigate the relation between the emotions in the mailing list and the respective activity of contributors in the project. Finally, the authors of [START_REF] Ortu | Are Bullies more Productive? Empirical Study of Affectiveness vs[END_REF] and [START_REF] Murgia | Do developers feel emotions? an exploratory analysis of emotions in software artifacts[END_REF] analyse comments in an issue tracking system, in order to investigate whether a relationship exists between human affectiveness (emotion, sentiment and politeness) and developer productivity (i.e. time needed for fixing an issue).

Case Study Plan

We have chosen Libre Office as a candidate to conduct our analysis for a variety of reasons: (1) It is an Open Source Software project with a rich code base (until the time of writing it has had 486,472 commits made by 1,880 contributors representing 9,517,407 lines of code [START_REF]Libre Office Project[END_REF]), ( 2) it has an active community that shows no sign of long-term decline and has attracted the long-term and most active committers in OpenOffice.org (from which Libre Office was originated as a fork).

In this work we will be studying sixteen (16) major versions of the Libre Office productivity suite, namely: 3.3, 3.4, 3.5, 3.6, 4.0, 4.1, 4.2, 4.3, 4.4, 5.0, 5.1, 5.2, 5.3, 5.4, 6.0, 6.1.

Data Collection -Bugs

We collected our data from the official Libre Office bug tracking tool which is implemented with Bugzilla [START_REF]Libre Office Bugzilla[END_REF]. We gathered a total of 740 bugs that are related to the versions. Each bug is a threaded discussion with comments related to the bug reported. These 740 bugs are consisted of 6960 comments in total. Apart from the text of the comments to which we have applied the sentiment analysis process we also gather the following information for each bug [START_REF]Libre Office Bugzilla Fields Documentation[END_REF]:

• ASSIGNED_TO: The person to which the bug was assigned to be fixed.

• CREATED: The date of the creation of the bug.

• CREATOR: The creator of the bug.

• LAST_CHANGED: When was the last time that this bug was updated.

• OPEN: If the bug is open or closed.

• COMPONENT_ID: Which component does the bug refer to (i.e. Writer).

• VERSION_ID: Which version does the bug refer to (i.e. 3.3).

As far as the comments of a bug are concerned (threaded discussion) we have gathered the following information:

• CREATED: Date and time that the comment was created.

• CREATOR: The creator of the comment (can be different than the creator of the bug) • COMMENT_TEXT: The text of the comment.

• COUNT_ORDER: The order of the comment in the discussion (needed to be able to follow the flow of the threaded discussion).

• BUG_CREATOR: Used to identify when a comment is an answer to the thread by the creator of the bug. • BY_SYSTEM: Used to identify system automated responses (which show zero sentiment by default).

Data Collection -Sentiment Analysis

As far as the sentiment analysis part is concerned, we used two (2) different tools, namely VADER [START_REF] Vader | [END_REF] and MeaningCloud [16].

We consider both tools valuable for our investigation. VADER (Valence Aware Dictionary and sEntiment Reasoner) is an academic product [START_REF] Hutto | VADER: A Parsimonious Rule-based Model for Sentiment Analysis of Social Media Text[END_REF] that serves "as a lexicon and rule-based sentiment analysis tool". MeaningCloud, on the other hand is a commercial solution for sentiment analysis that provides a free plan for 20.000 requests per month. Since we are interested in investigating if and how sentiment affects the bug tracking process in open source software, by using both tools we, without loss of generality, get safer results concerning the existence of sentiment in the bug tracking process of open source software whereas, at the same time, we are utilizing the different kinds of information that each tool provides with the aim of succeeding a wider scope in our investigation.

VADER sentiment analyzer provided us with the following data per comment:

• COMPOUND_SCORE: As the authors of the tool describe it, a "normalized, weighted composite score. This score is the sum of the valence scores of each word in the lexicon, adjusted according to the rules, and then normalized to be between -1 (most extreme negative) and +1 (most extreme positive).". • NEGATIVE, NEUTRAL, POSITIVE: These scores are ratios that show the percentage of the comment that is positive, negative and / or neutral.

MeaningCloud analyzer provided us with the following data per comment:

• SCORE: The sentiment score that can be one of the following values: none (no sentiment), N+ (very negative), N (negative), neutral, P (positgive), P+ (very positive). • CONFIDENCE: Percentage to which the analysis is accurate [0 -100].

• IRONY: If the comment is ironic (IRONIC, NONIRONIC).

• SUBJECTIVITY: If the opinion on the comment is considered subjective or objective (SUBJECTIVE, OBJECTIVE). • AGREEMENT: If the sentences of the comment are in agreement with each other or there are ambiguous meanings (AGREEMENT, DISAGREEMENT).

Statistical Analysis

This section presents the statistical analysis of the data collected. As a first step we tried to identify possible outliers that might be misleading for our results to consider possible data reduction [START_REF] Wohlin | Experimentation in Software Engineering[END_REF]. In the following image you can see a visualization of the number of comments distribution per version of Libre Office and the box plots regarding our variables. From Fig. 2 and Fig. 3 we can see that our means are being affected by low values of our population. This also becomes obvious by the descriptive statistics provided to Table 3 following. Since this work studies the bugs reported to Libre Office per version, we decided not to proceed to data reduction since the versions that seem to act like outliers are provide valuable information. For example, the increased activity of comments in some of the 4.x versions is since 3.6 version was the version that followed the fork from Open Office after which redesign and refactor processes took place. We also chose to let versions with low concentration of comments, i.e. 6.1, to further investigate if this behavior is due to successful bug fixing or it was just a version with low bug tracking activity. In Table 3 you can see the descriptive analysis of the variables we gathered for the sentiment analysis using the tools described in Section 4. 7

Finally, we conducted a descriptive analysis separately for the confidence variable per version of the Libre Office project. Having concluded with the descriptive analysis of the chosen variables we then proceeded in studying our selected variables regarding their normality. Since the descriptive analysis is showing (Table 3) skeweness with values around or bigger than 1 we have the indication that some of our variables might not follow the normal distribution. Therefore, we proceeded in applying the Shapiro-Wilk normality test in order to identify which variables follow the normal distribution and which do not From the results we are seeing that there are variables with p-value > 0.05 therefore parametric statistical analysis cannot be carried for them in this study since their data might not follow the normal distribution. Therefore, we will be conducting our statistical tests with the use of nonparametric tests and more specifically using the Spearman's Rank Correlation Coefficient.

Discussion

In this work we are studying the sentiment in Open Source Software projects and more specifically in the process of bug reporting in the Libre Office project via its bug tracking platform, Bugzilla. We conducted our experiment in 16 major versions of the software and gathered the respective data (as analyzed in Section 4) for 740 bugs consisted of threaded discussions with 6960 comments in total. We proceeded in sentiment analysis of these comments using two different tools (Vader & Meaning Cloud) and statistically analyzed the results. Our first goal in this investigation was to get a result on whether the sentiment analysis of comments in bug report is meaningful. Given that bug reporting is a technical process, usually made by technical oriented people (developers, and so forth) one might argue that the text of the reports could be standardized with technical language and therefore, possible lack of sentiment. In Table 4, showing the descriptive analysis of the confidence metric of the sentiment analysis across the versions of Libre Office, we can see that the mean is > 90% for all the versions. This gives us a first indicator that the confidence of the sentiment analysis (which is done with the MeaningCloud tool) is strong across all our data. In Table 6 we performed a nonparametric test to get results regarding the similarities for the positive, neutral and negative groups of comments between the two tools we have used. We see that the tests show significant similarities in the distributions of Positive, Neutral and Negative groups of comments for both Vader and Meaning Cloud.

From Table 3 we see that the number of ironic comments (variable Irony) are significantly fewer (min: 0, max: 7, mean: 2.44) than the non-ironic comments (min: 2, max: 1341, mean: 432,56). This seems to be intuitively logical if we consider that Bugzilla is a tool to which a community of Libre Office users (many of them voluntarily) report bugs. Having a closer look to random comments tagged as ironic from MeaningCloud we observed that such comments usually contain capitalized words and although the message does not seem to be ironic, however the tool scores them as such (i.e. […] however, it's happened on EVERY release since it started happening 2 years ago (I always move to the n+1.0.0 release when it comes out) ).

Looking at the subjectivity related variables we are observing similarly interesting comments as with the irony variable. Starting a bug report with a reference to ourselves is common in bug reporting (i.e. I have experienced this think while I was doing that). However, in some cases if we strip this first-person reference in the beginning of the sentence, we are left with the bug itself (i.e. in the previous example: this is happening when someone does that). In the comments collected there are similar "misunderstandings" by the MeaningCloud which could be considered objective comments otherwise (i.e. In order to limit the confusion between ProposedEasyHack and EasyHack and to make queries much easier we are changing ProposedEasyHack to NeedsDevEval. Thank you and apologies for the noise).

Threats to Validity

We are conducting our experiment to Libre Office. This may be a threat to validity since including all of the components of the project would resuls in a much bigger dataset with a bigger bariety of functionality and thus, variety in bugs.

A significant difficulty we came across during our work involves the domainspecific vocabulary used in the input text (i.e. bug reports) we analysed. This often may result to inaccurate ratings by the sentiment analyser, since most popular sentiment analysis tools have been trained on more generic texts (i.e. Social Media). However, this problem is not new; it constitutes a commonly recognized threat to the validity of sentiment analysis results, not only in the domain we are working on, but in any other specialized field.

Another difficulty lies in the fact that, besides specialized terminology, content like bug reports may often contain extensive use of "every-day" (i.e. Jargon) expressions, abbreviations and even emoticons (sequences of symbols representing an emotion). These expressions are typically very dynamic, changing constantly and are being frequently replaced by other expressions, following each time the popular trends. Thus, even training the sentiment analyser accordingly would unfortunately generate dubious results.

Moreover, attempting to perform sentiment analysis in informal text generated by numerous human users may often involve subjectivity and sarcasm, both of which lead to inaccurate sentiment measurements. A solution to the former problem may involve integrating a subjectivity classifier [START_REF] Wiebe | Creating subjective andobjective sentence classifiers from unannotated texts[END_REF][START_REF] Barbosa | Robust sentiment detectionon twitter from biased and noisy data[END_REF]. The latter problem, on the other hand, is even more challenging and typically appears in online discussions (like e.g. bug reports), although it is not that frequent in reviews of products and services. There have been some initial investigations (e.g. [START_REF] González-Ibánez | Identifying sarcasm in Twitter: a closer look[END_REF] and [START_REF] Riloff | Sarcasm as Contrast between a PositiveSentiment and Negative Situation[END_REF]), although the topic has not been extensively studied yet.

Finally due to space limitation we decided to make this first attempt to run our experiment per version of the Libre Office. This means that our original dataset was "compressed" in groups and, inevitably some of the fields that would otherwise be part of the experiment were ommited. It is however our intention to extend the version in this direction as well, as mentioned in the future work section.

Conclusion & Future Work

In this work we investigated the semantic analysis of bugs reported to the Libre Office Open Source Software, a tool written in C++ programming language.

As future work, we plan to replicate our case study on projects written in various programming languages for both desktop and web development (i.e. java, php, and so forth). We also intent to include metrics related with both the structural properties of the source code of the Open Source project alongside with its quality and resilience characteristics.

Additionally, we would like to attempt to enrich the human based dataset (for the sentiment analysis part) by using, additionally to the text originated from the bug reports (which mainly tend to be technical reports), the user ratings (both score and the text of the review) that various FLOSS projects provide. This way we believe we will be capturing the sentiment of both the developers and the end users of the software.

Finally, it is our intention to study other sentiment analyzers found in literature and possibly compare and contrast their application to our dataset.

Fig 1 . 2 .Fig 3 .

 123 Fig 1. NOF Comments Distribution Fig 2. Box plots for Comments, Ironic, Non Ironic

Fig 4 .Fig 5 .

 45 Fig 4. Box plots for VADER sentiment analyzer

Table 3 .

 3 Discriptive analysis for variables.

	Variable	n	mean	sd	median min max	skew kyrtosis
	Comments	16 435.00 390.32 336.50 2.0 1345.0 0.91	-0.26
	Ironic	16	2.44	2.06	2.00	0.0	7.0	0.47	-0.78
	NonIronic	16 432.56 389.11 334.50 2.0 1341.0 0.92	-0.24
	Subjective	16 279.56 259.58 205.50 1.0 889.0 0.95	-0.20
	Obective	16 155.44 131.34 131.00 1.0 456.0 0.83	-0.40
	Agreement	16 299.94 282.60 212.50 1.0 973.0 0.99	-0.10
	Disagreement	16 135.06 108.60 124.00 1.0 372.0 0.69	-0.67
	Vader (Positive)	16 269.88 248.98 200.00 2.0 869.0 1.03	0.00
	Vader (Neutral)	16 101.75 92.38	81.00 0.0 311.0 0.84	-0.45
	Vader (Negative)	16	63.38	50.76	55.50 0.0 165.0 0.46	-1.13
	MeaningCloud (Positive)	16 241.38 229.88 177.50 1.0 808.0 1.10	0.20
	MeaningCloud (Neutral)	16	40.94	31.86	35.50 0.0 107.0 0.55	-0.87
	MeaningCloud (Negative)	16	60.75	47.12	54.50 0.0 156.0 0.56	-0.93
	MeaningCloud (No Sent.)	16	91.94	84.51	67.00 1.0 274.0 0.72	-0.80

Table 4 .

 4 Descriptive analysis for confidence.

	Version	n	mean	sd	median min max skew kyrtosis
	v3.3	89	94.83	6.32	100	76	100	-0.75	-0.83
	v3.4	145	95.03	6.26	100	76	100	-0.85	-0.52
	v3.5	309	95.83	5.24	100	84	100	-0.87	-0.64
	v3.6	129	96.05	5.26	100	86	100	-0.94	-0.62
	v4.0	364	95.83	5.71	100	74	100	-1.06	-0.06
	v4.1	1345	96.98	5.03	100	76	100	-1.41	0.53
	v4.2	624	96.78	4.99	100	74	100	-1.48	1.47
	v4.3	746	96.79	5.11	100	76	100	-1.42	0.96
	v4.4	1126	97.05	4.83	100	83	100	-1.41	0.61
	v5.0	624	96.73	4.84	100	73	100	-1.40	1.38
	v5.1	128	96.02	4.94	100	76	100	-1.16	1.12
	v5.2	615	96.66	5.05	100	73	100	-1.43	1.37
	v5.3	435	96.65	5.23	100	84	100	-1.23	-0.06
	v5.4	186	97.72	3.86	100	86	100	-1.57	1.63
	v6.0	93	96.82	5.09	100	76	100	-1.67	2.52
	v6.1	2	93.00	9.90	93	86	100	0.00	-2.75

Table 5 .

 5 Shapiro-Wilk normality tests.

	Variable	W	p-value
	Comments	0.87727	0.0352
	Ironic	0.90422	0.09393
	NonIronic	0.87637	0.03408
	Subjective	0.89079	0.05734
	Obective	0.87399	0.03131
	Agreement	0.86491	0.02275
	Disagreement	0.90727	0.1051

Table 6 .

 6 Spearman's Rank Correlation for VADER versus MeaningCloud

		Vader POS	Vader NEU	Vader NEG
	MC POS	p-value = 2.2e-16 ρ = 0.9617647
	MC NEU		p-value = 2.2e-16 ρ = 0.9588235
	MC NEG			p-value = 1.252e-10 ρ = 0.9757177
	In Table 6 we have applied the Spearman's Rank Correlation to investigate possible
	statistical similarities in the distributions of VADER (Positive, Neutral, Negative)
	and Meaning Cloud (Positive, Neutral, Negative). Our results indicate that all three
	correlations are statistically significant (p-value < 0.05) and very strong correlated (ρ
	> 0,9).


Maurice Tchoupé
email: maurice.tchoupe@univ-dschang.org

Patrik Joslin Kenfack

An XQuery Specification for Requests with Preferences on XML Databases

Keywords: Semi-structured documents, XQuery, XQuery preference, XML, Open source

An exact query is a query in which the user specifies precisely what to retrieve from a database (XML or relational database). For these queries only data that strictly respect all user's conditions is returned. XML documents are generally semi-structured. Due to the non-existence or lack of knowledge of the model of the document being queried, when exact queries are used, there is a high risk of obtaining an empty result (in the case of too specific queries) or too large (in the case of too vague queries). In contrast to exact queries, requests with preferences aim to return only the most relevant results in order to avoid empty or too important results as much as possible. To achieve this goal, requests with preferences generally consist of two parts: the first part is used to express strict constraints and the second part to express preferences or wishes. The satisfaction of both parts increases the relevance of the corresponding results. This paper presents XQuery preference, an extension of the XQuery language, that allows to express requests with preferences relating to both the values and the structure of an XML document. A representation model of such requests based on the Generalized Tree Pattern (GTP) model is also proposed in order to allow an evaluation of these requests through a tree pattern matching process. Integration of the proposed language in open source implementations of XQuery like BaseX, Berkeley DB XML, eXist-db, Galax and much more, will allow users to get much more relevant responses to their concerns.

Introduction

One of the consequences of the proliferation of online information today is data diversity. XML is widely used as a core technology for knowledge management within companies and the dissemination of data on the Web (such as product catalogues), as it allows semi-structured data to be organized and manipulated. A collection of XML documents is considered to be a forest of trees with labelled nodes. To manipulate the data stored in XML and extract the relevant information in terms of structure and/or content, many query languages have been proposed such as XPath [START_REF] Consortium | Xml path language (xpath) 2.0[END_REF] and XQuery [START_REF] Consortium | Xquery 1.0 : An xml query language[END_REF]. Indeed, these query languages take into account both the content and the structure of underlying documents, as it can completely change their relevance and adequacy with regard to the needs expressed by the user. However, it is important to note that in order to query a document using these languages, the user must a priori know its structure. This requirement is difficult to meet in an open environment such as the Web, where document structures are not always available. Thus, due to the non-existence or lack of knowledge of the model of the document being queried, the documents are queried almost blindly. Query writers in this context do so according to an imaginary document structure they believe to be that of the document. Such queries would generally return either no results (cases of too specific queries having little or no match with the content or structure of the document in question) or, in the extreme, too many results (case of too general queries intensively using wildcards).

The problems of absence or very large number of results of a query have also emerged within the classical database community. Requests with preference aims to be a solution to this problem. Intuitively, a request with preferences specifies the user's wishes and consists of two parts specifying on the first one, the mandatory requirements called constraints and on the second part, the optional requirements called wishes or preferences. However, a result of a request with preferences must necessarily satisfy the first part and possibly the second; if there is at least one answer satisfying the first and second part of the query, only the answers satisfying both parts must be returned as a result.

Some specific languages (generally extensions of SQL or XPath) have been proposed for the formulation of queries with preferences : SQLf [START_REF] Pivert | SQLf Query Functionality on Top of a Regular Relational Database Management System[END_REF], Preference SQL [START_REF] Kießling | The preference sql system -an overview[END_REF], Preferences Queries [START_REF] Chomicki | Preference formulas in relational queries[END_REF],... for relational databases (RBD), XPref [START_REF] Agrawal | Xpref: A preference language for p3p[END_REF], Preference XPATH [START_REF] Kießling | Preference xpath:a query language for e-commerce[END_REF], PrefSXPath [START_REF] Tchoupe Tchendji | Xpath bipolar queries and evaluation[END_REF],... for XML databases (XML BDs). Generally, proposed extensions of XPath language for importing the concept of preferences are only interested in either value based preferences [START_REF] Agrawal | Xpref: A preference language for p3p[END_REF][START_REF] Kießling | Preference xpath:a query language for e-commerce[END_REF] or structure based preferences [START_REF] Tchoupe Tchendji | Xpath bipolar queries and evaluation[END_REF]. Our approach takes into account these two types of preferences in order to better satisfy user requirements.

The rest of this paper is organized as follows: Section 2 presents some concepts related to XML documents, queries languages and open source implementations, we detail our specifications by presenting in sections 3, a grammar for the language XQuery preference and the representation model. And we finally end with a conclusion and future work.

XML document and queries languages.

An XML document is commonly considered as a tree where nodes are the elements or attribute names, and edges represent the child node's membership of the parent node and where leaves are the contents of the elements or attribute values. An XML database is a forest of XML document trees. The figure 2 illustrates an example of a tree representation of an XML document. The use of XML documents requires the ability to extract information and reformulate it for applications. Thus, there are many languages to retrieve information from a semi-structured document. Here we present the most popular: XPath and XQuery.

XPath

XPath allows to designate one or more nodes in an XML document, using path expressions. Thus, an XPath expression is a sequence of steps. [/]step 1 /step 2 /.../step n . An XPath step consists of an axis, a filter and a predicate (optional) : axe :: f iltre[predicat] The axis indicates a search direction. The most used axes are parent-child (represented by A/B) and descendant axis (A//B). The filter selects a node type. For example the expression A/B returns all elements B children of an element A. Predicates select content.

XQuery

XQuery [START_REF] Consortium | Xquery 1.0 : An xml query language[END_REF] is the query language recommended by the W3C to extract information from many types of XML data sources. XQuery is the XML equivalent of SQL language, for retrieving data contained in relational databases and inherits the properties of several other languages. From XPath it uses the path expression syntax for addressing elements in XML documents. From SQL it takes up the idea of a series of clauses based on keywords that provide a model for data restructuring (the SQL SELECT-FROM-WHERE model). XQuery queries have several expression forms, the most famous is the FLWOR form. The acronym FLWOR comes from the reserved words of the language which make help to define the main clauses of this type of expression: For -Let -Where -Order By -Return.

Each clause in a FLWOR expression plays a particular role in the query and some of these clauses are optional. Thus, a FLWOR instruction consists of the following parts:

-For : iteration on an XML document part list -Let : allows the assignment of values to a variable -Order by : sorting results -Where : restriction clause (constraints) -Return : form of the expression to be returned An example of this type of request is given in figure 3. This query select the email addresses and skills of people who have a Java skill level above 3 and have more than two years of experience.

Open source implementations of XQuery

There are many open source implementations of XQuery. We present here a non-exhaustive list of them:

-BaseX is a very light-weight, high-performance and scalable XML XML queries (XPath or XQuery) to be evaluated on XML documents (trees), need to be represented in a model (a tree representation) in order to facilitate their evaluation. Therefore, evaluating the query is equivalent to apply the corresponding model to the XML tree trough a tree pattern matching process.

Generalized Tree Pattern (GTP)

The concept of the generalized tree model (GTP) is introduced in [START_REF] Chen | From tree patterns to generalized tree patterns: On efficient evaluation of xquery[END_REF] and allows to express more precisely the semantics of XQuery. The arcs of a GTP may be Parent-Child (PC), Ancestor-Descendant (AD) or optional. They are indicated by solid edges, double solid edges and dotted edges, respectively. A mandatory arc links an sub-expression corresponding to clauses FOR and WHERE with the rest of the query. An optional arc links an subexpression corresponding to clauses LET and RETURN with the rest of the query.

Definition 1. A generalized tree pattern is a couple G = (T, F ) where T is a tree and F a Boolean formula such as.

-Each node in the tree T is labeled with different variables and has a group number. -To each arc of T is associated a pair of labels < x, m >, where x ∈ {P C, AD} specifies the axis (parent-child and ancestor-descendant, respectively) and m ∈ {mandatory, optional} specifies the arc's status. -F is a Boolean combination of predicates applicable to nodes. Zhimin Chen et al. [START_REF] Chen | From tree patterns to generalized tree patterns: On efficient evaluation of xquery[END_REF] also propose an algrithm for translating an XQuery expression3 in GTP. The request is put in a canonical form and is then parsed clause by clause while the GTP is progressively built up to the last clause, we invite you to read [START_REF] Chen | From tree patterns to generalized tree patterns: On efficient evaluation of xquery[END_REF] for more details. The GTP is intended to be mapped (Pattern matching) to the XML tree.

Definition 2. A Pattern Match of a GTP G = (G, F ) in a tree collection C is a subtree h partial: h : G → C such that:
h contains at least group 0 of G.

h preserves the relational structure of G. This means that whenever h is defined on two nodes u, v and there is a PC arc (respectively AD) (u, v) in G, then h(v) is a son (respectively a descendant) of h(u). h satisfies the Boolean formula F of G.

$p $s $w $l $t $g $i (0) (0) (0) (0) (1)
(1) 3 XQuery preference: a language for expressing XQuery requests with preference.

In order to take into account the two types of preferences, namely on values based and structure based, we propose an extension of XQuery at two levels: an extension of XPath language for the integration of structural preferences, through the use of the operator "!" introduced in [START_REF] Tchoupe Tchendji | Xpath bipolar queries and evaluation[END_REF] and the addition of a new clause (the Pref clause) for the expression of preferences on content.

Grammar of the language XQuery Preference

Based on the grammar given in [START_REF] Chen | From tree patterns to generalized tree patterns: On efficient evaluation of xquery[END_REF] to describe a significant subset of the XQuery language, we consider the following grammar for XQuery preference expressions. For simplicity, we make other assumptions about our grammar as follows.

-The atomic predicates allowed in the boolean formula ϕ are the integrated relop predicates (<, ≤, >, ≥, =, =) or the integrated predicate empty(F LW R).

The operand of a relop predicate can be one of the following: constant c, XPath expression XP E, or agg(XP E), where agg is one of the integrated aggregate functions, namely, avg, count, min, max, or sum [START_REF] Chen | From tree patterns to generalized tree patterns: On efficient evaluation of xquery[END_REF]. -The XPath expressions used are expressions extended by the operator "!" except for the Pref clause.

Expression of preferences on values and structure

XPath language is a component of XQuery and is used to extract nodes from the XML document. This language therefore allows you to browse the structure of the document. We use the notation ! (a unary operator) introduced by Tchoupé et al. [START_REF] Tchoupe Tchendji | Xpath bipolar queries and evaluation[END_REF] for expressing preferences in an XPath (sub)path. For example, in the path Q 1 = /a/b!/c, the subpaths /a and /c represent the constraints, while /b represents a preference. Q 1 is interpreted as a request returning all occurrences c i of the node c such that the path from the root to c i must have an occurrence of a and possibly an occurrence of b. The occurrences c i candidates to be included in the solution are the sub-trees of the form /a i /b i /c i or /a i /c i . For simplification purposes, we assume that operator ! can only be applied on a single node and not on an XPath subpath for example (a/b/c)!. In other words, this operator does not take into account parentheses. We introduce a new clause in the XQuery language: the Pref clause. A Boolean clause to define preferences (wishes) on results. Just like the clause Where, Pref will define the constraints on the values but with the only difference that, it will not accept an embedded XQuery expression.

In this way, requests for XQuery preference language are composed of two parts: one to express mandatory constraints (the Where clause), and the other to express preferences or wishes (the Pref clause). The language XQuery preference therefore follows the bipolar model. Thus, the answers satisfying constraints and wishes are returned in priority to the user. But if such answers do not exist then results that satisfy only the constraints are delivered. The example below shows an example of an XQuery request with preferences on values and structure.

Example 1 XQuery query with preference on values and structure: Let's consider a query in witch, a user is looking for a candidate with Java skills and at least a diploma level above 3. But would like this person to have at least two years of experience, and skills with the framework Sping-boot would be a plus. The user also wants the returnees to have filled in the information on their profiles.

In this example, the condition on Java skills and diploma level above 3 is a constraint while the condition on the number of years of experience and Spring-Boot skills is a wish whose satisfaction increase relevance of the associated result. The figure 6 illustrates how this request can be expressed in the language XQuery preference.

For this request, people with only Java skills and a diploma level above 3 represent potential responses but are dominated by candidates who have in addition, an experience of more than 2 years and Spring-Boot skills. However, For $p in document('candidate.xml')//persons Where $p/skills/Java > 1 AND $p/diploma > 3 Pref $p/experience > 2 AND $p/skills/Spring-Boot > 1 Return <result> {$p/profile!//name} </result> Fig. 6: An example of XQuery request with preference on structure and values if no answer respects all the constraints of the Pref clause, only those that best integrate the user's preferences are returned: They are called undominated solutions. The operator "!" present in the XPath expression $p/prof ile!//name specifies that the person elements with a prof ile sub-element are preferred. For now, we have imposed certain restrictions on XQuery preference expressions. For example, we require that XPath paths defined in the clause Pref do not include a preference element for the simple reason that all these paths are already preferential since they appear in the pref clause.

In the section 2.4 we presented a model for XPath and XQuery queries. Indeed, these model considerably reduce the complexity of evaluating requests. In the following section, in the same vein we propose a query model for XQuery preference requests based on the GTP model of Chen Zhimin et al.

GTP request with preference

As previously stated, GTP model is used to represent exact XQuery queries. We adapt this model as follows for the representation of XQuery requests with preferences:

to the GTP tree we add a new type of arc called preference arcs. A preference arc can be of the type AD (Ancestral-descending), PC (Parent-child) or PP ( Preference Path). the Boolean formula F verifying the predicates applicable to nodes is divided into two groups of formulas S and P:

• group S defines the mandatory constraints.

• and group P the preferential constraints (wishes). -A set of nodes forms a group if they are connected to each other by nonoptional or preferential relationships.

The figure 7 illustrates an example of a GTP request with preference (see figure 8), distinguishing between the different types of arcs to take preferences into account:

-The arcs preferences of type ancestor-descendant (APN). This type of arc allows to represent a structural preference between an element and its descendant for example a//b! -The arcs of type parent-child preferences (PPN). For the representation of a structural preference between an element and its child for example a/b! -Finally, arcs of the type preference path (PP) for the representation of preferences on values. This type of arc will be generated for XPath expressions found in the Pref clause. The formula group S defines constraints on mandatory nodes while the group P defines constraints on preference nodes. All the nodes of the tree are part of the same group because they are all connected to each other by optional arcs or preference. More formally, a GTP with preference is defined as follows:

Definition 3. A generalized tree pattern with preference is a couple G = (T, F ) where T is a tree and F a Boolean formula such as:

-Each node in the tree T is labeled with a different variable and has a group number.

to each arc of T is associated a tag e, where e ∈ {P C, AD, OP, P N, AP N, P P }

• PC, AD: specify the parent-child and ancestor-descendant axis • PN, APN: specify respectively the parent-child preference and ancestordescendant preference axes. • OP, PP: specify the optional axes and preference path respectively.

-F is a group of formula S and P specifying respectively a Boolean combination of predicates applicable to non-preferential nodes and to preferential nodes. Definition 4. A node is said to be a preference if it is located at target of a preference arc. The model thus presented integrates the different elements for the representation of preferences in the GTPs. The GTP with preference is obtained by a parsing of the query XQuery preference as in [START_REF] Chen | From tree patterns to generalized tree patterns: On efficient evaluation of xquery[END_REF]. The process for parsing a request is as follows: We have a global analysis environment ENV to manage information collected from the request analysis i.e The association variable name-nodes. The query is parsed clause by clause. We also use a help function buildT Q(xp) xp is an extended XPath expression4 , which constructs part of GTP with preference from xp. This function is described as follows:

-Each time that xp starts with the built-in document function, a new GTP is added to ENV -If xp begins with a variable, the node associated with this variable is searched for in the tree and the new part resulting from xp starts from it. -When xp contains the operator "!", The arcs associated with the nodes considered are of PN or APN type, depending on the axis (/ or // respectively) and the constraints linked to these nodes are placed in group P of the GTP formula.

During the analysis of a Pref clause, the arcs created are of type PP and the constraints linked to these nodes are placed in group P.

Conclusion

In this paper, we have made two major proposals: XQuery preference an extension of the XQuery language for the expression of requests with preferences which can relate to both the structure and the content; the GTP model with preference an extended version of the GTP model for the representation of XQuery preference queries; The examples given show that the proposed language is quite expressive and thus makes it possible to meet a variety of needs.We have carried out a study for the evaluation of GTPs requests with preference by an adaptation of the algorithm T wig 2 Stack [START_REF] Chen | Twig2stack: Bottom-up processing of generalized-tree-pattern queries over xml documents[END_REF] for the evaluation of exact GTPs requests. Due to the limitation of the number of pages in this paper, we could not describe it here, but it is accessible via the open repository on Github5 . The results obtained are very interesting and show that we can extend the existing algorithms with a very small loss in performance but an improvement in terms of quality of the results delivered to users. Furthermore, this work serves as the foundation for a much larger body of work, which could be the subject of further study. Among which, integration and experimentation of XQuery preference in the presented open source sources implementations, an in-depth study of the nested XQuery preference queries and the search for the best algorithms for evaluating queries with preferences.

Fig. 1 :Fig. 2 :

 12 Fig. 1: XML document.persons

FORFig. 3 :

 3 Fig. 3: Example of an XQuery query

Fig. 4 :

 4 Fig. 4: Example of an XQuery expression and corresponding GTP query.

  FLWR ::= (ForClause | LetClause)+ WhereClause PrefClause ReturnClause. ForClause ::= FOR $fv1IN E1 , ..., $fvn IN En. LetClause ::= LET $lv1 := E1 , ..., $lvn := En. WhereClause ::= WHERE ϕ(E1, ..., En). PrefClause ::= Pref ϕ(E1, ..., En) ReturnClause ::= RETURN E1...En. Ei ::= FLWR | XPATH.

Fig. 5 :

 5 Fig. 5: Syntax of XQuery preference expressions

Fig. 7 :

 7 Fig. 7: Example of representation of a GTP request with preference

FOR $ p Fig. 8 :

 p8 Fig.8: XQuery preference request corresponding to the GTP with preference of the figure7

  -eXist-db is a high-performance open source native XML database -a NoSQL document database and application platform built entirely around XML technologies. A Browser-based IDE allows managing and editing all artifacts belonging to an application. Syntax-coloring, code-completion and errorchecking help to get it right. Being a complete solution, eXist-db tightly integrates with XForms for complex form development[START_REF] Meier | The high-performance native xml database engine[END_REF]. -Galax is an open-source implementation of XQuery, the W3C XML Query Language. It includes several advanced extensions for XML updates, scripting, and distributed programming. Implemented in O'Caml, Galax comes with a state of the art compiler and optimizer. Most of Galax's architecture is formally documented, making it ideal for users interested in teaching XQuery, in building new language extensions, or developing new optimizations [11]. -Oracle Berkeley DB XML is an open source, embeddable XML database with XQuery-based access to documents stored in containers and indexed based on their content. Implemented in C, Oracle Berkeley DB XML is built on top of Oracle Berkeley DB and inherits its rich features and attributes.

Database engine and XPath/XQuery 3.0 Processor, including full support for the W3C Update and Full Text extensions all developed in Java. It comes with interactive user interfaces (desktop, web-based) that give users great insight into their data

[START_REF] Database | Implements the xquery update facility[END_REF]

.

The GTP model deals with a very significant subset of the XQuery language and supports nesting, quantizer, grouping and aggregation.

An extended XPath expression is an expression containing the notation $ and the operator "!"

https://github.com/patrikken/PrefTwig2Stack


Bettina Schwab
email: bettina.schwab@gmx.net

Dirk Riehle

Ann Barcomb

Nikolay Harutyunyan
email: nikolay.harutyunyan@fau.de

The Ecosystem of openKONSEQUENZ, a User-Led Open Source Foundation

Keywords: open source foundations, sponsored open source, commercial open source, open source software, user-led open source foundations

Companies without expertise in software development can opt to form consortia to develop open source software to meet their needs, as an alternative to the build-or-buy decision. Such user-led foundations are little understood, due to a limited number of published examples. In particular, almost nothing is known about the ecosystems surrounding user-led foundations. Our work seeks to address this gap, through an exploratory qualitative survey of openKONSEQUENZ, from the German energy sector. We find that the technological goals are quite homogeneous, independent of a participant's role in the ecosystem, but that economic conflicts exist between foundation members and supplier companies due to the consortium's efforts to transform the software market structure to limit dependency on specific vendors.

Introduction

Companies are now using open source software (OSS) not only as infrastructure and to support development, but also as part of their software supply chains [START_REF] Germonprez | Eight observations and 24 research questions about open source projects: Illuminating new realities[END_REF][START_REF] Harutyunyan | Corporate Open Source Governance of Software Supply Chains[END_REF][START_REF] Riehle | License Clearance in Software Product Governance[END_REF]. However, not all enterprise software needs are addressed by classic, community-led, volunteer-driven OSS communities. In particular, communityled projects struggle to address the challenge of providing software for institutions rather than individuals, such as financial or HR systems [START_REF] Mackie | Open source in open education: Promises and challenges. Opening up education: The collective advancement of education through open technology[END_REF]. In part this is because many community-led projects are founded by IT professionals to meet their own needs, what Raymond famously described as developers scratching their own itches [START_REF] Raymond | The cathedral and the bazaar[END_REF]. Mackie [START_REF] Mackie | Open source in open education: Promises and challenges. Opening up education: The collective advancement of education through open technology[END_REF] identified several other possible reasons why community-led OSS has not met commercial needs: the number of developers with relevant skills might be too few to build a community, the benefits of the software may be too diffuse to encourage collaboration, and the software may be too complex to be developed on a voluntary basis.

These limitations suggest that a non-volunteer OSS, created by businesses collaborating to jointly develop the software, could be a valid option for niche enterprise markets. Such an approach could offer an alternative to the build-orbuy decisions companies currently face. In contrast to off-the-shelf proprietary solutions, OSS can help companies avoid the costs of extensive customization and vendor lock-in, which lead to a high total cost of ownership [START_REF] Courant | Software and collaboration in higher education: A study of open source software[END_REF][START_REF] Liu | On assessment of project success in community source development[END_REF]. At the same time, it is cheaper than custom software, and has the potential to become the de-facto standard, reducing training costs [START_REF] Liu | A cooporative analysis framework for investment decisions in community source partnerships[END_REF][START_REF] West | Contrasting community building in sponsored and community founded open source projects[END_REF]. In the last fifteen years, there has been a significant increase in vendor-led foundations. Unlike community-led OSS, vendor-led OSS does not develop organically but is synthetically created by a consortium of companies [START_REF] Omahony | What makes a project open source? Migrating from organic to synthetic communities[END_REF]. Vendor-led OSS should not be confused with single-vendor OSS, where development is led by a single company with a business model based on complementary software or services [START_REF] Riehle | The single-vendor commercial open course business model[END_REF].

Vendor-led foundations have proved popular in industries made up of companies developing software, where OSS can be used as a base for the company's commercial offerings [START_REF] Liu | Achieving flexibility via service-centric community source: The case of Kuali[END_REF][START_REF] Omahony | What makes a project open source? Migrating from organic to synthetic communities[END_REF]. Often this is done in order to dilute the power of a market leader, to reduce costs, and to create standards [START_REF] Germonprez | Open source communities of competitors[END_REF][START_REF] Riehle | The economic case for open source foundations[END_REF][START_REF] Weikert | Managing commercial conflicts of interest in open source foundations[END_REF].

Creating a consortium to develop mutually beneficial software using an open source approach is less common when it concerns enterprise software to address internal needs. We refer to this approach as a user-led foundation, to highlight the differences between the collaborative creation of software in the supply chain, and enterprise software [START_REF] West | Contrasting community building in sponsored and community founded open source projects[END_REF]. In the latter case, the user-led foundation members often lack software development expertise, and must commission vendors to perform the development, with the associated administrative challenges [START_REF] Liu | The community source approach to software development and the Kuali experience[END_REF][START_REF] Niazi | Challenges of project management in global software development: A client-vendor analysis[END_REF].

Despite the strong potential of user-led OSS foundations to address enterprise business needs in under-served or monopolistic markets [START_REF] Courant | Software and collaboration in higher education: A study of open source software[END_REF], very little research has been conducted on the topic. The majority of examples are drawn from the education sector and are grant-funded [START_REF] Liu | Achieving flexibility via service-centric community source: The case of Kuali[END_REF][START_REF] Wheeler | Open source 2010: Reflections on 2007[END_REF]. Furthermore, existing studies have focused on foundation members, with the ecosystem described primarily in terms of potential (e.g., [START_REF] Wang | Community source software in higher education[END_REF]).

This paper addresses this gap through an exploratory study of a user-led OSS foundation. We examined openKONSEQUENZ (oK), a foundation from the German energy sector representing the interests of distribution system operators (DSOs). The goal of our study was to use oK to develop a preliminary understanding of the ecosystem surrounding the user-led OSS foundation and the conflicts within it. We addressed this goal through a qualitative survey of software vendors, consultants, and DSOs associated with oK. The contribution of this paper is a description of the software ecosystem of oK, which includes the economic objectives of participants, and the conflicts arising from different economic objectives. We see our work as the basis for future investigation into the differences and similarities between user-led consortia.

The rest of this paper is organized as follows. Related literature is covered in Sec. 2. The research approach is explained in Sec. 3. Results are presented in Sec. 4. Limitations and a discussion of the results are covered in Sec 5. The paper concludes with a summary in Sec. 6.

Related Work

While some government-backed open-source enabled collaboration projects have been studied [START_REF] Feller | Open innovation and public administration: transformational typologies and business model impacts[END_REF][START_REF] Robles | Setting up government 3.0 solutions based on open source software: The case of x-road[END_REF], we reviewed the research on vendor-led and user-led founda-tions that were directly related to our study. Firstly, the vendor-led foundations and their ecosystems were considered, because of the potential similarity to userled foundations and the greater body of work. Secondly, we covered the existing literature on user-led open source foundations.

Vendor-Led Open Source Foundations

Vendor-led foundations have been a topic of greater academic interest than userled foundations. O'Mahoney and West [START_REF] Omahony | What makes a project open source? Migrating from organic to synthetic communities[END_REF] describe them as synthetic communities, as distinct from organic, or community-led communities. Vendor-led foundations are usually initiated by a commercial entity, and governed by the company, or involve two or more organizations jointly founding a project which addresses an industry need. The latter type can be called a multi-vendor OSS project, where the foundation is used for governance. Multi-vendor foundations are also known as sponsored [START_REF] West | Contrasting community building in sponsored and community founded open source projects[END_REF], federated [START_REF] Levy | Is it egalitarianism or enterprise strategy? Exploring a new method of innovation in open source[END_REF], or consortia [START_REF] Riehle | A model of open source developer foundations[END_REF].

Vendor-led foundations can foster the necessary ecosystems that enable vendor company innovation. In this context, open source software development can be seen as a successful variation of collective invention by building a pro-social intrinsic motivation of a critical mass of participants [START_REF] Osterloh | Open source software development-just another case of collective invention?[END_REF]. Companies have been recognizing the potential to collaborate on the basis of open source, as a result of which several types of collaboration strategies for research and development (R&D) have emerged [START_REF] Levy | Is it egalitarianism or enterprise strategy? Exploring a new method of innovation in open source[END_REF][START_REF] West | Challenges of open innovation: the paradox of firm investment in open-source software[END_REF]. In contrast to the non-collaborative proprietary innovation model, vendor-led foundations enable a collaborative innovation model through a consortia of software vendors that leverage pooled resources [START_REF] Riehle | The economic case for open source foundations[END_REF][START_REF] Weikert | Managing commercial conflicts of interest in open source foundations[END_REF].

User-Led Open Source Foundations

User-led foundations are an emerging way for companies to collaborate on software development projects. Unlike vendor-led foundations, open source user-led foundations bring together companies or institutions that are the users of the foundation-developed open source software, and often not the actual software development companies [START_REF] West | Contrasting community building in sponsored and community founded open source projects[END_REF]. This does not necessarily mean that the actual users (end-users operating the software product to perform their work) are represented and directly engaged in the software development process. Furthermore, not only software user firms are members of the consortium, but usually also other participants of the ecosystem, especially software vendors and service providers.

While there is little literature on the topic of user-led governance structures of open source communities, practitioners like Wheeler have studied the phenomenon using the examples of the existing user-led foundations such as Kuali Foundation, calling it community source [START_REF] Hanganu | The community source development model[END_REF][START_REF] Taft | Community-source development appeals in tough times: A combination of traditional and open-source development models, community source can save companies money and reduce vendor lock-in[END_REF]. We have opted to refer to it in this paper as user-led , due to the risk of confusion with classic, volunteerdriven OSS, which is frequently described as community-led. The Kuali Foundation, founded in 2005 to provide software for higher education institutions, is the most prominently discussed case of community source. Kuali's community source approach, its antecedents, and a framework for investment decisions have been described [START_REF] Liu | Antecedents of community source network formation: The case of Kuali[END_REF][START_REF] Liu | Achieving flexibility via service-centric community source: The case of Kuali[END_REF][START_REF] Liu | Technology flexibility as enabler of robust application development in community source: The case of Kuali and Sakai[END_REF][START_REF] Liu | A cooporative analysis framework for investment decisions in community source partnerships[END_REF]. Haganu [START_REF] Hanganu | The community source development model[END_REF] calls community source "the pub between the cathedral and the bazaar." The hybrid form between commercial software development and open source software development draws on advantages of both worlds, but is complex to handle because diverse and possibly conflicting requirements of the involved members have to be balanced [START_REF] Liu | The community source approach to software development and the Kuali experience[END_REF].

Methodology

To address our research goal, we performed a qualitative survey to investigate the phenomenon of the ecosystem surrounding a user-led consortium [START_REF] Andersson | Verification and validation in industry-a qualitative survey on the state of practice[END_REF][START_REF] Jansen | The logic of qualitative survey research and its position in the field of social research methods[END_REF][START_REF] Myers | Qualitative research in information systems[END_REF]. Our primary reason for opting for this approach is that there is little published information about user-led consortia. An exploratory study is appropriate when the topic being studies is a real-world phenomenon, and little is known about it. The ecosystems surrounding user-led foundations have not previously been studied in depth, and it is unclear if the limited software development expertise of user-led foundation members creates a significantly different environment than the vendor-led foundation [START_REF] Liu | Antecedents of community source network formation: The case of Kuali[END_REF]. An additional consideration was the fact that all the supplemental material we found concerning the focus of our study-the open source user foundation called openKONSEQUENZ (oK)-was outdated, leading us to reject the alternative of a case study.

The main subject of our qualitative survey was the Germany-based open source user foundation oK, a foundation from the German energy sector representing the interests of distribution system operators (DSOs). While oK and the software ecosystem for DSOs have not been subject of research yet, six companies-potential early members of the foundation-published a preliminary feasibility study [START_REF] Openkonsequenz | Machbarkeit konsortiale softwareentwicklung auf basis von open source softwarevon[END_REF] in 2013, followed by two publications on software architecture and quality [START_REF] Goering | Reference architecture for open, maintainable and secure software for the operation of energy networks[END_REF][START_REF] Goering | Architecture and quality standards for the joint development of modular open source software for power grid distribution management systems[END_REF]. We selected oK due to our insider access to the foundation. oK also exemplifies the case of the user-led foundation members commissioning software rather than developing it themselves, and therefore the situation might display some differences from vendor-led foundations where development is kept in-house.

Data Sources

We conducted six semi-structured interviews with representatives of the participants of the openKONSEQUENZ ecosystem. Interview data was collected in advance of analysis due to constraints of access to the informants. The interviews were collected between December 2017 and March 2018 and were conducted in German. The quotations used in this paper are our translations.

In our selection of interviews we sought to interview a representative of each type of participant in the oK foundation: DSOs, service provider members, and guest members. We also included a non-member. All interviewees wished to remain anonymous. Table 1 summarizes the study participants in terms of oK foundation membership type, role in the ecosystem, and role in their company.

Analysis

We made use of a data analysis process inspired by Eisenhardt [START_REF] Eisenhardt | Building theories from case study research[END_REF], with the addition of thematic networks [START_REF] Attride-Stirling | Thematic networks: an analytic tool for qualitative research[END_REF]. Eisenhardt [START_REF] Eisenhardt | Building theories from case study research[END_REF] offers guidance specifically for building organizational theories. Fig. 1 depicts all six steps of the process: skimming, open coding, axial coding, condensation, and ordering. Open coding was an iterative process, which resulted in a gradually evolving set of codes. Each step, however, was performed sequentially. The coding was done using MaxQDA.

Results

Below we first describe the oK software ecosystem, before examining the goals of individual participants, and conflicts in economic objectives.

The oK Software Ecosystem

Changes in the regulations for German energy companies provided the initial impetus for DSOs to look for a more open approach. The core control unit, also known as the supervisory control and data acquisition (SCADA) system, was at the forefront of these changes. DSO employees using SCADA systems began participating in a user group organized by a software vendor.

A law calling for the digitalization of the energy transition issued in 2016 [START_REF]Gesetz zur digitalisierung der energiewendebundesgesetzblatt jahrgang[END_REF] pushed DSOs further toward additional collaboration and innovation. With the employees working with SCADA system already engaging in a form of collaboration, oK was created with the scope of collaborating on software systems that are used in grid operation management and which are closely connected to SCADA. Grid operation management is largely independent within each company, and grid operations are similar for all DSOs, even if requirements and scope vary somewhat (i.e., some DSOs manage gas and water grids, while others do not).

At present, software vendors offering products closely connected to the SCADA system can be considered part of the oK ecosystem, along with the DSOs which are the driver members of oK. We define the scope as the companies which are currently affected by oK. The consortium has not yet had a significant impact on other systems and vendors.

Investments in oK are done collaboratively. A DSO who wants to develop a module takes a leading role in the resulting project and usually covers 70% of the necessary financial investment and human resources. The rest of the DSO members in oK will cover the remaining 30% of the cost. This principle ensures that development costs are distributed among the DSOs, which is economically beneficial compared to in-house development financed by a single DSO.

Economic Goals

In describing the economic goals we summarized the perspectives of each (potential) participant in the ecosystem based on the role in the ecosystem.

DSOs are regulated by the German Federal Network Agency (Bundesnetzagentur), but are nonetheless for-profit enterprizes. DSOs do not compete with one another because their activities are regionally exclusive. The Federal Network Agency set up an incentive regulation to encourge DSOs to lower operational costs. Due to regulated pricing, DSOs can increase their profits by decreasing their operational costs. There are three approaches to lowering software costs that DSOs intend to use: lowering costs of development through collaborative investment, lowering costs in software procurement, and lowering costs in grid operations through better software tools.

Despite the desire to lower costs, DSOs were not primarily driven by cost to create the oK consortium. Insufficient software quality and long delivery times for new functionality made vendor lock-in particularly painful. This was especially pronounced during the maintenance and support phase of the software life cycle. Sometimes software vendors dictated prices which DSOs could not agree to for support and maintenance. Therefore the main goal of DSOs was to break vendor lock-in to provide themselves with more flexibility in software procurement and maintenance contracts. The pricing of the software played a role, but quality and functionality were even more important factors. One participant explained: "It was not primarily an economic goal. It was primarily a goal to increase the quality of software."

DSO representatives reported that they wanted to choose the most appropriate software tools to operate their grid more efficiently and thereby lower operational costs. Choosing the most appropriate software is only possible when the software has a modular design based on standardized interfaces. If the consortium can reach its goal of offering a vendor-independent open source platform, DSOs will be able to engage in flexible software selection by combining modules to reach optimal operational efficiency.

Having modular grid management software might also reduce procurement prices, although this is not the key anticipated benefit as prices are already low compared to other types of software. Another possible outcome is that more service providers will enter the market, offering DSOs even more flexibility and negotiating power.

DSOs do not necessarily have to participate in the oK consortium. Because the platform software is open source, it is possible for DSOs to become free riders. For the free rider, the benefit is getting software and access to an ecosystem without investing resources, but the drawback is having no power to influence the direction of software development.

Widespread free riding would be problematic for the strength of the consortium. However, some free riding could be positive in that it would help to make the platform a standard, increasing the impact of the consortium. One respondent explained: "The big network operators won't cause problems for small municipal utilities if they just use the modules. They expressly wish for this."

Software Suppliers constitute the most diverse group in the ecosystem. Software vendors vary by their product and service portfolio: some vendors sell SCADA systems and other modules and services, while others are IT service providers which develop modules on demand.

All software suppliers stated that their current investment of time, expertise, and membership fees to oK exceeds the short-term profits that are made via the consortium. One supplier of on-demand development expressed that the short-term goal is to win future tendering processes. The software suppliers we interviewed engage in oK because they strive for long-term goals. One respondent explained: "The pre-sale expenses are already very high. We also spend more being in committees than we get through our margins in the short term. We are there because we believe in the idea." Software suppliers who participate in oK want to have their technical perspective considered in reshaping the structure of grid management software. This helps ensure that their own products will be compatible and competitive in the future. By promoting a modular approach with standardized interfaces, they also shift the market from favoring general contractors to more specialized service providers, making it more difficult for competitors to acquire the necessary expertise. Being part of the consortium is also a way of signaling to buyers that the supplier is a trusted vendor [START_REF] Heiskanen | Control, trust, power, and the dynamics of information system outsourcing relationships: A process study of contractual software development[END_REF].

Part of this strategy is accomplished by donating modules to the consortium. Such donations need to be adapted and fitted to consortium quality standards and guidelines. A donation is attractive for oK software provider members because they can spread their technologies and strengthen their future market position. Developers are motivated when their work is open sourced and when they know it will be put to a good use. According to one respondent: "Our developers are of course interested in modern platforms and modern tools."

Software suppliers that are not part of oK can be motivated to maintain their position in the new market, to grow market share, to maintain the existing market structure to ensure predictable revenues, or to change the market in other ways (for example, by promoting development toward cloud technology). The last two motivations can be seen as a reason for not joining the consortium. Suppliers who are interested in growing or maintaining their position may find the costs, which currently exceed the benefits, too high to justify membership.

Consultants are motivated to sell consulting projects, but are otherwise as diverse as software suppliers. For those who are oK members, the most important objective is not economic. Some participants in this category are research groups, and primarily benefit through the data and experience acquired from close industry collaboration: "We are also active in other research projects where we are pushing for something to be developed based on the oK technology stack and components. It would be nonsense to develop everything again." As with software suppliers, service providers who decide not to join oK have likely decided that the costs of joining the consortium outweigh the expected benefits.

Conflicting Economic Goals

Homogeneity of goals within the oK consortium is high. Even though the different member classes have different economic goals, these play a secondary role and the common goal is emphasized by all members. The service provider members collaborate in the consortium, but they are aware that they are still competing companies. The economic conflict within the consortium is therefore to be located between participants in the same category, with the exception of DSOs, which are natural monopolies. As one interviewee stated: "One should not forget that these are all different companies." Another explained "Of course, if there are modules for the tender, everybody (competing service provider members) would like to do it."

The main economic conflict occurs between oK members and non-members, or more specifically, those who want to change the technological approach from monolithic to modular, and therefore the business model of software vendors and the market structure of the ecosystem, and those who would like to stick with the current business model. According to the interviewees, the attitude towards the consortium is mainly dependent on the perspective of decision-makers on the software ecosystem. An interviewee elaborated: "For them, this is a business model where they can only lose. At least that's what the boardroom thinks."

The old business model delivered operational security to the software vendor, but also to the DSOs. The pricing and maintenance were fixed for a certain period of time (in most cases for five years or more). Established software vendors prefer this model because it provides them with influence and authority. One participant stated: "The software vendors could sit back, because they knew their existing customers could not run away."

Enabling a different business model could lead to a profound change of the market structure. Vendor lock-in was and is possible because software vendors and consultants could not be substituted. The consortium aims to change the business model by altering the technical situation that led to vendor lock-in. Instead of monolithic systems owned by vendors, oK is based on a vendorindependent platform that enables software modularity.

Market leaders see the change as a threat. Speaking of a market leader, one respondent said, "They are afraid that open source will sell less software." Vendors have not taken any actions against the consortium. One interview partner described the current attitude of these vendors towards oK as one of curiosity.

Limitations and Discussion

Limitations

This study followed a methodology suggested by Eisenhardt [START_REF] Eisenhardt | Building theories from case study research[END_REF]. And while building theory from interviews comes with the strength of close ties with empirical data and a high likelihood of generating novel theory, there are also some downsides concerning choice of methods. The results are often rather modest and no grand theory emerges. This is one of the reasons we consider this an exploratory study. Qualitative research can, according to Guba [START_REF] Guba | Criteria for assessing the trustworthiness of naturalistic inquiries[END_REF], be assessed as follows.

Credibility concerns identifying and eliminating obfuscating factors. We use two approaches to improve credibility: prolonged engagement and member checking. Our research group is a guest member of the consortium, and one of the authors has been involved in oK since its inception. Furthermore, each person we interviewed received a preliminary copy of this study. Transferability involves identifying situational variations to ensure the result applies to a broader context. As our study concerns a single consortium, we do not make this claim. Instead, we present this as an exploratory study. Confirmability refers to researcher neutrality. This study was provided as part of a larger report to oK, thus making it available to a professional audience that was familiar with oK but not a direct data source. We triangulated on each category of participant by asking interview partners about not only their own experiences, but also about other members of the ecosystem. Dependeability is about ensuring the consistency of results. We created an audit trail by preserving three phases of the code system (see Fig. 1), namely open coding, thematic networks, and the final code system. The code system can be found in the Appendix [START_REF] Schwab | The ecosystem of openKONSEQUENZ, a user-led open source foundation: Appendix[END_REF].

Discussion

The findings of this research concerning economic conflicts in the software ecosystem are general. The main conflict that was identified is evolving around business model change to break vendor lock-in. This is not a new insight because this conflict was essentially willingly established by the user consortium oK in the first place. However, this source of conflict is not commonplace in vendor-led foundations [START_REF] Weikert | Managing commercial conflicts of interest in open source foundations[END_REF], suggesting that user-led foundations are somewhat different. The main reason for persistence of conflict is the low maturity of the user foundation: most interview partners mentioned that oK is still in an early phase of its development and will need more time to impact the ecosystem.

The empirical evidence collected here points towards something else: the slow advancement of the consortium might allow it to open doors that seemed to be shut. Technologically, many goals are congruent even with non-member institutions. One incumbent suggested that even though they are not in favor of business model change, the technological advancements of the consortium towards the standardization of interfaces is very interesting.

Consortium members expect that it will take another 5-10 years for oK to have a real effect on the ecosystem around DSOs. We see a chance of maintaining the consortium goal to develop a vendor-independent platform that allows a flexible and modular use of technology to control smart grids, but at the same time to unite the whole software ecosystem and lead a standardization effort in the industry. Future research could take a longitudinal look at oK, from inception to possible success, potentially creating a road-map for other user-led consortia.

Our findings add to the research field by describing a user-led consortium which is different from the previous descriptions from the educational sector. As user-led consortia become more widespread, there will be the opportunity for research which goes beyond exploring the single foundation, in order to draw more generalizable conclusions about user-led consortia and their ecosystems.

Conclusion

This paper presented an exploratory qualitative survey of a software ecosystem surrounding a user-led consortia in the German energy sector. We described three main categories of participants: distribution system operators (DSOs), or software users; software suppliers; and consultants. We explained the situation of openKONSEQUENZ (oK) members and non-members in each category.

The data analysis provided an overview of the different participants in the ecosystem and their goals. The primary economic conflict comes from the change of business model. The consortium was founded to change the balance of power in the ecosystem by offering an alternative platform and standardized interfaces. This has the potential to break vendor lock-in by allowing more competition. However, it also provides small software vendors the opportunity to specialize. Software vendors who are established do not like the idea of losing bargaining power. Interestingly, despite the disagreement over the economic impact of the modular and flexible design, all companies in the ecosystem support the technological aspects of the change.

Our study provides a look at a user-led consortia which is neither drawn from the education sector nor grant-sponsored. There is significant promise for industry in the user-led consortium approach, but our work shows that, at least in the case of oK, it may take significant time to realize the benefits. Additionally, companies seeking to establish software consortia should be aware of the possibilities for conflict, even when there is technological consensus.

Fig. 1 .

 1 Fig. 1. Coding steps and activities

Table 1 .

 1 Interviewees by oK membership type, ecosystem and company roles

	Membership	Ecosystem role Company role
	DSO		Customer	User representative
	Service provider	Software supplier Project lead
	-		Software supplier Development lead
	Guest	Consultant	Domain expert
	DSO		Customer	User representative
	Service provider	Software supplier Business development
	Skimming interviews and notes	• Get a broad overview of topics	Thematic networks	• Identify themes • Identify connections most prominent topics between stakeholders and
	Free / open coding	• Create codes • Coding		Condensation	• Condense codes multiple sources of support • Exclude topics without
	Axial coding	• Identify connections • Condense codes	Ordering	• Hierarchically order codes