1 Introduction

Sharing, or contributing, software artifacts (e.g., features, projects, and frameworks) as Open Source Software (OSS) is a common practice among software-intensive organizations today (Munir et al. 2016). By “opening up” (Chesbrough et al. 2014), 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 (Munir et al. 2016, 2018a; Stuermer et al. 2009; Henkel 2006; Lindman et al. 2009). The motive may also be driven by pure idealism and being a good OSS citizen (Jansen et al. 2012). 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 (Shahrivar et al. 2018; Andersen-Gott et al. 2012; Spijkerman and Jansen 2018), or as a means to create a new standard or compete with existing ones (Lindman et al. 2009; Jansen et al. 2012; Henkel 2006; West 2003). 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 (Andersen-Gott et al. 2012).

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 (Dahlander and Magnusson 2008). 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 (Dahlander and Magnusson 2005, 2006). An organization, therefore, may have to consider not just where, but also what it contributes, and when. Risks include giving away differentiating functionality (Wnuk et al. 2012; Van der Linden et al.2009; Henkel 2006, 2008; West and Gallagher 2006; Iivari et al. 2008), or contributing too late and having to choose between adopting the alternative solution or maintaining an internal solution alone (Linåker et al. 2018; Wnuk et al. 2012). 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 (Linåker et al. 2018).

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 organization and its business goals (Wnuk et al. 2012). 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 (Munir et al. 2016), with some exceptions (Wnuk et al. 2012; Weikert and Riehle 2013; Linåker et al. 2018). 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 semi-structured 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–A provide detailed information about interview instruments and findings.

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

2.1 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 (Shahrivar et al. 2018; Munir et al. 2016; Höst and Orucevic-Alagic 2011; Hauge et al. 2010). We categorize the benefits into four different themes.

A common theme is the cost-saving aspects (Munir et al. 2018b, 2016; Andersen-Gott et al. 2012). By extending the resource-base (Dahlander and Magnusson 2008) and agreeing on a common standard (West and Gallagher 2006), organizations can share the maintenance and quality assurance, accelerate the development and potentially decrease their time-to-release and market (Munir et al. 2018a; Stuermer et al. 2009; Henkel 2006; Lindman et al. 2009; Olsson and Bosch 2017; Lundell et al. 2011). By freeing up internal resources, they can focus on more value-adding activities (Munir et al. 2018a; Van der Linden et al. 2009; Lindman et al. 2009). On the opposite, by adopting a less symbiotic relationship to the OSS community (Dahlander and Magnusson 2005), 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 (Wnuk et al. 2012; Ven and Mannaert 2008). Hence, to attain these potential benefits, active engagement and a symbiotic relationship may be needed with the OSS community (Chengalur-Smith et al. 2010; Dahlander and Wallin 2006).

Another common theme is the innovation aspects (Munir et al. 2016; Andersen-Gott et al. 2012), which can be both product and process-oriented (Munir et al. 2018b). By opening up the innovation process (Chesbrough and Appleyard 2007) and “pooling” the R&D/product development (West and Gallagher 2006), organizations get access to an external workforce (Lundell et al. 2010), which may bring increased knowledge sharing (Nagle 2018; Lundell et al. 2011) and innovation at a lower cost (Stuermer et al. 2009; Ziegler et al. 2014). However, this external workforce should be seen as a complement rather than a substitute for internal knowledge and development (Stam 2009; Dahlander and Magnusson 2008). Munir et al. (2016) 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 (ÅGerfalk and Fitzgerald 2008).

A third theme can be tied to improved reputation (Munir et al. 2016; Ven and Mannaert 2008). 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 (Lundell et al. 2010; Dahlander and Magnusson 2008; Riehle 2011; Stuermer et al. 2009; Henkel 2006). The improved reputation can turn into a competitive advantage (Henkel et al. 2014) and legitimize the use of the OSS from a public perspective (Dahlander and Wallin 2006). An organization’s customers are offered an opportunity to avoid vendor-lockin, and the ability to customize the software to internal needs (Lundell et al. 2011; Munir et al. 2018a).

A fourth theme concerns control aspects (Linåker et al. 2018). If an OSS community has a meritocratic coordination process in place (Shaikh and Henfridsson 2017), influence on the development direction of the community may be gained by participating in the development and maintaining a symbiotic relationship (Linåker et al. 2019a; Dahlander and Magnusson 2005, 2006; Butler et al. 2018; Schaarschmidt et al. 2015; Syeed et al. 2017; Nguyen-Duc et al.2019). This may help steer the community including competitors and to manage potentially conflicting agendas (Linåker et al. 2019a; West and Wood 2008; Munir et al. 2016; Schaarschmidt et al. 2015; Mäenpää et al. 2018).

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 (Munir et al. 2018a). 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 (Linåker et al. 2018). If released as a new community and traction is gained, it can potentially become a new standard or compete with existing (Lindman et al. 2009; Jansen et al. 2012; Henkel 2006; West 2003), and create a surrounding ecosystem with complements from other organizations (West 2007; Hartmann and Bosch 2016).

Some of these themes may be more or less important depending on the type of organization. Munir et al. (2018b) 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 (Dahlander and Magnusson 2005). 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.

2.2 Costs and Risks of Sharing Software as OSS

Deciding what should be contributed is a complex matter (Munir et al. 2016). Even though the amount of a software that may be considered differentiating is often limited (Lindman et al. 2009; Van der Linden et al. 2009), 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., Wnuk et al. 2012; Van der Linden et al. 2009; Henkel 2006, 2008; West and Gallagher 2006; Iivari et al. 2008). Instead of disqualifying a complete software artifact however, one approach may be to selectively reveal commodity or enabling parts while keeping differentiating parts closed (West 2003; Henkel 2006; Stuermer et al. 2009). An alternative approach may be to “spinout” (West and Gallagher 2006) disclose the software artifact under a restrictive copy-left license (West 2003), e.g., the General Public Licence version 2 and 3, or the Affero GPL.Footnote 1 This is a common approach for commercial OSS organizations (Riehle 2012) using a dual-license approach to appropriate and capture value from customers (Chesbrough and Appleyard 2007). 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 (Deodhar et al. 2012), or kept proprietary (Weikert and Riehle 2013).

A related challenge is determining when software should be contributed (Wnuk et al. 2012). Several studies have attempted to model and identify an optimal timing (Haruvy et al. 2008; Kort and Zaccour 2011; Caulkins et al. 2013). Caulkins et al. (2013) 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” (Linåker et al. 2018). As suggested by Van der Linden et al. (2009), a first step may be to open up the software in joint ventures or closed strategic alliances (Linåker et al. 2018), while a third step may be to release it as OSS. Wnuk et al. (2012) 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 (O’Mahony 2007), the organization needs to consider the requirements engineering process of the community (Scacchi 2002). In this context, the organization is a stakeholder among many and needs to consider potentially conflicting agendas from other stakeholders (Munir et al. 2016; Schaarschmidt et al. 2015; Mäenpää et al. 2018; Linåker et al. 2019b). If there is a misalignment between the organization’s and the community’s Requirements Engineering (RE) process (Ernst and Murphy 2012; Alspaugh and Scacchi 2013; Kuriakose and Parsons 2015), the organization may need to influence the development direction of the community (Munir et al. 2018a). If the organization lacks the influence needed, they need to consider the cost of gaining it (Linåker et al. 2019a). 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 (Kilamo et al. 2012; West and O’Mahony 2005; Dahlander and Magnusson 2008).

2.3 Contribution Strategies

Wnuk et al. (2012) highlighted the importance of contribution strategies early on. Research on the topic has however been limited (Munir et al. 2016) with some exceptions (Wnuk et al. 2012; Weikert and Riehle 2013; Linåker et al. 2018).

In previous work (Linåker et al. 2018), 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. 1), with each cell representing a certain type of generic artifact with its own contribution strategy that is proposed for the artifact.

Fig. 1
figure 1

The Contribution Acceptance Process (CAP) model as presented in Linåker et al. (2018). 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

Full size image

As an example, one of the four artifact types concerned strategic artifacts (upper right quadrant in Fig. 1) (Linåker et al. 2018). 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 (Linåker et al. 2018). 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 artifacts 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 (Linåker et al. 2018). 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 (Linåker et al. 2018). In the proactive, it is used to map a series of software artifacts, e.g., features in the product planning process (Kittlaus and Fricker 2017). 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.

2.4 Summary

The benefits that may incentivize an organization to contribute its software as OSS are many (Shahrivar et al. 2018; Munir et al. 2016; Höst and Orucevic-Alagic 2011; Hauge et al. 2010), as are the potential costs and risks that may remove or outweigh the benefits (Munir et al. 2016; Linåker et al. 2015). 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 (Munir et al. 2016), with some exceptions (Wnuk et al. 2012; Weikert and Riehle 2013), including our previous work with Sony Mobile and the CAP-model (Linåker et al. 2018). 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.

3 Research Design

To answer the research questions RQ1 and RQ2 as defined in Section 1, we employed a multiple-case study (Runeson et al. 2012) 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 (Easterbrook et al. 2008). 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 (Runeson et al. 2012).

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.

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

3.1.1 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. CaseOrg2 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 (Linåker et al. 2018).

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 (Linåker et al. 2018).

3.1.2 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 (Jansen et al. 2009) 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 communities. 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 JenkinsFootnote 2 and GerritFootnote 3 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 GithubFootnote 4 page.

3.1.3 CaseOrg3

General description:

The Swedish Public Employment ServiceFootnote 5 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 platformFootnote 6 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.Footnote 7 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.

3.2 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 (Linåker et al. 2018) conducted by the authors of this study.

Table 1 List of interviewees from CaseOrg1-3
Full size table

Interviewees were selected in order to gain different and complementary perspectives on CaseOrg1’s contribution strategy decision process. Each of the 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 (Runeson et al. 2012). Using an iterative and refining coding process (Runeson et al. 2012; Robson 2011), 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.”.

3.3 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 Table 2). A contribution request form contains questions about software artifacts, and often guidelines for, and examples of what types of contributions the organization generally accepts. The form is often submitted by the engineer or team behind the concerned software artifact. The contribution request forms give an indication of what the organizations consider when deciding whether the software artifact should be contributed.

Table 2 List of organizations from where contribution request forms has been gathered
Full size table

The revised questionnaire (see Appendix A) was then used in semi-structured interviews with five employees from CaseOrg2 and nine employees from CaseOrg3. 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
Full size table

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.

  • 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 positivexemployment 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.

4 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).

Fig. 2
figure 2

This study presents 27 considerations (12 Contribution Objectives (CO) and 15 Contribution Complexities (CC)) that may need to be considered by an organization when deciding on a contribution strategy for a software artifact. The COs and CCs are divided into four and five categories respectively and are listed in Tables 4 and 5

Full size image

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 decision-makers 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 A and A.

Table 4 Overview of the contribution objectives, related key benefits, in which case organization they were identified, and examples of similar findings in literature
Full size table
Table 5 Overview of the contribution complexities, related key concerns, in which case organization they were identified, and examples of similar findings in literature.
Full size table

4.1 Contribution Objectives

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

4.1.1 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 quality of a service is measured or what is produced based on public funding are two examples that are highlighted in interviews.

Allowing and enabling engineers to contribute to OSS can benefit the organization both in terms of retention and attraction of new talent (CO3). 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).

4.1.2 Supplier-centric Objectives

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

4.1.3 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 (DaSilva and Trkman 2014). 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 (Jansen et al. 2009) 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).

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

4.2 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 A 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 A to provide context for each of the examples.

4.2.1 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 (Linåker et al. 2019a). Also if one wants to grow a community, the organization to some extent have to consider the wills and opinions of the community (Laurent and Cleland-Huang 2009). 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.

4.2.2 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).

4.2.3 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 pro-actively investigate potential unethical use cases and perform security audits, before releasing any artifact as OSS.

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

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

5 Discussion

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

5.1 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. (2012). 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 (Butler et al. 2018; Duc et al. 2017 Dahlander and Magnusson 2005, 2006; ÅGerfalk and Fitzgerald2008). Further, the commercially motivated cost-saving objectives implied by the extended development workforce (CO12), and related benefits, has also been observed in a number of other studies (e.g., Munir et al. 2018a; Stuermer et al. 2009; Henkel 2006; Lindman et al. 2009; Olsson and Bosch 2017; Van der Linden et al. 2009). Support was also found for the survival, or more strategically, motivated objectives such as CO9 - Build a software ecosystem (West and Gallagher 2006, 2008). 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 (Shahrivar et al. 2018), or non-monetary benefits (Morgan and Finnegan 2014) is that they may be less obvious and harder to measure and track in financial spreadsheets (Morgan and Finnegan 2014), 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 objectivesFootnote 8. With such metrics in place, contribution requests and strategies can potentially become easier to motivate, execute, follow-up and learn from. Morgan and Finnegan (2014) 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. (2018b) which states that organizations adopting OSS in their tools and infrastructure setups may benefit through reduced product development costs and time-to-market, as well as increased product and process innovation. Considering Munir et al. (2018b) 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 (Munir et al. 2018b), 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 (Van der Linden et al. 2009). 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.

5.2 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., (Wnuk et al. 2012; Van der Linden et al. 2009; Henkel 2006; 2008; West and Gallagher 2006; Iivari et al. 2008)). This risk was also explicitly recognized in the complexities CC3 and CC5. Selective revealing, as labeled by Henkel (2006), was a recognized practice in both CaseOrg1 and 2, as well as in Sony Mobile (Linåker et al. 2018).

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”Footnote 9. 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 (Van der Linden et al. 2009; Wnuk et al. 2012; Haruvy et al. 2008; Kort and Zaccour 2011; Caulkins et al. 2013; Linåker et al. 2018). 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 (Linåker et al. 2019a; Munir et al. 2018a), or within an industry through a new standard or platform (West and Gallagher 2006) (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 (Linåker et al. 2018; Ven and Mannaert 2008). 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 (Wnuk et al. 2012).

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., CC1-2, 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 (Linåker et al. 2019a; Schaarschmidt et al. 2015), or as a new community (Linåker et al. 2018). 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) (Munir et al. 2018a). 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 (Linåker et al. 2019a).

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 (Kilamo et al. 2012; West and O’Mahony 2005). How this is best done is, however, beyond the scope of this paper, and an interesting topic of further research.

6 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 (Runeson et al. 2012) of the objectives and complexities, the characteristics of these organizations need to be considered as they define the problem context (Wieringa 2014) 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 (Flyvbjerg 2007) 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 business-oriented 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. (2018b), 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 (Runeson et al. 2012). 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 (Wieringa 2014)), results from this study can then be extended to cases with similar characteristics within a similar context (Runeson et al. 2012). Both similarities and dissimilarities between the source and target cases should be thoroughly analyzed (Ghaisas et al. 2013). 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 A and A) 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 (Easterbrook et al. 2008) 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 (Runeson et al. 2012). Cross-case analysis (Seaman 1999) 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 (Runeson et al. 2012) 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 (Gorschek et al. 2006) or descriptive validation (Hevner et al. 2004) 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 (Wieringa 2014; Gorschek et al. 2006).

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 (Linåker et al. 2019a).

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.

7 Conclusions

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.