On Company Contributions to Community Open Source Software Projects

—The majority of contributions to community open source software (OSS) projects are made by practitioners acting on behalf of companies and other organisations. Previous research has addressed the motivations of both individuals and companies to engage with OSS projects. However, limited research has been undertaken that examines and explains the practical mechanisms or work practices used by companies and their developers to pursue their commercial and technical objectives when engaging with OSS projects. This research investigates the variety of work practices used in public communication channels by company contributors to engage with and contribute to eight community OSS projects. Through interviews with contributors to the eight projects we draw on their experiences and insights to explore the motivations to use particular methods of contribution. We ﬁnd that companies utilise work practices for contributing to community projects which are congruent with the circumstances and their capabilities that support their short- and long-term needs. We also ﬁnd that companies contribute to community OSS projects in ways that may not always be apparent from public sources, such as employing core project developers, making donations, and joining project steering committees in order to advance strategic interests. The factors inﬂuencing contributor work practices can be complex and are often dynamic arising from considerations such as company and project structure, as well as technical concerns and commercial strategies. The business context in which software created by the OSS project is deployed is also found to inﬂuence contributor work practices.


INTRODUCTION
O PEN source software (OSS) is widely deployed in commercial software products and services [1], [2], [3] and within companies [4], [5], [6], and is used to support open innovation processes between companies [7], [8]. Given the level of integration into company products, processes and services, company software developers have long contributed to OSS projects for many reasons, including improvement of the quality of the software they use and a desire to influence the direction in which the software is developed [1], [8], [9], [10], [11].
Research on developers' contributions to OSS projects has focused on the motivation and behaviour of individuals [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], as well as the challenges of using the tools available to make technical contributions [22], [23], [24], [25], [26], [27]. A wide range of research on company engagement with and contribution to OSS projects has provided an understanding of the motivations of companies to use OSS and to work with projects, and their ways of working [8], [10], [11], [28], [29], [30], [31]. However, while some research illuminates company strategies when engaging with OSS projects [8], [28], [30], [31], [32], [33] often it is in the context of projects where the company has a controlling influence over the community and the direction of software development. In this work, we focus on engagement by companies and their employees and contractors with community OSS projects. By community OSS project we mean an OSS project managed by a foundation or otherwise collectively organised [34], where many contributors are professional practitioners directed by companies and other organisations who collaborate to create high quality software [1].
Decisions on how companies engage with community OSS projects are taken both by managers within each company and individual developers, and the majority of contributions are made directly by developers or other employees, who decide how to conduct each individual interaction with the project [28], [31], [34], [35], [36]. It can be inferred that many contributions made by companies are motivated by software development needs driven by business requirements. Further, we conjecture that practitioners commissioned by companies are working with technical, fiscal and temporal constraints within the business context that may not be apparent which also motivate contributions and how they are made. The context for decisions about engagement and contributions is also determined by the governance [37], [38] and licensing [39], [40] of the OSS project as well as the strategic interests of other participants in the project [31], [33]. Previous research has shown that when a company and individuals (owners, employees and contractors) affiliated with the company engage with an OSS project governed outside the company's control and specific development context, it is critical to adhere to established "work practices that are appreciated by community members" [41].
This article seeks to illuminate how companies engage with and contribute to OSS projects independent of company control and collaborate with other companies and organisations to achieve their own and common aims. To that end we ask the first research question:

RQ 1: How do companies contribute to community OSS projects?
The context in which a company contributes to a community OSS project is framed by many factors, including the business and technical interests of the contributing business, as well as those of others in the community, and the governance systems of the OSS project. Less clear is how those factors combine to motivate the use of particular work practices, i.e. the specific methods or approaches used to collaborate in community OSS projects. For example, why a particular method of interaction might be chosen to achieve a given outcome. To explore the motivations of companies and practitioners working on their behalf to adopt specific work practices we ask a second research question: RQ 2: What factors inform the selection of specific work practices used by companies to contribute to community OSS projects?
To answer RQ 1 we undertook an investigation of the public online records of eight community OSS projects (including mailing lists and issue trackers) to identify the opportunities to make contributions to each project and the work practices used to make the contributions. In addition we interviewed practitioners from companies engaged with the eight community projects investigated to obtain further information about the types of contributions made, particularly those that may not be apparent from public records. The interviews also explored the practitioners' motivations to use particular forms of contribution in order to answer RQ 2. The interviews examined both the more strategic or policy level decisions about why a company might engage with an OSS project in a particular way, and the choices individuals working for companies make about how to make a contribution to an OSS project.
This research extends previous work [42] that investigated RQ 1 in five community OSS projects. In this research the scope of the investigation is increased to include all contributions made to a project, expands the number of OSS projects studied from five to eight, and adds a second research question to examine motivation for the observed behaviour.
The remainder of the article is structured as follows. We first present background information and a review of the academic literature (Section 2). In Section 3 we outline the research methodology and give details of the selected projects in Section 4, including the governance mechanisms that frame project activity. In Section 5 we present results, which detail interactions between companies and OSS projects as well as the reasons given by developers for the approaches used. In Section 6 we analyse and discuss the results, and present the conclusions from the study in Section 7.

BACKGROUND AND RELATED WORK
In a keynote presentation at ICSE 2017, the Executive Director of the Eclipse Foundation, Mike Milinkovich, explained how many companies strategically engage with OSS projects and claimed that "every software company is an open source company" [43]. Research shows that many companies in different sectors, utilise software that is developed and maintained by OSS projects external to the company [44]. Software created by OSS projects supports business activities, including software development, as part of revenue generating products and services, and as part of open innovation processes [7], [8]. Practitioners engaged with software deployed from well-known community OSS projects (including Linux and the Apache web server) and open source foundations (e.g. Eclipse Foundation and MariaDB Foundation) experience many business benefits, and at the same time encounter a number of challenges that companies need to overcome in order to engage successfully with and contribute to OSS projects [43], [45].
Community OSS projects, like Linux and the Apache web server, are organised for the mutual benefit of participants, in contrast to single vendor, or company controlled, OSS projects, where the OSS project is intended to benefit the controlling business [46]. The development of software by companies in open innovation processes mediated by community OSS projects has been described as "OSS 2.0" [1]. The benefits to businesses of contributing to OSS projects extend beyond the creation of software and include the acquisition of marketable knowledge and expertise [47], and organisational learning [8], [9], [48]. Individual contributors also benefit in terms of their careers [21] and their careers within projects [49], which also has value for the employer [21], [31].

Business and OSS Projects
Research on the interaction between companies, practitioners, and OSS projects has been undertaken from a variety of perspectives (See Table 1). Fitzgerald [1] articulated the idea that OSS development had evolved from being dominated by individuals to a process where businesses, and, particularly, professional software developers undertaking paid work on behalf of businesses, collaborate to develop software, and characterised it as OSS 2.0. The continuing growth and development of OSS 2.0 is exemplified by very large scale community OSS projects like OpenStack.Ågerfalk and Fitzgerald noted that businesses using and contributing to OSS projects take part in external collaboration with an "unknown workforce" [50]. A further observation made byÅgerfalk and Fitzgerald, and also by Dahlander and Magnusson [30], was that the working relationships between companies within OSS projects are not governed by contracts that, for example, formally specify deliverables and delivery dates. Consequently, companies need to give careful consideration to the relationship between internal software development processes and engagement with strategically important community OSS projects. The strategic concerns, as Lundell et al. [44] argued, include the sustainability of both external OSS projects important to the business and the business itself.
Riehle [34], [46] identified the principles of the business models used by participants in community OSS projects, arguing that the software developed is often restricted to core non-differentiating functionality to which companies then add value to generate revenue. Further, Germonprez et al. [36] highlighted that community OSS projects are, sometimes unplanned, collaborations between competitors to create core software platforms.

OSS Project Governance
In the absence of contracts, governance processes used by OSS projects provide the basis for collaboration between businesses involved in OSS projects; regulating financial contributions, where they are permitted, and contributions from individuals working on behalf of the businesses. Research has examined forms of governance, and how governance facilitates both contributions and the activities of contributors. Markus [37] synthesised a set of core functions a governance system fulfils from a review of the academic literature. Informal aspects of governance found as norms within OSS projects are recognised, in addition to the formal aspects of governance recorded as rules. Four broad types of governance are identified by Germonprez et al. [52] that include meritocracies, as well as more flexible systems, and that these forms of governance can coexist within the same project. In a case study of the Linux kernel, Shaikh and Henfridsson [38] found that governance evolves within an OSS project and may also manifest itself as different coexistent forms. Furthermore, Shaikh and Henfridsson found evidence that the tools used to manage software development contribute to the project governance process [38]. Alves et al.'s [51] systematic review of the literature on governance systems supporting both open and proprietary software ecosystems identified three key aspects of governance systems: how the participants are able to create value from their contributions, the coordination of the activities of contributing organisations, and mechanisms used to balance between openness and control.

Business: Activity and Motivation
Bonaccorsi and Rossi [10] found that companies were motivated to contribute to OSS projects for economic and technological reasons, rather than the more altruistic motives sometimes ascribed to individuals. Germonprez et al. [36] described business motivations to use community OSS as a means of open collaboration to create core, nondifferentiating software. The authors also identified that the process of collaboration is not always easy, but that participants gain clear economic benefits [36]. Activity in two community OSS projects governed by foundations and four OSS projects each controlled by a single company was compared by Mäenpää et al. [53] who found the foundation governed projects facilitated greater external collaboration through increased openness.
Businesses can also be motivated to participate actively in a project for strategic purposes. Schaarschmidt et al. found resource deployment -the deployment of company developers in the OSS project -was a common strategy in the community OSS projects investigated, particularly where company developers acquire committer or core developer 1 status [31].
The acquisition of knowledge is also an important benefit for businesses participating in OSS projects. The contribution to organisational learning was identified by practitioners interviewed by Lundell et al. [9]. The finding is supported by Munir et al. [8] who observed the value to a company of knowledge interchange with OSS projects in an open innovation process. Andersen-Gott et al. [47] also highlighted that technical knowledge gained through contribution to an OSS project can be monetised by the business through the provision of complementary services. The finding is aligned with earlier work by Lakhani and von Hippel [48] which concluded that the main beneficiaries of help-giving in the Apache web server project were the help-givers themselves, who derived direct learning benefits from the experience.
Businesses can also be cautious about contributing to community OSS projects. A study of OpenStack by Zhang et al. [56], [57] considered the importance of dominance of the software development process by particular companies and the consequences for both the software created by the OSS project and the community. The authors concluded that there are advantages to single company dominance for software development, but that some smaller companies become reluctant to contribute to the development process because of concerns that they are providing free labour to support the efforts of the dominant companies [56], [57]. An investigation by Morgan and Finnegan [55] found tensions between senior managers' desire for the company to be selfreliant and the opportunity to derive business value from OSS. Lundell et al. [54] also found differing attitudes towards collaboration with OSS projects held by technical staff and management. Caution also extends to technical contributions. Linåker et al. [7] studied a model, developed within Sony Mobile, that supports decision-making concerning the contribution of internally developed enhancements to OSS projects. The concern for the company is to distinguish between source code that represents functionality that has business value, and code that can be contributed to the upstream OSS project.

Practitioners: Activity and Motivation
The motivation of individual developers to contribute to OSS projects has been studied extensively. Many authors, including Lerner and Tirole [12], have found that developers are motivated by "career considerations and ego gratification" [12]. More recent studies of developers working in community OSS projects continue to support this perspective. The motivating factor of a "career path" for company developers working on OpenStack was found by van Wesel et al. to be a strong influence on their activity [49], while Riehle [21] highlighted the value to developers' careers of contributing to OSS projects. Furthermore, Riehle [21] provided evidence of the value of core developers to businesses also identified by Schaarschmidt et al. [31]. However, the studies focused on the motivation of developers to work 1. We use the term core developer to refer to contributors who have commit privileges to the project version control system and therefore act as a gatekeeper.  [58] with OSS projects, and did not examine either how developers work to support the aims of the business they work for, or the commercial pressures and constraints on their activity. The retention of contributors by OSS projects has also been a concern for researchers, particularly in the first few months of a contributor's activity. Zhou et al.'s study of company developers contributing to Gnome and Mozilla [58], for example, examined the characteristics of the behaviour of those who became long-term contributors, rather than making a small number of contributions at most. However, the study did not consider the motivations of company developers whose involvement with the project might be intended to complete a specific task for commercial reasons.
Further evidence of short-term or intermittent contribution by individuals is found in the research literature. For example, Pinto et al. [19] investigated contributors to GitHub projects that make single or very limited contributions, sometimes referred to as drive-by, or casual, contributions. Although the authors considered the motivations of contributors they did not consider commercial aspects in detail. However, they observed that some casual contributors were known to be longer-term contributors to other OSS projects. An investigation by Lin et al. [18] found contributors to five community OSS projects who created source code tended to have briefer relationships with projects than those who edited the project source code. The focus of the work was on developer turnover in projects and did not examine the reasons behind short-term contribution. A speculative explanation might be that some developers contribute source code to resolve an issue of significance to their employer, and once the task has been completed there is no business case to contribute further code.
To summarise, the academic literature identifies the business incentives to contribute to community OSS projects, and the principles of the business models used to generate revenue from participation. There is also evidence that businesses gain from participation in OSS projects in other ways, such as knowledge acquisition. Researchers have also identified that participation in OSS projects can be challenging for businesses. Much research acknowledges that contributors to OSS projects are mainly acting on behalf of businesses, and documents the career incentives for developers. However, few studies examine how such developers interact with OSS projects, particularly community projects, to undertake tasks in order to achieve business goals.

RESEARCH DESIGN
In this article we report on a descriptive multi-case study [59] of a purposeful sample [60] of eight community OSS projects. We initially compiled a list of software created by OSS projects that is of strategic importance to the businesses represented by six of the authors. From that list, we selected eight OSS projects to investigate according to three fundamental criteria. Firstly, the projects investigated are community OSS projects; that is they are neither exclusively controlled nor maintained by a single commercial entity, but are maintained independently, by independent foundations, or under the aegis of the Apache Software Foundation (ASF) and the Eclipse Foundation. Secondly, the projects are widely used in that they are deployed in, or support the development or provision of, products and services in multiple business; i.e. the projects studied provide software recognised by many businesses as appropriate for use in commercial contexts. Thirdly, the projects have active communities of contributors, and histories measured in years. In addition, the software solutions implemented by the projects are not concentrated in a single domain and represent a variety of project types including open innovation and large-scale industry collaborations (See Table 2). Furthermore, the eight projects are also ones that seven of the authors have first hand experience of as users in commercial deployment contexts and as contributors. In summary, in this work we investigate company participation in OSS projects where there is a non-exclusive relationship between the contributor and the project, and the company must interact with other contributors -commercial entities and individuals -to achieve its goals.

Archival Investigation
We examined the public archival records [61] available for each of the eight projects to investigate the first research question. Beginning with the project website and any project pages on foundation websites, we identified the online resources that define the project and how it works, as well as the systems used to contribute to the project including mailing lists, changelogs, and bug tracking information (see Appendix A for details).
The interactions recorded in publicly available online resources for each project were analysed. Firstly, to identify the forms of communication used to contribute to the projects and the types of contribution made; and, secondly, for evidence of both the manner in which interactions were conducted and their outcomes. The resources used by each project vary and those examined include mailing lists, online forums, and bug and issue trackers.
Three categories of activity in OSS projects reported in the academic literature were used as an a priori framework to identify the wider purpose of the contribution: bug reports [62], feature requests [62], and support messages or help requests [48], [63]. A fourth category was also used to capture events outside the scope of the other three categories, including project governance activity.
The characteristics of the work practices used by individuals to pursue their aims in each contribution were also identified and captured using an open coding process, informed by Glaser's ideas [64], [65]. The first author took main responsibility for the coding process and emerging codes were discussed and scrutinised by the first three authors as the coding progressed. A key principle adopted is the notion that, contingent on context, any unit of coding is acceptable. Accordingly codes are applied to email threads, issue tracker tickets, individual comments, emails, and to sentences to develop and refine abstract concepts grounded in the data to support reporting of observations. Evolving observations were discussed by all authors.
We followed an iterative coding process. Initially, one month of activity on the Apache Solr issue tracker and the four project mailing lists was considered in the analysis. Eleven more months of activity on Solr was subsequently considered so that the period between April 2017 and the end of March 2018 was analysed. Thereafter activity in the public communication channels of each project was considered for the same period, with the exception of OpenStack Nova. OpenStack Nova has a volume of activity and number of communication channels that is considerably greater than the other projects analysed. Three months of activity (May and October 2017, and January 2018) were selected at random for analysis.

Practitioner Interviews
To contribute detail to the first research question and to investigate the second research question we conducted open interviews with contributors to each project. Email invitations were sent to individuals identified as having contributed to each of the eight OSS projects in public communication channels as part of their employment. In total, seventeen respondents were interviewed; nine and eight respectively from the primary and secondary software sectors [66]. The majority of interviewees were employed to work in multiple roles, including non-technical roles. Sixteen interviewees, for example, spent at least part of their working week as a software developer, and some of those also had a role as a core developer in an OSS project as part of their paid work. Some interviewees had consultancy roles; both technical consultancy working with a specific OSS project, and providing bespoke solutions where the OSS formed part of the solution. Just less than half also had non-technical roles, for example in business management and in practitioner training. As well as experience of project governance as core developers, a few interviewees also had wider experience of foundation and project governance having had roles on steering committees and in foundation administration. Interviewees with software development roles all have several years of industry experience. Some have sought roles where they can contribute to OSS projects, while others work with OSS because of strategic decisions made by their employer.
Interviews were conducted in English by the first author of which fourteen were conducted by telephone and three by email. English is the native language of the first author and four interviewees (all telephone interviewees), and a working language for thirteen interviewees. Interviewees were informed that reporting of the research will preserve anonymity for both the individuals and their employer so that they were able to discuss their experiences and motivations more freely.
Interviews initially probed for a generic understanding of the interviewee's work context through an opening question of the form: "Please describe your involvement with [OSS project] and how that activity relates to your employment?" For each interview a number of follow up questions were prepared to explore observed activities in which the interviewee had participated.
The telephone interviews were recorded and transcribed. Each interviewee was sent the transcript of the interview to check the transcription of the conversation and correct any misunderstandings that may have occurred during the conduct of the interview. Interviewees were also invited to expand on any points made during the interview, if they wished.
The approved interview transcripts were analysed using an open coding process (using the same open coding strategy as used in the archival investigation, see Section 3.1). A coding scheme was developed through analysis of the first five interview transcripts by the first author and evolved iteratively thereafter. A coding dictionary was maintained and the coding of interviews was reviewed following each interview through scrutiny by the first three authors as the systematic coding process progressed. Anonymised synopses of the interviews, including quotes, were discussed by all authors during a four month period to allow time for reflection. In retrospect, we found that after twelve interviews saturation was being reached because subsequent interviews gave very limited additional material apart from further examples supporting the evidence already gathered.

CASES AND CASE CHARACTERISTICS
The eight OSS projects investigated are: Apache CloudStack, Apache Solr, Bouncy Castle, Contiki-NG, Eclipse Leshan, MariaDB Server, OpenStack and Papyrus (See Table 2). As well as having a specific technical mission, each project provides opportunities for both companies and individuals acting on their behalf to interact with the project. The governance model for each project defines the intellectual property mechanisms and communication systems through which contributions are made (See Table 3). In addition, contributions may be made to the governing foundation depending on its financial structure (See Table 4).
Apache CloudStack provides a cloud computing platform. Initially developed as a proprietary licensed product, CloudStack became an OSS project in 2010 and came under the control of the ASF in 2012 [76]. Apache Solr was initially proprietary licensed software that became an OSS project governed by the ASF in 2006. The close relationship with the Apache Lucene project led to the integration of the two projects in 2010. Bouncy Castle is a widely used cryptographic library first released as an OSS project in 2000. Contiki-NG provides an operating system for small, low-powered devices [77]. Contiki-NG was forked 2 in 2017 from Contiki-OS, which was established as an OSS project in 2003. Contiki-OS remains an active OSS project, but has not released a version of the software since 2015. The Contiki-NG project is independent of company control and managed by its core developers. MariaDB Server is a fork of MySQL. Originally a closed source database management system, MySQL was established as an OSS project in 1995. MariaDB Server was forked from MySQL in 2009 and the MariaDB Foundation was created in 2012 to preserve the project's independence. Leshan and Papyrus are projects in the Eclipse ecosystem and are governed by the Eclipse Foundation. Leshan is an implementation of the Lightweight Machine to Machine (LWM2M) protocol [78] and is overseen by the Eclipse Internet of Things Working Group [79]. Papyrus is an industry-led project to create a UML and SysML modelling tool and has been an Eclipse Foundation project since before its initial release in 2008 [35], [80]. Papyrus is managed by the Papyrus Industry Consortium [81], a member of the PolarSys [82] working group, which oversees a number of projects focused on model driven engineering and embedded systems. OpenStack provides a platform that supports the provision of private and public clouds through virtual servers and software defined storage on heterogeneous hardware [83]. Development of OpenStack is supported by the Open Stack Foundation [84].
The governance of an OSS project outlines the management of the project itself and its assets, and defines the mechanisms through which the project publishes information, manages activities and receives contributions. Markus [37] identified six categories of formal and informal governance structures and rules found in OSS projects.
• Ownership of Assets: rules for ownership of intellectual property, foundation structure.

2.
A fork occurs where an OSS project divides into two separate projects. There are many reasons why projects may fork including inactivity by core developers and disagreements over the direction of software development [41].
• Chartering the Project: the goals of the project.
• Community Management: rules pertaining to membership and the roles members may have.
• Software Development Processes: rules for requirements gathering, coordination, software changes and release management.
• Conflict Resolution and Rule Changing: rules concerning conflict resolution and changing rules.
• Use of Information and Tools: rules concerning communication, and the use of tools and repositories. Table 3 provides an overview of the way each of the eight selected projects implements governance mechanisms for each category identified by Markus, with the exception of 'Chartering the Project' which all eight projects do through their websites and in other documentation, and is omitted from the table to avoid duplication. The MariaDB Server project, for example, states that the software is ". . . an enhanced, drop-in replacement for MySQL" and will remain open source [88].
The practical differences for individual contributors that arise from the governance mechanisms are in two main areas. Firstly the communication channels and software development coordination tools used by the projects vary in number and complexity from Contiki-NG's use of a GitHub repository, to the multiple mailing lists, code review tools, planning system and internet relay chat channels used by OpenStack. Secondly, the mechanisms used by the projects to acquire the right to use and distribute contributed source code introduces a layer of bureaucracy in six projects. The ASF, Eclipse Foundation projects, and OpenStack ask individual contributors, and companies, for ASF projects and OpenStack, to complete a Contributor Licence Agreement (CLA) [89], [90], [91], [92] 34 which gives the project or foundation a perpetual copyright licence for the contribution. The MariaDB CLA [93] is used for contributions made using version two of the GNU Public License (GPL v2) and relies on copyright assignment. The MariaDB CLA grants joint copyright at the point of contribution and, thus, appears to function similarly to a copyright licence. Contributions to MariaDB can also be made using the permissive MIT Licence. From a contributor's perspective, a CLA requires a business to approve the terms under which technical contributions are made on its behalf, and for practitioners acting for a company to seek that approval.
The licences under which the source code for each project is distributed place varying obligations on users that modify the source code, and few restrictions on users deploying the software. The more permissive licences -BSD 3-Clause, the Eclipse Distribution Licence (EDL) and MIT -place yet fewer obligations on users of the software, allowing industrial users to integrate the code with their own solutions and products.
Companies and individuals may also contribute to the foundations financially, or in kind, and the nature of the relationships formed between the foundations and the donors is related to the legal status of each foundation (See Table 4). 3. We refer to v2.0.0 of the ECA dated 2016-08-22, which was in force during the period of data collection for this research. v3.0.0 of the ECA was published in October 2018.
4. Access to the OpenStack CLA requires a Launchpad account. The Legion of the Bouncy Castle Inc. supports the development of the Bouncy Castle library through donations from companies and individuals [94]. The ASF uses sponsorship to pay for the infrastructure used by projects, accounting and legal costs, as well as marketing [95]. The Eclipse, MariaDB and OpenStack Foundations offer a range of membership types through which companies and organisations are able to influence the direction of software development to varying degrees [96], [97], [98], [99]

RESULTS
In this section we report on interactions between practitioners representing companies and OSS projects. First we report observations of how businesses interact with OSS projects when making contributions. We then report on why software developers, both core and non-core, use specific work practices, and their employers' motivations to contribute to the OSS projects.

Work Practices Used to Contribute to OSS Projects
Governance frames the activities of contributors to OSS projects and the public communication systems through which they contribute to projects. Through examination of interactions found in archives of the collaboration platforms used by the projects 5 we identified work practices used to contribute to OSS projects.

Bug Reporting and Fixing
Practitioners adopt two fundamental approaches when reporting bugs. One approach is to ask an exploratory question on a mailing list or in a forum. The question typically enquires about some functionality to ensure that the submitter understands how the software is intended to work and whether the observed behaviour is to be expected, the result of error on their part, or a genuine issue (See Table 5, Example 1). Often the contributor will include precise details of the software, hardware and operating system they are using to provide context. Where the issue is identified as a 5. Appendix A lists the data sources and archives examined.
bug it may then be reported via the issue tracker, either by the original contributor, or by a core developer. Where the contributor is more certain they have identified a problem with the software a bug report is submitted to the mailing list or issue tracker with supporting evidence (Example 2). Bug fixes are contributed to projects in response to an identified fault and, sometimes, with a bug report. The mechanism for contributing bug fixes varies according to the tools projects use and the project workflow. For example, a bug report accompanied by source code may be submitted as a pull request on GitHub. Many projects prefer that bug fixes are submitted with unit tests that establish both the problem and that the bug fix solves the problem and to support regression testing (Example 3). Where unit tests have been omitted from a proposed bug fix the core developers will often request unit tests to support fixes as part of the code review process.
Interactions with an OSS project require the input of company resources, including staff time, and, thus, are a financial cost for the business. Many reports of issues consist of a few steps and messages exchanged between the contributor and the OSS project (as in Example 2). However, sometimes, despite details being provided the core and non-core developers manage to misunderstand each other, which may require further contribution of time by both parties (Example 4). Contributions in larger projects can also be forgotten or take a long time to be integrated into the code base, especially when they are not a priority for core developers, and, thus, have the potential to become wasted effort for the contributor (Example 5).

Feature Requests
Non-core contributors also make requests to add new features to OSS projects. As with reporting bugs, the opportunities available for the initial approach include an exploratory question on a mailing list, in a forum or as a GitHub issue, so that the contributor can understand whether the project would be receptive to the proposed feature (Example 6).
Sometimes, as with bug fixes, non-core developers will submit a feature request with the source code that implements the feature. The implementation represents an investment of resources by the contributing company. Typically,  as with code submitted to fix bugs, the developer will take part in a review process and revise the code to ensure that it meets the core developers' requirements before it is integrated into the code base. There are also occasions where contributors do not take part in the review process and the code, depending on project policy, often does not get merged into the project. It is uncommon, but significant amounts of software development work (sometimes of the order of thousands of lines of code) can be submitted and abandoned by their contributors. In some cases, the core developers have reviewed the contribution, the requested revisions are not made, and the contributor does not respond to further messages (Example 7).
Review comments on source code submitted by noncore contributors are, in many OSS communities, mostly made by the core developers who have to accept the code. Sometimes, however, commercially unrelated non-core developers will contribute to code reviews and we infer that there are likely to be strong motivations for what appear to be unconventional actions. Observed interactions include the addition of relatively minor technical points that may improve the maintainability of the code (Example 7). We also observed a core developer not directly involved in the code review process intervene when they recognise a more generic use of a new feature that helps their employer's use of the software (Example 8).
OpenStack Nova uses a different process for making a feature request. The most common workflow is that an idea is discussed initially in the IRC channel and a proposal subsequently developed and added as a blueprint on the Launchpad platform (Example 9). The blueprint can be reviewed by the community to ensure that the proposal is relevant for the project, that the proposed implementation is sound and does not duplicate or restrict existing functionality, or overlap with other proposals. The blueprints also support traceability of the feature implementation and associated code reviews.
Core developers also make feature requests. Mostly, feature requests made by core developers are openly documented alongside those made by non-core developers in the projects investigated, including Leshan, OpenStack, and Solr. Feature requests are made openly so that other members of the project community can understand what functionality and implementation is being proposed, that the idea is sound, and welcome, and to identify whether the idea has been considered previously (Example 10). Furthermore, documenting intended areas of development may attract potential contributors.

Support
Project documentation may be incomplete, misunderstood, not read closely, or possibly out of date. Consequently, users of the software often seek help on mailing lists and in forums, and both core and non-core contributors provide support (Example 11). As software users, those giving help have detailed collective knowledge of the deployment and use of the software.
Mailing lists and issue trackers are asynchronous communication channels. Sometimes practitioners seeking help may have solved a problem, or have continued working on it, while waiting for a response. In such cases, practitioners can provide a commentary on their ongoing problem solving activity and the outcomes (Example 12).
Occasionally, contributors make mistakes and take actions in communications channels that the core developers may not anticipate, despite extensive documentation of how the core developers expect contributors to behave. Typically, users would be expected to ask for help on a mailing list and only to use the issue tracker when a bug has been identified. However, on occasion, help questions can be posted directly to the issue tracker (Example 13). The response of the core developers to such errors varies from project to project.

Other Activities
While the literature reports three groupings of contribution made in the communication channels of OSS projects, those active in OSS projects contribute in other ways. Three main additional types of activity are observed. The first is the creation and maintenance of documentation. A second type of activities relates to project governance and administration, and community building. Thirdly there are opportunities for additional activity in some larger projects as a consequence of the additional communication channels and tools available to developers.
Documentation activity in OSS projects can be seen as two processes. There is a deliberate effort to create and maintain documentation of the software. In some larger projects, such as Solr, there is often at least one person who focuses on managing the documentation effort (Example 14). The other form of documentation is a knowledge maintenance task undertaken by contributors -mostly core developers -that occurs during other activities such as providing support, fixing bugs, and feature implementation. While working on the primary task, links or connections are made to related items in the issue tracker, and sometimes to sources of information outside the project. Recording connections between mailing list threads, issues and other items annotates and connects knowledge within the communication and software development systems to create a detailed, emergent documentation of the project.
Project governance activities and opportunities differ between foundations and projects. ASF project core developers, for example, vote to accept a release candidate as the next release. ASF project management committees also vote privately to appoint new committers, who are subsequently introduced to the community on the developer mailing list. A similar process happens when new core reviewers are appointed for OpenStack Nova. Occasionally, projects need to discuss issues such as the impact of the foundation's intellectual property rules on the project (Example 15). The core developers in most of the projects studied are responsible for ensuring contributors have completed the appropriate CLAs when making their initial technical contribution.
In addition, OpenStack Nova, as noted, uses IRC extensively and makes logs available so others can, as with email threads, follow discussions and understand the discussion leading to a specific decision. IRC is also used to help coordinate other aspects of OpenStack development in close to real time (Example 16), as well as a channel for automated messages from the Gerrit code review tool, and to organise or invite review for particular code revisions. Also within OpenStack are a number of special interest groups (SIG) 6 that developers with common interests use to coordinate their activities across the project.

Motivations to Adopt Contribution Strategies
In this and the following subsection we report on analysis of the data collected from interviews conducted with contributors to the eight OSS projects studied. This subsection focuses on the strategic choices made about company contributions to OSS projects, and the following subsection (Section 5.3) focuses on why practitioners use individual work practices. In both subsections we report additional work practices, or aspects of those reported above, which were uncovered during the interviews.
A variety of factors influencing the type and extent of company engagement with the eight community OSS projects emerged from analysis of the collected interview data (See Table 6). Two key factors influencing the extent of engagement are the relationship between the company's business model and the deployment of the project software, and the maturity of the domain and the software. Another factor identified is the influence of the location of knowledge and expertise within the project and the contributing business on the manner in which companies contribute to OSS projects. Some contributors to OpenStack and Apache CloudStack worked 90% or more of their time on the OSS project. In each case the company involved deploys the software as a key component of one or more of the company's revenue streams. In one business model, for example, the software is deployed to customers as a platform for them to deliver their services and products, in another the business deploys the software as a platform to support service delivery to 6. The OpenStack SIGs are listed at https://wiki.openstack.org/ wiki/OpenStack SIGs and include activities related to supporting newcomers, and high performance computing OSS is deployed to generate revenue by delivering functionality or service to customers.
Revenue generated through adding value with software that depends on, adapts, or enhances OSS.
OSS project as an open innovation platform and revenue is generated by other company products.
Software and Domain Maturity The technical context of the OSS project software, including the factors contributing to the evolution of the domain and the pressures for continuing software development.
Domain: evolves through external pressures e.g. technology change.
Software: additional functionality required by user.
Software: incomplete implementation of specification.

Knowledge and Expertise
The knowledge and expertise required to deploy and develop software is not evenly distributed in OSS project communities.
Core developers have implementation expertise.
Other contributing businesses may have the required implementation or domain expertise.
Users of an OSS project have extensive experience of deploying the software.
their customers, as well as being a platform their customers could also add value to. The cost to the businesses of switching to different software would be considerable, or even existential, as stressed by one interviewee: ". . . if the project dies then basically our company dies because the core business of the company is based on [the OSS project]." Where the business's product is part of the OSS project, the business adds value to the OSS by developing functionality for itself or a client, and contributes enhancements to the OSS project, perhaps identifying possible bugs as well. Some other businesses contributing to OpenStack and Apache CloudStack use a more product-focused strategy. Product-focused companies are similarly reliant on deployment of software from the OSS project to deliver services to their customers. While the contributors, the company developers, still work on the upstream project their main focus is on the product they develop within the business. The product is integrated with or dependent on the software created by the OSS project, and company developers contribute features in the project software and fix bugs to meet specific requirements to support their product.
The high level of confidence that businesses place in the capabilities and initiative of some individuals at the centre of their engagement with OSS projects was also reflected in the qualitative analysis. Some developers were given a great deal of license by their employer to work on the OSS project while delivering value to the business. For example, one interviewee commented that around 90% of their work on the OSS project was not specifically requested or directed by the company. The employer was said to have decided to invest in the OSS project to improve the quality and extend the functionality of the software, which is integral to the business. As the interviewee observed: "If we work towards code quality and community building, [the project] will become more attractive for other developers." By encouraging wider deployment and participation the company anticipates maintenance costs will be reduced in the long term.
In addition, interviewees suggested other reasons for the intensity of the company's engagement with CloudStack or OpenStack including the relative size of the project and the relatively fast pace of software development, as well as the evolution of cloud services and the cloud domain. Two developers commented on the reciprocated development effort between company and OSS project as mutually beneficial, with one saying: ". . . we provide contributions to [the OSS project] at the same time that we get benefits from the community." Another described the process as follows: ". . . we execute the change in our branch and then we push to upstream. We work with a custom fork of [the project], which enables us to customize it to our needs and to create new features faster. We do have a roadmap to migrate back to upstream versions. Then, we fork again, and so on." The IoT sector, for example, follows a similar open innovation model to that seen in CloudStack and OpenStack by developing standards compliant infrastructure, such as communication protocol stacks, in OSS projects. The business model identified from analysis of interview data is product-focused. Companies collaborate in OSS projects, such as Leshan, to implement infrastructure that complies with established technical standards. Accordingly, development and maintenance costs for the communication systems are shared between companies contributing to the OSS projects. Individual businesses generate revenue through the development of connected products. Importantly, those products are interoperable because they have been developed to use standards-based implementations of supporting infrastructure. Furthermore, the development of new products is supported through the provision of reference implementations of communication and server infrastruc-ture. In addition to businesses developing products, some companies employ developers to work on open innovation projects, though not exclusively on a single project 7 .
A third group of businesses are identified from analysis of the interview data. The companies can be less directly engaged with OSS projects as a consequence of their business model. Interviewees working for consultancies, and as individual consultants, for example, tended to interact intermittently with the OSS project, mostly when deploying software for a client or maintaining an existing installation. Although their business model is dependent on software from the OSS project, the need to interact with the project is reduced because of the manner in which the software is deployed. Typically the interaction consists of reporting issues or asking questions on the user mailing list. However, as some interviewees explained, there are occasions where they develop software for the OSS project to support their particular use case and contribute that code back to the project, if appropriate.
The mechanisms available for businesses to contribute to an OSS project obviously influence the types of contributions that can be made. Analysis of the data collected from interviews also reveals constraints and opportunities within both businesses and OSS projects that shape contribution strategies. The value of participation in project governance to their employers, and in particular the enhancement of company reputation through active involvement in project governance, was a strong influence for some interviewees. One interviewee, however, provided note of caution through a critique of company involvement in foundations and project steering committees, arguing that tensions within larger companies around budgets and company aims often mean that company commitment to projects does not always fully reflect the business's strategic interests.
Companies may also adopt strategies that support a nontechnical effort made by the project which brings business benefits to the contributor. The Bouncy Castle library, for example, is deployed in some operational contexts where software must be certified as meeting the Federal Information Processing Standards (FIPS). An interviewee described how the FIPS certification process is expensive and companies donate money to the Legion of the Bouncy Castle Inc. to contribute towards the payment of FIPS certification fees. Furthermore, other interviewees commented that financial contributions, or contributions in kind can be more relevant for the project or foundation in addition to technical contributions, in some circumstances, and can form part of a strategy to support the OSS projects the business uses. One example highlighted by interviewees is the contribution of money through foundation memberships to finance the computing infrastructure required for the development of OpenStack.
The location of expertise and knowledge within the business and the project also emerged, during analysis of interview data, as a factor influencing decisions about contributing to an OSS project. Constraints on a business in terms of expertise, knowledge or personnel required 7. For example, the approach used by Bosch Software Innovations GmbH is outlined as part of a talk at FOSDEM 2018 (https://fosdem. org/2018/schedule/event/eclipse iot/) to contribute can mean that sometimes it can be more cost effective to commission work through consultancy and software development companies already engaged with a project to fix bugs or develop software for the OSS project. Committers for the two ASF projects studied, for example, are mostly company developers paid to work on the project. Some businesses employing core developers sell services and support for software from the OSS project. One interviewee spoke of their employer having a support contract for much of the work with the upstream project, but added that they also undertake some smaller tasks in-house and submit bug fixes and feature requests as well. A slightly different model is found with Bouncy Castle and MariaDB Server where considerable domain expertise is often required to work with the source code. Both projects receive technical contributions from their respective communities, including larger companies. In addition, Crypto Workshop, a company run by the founders of Bouncy Castle, sells support subscriptions and undertakes commissioned work on the project source code. The MariaDB Corporation also undertakes commissioned work to develop additional functionality. Interviewees commented that acquiring the necessary expertise to create technical contributions can be prohibitively expensive, or cannot produce the timely solution required. Accordingly, paying for established expertise can be a cost effective means of contributing code to the project and gaining the required functionality.

Bug Reporting
The care taken and attention to detail by developers contributing bug reports was a theme identified during analysis of the interviews. An interviewee explained that bug reporting was often a slow and painstaking process. They highlighted the challenge of gathering information from different parts of the project documentation and systems such as issue trackers, as well as external sources including question and answer sites like Stack Overflow, to determine whether the observed problem had been seen previously, and potentially resolved. The same interviewee asserted that only then would they ask a question on the appropriate mailing list. Even at that stage, they explained, the question would employ the use of negative politeness in a formula such as ". . . or have I missed something?", so that the possibility of an error or oversight is allowed for to protect the reporter's community reputation.
Another interviewee emphasised the value of bug reports for improving project documentation. In their experience -both as a core developer and contributor -some bug reports arise because software behaviour found by users differs from the documentation. They also explained that where standards are implemented, bug reports can help identify and document cogent misinterpretations and misunderstandings of the standard.
As well as the desire expressed by bug reporters to report their observations clearly, interview analysis found that core developers also needed clear evidence in bug reports. Without clear evidence to help identify the underlying cause they found the process of determining the nature of the problem, and possible solutions to be considerably more challenging, To develop understanding of the problem and explain it clearly.
Tentative bug report To acknowledge potential knowledge gap between reporter and core.
To protect reputation in project community by allowing for error.

Feature Requests
Feature proposal To ensure relevance of proposed contribution.
To prevent unnecessary work by contributor.

Code review
To ensure suitability of contributed code.
To support and encourage new contributors.
To document project source code quality expectations.

Support
Help-seeking To identify a solution to a problem.
To indicate continuing use of feature under threat of deprecation.
To document a problem for client.

Help-giving
To encourage software use.
To identify bugs that might lie behind support requests.
To gain knowledge and develop skills to support customers.

Other Activities Documentation
To record project processes for fellow core developers.
Source code maintenance To ensure tasks that do not attract non-core developers are completed.

Governance
To provide a layer of project oversight. and often time-consuming. Some request specific forms of evidence are included in bug reports, but that it is not always supplied. One core developer interviewed, however, remained relatively optimistic: ". . . we have a template . . . please tell us which branch, please give us the logs. And it's frequently ignored. But, OK, if it's ignored and we can handle the issue in another way it's OK."

Feature Requests
Qualitative evaluation of the collected interview data found some developers are often motivated to submit feature requests to migrate already implemented features into the OSS project. Often the feature has been implemented and tested within the contributor's private version of the OSS project source code, and the feature would be easier to manage if it were incorporated in the upstream source code and released as part of the software from OSS project. One interviewee explained the challenging and expensive process of needing to integrate local code revisions into each release of the upstream project software to introduce functionality required before the company could deploy the software from the OSS project to customers. The effort required to maintain their own version of the upstream project's source code and make revisions to each release to integrate their own code introduced an unacceptable level of effort and cost for the business. By having their features incorporated into the upstream project, future revisions to the project would not break the code, and the company would not have the overhead of reintegrating code to each release. The interviewee observed that the process of having the feature accepted and integrated in the OSS project had taken a long time and had been achieved in a series of steps, rather than as a single feature request. They also emphasised the importance of the project to the business, saying: "We had to do some fairly awkward things . . . to continue being able to produce what we needed to produce and to make a saleable product." Depending on the project infrastructure, there are opportunities to negotiate with core developers and other users about proposed features to understand whether the proposed feature is likely to be accepted. Some interviewees commented that discussion of proposals of new or extended functionality was an effective process for scrutinising proposals and revising them to ensure the quality of the proposed contribution, and its acceptability to the rest of the community. Another interviewee added that working in relevant areas of the project source code that other contributors appeared not to be interested in increased the likelihood of features being accepted.
Part of the process of submitting a feature request is the code review work undertaken by the core developers prior to accepting and integrating the feature. In a large project such as OpenStack there is an extensive process of code review undertaken by developers from different contributing companies. A theme that emerged from the analysis of the collected interview data was the value of the review process as a means of preventing unwanted or undesirable changes, and supporting the longevity of the project. Interviewees also noted the need for vigilance dur-ing reviews to ensure that implementations were sufficiently generic so that the project remained useful to the wider user community and that new features were implemented for all supported platforms. Core developers also highlighted the value of a supportive and educational review process. In particular that the contributing developer should to be encouraged to continue contributing to support the longevity of the community and the software created by the project. Two core developers also commented that supportive code reviews can require additional effort and might seem an inefficient use of time. However, they both emphasised the value to the OSS project of investing time, with one saying: "Is it worth it? Personally, I feel that code contribution integration is often less efficient than if I coded it myself but this is normal as contributors need to gain skills on the project, this is a kind of investment. For the longevity of the project, it's important to have more people involved." An additional benefit of code reviews, explained by one interviewee, is that they document the core developers' expectations for source code quality, and, in their opinion, potentially, influence the quality of future contributions.
One interviewee also drew attention to the challenges of processing large feature requests, explaining that the larger a submitted feature was the more difficult it was to review. In practice they preferred submissions to consist of smaller features so that each could be better understood, tested in isolation, and integrated more easily. Non-core contributors with limited experience of OSS reported finding the practice a challenge at first.
Interviewees working as core developers also identified that some software has additional requirements that are not always apparent to contributors of code. Additional considerations can consequently make integration of contributions time-consuming and challenging. Examples given by interviewees include the security aspects of Bouncy Castle, Contiki-NG and MariaDB, and differences between the virtualisation models implemented on hardware platforms used for CloudStack and OpenStack installations.

Support
The definition of support activities used earlier includes both asking and answering questions as well as the provision of documentation, both for fellow contributors and end users.
Some subtleties of the process of asking for and providing help in forums and on mailing lists were illuminated by analysis of the interviews. Rather than simply asking for help, help requests can be considerably richer and have multiple intended audiences. One interviewee explained having used a mailing list question about a potential bug: ". . . to document to the project that there are people still using it [the functionality] and there are likely to be people using it for quite some time." Furthermore, the same interviewee reported using questions about potential bugs and possible solutions to document for their clients that the company was making progress towards resolving the issue.
Additional uses of mailing lists were identified through the qualitative analysis. Mailing lists are not just help forums, or places to make announcements, but can also be a practical means of disseminating information. One interviewee saw the provision of an email summarising decisions made in different communication channels as helpful for those involved in one particular area of development. Furthermore, they argued that while a variety of communication channels enhanced interaction in large projects, it also created problems for information management, particularly in the sense of curating knowledge of the project's evolution.
Analysis also found both help-givers and help-seekers value the learning process required to formulate and respond to mailing list questions. One help-seeker explained the value of preparing questions to their working life saying: ". . . part of the motivation is that I found it to be a useful way of fixing problems. So I probably write twice as many questions with the intention of posting them to a mailing list as I actually post." They then elaborated: ". . . by the time you have formulated a good question and collected all the information to say what the problem is then the process of asking the question will often make the answer become clear." A consultant explained the value of reading mailing lists and providing help as a way of acquiring knowledge and skills. As well as learning the soft skills required to help others, the interviewee identified an additional benefit to their professional practice as: ". . . learning about the problems that other people face so that when I run into similar problems with the consultancy work I can remember the problem."

Other Activities
We also found that core developers, in particular, but not exclusively, engaged in a wide range of activities, both technical and non-technical, to support the longevity of the project. An interviewee explained the value of documenting project processes, ". . . because then anyone else can take over parts of the process when someone leaves . . . " Three more interviewees highlighted, from their experience as core developers, the importance of undertaking basic software maintenance tasks and code quality improvement activities, such as fixing some bugs, refactoring code and identifying unused portions of source code for deletion. One commented about the motivation of contributors to maintain code: ". . . if there is a very well-known bug that somebody needs to sit and fix: for some people it's not part of the day-to-day job so they will not do it. . . . sometimes it means that we end up getting lots of nice cool new things, but there's that old thing [bug] back there that nobody is looking at." From the interview analysis we also identified motivations for other forms of contribution. Some, such as contributions to project governance, for example, depend on the opportunities provided by the project and foundation structure. Projects including Eclipse Foundation projects and OpenStack have steering committees that help determine the direction of software development. One interviewee emphasised the value of strong steering committees to projects in providing a layer of oversight. OpenStack is a very large project and has forms of internal organisation and structures that many other projects do not. For example there are a number of SIGs for cross-cutting, project-wide concerns, such as security. One OpenStack developer interviewed stressed participation in the SIGs as a valuable aspect of their work because they provide input into technical contributions in the form of trying to standardise development approaches across the project.

ANALYSIS
The combination of observations and analysis of project archives and rich insights and experiences of how experienced contributors work with community OSS projects provides rich accounts of work practices used, as well as explanations of why the observed approaches are used. In this section we elaborate on the variation in type, extent and intensity of interaction between company practitioners and OSS projects. We also identify how the nature of some contributions represent an investment in the project by the business, and analyse how costs and availability of resources can influence the way that businesses and practitioners contribute to community OSS projects.

Type, Extent and Intensity of Interaction
A wide variation in the extent and intensity of engagement between individual practitioners and companies, and the OSS projects was observed. Some practitioners spend a large proportion of their working time directly on a project while others interact with projects less often. The form and the intensity of the engagement with the OSS project appear to be largely related to how the business adds value to the project software. The software might be deployed as a component of a product or service that directly generates revenue, for example, or the business may add value by applying their expertise to deploy, and perhaps manage, solutions for customers that include the OSS project software.
An additional factor identified by interviewees was the critical nature of the OSS project software to the business model of the company they worked for. For some practitioners there was no viable alternative software solution. Their interactions with the project focused on the two objectives of delivering a viable product or technical solution now, despite difficult challenges, and working towards a more cost effective solution for the business in the future.
Where companies provide consultancy services to support deployment of the project software then their interactions with the OSS project may be infrequent and limited largely to help-seeking and bug reporting. The company's main requirement in such situation is reliable software for their customers to use and, perhaps, some additional knowledge of how to deploy the software. Companies that add value by incorporating the OSS in a product or service will have similar needs to those adding value through consultancy services, but also may need to add or improve functionality to support their work. It is notable, however, that many companies deploying OSS components in products and services do not engage with or contribute to some, if not most, of the OSS projects whose software they use. The first reason is that the component is perceived to be a commodity, or is used as if it were one. For example a specific version of a component may be deployed and only reliable, fully tested functionality is used. The second reason is that the component is replaceable.
Amongst the interviewees there was also variation in the intensity of engagement with the OSS project. Some contributors, especially in the cloud domain, spent a great deal of their time working on the project software either to improve the software or to add functionality required by products they were developing that built on the OSS project software. The reason for the intense or extensive engagement with the project seemed to be related to the domain, as the greatest intensity of activity was seen with contributors to CloudStack and OpenStack. A contributing factor reported by interviewees was the speed of product development within the domain, where, typically, development work was undertaken on a private fork of the project software, and then reintegrated with the upstream project.

Investment in Projects
Some interviewees, particularly core developers, identified strategic dimensions to their activities. They spoke of an additional investment of time and effort when reviewing and integrating contributed source code to encourage further contributions. Others identified software maintenance tasks such as refactoring that would not be done by non-core contributors. In some cases, where the project software is a major component of the employer's revenue stream, core developers also reported a larger part of the work they did was of direct benefit to the project, but of less immediate benefit to their employer. Work of this kind contributes to the quality of the software created by the project as well as making technical contributions easier by reducing technical debt. Similarly, activities, that may be non-technical, such as supporting the governance of the project contribute to the longevity of the project, and represent a longer term perspective of the project. That companies invest in the project rather than just contributing to the technical effort is indicative of the long-term importance of the project to the business.

Operational Costs
Engagement with a project is often seen as a long-term investment in staff time and expertise, which also consumes company resources that are typically considered a shortterm operational cost. Consequently, for both businesses and individual contributors it is desirable that interactions with OSS projects should be effective and efficient. We found interactions where developers proceed cautiously by, for example, trying to explore whether a specific feature might be accepted (Example 6) so as to avoid duplication of effort, or unnecessary work. However, we also found that contributors can be drawn into time-consuming interactions (e.g. Example 4). Example 4 and similar cases can have obvious causes, such as miscommunication or not following instructions, but in some instances the cause is less clear and further research is needed to understand the causes of inefficient interactions between contributors and project and how they might be avoided. If, as Milinkovich argues [43], OSS will be used increasingly, then without understanding the causes of inefficient interaction and how to avoid them, a lot of working time, and thus resources, may be used unnecessarily.
Several interviewees indicated the value of preparation of questions and bug reports using the project documentation, and external sources, as a way of ensuring that interactions within the project were more effective and efficient. One interviewee drew attention to the value to their employer of help-giving within a project as preparation for working with customers. Interviewees also identified the richness of some contributions that was not immediately apparent from observation as a means of trying to achieve additional goals. For example, an outwardly simple helprequest was used to try to influence software development plans within the project.
A further aspect of the costs encountered, and identified by interviewees, is that of technical debt, in the sense that maintaining local source code improvements, or bug fixes and reintegrating them at each release, is not an efficient or cost effective way of working. It is, however, as was identified in one case, a necessity where the upstream project is critical to the business model. In the long term a business reduces costs through enhancements to OSS project software being integrated in the project software; so long as they do not generate revenue through the addition of commercially differentiating functionality.
As well as the influence of deployment and the business model on the way that companies contribute to OSS projects, two additional factors appear to motivate the approaches to contribution by companies and those working with them, or on their behalf. The first is the maturity of the software implementation and the domain, and the second is the location of the knowledge and expertise required to complete a given task. In both cases care is needed to identify cost effective opportunities to make contributions.

Software and Domain Maturity
Projects where the software implementation is perceived as relatively immature and the core functionality under development, such as Leshan (where some parts of the OMA LWM2M specification remain to be implemented), can require greater investment of company resources in the project (in collaboration with competitors or not) to ensure the software meets the company's requirements. Opportunities for a company to work with the community include company developers joining the community, and the company employing core developers within the community. The latter is possible where the implementation aims of the company do not conflict substantially with those of the community. An example might be the development of software to implement an existing standard where the domain is thought to be relatively mature and clearly defined.
Software maturity is not easily evaluated and has many aspects. Consequently, determining the maturity of an OSS project requires recognition of aspects of the project, and whether they might be subject to change. The core functionality of Solr, for example, is perceived as relatively mature. However, machine learning techniques are relevant in the search domain and are being introduced to Solr. In addition, relative increase in the amount of data searched and consequent changes to the hardware platforms on which Solr is deployed in industry also influence the direction of software development. Consequently there can be implementation or reimplementation of features and functionality as software technology develops, and software and configuration changes in response to developments in external technology. Accordingly, though aspects of an OSS project may be considered mature and the direction of software development largely self-regulates, there are aspects of the project that may evolve as a consequence of external changes. Although the involvement of some companies using the software is mainly limited to contributing bug reports, vigilance is also required to ensure the project software continues to meet existing requirements.

Knowledge and Expertise
Interviewees also identified the location of knowledge and expertise as a significant factor when deciding to make a contribution to an OSS project, because it can indicate who may be best placed to contribute as well as the type of contribution that can be made. Three broad categories of knowledge emerged from analysis of OSS projects and the interview data: knowledge of the application domain, knowledge the software implementation, and knowledge of software deployment and use.
First, the application domain knowledge in the software is an asset that companies exploit to add value when delivering a service or a product. In some sectors, for example security, or during product innovation there can also be a significant level of domain knowledge within the company using the software. In the case of Bouncy Castle, for example, the application domain expertise and awareness of the community helps to identify new areas for development, as well as to report bugs clearly to the developers. Also, in projects associated with open innovation, like Leshan, expertise within companies that arises from product development supports the implementation of features, or missing functionality, in the upstream project.
Second, detailed knowledge of the software implementation is usually limited to the core developers within a project. Generally, it is possible to delegate responsibility for implementing bug fixes and feature requests to the upstream project. However, some deployment contexts can require timely implementation of fixes and features. Where the project software is deployed as part of a product, or delivers a critical service, it can be necessary for contributors to implement bug fixes to maintain revenue generation. A key challenge in such circumstances, therefore, is to acquire sufficient knowledge of the software implementation to be able to implement meaningful changes. Furthermore, there is a trade-off between implementing a bug fix that resolves the problem until it is fixed in the next release, and a solution that meets the requirements and development plans of the core developers sufficiently that the changes will be incorporated into the upstream project. Striking the right balance is a key challenge for a company, and, as identified through the analysis of interview data, there are many ways to acquire software implementation knowledge and expertise. Employees can acquire knowledge sufficient to implement fixes, though there may be limitations to the level of expertise that can be acquired alongside their dayto-day work. However, some core developers are willing to invest time to nurture contributors so that they are able to make more effective technical contributions. There is also the issue highlighted by some interviewees where the level of knowledge and expertise required to develop the software, in particular cases, can be such that it may be an unrealistic proposition for a contributor (individual or company) to acquire that expertise, especially where business resources are constrained. A further option, identified by some interviewees, is to hire expertise already within the upstream project in the form of core developers -either as consultants, or to invest in the project, if appropriate, and employ core developers as staff. Alternatively, companies may develop working relationships with businesses that employ core developers.
Third, deployment and use knowledge and expertise lies both with the user community and the core developers. Contributing knowledge to the project community makes the project more attractive to new users and contributors, and can contribute to the development of professional expertise of the help-giver. Documenting knowledge of deployment also helps improve the quality of the software by recording use cases and requirements that the core developers may not have considered.
To summarise: the challenge for any business contributing to an OSS project is to understand the wide range of factors that might motivate the contribution, as well as the factors that constrain avenues of action, and the need to identify appropriate means of interacting with the project that are an effective use of resources.

Discussion
In this article we have reported on how and why companies and practitioners acting on their behalf contribute to eight community OSS projects. Companies contribute to OSS projects for business reasons, and decisions about the nature of the contribution are influenced primarily by the need for the business to generate long-term value, i.e. for the business to benefit from the contribution. We found a wide variety of ways businesses contribute to projects and provided some explanations of the choices made from analysis of interviews with practitioners. Observations of practitioners' work practices and the interviews provide rich descriptions of the factors considered, including where expertise and knowledge lie, and how effectively the business might be able to contribute in order to achieve its goals. The goals may be short-term, such as fixing a bug, or more long-term, such as supporting a particular development effort, or perhaps even influencing the direction of software development.
A major influence on the type and level of engagement with an OSS project is the way in which the business deploys the software created by the project. In some deployment contexts the software requires little or no modification to create revenue for the company; the revenue comes from selling the expertise required to deploy the software. At the other end of the spectrum the software is deployed in a context where ongoing development of features is required to support the generation of revenue. In such usage contexts the software may be deployed to provide services to customers who have evolving requirements, or it may be that the software is in a rapidly evolving domain. However, it is important to remember that businesses participate in OSS projects for multiple reasons, and while there may be common factors for many companies contributing to a given project, they do not lead to the same form of contributions to the project. Contributions, and consequently the pace and direction of development, are the combination of the needs and capabilities of many companies.
The capability of a company to make a technical contribution to an OSS project is contingent on having the necessary technical and implementation knowledge and expertise, as well as other resources, including staff time to make the contribution. Companies need to be aware of their strengths and weaknesses when making decisions and to adopt a cautious approach when proposing additional features, for example. Furthermore, that if, for any reason, the company lacks the capacity to make a technical contribution, then there is the opportunity to outsource the work to others. An orthogonal factor that must be considered is the timeliness of any implementation; can the company afford to wait for the project to implement the change? The company may then need to acquire the necessary expertise.
The contributions made by interviewees were motivated, mostly, by the need to complete software development tasks for their employer. The majority of activity was intended to meet short-term goals, and driven by the need to deliver a product or service. Some activity was more strategic and intended by the commissioning business to support the community OSS project. We also identified instances where individuals spent part of their paid work making contributions to develop skills beneficial to the business. While many interviewees were motivated for career reasons to work in jobs where they could contribute to OSS projects, contributions were made in the context of paid employment, and for the benefit of the business.
Rather than simply contributing in ways that support the technical effort where there are direct benefits to the company's revenue, some companies contribute to the longer term future of the project. There appears to be a point at which the project becomes of sufficient importance for the business to support aspects of software development, through employing core developers, that contribute to the long-term future of the project in ways that do not have an apparent financial return for the company. Exactly what factors lead to the decision to invest in a community OSS project is a subject for future research.
We have identified a range of non-code contributions including donations, sponsorship, and participation in governance processes, and some motivations to make such contributions. Documentation, for example, is an activity that developers contribute to and that some individuals specialise in. Individuals contributing primarily to the documentation process did not respond to invitations for interview. The broad topic of non-technical contributions and particularly those who make only non-code contributions to community OSS projects is therefore an area for future research.
The study presented in this article presents systematic analyses of collected data from public sources and contributors to eight widely used community OSS projects implementing software in a variety of domains. We acknowl-edge the inherent characteristics of utilising a purposeful sampling for transferability of findings from the study. While we cannot reflect every possible form of business pressure on, and work practice used by, contributors to OSS projects in this study, we have provided results which draw from a systematic analysis of rich insights and experiences of activities related to the investigated community OSS projects, including drawing on the long experience of the authors. Consequently, we conjecture that the findings may be particularly representative for transferability of results related to company involvement with other community OSS projects.

CONCLUSIONS
We have reported on the interactions of companies with eight community open source software (OSS) projects governed independently and by foundations. The work practices used by companies to contribute to OSS projects are identified and characterised, and the motivations for the use of particular contribution strategies and work practices explored through analysis of data gathered during interviews with contributors.
Our investigation provides a picture of the inherent complexity for businesses working with OSS and illuminates the manner in which companies and practitioners contribute to OSS projects, despite the outward similarity of the project structures, available communication channels, and apparent business models and priorities of participants. We found key factors that help determine how a company interacts with a community OSS project include the maturity of the software created by the project, the business context within which the company deploys the software, and the balance of areas of knowledge and expertise between the company and the project. In addition, companies have a strong interest in the longevity and sustainability of projects they use and contribute to, that also motivates their activities and both technical and non-technical contributions, and can motivate a much more strategic investment of resources in the project.
This study makes the following contributions to the existing body of knowledge: • Identification of work practices used by companies and practitioners to contribute to eight widely used community OSS projects.
• Documentation of factors for both the community OSS project and contributors that influence company and practitioner decision-making.
• Documentation of insights from industrial praxis into the opportunities and constraints of the relationships between projects, companies and practitioners.
• Identification of opportunities for companies and practitioners to improve their strategies for working with community OSS projects.
In summary, this study contributes novel findings about the nature of, and the decision-making behind, strategic and everyday contributions by companies and practitioners to community OSS projects. The rich descriptions and analysis of the interviewed practitioners' insights and experiences provide an understanding of the nature of the complex interplay between influences from technical and business considerations that inform decisions made by businesses and individual practitioners about the work practices used to make contributions to independently governed OSS projects. The findings draw from investigations of company involvement with eight community OSS projects which to large extent may be transferable to other similar contexts involving other OSS projects. However, findings from the study should not be perceived as supporting a contextindependent prescribed method for contributing successfully to all other community OSS projects. Hence, findings from the study indicate the need for awareness and understanding by businesses and practitioners of the many characteristics of both their own situation and goals, and those of the OSS project, in order to be able to contribute effectively.
Erik Lönroth holds an MSc in Computer Science and is the Technical Responsible for the high performance computing area at Scania IT AB. He has been leading the technical development of four generations of super computing initiatives at Scania and their supporting subsystems. Erik frequently lectures on development of super computer environments for industry, open source software governance and HPC related topics.