Duplicated Projects
TBD
- 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?
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
- 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.
- 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 pattern.
- Related to the Common Requirements pattern.
- It's like buying another company and having duplicate projects.
- 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.
- 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.
- Initial