InnerSource Patterns

This repository contains the InnerSource Patterns collected by the InnerSource Commons. These patterns are InnerSource best practices codified in a specific format to make it easy to understand, evaluate, and reuse them.

If you are here for the first time, you may start by reading our most mature patterns, published at patterns.innersourcecommons.org.

Below you find what a pattern is, a list of known patterns, and how to use these patterns in your organization.

Are you already using InnerSource in your company? If you would like to share your experiences with the world, we would love to welcome your contributions!

Mission Statement

Our mission

• Collect and document best practices on how to do InnerSource - in the form of patterns
• Publish the most mature patterns as an ebook

List of Patterns

All known patterns (grouped into three maturity levels) are as follows:

Maturity Level 3: Validated

Note: We don't have patterns in this stage yet, but are actively working on leveling up patterns into this maturity.

Maturity Level 2: Structured

• 30 Day Warranty - 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.
• 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.
• Maturity Model - Teams have started adopting InnerSource. The practice is spreading to multiple departments. Understanding of what constitutes an InnerSource project are wide spread though. The solution is to provide a maturity model to allow for teams to go through a self check and discover patterns and practices that they are not yet aware of.
• InnerSource License - Two legal entities that belong to the same organization want to share software source code with each other but they are concerned about the implications in terms of legal liabilities or cross-company accounting. An InnerSource License provides a reusable legal framework for the sharing of source code within the organization. This opens up new collaboration options, and makes the rights and obligations of the involved legal entities explicit.
• InnerSource Portal - Potential contributors cannot easily discover InnerSource projects that they are interested in. By creating an intranet website that indexes all available InnerSource project information you enable contributors to learn about projects that might interest them and 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
• Repository Activity Score - The repository activity score is a numeric value that represents the (GitHub) activity of an InnerSource project.
• Review Committee - The InnerSource working model is a radical departure from more traditional approaches, for developers and managers alike. By establishing a review committee as an interface between the InnerSource initiative and all senior managers of business units participating in it, the latter are more likely to familiarise themselves with the initiative and support it, as it affords them a certain level of oversight and control without fostering micromanagement.
• Service vs. Library - 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 InnerSource 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.
• Standard Base Documentation - New contributors to an InnerSource project have a hard time figuring out who maintains the project, what to work on, and how to contribute. Providing documentation in standard files like README.md/CONTRIBUTING.md enables a self service process for new contributors, so that they can find the answers to the most common questions on their own.
• Issue Tracker Use Cases - The InnerSource host team fails to make not only plans and progress but also context for changes transparent. This is solved by increasing the use cases for the project issue tracker to also serve brainstorming, implementation discussion, and feature design.
• Communication Tooling - The users of an InnerSource project have trouble getting help and getting in touch with the host team. By consistently using asynchronous communication tooling, the project makes discussions visible, archived and searchable, leading to an improved level of support for users.
• Cross-Team Project Valuation - It's hard to sell the value of cross-team InnerSource 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.
• Transparent Cross-Team Decision Making using RFCs - InnerSource projects that want to achieve high participation rates and make the best possible decisions for everybody involved need to find ways to create participatory systems throughout the full software lifecycle. Publishing internal Requests for Comments (RFCs) documents allows for discussions early on in the design process, and increases the chances to build solutions with a high degree of commitment from all involved parties.
• Start as an Experiment - Start your InnerSource initiative as a time limited experiment to make it easier for managers unfamiliar with InnerSource to endorse and support the initiative.
• Core Team - Even when an InnerSource project is widely needed, contributions and usage may be hindered because the project is difficult to work with. Establish a core team that is dedicated to take care of the project's fundamental items. Their work enables contributors to add and use the features that provide value to their scenarios.
• Document your Guiding Principles - The usual InnerSource explanation of "applying open source best practices inside an organisation" does not work well with people lacking an open source background. As a remedy the most important principles of InnerSource get documented and published widely.
• Extensions for Sustainable Growth - An InnerSource project is receiving too many contributions, making maintenance difficult. By offering an extension mechanism outside of the core project, the maintainers enable scaling of project capabilities with minimal cost and maintenance overhead.
• Standard Release Process - Teams may hesitate to adopt an InnerSource project if they are unsure of its maturity. To address this, consistent release notes and published artifacts are crucial. These practices showcase a strong dedication to the project, instilling confidence and assuring users of ongoing commitment to sustainable and well-managed software.
• Group Support - What happens if a team or individual no longer supports an InnerSource project? Keep the project alive by forming a group of interested individuals.

Maturity Level 1: Initial

• Modular Code - The lack of modularization in the software architecture prevents reuseability, and with that the ability to reap the benefits of InnerSource. By helping the teams to understand the benefits of modularization, and making time to work towards that goal, more InnerSource collaboration can happen and the software architecture overall can be improved.
• Improve Findability - People can't find the internally developed solutions that they need due to poor naming conventions. This causes frustration in finding InnerSource solutions and a reduction in code reuse.
• 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.
• Introducing Metrics in InnerSource - Involve all stakeholders in designing and interpreting metrics to measure the current status in terms of health and performance of the InnerSource initiative.
• Shared Code Repo Different from Build Repo - Deal with the overhead of having shared code in a separate repository that isn't the same as the project-specific one that is tied to production builds.
• InnerSource Portal - Hygiene - Allow generation of an official badge for projects intending to be recognized as InnerSource project within your company.
• Reluctance to Receive Contributions - Core owner of shared asset is reluctant to take contributions due to the required maintenance that comes with them. Summary pattern that lays out four children patterns with three to be defined.
• Include Product Owners - Engaging and educating Product Owners about InnerSource can help them modify their actions (e.g., in the space of KPIs) to help InnerSource collaboration work better.
• Assisted Compliance - Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.
• Open Source Trumps InnerSource - Developers disregard InnerSource projects because they consider open source projects to be superior. Introducing a required evaluation of InnerSource projects before choosing an open source project increases the likelihood of the InnerSource projects to be adopted.
• Transparent Governance Levels - There are projects in multiple stages of InnerSource adoption. Contributors get confused when working with projects that are at different stages.
• Contained InnerSource - Apply InnerSource methods to facilitate collaboration in a cross-divisional project but don't invest in soliciting contributions from outside of that project.
• Good First Project - An InnerSource program has been launched at an organization, and to get off to a successful start it requires some good first projects that lend themselves to InnerSource-style development. Assessing the InnerSource-readiness (fitness) of the candidate projects can help in selecting projects that have the potential to help demonstrate the power of InnerSource.
• InnerSource Guidance Group - A highly divergent set of development standards in different teams can slow down collaboration between these teams. A InnerSource Guidance Group that establishes broad governance and behavioral guidelines can help to reduce these frictions.
• Unified Source Code Inventory - In a large organization with different legal entities is often hard to get full visibility into all software assets, in particular all source code. This situation reduces the opportunities to increase business value and keep liability costs, such as software maintenance, under control across the organization as a whole. An organization-level source code inventory addresses these issues while exploiting opportunities to identify and support valuable InnerSource assets.
• Explicit Shared Ownership - A software component that several teams depend on has grown to the point where owners are no longer capable of taking full ownership. There is confusion who to involve for changes. Sharing ownership explicitly and making expected behavior visible removes ambiguity. Writing a contributions document creates a natural way to evolve ownership.
• Overcoming the Not-Invented-Here Mindset - Perfectly good solutions are being rejected because of "Not Invented Here" (NIH). Engineers and their managers will choose to implement functionality themselves first, even if an alternative exists. A shift towards a culture of "Proudly Found Elsewhere" can help reduce the negative impact of NIH.
• Balancing Openness and Security - While InnerSource flourishes in environments with a high degree of shared code, Security/Legal prefers the limitation of source code access to only those that need it. By making Security/Legal part of the team, introducing explicit sharing levels and security policies for shared repositories, as well as defining what qualifies as sensitive information, code sharing can be facilitated while minimizing the associated risks.
• Crossing the InnerSource Chasm - Early InnerSource experiments have been successful. Methods that were successful convincing early teams stop working though when scaling the initiative. This chasm can be crossed by using different methods to reach people at different stages of the innovation curve.
• Transitioning Contractor Code to InnerSource Model - Contract developers are often not motivated to engage in InnerSource activities, which may be beyond the scope of their contract. This pattern describes how you can focus on transitioning the contractor project after the fact to an InnerSource project by setting expectations for specific InnerSource-related deliverables as part of the overall project delivery.
• Incubator Pipeline - A team maintaining a widely shared code library wants to accept contributions from other teams, without lowering the overall quality of their library. Therefore the shared library team uses an incubator pipeline to set a lower bar for contributions to enter and a higher bar to exit and become a top-level unit in the library.
• InnerSource Customer Interview Questions - An organization has decided to create an InnerSource program but are unsure which issues they should address first. Using a customer interview will help evaluate pain points across the organization, to prioritize the areas where InnerSource will have the biggest positive impact.
• Creating an InnerSource Strategy - Sometimes, it is difficult to convince people of the relevance of InnerSource for your organization and/or to get support from management. Creating an InnerSource strategy, that connects your InnerSource approach and activities to the goals and the overall strategy of your organization, can help in this regard.
• Code of Conduct - Communications and interactions between collaborators are rude, not inclusive or offensive, harming and increasing the discussions without any value added. A Code of Conduct provides guidelines for establishing rules and expectations regarding behavior and interactions within the community to build stronger levels of collaboration.
• Trusted Committer and Contributor Retrospectives - A host team working with contributors outside of their own line of management constantly runs into misunderstandings. As a result collaboration becomes brittle and frustrating. Setting aside time for regular retrospectives for the InnerSource team consisting of trusted committers and contributors can help make communication smooth.
• InnerSource Hackathon - In a company, initially only InnerSource enthusiasts are interested and practicing InnerSource during the early stages of InnerSource adoption; not all engineering teams are willing or have enough time and resources to adopt InnerSource. In this scenario, it is good to provide a safe space to try and adopt InnerSource through an InnerSource Hackathon event within the company.