## Title

Duplicated Projects

## Patlet

TBD

## Problem

* Multiple teams are doing InnerSource, but they don't want to work together.
* Multiple teams are working on the same product. How do they merge?

## Story

e.g. Splunk.

* 4 unique products have significant overlap. Discovered after opening them up as InnerSource projects.
* This could apply to more than just InnerSource situations

## Context

* Multiple teams (doing InnerSource or not) are trying to tackle the same problem.
* Managers want to run the project in their way.
* Manager B gets upset if something Manager A does breaks B's team.
* It's easier to be mean when you're not face-to-face.

## Forces

* People don't want to lose their jobs (or reason for existence).
* Managers can be territorial with their project.
* People rewrite 100% rather than using the 80% that is already there (even though it would be better to InnerSource).
* Related to the [Not Invented Here](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/64) pattern.
* Related to the [Common Requirements](../2-structured/common-requirements.md) pattern.
* It's like buying another company and having duplicate projects.

## Solutions

* We are lacking a solution of establishing a baseline (which of the 4 projects is the baseline for the merge)?
* An open and transparent process CI/CD, requirements backlog, deployment, etc.
* Anyone participates in the process in the same way.
* Project lead is assisted by the former managers.
* Move away from (benevolent) dictator (e.g. eng. manager?).  Could this be hard to achieve?
* Experience has shown that if people are in the same room then things tend to go better.  Not so much by email/phone.  You are nicer if you see the people.

## Resulting Context

* Managers have been convinced to be a part of the solution.
* Managers are bought in to a process where they have left some control but still retain influence.

## Status

* Initial
