pattern/open-source-trumps-innersource (#46)

Create open-source-trumps-innersource.md (originally from 2017) Co-authored-by: Tim Yao <[email protected]> Co-authored-by: rrrutledge <[email protected]> Co-authored-by: Georg Gruetter <[email protected]> Co-authored-by: Sebastian Spier <[email protected]> Co-authored-by: Johannes Tigges <[email protected]>
InnerSourceCommons · Feb 5, 2021 · 73c7d11 · 73c7d11
1 parent 2402f05
commit 73c7d11
Show file tree

Hide file tree

Showing 3 changed files with 69 additions and 6 deletions.
diff --git a/README.md b/README.md
@@ -30,8 +30,6 @@ The below lists all known patterns. They are grouped into three [maturity levels
 
 ### Maturity Level 2: Structured
 
-#### Reviewed Patterns (proven and reviewed)
-
 * [30 Day Warranty](patterns/2-structured/30-day-warranty.md) - *a pattern for getting a reluctant code-owning team to accept code submissions from outside their team.*
 * [Common Requirements](patterns/2-structured/common-requirements.md) - *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](patterns/2-structured/contracted-contributor.md) - *Associates wanting to contribute to InnerSource are discouraged from doing so by their line management. Relief is provided by formal contracts and agreements.*
@@ -52,10 +50,6 @@ The below lists all known patterns. They are grouped into three [maturity levels
 * [Transparent Cross-Team Decision Making using RFCs](patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md) - *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](patterns/2-structured/start-as-experiment.md) - *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)
-
-* [Open Source Trumps InnerSource](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/46) - *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
 
 * [Modular Code](patterns/1-initial/modular-code.md) - *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.*
@@ -76,6 +70,7 @@ The below lists all known patterns. They are grouped into three [maturity levels
 * [Reluctance to Receive Contributions](patterns/1-initial/reluctance-to-accept-contributions.md) - *Core owner of shared asset is reluctant to take contributions due to the required maintenance that comes with them. Summary pattern that lays out four children patterns with three to be defined.*
 * [Include Product Owners](patterns/1-initial/include-product-owners.md) - *Engaging and educating Product Owners about InnerSource can help them modify their actions (e.g., in the space of KPIs) to help InnerSource collaboration work better.*
 * [Assisted Compliance](patterns/1-initial/assisted_compliance.md) - *Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.*
+* [Open Source Trumps InnerSource](patterns/1-initial/open-source-trumps-innersource.md) - *Developers disregard InnerSource projects because they consider open source projects to be superior. Introducing a required evaluation of InnerSource projects before choosing an open source project increases the likelihood of the InnerSource projects to be adopted.*
 * [Transparent Governance Levels](patterns/1-initial/governance-levels.md) - *There are projects in multiple stages of InnerSource adoption. Contributors get confused when working with projects that are at different stages.*
 
 #### Donuts (needing a solution)

diff --git a/assets/img/landscape-of-effective-and-efficient-software-development.png b/assets/img/landscape-of-effective-and-efficient-software-development.png
diff --git a/patterns/1-initial/open-source-trumps-innersource.md b/patterns/1-initial/open-source-trumps-innersource.md
@@ -0,0 +1,68 @@
+## Title
+
+Open Source trumps InnerSource
+
+## Patlet
+
+Developers disregard InnerSource projects because they consider open source projects to be superior. Introducing a required evaluation of InnerSource projects before choosing an open source project increases the likelihood of the InnerSource projects to be adopted.
+
+## Problem
+
+People find the InnerSource project but, even if the InnerSource component meets their needs better than the respective open source component, they choose the open source component over the InnerSource component.
+
+## Context
+
+* People look for software through external search engines.
+* Different Business Lines (BLs) are selecting different SW components to do the same function, resulting in inconsistencies in the user experience.
+* There may be many silos in the company; it would then be difficult to reach the developer base across those silos.
+* The company culture is based on strong governance.
+
+## Forces
+
+* There is a perception that the open source components are of higher quality and more reusable than the InnerSource components. This is caused by the common belief that open source always means many more developers and users and therefore higher quality. This is sometimes the case in open source but not always!
+* The channels to get needed changes done are more established with open source (GitHub) than with internal components (GitHub Enterprise, Bitbucket, GitLab, Gerrit - possibly multiple installations in one company).
+* Open source should be voluntary; mandating people to use internally developed software goes against open source principles.
+* Internally developed components are potentially more suitable for corporate use if they are designed with that in mind.
+* Using corporate licensed InnerSource components instead of using open source components with strong copyleft license avoids having to disclose IP
+* It can be hard to find relevant projects in GitHub (especially if names are cryptic and keywords aren't used). See [Poor Naming Conventions](https://github.com/paypal/InnerSourcePatterns/pull/59).
+* The consistent use of internally developed components potentially reduces the diversity of the internal software landscape compared to a situation where every business line chooses their own, favourite open source component.
+
+## Sketch
+
+![The landscape of effective and efficient software development](/assets/img/landscape-of-effective-and-efficient-software-development.png "The landscape of effective and efficient software development")
+
+**Source:** [Commodification of Industrial Software: A Case for Open Source](https://www.semanticscholar.org/paper/Commodification-of-Industrial-Software%3A-A-Case-for-Linden-Lundell/54d6cb77a86e292ff1845eb910c1a1f258e6cee3), F. Linden, B. Lundell, P. Marttiin, Published 2009, Engineering, Computer Science, IEEE Software
+
+## Solutions
+
+* Corporate governance mandates that internally developed components are to be evaluated before open source component are selected.
+* Make it easier to find relevant InnerSource components (see [InnerSource Portal](../2-structured/innersource-portal.md)).
+* Assign maintainers to make sure proper open source processes are being followed within the leading repos.
+* Increase the attractiveness of InnerSource components by providing “value add” services for them, such as automated CI/CD services, IaaS/PaaS, NPM organization/server linkages, ChatOps, etc.
+
+## Resulting Context
+
+* Developers select the best component regardless of whether it is open source or internally developed (InnerSource). They do so with full knowledge of the InnerSource component, its capabilities, and reasons why it is recommended.
+* By doing so, InnerSource components end up being more widely and consistently used within the company.
+
+## Known Instances
+
+TBD
+
+## Status
+
+Initial
+
+## Author
+
+* As told to Padma Sudarsan, 2016-09-30
+* Tim Yao
+* Georg Gruetter (Robert Bosch GmbH)
+* Russ Rutledge
+* Johannes Tigges
+* Sebastian Spier
+
+## References
+
+* Some interesting conversation threads from the time when this pattern was created can be found in [this PR](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/46/).
+* [Commodification of Industrial Software: A Case for Open Source](https://www.semanticscholar.org/paper/Commodification-of-Industrial-Software%3A-A-Case-for-Linden-Lundell/54d6cb77a86e292ff1845eb910c1a1f258e6cee3), F. Linden, B. Lundell, P. Marttiin, Published 2009, Engineering, Computer Science, IEEE Software