What to share, when, and where: balancing the objectives and complexities of open source software contributions

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.

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

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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.

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.

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 objectives⁸. 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.

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”⁹. 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.