Keywords

1 Introduction

Open source software (OSS) is ubiquitous in today’s world. OSS is widely used within companies, not only for tooling and infrastructure, but also as a critical component of the supply chain [1, 17, 38]. Companies are not only using OSS, but are also contributing to OSS projects [2, 3] and open sourcing, or releasing as OSS, millions of lines of source code [31]. Although many single vendor open source companies opt to retain intellectual property rights to their software, some companies donate their software to non-profit foundations [12, 25, 33, 34, 36]. Becoming a donor can help companies create open standards, lower their development costs, increase sales of complementary products or services, and take advantage of faster innovation  [35, 39], but it comes at a price.

By transferring their intellectual property rights to a non-profit foundation, these companies give up the control over their software [43] and have only the same privileges as other members of the foundation. Foundation members may even compete with each other, potentially introducing conflicts and tensions because of differing interests [15, 20].

In the context of donated projects, our research question is:

  • RQ: How do foundations handle the conflicting interests of their members, when one member is a donor?

We investigate these questions through an exploratory multiple-case case study of four OSS projects which were created by companies, and subsequently donated to non-profit foundations.

The contributions of this paper are:

  • A theory of conflict prevention in open source foundations.

  • A discussion of the different types of foundations and the impact of foundation type on the use of conflict prevention mechanisms.

The rest of this paper is structured as follows: related work is reviewed in Sect. 2. Section 3 outlines the research process and Sect. 4 describes the results of our research. Limitations and suggestions for future work are discussed in Sect. 5. Finally, Sect. 6 concludes this paper.

2 Related Work

We identified three areas of research that were relevant to our topic: open source foundations, the evolution of company-created projects into open source, and conflicts in open source projects.

2.1 Open Source Foundations

Open source foundations are not all the same. For example, comparisons of the Apache Software Foundation (ASF) and the Eclipse Foundation have shown significant differences. Riehle [37] describes differences in legal status, mission, philosophy and governance structures. Furthermore, the power within the Eclipse Foundation is concentrated on the executive director, while the ASF gives most of its power to the board of directors [32]. Our work differs from previous work on conflict in open source foundations by explicitly considering the type of foundation involved.

The benefits of foundations are that they can handle donations [53]; provide communities with tools to handle corporate interests [23, 27, 28]; and manage and protect projects, intellectual property rights and communities [35]. Foundations enable shared development of software, thus reducing costs, helping to create a common standard, and increasing both reputation and visibility of members [35].

2.2 Project Evolution: From Company-Founded to Community-Managed

West and O’Mahony classify projects based on whether they are currently managed by a community (autonomous) or by a sponsoring company (sponsored) [52]. As projects may evolve from sponsored to autonomous, they also introduce the categories synthetic (sponsor-created, i.e. started as a sponsored project) and organic (community-created, i.e. started as an autonomous project) to describe the original state of the project [30]. In this work, we consider the origin of the project as a possible source of conflict within foundations, and specifically examine projects which are synthetic and autonomous according to this framework.

If a project receives its initial resources and code from a company, it can also be described as a spinout [51]. Spinouts build on an established code base and are usually supported by their creators. However, this also means that new contributors face a steep learning curve because they must understand the existing code before they can contribute. As a result, the original sponsor may remain the largest contributor after spinning out the project. For example, even several years after it was donated, the majority of the source code in OpenStack was created by its donor, Rackspace [19].

2.3 Conflicts in Open Source Projects

One source of conflicts arises from the different interests of corporate and individual participants. For example, corporate sponsors have tried to steer the development via financial rewards or wanted to close parts of the code, thus violating the philosophy of open source software [13, 42]. Other companies exploit OSS by taking more than they contribute [2]. As a result, tensions can be seen as a consequence of corporate behavior: that is, whether companies respect and give back to the community [7].

Another source of conflicts is within companies. Individuals who participate in OSS as employees of a company do not always promote the technical or business interests of their employers [3, 29, 40, 47].

Finally, there can be conflicts between companies which are members of the same foundation. Sometimes, companies can collaborate on OSS and compete in the same market, without obvious conflicts [45]. This ‘community of competitors’ coordinates OSS development for mutual benefit by focusing on non-differentiating components [15]. However, inter-company rivalry can manifest in several ways. When companies make contributions without a complementary donation of intellectual property such as patents, it hinders innovation and limits the commercial benefit of OSS [50]. When multiple companies are contributing to a project, a company has to invest more resources to influence the project [16, 41]. Companies can also be concerned about losing key developers to competitors [40]. Our emphasis is on the conflicts that can arise between foundation members, specifically in the case where one member is the project donor.

Van Wendel de Joode [46] argues that conflict management is mandatory for the success of software projects and identifies four mechanisms for managing conflict: third party intervention through mediators or arbitrators, code modularity to increase independence, parallel development lines to allow multiple solutions and the option to fork the project. Other techniques which have been proposed to resolve conflict are the promotion of shared beliefs and values, and discussions on persistent and public channels such as mailing lists [10, 24].

3 Research Process

Our research is an exploratory investigation of conflict in open source foundations, and we wanted to consider different foundations in order to develop a broader understanding of how conflict between donors and other foundation members is handled. We chose an exploratory multiple-case case study research approach combined with grounded-theory-based analysis [6, 54].

3.1 Case Study Design

A multiple-case case study allows researchers to employ replication logic to generalize case findings [54]. Our study consists of non-profit foundations as the primary unit of analysis. Our embedded, or sub-units of analysis, were made up of the different legal entities involved: the foundation itself, as well as individual companies.

As shown in Tables 1 and 2, we selected four cases based on their unique characteristics (age of the foundation, acceptance of corporate members, public versus member benefit, and whether they existed prior to the donation), thus using theoretical sampling [6] of polar types. Because of our grounded theory approach, we did not start with a preexisting theory [11]. Following Yin [54], we used a case study protocol and a case study database.

Table 1. Overview of cases
Full size table
Table 2. Overview of foundations
Full size table

3.2 Data Sources

We utilized a broad array of data sources, including documents (e.g. foundation bylaws and rules, protocols of board meetings, mailing list discussions, blog posts and press releases), podcasts and conference videos. We also conducted interviews with selected foundation representatives. More specifically, we contacted potential interview partners who had been active in the project for several years and who were (former) employees of the respective donor. With the exception of Cloud Foundry, we had one semi-structured interview per foundation. The interviews lasted between 45 and 90 min and were conducted via Skype, recorded and then transcribed. We refined our questions after each interview [6]. The case study protocol, interview protocols, and the case study database are published in an appendix [48].

As displayed in Table 3, our research incorporated more than 280 data sources, which we used for triangulating the insights and the resulting theory.

Table 3. Data sources by case and step of analysis
Full size table

3.3 Data Analysis

As is typical for grounded theory research, data collection and analysis happened simultaneously [5]. The whole process was iterative because we re-visited previously collected data and findings after new insights had emerged.

First, we started with a preliminary analysis step by creating a chronology of the most important events in the histories of the foundations and by identifying governance structures as well as the most important entities within the foundation. Moreover, we created an overview of participating companies and tracked the affiliations of contributors and board members.

Next, we used a software for qualitative data analysis (MAXQDA) to analyze the documents, all interview transcripts and the partial transcripts of the videos and podcasts while following the grounded theory approach of Corbin and Strauss [6].

We labeled text fragments with codes that emerged from the data (open coding). For example, when interview partners cited structures and rules that were borrowed from existing foundations, we assigned the code learning from existing foundations. Codes and text fragments were constantly compared to each other. Furthermore, we revised the codings after each interview in order to incorporate new insights.

The next step entailed combining codes into categories based on shared concepts (axial coding). For instance, the category limited foundation power included the codes no authority over volunteers and prioritizing project health over vendor dominance.

Finally, we started selective coding in order to reduce our model to a core category. Although conflict resolution appeared to be a suitable candidate, we discovered that the category conflict prevention was central to our findings. We focused on this category by further developing its subcategories such as governance, strategies, culture, screening processes as well as values and common motivation. Moreover, we identified the causal relation of bad behavior and the influencing factor foundation type.

We wrote analytic memos throughout analysis [5] and compared the emerging theory to existing literature. This paper uses a theory-building logic [54] where individual case reports are omitted in favor of a comprehensive theory.

4 Results

Our research question concerned the mechanisms foundations use to handle conflicting interests between members, when one member is a donor. Our analysis identified the main category of conflict prevention, as described in Sect. 4.2. We also observed that the concrete strategies were influenced by the type of the foundation as described in Sect. 4.3.

4.1 Sources of Conflict

Since the foundations attracted a diverse audience of individuals and sometimes companies, the existence of different interests and goals was hardly surprising. However, this led to conflicts when members tried to enforce their own interests at the expense of other foundation members (bad behavior). For example, some wanted to take over specific projects or committees. This was especially likely when corporate members were competing with each other, thus having conflicting interests. Competition was especially fierce when these members targeted the same users, the market potential was huge or the technology was disruptive. The interview partners were also aware that this could ultimately threaten the success of the foundation.

However, foundations and their members not only expected but even encouraged competing companies to join. For example, the donors welcomed some of their competitors if those would help them fight a single dominant competitor (see Table 4).

Table 4. Dominant competitors as common motivation
Full size table

4.2 Conflict Prevention

Figure 1 depicts our theory of conflict prevention in open source foundations. The five major subcategories from the code system were (1) screening processes, (2) governance rules, (3) prevention strategies, (4) common interests and (5) culture and values. We now describe these major categories and their relationships.

Fig. 1.
figure 1

Mechanisms for conflict prevention and their relations.

Full size image

Screening Processes. Potential new members and projects had to pass specific screening processes before being accepted in a foundation (see Table 5). These processes had two goals.

First, they tried to identify common interests and to assess the motivation of potential members. Moreover, the technical, cultural and strategic fit of new projects was determined. If a new project was proposed for donation, the foundation also wanted to make sure that the donor was interested in its long-term support while tolerating other participants.

Second, foundations—in particular the ASF—used an incubation process to teach both their governance rules and culture and values to new projects.

Additionally, these processes were described as two way vetting processes (ACS) since they did not only allowed the foundation to assess new members, but also allowed the potential members to see whether the foundation suited their needs.

Table 5. Different types of screening processes
Full size table

Governance Structures and Rules. As shown in Table 6, foundations had established formal governance structures and rules that were codified in their bylaws. Corporate members required such clearly-defined structures.

For example, transparent affiliations meant that individual contributors had to disclose their affiliations when joining the foundation. Moreover, any changes in status had to be communicated immediately. Distributed decision-making through clearly defined voting processes enabled a large base of members to voice their opinions. If the foundation was organized as a meritocracy, privileges such as the right to vote or write-access to source code repositories had to be earned through contributions. Consequently, even employees of smaller companies could reach high ranks in the foundation because of their individual contributions. Although some foundations accepted corporate members, they made sure that the amount of control through sponsorship was limited (decoupling funding from control). The foundations in this paper also established a separation of powers by transferring the technical authority to specific committees. As a result, the board of directors could only make legal and management decisions. In order to address the resource inequality of participating companies and individuals, some foundations offered different tiers of membership, depending on the size and financial possibilities of their members. As a result, these tiers could send their own representatives to the board. However, some foundations had established representation limits which limited the number of employees a single company could have on the board. Finally, the foundations and their committees saw themselves as independent entities. They made sure that their success did not depend on just a few companies by recruiting independent staff and by monitoring the behavior of corporate members.

Table 6. Examples of governance structures and rules
Full size table

Explicit Strategies. In addition to creating governance structures, the foundations also employed a set of explicit prevention strategies to protect their culture and values (Table 7).

Because of transparent processes, foundations could monitor the behavior of their members and act accordingly. They also tried to allow community participation by including the larger community in as many decision-making processes as possible. For example, proposed governance changes were made subject to community review. This required the foundations to enforce public communication by announcing and discussing decisions on public mailing lists. Finally, they could use project-specific strategies if a project was dominated by a single corporate member. This could mean sending in independent contributors, terminating the project or creating a competing project.

Common Interests. Even if members were competing with each other, they shared some common interests. For example, their contributors were described as engineers by heart (EC) who valued merit and the technical value of solutions more than corporate agendas and employment relations.

Common interests were also observed on the business side. Companies participated for pragmatic business reasons as they had commercial dependencies on the foundations’ projects. Some of them saw foundations as a possibility to create a common platform against a dominant competitor (see Table 4).

Consequently, these companies were interested in growing their former projects by attracting new allies who had the same enemy. However, this could only work if they behaved in a collaborative way. Moreover, bad behavior was limited by the costs it would incur: the money you spend and the outcome you get out of this is the big equalizer in this game. (EC)

Culture and Values. Interview partners cited the existence of a good culture and shared values as essential for project success. While they helped to prevent bad behavior, the absence of such values could even destroy a project.

Openness describes not only open access to the source code, but also to decision processes, committees and documents. Interview partners pointed out that too much openness slowed down decision processes and could scare away potential commercial members. Transparency was as important as openness. Consequently, foundations tried to restrict the use of non-public communication like private mailing lists. If a foundation allowed corporate members, equality of opportunity was important to attract smaller companies and individual members: The main role of the foundation is to make sure there is a level playing field where everybody feels safe (OSt). The foundations also valued merit by acknowledging the amount of work contributors spent on the projects. Neutrality was named the single most important thing of all (EC). Consequently, foundations should not prefer single members. Instead, a truly vendor-neutral foundation would create a safe place where even competitors could collaborate. Similar to equality, a lack of neutrality would scare away contributors. Having competing members inside a foundation was seen as a sign of its independence. Moreover, foundations did not want to depend on specific members. Finally, they valued diversity of their members to benefit from different experiences and backgrounds.

Table 7. Examples of prevention strategies
Full size table

4.3 Different Types of Foundations

We noticed that the ASF differed from the other foundations in several characteristics. For example, it tried to minimize corporate influence by allowing only individual members and by discouraging the display of member affiliations (non-affiliation). Our interview partners explicitly described the ASF as a user-led foundation, while the others were vendor-led. As a result, the ASF could not employ rules such as transparent affiliations and representation limits.

Instead, it emphasized culture and values more than the other foundations did. For example, its cultural principles—the Apache Way—and meritocracy were explicitly mentioned in its bylaws. This could be explained with the origin of the ASF: unlike vendor-led foundations, it was founded by a group of individuals (Apache Group), a “‘grass roots’ community of user-developers” [51, p. 1]. While companies are motivated by formal rules and structures [20, 23, 49], communities reflect the cultural beliefs and values [9] of traditional open source.

5 Limitations and Future Work

5.1 Limitations of the Study

Guba [21] proposed that the quality of qualitative work should be evaluated by its credibility, transferability, dependability, and confirmability, in place of measures which are appropriate for quantitative studies. For instance, a qualitative case study cannot claim statistical generalizability to a population, but this does not mean that it cannot offer theoretical generalizability, for instance through careful selection of polar cases [4, 6, 54].

Credibility can be established through triangulation. Case studies are a form of research which naturally incorporate data triangulation. We examined four cases, with three of them being backed by our interviews. However, we compensated for this fact by analyzing more than 200 other documents. While we cannot claim to have reached theoretical saturation, several researchers have noted that four cases might be reasonable due to pragmatic reasons [8].

Transferability concerns claims of theoretical generalizability [4], as described above. Our four cases were selected to vary by age of the foundation, acceptance of corporate members, public versus member benefit, and whether the foundation existed before the software donation. The differences between the ASF and the other foundations studied suggests that the dimension of membership was especially relevant.

Confirmability describes the extent to which researcher bias is mitigated. Any grounded theory analysis might be subject to coding errors or misinterpretations, and could have been influenced by previous knowledge of the researchers [11]. However, one way of reducing bias is through venting, which entails sharing the results with professional colleagues to ensure that the findings are consistent with their experiences [18]. Moreover, our consideration of extant literature enhanced the objectivity of our study [8].

Dependability is increased through maintaining a record of the research process. We maintained both a case study protocol and a case study database to improve reliability [54]. Furthermore, we applied constant comparison and memoing during grounded theory analysis to increase theoretical sensitivity [22].

5.2 Future Work

In our research, we identified two particularly interesting topics which could benefit from further study.

Role of Trust. Since individual members were volunteers, the foundations did not have formal authority over them, thus having to trust them and their motivations. Trust was also cited by one foundation member as important for conflict resolution. However, existing literature makes opposing claims. For example, Gallivan [14] regards control as far more important while other researchers stress the importance of trust in open source projects [26, 44].

Effectiveness of Non-Affiliation. It is not clear whether non-affiliation solves the problems of commercial interests instead of merely hiding them, as the underlying economic motivations still existed. Additionally—unlike foundations—companies do have formal authority over their contributors. However, there have been multiple reported cases where employees prioritized community needs over those of their employers [29, 47], so this question needs to be studied with a nuanced understanding of affiliation.

6 Conclusions

In this paper, we examined four non-profit open source foundations that managed projects originally created by companies. More specifically, we investigated how these foundations handled potential conflicts of interests of their corporate members.

By conducting a multiple-case study combined with grounded theory analysis, we established a theory of conflict prevention. We identified a combination of screening processes, governance rules, prevention strategies, culture, values and common interests to discourage bad behavior of foundation members. This is of practical value to new foundations, as well as to companies which are considering donating to a foundation. For researchers, our work contributes to the understanding of cooperation between competitors in open source foundations by explaining how conflict is prevented.

Finally, we highlighted potential future work when we discussed the role of trust and non-affiliation. The limitations of our process and a theory-testing approach might also warrant future research on this topic.