Skip to content
Proven approaches that can guide you through applying open source best practices within your organization
Branch: master
Clone or download

Latest commit

lenucksi Merge pull request #111 from StingRayZA/moving-wiki
Fixing a couple of non-relative links & moved wiki links to new InnerSourceCommons location
Latest commit 5f42f1b Mar 28, 2019


Type Name Latest commit message Commit time
Failed to load latest commit information.
assets cropped solution sketch for contracted contributor Sep 8, 2017
meta figured out raw relative link Mar 27, 2019
project-roles testing reference links Mar 8, 2019 generic link bulk change Mar 8, 2019 Renamed trusted collaborators to the standardised trusted committer Mar 8, 2019
LICENSE.txt Moved licensing info Feb 1, 2017 updating more links from old repo to new & making relative where poss… Mar 27, 2019 Inserted patlet Nov 17, 2017 generic link bulk change Mar 8, 2019 more bulk generic link changes Mar 8, 2019 Various typos and a double space May 21, 2018 more bulk generic link changes Mar 8, 2019 Changed Context prerequisites subsection to 3rd level heading Sep 13, 2018 Update Sep 22, 2017 Changed Context prerequisites subsection to 3rd level heading Sep 13, 2018 Merge branch 'master' into pattern/introducing-metrics-in-innersource Aug 27, 2018 Update May 9, 2017 Update Jun 1, 2017 - added categorization proposal. Thanks Ofer! Dec 1, 2017 generic link bulk change Mar 8, 2019 feminine pronouns added Oct 2, 2018 generic link bulk change Mar 8, 2019 added patlet to start-as-experiment pattern Feb 16, 2018

This repository serves as the collection-point, ideation hub, and process behind the InnerSource Commons' InnerSource Patterns--a set of proven and reviewed solutions to InnerSource problems. These patterns illustrate beneficial activities and behaviors found in organizations who apply InnerSource methodologies. See below the list for more on what a pattern is, how to use them in your organization, and how to get involved.

List of Patterns

The below lists all known patterns. They are grouped into four stages of maturity.

Reviewed Patterns (proven and reviewed)

  • 30 Day Warranty - a pattern for getting a reluctant code-owning team to accept code submissions from outside their team.
  • Common Requirements - Common code in a shared repository isn't meeting the needs of all the project-teams that want to use it; this is solved through requirements alignment and refactoring.
  • Contracted Contributor - Associates wanting to contribute to InnerSource are discouraged from doing so by their line management. Relief is provided by formal contracts and agreements.
  • Dedicated Community Leader - Select people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative.
  • Gig Marketplace - Establish a marketplace by creating an intranet website that lists specific InnerSource project needs as "Gigs" with explicit time and skill requirements. This will enable managers to better understand their employee’s time commitment and professional benefits thereby increasing the likelihood of garnering approval to make InnerSource contributions.
  • InnerSource Portal - Create an intranet website that indexes all available InnerSource project information. This will enable potential contributors to more easily learn about projects that might interest them and for InnerSource project owners to attract an outside audience.
  • Praise Participants - Thank contributors effectively to engender further engagement from them and to encourage others to contribute
  • Review Committee - A formal review committee is setup within an org to "officiate" particular inner source projects with resources, etc.
  • Service vs. library: It's inner source, not inner deployment - Teams in a DevOps environment may be reluctant to work across team boundaries on common code bases due to ambiguity over who will be responsible for responding to service downtime. The solution is to realize that often it's possible to either deploy the same service in independent environments with separate escalation chains in the event of service downtime or factor a lot of shared code out into one library and collaborate on that.
  • Trusted Committer - Many inner-source projects will find themselves in a situation where they consistently receive feedback, features, and bug-fixes from contributors. In these situations project maintainers seek ways to recognize and reward the work of the contributor above and beyond single contributions.

Reviewed Pattern Ideas (not yet proven but reviewed)

  • Modular Code - Management does not want to spend the extra resources needed to develop modular components and make them available in a visible repository for others to use.
  • Improve Findability - People can't find the internally developed solutions that they need due to poor naming conventions. This causes frustration in finding inner source solutions and a reduction in code reuse.

Pattern Drafts (proven, not yet fully reviewed)

  • Assisted Compliance - Helping repo owners be compliant by writing their for them as a pull request.
  • Cross-Team Project Valuation - It's hard to sell the value of cross-team, inner sourced projects that don't provide a direct impact on company revenue. Here's a data-driven way to represent your project that both articulates its value and amplifies it.
  • Reluctance to Receive Contributions - Core owner of shared asset is reluctant to take contributions due to the required maintenance that comes with them.
  • What Before How or Services Documentation - A lack of common understanding between different management tiers creates funding barriers and increases the risk that solutions will not deliver required business outcomes.
  • Overcome Acquisition Based Silos - Developers
  • Overcome Acquisition Based Silos - Managers
  • Open Source Trumps InnerSource - People find the InnerSource project but, after all things are considered, even if the InnerSource component meets their needs, they still go with the open source component.
  • Overcoming Project Management Time Pressures - Project management believes timeline pressure and commitments on feature content does not allow for developers to spend the time needed to develop shareable code and provide support.
  • Start as Experiment - An inner source initiative is considered but not started, because management is unsure about its outcome and therefore unwilling to commit to the investment.
  • Include Product Owners - Key Performance Indicators (KPIs) for Product Owners are primarily product focused, and don't consider areas such as collaborative development. This results in a lower level of engagement with inner source projects.

Pattern Ideas (not yet proven; brainstormed)

Pattern Donuts (needing a solution)

What are Inner Source Patterns?

Patterns are a way of describing a repeatable, proven solution to a problem with a context. They follow a simple form that helps people wanting to implement the solution to understand the constraints on the problem, the forces that must be balanced and the resulting context (the situation you are left with after the solution is applied). In inner sourcing, patterns can provide a way for the InnerSource Commons participants to concisely share information with each other, improving the practice of inner sourcing. Each of the patterns are divided into Title, Problem Statement, Context, Forces, and Solutions as their main sections.

How can you use Inner Source Patterns?

Patterns must be used in a thoughtful manner. They cannot be blindly applied. In most cases, you will need to adapt the given solution to your own situation; but the information given in the pattern, defining the context (immovable constraints) and forces (constraints that can be changed and balanced against each other), should help you do this. Note that you will also need to determine if there are additional constraints (company context and company forces) that apply to your particular company/organization that must be added to the pattern (as a kind of filter). These additional constraints may require additional solution steps to be applied.

The pattern form is useful for describing proven patterns but it can also be used for brainstorming solutions where patterns are not yet established, since the form gives a structured way for thinking about a problem. You could also create a donut pattern (filling in the problem, context, forces and resulting context fields but leaving the solution blank) as a way of asking the InnerSource Commons community for help (to find a proven solution or to brainstorm things to try).

How to Contribute?

See our for details on getting involved

We encourage beginners seeking answers to jump in by creating ''donuts'' (problems without solutions). We encourage experts to pad their experience - these are hoped to become part of a book one day. Anyone can offer reviews and comments for in-progress patterns.

We work together via Github, Webex, Slack, etc. Do not hesitate to join the #innersourcecommons or #innersource-patterns slack channels and ask to be included in the patterns meetings (there is an email list).

Pattern Meta Info

The topics below cover information about how we define, operate, and upkeep this collection of patterns.

  • Pattern Template - Start a new pattern with a copy of this
  • Pattern States - Definitions of the various states and review steps a pattern can be in
  • Trusted Committers - Who these people are, what elevated rights they get, and how you can become one
  • Publishing - How we take completed, reviewed, proven patterns and publish them toward an online book
  • Markdown Info - Markdown is the ascii text format our patterns are written in; this document briefly defines how we use it
  • Contributing - How to interact with our group, create your own patterns, or take part in our review-process; Github / Web centric instructions
    • Alternate Command-line steps - If you want to contribute a pattern using git from the command-line, this is your document
    • Meetings - Become involved with the people and communications of the Inner Source Patterns group

Related References


Creative Commons License

InnerSourcePatterns by is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

You can’t perform that action at this time.