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

rrrutledge/InnerSourcePatterns

 
 

Repository files navigation

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.

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 CONTRIBUTING.md 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).

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 - The common code in the shared repository isn't meeting the needs of all the projects that want to use it.
  • Contracted Contributor - Solutions for when associates wanting to contribute to an InnerSource project are discouraged from doing so by their line management
  • Dedicated Community Leader - When starting an InnerSource initiative it is crucial to nominate the right people to lead the communities. Selecting the wrong persons and/or not providing enough capacity for them risks wasted effort and ultimately the failure of the InnerSource initiative. The person needs both communication skills as well as technical.
  • Review Committee - A formal review committee is setup within an org to "officiate" particular inner source projects with resources, etc.

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.
  • Poor Naming Conventions - 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)

Pattern Ideas (not yet proven; brainstormed)

Pattern Donuts (needing a solution)

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 Collaborators - 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

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