Contained InnerSource (#84)

(2017) Added pattern “Contained InnerSource Enables Collaborative Product Development” from Tim Yao (#12)
(2017) Rewrote and partially restructured pattern, triggered by Tim's comments
(2020) Moved to Initial and merging PR to share with a broader audience.  

Co-authored-by: NewMexicoKid <nmk@teiru.net>
Co-authored-by: Nick Yeates <nyeates1@umbc.edu>
Co-authored-by: Sebastian Spier <github@spier.hu>

Author: 4 people

README.md

@@ -73,6 +73,7 @@ The below lists all known patterns. They are grouped into three [maturity levels
 * [Assisted Compliance](patterns/1-initial/assisted_compliance.md) - *Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.*
 * [Open Source Trumps InnerSource](patterns/1-initial/open-source-trumps-innersource.md) - *Developers disregard InnerSource projects because they consider open source projects to be superior. Introducing a required evaluation of InnerSource projects before choosing an open source project increases the likelihood of the InnerSource projects to be adopted.*
 * [Transparent Governance Levels](patterns/1-initial/governance-levels.md) - *There are projects in multiple stages of InnerSource adoption. Contributors get confused when working with projects that are at different stages.*
+* [Contained InnerSource](patterns/1-initial/contained-innersource.md) - *Apply InnerSource methods to facilitate collaboration in a cross-divisional project but don't invest in soliciting contributions from outside of that project.*
 * [Good First Project](patterns/1-initial/good-first-project.md) - *An InnerSource program has been launched at an organization, and to get off to a successful start it requires some good first projects that lend themselves to InnerSource-style development. Assessing the InnerSource-readiness (fitness) of the candidate projects can help in selecting projects that have the potential to help demonstrate the power of InnerSource.*
 
 #### Donuts (needing a solution)

patterns/1-initial/contained-innersource.md

@@ -0,0 +1,49 @@
+## 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