What to share as open source, and when?

What should you share as open source, and when?

In this post I’m going to present a decision-support process to help answer the question what you should share and contribute as open source, and when. This process is a product of a joint research collaboration between our research group at Lund University together with the Open Source Program office at Sony Mobile in Lund, Sweden. The full paper is available as open access (Linåker, Munir, Wnuk, & Mols, 2018) and free to download. The scope of this post will be limited to describing the process, while future posts will provide in-depth examples.

Why share something as open source?

The incentives for why a company would want to share their software as open source can be many. For example, sharing a solution implies sharing the maintenance and feature development of it which allows for cost cuts and a more value-focused internal development. Improved time-to-market is another positive consequence, which may be further reduced as the need for internal patches is diminished. Also, sharing internal solutions may impose advantage over the competition by providing a time-limited monopoly and forcing them to adapt through the commoditization and standardization of the solutions.

Considering the pros and cons

However, sharing everything with everyone is be a topic of debate which this post aims to address. We argue that contributions should be made with the right purpose in the right places, connecting to the business incentives specific to a company. A risk otherwise is that differentiating intellectual property (IP) could end up in the hands of competition, or even create new ones. Also, on the other hand, companies that introduce control and do not consider the business motivations may risk blocking otherwise motivated contributions due to compliance, defensive IP portfolios, and lack of knowledge of the potential value creation.

This leads us to the question - What should you share as open source and contribute, and when?

The Contribution Acceptance Process

To answer this question we designed a Contribution Acceptance Process (CAP) in close collaboration with the Open Source Program office at Sony Mobile. In this process, a company can classify software artifacts, (e.g., software projects, features or components) according to the artifact’s business impact, control complexity, and the related community strategy and objectives. A decision can then be made in regard to if, what, when, how, and to whom the artifact to should be contributed in what we call a contribution strategy. Contributions and community engagement should be performed and made for the right reasons and align with a company’s internal business and product strategies.

Commoditization curve

CAP is based on the concept of commoditization and how a feature moves from a differentiating state to becoming a commodity and standard technology which can be easily acquired or created by others. As this is a temporal factor, CAP should be applied iteratively over time as the technology life-cycle of the software artifacts progresses.

The Contribution Acceptance Process Model Proactive vs. Reactive usage

We make a distinction between how CAP can be used either proactively or reactively. In the former case, we refer to the classification of a portfolio of software artifacts as part of the product planning process. In the latter case, we refer to the possibility to react to incoming contribution and engagement requests from the development organization for example. The process should preferably be performed and maintained by a cross-functional team, and headed by the company’s product management and/or Open Source Progam office.

So, how does it work?

CAP takes use of an adapted version of Peter Kraljic’s sourcing model (Kraljic, 1983) which was originally used by manufacturing companies to create procurement strategies towards their suppliers.

This model (explained in more detail below) is the main tool in CAP that allows software artifacts to be classified and assigned a contribution strategy. Around this model, CAP consists of five steps.

1. Scope and abstraction

The Contribution Acceptance Process step 1

The first step is to decide on the scope and abstraction of the software artifacts. An example scope could be a certain product or a functional area of such. Like a certain phone model or area such as telephony. An abstraction level could be features related to telephony-functionality.

2. Artifact classification

The Contribution Acceptance Process step 2

In the second step, these artifacts are classified according to their business impact and control complexity.

Business Impact of the artifact

Business impact concerns how the artifact relates to the company’s business model (no, there is no open source business model). In Sony mobile’s case, OSS is embedded in devices that are then sold to operators and consumers. In Red Hat’s case, they offer support and subscriptions to stable and secure versions of OSS. In Cloudera’s case, they package many different OSS into a product with closed enterprise layerings on top, and sell it as their own distribution. In Comcast Cable’s case, they use OSS to build and maintain the infrastructure with which they deliver their Cable and ISP services. In Google’s case, they use OSS as a mean to collect data and sells custom ads.

All these are just a few examples of how OSS can be related to the core value proposition of a company’s business model, some more direct than others. Questions that may be asked by the company regarding the artifact include:

  • How does the artifact impact on the firm’s profit and revenue?
  • How does the artifact impact on the customer and end-user value?
  • How does the artifact impact on the product differentiation?
  • How does the artifact impact on the access to leading technology/trends?
  • How does the artifact impact if there are difficulties or shortages?

Control Complexity of the artifact

The second aspects we mentioned, control complexity, regards how hard the artifact is to acquire and control. We’ve added the word complexity as it is not just a question about how much control you may need of the artifact’s development and roadmap (e.g., considering patents and market requirements), but also how a question about its availability. If the technology/knowledge is standard and there are alternative solutions available, these maybe should be considered as options in a make-buy-share decision. To help break down the control complexity, questions as those that follow may be used:

  • Do we have knowledge and capacity to absorb the technology?
  • Are there technology availability barriers and IPR constraints?
  • What is the level of innovativeness and novelty?
  • Is there a lack of alternatives?
  • Are there limitations or constraints by the firm?

The Contribution Acceptance Process artifact classification

To address these questions, a cross-functional team should be assembled and use open consensus-seeking discussions to gather everyone’s view. Open Source Governance boards or Advisory councils (usually facilitated in a company’s Open Source Program) are usually a suitable place for these discussions. By classifying an artifact, it will help the group to map the artifact onto the matrix, and put it into one of four quadrants, each proposing a specific contribution strategy for the artifact.

3. Contribution strategy

The Contribution Acceptance Process step 3

In the third step, we consider and discuss the contribution strategy that is proposed for the artifact, based on the classifications. The artifact should be discussed in relation to the strategy and may render in a potential adjustment of the business impact and control complexity classifications. The borders should not be seen as strict, as there can very well be overlaps. The four different contribution strategies should rather be viewed as reference points that can help the company agree on a custom contribution strategy for an artifact.

The Contribution Acceptance Process contribution strategy

  • Strategic/Differentiating artifacts have a high business impact and control complexity. These parts generally have a differential value and a competitive edge for the company (aka. its secret sauce/glaze). Differentiating vs. Commodity Differentiating parts should be guarded and kept internal, or when possible, shared in strategic alliances and tightly controlled joint-ventures. Apart from that, enablers and qualifiers should be contributed as openly and fast as possible to avoid competing solutions being adopted by the community. In regard to the related community, it is motivated to maintain a large degree of influence and general investment in order to be able to affect the development and road-map of the artifact. If existing community doesn’t suit, creating a new one should be considered. To give you an example of a strategic artifact, for Sony Mobile, certain camera functionality is what can be a differentiator for customers choosing between them and competing firms. But the media frameworks that enable Sony Mobile’s unique feature to function should be contributed.

  • Standard/Commodity artifacts which are placed in the bottom-left corner, has a low business impact and control complexity. These provide little or no advantage, do not require a certain level of control and can be easily acquired by anyone, hence considered a commodity and should, therefore, be contributed. For Sony Mobile, an example could be software that enables to screen to light up or the power outlet to function. The technology does not have to be mastered by the company as it’s roadmap is aligned with expectations. The overall goal should be to decrease maintenance and stick to standard solutions, avoiding unnecessary forks and creation of new communities.

  • Product/Bottleneck artifacts are those that do not bring much business impact to the company, but needs to be there. These can be special requirements from customers why they may not be contributable to a community but rather to a smaller number of commons. For Sony Mobile, this could regard certain operator requirements, needed to be fulfilled in order for the phones to be ranged. These operator requirements may not be in line with Google’s view on Android, but could be a common pain for other hand-set manufacturers who share the same operator as a customer. The overall goal should be to secure the supply of the technology and artifact, while maintaining control and opening up for collaboration as far as possible.

  • Platform/Leverage artifacts has a high business impact but a low control complexity. They offer an opportunity for the company and are easy to acquire, potentially from multiple sources with low switching costs. Everything should be contributed as there is no specific need for control. If there are proprietary solutions available that could be considered cheaper than OSS, these could be preferred in a make-buy-share decision. For Sony Mobile, an example could Voice over LTE (4G). In the time (approx. 2015) this is had a high business impact for them, but there were many implementations available so there was no need for Sony to create their own, but rather adopt an existing and contribute what is required. Overall goal should be to maximize the innovation and drive towards a standardized solution, why creating new communities should be avoided when possible.

4. Contribution strategy tuning

The Contribution Acceptance Process step 4

In the fourth step, the chosen contribution strategy for the artifact can be tuned and adjusted according to the related community strategy. The community strategy describes how important a community is to a company, what the goals are for the company’s engagement, and how they aim to reach these goals through their engagement.

Considering the related Community Strategy

How to construct a community strategy is itself an own blog post, but here I’ll give an overview of how it connects and affects the choice of contribution strategy.

As with the artifact, the community and its project need to be valued and classified in relation to the company. Four dimensions to consider include:

  • Business impact of that project and its community, i.e., how do they relate and affect to the company’s business model. A high business impact may warrant a quick contribution to avoid unnecessary maintenance, and to avoid competing solutions to gain community acceptance.
  • Technical impact considers issues such as what dependencies there are between the OSS project and internal integrations, as well as how well release planning and roadmaps align. As with business impact, when there is a high technical impact, a quick contribution may be warranted.
  • Stakeholders population includes anyone (person or organization) who influences the OSS project’s requirements or who is impacted by the project. I.e., primarily the members of the related community. Knowledge about who they are and what agendas they have can provide valuable input. E.g., presence of competitors among the stakeholders may impact on what is considered commodity and differentiating, while presence of potential partners could provide opportunity, either for community or direct collaboration.
  • Sustainability and health of the OSS project and its community include many factor and cannot be boiled down to any single number. Things to consider include the number of maintainers and active contributors, as well as general activity and size of the community. Would it still survive without your involvement? Would your contribution make a difference?

Given these dimensions, the company should also consider the goals that they have set up for their community engagement. If a contribution would help them in reaching these goals, the contribution would be motivated.

5. Communication and follow-up

The Contribution Acceptance Process step 5

Once adjusted, the contribution strategy for the concerned artifact can be documented and communicated to the development organization for execution. To enable this, but also the possibility to follow-up and update the contribution strategy for an artifact, there needs to be an infrastructure in place that allows this traceability.

The Contribution Acceptance Process information meta-model

For Sony Mobile, we proposed an information meta-model in their existing requirements management infrastructure that allows components and features to be traced from products, down to commits, and patches that have been contributed.

Summary

Whether to share something as open source or not is a question with many ways to address and answer. Some companies may have it in their DNA to contribute with an upstream-first policy. Others may be unaware if and how they do it, or be reluctant to open source because they see risks concerning compliance and losing a competitive edge. We believe that contributions is an important aspect besides pure consumption and compliance, and that it should be done for the right reasons in the right places, aligning with a firm’s business and product strategies.

This post and related research provides one angle to the question of the what and when, but should not be seen as a definitive solution. Research on CAP’s validity is ongoing with further case studies outside Sony Mobile. If you are interested in more information about CAP, our research, or anything related, comment below, ping me on twitter or drop a mail! I will return to CAP in future posts.

References

  1. Linåker, J., Munir, H., Wnuk, K., & Mols, C. E. (2018). Motivating the contributions: An Open Innovation perspective on what to share as Open Source Software. Journal of Systems and Software, 135, 17–36.
  2. Kraljic, P. (1983). Purchasing must become supply management. Harvard Business Review, 61(5), 109–117.