{'fraction_non_alphanumeric': 0.03022258113359915, 'fraction_numerical': 0.010770706102054207, 'mean_word_length': 5.069848661233993, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 1, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 6, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
What to share, when, and where: balancing the objectives and complexities of open source software contributions

Context: Software-intensive organizations' rationale for sharing Open Source Software (OSS) may be driven by both idealistic, strategic and commercial objectives, and include both monetary as well as non-monetary benefits. To gain the potential benefits, an organization may need to consider what they share and how, while taking into account risks, costs and other complexities. Objective: This study aims to empirically investigate objectives and complexities organizations need to consider and balance between when deciding on what software to share as OSS, when to share it, and whether to create a new or contribute to an existing community. Method: A multiple-case study of three case organizations was conducted in two research cycles, with data gathered from interviews with 20 practitioners from these organizations. The data was analyzed qualitatively in an inductive and iterative coding process. Results: 12 contribution objectives and 15 contribution complexities were found. Objectives include opportunities for improving reputation, managing suppliers, managing partners and competitors, and exploiting externally available knowledge and resources. Complexities include risk of loosing control, risk of giving away competitive advantage, risk of creating negative exposure, costs of contributing, and the possibility and need to contribute to an existing or new community. Conclusions: Cross-case analysis and interview validation show that the identified objectives and complexities offer organizations a possibility to reflect on and adapt their contribution strategies based on their specific contexts and business goals.

Keywords Open Source Software · Software Product Management · Requirements Engineering · Contribution Strategy · Community Strategy

Introduction
Sharing, or contributing, software artifacts (e.g., features, projects, and frameworks) as Open Source Software (OSS) is a common practice among softwareintensive organizations today [50]. By "opening up" [9], an organization can exploit the external workforce residing in the OSS communities that develops and maintains the OSS. Improved product innovation, accelerated development, lower maintenance cost, as well as improved branding and reputation, are some of the potential benefits that may motivate [23,42,48,50,66]. The motive may also be driven by pure idealism and being a good OSS citizen [30]. For some organizations, OSS may have a more direct connection to the business model or strategy, e.g., as a basis for complementary products and services [3,62,64], or as a means to create a new standard or compete with existing ones [23,30,42,72]. Objectives for why an organization would choose to contribute software artifacts as OSS does, however, not have to be limited to one or the other [3].
In this paper, we present the results from an empirical study on organizations' rationale for sharing software artifacts as open source. In the context of this study, we introduce the term Contribution Objective (CO), which we define as a purpose for contributing a software artifact, motivated by a monetary or non-monetary benefit that is enabled or resulted directly or indirectly as a consequence of the contribution.
To gain potential benefits by acting in line with contribution objectives, an organization needs to access the external workforce, either by contributing its software artifacts to an existing OSS community or by creating a new community, each with its respective costs and risks [11]. In either case, the organization then needs to work actively to align its internal strategy with the community where they are a stakeholder among many, potentially including competitors with conflicting agendas [10,12]. An organization, therefore, may have to consider not just where, but also what it contributes, and when. Risks include giving away differentiating functionality [23,24,29,68,74,78], or contributing too late and having to choose between adopting the alternative solution or maintaining an internal solution alone [38,78]. Hence, there are several potential costs and risks tied to a contribution.
In the context of this study, we refer to these potential costs and risks as Contribution Complexities (CCs) and define them as aspects related to a software artifact that may complicate the contribution of the artifact, or imply a cost or risk as a result thereof, either directly or indirectly. As with contribution objectives, not all complexities may be relevant for all organizations [38].
By not considering relevant contribution objectives or complexities, an organization may risk making a contribution that could be damaging, or inadvertently block a contribution that could have been beneficial for the orga-nization and its business goals [78]. To gain the expected benefits, organizations therefore need to link their business goals with their decisions on what they contribute as OSS. Despite the problematic context, research on how organizations can develop and use such strategies is limited [50], with some exceptions [38,71,78]. This leads us to define the following research questions: RQ1 What contribution objectives should a software-intensive organization consider when assessing if, where and when a software artifact should be shared as OSS?
RQ2 What contribution complexities should a software-intensive organization consider when assessing if, where and when a software artifact should be shared as OSS?
We addressed these research questions by conducting a multiple-case study at three software-intensive organizations with an iterative approach spanning over two research cycles. Based on an inductive coding of twenty semistructured interviews divided among the three organizations, 12 contribution objectives and 15 contribution complexities were identified.
An organization may, based on the contribution objectives and complexities that they find relevant for their context and business goals, make informed decisions on what software artifacts that should be released as OSS, when and where. For a specific artifact, the question "what? " regards if the artifact should be contributed in full or kept closed, or if certain parts can be contributed under certain conditions. The question "when? " refers to when in time an artifact should be contributed. Finally, the question "where? " asks whether the artifact should be contributed to one of many existing OSS communities or if a new community should be established. Answers to these questions are input to a contribution strategy for the software artifact under consideration. The overall objective of the work presented in this paper is to elicit such answers from real-world example cases, and start building a relevant list of considerations that can help when developing a contribution strategy.
The rest of this paper is structured as follows. Sections 2 presents related and previous work to this study. Section 3 presents the research design and background information to the three case organizations. Section 4 presents the identified contribution objectives and complexities, and section 5 provides a discussion on the objectives and complexities in regards to related work. Section 6 presents a discussion on threats to validity, while section 7 concludes the paper. Appendices A-D provide detailed information about interview instruments and findings.

Related and Previous Work
This section provides an overview of related work to the two concepts of Contribution Objectives and Contribution Complexities. This is followed by an overview of contribution strategy research after which we present a summary of the related and previous work.

Benefits of Sharing Software as OSS
Several studies have systematically surveyed the literature and to different extents covered the benefits for why software should be shared as OSS [22,28,50,62]. We categorize the benefits into four different themes.
A common theme is the cost-saving aspects [3,49,50]. By extending the resource-base [11] and agreeing on a common standard [74], organizations can share the maintenance and quality assurance, accelerate the development and potentially decrease their time-to-release and market [23,27,42,44,48,66]. By freeing up internal resources, they can focus on more value-adding activities [42,48,68]. On the opposite, by adopting a less symbiotic relationship to the OSS community [10], an organization will have to maintain an internal branch of the OSS project, which may become costly depending on the number of modifications that need to be applied to new releases of the OSS project [69,78]. Hence, to attain these potential benefits, active engagement and a symbiotic relationship may be needed with the OSS community [7,12].
Another common theme is the innovation aspects [3,50], which can be both product and process-oriented [49]. By opening up the innovation process [8] and "pooling" the R&D/product development [74], organizations get access to an external workforce [43], which may bring increased knowledge sharing [44,51] and innovation at a lower cost [66,80]. However, this external workforce should be seen as a complement rather than a substitute for internal knowledge and development [11,65]. Munir et al. [50] describe it as a catalyst for ideas that may help organizations in broadening their offerings. Hence, an organization may question how much of its internal R&D and innovation process it should outsource to a community [1].
A third theme can be tied to improved reputation [50,69]. By creating a community or contributing to an existing community, an organization can create a marketing channel both towards (potential) customers, as well as future employees and have a positive effect on internal developers' satisfaction [11,23,43,55,66]. The improved reputation can turn into a competitive advantage [25] and legitimize the use of the OSS from a public perspective [12]. An organization's customers are offered an opportunity to avoid vendor-lockin, and the ability to customize the software to internal needs [44,48].
A fourth theme concerns control aspects [38]. If an OSS community has a meritocratic coordination process in place [63], influence on the development direction of the community may be gained by participating in the development and maintaining a symbiotic relationship [5,10,12,39,53,60,67]. This may help steer the community including competitors and to manage potentially conflicting agendas [39,45,50,60,76].
Influence may also come implicitly when an organization's project or a feature is released and accepted as a standard solution, either within an existing community or as a new community [48]. If contributed to an existing community, other organizations will either have to accept and adapt, maintain internal forks of their solutions, or attempt to contribute their solutions in competition with the solution already established within a community [38].
If released as a new community and traction is gained, it can potentially become a new standard or compete with existing [23,30,42,72], and create a surrounding ecosystem with complements from other organizations [20,73].
Some of these themes may be more or less important depending on the type of organization. Munir et al. [49] present a theory of openness that categorizes organizations using OSS in their tools and infrastructure setups based on why and when they adopt and share software as OSS. The "why" is either focused on reducing product development costs or building a symbiotic relationship with the OSS communities [10]. The "when" concerns whether a reactive or proactive strategy is adopted. In the former, an organization adapts to existing and upcoming OSS communities without taking any initiatives. In the latter, an organization has a long-term agenda and adapts its OSS community engagements or create new communities accordingly.

Costs and Risks of Sharing Software as OSS
Deciding what should be contributed is a complex matter [50]. Even though the amount of a software that may be considered differentiating is often limited [42,68], the risk of sharing differentiating functionality and sensitive Intellectual Property Rights (IPR), and as a consequence losing a competitive edge, is a recognized challenge in literature (e.g., [23,24,29,68,74,78]). Instead of disqualifying a complete software artifact however, one approach may be to selectively reveal commodity or enabling parts while keeping differentiating parts closed [23,66,72]. An alternative approach may be to "spinout" [74] disclose the software artifact under a restrictive copy-left license [72], e.g., the General Public Licence version 2 and 3, or the Affero GPL 1 . This is a common approach for commercial OSS organizations [56] using a dual-license approach to appropriate and capture value from customers [8]. Combinations can be found, e.g., where a core OSS project is permissively licensed, while certain extensions or improvements are licensed with more restrictive licenses [14], or kept proprietary [71].
A related challenge is determining when software should be contributed [78]. Several studies have attempted to model and identify an optimal timing [6,21,35]. Caulkins et al. [6] for example, identify costs related to the development and adapting the business model, along with the software quality as factors affecting when software should be released as OSS. Quality is in this case not just referred to the number of errors, but to the software's features and functionality. The shift in how quality changes can be compared to where in the commoditization process a software artifact is. I.e., the "software artifact's value depreciation and how it moves between a differential to a commodity state, i.e., to what extent the artifact is considered to help distinguish the focal organization's product offering relative to its competitors" [38]. As suggested by van der Linden et al. [68], a first step may be to open up the software in joint ventures or closed strategic alliances [38], while a third step may be to release it as OSS. Wnuk et al. [78] describe the challenge as a balance between losing a competitive edge and increased maintenance costs.
Where to contribute is a third challenge. When contributing the software artifact to an existing OSS community not governed by the organization itself [54], the organization needs to consider the requirements engineering process of the community [59]. In this context, the organization is a stakeholder among many and needs to consider potentially conflicting agendas from other stakeholders [40,45,50,60]. If there is a misalignment between the organization's and the community's Requirements Engineering (RE) process [2,16,36], the organization may need to influence the development direction of the community [48]. If the organization lacks the influence needed, they need to consider the cost of gaining it [39]. An option is to release the software as an independent OSS project and build a new community around it, which may require significant investment as well [11,33,75].

Contribution Strategies
Wnut et al. [78] highlighted the importance of contribution strategies early on. Research on the topic has however been limited [50] with some exceptions [38,71,78].
In previous work [38], the first author of this study conducted a case study on the contribution strategy decision process at Sony Mobile. Through the case study, a Contribution Acceptance Process (CAP) model was designed with the purpose to help organizations decide if a software artifact should be shared as OSS. A software artifact (e.g., features or projects) is valued according to its business impact (how much you profit from the component) and control complexity (how hard the technology and knowledge behind the artifact is to acquire and control). With the help of a series of questions provided, the software artifact could be ranked qualitatively and placed in a two-by-two matrix (see Fig. 2.3), with each cell representing a certain type of generic artifact with its own contribution strategy that is proposed for the artifact.
As an example, one of the four artifact types concerned strategic artifacts (upper right quadrant in Fig. 2.3) [38]. These artifacts have a high business impact and a high control complexity. They contain differentiating value and provides a competitive edge to the organization. Differentiating parts should be kept closed while enabling parts, should be contributed. The contribution is recommended to be made to a community where the organization has a high level of influence. If not possible, a new community may be created.
The contribution strategy could then be fine-tuned based on a series of objectives [38]. The more strategic an artifact is (higher business impact and control complexity) the faster the artifact (or enabling parts of it) should be contributed to establishing the artifact as the standard solution. The organization could thereby avoid having to adapt to competing solutions and instead strive towards steering its competitors. For this reason, these kinds of arti- Fig. 1 The Contribution Acceptance Process (CAP) model as presented in Linåker et al. [38]. Based on how a software artifact is valued in regards to its business impact and control complexity, a contribution strategy is elicited pending the artifact's placement on the grid. facts should be prioritized before standard artifacts, which may be considered as standard knowledge.
An example of a strategic artifact included a multimedia framework that enabled differentiating camera functionality [38]. The framework was contributed, while the camera functionality could be kept closed. This gave Sony Mobile the advantage of not having to refactor or adapt to competing frameworks and still keep differentiating functionality closed.
The CAP model can be used both in a proactive and reactive approach [38]. In the proactive, it is used to map a series of software artifacts, e.g., features in the product planning process [34]. A cross-functional team may be assembled, including e.g., representatives from marketing, legal and product development. The team can iterate the mapping process comparing features against each other through consensus-seeking discussions. In the reactive approach, the CAP model is used in a similar manner but for making decisions in regard to incoming contribution requests from the organization's development teams.
The validation of the CAP model showed that the CAP model provided a good foundation for discussion. Feedback pointed out that the questions and scale used to value a software artifact in terms of business impact and control complexity, was found useful but in need of being tailored to the context where the CAP model is applied. A highlighted concern for future work was to avoid making the following versions of the CAP model more complex.
A contribution process starts with an individual filing a contribution request, requesting to be allowed to contribute a certain software artifact to a certain community or create a new community. The request is then managed by an entity within the organization that has the mandate to decide on a contribution strategy.
In the case of Sony Mobile [38,46,48], an individual from the development organization fills in a contribution request answering a set of pre-defined questions. One of these questions concerns the size and complexity of the contribution [38].
-Trivial contributions include small changes such as bug fixes and minor improvements to existing OSS communities. -Medium contributions include new features and larger architectural changes to existing communities. -Major contributions include projects where a new community is to be established or software artifacts containing important IPR such as patents.
Trivial contribution requests are decided on by the closest manager, while medium and major contribution requests are processed by an Open Source Governance board [38]. The board has a cross-functional constellation with competencies covering aspects such as legal, user experience, product development, and product ownership [48]. Each medium and major contribution request is investigated further, which includes an IPR review rendering in a decision from the board on a relevant contribution strategy [38]. To ease bureaucracy, the board can develop general contribution strategies for specific communities allowing developers to, e.g., contribute minor and medium contributions to an OSS community without having to submit a request. This approach was applied to OSS communities where the OSS project was considered not providing a competitive edge to Sony Mobile, e.g, the two developmenttools Jenkins and Gerrit [48].
Creating awareness and maintaining the contribution process can be a challenge in large organizations [78]. In Sony Mobile, the contribution process and Open Source Governance board are led and supervised by the Open Source Program Officer, a role that connects management, legal, IPR and software development functions around Sony Mobile's OSS operations [46]. Similar organizational and process setups have been reported on in the documents and guidelines published by the TODO-group 2 , a foundation for organizations that has an established Open Source Programs Office. The program's office can be viewed as an organizational entity including the Open Source Program Officer and any further roles tied to an organization's OSS operations, e.g., concerning compliance and community management. In his more compliance-focused overview of OSS governance within an organization, Kemp [32] proposes the creation of an "OSS working party" and an "OSS compliance officer", which to some extent can be compared to an Open Source Programs Office and an Open Source Program Officer.

Summary
The benefits that may incentivize an organization to contribute its software as OSS are many [22,28,50,62], as are the potential costs and risks that may remove or outweigh the benefits [41,50]. To gain the expected benefits, an organization, therefore, needs to consider the contribution objectives and complexities relevant to their context, and make an informed decision on what they contribute, where, and when, in alignment with their business goals. Related work on how organizations can develop such strategies is limited [50], with some exceptions [71,78], including our previous work with Sony Mobile and the CAP-model [38]. The validation of the CAP-model pointed to a need for more general and less complex approaches for creating contribution strategies. This study, therefore, aims to identify and define a set of contribution objectives and complexities from which organizations can choose those relevant and thereby create contribution strategies based on their specific contexts and business goals.

Research Design
To answer the research questions RQ1 and RQ2 as defined in section 1, we employed a multiple-case study [58] in an iterative approach with two research cycles. The method offers a way for generating in-depth knowledge and understanding of a phenomena in how and why it occurs [15]. In our study, this regards an exploratory investigation of what Contribution Objectives (COs) and Contribution Complexities (CCs) that the case organizations consider in decisions on whether a software artifact should be released as OSS, when in time, and if it should be contributed to an existing community or if a new community should be created. Answers to these questions together form the contribution strategy for the software artifact. The decision of arriving at such strategies makes up our unit of analysis [58].
In total three case organizations were studied, one in the first research cycle and two in the second. Through this approach, we could develop the first set of contribution objectives and complexities which could then be used as a foundation when entering the second research cycle. Below we first describe the case organizations. We then describe how the research was carried out through the two research cycles.

Case Organizations
Below we describe and provide context to each of the three case organizations studied, denoted CaseOrg1-3. Per organization, we present a general description, along with a more in-depth overview of their contribution process as well as examples of OSS projects, which they have released, or are active contributors to.

CaseOrg1
General description: CaseOrg1 is a US-based media and technology company providing video, high-speed internet, smart home and voice services. They have 1000+ employees and develop their own software to enable and deliver their services to the customers. Having been passive consumers of OSS before 2006, they became active contributors starting in 2006. Since then, they have released several OSS projects and are active contributors in several others, as well as members of a number of OSS foundations.
Contribution process: Internally, they have an Open Source Programs Office set up to develop and manage e.g., contribution and compliance processes, and community management. Their contribution process starts with a developer filling out a contribution request form concerning a software artifact (e.g., feature or project). If the artifact regards a smaller contribution (e.g., a bug fix, or documentation), or a contribution to an OSS community deemed generally as non-competitive, approval can be gained online by the manager and the Open Source program office. For more significant components, the contribution request is managed by an OSS advisory board, which has representatives from legal, IPR, development and business functions within the organization. The board then gives a final decision on how to proceed. Case-Org2 also has what they refer to as sandbox approval, which allows a project and identified contributors to be approved to contribute to a project without coming back for each patch. This governance set-up and contribution process is similar to that of Sony Mobile [38].
Example OSS projects: One example concerns an internally developed Linux distribution that is embedded in hardware devices shipped to customers, which enables the delivery of CaseOrg1's consumer-oriented services. The software was initially developed to replace a proprietary option and was later released as OSS under the governance of an industry consortium. Another example concerns an infrastructure project, which enables the delivery of services related to secure and reliant internet-traffic to business-oriented customers. The project was released under the governance of a neutral community with an existing OSS foundation. A third example regards a DNS-as-a-Service project originally developed to increase internal operational efficiency. The decision process is thoroughly reported on in previous work [38].

CaseOrg2
General description: CaseOrg2 is a European-based hardware electronics manufacturer serving both business and private customers. They have 1000+ employees and develop their own software and orchestrate a software ecosystem [31] to enable and deliver their services to the customers. This study has focused on its Tools department which develops and maintains development tools and infrastructure projects used by the organization's product development teams. A majority of the tools and infrastructure projects are OSS-based with active engagement from the Tools department in their respective com-munities. The active engagement includes continuous contributions of features and plugins to existing OSS communities as well as the release of new OSS projects.
Contribution process: CaseOrg2 does not have a dedicated Open Source Programs Office. The organization has two contribution processes set up, one for their product development teams, and one for the Tools department. The latter is less strict than the former as CaseOrg2 generally considers the projects developed within the Tools department to provide a limited competitive edge to the organization. The contribution process used within the Tools department is initialized by a developer filling out a contribution request form concerning a software artifact (e.g., feature or project). If the contribution request is intended for an existing community, the request is managed by the department manager. If the contribution request concerns the creation of a new OSS community, the request is managed by the business unit manager. If deemed necessary the concerned manager will consult relevant functions within the organization such as Legal and IPR departments.
Example OSS projects: The Tools department has contributed and maintains several plugins to the Jenkins 3 and Gerrit 4 OSS projects. Jenkins is a build-server and Gerrit is a code-review tool, both used in CaseOrg2's continuous integration tool-chain. The Tools department has recently also started to create new OSS projects that fall outside existing communities. One such project was developed internally to allow for the creation and use of shorter URLs to internal resources. These are maintained as standalone projects on CaseOrg2's Github 5 page.

CaseOrg3
General description: The Swedish Public Employment Service 6 makes up the third case organization. They are non-anonymous but are referenced to as CaseOrg3 for consistency. CaseOrg3 is a public sector agency in Sweden with the main goal to facilitate and enable matching between job-seekers and employers on the Swedish labor market. The organization has 10 000+ employees of which 600 are employed within their IT division. The focus of this study is on a department within the IT division which aims to create a platform 7 on which private actors can build complementary products and services for matching job-seekers and employers. The platform, consisting of OSS projects and Open Data sources, is intended to help CaseOrg3 to move from the role of being a service provider to become a service enabler and help the platform's ecosystem members to collaborate and co-create, potentially resulting in accelerated innovation and a more efficient job-matching on the Swedish labor market.
Contribution process: CaseOrg3 does not have a dedicated Open Source Programs Office or contribution process in place. The studied department prioritize the release of internal projects based on what they believe is of most value to the platform's ecosystem of private actors.
Example OSS projects: The studied department has released a number of OSS projects consisting of small components that can integrate into existing applications, stand-alone end-user applications, and developer-focused tools and utilities 8 . One project is a video-conference-tool used internally at CaseOrg3 to facilitate remote interviews for employers and job-seekers. Another example concerns a search engine that can be used to access and search among job listings in CaseOrg3's Open Data sources with job ads.

Research Cycle 1
In the first research cycle, we investigated the problem context through a first case study of CaseOrg1. Data was gathered through six semi-structured interviews with employees from different areas of the organization, see Table 1. A questionnaire (see Appendix A) was created based on findings from an earlier reported case study of the contribution strategy decision process at Sony Mobile [38] conducted by the authors of this study.
Interviewees were selected in order to gain different and complementary perspectives on CaseOrg1's contribution strategy decision process. Each of the 8 https://jobtechdev.se/doc/samples/ interviews was audio-recorded and transcribed. An anonymized interview summary was presented to I1 and I2 to verify interpretations and clarify any misunderstanding. The transcripts were then coded with an inductive approach and audit trails maintained [58]. Using an iterative and refining coding process [57,58], sentences and paragraphs from the interviews were given descriptive topic sentences which then merged together in common codes and sorted under the two categories contribution objectives and complexities, mapping to RQ1 and RQ2 respectively. This rendered in a first set with a total of 16 objectives and 12 complexities (see table 3). Below we provide an example coding from CaseOrg1, which later was conceptualized as Contribution Objective CO3 after the updated coding from the second research cycle: -Code: Developer satisfaction -Quote by I5: ". . . I think a real reason goes to staffing engagements and retention. It is important to people and I think a positive employment characterization that you get to engage with open source communities and that the company does release something as open source projects. I think that's a big selling point that people are looking for in whom they want to work for as an engineer.".

Research Cycle 2
In the second research cycle, our goal was to validate the contribution objectives and complexities identified in the previous cycle while continuing to explore the problem context and identify new ones. The interview questionnaire was therefore updated based on previous findings. To validate the questionnaire and gain further input into its revision, we studied contribution request forms collected from seven different software-intensive organizations (see Ta-  The revised questionnaire (see Appendix B) was then used in semi-structured interviews with five employees from CaseOrg2 and nine employees from Case-Org3. As in the former cycle, interviewees were selected in order to gain different and complementary perspectives on two organizations' contribution strategy decision process. All interviews were audio-recorded and transcribed. Anonymized interview summaries were presented to I7 and I8 from CaseOrg2 and I15 from CaseOrg3.
Using the coding schema from the first cycle, transcripts from CaseOrg2 were first coded, which resulted in three new COs and one CC being added. In the following step, the new coding schema covering CaseOrg1-2 was applied to transcripts from CaseOrg3, resulting in one new CO being added, six COs merged into three. Three new CCs were added, of which two were former COs. Transcripts from all case organizations were then reiterated, and a final coding scheme assembled. This resulted in two COs being merged into one, two COs converted to CCs, and six CCs being merged into three. In table 3, the evolution, and saturation of the COs and CCs throughout the coding process are presented. Table 3 Evolution and saturation of COs and CCs throughout the coding process consisting of four steps. The first coding schema was based on transcripts from CaseOrg1. This was then applied and revised based on transcripts from CaseOrg2, and then CaseOrg3. The coding schema was then reiterated, resulting in the final set of COs and CCs. Below we present a continuation of the example code Developer satisfaction provided in Section 3.2. After coding the transcripts from CaseOrg2-3, further support was identified for Developer satisfaction. This code was then consolidated with the new code Hire talent, which was also identified in transcripts from CaseOrg1 in the reiteration, finally rendering in contribution objective CO3.

CaseOrg1 2. CaseOrg2 3. CaseOrg3 4. Final coding
-Contribution Objective CO3: Improve employer branding -Code: Developer satisfaction • Quote by I5: ". . . I think a real reason goes to staffing engagements and retention. It is important to people and I think a positive employment characterization that you get to engage with open source communities and that the company does release something as open source projects. I think that's a big selling point that people are looking for in whom they want to work for as an engineer.". • Quote by I19: "We think it is fun and it is positive for our personal satisfaction to contribute back". -Code: Hire talent • Quote by I8: "And then as a result of that, we already see it in some areas, because of our involvement in open standards or open source communities, we're able to attract a different type of engineer, or a different higher level engineer or value-add that they can bring to the company as a result of our openness and engagement. And so it's sort of a natural reinforcing cycle.". • Quote by I7: "Show that we are a modern firm with a presence in open source and that we contribute and not just consume, which attracts a lot of great developers and becomes a channel for us to attract new employees.".
The revised set of COs and CCs were presented and discussed with I1 from CaseOrg1, I7 and I8 from CaseOrg2 and I15 from CaseOrg3. All interviews were audio-recorded and transcribed. The interviewees were first asked about the correctness of the COs and CCs that had been mapped to their organization. Interviewees were then asked if any COs or CCs not mapped to them were found relevant for the organization. Lastly, the interviewees were asked about the general completeness, applicability, and usability of the set of COs and CCs, and whether something was redundant, missing, or could potentially be modified. Existing COs and CCs were then refined based on interview findings, while none were added nor removed.

Results
In this section, we summarize the identified contribution considerations, grouped into Contribution Objectives (COs) and Contribution Complexities (CCs), which an organization may analyze and weigh against each other when deciding on a contribution strategy for a certain software artifact. In total, we present 12 COs and 15 CCs divided over four and five categories respectively (see Fig. 2).
All contribution considerations are maybe not relevant to all organizations and all software artifacts. To help guide decision-makers and those making contribution requests, the presented contribution considerations can help as input when forming an organization-specific contribution strategy. COs and CCs can then be described in the context of the focal organization and relevant questions asked in a contribution request form when setting up a contribution process within the organization. An individual intending to file a request is then enabled to beforehand understand the rationale used by the decisionmakers when deciding on a contribution strategy, and thereby to provide motivated arguments why the request should be accepted. For further discussion, see Section 5. The COs are presented, each with a number of (potential) key benefits, in Table 4, while the CCs are presented, each with a number of key concerns, in Table 5 and are further explained below. A detailed description of each consideration, together with example quotes from interviews, are given in Appendices C and D.

Contribution Objectives
In total, 12 COs were identified in the analysis process divided over four categories: reputation-centric objectives, supplier-centric objectives, strategycentric objectives, and engineering-centric objectives. Below an overview is given to the COs in each category. A more detailed overview is presented in Appendix C where the COs are described separately with examples per identified benefit. Quotes from interviewees of the case organizations are given in Appendix C to provide context for each of the examples.

Reputation-centric Objectives
The reputation-centric objectives highlight the value in creating and maintaining a good reputation towards different stakeholders, including customers, partners, community, as well as existing and potential employees. By contributing to a specific community, an organization can improve the trust of customers and partners. The organization can demonstrate relevant technical knowledge about the OSS, and gain the influence needed in order to steer the development in a way that aligns with expectations and wishes from the customers and partners. Both retention and attraction of new customers and partners are further mentioned as potential results (CO1).
Increasing transparency is an aligning objective (CO2) in order to build trust among customers, or even the public. Being transparent about how the Reported examples include the ability to build a public CV, having an impact and collaborating with people outside the organization. Idealistic satisfaction of "doing the right thing" by contributing back and not just consuming OSS is also viewed as an important aspect among an organization's employees (CO4).

Supplier-centric
Supplier-centric objectives focus on how an OSS software artifact can be leveraged to better extract value from supplier-relations. For example, releasing projects as OSS can be a way to put price pressure on those providing corresponding products, as well as a means of inviting more potential suppliers to bid on tenders and thereby make the price more competitive (CO5). However, price pressure does not have to be the main incentive in terms of suppliers. By making a project available as OSS it becomes possible for cloud providers to run and maintain the project at scale and thereby lower the cost, while enabling internal resources to focus on more value-adding activities (CO6).

Strategy-centric Objectives
The strategy-centric objectives consider contributions that can have a larger impact on the organization's ability to stay competitive in the business environment where it operates [13]. Releasing a software artifact as OSS may, for example, enable generation and collection of data that can be used to improve machine learning and artificial intelligence algorithms, while also enabling the potential development of new products or services based on the data (CO7).
A more control-focused objective (CO8) concerns the creation of a standard solution, either within an industry or within a specific community. If a solution gains traction and acceptance, it could provide a first-mover advantage as other actors would have to adapt. It may also provide the organization with some level of influence on the development of the artifact, with the potential to steer the direction of either a community or industry.
A related and potentially overlapping objective (CO9) may be to create a software ecosystem [31] with the rationale of attracting and enabling third-party developers to create complementary products and services, and potentially also contribute to the platform constituted by the OSS project released by the platform provider. For example, releasing tools and infrastructure projects related to the platform, could further help to improve collaboration with partners and third-party developers, and thereby help increase the value of the software ecosystem (CO10).

Engineering-centric Objectives
The engineering-centric objectives concerns contributions where the rationale is to explicitly exploit the knowledge and resources of a community to one's advantage. One such objective (CO11) is to open up the innovation process by using the concerned community as a source of e.g., new and innovative requirements and feature implementations. An overlapping objective (CO12) is to use the development resources of the community as a force multiplier in order to share maintenance and quality assurance, while also accelerating development and enabling a value-adding focus for engineers internally of the organization.

Contribution Complexities
In total, 15 CCs were identified in the analysis process divided over five categories: control-centric complexities, IPR-centric complexities, exposure-centric complexities, cost-centric complexities, and community-centric complexities. Below, an overview is given to the CCs in each category. A more detailed overview is presented in Appendix D where the CCs are described separately with examples per identified concern, along with identified mitigation strategies for managing the complexities. Quotes from interviewees of the case organizations are given in Appendix D to provide context for each of the examples.

Control-centric Complexities
Control-centric complexities highlight the risk of the development of the software artifact (if released as OSS) heading in another direction than expected by the focal organization and what impact this would have. This is a risk that may be expected as the stakeholder population in a community is heterogeneous with agendas that not always align [39]. Also if one wants to grow a community, the organization to some extent have to consider the wills and opinions of the community [37]. One complexity (CC1) considers the case when the artifact has a close relationship to the organization's value proposition, for example by enabling the organization to sell and deliver its products and services. Another complexity (CC2) considers the case where the artifact may have a more distant relationship to the value proposition but still being of importance in terms of internal operations. Examples highlight OSS projects integrated into the continuous integration tool-chain and used heavily by the product development departments. To address this complexity and the risk of deviating agendas in a community, and organisation can try to build influence in the concerned community through active engagement and contributions.

IPR-centric Complexities
Complexities centered around Intellectual Property Rights (IPR) considers what impact it would have on the focal organization's rights if the software artifact is released as OSS. One complexity (CC3) highlights the potential presence of differentiating functionality which could lead to a loss of competitive edge. A recommended practice is to separate between what is commodity and differentiating functionality, for example, through a modular architecture, and contribute underlying parts such as frameworks and libraries. Another complexity (CC4) considers the timing aspect of when the artifact should be released as OSS. It refers to the commoditization cycle where technology moves from an innovative and differentiating state to becoming commodity and general knowledge. One interviewee described it as a "a trade-off between a competitive edge and burdon" (I1) implying that by keeping it closed, an organization may guard what it considers differentiating, but as a consequence needs to maintain it by themselves, and at the same time risks that a competing solution gets released and adopted. It is, therefore, important to keep an awareness of potential alternative solutions. From a public sector perspective, the intention may be the opposite in terms of CC3-4, for example to enable companies to create value based on public assets. This may also help concerned organizations to shift focus from commodity to more value-adding development. However, a risk is that it may damage the business and be viewed as the agency is intending to compete on the market. It may therefore be good to inform concerned organizations in advance and provide them with an opportunity to adapt and enter a dialogue when needed.
Another complexity (CC5) highlights sensitive IPRs in general, which may include patents used in a defensive patent portfolio, as a source of license revenue, or patents belonging to third-party. Hence, a critical review process for the need of the patents and their origin may be motivated in order to weigh these aspects against the potential value that the artifact may produce, if released as OSS.
A frequent scenario reported is that engineers request to release an artifact as OSS when there is already an acceptable alternative available as OSS (CC6). Actively encouraging engineers to research available options is therefore recommended. Education is also seen as a key approach to managing the risk of violating license conditions as these may demand that certain artifacts are contributed or made available as OSS under a certain license (CC7).

Exposure-centric Complexities
Exposure-centric complexities highlight ways in how the software artifact may be used that could have a negative exposure of the organization. The artifact may, for example, be used in contexts or for certain purposes that may be considered unethical and not originally intended by the organization (CC8).
Another risk is that security vulnerabilities are identified before they are fixed which could be used to damage the focal organization and other users of the artifact when available as OSS (CC9). It may therefore be good to proactively investigate potential unethical use cases and perform security audits, before releasing any artifact as OSS.

Cost-centric Complexities
Constraints in terms of budget and available resources can be an issue as preparing an artifact to be contributed, pushing it through a contribution process, as well as potentially maintaining it once released as OSS has attached costs (CC11). In certain cases the technical feasibility of releasing the artifact may be questioned, as it may be too integrated into an organization's internal software stack, which in turn leads to that the cost may outweigh the potential benefits of releasing it as OSS (CC12). A mitigation can be to, early on, consider the potential of releasing the artifact as OSS and develop the artifact with that in mind, e.g., by using modular architecture and keeping code comments general.
When an artifact relates to an existing OSS project, there is an alternative cost of maintaining the artifact internally and a risk of growing a technical debt by not contributing (CC12). One way to minimize such costs and risks is to keep the internal fork as close as possible to the up-stream OSS project.

Community-centric Complexities
One risk is that the external interest is limited for a software artifact intended to be released as OSS (CC13). For existing communities, this would prevent it from being accepted. If creating a new community is considered, but none interested in joining, some of the expected benefits may be missed (e.g., shared maintenance costs). It may therefore be recommended to investigate whether there actually exists external interest, and if the use cases that the software artifact addresses are general enough.
Limited interest from a community may be due to misaligned agendas among its members (CC14). In these cases, it may be important for the focal organization to build up a level of influence through active engagement and contributions, in order to be able to contribute its artifacts.
When an organization is dependent on an OSS project and the community's health may be considered as a risk, it is important to contribute to that community (CC15). Hence, the level of health of the related community should be weighed against other complexities, when deciding if an artifact should be released as OSS.

Discussion
In this section we discuss the identified contribution considerations, in relation to literature, and with respect to the contexts they were observed.

Contribution Objectives
The expected benefits from sharing a software artifact as OSS is reflected by the identified COs and related key benefits (see Table 4). Objectives can be considered to cover both the idealistic, survival and commercial motivators highlighted by Jansen et al. [30]. Supportive findings can to a large extent also be found in literature if compared to Section 2.1. For example, the idealistically motivated objective CO4 -Be a good open source citizen, implying that an organization should respect and understand the needs, governance and culture of the community [1,5,10,12,52]. Further, the commercially motivated costsaving objectives implied by the extended development workforce (CO12), and related benefits, has also been observed in a number of other studies (e.g., [23,27,42,48,66,68]). Support was also found for the survival, or more strategically, motivated objectives such as CO9 -Build a software ecosystem [74,76]. Some objectives, however, were not reflected among the reviewed literature, e.g., CO5 -Create price pressure on third-party vendors and suppliers.
A challenge with the intangible [62], or non-monetary benefits [47] is that they may be less obvious and harder to measure and track in financial spreadsheets [47], compared to the tangible revenues and monetary benefits. In this study, an attempt is made by presenting key benefits to each objective. Future research could strive to identify and derive suitable and actionable metrics for the different types of benefits, or objectives 9 . With such metrics in place, contribution requests and strategies can potentially become easier to motivate, execute, follow-up and learn from. Morgan and Finnegan [47] highlight how organizations " . . . need to put structures and incentives in place to convert intangible asset capture into something tangible for the [organization]".
Objectives further align with the propositions proposed by Munir et al. [49] which states that organizations adopting OSS in their tools and infrastructure setups may benefit through reduced product development costs and time-tomarket, as well as increased product and process innovation. Considering Munir et al's [49] classification of why and when organizations adopt and share software as OSS, all three case organizations can be classified as having a proactive approach with the main focus on building symbiotic relationships through their OSS engagements. Similar to Sony Mobile [49], these organizations can hence be seen as mature players where the use and sharing of OSS are motivated by business rationale.
When comparing the two private case organizations, CaseOrg1 and 2, against the public case organization CaseOrg3, many of the objectives overlapped, although the expected key benefits may differ. For example, regarding CO8, which is focused on creating or replacing an existing industry or community standard, CaseOrg 1 and 2 see value in being able to steer the direction of a community or industry, and potentially disrupting competitors by commoditizing a certain technology [68]. CaseOrg3, on the other hand, views the key benefit as improving competition in the industry or market and potentially forcing the private actors to adapt. Hence, both private and public actors may view the release of OSS and commoditization of the underlying technology as a strategic tool, but in some cases for the opposite reasons.

Contribution Complexities
The contribution complexities presented in Table 5 can be viewed from the different perspectives of a contribution strategy. With respect to whether a software artifact or parts of it should be shared as OSS or not, a common concern in literature regards the risk of sharing differentiating or in other ways sensitive IPR ((e.g., [23,24,29,68,74,78]). This risk was also explicitly recognized in the complexities CC3 and CC5. Selective revealing, as labeled by Henkel [23], was a recognized practice in both CaseOrg1 and 2, as well as in Sony Mobile [38].
In contrast, this was not an issue for CaseOrg3. As a public sector organization, they aim to release what they find most "differentiating" in their view, and what can provide the biggest value to their ecosystem, and in the end, the citizens. Their motivation lies in their goals as defined by the government: "to facilitate and enable matching between job-seekers and employers on the Swedish labor market" 10 . However, they do see a balance between raising the bar for private actors in their ecosystem and not hurting their business model. Although not explicitly found in the coding, this introduces a timing factor, i.e., that the contribution or release of the software artifact is stalled until the private actors have had time to adapt. This addresses the question of when a software artifact should be shared as OSS.
A related complexity is that of the commoditization process and the concerned software artifact (CC4), which is also brought up in literature [6,21,35,38,68,78]. By being early, an organization can get a first-mover advantage, gain bigger influence, and potentially steer the development, e.g., within a community through a new feature [39,48], or within an industry through a new standard or platform [74] (see e.g., contribution objective CO8 and CO9). By being too late, an organization can risk having to adapt to competing solutions or maintain the internal solution [38,69]. Among the case organizations, both CaseOrg1 and 2 experienced this complexity. I1 from CaseOrg1 described it as a ". . . trade-off between competitive edge and burdon", aligning with other reported observations [78].
Lastly, the question of where, i.e., if the software artifact should be contributed to an existing community, or if a new community should be established, touches on several of the complexities, many of which are found across all three case organizations. A common concern among many of the complexities is the need for, or risk of losing, control (e.g., 14). In these cases, if an organization requires a certain level of control on the development direction of the software artifact, the artifact may preferably be released in a community where the organization has a high level of influence on the RE process [39,60], or as a new community [38]. A decisive factor is the external interest for the software artifact (CC13), i.e., whether or not it be accepted within a specific community, or if there is an interest for a new community. In the former case of an existing community, having an existing influence within the community could help to create the interest (CC14) [48]. The health of the OSS community is another complexity as a community requires active contributions from its members to stay alive. These factors may be considered in a specific community strategy as seen from the perspective of the focal firm, which outlines the importance of that community, and what engagement and level of influence that the focal firm wants with respect to the community's requirements engineering process [39].
When weighing the options of contributing to an existing community or creating a new one, the earlier may be preferred if possible. As highlighted by CC10, creating a new community may be related to a higher cost, and comes with a number of extra challenges [33,75]. How this is best done is, however, beyond the scope of this paper, and an interesting topic of further research.

Threats to Validity
The identified contribution objectives and complexities are the result of a multiple-case study of three case organization over the lapse of two research cycles. To determine the external validity [58] of the objectives and complexities, the characteristics of these organizations need to be considered as they define the problem context [77] on which the COs and CCs are based.
The three case organizations investigated in this study both have overlapping and distinct characteristics. To some extent, they provide extremes [17] to each other, while still having resembling characteristics. Considering the way they use and leverage OSS, all three organizations use it for their internal tool and infrastructure setups. In CaseOrg2, the department developing these tools are explicitly studied. CaseOrg1 uses OSS to enable and add value to their hardware devices and as a basis for certain services sold to businessoriented customers. As a public agency, CaseOrg3 differs from CaseOrg1 and CaseOrg2 in that they are not driven by commercial business incentives. Instead, they wish to help private actors focus on more value-adding activities and thereby improve job-matching capabilities for employers and job-seekers. CaseOrg2 however, does not consider themselves as having any product differentiation, compared to CaseOrg1. Following the categorization by Munir et al. [49], the organizations provide a suitable sample as they all have an awareness for why they share software as OSS and may reflect on the complexities that are present, even in the case of CaseOrg3 who does not have an explicit contribution process in place.
We acknowledge the limitations of case studies and do not claim any statistical generalization [58]. However, we do believe they provide a means to gather deep knowledge of industry practice and rationale in the problem context. By considering the case organizations' characteristics, the reader can put the presented contribution objectives and complexities as well as the organizations' rationale and concerns for sharing software as OSS into context. Through analytical generalization (cf. analogical inference [77]), results from this study can then be extended to cases with similar characteristics within a similar context [58]. Both similarities and dissimilarities between the source and target cases should be thoroughly analyzed [18]. In Section 3.1, we provide a general description of each of the case organizations, as well as of their specific contribution processes and examples of OSS projects that they are contributing to or have released as OSS. Quotes from interviewees (see examples in Appendices C and D) are used to describe the contribution objectives and complexities, and to provide further contextual factors that may otherwise risk being lost in the reporting of the research if abstracted by the researcher.
A threat in regards to reliability relates to that only the first author was involved in the data gathering and analysis process of the study. To minimize the risk of misinterpretations, member-checking [15] was performed by presenting interview summaries to key interviewees at the case organizations. During the coding process, the inductive approach infused a constant comparison between new data and existing codes, enabled by audit-trails being kept [58]. Cross-case analysis [61] was also performed as codes identified in one case were reiterated in the transcripts from the other cases, after which a final coding scheme assembled. As can be noticed in table 3, there was saturation in the number of emerging contribution objectives and complexities. Triangulation [58] with archival data was also performed by cross-checking coding schema and basing interview questionnaires on contribution request forms from seven organizations.
After the final coding was performed in the second research cycle, the contribution objectives and complexities were presented and discussed with I1 from CaseOrg1, I7 and I8 from CaseOrg2 and I15 from CaseOrg3. This kind of static [19] or descriptive validation [26] is a useful approach in the artifact validation phase to gain feedback and refine a research artifact before it is transferred or implemented in a real-world problem context [19,77].
I1 from CaseOrg1 confirmed identified contribution objectives and complexities. I1 added further facets to e.g. CC6, that patents may also provide a source of license revenues in other cases which should also be considered. I1 found the objectives and complexities useful and that "[they] really fit into [CaseOrg1's] strategy which is, we are trying to streamline the entire [contribution] process so that we are asking the right questions and we want to get to a point where we are able to approve everything online and don't need to have a meeting. Because if these questions are answered correctly then we should be able to even have an AI/ML-based algorithm which says, the risk is 10% so it is OK to approve it". I1 also adds that a contribution may be "more things than just code", exemplifying evangelizing, technical writing, writing bug reports, sharing of knowledge and experience, as well as test cases and design documentation. We agree with I1 that a contribution may be many things, but choose to limit the scope to the sharing of software artifacts as OSS. We view these artifacts as internally developed software functionality of different size and complexity, e.g., bug-fixes and features to frameworks, projects, and products, including e.g., related test cases and documentation. Other activities we believe should be covered by a community strategy that specifies how an organization should engage with a specific OSS community [39].
I7 and I8 from CaseOrg2 found the contribution objectives and complexities valuable and saw value in comparing with other organizations. They believed that the objectives and complexities can be used as an eye-opener to those within the organization that are skeptic to OSS. Both interviewees agreed with and verified the relevance of all of the identified objectives and complexities. They also added support for CC5 and CC15 and refined the description of CO7.
I15 from CaseOrg3 confirmed the identified objectives and complexities, while also adding support for CC4 and CC5. In regards to the latter complexity, I15 highlights how it also connects to CC4 and how they strive to share software artifacts that are differentiating in order to help businesses focus on more value-adding activities.
In conclusion, we believe that the identified contribution considerations are relevant to the studied case organizations, but we also believe that the findings have relevance beyond these organisation, while that of course depends on problem context to which these findings are transferred. The validation of the completeness of the set of contribution considerations, is a matter for continued research, but our investigation of existing literature has not indicated any significant omissions.

Conclusion
In this study, we aim to help organizations in deciding if a software artifact (e.g., feature, framework or project) should be released as OSS, and, if so, when and where. For a specific artifact, the "what"-question regards if the artifact should be contributed in full or kept closed, or if certain parts can be contributed under certain conditions. The "when"-question regards the timing of the release. Finally, the "where"-question regards whether the artifact should be contributed to one of many existing OSS communities or if a new community should be established. Answers to these questions may be valuable input to the development of a contribution strategy for the concerned software artifact.
To support organizations in creating effective contribution strategies, we conducted a multiple-case study at three software-intensive organizations using an iterative approach spanning over two research cycles. A set of 27 contribution considerations, divided into 12 objectives and 15 complexities, were identified based on an inductive and iterative coding of 20 interviews across the three case organizations.
Contribution objectives highlight opportunities for 1) improving reputation towards community, customers, partners, and current and future employees, 2) managing suppliers through price pressure and outsourcing, 3) managing partners and competitors through standardization efforts and ecosystems, and 4) exploiting externally available knowledge and resources through open innovation and extended development resources.
Contribution complexities focus on 1) risk of losing control of the development of business-critical software in concerned communities, 2) risk of giving away differentiating IPR that provides a competitive advantage, 3) risk of unintentionally exposing unethical use-cases and security vulnerabilities, 4) costs of abstracting and generalizing software artifact, pushing through contribution process and potentially maintaining once contributed, and 5) difficulties in deciding where the artifact should be contributed based on external interest, potential need for influence, and community health.
Future work should look to generalize these identified contribution considerations beyond the problem context of the three investigated case organizations. In order to arrive at a framework that can be used by software-intensive organizations when setting up their contribution strategy decision process, further validation and generalization is need. Specific research focus is also needed to investigate possible relationships between contribution objectives and contribution complexities. In addition, research attention could be given to identifying and formalizing metrics that may be used for quantifying the potential benefits proposed in the objectives, as well as the risks and costs implied by the complexities. Such metrics could help organizations arrive at key performance indicators, such as a Return-on-Contribution, which may help to make decisions comparable, measurable, and easier to motivate. This could further help organizations in automating their contribution processes and thereby potentially lowering the threshold for developers to contribute, and also, hopefully, help the organization to more effectively reach their contribution objectives.
-How would commoditization affect what you contribute and not? How would it affect the timing of when you contribute? -How would a feature's profit for the company affect what is contributed and not? How would it affect the timing of when you contribute? How could this aspect be judged or quantified? -How would it affect if the feature or the knowledge and technology behind it is hard to acquire or control? How could this aspect be judged or quantified? -How would you reason in regard to if and when to contribute, given that a feature results in a: high profit for your company, and is critical to maintain control over? low profit for your company, and is critical to maintain control over? high profit for your company, and not critical to maintain control over? low profit for your company, and is not critical to maintain control over? -What other aspects would affect your decisions? -How would your decisions affect how you engage and invest in the community where the feature is to be contributed to? -How are policies or decisions regarding what to contribute communicated today? How could this be improved/otherwise done? -Is there anything I have missed that you would like to pick up on? Or anything else that you would like to talk about?

Appendix B Questionnaire -Second Research Cycle
Demographics: -What is your job title? -How many years of experience do you have in your current and similar roles? -Could you, in short, describe your daily work and responsibilities? -Could you, in short, describe your experience in working with OSS communities?
Contribution Objectives: -What reasons do you see to share your internally developed software as OSS? What can your organization gain out of this? How can you measure it? -What reasons do you see in relation to competition and collaboration with external parties? Who would it benefit or hurt? -What effect can you have on a third party by releasing software as OSS?
For example, competitors or suppliers of similar proprietary products? -Do you consider if there is a potential to create a new standard? How can such potential be measured? -Are there any type of software that should be shared for different reasons?
How would these types be characterized?
Contribution Complexities: -What aspects should you take into consideration in the decision of sharing software as open source or not? -What consideration should be taken to how software relates to your value proposition and how it affects your revenues? For example, if the software is shipped with your product or if it is used to build or deliver your product/service? -How is a decision affected if the software contains differentiating parts? -How is a decision affected if the software contains patents or parts that could be patented? -Is there any type of sensitive information within the software that could complicate a contribution? -How should any competitive advantages be taken into consideration? -How do timing and commoditization affect such aspects and any future decisions? How do you consider the risk of competing solutions being released before yours? -How do you consider internal restrictions in terms of budget and resources?
What costs do you see related to releasing software as OSS? How do these costs affect the decision? -Do you see any other business related aspects, impediments or risks that should be taken into consideration? -What consideration should be taken in regards to how the software is used and integrated into your organization and your product/services? -What consideration should be taken to security-related aspects? -How do you consider the software's generalizability and potential to extend? -Do you see any other technical aspects, impediments or risks that should be taken into consideration? -How is a decision affected in terms of the need to control the development of the software? -How do you consider existing alternatives (OSS and proprietary)? -What alternatives to you see if there is a shallow external interest from a community? -What factors affect your decision when choosing to contribute to an existing community or creating a new community? -How do you consider the health and sustainability of a community?

C.1.1 CO1 -Prove skill and influence:
Description: Being an active contributor in a community can help to build a reputation of an organization as technically skilled and influential in the community [50,69].
Benefit: Improved trust towards customers. Example (CaseOrg1): "We basically realized that we were so dependent on [OSS project] and that it was the selling point of our product, so we needed to demonstrate for customers that we were one of the core contributors. It was a selling point in the marketing brochure" (I1). Benefit: Improved trust towards partners. Example (CaseOrg2): I7 reports how being an active contributor in a community can help to promote CaseOrg2 in new channels and build up new partnerships.

C.1.2 CO2 -Increase transparency:
Description: By being transparent in how an organization performs certain actions, they can build trust among customers and potentially avoid allegations of wrongful doing. Benefit: Improved trust among customers. Example (CaseOrg1): A tool was developed and open sourced to measure the speed of their services. By keeping the project open, the organization could be transparent in how they performed the measurement. Benefit: Improved trust among the public. Example (CaseOrg3): From a public sector perspective, CaseOrg3's aim is in a similar manner to create transparency towards the public and thereby earn their trust, "this is what you get for your tax money" as put by I13.

C.1.3 CO3 -Improve employer branding:
Description: Working with OSS projects can help an organization to both retain existing and attract new engineers [50]. Benefit: Attraction of talented employees. Example (CaseOrg1): "It is important to people and I think a positive employment characterization that you get to engage with open source communities and that the company does release something as open source projects. I think that is a big selling point that people are looking for in whom they want to work for as an engineer". Benefit: Retention of existing employees. Example (CaseOrg1&3): Besides being allowed to engage with an external community with the intrinsic rewards that follow, highlighted by I19 as "the fun parts", working with OSS offers engineers the opportunity build their own transparent portfolios. As stated by I6, "[the engineers] view it as a core part of their career development and in a way, they can kind of be recognized for that in a very different way than they could if they were simply working on internal or commercial software".

C.1.4 CO4 -Be a good open source citizen:
Description: Contributing to an OSS project may for some be ideologically motivated [30]. Benefit: Idealistic satisfaction among employees. Example (CaseOrg1): "I think it is from one point of view the right thing to do, because you are taking advantage of this set of code, and so you should, while you are taking advantage of it, you should also be contributing back [from] a good citizen point of view". I5 further adds that a reason "may be that the developers are pro-OSS and so they are just like, this isn't secret sauce, so just sort philosophically we want to contribute this to the commons because maybe someone will take advantage of it. There's a good citizen aspect to it". ware as OSS, and requiring tenders to build on it, competition in the tender process is improved as smaller actors enabled to participate in a process "otherwise set-up to benefit large firms" (I12).

C.2.2 CO6 -Outsource infrastructure operation:
Description: Sharing software as OSS can be seen as a way to not just outsource the development of a software project [1], but also the operation of it. Benefit: Internal focus on activities related to core business. Example (CaseOrg1): As explained by I5, "We can get to a point where we can actually outsource the operations of this [software] ... via an open source path, which then frees up this team to do other stuff ".

C.3.1 CO7 -Collect data:
Description: By sharing e.g., algorithms as OSS, others can generate data which can then be used to improve artificial intelligence and machine learning initiatives. Benefit: Improved machine learning and artificial intelligence algorithms. Example (CaseOrg1): I1 explains "The Machine learning team has often come to us saying, I want to open source this algorithm because I wanna learn how it grows, and we alone don't have enough data to feed and we need the world to feed it data". Benefit: Creation of solutions based on Open Data sources. Example (CaseOrg3): I15 exemplifies how the gathering of job-ads can help create an automated review-function which could classify if an add is discriminatory or not.

C.3.2 CO8 -Standardize a solution:
Description: By having an OSS project or contribution adopted and accepted as a standard solution, an organization can potentially replace existing proprietary and community solutions [23,30,42,72]. Benefit: Force competitors to adapt and steer market or community according to internal agenda. Example (CaseOrg1): A project was developed and open sourced in order to replace proprietary solution as "a way to get away from a commercial vendor and open up the access to the data collected by the vendor, but also to be able to influence and control [the project's] direction" (I6). As further explained by I1, "by putting it out there you can influence it and thereby where the market is heading", potentially steering the competition in the direction most beneficial to the firm. Benefit: Improve competition and enable more value-adding development on market. Example (CaseOrg3): From a public sector perspective, CaseOrg3 views the benefit as "improving competition" (I13) and "allowing more to join the market" (I15). I15 continues, "I think we are raising the bar for the entire market, allowing everyone to level up and stop focus on base infrastructure".

C.3.3 CO9 -Build a software ecosystem:
Description: Software released as OSS can serve as a technological platform around which a software ecosystem may form with firms who can start to collaborate and interact through a shared market of software and services. Benefit: Enable and stimulate creation third party applications and services.
Example (CaseOrg3): From a public sector perspective, CaseOrg3 is aiming to create a software ecosystem by contributing internal software artifacts as new OSS projects along with Open Data sources. Based on the platform, constituted by the OSS projects and Open Data sources, private organizations and firms on the labor market can create new and "hopefully better market-adapted solutions" (I13). I17 adds "I think there is an interest and a need for everybody within the sector to collaborate and to help each other and to make sure that the right individuals land the right opportunities. So what we are trying to gain is literally a collaboration [...] with others to provide better services to society".
C.3.4 CO10 -Improve partner collaboration: Description: Sharing e.g., tools and infrastructure projects as OSS could potentially act as a complement and improve collaboration between CaseOrg2 and other actors within CaseOrg2's software ecosystem that is connected to its core-business of embedded devices. Benefit: Increased value of software ecosystem. Example (CaseOrg2): As put by I7, "It would be easier to collaborate around the same stack... Also, by offering boilerplates to our partners we help them to do the right thing from start". I8 adds, "I think, would [CaseOrg2] be more open with its tools and libraries, this would be appreciated by, and a way to come closer to our third-party developers".

C.4.1 CO11 -Open up innovation process:
Description: Collaboration with OSS communities can be seen as a case of Open Innovation [50], allowing an organization to extend its R&D and innovation capabilities and initiate new collaborations in an open and transparent way. Benefit: Accelerated innovation process. Example (CaseOrg1): I6 describes it as "Open source is in many cases about doing external R&D in a way. You are leveraging external groups to do things, and it is often the case that many companies don't really fund medium to longer term R&D in-house anymore... You get the network effect of so many more participants". Benefit: Creation of more and better market-oriented solutions Example (CaseOrg3): Open collaboration may also be seen as an opportunity to "open up the requirement engineering process" (I15) and create "faster feedback-loops, and to become more reactive and compatible to the needs of the market" (I12).

C.4.2 CO12 -Extend development resources:
Description: Using and combining the development resources of an OSS community with an organization's internal, software development may potentially be accelerated and extended as e.g., features are implemented and bugs corrected [48]. Benefit: Focus on more value-adding development. Example (CaseOrg1): I6 describes it as "the more that you can push things down to commodity, the easier it becomes, and cheaper, and then you can keep focusing more up the stack. Keep focusing on the next new feature". Benefit: Accelerated development. Example (CaseOrg1): "[Y]ou almost get this acceleration of innovation on that platform. It supercharges [the platform] in a way and you are getting, maybe it is us and five other actors, maybe even competitors, and we are all contributing back to things that we are finding. It is a better product for everybody. So I think that accelerates the development process" (I6). Benefit: Lower maintenance cost. Example (CaseOrg3): "The code is actually a cost and when you realize that, you will see that it is better to share that cost than keeping it to yourself " (I12).

D.1.1 CC1 -Impact on the value proposition:
Description: Software artifacts that have a close connection to an organization's value proposition and its revenue stream may warrant special attention in order to determine any potential costs or negative risks that may be implied by contributing the artifact. Concern [CaseOrg1&2]: Risk for misalignment between internal and external agendas on OSS with high impact on value proposition. Example [CaseOrg2]: In the case of CaseOrg2, the department studied in this paper focuses on infrastructure and tools-projects which is used by CaseOrgs2's product development teams. The software developed and maintained by the department can hence be considered to have an indirect connection to CaseOrg2's value proposition and revenue streams, or as put by I7, "not even close to core business". This provides the department with a "much less restrictive process than what applies for core business" (I7). Example [CaseOrg1]: CaseOrg1 develops and maintains similar types of projects, but also those that have a stronger connection to the organization's value proposition and revenue streams. For example, one project that they have released is a Linux-based operating system embedded in hardware devices which enables the organization the deliver its service offerings to its customers. Another project released by the organization makes up a pivotal part of their infrastructure, also enabling the delivery of its service offerings, but also the possibility to offer the infrastructure as a service to business customers, including competitors. In both examples, the projects are considered as commodity but of strategic importance why the organization needs to be "actively involved and be able to steer the direction and make sure that as that project evolves that it continues to meet our needs and to evolve in a certain way" (I5). Mitigation strategy: Build influence on OSS community's RE process to enforce internal agenda.
CC2 -Impact on internal operations: Description: Giving away software artifacts that provide product differentiation or other types of competitive edge is a common fear among firms, but also an opportunity and a balancing act for public organizations. approve. The 7 percent has been the things that are core to our business, or something that is a competitive advantage". This may be a consequence of CaseOrg1's work to actively encourage its developers to separate between differentiating and commodity functionality as explained by I6, "These things are really basic functionality, that is ok, we are going to share that, that is part of the core platform. But there are maybe some parts where you can on a modular basis extend it or do integrations with internal systems in order to not give away the secret sauce, the differentiation". Mitigation strategy: Identify and separate between differentiating and commodity functionality when possible. Concern [CaseOrg1&2]: Risk of loosing process-based competitive edge. Example [CaseOrg2]: For the department studied in CaseOrg2, a bigger concern relates to the risk of giving away process-based competitive edge, as explained by I7 "Of course we have tools that can provide us with a competitive edge". Faster development pace and better quality assurance are two areas highlighted by I9. Mitigation strategy: Identify and separate between differentiating and commodity functionality when possible. Concern [CaseOrg3]: Risk of damaging the business models of existing actors on market. Example [CaseOrg3]: Concerning CaseOrg3, they prioritize releasing software artifacts that have the potentially highest differentiating value for actors on the market. However, as expressed by I15, "It is a balancing act. There will be cases where we will open up stuff that some make a living on. Actors will have to innovate their business models and adapt. Our aim is to improve competition, not hurt it". Mitigation strategy: Inform actors and provide possibility to adapt in advance.

D.2.2 CC4 -Commoditization:
Description: The timing of when to release something as OSS can be a complex issue. As I1 highlights, "There is a trade-off between a competitive edge and burdon". I.e., while keeping the software closed may provide a competitive advantage, it may cost in terms of maintenance and support. Concern [CaseOrg1&2]: Risk for giving away competitive edge or differentiating functionality too early or an alternative solution being accepted before ones' own. Example [CaseOrg1]: I1 describes as a "waiting game... [Some] may want to say -I want to hold on to this feature longer -because they don't want to make it a level playing field for everybody, or they may take certain features and say, -I think we need to get it out there as fast as possible, because we heard that competitor X is working on putting this into the pipeline... So I think it could be both ways, there could be some features where we say, No, let us hold on to this until we get a first-mover advantage on the market using it, then once we have a significant advantage, then it is ok to commoditize it and put it out there". Mitigation strategy: Maintain awareness in community and industry about potential alternative solutions. Concern [CaseOrg3]: Risk of damaging the business models of existing actors on market. Example [CaseOrg3]: CaseOrg3 also considers the commoditization process as an important aspect, but as highlighted in CC4 they strive to share software artifacts that are differentiating in order to help businesses focus on more value-adding activities. Mitigation strategy: Inform actors and provide possibility to adapt in advance.

D.2.3 CC5 -Sensitive IPRs:
Description: Sensitive IPs or patents is not limited to functionality that provides a competitive edge in terms of a product or process (see CO4). They can also constitute pieces in a defensive patent portfolio, serve as a revenue source of license subscriptions, or belong to a third-party. Concern [CaseOrg1&2]: Risk of giving away patented, patentable or in other ways sensitive IPR. Example [CaseOrg1]: For CaseOrg1, patents can be viewed as a competitive edge even in cases where they do not cover functionality that is actively used. As I1 explains, "We live in a very litigious environment, which means, as a company we are in an industry where there are lots of lawsuits against each other, so we use our patent portfolio in a defensive way. So there is a drive to build a patent portfolio which is why the patent office encourages people to seek patents, because the bigger and better the patent portfolio, the more we can defend ourselves". Hence, a common question that is asked in CaseOrg1 is "can and should we patent this?" (I1). I1 also adds that in other organizations certain patents may provide license revenue, which should also be weighed against the potential value of sharing the patent as OSS. Example [CaseOrg1]: In the case of CaseOrg2, as they are orchestrating a larger software ecosystem around its products, a question they ask is if there are any patents or IPRs that belong to one of their partners. Mitigation strategy: Critically review need and origin of patents. : I18 sees a a risk of "cases where we would not be very proud of as a public agency" and asks "how far does the responsibility of CaseOrg3 as a public agency stretch?" Mitigation strategy: Investigate potential alternative use cases of software artifact.

D.3.2 CC9 -Security threats:
Description: Releasing a software artifact as OSS may pose a security threat by exposing unknown vulnerabilities present in its source code. Concern [CaseOrg1,2&3]: Risk of exposing security-related vulnerabilities. Example [CaseOrg2]: At CaseOrg2, "the security department has a positive view on open source as you get more eyes on the code" (I11). However, they still have a careful review process in place as they do not wish to expose any potential back-doors that could lead to the organization's hardware-based products. Example [CaseOrg3]: At CaseOrg3, I18 highlights that "it is the data that is considered valuable and needs protection" which is rather done by "proper key management" than keeping any related software closed. Mitigation strategy: Include security audits in contribution process.

D.4.1 CC10 -Budget and resource constraints:
Description: Contributing a software artifact always comes with a cost, both in terms of preparing, contributing and potentially maintaining the software artifact as OSS. Concern [CaseOrg1,2&3]: Cost for preparing, contributing and maintaining software artifact. Example [CaseOrg2]: Abstracting, modularizing and generalizing an artifact may prove an expensive effort compared to projects that are developed with the intention from the start. As put by I8, "if we build something that is tailored to and dependent on internal infrastructure, it is most often no idea to contribute it. In most cases, we can modularize and generalize it, but the cost can get really high, so it is a matter of if it is worth it or not". I9 further mentions that there "is a lot of hidden costs" that are connected to the contribution process, such as "scrubbing" or cleaning the source code and its version history of sensitive or unnecessary comments and information. Other costs include going through the contribution process of the related community, or creating a community if the software artifact is released independently of any existing community. In the latter case, much more resources are required long-term both in terms of managing the community, but also maintaining and leading the software development within the community. As highlighted by I10, "we prefer contributing to existing communities because it is expensive taking on the role of a maintainer in a larger project". Example [CaseOrg3]: CaseOrg3 recognizes the costs implied by sharing a software artifact as OSS as a concern, but sees it from a long-term perspective. I15 asks, "What is the need of the labor market? If there is a potentially positive outcome, then I think we are prepared to spend the money needed". Mitigation strategy: Develop software artifacts as if they were intended to be released as OSS from start, separating commodity and differentiating functionality. Also, ask "who is going to be the owner of this repo, and have you allocated the time to maintain it, and has your boss approved your time budget?" (I1).

D.4.2 CC11 -Modularity and architecture:
Description: In certain cases, it may be that the software artifact is too embedded in internal infrastructure, which makes it infeasible to modularize the artifact. Concern [CaseOrg1,2&3]: Technical feasibility to modularize and abstract software artifact. Example [CaseOrg]: I1 stresses that "companies should start projects with the goal that it will be open one day, then they could architect it right from the start with generality and modules that can be contributed". Mitigation strategy: Develop software artifacts as if they were intended to be released as OSS from start, separating commodity and differentiating functionality. An option may be to contribute the "design document or the blueprint of the project itself so someone else can create it", i.e., documentation that in some way captures the knowledge from the underlying software artifact.

D.4.3 CC12 -Code alignment:
Description: By not contributing internally developed code that relates to a project, a misalignment between the internally and externally developed software may arise. A negative consequence may be that the organization unintentionally ends up on a fork that grows with time and creates unnecessary maintenance and patch-work. Concern [CaseOrg1,2&3]: Cost of maintaining internal fork. Misalignment between internal and external development may prevent or complicate future contributions. Example [CaseOrg2]: I8 explains it as, "If you don't share, the community may take off in another direction. Then you will stagnate and come to a place that will be very hard to get back from". Mitigation strategy: Keep internal fork of concerned OSS as close as possible to the community's.

D.5.1 CC13 -External interest:
Description: To contribute a software artifact to an existing OSS community, or to create a new community around it, there needs to be an external interest for the artifact. Concern [CaseOrg1,2&3]: Risk of contribution not being accepted or community not being established. Example [CaseOrg1]: I3 describes it as "filling in a gap". I5 asks the question, "Is there a general purpose part of this that I can see multiple teams inside my company taking advantage of ?". External interest should, therefore, be investigated before proceeding with any contribution. In one example where CaseOrg1 ended up creating a new community, I6 explained, "everyone needs to do it, and it is not really great agreement over what the right methodologies are". Example [CaseOrg2]: For "existing communities that have been around for long you know, or at least get an indication, if it is going to be an uptake or not [of the contribution]" (I7). Analyzing stakeholders' agendas within a community can further help. "What's their strategy, whom do they have playing, what are they trying to get done, what chess moves are they making, and if so, which then informs what we contribute, when we contribute, and how strongly we need to be present" (I1). Mitigation strategy: Investigate external interest and needs within concerned communities and industries, and consider the generality of the usecase that the software artifact solves.

D.5.2 CC14 -Influence in community:
Description: If the external interest within a community is weak, or if the community is heading in a different direction, it may be important to have influence on the concerned community's RE process in order to create traction and approval for the contribution, but also to be able to steer its development if it is accepted [39]. Concern [CaseOrg1,2&3]: Low level of influence in the community may prevent or complicate the contribution of a software artifact. Example [CaseOrg2]: I7 highlights that "It is important for [CaseOrg2] to pick up a leading role in certain communities that we value as strategically important and as a potential way to get an edge against competitors in those communities". Concern [CaseOrg1,2&3]: Target foundation may require a governance model too open which may render in too large scope and loss of control. Example [CaseOrg1]: I1 explains how CaseOrg1 reasoned about the creation of a separate community behind an internally developed Linux distribution, "We could have contributed that code to the Linux Foundation or the Apache Software Foundation and have them make it a broader project. But we ended up creating our own foundation and collected all the [relevant stakeholders] together to contribute towards this platform that we created. In a way, it is the right way because we wanted to make sure that it served the need of our [main customers] and it didn't get too broad and become an embedded system that everyone uses... So we want to maintain influence and be in a controlling position, so we are one of three members of the steering committee". Mitigation strategy: Build influence needed on concerned community's RE process. If e.g., the current level of influence is deemed not high enough to be able to contribute and steer the software artifact, one option is to create a new community where the community's governance structure can be tailored based on the focal organization's needs.

D.5.3 CC15 -Community health:
Description: Contributing to and engaging actively with a community is one way to support its health, i.e., ability to survive throughout time [70], which is an important aspect if an organization is dependent on a specific OSS project [39]. Concern [CaseOrg1,2&3]: Not contributing may have a negative impact on the health of the OSS project. Example [CaseOrg1]: I1 explain CaseOrg1's approach as "We care about the health of the project, will it die because there are not enough contributors maintaining it? We cannot let that project die because we are using it and we would have to swap out the code and go to something else". I1 continues, "We prefer to use something that is already there, and not reinvents the wheel, but if it is not going to be healthy, then we would want to be there just to create a vibrant community, not for influence, but for health". Mitigation strategy: Monitor and analyze the health of concerned OSS communities.