From 43a30defe827dfcf75a3d2614146711c299491ed Mon Sep 17 00:00:00 2001 From: Georg Gruetter Date: Mon, 5 Dec 2016 16:09:57 +0100 Subject: [PATCH 01/10] =?UTF-8?q?added=20pattern=20=E2=80=9CContained=20In?= =?UTF-8?q?nerSource=20Enables=20Collaborative=20Product=20Development?= =?UTF-8?q?=E2=80=9D=20from=20Tim=20Yao=20(#12)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...ables-collaborative-product-development.md | 35 +++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 contained-innersource-enables-collaborative-product-development.md diff --git a/contained-innersource-enables-collaborative-product-development.md b/contained-innersource-enables-collaborative-product-development.md new file mode 100644 index 000000000..0fe24f879 --- /dev/null +++ b/contained-innersource-enables-collaborative-product-development.md @@ -0,0 +1,35 @@ +## Title +Contained inner source enables collaborative product development + +## Context +* Multiple business units need a software component. +* It makes sense for the business units to collaborate; each needs some different changes to the code. +* One BU doesn't have the resources to do the development for all the rest. +* InnerSource programs and tools exist. + +## Problem +The company needs to develop a software product component; multiple business units use this component. + +## 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). + +## Sketch (optional) + +## Solution +The solution is for the participating BUs to each dedicate development resources to collaboratively add the features that each BU needs to the software component. InnerSource tools and some InnerSource processes are used, but the InnerSource cooperation is contained; there is no attempt to encourage open contribution from participants outside the core group of BUs that have entered into this arrangement. + +## Resulting Context +Product development is successfully completed. Inner sourcing in the classic sense isn't happening, so while the development cooperation that needs to occur happens, the full benefits from inner sourcing are not realized (e.g., exemplary documentation designed to promote further use of the component by others). + +## Rationale + + +## Known instances +* Large company + +## Status +* DRAFT pattern (in progress) + +## Author +* As told to Tim Yao + From d743f7f9ee80ef24dacabcab9839b1a627bf44ec Mon Sep 17 00:00:00 2001 From: NewMexicoKid Date: Wed, 7 Dec 2016 14:30:31 -0600 Subject: [PATCH 02/10] renamed file to contained-innersource.md; edited in revisions --- ...ables-collaborative-product-development.md | 35 ---------------- contained-innersource.md | 41 +++++++++++++++++++ 2 files changed, 41 insertions(+), 35 deletions(-) delete mode 100644 contained-innersource-enables-collaborative-product-development.md create mode 100644 contained-innersource.md diff --git a/contained-innersource-enables-collaborative-product-development.md b/contained-innersource-enables-collaborative-product-development.md deleted file mode 100644 index 0fe24f879..000000000 --- a/contained-innersource-enables-collaborative-product-development.md +++ /dev/null @@ -1,35 +0,0 @@ -## Title -Contained inner source enables collaborative product development - -## Context -* Multiple business units need a software component. -* It makes sense for the business units to collaborate; each needs some different changes to the code. -* One BU doesn't have the resources to do the development for all the rest. -* InnerSource programs and tools exist. - -## Problem -The company needs to develop a software product component; multiple business units use this component. - -## 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). - -## Sketch (optional) - -## Solution -The solution is for the participating BUs to each dedicate development resources to collaboratively add the features that each BU needs to the software component. InnerSource tools and some InnerSource processes are used, but the InnerSource cooperation is contained; there is no attempt to encourage open contribution from participants outside the core group of BUs that have entered into this arrangement. - -## Resulting Context -Product development is successfully completed. Inner sourcing in the classic sense isn't happening, so while the development cooperation that needs to occur happens, the full benefits from inner sourcing are not realized (e.g., exemplary documentation designed to promote further use of the component by others). - -## Rationale - - -## Known instances -* Large company - -## Status -* DRAFT pattern (in progress) - -## Author -* As told to Tim Yao - diff --git a/contained-innersource.md b/contained-innersource.md new file mode 100644 index 000000000..205f3b5f5 --- /dev/null +++ b/contained-innersource.md @@ -0,0 +1,41 @@ +## Title +Contained inner source enables collaborative product development + +## Context +* The company needs to develop a software product component; multiple business units use this component. +* Multiple business units need a software component. +* The business units (BUs) are in agreement that it makes sense for the BUs to collaborate; each needs some different changes to the code. +* One BU doesn't have the resources to do the development for all the rest. +* InnerSource programs and tools exist ("uncontained" InnerSource). + +## Problem +* The uncontained inner sourcing of the collaboration is regarded as distracting from the needed efficiency of specific collaborative development with the other BUs sharing the use of this component, but normal development practices do not effectively work with sharing of development resources to work on this component. + +## 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). +* Uncontained InnerSource has an effect on on collaborative product development: there is added effort for soliciting and managing contributions. In addition, uncontained InnerSource may have some effect on the ability to control the timeline for completion and deployment. + +## Sketch (optional) + +## Solution +The solution is for the participating BUs to each dedicate development resources to collaboratively add the features that each BU needs to the software component. InnerSource tools and some InnerSource processes are used, but the InnerSource cooperation is **contained**; there is no attempt to encourage open contribution from participants outside the core group of BUs that have entered into this arrangement. + +In some cases, the component source might be kept visible only to those BUs participating in its development, even though it uses InnerSource infrastructure and development processes. + +Uncontained InnerSource infrastructure and processes effectively allow and facilitate the development collaboration of multiple BUs where existing traditional development infrastructure and processes do not suffice. + +## Resulting Context +Product development is successfully completed. Inner sourcing in the classic sense isn't happening, so while the development cooperation that needs to occur happens, the full benefits from inner sourcing are not realized (e.g., exemplary documentation designed to promote further use of the component by others). + +## Rationale + + +## Known instances +* Large company + +## Status +* DRAFT pattern (in progress) + +## Author +* As told to Tim Yao + From 473639bb139a26ee87519cfdb311c4130c60d661 Mon Sep 17 00:00:00 2001 From: Nick Yeates Date: Thu, 15 Dec 2016 03:10:55 -0500 Subject: [PATCH 03/10] Simplified Title --- contained-innersource.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/contained-innersource.md b/contained-innersource.md index 205f3b5f5..40009f34c 100644 --- a/contained-innersource.md +++ b/contained-innersource.md @@ -1,5 +1,5 @@ ## Title -Contained inner source enables collaborative product development +Contained InnerSource ## Context * The company needs to develop a software product component; multiple business units use this component. @@ -15,8 +15,6 @@ Contained inner source enables collaborative product development * 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). * Uncontained InnerSource has an effect on on collaborative product development: there is added effort for soliciting and managing contributions. In addition, uncontained InnerSource may have some effect on the ability to control the timeline for completion and deployment. -## Sketch (optional) - ## Solution The solution is for the participating BUs to each dedicate development resources to collaboratively add the features that each BU needs to the software component. InnerSource tools and some InnerSource processes are used, but the InnerSource cooperation is **contained**; there is no attempt to encourage open contribution from participants outside the core group of BUs that have entered into this arrangement. From 05cc2fb2571d76bbd7d320a85d24483f93685bca Mon Sep 17 00:00:00 2001 From: Georg Gruetter Date: Fri, 1 Dec 2017 14:59:47 +0100 Subject: [PATCH 04/10] rewrote and partially restructured pattern, triggered by Tims comments --- contained-innersource.md | 65 +++++++++++++++++++++++++++++----------- 1 file changed, 48 insertions(+), 17 deletions(-) diff --git a/contained-innersource.md b/contained-innersource.md index 40009f34c..e14c31543 100644 --- a/contained-innersource.md +++ b/contained-innersource.md @@ -1,39 +1,70 @@ ## Title + Contained InnerSource -## Context -* The company needs to develop a software product component; multiple business units use this component. -* Multiple business units need a software component. -* The business units (BUs) are in agreement that it makes sense for the BUs to collaborate; each needs some different changes to the code. -* One BU doesn't have the resources to do the development for all the rest. -* InnerSource programs and tools exist ("uncontained" 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 -* The uncontained inner sourcing of the collaboration is regarded as distracting from the needed efficiency of specific collaborative development with the other BUs sharing the use of this component, but normal development practices do not effectively work with sharing of development resources to work on this component. + +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 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 (_Full Scale InnerSource_). ## 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). -* Uncontained InnerSource has an effect on on collaborative product development: there is added effort for soliciting and managing contributions. In addition, uncontained InnerSource may have some effect on the ability to control the timeline for completion and deployment. -## Solution -The solution is for the participating BUs to each dedicate development resources to collaboratively add the features that each BU needs to the software component. InnerSource tools and some InnerSource processes are used, but the InnerSource cooperation is **contained**; there is no attempt to encourage open contribution from participants outside the core group of BUs that have entered into this arrangement. +* 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 my have some effect on the ability to control the + timeline for completion and deployment. -In some cases, the component source might be kept visible only to those BUs participating in its development, even though it uses InnerSource infrastructure and development processes. +## Solution -Uncontained InnerSource infrastructure and processes effectively allow and facilitate the development collaboration of multiple BUs where existing traditional development infrastructure and processes do not suffice. +The BUs involved in the development of the new product each dedicate +development resources 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 +but is not required to share the developed artefacts outside of the project. ## Resulting Context -Product development is successfully completed. Inner sourcing in the classic sense isn't happening, so while the development cooperation that needs to occur happens, the full benefits from inner sourcing are not realized (e.g., exemplary documentation designed to promote further use of the component by others). -## Rationale +_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 projects success still lends credibility +to the concept of InnerSource. ## Known instances -* Large company +* Large Company ## Status * DRAFT pattern (in progress) ## Author -* As told to Tim Yao +* Tim Yao +* Georg Grütter From cab67eeaa37555f71014c550ffcf7d38b686245e Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 6 Feb 2021 17:23:27 +0100 Subject: [PATCH 05/10] move pattern to Initial --- README.md | 3 +++ .../1-initial/contained-innersource.md | 11 +++++------ 2 files changed, 8 insertions(+), 6 deletions(-) rename contained-innersource.md => patterns/1-initial/contained-innersource.md (95%) diff --git a/README.md b/README.md index dd7c9366c..c6d1d5921 100644 --- a/README.md +++ b/README.md @@ -73,6 +73,9 @@ 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.* #### Donuts (needing a solution) diff --git a/contained-innersource.md b/patterns/1-initial/contained-innersource.md similarity index 95% rename from contained-innersource.md rename to patterns/1-initial/contained-innersource.md index e14c31543..11cdbdcae 100644 --- a/contained-innersource.md +++ b/patterns/1-initial/contained-innersource.md @@ -14,7 +14,7 @@ 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. +detrimental for the required efficiency. ## Context @@ -22,7 +22,7 @@ detrimental for the required efficiency. business units 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. +* An InnerSource program and required tools exist. * The InnerSource program advocates using the full spectrum of InnerSource practices (_Full Scale InnerSource_). @@ -31,9 +31,9 @@ detrimental for the required efficiency. * 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 my have some effect on the ability to control the +* _Full scale InnerSource_ includes substantial effort for soliciting and + managing contributions as well as onboarding new contributors, which is + hard to plan for and my have some effect on the ability to control the timeline for completion and deployment. ## Solution @@ -67,4 +67,3 @@ to the concept of InnerSource. ## Author * Tim Yao * Georg Grütter - From 864bd7183bd4a585b3f6c59d5a994ede964c7bba Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 6 Feb 2021 17:24:05 +0100 Subject: [PATCH 06/10] Fixing linter issues --- patterns/1-initial/contained-innersource.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/patterns/1-initial/contained-innersource.md b/patterns/1-initial/contained-innersource.md index 11cdbdcae..5b0e8d000 100644 --- a/patterns/1-initial/contained-innersource.md +++ b/patterns/1-initial/contained-innersource.md @@ -4,7 +4,7 @@ Contained InnerSource ## Patlet -Apply InnerSource methods to facilitate collaboration in a cross divisional +Apply InnerSource methods to facilitate collaboration in a cross divisional project but don't invest in soliciting contributions from outside of that project. @@ -58,12 +58,15 @@ practices, such as exemplary documentation which facilitates reuse beyond the project context, are not realized, the projects success still lends credibility to the concept of InnerSource. -## Known instances +## Known Instances + * Large Company ## Status -* DRAFT pattern (in progress) + +* Initial ## Author + * Tim Yao * Georg Grütter From 1109497302f0fa542f46c5b651fb8be83823c871 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 6 Feb 2021 22:44:09 +0100 Subject: [PATCH 07/10] remove linebreak that would break the formatting once release in gitbook --- patterns/1-initial/contained-innersource.md | 49 ++++++--------------- 1 file changed, 13 insertions(+), 36 deletions(-) diff --git a/patterns/1-initial/contained-innersource.md b/patterns/1-initial/contained-innersource.md index 5b0e8d000..0e00652e4 100644 --- a/patterns/1-initial/contained-innersource.md +++ b/patterns/1-initial/contained-innersource.md @@ -4,59 +4,36 @@ 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. +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. +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 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. +* 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 (_Full Scale InnerSource_). +* 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 my have some effect on the ability to control the - timeline for completion and deployment. +* 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 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 -but is not required to share the developed artefacts outside of the project. +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 but is not required to share the developed artefacts outside of the project. ## 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 projects success still lends credibility -to the concept of InnerSource. +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 projects success still lends credibility to the concept of InnerSource. ## Known Instances From adc77310c2811efeeb939abd2b2ef098ad444879 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 6 Feb 2021 22:52:48 +0100 Subject: [PATCH 08/10] work in further feedback --- patterns/1-initial/contained-innersource.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/patterns/1-initial/contained-innersource.md b/patterns/1-initial/contained-innersource.md index 0e00652e4..30e662a14 100644 --- a/patterns/1-initial/contained-innersource.md +++ b/patterns/1-initial/contained-innersource.md @@ -26,14 +26,14 @@ Traditional development practices do not work as effectively for cross divisiona 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 but is not required to share the developed artefacts 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 projects success still lends credibility to the concept of InnerSource. +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 From 2820128660d10536c8d8b70fc97c9a3f082aea60 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 6 Feb 2021 22:53:43 +0100 Subject: [PATCH 09/10] remove linebreaks in patlet --- README.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/README.md b/README.md index c6d1d5921..fd2f68742 100644 --- a/README.md +++ b/README.md @@ -73,9 +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.* +* [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.* #### Donuts (needing a solution) From 20f712da5bb76e036eb3638010505f46c3eafde8 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 13 Feb 2021 09:54:02 +0100 Subject: [PATCH 10/10] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 66e762211..d6ef85a42 100644 --- a/README.md +++ b/README.md @@ -73,7 +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.* +* [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)