From 06fd1c1190fc075f950d1b6a6f8aa27572f730bd Mon Sep 17 00:00:00 2001 From: Clare Dillon <32961070+claredillon@users.noreply.github.com> Date: Sat, 18 Dec 2021 07:19:48 +0000 Subject: [PATCH 1/8] Create innersource-contractor-model-terms Taken from issue: https://github.com/InnerSourceCommons/InnerSourcePatterns/issues/376 --- .../innersource-contractor-model-terms | 64 +++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 patterns/1-initial/innersource-contractor-model-terms diff --git a/patterns/1-initial/innersource-contractor-model-terms b/patterns/1-initial/innersource-contractor-model-terms new file mode 100644 index 000000000..18b3a83d6 --- /dev/null +++ b/patterns/1-initial/innersource-contractor-model-terms @@ -0,0 +1,64 @@ +## Title +InnerSource Contractor Model Terms + +## Patlet +Contract developers are often not motivated to engage in InnerSource activities. This patlet includes some terms which could be included in their initial contract to ensure engagement in the InnerSource process. + +## 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. + +## 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 may be 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's 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 any new project, ensure terms of the contract and Statement of Work reference InnerSource goals and the expected roles that can be played by individual contractors. + +Specific examples include: +- Role Definitions :- At the beginning of every project, contractors are explicitly assigned roles such as Admin, Contributor, Reader or InnerSource roles such Trusted Committer / Contributor. +- Specific InnerSource Goals and/or time to be allocated to InnerSource initiative:- e.g. Allocated time to reviewing PRs from outside the team; response time goals to respond to PRs from others. +- Specific guidelines on decision-making processes to decide how SOW may change as a result of PRs that come during the implementation of the project. + +(Derek Murawsky will hopefully have more info/details/examples to add there) + +Implicit in these new terms is a move away from a rigid SOW with a hard deadline and set of deliverables. + +## Resulting Context +This patlet can help re-define standard contract terms with software development vendors. When implemented, it gives individual contractors permission and guarantees reward for engaging in the InnerSource process. +The end result should also be more sustainable code for the contracting organization. + +## Known Instances (optional) +Some community participants have seen this approach work with their clients. Derek Murawsky 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 Gil Yehuda for raising the issue in the InnerSource Slack channel and Derek Murawsky for sharing his approach. + +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 b6c408a5f659efb7cf4723131c12af6ce32764b0 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 18 Dec 2021 10:30:51 +0100 Subject: [PATCH 2/8] Renaming file to .md + Fixing some spacing --- ... => innersource-contractor-model-terms.md} | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) rename patterns/1-initial/{innersource-contractor-model-terms => innersource-contractor-model-terms.md} (94%) diff --git a/patterns/1-initial/innersource-contractor-model-terms b/patterns/1-initial/innersource-contractor-model-terms.md similarity index 94% rename from patterns/1-initial/innersource-contractor-model-terms rename to patterns/1-initial/innersource-contractor-model-terms.md index 18b3a83d6..bdfa232de 100644 --- a/patterns/1-initial/innersource-contractor-model-terms +++ b/patterns/1-initial/innersource-contractor-model-terms.md @@ -1,19 +1,26 @@ ## Title + InnerSource Contractor Model Terms ## Patlet + Contract developers are often not motivated to engage in InnerSource activities. This patlet includes some terms which could be included in their initial contract to ensure engagement in the InnerSource process. ## 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. ## 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 may be 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,10 +36,12 @@ It should be noted that the above scenario is indirectly impacted by: It could also be noted that the Contractor's 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 any new project, ensure terms of the contract and Statement of Work reference InnerSource goals and the expected roles that can be played by individual contractors. Specific examples include: -- Role Definitions :- At the beginning of every project, contractors are explicitly assigned roles such as Admin, Contributor, Reader or InnerSource roles such Trusted Committer / Contributor. + +- Role Definitions:- At the beginning of every project, contractors are explicitly assigned roles such as Admin, Contributor, Reader or InnerSource roles such Trusted Committer / Contributor. - Specific InnerSource Goals and/or time to be allocated to InnerSource initiative:- e.g. Allocated time to reviewing PRs from outside the team; response time goals to respond to PRs from others. - Specific guidelines on decision-making processes to decide how SOW may change as a result of PRs that come during the implementation of the project. @@ -40,19 +50,24 @@ Specific examples include: Implicit in these new terms is a move away from a rigid SOW with a hard deadline and set of deliverables. ## Resulting Context + This patlet can help re-define standard contract terms with software development vendors. When implemented, it gives individual contractors permission and guarantees reward for engaging in the InnerSource process. The end result should also be more sustainable code for the contracting organization. ## Known Instances (optional) + Some community participants have seen this approach work with their clients. Derek Murawsky 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 Gil Yehuda for raising the issue in the InnerSource Slack channel and Derek Murawsky for sharing his approach. This pattern was extracted from a conversation on the topic held with the following folks: From d0b2b8db31444e46d3018d8bf732e63d7573ccaf Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 18 Dec 2021 10:33:37 +0100 Subject: [PATCH 3/8] Add spacing before list --- patterns/1-initial/innersource-contractor-model-terms.md | 1 + 1 file changed, 1 insertion(+) diff --git a/patterns/1-initial/innersource-contractor-model-terms.md b/patterns/1-initial/innersource-contractor-model-terms.md index bdfa232de..7bf8fda50 100644 --- a/patterns/1-initial/innersource-contractor-model-terms.md +++ b/patterns/1-initial/innersource-contractor-model-terms.md @@ -71,6 +71,7 @@ Clare Dillon (v.0 assuming others will add themselves in this section as we fles Particular thanks to Gil Yehuda for raising the issue in the InnerSource Slack channel and Derek Murawsky for sharing his approach. This pattern was extracted from a conversation on the topic held with the following folks: + - Brittany Istenes - Clare Dillon - Cristina Coffey From 1177ec8ca6d4305480d50db7ef4c7c584394ae0e Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 18 Dec 2021 10:38:41 +0100 Subject: [PATCH 4/8] Removing some trailing spaces --- .../innersource-contractor-model-terms.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/patterns/1-initial/innersource-contractor-model-terms.md b/patterns/1-initial/innersource-contractor-model-terms.md index 7bf8fda50..9e5b4526b 100644 --- a/patterns/1-initial/innersource-contractor-model-terms.md +++ b/patterns/1-initial/innersource-contractor-model-terms.md @@ -14,16 +14,16 @@ 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. +- 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. ## 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 may be system-level constraints pushing them not to. @@ -31,23 +31,23 @@ 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's 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's 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 any new project, ensure terms of the contract and Statement of Work reference InnerSource goals and the expected roles that can be played by individual contractors. +At the outset of any new project, ensure terms of the contract and Statement of Work reference InnerSource goals and the expected roles that can be played by individual contractors. Specific examples include: -- Role Definitions:- At the beginning of every project, contractors are explicitly assigned roles such as Admin, Contributor, Reader or InnerSource roles such Trusted Committer / Contributor. -- Specific InnerSource Goals and/or time to be allocated to InnerSource initiative:- e.g. Allocated time to reviewing PRs from outside the team; response time goals to respond to PRs from others. +- Role Definitions: At the beginning of every project, contractors are explicitly assigned roles such as Admin, Contributor, Reader or InnerSource roles such Trusted Committer / Contributor. +- Specific InnerSource Goals and/or time to be allocated to InnerSource initiative: e.g. Allocated time to reviewing PRs from outside the team; response time goals to respond to PRs from others. - Specific guidelines on decision-making processes to decide how SOW may change as a result of PRs that come during the implementation of the project. (Derek Murawsky will hopefully have more info/details/examples to add there) -Implicit in these new terms is a move away from a rigid SOW with a hard deadline and set of deliverables. +Implicit in these new terms is a move away from a rigid SOW with a hard deadline and set of deliverables. ## Resulting Context From eb3494cbcdce87efeb236cc5259348fce2d01b5a Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 18 Dec 2021 19:18:49 +0100 Subject: [PATCH 5/8] More spacing fixes --- patterns/1-initial/innersource-contractor-model-terms.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/patterns/1-initial/innersource-contractor-model-terms.md b/patterns/1-initial/innersource-contractor-model-terms.md index 9e5b4526b..250801655 100644 --- a/patterns/1-initial/innersource-contractor-model-terms.md +++ b/patterns/1-initial/innersource-contractor-model-terms.md @@ -42,7 +42,7 @@ At the outset of any new project, ensure terms of the contract and Statement of Specific examples include: - Role Definitions: At the beginning of every project, contractors are explicitly assigned roles such as Admin, Contributor, Reader or InnerSource roles such Trusted Committer / Contributor. -- Specific InnerSource Goals and/or time to be allocated to InnerSource initiative: e.g. Allocated time to reviewing PRs from outside the team; response time goals to respond to PRs from others. +- Specific InnerSource Goals and/or time to be allocated to InnerSource initiative: e.g. Allocated time to reviewing PRs from outside the team; response time goals to respond to PRs from others. - Specific guidelines on decision-making processes to decide how SOW may change as a result of PRs that come during the implementation of the project. (Derek Murawsky will hopefully have more info/details/examples to add there) @@ -51,8 +51,8 @@ Implicit in these new terms is a move away from a rigid SOW with a hard deadline ## Resulting Context -This patlet can help re-define standard contract terms with software development vendors. When implemented, it gives individual contractors permission and guarantees reward for engaging in the InnerSource process. -The end result should also be more sustainable code for the contracting organization. +This patlet can help re-define standard contract terms with software development vendors. When implemented, it gives individual contractors permission and guarantees reward for engaging in the InnerSource process. +The end result should also be more sustainable code for the contracting organization. ## Known Instances (optional) From 34d8b510f602c2dd357ed686b0411318d6722484 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 29 Dec 2024 18:35:53 +0100 Subject: [PATCH 6/8] Spacing --- patterns/1-initial/innersource-contractor-model-terms.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/innersource-contractor-model-terms.md b/patterns/1-initial/innersource-contractor-model-terms.md index 250801655..b60d33bb5 100644 --- a/patterns/1-initial/innersource-contractor-model-terms.md +++ b/patterns/1-initial/innersource-contractor-model-terms.md @@ -56,7 +56,7 @@ The end result should also be more sustainable code for the contracting organiza ## Known Instances (optional) -Some community participants have seen this approach work with their clients. Derek Murawsky can add details as appropriate. +Some community participants have seen this approach work with their clients. Derek Murawsky can add details as appropriate. ## Status (optional until merging) From 607cbd55a59986e18224ae7a6d2e58ac3724a23f Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 29 Dec 2024 18:36:19 +0100 Subject: [PATCH 7/8] Add Status --- patterns/1-initial/innersource-contractor-model-terms.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/innersource-contractor-model-terms.md b/patterns/1-initial/innersource-contractor-model-terms.md index b60d33bb5..5e3473c7a 100644 --- a/patterns/1-initial/innersource-contractor-model-terms.md +++ b/patterns/1-initial/innersource-contractor-model-terms.md @@ -60,7 +60,7 @@ Some community participants have seen this approach work with their clients. Der ## Status (optional until merging) -TBD +- Initial ## Author(s) (optional) From 2d93c836265efa116fd9f78ba28f4cf91854df41 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 29 Dec 2024 18:36:56 +0100 Subject: [PATCH 8/8] Wording fix --- patterns/1-initial/innersource-contractor-model-terms.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/innersource-contractor-model-terms.md b/patterns/1-initial/innersource-contractor-model-terms.md index 5e3473c7a..6c966ce16 100644 --- a/patterns/1-initial/innersource-contractor-model-terms.md +++ b/patterns/1-initial/innersource-contractor-model-terms.md @@ -51,7 +51,7 @@ Implicit in these new terms is a move away from a rigid SOW with a hard deadline ## Resulting Context -This patlet can help re-define standard contract terms with software development vendors. When implemented, it gives individual contractors permission and guarantees reward for engaging in the InnerSource process. +This pattern can help re-define standard contract terms with software development vendors. When implemented, it gives individual contractors permission and guarantees reward for engaging in the InnerSource process. The end result should also be more sustainable code for the contracting organization. ## Known Instances (optional)