Skip to content

Proven approaches that can guide you through applying open source best practices within your organization

License

Notifications You must be signed in to change notification settings

mahongweichina/InnerSourcePatterns

 
 

Repository files navigation

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 innersourcecommons.gitbook.io/innersource-patterns.

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

You are already using InnerSource in your company and want to share your ideas and experiences with the world? We would love to welcome your contributions!

Mission Statement

Our mission in this working group

  • Collect and document agreed upon best practices of how to do InnerSource - in the form of patterns
  • Continuously publish the most mature patterns as an ebook

List of Patterns

The below lists all known patterns. They are grouped into three maturity levels.

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

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.
  • 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 - 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
  • 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 - An InnerSource project is being used outside the original development team but users are having trouble getting help and getting in touch with the project team. The idea is to setup and document standard communication tooling that allows for discussions to become visible, archived and searchable.
  • 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.

Pattern Drafts (proven, not yet fully reviewed)

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

Maturity Level 1: Initial

Donuts (needing a solution)

What are InnerSource 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 InnerSource 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?

We welcome your contribution - be it small or huge! To learn more about how you can become a contributor, please see our CONTRIBUTING.md file.

Related References

Licensing

Creative Commons License

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

About

Proven approaches that can guide you through applying open source best practices within your organization

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • HTML 51.5%
  • JavaScript 29.5%
  • Ruby 19.0%