From 0c65e693309bd8acf7f1d7ea0e7b81996eb2f6d0 Mon Sep 17 00:00:00 2001 From: Clare Dillon <32961070+claredillon@users.noreply.github.com> Date: Sat, 18 Dec 2021 07:17:10 +0000 Subject: [PATCH 01/28] Create transitioning-contractor-code-to-InnerSource-model Taken from https://github.com/InnerSourceCommons/InnerSourcePatterns/issues/375 --- ...oning-contractor-code-to-InnerSource-model | 59 +++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 patterns/1-initial/transitioning-contractor-code-to-InnerSource-model diff --git a/patterns/1-initial/transitioning-contractor-code-to-InnerSource-model b/patterns/1-initial/transitioning-contractor-code-to-InnerSource-model new file mode 100644 index 000000000..8d6afab5f --- /dev/null +++ b/patterns/1-initial/transitioning-contractor-code-to-InnerSource-model @@ -0,0 +1,59 @@ +## Title +Transitioning Contractor Code to InnerSource Model + +## Patlet +Contract developers are often not motivated to engage in InnerSource activities, which may be beyond the scope of their contract. This patlet describes how you can focus on transitioning the contractor project after the fact to an InnerSource project. + +## Problem +Contractor developers are often not motivated (through forces described below) to not engage in InnerSource activities. Once delivered, and even if the code is made visible, their projects are often less likely to be part of successful InnerSourced engagements. + +## Context +This problem exists where an organization either: +- out-sources the development of a well defined project or +- engagages external firms for staff augmentation and has mixed teams of permanent employees with a large percentage of contract staff. This issue may occur less often in a mixed team where InnerSource principles and ways of working are already established within the organization, but the forces described below are still often at play. + +## Forces +Contractor Motivation and Constraints:- +- Often contracts with third-party developers are very focused on delivering an end result in the fastest possible fashion. As a result, all InnerSource activities (e.g. responding to third-party PRs) are considered to be distractions or something that will “slow down” ultimate delivery. +- There is also often a concern that accepting code from other parts of the business might introduce security risks, scope creep or other issues that would subsequently have to be resolved by the contract team. +- Above and beyond the idea that InnerSource may slow down the project, there is often an additional concern that accepting PRs from other parts of the company may “muddy the waters” when it comes to assessing what parts of the project were completed/delivered by the contracted developers. + +All of the above can mean that even if an individual contract developer wants to engage in InnerSource, there are system-level constraints pushing them not to. + +It should be noted that the above scenario is indirectly impacted by: +- The norms around defining Statements of Work for third party contractors +- Pressures to reduce contractor costs during procurement +- Ability to tie contributions to payment at a granular level. + +It could also be noted that the Contractor motivations in this instance is almost like a more extreme instance of the oft-reported organizational/budgetary constraints that might exist for some internal business units. (Not sure if this is relevant, but it does seem to be an extreme case of what is reported as common objections even in internal teams). + +## Solutions +At the outset of the project, clearly define: +- That the code will be made visible by default. +- How the project will be transitioned to an InnerSource project. (Zack can add more explicit details here) + +It is noted that this practice can work very well where there is a high trust relationship between the contracting team and the contractors. Perhaps they have worked closely together before, or have a pre-existing relationship. Further patterns that explore how to build trust between teams might enhance this pattern. + +## Resulting Context +This particular pattern does not attempt to change the initial behavior of the contract development team (in terms of their potential lack of engagement with the InnerSource process). However, the end result is that the project does become part of the InnerSourced projects for the company after the fact. + +## Known Instances (optional) +GitHub has seen this approach work with their government customers. Zack Koppert can add details as appropriate. + +## Status (optional until merging) +TBD + +## Author(s) (optional) +Clare Dillon (v.0 assuming others will add themselves in this section as we flesh it out). + +## Acknowledgements (optional) +Particular thanks to Zack Koppert for sharing his experiences in this area and to Gil Yehuda for raising the issue in the InnerSource Slack channel. + +This pattern was extracted from a conversation on the topic held with the following folks: +- Brittany Istenes +- Clare Dillon +- Cristina Coffey +- Derek Murawsky +- Gil Yehuda +- Zack Koppert + From c165cbfdfe5743970421b5cdbbc418e1c1587568 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 18 Dec 2021 10:28:21 +0100 Subject: [PATCH 02/28] Renaming file to .md --- ...odel => transitioning-contractor-code-to-InnerSource-model.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename patterns/1-initial/{transitioning-contractor-code-to-InnerSource-model => transitioning-contractor-code-to-InnerSource-model.md} (100%) diff --git a/patterns/1-initial/transitioning-contractor-code-to-InnerSource-model b/patterns/1-initial/transitioning-contractor-code-to-InnerSource-model.md similarity index 100% rename from patterns/1-initial/transitioning-contractor-code-to-InnerSource-model rename to patterns/1-initial/transitioning-contractor-code-to-InnerSource-model.md From 8ea750ed678d128639bd56f8ac63714fa0ebd2db Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 18 Dec 2021 10:32:46 +0100 Subject: [PATCH 03/28] Changing caps in filename + Fixing some spacing --- ...ng-contractor-code-to-innersource-model.md} | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) rename patterns/1-initial/{transitioning-contractor-code-to-InnerSource-model.md => transitioning-contractor-code-to-innersource-model.md} (98%) diff --git a/patterns/1-initial/transitioning-contractor-code-to-InnerSource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md similarity index 98% rename from patterns/1-initial/transitioning-contractor-code-to-InnerSource-model.md rename to patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 8d6afab5f..1102e7732 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-InnerSource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -1,19 +1,26 @@ ## Title + Transitioning Contractor Code to InnerSource Model ## Patlet + Contract developers are often not motivated to engage in InnerSource activities, which may be beyond the scope of their contract. This patlet describes how you can focus on transitioning the contractor project after the fact to an InnerSource project. ## Problem + Contractor developers are often not motivated (through forces described below) to not engage in InnerSource activities. Once delivered, and even if the code is made visible, their projects are often less likely to be part of successful InnerSourced engagements. ## Context + This problem exists where an organization either: + - out-sources the development of a well defined project or - engagages external firms for staff augmentation and has mixed teams of permanent employees with a large percentage of contract staff. This issue may occur less often in a mixed team where InnerSource principles and ways of working are already established within the organization, but the forces described below are still often at play. ## Forces -Contractor Motivation and Constraints:- + +Contractor Motivation and Constraints: + - Often contracts with third-party developers are very focused on delivering an end result in the fastest possible fashion. As a result, all InnerSource activities (e.g. responding to third-party PRs) are considered to be distractions or something that will “slow down” ultimate delivery. - There is also often a concern that accepting code from other parts of the business might introduce security risks, scope creep or other issues that would subsequently have to be resolved by the contract team. - Above and beyond the idea that InnerSource may slow down the project, there is often an additional concern that accepting PRs from other parts of the company may “muddy the waters” when it comes to assessing what parts of the project were completed/delivered by the contracted developers. @@ -21,6 +28,7 @@ Contractor Motivation and Constraints:- All of the above can mean that even if an individual contract developer wants to engage in InnerSource, there are system-level constraints pushing them not to. It should be noted that the above scenario is indirectly impacted by: + - The norms around defining Statements of Work for third party contractors - Pressures to reduce contractor costs during procurement - Ability to tie contributions to payment at a granular level. @@ -28,28 +36,36 @@ It should be noted that the above scenario is indirectly impacted by: It could also be noted that the Contractor motivations in this instance is almost like a more extreme instance of the oft-reported organizational/budgetary constraints that might exist for some internal business units. (Not sure if this is relevant, but it does seem to be an extreme case of what is reported as common objections even in internal teams). ## Solutions + At the outset of the project, clearly define: + - That the code will be made visible by default. - How the project will be transitioned to an InnerSource project. (Zack can add more explicit details here) It is noted that this practice can work very well where there is a high trust relationship between the contracting team and the contractors. Perhaps they have worked closely together before, or have a pre-existing relationship. Further patterns that explore how to build trust between teams might enhance this pattern. ## Resulting Context + This particular pattern does not attempt to change the initial behavior of the contract development team (in terms of their potential lack of engagement with the InnerSource process). However, the end result is that the project does become part of the InnerSourced projects for the company after the fact. ## Known Instances (optional) + GitHub has seen this approach work with their government customers. Zack Koppert can add details as appropriate. ## Status (optional until merging) + TBD ## Author(s) (optional) + Clare Dillon (v.0 assuming others will add themselves in this section as we flesh it out). ## Acknowledgements (optional) + Particular thanks to Zack Koppert for sharing his experiences in this area and to Gil Yehuda for raising the issue in the InnerSource Slack channel. This pattern was extracted from a conversation on the topic held with the following folks: + - Brittany Istenes - Clare Dillon - Cristina Coffey From 17791fa4a4de912e5b004e6fb7726e300b616ebd Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 18 Dec 2021 10:40:53 +0100 Subject: [PATCH 04/28] Removing some trailing spaces --- ...ng-contractor-code-to-innersource-model.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 1102e7732..055a6c298 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -8,22 +8,22 @@ Contract developers are often not motivated to engage in InnerSource activities, ## Problem -Contractor developers are often not motivated (through forces described below) to not engage in InnerSource activities. Once delivered, and even if the code is made visible, their projects are often less likely to be part of successful InnerSourced engagements. +Contractor developers are often not motivated (through forces described below) to not engage in InnerSource activities. Once delivered, and even if the code is made visible, their projects are often less likely to be part of successful InnerSourced engagements. ## Context This problem exists where an organization either: -- out-sources the development of a well defined project or +- out-sources the development of a well defined project or - engagages external firms for staff augmentation and has mixed teams of permanent employees with a large percentage of contract staff. This issue may occur less often in a mixed team where InnerSource principles and ways of working are already established within the organization, but the forces described below are still often at play. ## Forces -Contractor Motivation and Constraints: +Contractor Motivation and Constraints: -- Often contracts with third-party developers are very focused on delivering an end result in the fastest possible fashion. As a result, all InnerSource activities (e.g. responding to third-party PRs) are considered to be distractions or something that will “slow down” ultimate delivery. +- Often contracts with third-party developers are very focused on delivering an end result in the fastest possible fashion. As a result, all InnerSource activities (e.g. responding to third-party PRs) are considered to be distractions or something that will “slow down” ultimate delivery. - There is also often a concern that accepting code from other parts of the business might introduce security risks, scope creep or other issues that would subsequently have to be resolved by the contract team. -- Above and beyond the idea that InnerSource may slow down the project, there is often an additional concern that accepting PRs from other parts of the company may “muddy the waters” when it comes to assessing what parts of the project were completed/delivered by the contracted developers. +- Above and beyond the idea that InnerSource may slow down the project, there is often an additional concern that accepting PRs from other parts of the company may “muddy the waters” when it comes to assessing what parts of the project were completed/delivered by the contracted developers. All of the above can mean that even if an individual contract developer wants to engage in InnerSource, there are system-level constraints pushing them not to. @@ -31,22 +31,22 @@ It should be noted that the above scenario is indirectly impacted by: - The norms around defining Statements of Work for third party contractors - Pressures to reduce contractor costs during procurement -- Ability to tie contributions to payment at a granular level. +- Ability to tie contributions to payment at a granular level. -It could also be noted that the Contractor motivations in this instance is almost like a more extreme instance of the oft-reported organizational/budgetary constraints that might exist for some internal business units. (Not sure if this is relevant, but it does seem to be an extreme case of what is reported as common objections even in internal teams). +It could also be noted that the Contractor motivations in this instance is almost like a more extreme instance of the oft-reported organizational/budgetary constraints that might exist for some internal business units. (Not sure if this is relevant, but it does seem to be an extreme case of what is reported as common objections even in internal teams). ## Solutions At the outset of the project, clearly define: -- That the code will be made visible by default. -- How the project will be transitioned to an InnerSource project. (Zack can add more explicit details here) +- That the code will be made visible by default. +- How the project will be transitioned to an InnerSource project. (Zack can add more explicit details here) It is noted that this practice can work very well where there is a high trust relationship between the contracting team and the contractors. Perhaps they have worked closely together before, or have a pre-existing relationship. Further patterns that explore how to build trust between teams might enhance this pattern. ## Resulting Context -This particular pattern does not attempt to change the initial behavior of the contract development team (in terms of their potential lack of engagement with the InnerSource process). However, the end result is that the project does become part of the InnerSourced projects for the company after the fact. +This particular pattern does not attempt to change the initial behavior of the contract development team (in terms of their potential lack of engagement with the InnerSource process). However, the end result is that the project does become part of the InnerSourced projects for the company after the fact. ## Known Instances (optional) @@ -62,7 +62,7 @@ Clare Dillon (v.0 assuming others will add themselves in this section as we fles ## Acknowledgements (optional) -Particular thanks to Zack Koppert for sharing his experiences in this area and to Gil Yehuda for raising the issue in the InnerSource Slack channel. +Particular thanks to Zack Koppert for sharing his experiences in this area and to Gil Yehuda for raising the issue in the InnerSource Slack channel. This pattern was extracted from a conversation on the topic held with the following folks: From c7d924b6f1e4864af7492d20da37c5c13fb9c13f Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Mon, 20 Dec 2021 08:23:36 +0100 Subject: [PATCH 05/28] Fix spelling of Contractor Co-authored-by: Zack Koppert --- .../transitioning-contractor-code-to-innersource-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 055a6c298..5ceef61f2 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -33,7 +33,7 @@ It should be noted that the above scenario is indirectly impacted by: - Pressures to reduce contractor costs during procurement - Ability to tie contributions to payment at a granular level. -It could also be noted that the Contractor motivations in this instance is almost like a more extreme instance of the oft-reported organizational/budgetary constraints that might exist for some internal business units. (Not sure if this is relevant, but it does seem to be an extreme case of what is reported as common objections even in internal teams). +It could also be noted that the contractor motivations in this instance is almost like a more extreme instance of the oft-reported organizational/budgetary constraints that might exist for some internal business units. (Not sure if this is relevant, but it does seem to be an extreme case of what is reported as common objections even in internal teams). ## Solutions From 2949d13bffb995e423940267eb8c1adb9ee1567a Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Mon, 20 Dec 2021 08:24:31 +0100 Subject: [PATCH 06/28] Adding details about Known Instance Co-authored-by: Zack Koppert --- .../transitioning-contractor-code-to-innersource-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 5ceef61f2..69b33526b 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -50,7 +50,7 @@ This particular pattern does not attempt to change the initial behavior of the c ## Known Instances (optional) -GitHub has seen this approach work with their government customers. Zack Koppert can add details as appropriate. +GitHub has seen this approach work with their US government agency customers. ## Status (optional until merging) From c908382f661d1951632409c2760e3528d528f036 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Mon, 20 Dec 2021 08:25:35 +0100 Subject: [PATCH 07/28] Removing "optional" --- .../transitioning-contractor-code-to-innersource-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 69b33526b..00711311d 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -48,7 +48,7 @@ It is noted that this practice can work very well where there is a high trust re This particular pattern does not attempt to change the initial behavior of the contract development team (in terms of their potential lack of engagement with the InnerSource process). However, the end result is that the project does become part of the InnerSourced projects for the company after the fact. -## Known Instances (optional) +## Known Instances GitHub has seen this approach work with their US government agency customers. From be3807c0c72f9db59ac661e6ca11528fa7d9ff0c Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Mon, 20 Dec 2021 08:25:43 +0100 Subject: [PATCH 08/28] Removing "optional" --- .../transitioning-contractor-code-to-innersource-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 00711311d..6af091c61 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -60,7 +60,7 @@ TBD Clare Dillon (v.0 assuming others will add themselves in this section as we flesh it out). -## Acknowledgements (optional) +## Acknowledgements Particular thanks to Zack Koppert for sharing his experiences in this area and to Gil Yehuda for raising the issue in the InnerSource Slack channel. From dd34d96a0b60193bb830bdbec0b07dd89b639bde Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Mon, 20 Dec 2021 08:25:53 +0100 Subject: [PATCH 09/28] Removing "optional" --- .../transitioning-contractor-code-to-innersource-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 6af091c61..bbdcd1b15 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -56,7 +56,7 @@ GitHub has seen this approach work with their US government agency customers. TBD -## Author(s) (optional) +## Author(s) Clare Dillon (v.0 assuming others will add themselves in this section as we flesh it out). From 1e744bf6942c505fc11a8af1e9e4f818948390f1 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Mon, 20 Dec 2021 08:26:18 +0100 Subject: [PATCH 10/28] Adding Zack as author Co-authored-by: Zack Koppert --- .../transitioning-contractor-code-to-innersource-model.md | 1 + 1 file changed, 1 insertion(+) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index bbdcd1b15..3793af018 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -59,6 +59,7 @@ TBD ## Author(s) Clare Dillon (v.0 assuming others will add themselves in this section as we flesh it out). +Zack Koppert ## Acknowledgements From 0d93fbd8907a6b2e2d55870b6514f0a76fddffd8 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Mon, 20 Dec 2021 08:27:21 +0100 Subject: [PATCH 11/28] Adding list formatting for Authors section --- .../transitioning-contractor-code-to-innersource-model.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 3793af018..77ddc04d4 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -58,8 +58,8 @@ TBD ## Author(s) -Clare Dillon (v.0 assuming others will add themselves in this section as we flesh it out). -Zack Koppert +- Clare Dillon (v.0 assuming others will add themselves in this section as we flesh it out). +- Zack Koppert ## Acknowledgements From d88b7322cf9871a043e6bbd853423de7ddb0771f Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Mon, 20 Dec 2021 08:33:07 +0100 Subject: [PATCH 12/28] Fixing linter issue --- .../transitioning-contractor-code-to-innersource-model.md | 1 - 1 file changed, 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 77ddc04d4..d3a16575f 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -73,4 +73,3 @@ This pattern was extracted from a conversation on the topic held with the follow - Derek Murawsky - Gil Yehuda - Zack Koppert - From c9976bcf7fe889825449de93af31b5803e2201a2 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Fri, 7 Jan 2022 10:50:08 +0100 Subject: [PATCH 13/28] Adding further Forces Co-authored-by: Zack Koppert --- .../transitioning-contractor-code-to-innersource-model.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index d3a16575f..6b06be401 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -24,6 +24,8 @@ Contractor Motivation and Constraints: - Often contracts with third-party developers are very focused on delivering an end result in the fastest possible fashion. As a result, all InnerSource activities (e.g. responding to third-party PRs) are considered to be distractions or something that will “slow down” ultimate delivery. - There is also often a concern that accepting code from other parts of the business might introduce security risks, scope creep or other issues that would subsequently have to be resolved by the contract team. - Above and beyond the idea that InnerSource may slow down the project, there is often an additional concern that accepting PRs from other parts of the company may “muddy the waters” when it comes to assessing what parts of the project were completed/delivered by the contracted developers. +- Contractors may have concerns about loss of control over the projects technical details if other teams are contributing significantly. +Even when motivations align (a project can be completed faster or with higher quality by engaging in InnerSource) contractors might still be unclear if they can because it is not explicitly listed as allowed in the contract terms. All of the above can mean that even if an individual contract developer wants to engage in InnerSource, there are system-level constraints pushing them not to. From cc8cc612822554c1106980436deb42897412da7e Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Thu, 3 Feb 2022 14:00:31 +0100 Subject: [PATCH 14/28] Grammar fix --- .../transitioning-contractor-code-to-innersource-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 6b06be401..2ca340a8a 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -15,7 +15,7 @@ Contractor developers are often not motivated (through forces described below) t This problem exists where an organization either: - out-sources the development of a well defined project or -- engagages external firms for staff augmentation and has mixed teams of permanent employees with a large percentage of contract staff. This issue may occur less often in a mixed team where InnerSource principles and ways of working are already established within the organization, but the forces described below are still often at play. +- engages external firms for staff augmentation and has mixed teams of permanent employees with a large percentage of contract staff. This issue may occur less often in a mixed team where InnerSource principles and ways of working are already established within the organization, but the forces described below are still often at play. ## Forces From 066c82c7d4839393bcf18b5687bbcc4196ff9968 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Thu, 3 Feb 2022 14:02:02 +0100 Subject: [PATCH 15/28] Formatting Known Instances as a list --- .../transitioning-contractor-code-to-innersource-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 2ca340a8a..d74445dca 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -52,7 +52,7 @@ This particular pattern does not attempt to change the initial behavior of the c ## Known Instances -GitHub has seen this approach work with their US government agency customers. +* **GitHub** has seen this approach work with their US government agency customers. ## Status (optional until merging) From 81716e1c2d47025ab54968b3c979a2f5dd9d58f4 Mon Sep 17 00:00:00 2001 From: Clare Dillon <32961070+claredillon@users.noreply.github.com> Date: Mon, 10 Oct 2022 10:11:52 +0100 Subject: [PATCH 16/28] Update patterns/1-initial/transitioning-contractor-code-to-innersource-model.md Co-authored-by: Zack Koppert --- ...transitioning-contractor-code-to-innersource-model.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index d74445dca..7d752aaa2 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -42,7 +42,14 @@ It could also be noted that the contractor motivations in this instance is almos At the outset of the project, clearly define: - That the code will be made visible by default. -- How the project will be transitioned to an InnerSource project. (Zack can add more explicit details here) +- That the architecture of the code should be modular and ready for component reuse. +- How the project will be transitioned to an InnerSource project. This could be similar to a transition of ownership plan for an open source project which should include: + - Identification of new a maintainer team + - An announcement to stakeholders regarding the transition + - Written documentation describing functionality, architecture, and common processes like releasing, patching, deploying, testing, etc. + - A prescribed number of hours on the contract set aside for the contractor to meet with the identified long term maintainer (normally from the company who hired the contractor) for an overview of responsibilities and Q & A. + - (untested) A 30 day warranty pattern could be applied and so the contractor would provide 30 days of direct transition support to the new maintainers + It is noted that this practice can work very well where there is a high trust relationship between the contracting team and the contractors. Perhaps they have worked closely together before, or have a pre-existing relationship. Further patterns that explore how to build trust between teams might enhance this pattern. From b355f23374cdcc0d5466daa460b4f0470c812c2d Mon Sep 17 00:00:00 2001 From: Clare Dillon <32961070+claredillon@users.noreply.github.com> Date: Mon, 10 Oct 2022 10:12:10 +0100 Subject: [PATCH 17/28] Update patterns/1-initial/transitioning-contractor-code-to-innersource-model.md Co-authored-by: Sebastian Spier --- .../transitioning-contractor-code-to-innersource-model.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 7d752aaa2..cf53bbb0d 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -61,9 +61,9 @@ This particular pattern does not attempt to change the initial behavior of the c * **GitHub** has seen this approach work with their US government agency customers. -## Status (optional until merging) +## Status -TBD +Initial ## Author(s) From 53382571b116a58aec379707713f421cf77e671b Mon Sep 17 00:00:00 2001 From: Clare Dillon <32961070+claredillon@users.noreply.github.com> Date: Mon, 10 Oct 2022 10:12:23 +0100 Subject: [PATCH 18/28] Update patterns/1-initial/transitioning-contractor-code-to-innersource-model.md Co-authored-by: Sebastian Spier --- .../transitioning-contractor-code-to-innersource-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index cf53bbb0d..7c1243d1d 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -21,7 +21,7 @@ This problem exists where an organization either: Contractor Motivation and Constraints: -- Often contracts with third-party developers are very focused on delivering an end result in the fastest possible fashion. As a result, all InnerSource activities (e.g. responding to third-party PRs) are considered to be distractions or something that will “slow down” ultimate delivery. +- Contracts with third-party developers tend to be focused on delivering an end result in the fastest possible fashion. As a result, all InnerSource activities (e.g. responding to third-party PRs) are considered to be distractions or something that will “slow down” delivery. - There is also often a concern that accepting code from other parts of the business might introduce security risks, scope creep or other issues that would subsequently have to be resolved by the contract team. - Above and beyond the idea that InnerSource may slow down the project, there is often an additional concern that accepting PRs from other parts of the company may “muddy the waters” when it comes to assessing what parts of the project were completed/delivered by the contracted developers. - Contractors may have concerns about loss of control over the projects technical details if other teams are contributing significantly. From be14878e79371c319840871e67a6fc6b5b6d4672 Mon Sep 17 00:00:00 2001 From: Clare Dillon <32961070+claredillon@users.noreply.github.com> Date: Mon, 10 Oct 2022 10:12:35 +0100 Subject: [PATCH 19/28] Update patterns/1-initial/transitioning-contractor-code-to-innersource-model.md Co-authored-by: Sebastian Spier --- .../transitioning-contractor-code-to-innersource-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 7c1243d1d..d36baeac9 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -22,7 +22,7 @@ This problem exists where an organization either: Contractor Motivation and Constraints: - Contracts with third-party developers tend to be focused on delivering an end result in the fastest possible fashion. As a result, all InnerSource activities (e.g. responding to third-party PRs) are considered to be distractions or something that will “slow down” delivery. -- There is also often a concern that accepting code from other parts of the business might introduce security risks, scope creep or other issues that would subsequently have to be resolved by the contract team. +- Concern that accepting code from other parts of the business might introduce security risks, scope creep or other issues that would subsequently have to be resolved by the contract team. - Above and beyond the idea that InnerSource may slow down the project, there is often an additional concern that accepting PRs from other parts of the company may “muddy the waters” when it comes to assessing what parts of the project were completed/delivered by the contracted developers. - Contractors may have concerns about loss of control over the projects technical details if other teams are contributing significantly. Even when motivations align (a project can be completed faster or with higher quality by engaging in InnerSource) contractors might still be unclear if they can because it is not explicitly listed as allowed in the contract terms. From da771098c30eae04eff6432f5f8215941885743f Mon Sep 17 00:00:00 2001 From: Clare Dillon <32961070+claredillon@users.noreply.github.com> Date: Mon, 10 Oct 2022 10:12:52 +0100 Subject: [PATCH 20/28] Update patterns/1-initial/transitioning-contractor-code-to-innersource-model.md Co-authored-by: Sebastian Spier --- .../transitioning-contractor-code-to-innersource-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index d36baeac9..31b0992b0 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -23,7 +23,7 @@ Contractor Motivation and Constraints: - Contracts with third-party developers tend to be focused on delivering an end result in the fastest possible fashion. As a result, all InnerSource activities (e.g. responding to third-party PRs) are considered to be distractions or something that will “slow down” delivery. - Concern that accepting code from other parts of the business might introduce security risks, scope creep or other issues that would subsequently have to be resolved by the contract team. -- Above and beyond the idea that InnerSource may slow down the project, there is often an additional concern that accepting PRs from other parts of the company may “muddy the waters” when it comes to assessing what parts of the project were completed/delivered by the contracted developers. +- Concern that accepting PRs from other parts of the company may “muddy the waters” when it comes to assessing what parts of the project were completed/delivered by the contracted developers. - Contractors may have concerns about loss of control over the projects technical details if other teams are contributing significantly. Even when motivations align (a project can be completed faster or with higher quality by engaging in InnerSource) contractors might still be unclear if they can because it is not explicitly listed as allowed in the contract terms. From a77d4895ac6d5d7b99dbc24a778b1a5235923cdd Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Mon, 10 Oct 2022 11:34:59 +0200 Subject: [PATCH 21/28] Fix linter issue --- .../transitioning-contractor-code-to-innersource-model.md | 1 - 1 file changed, 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 31b0992b0..916ad49e0 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -50,7 +50,6 @@ At the outset of the project, clearly define: - A prescribed number of hours on the contract set aside for the contractor to meet with the identified long term maintainer (normally from the company who hired the contractor) for an overview of responsibilities and Q & A. - (untested) A 30 day warranty pattern could be applied and so the contractor would provide 30 days of direct transition support to the new maintainers - It is noted that this practice can work very well where there is a high trust relationship between the contracting team and the contractors. Perhaps they have worked closely together before, or have a pre-existing relationship. Further patterns that explore how to build trust between teams might enhance this pattern. ## Resulting Context From c7a61fbb11dff32f2974634ca0596e4cd8bc7e85 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Mon, 10 Oct 2022 11:35:10 +0200 Subject: [PATCH 22/28] Fix linter issue --- .../transitioning-contractor-code-to-innersource-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 916ad49e0..016afbd41 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -43,7 +43,7 @@ At the outset of the project, clearly define: - That the code will be made visible by default. - That the architecture of the code should be modular and ready for component reuse. -- How the project will be transitioned to an InnerSource project. This could be similar to a transition of ownership plan for an open source project which should include: +- How the project will be transitioned to an InnerSource project. This could be similar to a transition of ownership plan for an open source project which should include: - Identification of new a maintainer team - An announcement to stakeholders regarding the transition - Written documentation describing functionality, architecture, and common processes like releasing, patching, deploying, testing, etc. From 24bc69465a790e0bf39d050638bdcf1d8507747b Mon Sep 17 00:00:00 2001 From: Clare Dillon <32961070+claredillon@users.noreply.github.com> Date: Mon, 10 Oct 2022 10:38:27 +0100 Subject: [PATCH 23/28] Update patterns/1-initial/transitioning-contractor-code-to-innersource-model.md Co-authored-by: Sebastian Spier --- .../transitioning-contractor-code-to-innersource-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 016afbd41..1652d6b32 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -41,7 +41,7 @@ It could also be noted that the contractor motivations in this instance is almos At the outset of the project, clearly define: -- That the code will be made visible by default. +- That the code will be made visible by default to all developers within the organization. - That the architecture of the code should be modular and ready for component reuse. - How the project will be transitioned to an InnerSource project. This could be similar to a transition of ownership plan for an open source project which should include: - Identification of new a maintainer team From ab05786f4731f981d7a4d51baa201aea6e76f52e Mon Sep 17 00:00:00 2001 From: Clare Dillon <32961070+claredillon@users.noreply.github.com> Date: Mon, 10 Oct 2022 10:39:05 +0100 Subject: [PATCH 24/28] Update patterns/1-initial/transitioning-contractor-code-to-innersource-model.md Co-authored-by: Sebastian Spier --- .../transitioning-contractor-code-to-innersource-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 1652d6b32..69bfec2fd 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -25,7 +25,7 @@ Contractor Motivation and Constraints: - Concern that accepting code from other parts of the business might introduce security risks, scope creep or other issues that would subsequently have to be resolved by the contract team. - Concern that accepting PRs from other parts of the company may “muddy the waters” when it comes to assessing what parts of the project were completed/delivered by the contracted developers. - Contractors may have concerns about loss of control over the projects technical details if other teams are contributing significantly. -Even when motivations align (a project can be completed faster or with higher quality by engaging in InnerSource) contractors might still be unclear if they can because it is not explicitly listed as allowed in the contract terms. +- Even when motivations align (a project can be completed faster or with higher quality by engaging in InnerSource) contractors might still be unclear if they can because it is not explicitly listed as allowed in the contract terms. All of the above can mean that even if an individual contract developer wants to engage in InnerSource, there are system-level constraints pushing them not to. From 45cedaddff4527676228e50ad45e3aef5dfc33e9 Mon Sep 17 00:00:00 2001 From: Clare Dillon <32961070+claredillon@users.noreply.github.com> Date: Mon, 10 Oct 2022 10:46:42 +0100 Subject: [PATCH 25/28] Update transitioning-contractor-code-to-innersource-model.md Extended the patlet description. Removed some comments for other editors. --- .../transitioning-contractor-code-to-innersource-model.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 69bfec2fd..3f38eb370 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -4,7 +4,7 @@ Transitioning Contractor Code to InnerSource Model ## Patlet -Contract developers are often not motivated to engage in InnerSource activities, which may be beyond the scope of their contract. This patlet describes how you can focus on transitioning the contractor project after the fact to an InnerSource project. +Contract developers are often not motivated to engage in InnerSource activities, which may be beyond the scope of their contract. This patlet describes how you can focus on transitioning the contractor project after the fact to an InnerSource project by setting expectations for specific InnerSource-related deliverables as part of the overall project delivery. ## Problem @@ -35,7 +35,7 @@ It should be noted that the above scenario is indirectly impacted by: - Pressures to reduce contractor costs during procurement - Ability to tie contributions to payment at a granular level. -It could also be noted that the contractor motivations in this instance is almost like a more extreme instance of the oft-reported organizational/budgetary constraints that might exist for some internal business units. (Not sure if this is relevant, but it does seem to be an extreme case of what is reported as common objections even in internal teams). +It could also be noted that the contractor motivations in this instance is almost like a more extreme instance of the often reported organizational/budgetary constraints that might exist for some internal business units. ## Solutions @@ -66,7 +66,7 @@ Initial ## Author(s) -- Clare Dillon (v.0 assuming others will add themselves in this section as we flesh it out). +- Clare Dillon - Zack Koppert ## Acknowledgements From 2494f3a22c8d0d7df283160653284bf6e46e455c Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Mon, 10 Oct 2022 11:50:41 +0200 Subject: [PATCH 26/28] Fix linter issue --- .../transitioning-contractor-code-to-innersource-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 3f38eb370..05e2b7d51 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -66,7 +66,7 @@ Initial ## Author(s) -- Clare Dillon +- Clare Dillon - Zack Koppert ## Acknowledgements From 65625510c6ac9d7c800fc89cd47ce105c7d2cc15 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Mon, 10 Oct 2022 11:50:48 +0200 Subject: [PATCH 27/28] Fix linter issue --- .../transitioning-contractor-code-to-innersource-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index 05e2b7d51..a9bd92778 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -35,7 +35,7 @@ It should be noted that the above scenario is indirectly impacted by: - Pressures to reduce contractor costs during procurement - Ability to tie contributions to payment at a granular level. -It could also be noted that the contractor motivations in this instance is almost like a more extreme instance of the often reported organizational/budgetary constraints that might exist for some internal business units. +It could also be noted that the contractor motivations in this instance is almost like a more extreme instance of the often reported organizational/budgetary constraints that might exist for some internal business units. ## Solutions From 712c53cac8d74bb37e2d9429cbd8a4edff54b0cb Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Mon, 10 Oct 2022 11:51:01 +0200 Subject: [PATCH 28/28] Wording fix. --- .../transitioning-contractor-code-to-innersource-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md index a9bd92778..a29d77a54 100644 --- a/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md +++ b/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md @@ -4,7 +4,7 @@ Transitioning Contractor Code to InnerSource Model ## Patlet -Contract developers are often not motivated to engage in InnerSource activities, which may be beyond the scope of their contract. This patlet describes how you can focus on transitioning the contractor project after the fact to an InnerSource project by setting expectations for specific InnerSource-related deliverables as part of the overall project delivery. +Contract developers are often not motivated to engage in InnerSource activities, which may be beyond the scope of their contract. This pattern describes how you can focus on transitioning the contractor project after the fact to an InnerSource project by setting expectations for specific InnerSource-related deliverables as part of the overall project delivery. ## Problem