Pattern Idea: InnerSource Contractor Model Terms

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

No se identifica ningún archivo, prueba ni punto de entrada. Empieza revisando las secciones Problem, Solutions y Resulting Context, y determina después la ubicación para contribuir al patrón en el repositorio y los ejemplos o detalles del contrato que faltan. Se considera terminado cuando los términos del contrato están suficientemente desarrollados para finalizar el patrón.