LogoLogo
Contribute to InnerSource PatternsJoin the community
🇺🇸 English
🇺🇸 English
  • Introduction
  • Table of Contents
  • Explore Patterns
  • Contribute to this book
  • Patterns
    • 30 Day Warranty
    • Common Requirements
    • Communication Tooling
    • Contracted Contributor
    • Core Team
    • Cross-Team Project Valuation
    • Dedicated Community Leader
    • Document your Guiding Principles
    • Explicit Governance Levels
    • Extensions for Sustainable Growth
    • Gig Marketplace
    • Group Support
    • InnerSource License
    • InnerSource Portal
    • Issue Tracker Use Cases
    • Maturity Model
    • Praise Participants
    • Repository Activity Score
    • Review Committee
    • Service vs. Library
    • Standard Base Documentation
    • Standard Release Process
    • Start as an Experiment
    • Transparent Cross-Team Decision Making using RFCs
    • Trusted Committer
  • Appendix
    • Pattern Template
    • Glossary
    • Extras
      • README Template
      • CONTRIBUTING Template
      • COMMUNICATION Template
      • RFC Template
  • Resources
    • This book on GitHub
    • InnerSource Commons
Powered by GitBook
On this page
  • Title
  • Patlet
  • Problem
  • Context
  • Forces
  • Solution
  • Resulting Context
  • Known Instances
  • Authors
  • Acknowledgments
  • Status
  • Variants

Was this helpful?

Edit on GitHub
Export as PDF
  1. Patterns

30 Day Warranty

Title

30 Day Warranty

Patlet

When accepting contributions from outside of your own team, there is a natural aversion to taking responsibility for code not written by the team itself. Through the 30 Day Warranty the contributing team consents to provide bug fixes to the receiving team, which will increase the level of trust between both teams and makes it more likely that contributions get accepted.

Problem

A team develops a component which is used throughout an organization. This team resists accepting or outright rejects contributions (feature requests). This behavior blocks progress and leads to frequent disruption from escalations.

Context

  • Teams depend 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, and/or inclination to write the contributed component/feature themselves.

Forces

  • 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 receiving team's 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 code 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).

Solution

Address the fears of both the receiving and the contributing teams by establishing a 30 day warranty period starting with the time the contributed code goes into production. During this warranty period the contributing team consents to provide bug fixes to the receiving 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.

Resulting Context

  • 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.

Known Instances

  • PayPal Tried this and it was proven successful.

  • GitHub internally uses this pattern with a modified warranty timeline of 6 weeks.

  • Microsoft recommends this pattern as a principle - teams set their own specific time target matching their needs and confidence.

Authors

  • Cedric Williams

Acknowledgments

  • Dirk-Willem van Gulik

  • Padma Sudarsan

  • Klaas-Jan Stol

  • Georg Grütter

Status

  • Structured

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

Variants

PreviousContribute to this bookNextCommon Requirements

Last updated 2 months ago

Was this helpful?

In addition it helps to provide clear , spelling out the expectations of the receiving team and the contributing team.

SAP leverages this pattern in their InnerSource-based Everest project to transform collaboration, ensuring contributions are not just accepted but also supported, enhancing trust and driving forward the culture of shared responsibility and innovation. See:

Ensure cooperation of dependent teams by making them a community by having more than one, meritocratically appointed "" (TCs) take responsibility.

contribution guidelines
InnerSource: First Contribution Explored
Trusted Committers
30 Day Warranty