Skip to content

Add InnerSource principles to list of draft patterns #325

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 18 commits into from
Jun 30, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
164 changes: 164 additions & 0 deletions patterns/1-initial/principles.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,164 @@
## Title

Explicit InnerSource Principles

## Patlet

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 published widely.

## Problem

The organisation is trying to roll out InnerSource at a larger scale. The
initiative started among open source enthusiasts. The goal is now to get buy-in
from people that are lacking open source experience. For that audience the typical
slogan of "applying open source best practices" is no longer sufficient to
transport the message of what InnerSource is, which problems it solves and which
tools it uses for solving these issues. As a result InnerSource adoption in the
organisation slows down. Teams develop diverging ideas of what the goals of InnerSource
is about and how to best implement it leading to confusion when contributors
are starting to cross team boundaries.

## Story

Early experiments in an organisation have shown that open source collaboration
best practices can be beneficial. The next step now is to move the initiative to
teams and individuals lacking a deep background in open source.

The goal now is to clearly communicate the goals of the InnerSource initiative
as well as a clear path towards achieving these goals.

## Context

* InnerSource as a term is circulating among employees.
* The initiative started among open source enthusiasts.

## Forces

* Teams have trouble communicating exactly what the important aspects of
InnerSource are.

* People lacking open source experience fail to understand what it means to bring
open source best practices into the organisation.

* On a daily basis teams trying to follow InnerSource best practices have a hard
time deciding if what they are doing is inline with general InnerSource values.

## Solution

Those driving the InnerSource initiative in the organisation need to help the teams and individuals that are lacking a deep background in open source, and therefore have a less intuitive understanding of InnerSource.

Clarity should be provided around these two areas:

### Why does the organisation want to adopt InnerSource?

In the past InnerSource has proven to be successful to solve several issues
commonly found in organisations.

However which organizational challenges does your organization hope to improve
upon using InnerSource?

Instead of going for generalizations, try to exactly identify the solutions
that match the challenges of your organisation - preferably with those affected
by the change you want to see.

Some challenges that others have addressed by following InnerSource
best practices:

* Reduce development silos caused by excessive ownership culture.
* Increase innovation speed by reducing time spent solving similar issues by
fostering healthy code reuse.
* Increase development speed by better cross-team collaboration.
* Solve project/ team dependencies beyond "wait it out" and "build workarounds",
thereby reducing engineering bottlenecks.
* Increase quality.
* Increase employee happiness.
* To increase success of new hires.
* To build actionable documentation.

### Which InnerSource principles will help to address these challenges?

Once teams understand which problems InnerSource will help them address, the
next step is to explain which principles help address these challenges.

Based on basic open source development principles the following guidelines
have been proven successful:

(1) Code must be transparently hosted within the organisation

Source code, documentation, data relevant for project development must be
available and easy to find for anyone in the organisation.

(2) Contributions over feature requests

All stakeholders of a project act as potential contributors and are being
treated and supported as such. Contributions remain suggestions instead of
requirements. Coordination before a contribution helps avoid wasted effort.
Projects provide contribution guidelines to avoid friction.

(3) Mistakes are opportunities for learning

With work visible across the entire organisation any mistake is visible to
everyone. As a result a culture must be established in which mistakes are
opportunities for learning instead of failure that should be avoided at all
cost.

(4) Written over verbal communication

For projects that span multiple teams, potentially on diverging meeting
schedules, it needs to be possible to collaborate asynchronously. The goal for
InnerSource projects is to recruit new contributors. For that, potential future
contributors need to be able to follow the project progress on a self serve
basis with a very low barrier to entry. If project relevant communication
happens through synchronous communication, arguments discussed need to be made
transparent in the written channel - decisions should be finalized only there.
As a side effect this leads to passive base documentation that is very valuable
for any newcomer to the project.

(5) Allow written advise to accumulate in a persistent, searchable archive

All project communication, in particular decisions taken and discussions leading
up to those decisions need to be archived. It must be possible to reference
communication via stable URLs. Previous communication needs to be stored in a
way that can easily be searched.

Two caveats though:

1. This does not replace structured documentation. It can serve as a starting point
to collect structured documentation though.

2. There are exceptions to the rule of everything being written and accessible to
the entire organisation: People related discussions as well as security related
discussions are sensitive and should not be held in public.

(6) Reward Trusted Committership

All contributions (e.g. source code, documentation, bug reports, input to
discussions, user support, marketing) are welcome and are being rewarded.
Those showing support for the project are being invited as
[Trusted Committers](../2-structured/trusted-committer.md). All Trusted Committers of a project are published.

## Resulting Context

* Organisation members understand which challenges they can address by
applying InnerSource best practices.

* Organisation members lacking prior open source experience understand the basic
values and principles of InnerSource projects.

* Organisation members lacking prior open source experience are able to check
their daily doing against a set of common established values.

* The organisation's development practices become more similar to open source projects thus
making it easier for organisation members to participate in open source
projects.

## Known Instances

* Europace AG - see also [Europace InnerSource Prinzipien](https://tech.europace.de/post/europace-inner-source-prinzipien/) (German)

## Status

Initial