| layout | title | nav_order | has_children | permalink |
|---|---|---|---|---|
default |
Open Source Contributions |
2 |
true |
/Contributions-3-1-Ind |
The business process of engaging in existing open source software projects can be set up in various ways and be subject to different governance models, depending on a company’s needs and capabilities. Regardless of if the decision is made through an ad hoc process or if it passes through a sophisticated setup (e.g. with an Open Source Program Office (OSPO)), the process should in the end lead to the following three cornerstones:
-
Purpose. A defined purpose for the specific contribution activity.
-
Suitability. A suitability assessment from relevant perspectives, based on the purpose.
-
Conscious decision. A conscious decision based on the above, including the allocation of adequate and suitable resources.
As described in module 2, there are many possible reasons for a company to engage in open source software development through contributions. When considering a specific contribution case, the task is essentially to identify which of these reasons apply to the case in question. In short: why make this contribution? If there is no obvious answer to that question, it is likely due to one out of two reasons:
-
The company is immature in the open source software business strategic dimension, lacking sufficient capabilities, structures and/or strategies to answer the question. See Module 2.
-
The contribution does not fit with the company strategy and is thereby questionable.
On the other hand, if there is an obvious business reason to engage in a particular open source software project, the question “why” will generally be relatively simple to answer and define.
For instance, the reason may be that the company is relying on a specific open source software component which has a declining community, and the company therefore wants to boost the continued engagement and redundance in the open source software project. Defining such a purpose will immediately uncover several aspects. To begin with, to truly boost engagement in the open source software project, it is unlikely that sporadic issue reports or the occasional suggestion of a bug fix will be enough to fulfil the purpose. Instead, it is likely that the company may need to engage continuously, also with more substantial types of contributions (see module 1) and even commit to assume roles higher up in the project hierarchy (see module 1).
When the question “why” is answered, the possibility to assess the contribution is significantly improved, both in terms of suitability and in terms of needed resources, engagement, timeframe, etc.
Large companies with mature open source development management organizations and a high volume of cases can often benefit from using standardized forms for contribution requests as part of the assessment process.