[Pattern Draft] innersource-contractor-model-terms

[claredillon]

Created new pattern as detailed in issue: #376

[claredillon]

@derekmurawsky - can you please take a look and see if you can add some model terms or examples of what might be included as upfront contractor terms please as per the discussion? Thanks!

[spier]

Nice job @claredillon! I added the .md extension to the file.

This also results in our markdown syntax linter to check this file, which is why you should have received some email notifications with syntax warnings. I tried to fix some of them but not sure if I found all.

[derekmurawsky]

I believe it goes beyond this. There are two main forms of contract in the consulting world: Fixed-Price (FP) and Time-and-Materials (T&M). With FP, project profitability is directly impacted by the number of hours worked. Contractors are incentivized to work as few hours as possible to achieve the outcomes stated in the SOW. T&M is more flexible, as there are usually no defined outcomes. Contracting orgs love FP with well defined scopes. Clients usually like a mix depending on the outcome (staff augmentation vs wanting a particular deliverable, for example).

[derekmurawsky]

@claredillon - I had a chance to read and think about this a bit. Is the goal here to encourage contractors to contribute to other projects internally via innersourcing, or to accept enhancements from other teams? Or both? The reason I ask is that I believe there are different constraints for each scenario that we would need to address separately. I'll put my thoughts below and would like to discuss them before making any major edits to the MD as they may change it significantly.

Contractors working on a Fixed Price deliverable contributing out

In this scenario, contractors will be working on a fixed price deliverable. They will be incentivized to spend as little time on the deliverable as possible to maximize profit. As such, they are dis-incentivized from engaging with other teams. I can see a few examples where we could shortcut this:

• When a project requires work/enhancements in another system. In this scenario, contractors building project A would require work to be done in system B in order to integrate with it. This is a prime use case for InnerSourcing, and could be put in the contract as something like "Contractor will work with Team B to develop necessary enhancements for project A". This could be the fastest way to achieve the goal as you would be blending the necessary domain expertise from project A and B together, and project B might be less likely to push back since they will essentially get some staff augmentation to help with delivering their part.
• If the project is a standalone offering, it must be supported by someone on the client side after the contractors leave. I believe InnerSource could shine here by having the contractors work with full time staff to build out the offering together. The contractors would work as part of a team led by a full time client resource and would build a community around the project with the client. Handover would then become easier as the natural leaders from the client community could take over code ownership along with the original full time client lead. Codifying this in a contract would be interesting, though, as there is some amount of risk for the contractor. The contract may have to be built as though the contractor would be doing all the work, with additional clauses around building a user community. Perhaps we could leverage the idea of "training" here... meaning the contractors would "train" a community on the new project in an iterative manner throughout it's development cycles. This would align well with agile, and would force more community involvement.

Contractors working on a Fixed Price deliverable receiving contributions

Like the previous example, contractors will be dis-incentivized from engaging with other teams. However, I see more barriers here because anything new that needs to be accepted into their project would be "scope creep" and would likely require a change order. The only exception to this that I can think of right now would be in the integration of the contractor's project with another. If the contractors are working on Project A, and must integrate with Project B, but Project B needs more functionality in A than was originally understood, Team B could provide resources/code to Project A. In this instance, I believe some existing patterns could be leveraged to make the contracting agency more comfortable. Specifically, I'm thinking of the warranty pattern.

Contractors working on a Time and Materials contract receiving contributions, or contributing out

This is more the classic staff-augmentation arrangement where the contractors are providing their expertise in a certain area, or other otherwise augmenting normal processes. I don't believe anything special is needed here from a contracting perspective. It is important to establish how the contractors will integrate in with the normal daily operations of the client team(s). If the client uses InnerSource already, that would be part of the normal integration.

Thoughts?

[claredillon]

I think all the above scenarios are perfectly valid! Thanks so mich @derekmurawsky . Is there any chance you have any experience in people actually writing clauses to enable such scenarios into vendor contracts?

[derekmurawsky]

Unfortunately, I do not @claredillon . I tend to work organically and push these ideas/attitudes regardless of the contract type. It leads to better engagement with the client communities, but I can't put "official" time on it.

[spier]

@claredillon this pattern has some text overlap with the pattern described in #377.
Therefore I propose to finish the review of that other PR first, potentially copy some text blocks over, and then proceed with the review here. Would that work for you?

[spier]

Update: #377 is merged.

So now we can decide how to proceed with this PR here.

[michael-basil]

Interesting pattern. From my experiences being a contractor it seems very useful. I'm curious if this will pick back upl

[spier]

@claredillon and @derekmurawsky do you still have the time/energy/interest to get this idea merged into our repo?

In the easiest case we could just clean up the existing content a bit (i.e. remove internal comments, fix formatting, etc) and then get it published as an Initial pattern. That might then help us to search for other companies that have already made similar experiences in this space, who can then help us to improve the pattern.