## Title  

Contained InnerSource

## Patlet

Apply InnerSource methods to facilitate collaboration in a cross divisional project but don't invest in soliciting contributions from outside of that project.

## Problem  

Traditional development practices do not work as effectively for cross divisional projects as do InnerSource style practices. However, Management does not support adopting InnerSource practices because it regards efforts for soliciting and facilitating contributions from outside of the project as detrimental for the required efficiency.

## Context

* The company plans to develop a new software-intensive product; multiple business units (BUs) are involved in the development of this product
* There is not one single BU which has the required resources or knowledge to do the development on its own.
* An InnerSource program and required tools exist.
* The InnerSource program advocates using the full spectrum of InnerSource practices (we call this _Full Scale InnerSource_ for the purposes of this pattern).

## Forces  

* The product's importance to company revenue and the committed feature content and dates require a development paradigm that provides known, stable development resources (headcount).
* _Full Scale InnerSource_ includes substantial effort for soliciting and managing contributions as well as onboarding new contributors, which is hard to plan for and may have some effect on the ability to control the timeline for completion and deployment.

## Solution

The BUs involved in the development of the new product each dedicate development resources to develop the new product, apply the InnerSource working model and adopt InnerSource tooling to facilitate collaborative development but limit the scope of InnerSource practices to the project. No effort will be spent on facilitating and managing contributions from outside of the project.

The application of InnerSource is _contained_ to the project. The project may share the developed artifacts outside the project but is not required to do so.

## Resulting Context

_Contained InnerSource_ effectively allows and facilitates the
development collaboration of multiple BUs where existing traditional development infrastructure and processes would not have worked efficiently.

Product development can be successfully completed. Even though _Full Scale InnerSource_ was not implemented and the full benefits from InnerSource practices, such as exemplary documentation which facilitates reuse beyond the project context, are not realized, the project's success still achieves several benefits that wouldn't have been possible through traditional development. In addition, it lends credibility to the concept of InnerSource.

## Known Instances

* Large Company

## Status  

* Initial

## Author

* Tim Yao
* Georg Grütter
