30 Day Warranty

Teams depends on another team accepting their contributions so that a component produced by the receiving team can be used by the contributing team. The receiving team does not have the resources, knowledge, permission, inclination to write the contributed component.

- TBD: link to pattern "setting clear expectations for contributing code"

A team developing a component which is used throughout an organization is resisting to accept or rejects contributions (feature requests) and as a result blocks progress or is disrupted by frequent escalations.

- There is distrust of contributions due to a past history of cheating: teams

submitted half finished contributions and subsequently filed requests for

fixes that make it ready for use in production.

- If code is contributed from outside the team, the team has the natural

suspicion that the other team does not know how to write code that would

meet the teams expectations.

- Each team looks first to help its own leaders achieve their own goals. This direction

of loyalty can complicate resolution of this problem.

- There is a natural aversion to taking responsibility for code not written

by oneself.

- Contributed needs to be heavily rewritten before being accepted into the

codebase.

- There is the fear of the contributors not being available for support with

fixing bugs after the time on contribution.

- Teams fear contributed code will lead to high(er) maintenance costs but do

not know how to control for that.

- Receiving teams may fear that teaching others how to contribute code will

expose technical debt in their system and that visibility may be damaging.

- Receiving teams may not believe that they will get acceptable code no

matter how much mentoring they provide.

- Either team may not feel confident in measuring risks or certifying that

they are mitigated in a contribution; the system itself is somewhat brittle

(may not be ways to fully test and catch all problems).

Address the fears of both the receiving and the contributing teams by establishing a 30 day period starting with the time the contributed code goes into production, during which the contributing team consents to provide bug fixes to the receiving team.

Provide clear contribution guidelines spelling out the expectations of the receiving team and the contributing team.

Note that the warranty period could be 45, 60, or 100 days too. The duration may vary based upon the constraints of the project, the software life cycle of the project, commitments to customers, and other factors.

- The receiving team is willing to accept contributions and able to share the

workload of initial adaptations/fixes.

- Increased transparency and fairness.

- Keeps escalations from becoming too heavyweight.

This was tried and proven successful at PayPal.

- Cedric Williams

- Dirk-Willem van Gulik

- Padma Sudarsan

- Klaas-Jan Stol

- Georg Grütter

Drafted at the 2017 Spring InnerSource Summit; reviewed 18 July 2017.

- Ensure cooperation of dependent teams by making them a community by having

more than one, meritocratically appointed "Trusted Committers" (TCs) take responsibility.