Keywords

1 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 [7, 13, 33]. However, not all enterprise software needs are addressed by classic, community-led, volunteer-driven OSS communities. In particular, community-led projects struggle to address the challenge of providing software for institutions rather than individuals, such as financial or HR systems [23]. 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 [29]. Mackie [23] 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-or-buy 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 [3, 21]. At the same time, it is cheaper than custom software, and has the potential to become the de-facto standard, reducing training costs [22, 39]. 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 [28]. 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 [31].

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 [19, 28]. Often this is done in order to dilute the power of a market leader, to reduce costs, and to create standards [6, 30, 37].

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 [39]. 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 [17, 25].

Despite the strong potential of user-led OSS foundations to address enterprise business needs in under-served or monopolistic markets [3], very little research has been conducted on the topic. The majority of examples are drawn from the education sector and are grant-funded [19, 40]. Furthermore, existing studies have focused on foundation members, with the ecosystem described primarily in terms of potential (e.g., [36]).

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 Sect. 2. The research approach is explained in Sect. 3. Results are presented in Sect. 4. Limitations and a discussion of the results are covered in Sect. 5. The paper concludes with a summary in Sect. 6.

2 Related Work

While some government-backed open-source enabled collaboration projects have been studied [5, 34], we reviewed the research on vendor-led and user-led foundations that were directly related to our study. Firstly, the vendor-led foundations and their ecosystems were considered, because of the potential similarity to user-led foundations and the greater body of work. Secondly, we covered the existing literature on user-led open source foundations.

2.1 Vendor-Led Open Source Foundations

Vendor-led foundations have been a topic of greater academic interest than user-led foundations. O’Mahoney and West [28] 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 [39], federated [16], or consortia [32].

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 [27]. 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 [16, 38]. 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 [30, 37].

2.2 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 [39]. 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 [12, 35]. We have opted to refer to it in this paper as user-led, due to the risk of confusion with classic, volunteer-driven 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 [18,19,20, 22]. Haganu [12] 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 [17].

3 Methodology

To address our research goal, we performed a qualitative survey to investigate the phenomenon of the ecosystem surrounding a user-led consortium [1, 15, 24]. 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 [18]. 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 [26] in 2013, followed by two publications on software architecture and quality [9, 10]. 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.

3.1 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.

Table 1. Interviewees by oK membership type, ecosystem and company roles
Full size table
Fig. 1.
figure 1

Coding steps and activities

Full size image

3.2 Analysis

We made use of a data analysis process inspired by Eisenhardt [4], with the addition of thematic networks [2]. Eisenhardt [4] offers guidance specifically for building organizational theories. Figure 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.

4 Results

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

4.1 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 [8] 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.

4.2 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 [14].

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.

4.3 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 ven- dor, 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 vendor-independent 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.

5 Limitations and Discussion

5.1 Limitations

This study followed a methodology suggested by Eisenhardt [4]. 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 [11], 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.

5.2 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 [37], 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.

6 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.