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

pattern/open-source-trumps-innersource #46

Open
wants to merge 3 commits into
base: master
from

Conversation

@InnerSrcAdmin
Collaborator

InnerSrcAdmin commented Feb 22, 2017

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.

NEXT STEP: Needs to be revised and reviewed
NOTES: Needs further clarification - 2016-10-27

## Statement of Problem
* 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.
* ORIGINAL: Developers tend to select open source components rather than internally developed components, which results in poorer quality components or also makes it difficult to sustain internal component development.
* NEW: Different BLs are selecting different SW components to do the same function, resulting in inconsistencies in the user experience.

This comment has been minimized.

@gruetter

gruetter Feb 28, 2017

Collaborator

What does BL stand for? Is it business line? Is this different from a BU (business unit)?

This comment has been minimized.

@NewMexicoKid

NewMexicoKid May 3, 2017

Collaborator

BL = Business Line. Typically there are multiple BLs in a Business Unit; but I can guess this varies depending on company.

## Forces
* There is a perception that the open source components are higher quality and more reusable. The channels to get any needed changes are more obvious with open source than with internal components. Can easily grab the open source whereas internally developed component has less visibility and ease of availability. (This could be separate Pattern). All things equal, they gravitate towards open source.
* Open source should be voluntary; mandating people to use internally developed software goes against open source principles.

This comment has been minimized.

@gruetter

gruetter Feb 28, 2017

Collaborator

I personally don't think this is a strong force. IMHO, voluntariness pertains more to the development of and making contributions to OSS, not necessarily to using it.

* ORIGINAL: Internal component is well written and there are no quality problems with the software. Whatever component is selected does not need to be forked. The internal component was created and more complete before the open source was available. People are aware there is an internally developed software component.
* ADDED: People look for software through external search engines.
## Forces

This comment has been minimized.

@gruetter

gruetter Feb 28, 2017

Collaborator

One more possible force in favour of using InnerSource components: licensing. Depending on the regulations within a company, it might be easier to use a corporate licensed, InnerSource component than an open source component which is licensed in a way that requires the company to disclose IP.

## Statement of Problem
* 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.
* ORIGINAL: Developers tend to select open source components rather than internally developed components, which results in poorer quality components or also makes it difficult to sustain internal component development.
* NEW: Different BLs are selecting different SW components to do the same function, resulting in inconsistencies in the user experience.

This comment has been minimized.

@gruetter

gruetter Feb 28, 2017

Collaborator

Might this be a problem for a dedicated pattern/donut? I feel this is not so much related to OSS trumping InnerSource.

## Resolution
Corporate requirement that internally developed components should be evaluated before we go outside to search for open source component. If the open source component is now more mature, replace the internally developed with the open source. Create some extrinsic rewards to encourage them (initially). Make it easier to find the internal component (discoverability and visibility). Make the process simple and aligned with well known open source methods.
Provide an internal instance of GitHub Enterprise or an well publicized external GitHub organization repo to allow employees to easily find internally developed solutions. Assign maintainers to make sure proper open source processes are being followed within the leading repos. Provide “value add” services linked to the formal repo solution such as automated CI/CD services, IaaS/PaaS, NPM organization/server linkages, ChatOps, etc.

This comment has been minimized.

@gruetter

gruetter Feb 28, 2017

Collaborator

I personally feel that assigning maintainers is the key solution here. I think it deserves a bullet point of its own.

Update open-source-trumps-innersource.md
Cleaned up the pattern. Ready for review #1. 2017-05-10
@@ -0,0 +1,35 @@
## Title
Open Source trumps InnerSource

This comment has been minimized.

@rrrutledge

rrrutledge Feb 15, 2018

Collaborator

Interested in a Patlet in this pattern?

This comment has been minimized.

@NewMexicoKid

NewMexicoKid Feb 15, 2018

Collaborator

Yes, it would be good to add:

Patlet

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.

Open Source trumps InnerSource
## Statement of Problem
* 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.

This comment has been minimized.

@rrrutledge

rrrutledge Feb 15, 2018

Collaborator

It's not clear to me that this behavior is a problem.

This comment has been minimized.

@NewMexicoKid

NewMexicoKid Feb 15, 2018

Collaborator

I think the core problem is that people's mindset is that open source is always superior to InnerSource, which often is not the case. The result is that this bias leads people to select and use inferior components, perhaps having to put effort to adapting them that would otherwise go towards improving and reusing the InnerSource component.

This comment has been minimized.

@rrrutledge

rrrutledge Feb 15, 2018

Collaborator

I see. I think that point would be useful to roll into the statement - the inner source component meets their needs better than an open source component. They should choose the component that best meets their needs irrespective of it being open source vs. inner source?

## 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.

This comment has been minimized.

@rrrutledge

rrrutledge Feb 15, 2018

Collaborator

This comment doesn't have to be addressed right now, but in the log run it would be nice if our patterns had consistent terminology (glossary) for terms like these (Business Lines).

Update open-source-trumps-innersource.md
Putting each sentence on its own line.  Doesn't change the look of the rendered markdown, but makes the document easier to review and comment.
@rrrutledge

These thoughts are great, Nick. I like the broad themes and big-picture items that you've outlined here and am excited to discuss more of the details.

## Forces
* There is a perception that the open source components are higher quality and more reusable. The channels to get any needed changes are more obvious with open source than with internal components. Can easily grab the open source whereas internally developed component has less visibility and ease of availability. (This could be separate Pattern). All things equal, they gravitate towards open source.
* Open source should be voluntary; mandating people to use internally developed software goes against open source principles.
* Internally developed components should have advantages over competing open source. If you can clearly demonstrate this, it can be persuasive.

This comment has been minimized.

@rrrutledge

rrrutledge Feb 15, 2018

Collaborator

This line seems like part-Context (Internally developed components should have advantages over competing open source) and part-Solution (If you can clearly demonstrate this, it can be persuasive.) rather than Forces.

* There is a perception that the open source components are higher quality and more reusable. The channels to get any needed changes are more obvious with open source than with internal components. Can easily grab the open source whereas internally developed component has less visibility and ease of availability. (This could be separate Pattern). All things equal, they gravitate towards open source.
* Open source should be voluntary; mandating people to use internally developed software goes against open source principles.
* Internally developed components should have advantages over competing open source. If you can clearly demonstrate this, it can be persuasive.
* Part of the reason this is a problem: if different teams are picking different open source components, the situation makes interoperability and integration more difficult; and this could potentially impact the user experience (inconsistency in behaviors).

This comment has been minimized.

@rrrutledge

rrrutledge Feb 15, 2018

Collaborator

If this is a problem then put it in the Problem section.

* Open source should be voluntary; mandating people to use internally developed software goes against open source principles.
* Internally developed components should have advantages over competing open source. If you can clearly demonstrate this, it can be persuasive.
* Part of the reason this is a problem: if different teams are picking different open source components, the situation makes interoperability and integration more difficult; and this could potentially impact the user experience (inconsistency in behaviors).
* Depending on the regulations within a company, it might be easier to use a corporate licensed, InnerSource component than an open source component which is licensed in a way that requires the company to disclose IP.

This comment has been minimized.

@rrrutledge

rrrutledge Feb 15, 2018

Collaborator

Use more clear, definite language (rather than conditional).

* Internally developed components should have advantages over competing open source. If you can clearly demonstrate this, it can be persuasive.
* Part of the reason this is a problem: if different teams are picking different open source components, the situation makes interoperability and integration more difficult; and this could potentially impact the user experience (inconsistency in behaviors).
* Depending on the regulations within a company, it might be easier to use a corporate licensed, InnerSource component than an open source component which is licensed in a way that requires the company to disclose IP.
* There may be many silos in the company; it would then be difficult to reach the developer base across those silos.

This comment has been minimized.

@rrrutledge

rrrutledge Feb 15, 2018

Collaborator

It's unclear to me what these two last bullet points are trying to get at or how they are uniquely appropriate to describing this pattern?

* It can be hard to find stuff in github (especially if names are cryptic and keywords aren't used). See [Poor Naming Conventions](https://github.com/paypal/InnerSourcePatterns/pull/59).
## Sketch
See figure 1 in https://drive.google.com/open?id=0B7_9iQb93uBQNlJ0YU5wWmpWYUU

This comment has been minimized.

@rrrutledge

rrrutledge Feb 15, 2018

Collaborator

If I understand the diagram (and this article) right, then it looks like the diagram suggests that it is preferable to use an inner source project over an open source project in areas of software that are differentiating to the company's core business?

See figure 1 in https://drive.google.com/open?id=0B7_9iQb93uBQNlJ0YU5wWmpWYUU
## Resolution
* Corporate requirement that internally developed components should be evaluated before we go outside to search for open source component.

This comment has been minimized.

@rrrutledge

rrrutledge Feb 15, 2018

Collaborator

I doubt the ability for such a requirement to have real, lasting, and actual affect on employee behavior.

## Resolution
* Corporate requirement that internally developed components should be evaluated before we go outside to search for open source component.
If the open source component is now more mature, replace the internally developed with the open source. Create some extrinsic rewards to encourage them (initially).
Make it easier to find the internal component (discoverability and visibility).

This comment has been minimized.

@rrrutledge

rrrutledge Feb 15, 2018

Collaborator

Quite a bit of overlap with Create a tool with a central view of internally available software. Maybe just delete this sentence?

## Sketch
See figure 1 in https://drive.google.com/open?id=0B7_9iQb93uBQNlJ0YU5wWmpWYUU
## Resolution

This comment has been minimized.

@rrrutledge

rrrutledge Feb 15, 2018

Collaborator

A lot of these suggested resolutions are (gut-feel) very large undertakings and outside the realm of reasonableness to just go and do. I agree that they would help the situation your describing, but feel that they are large to the point of their not having practical utility in including them here as independent items. Perhaps some of them need to be their own pattern and linked to from here? Or perhaps the need to include such large items as a solution indicates that the problem space that this pattern is trying to address is too broad?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment