Skip to content

pattern/open-source-trumps-innersource #46

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.

Sign up for GitHub

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 20 commits into from
Feb 5, 2021
Merged

pattern/open-source-trumps-innersource #46

Changes from 3 commits
Commits
Show all changes
20 commits
Select commit Hold shift + click to select a range
cdb394c
Create file
InnerSrcAdmin Feb 22, 2017
635ad95
Update open-source-trumps-innersource.md
NewMexicoKid May 11, 2017
7095777
Update open-source-trumps-innersource.md
rrrutledge Feb 15, 2018
8ce1bc0
followed up on PR suggestions #46
gruetter Sep 21, 2020
ad970f0
Merge pull request #216 from InnerSourceCommons/oss-trumps-is
gruetter Sep 21, 2020
1cbb243
Update open-source-trumps-innersource.md
spier Jan 30, 2021
f5c6311
Merge remote-tracking branch 'origin/master' into patch/open-source-t…
spier Jan 30, 2021
06fcbdf
Moving pattern to 1-initial
spier Jan 30, 2021
44c46ce
fix linter issues. adapting pattern to template.
spier Jan 30, 2021
8707512
Splitting up Resulting Context into bullets to improve readability. A…
spier Jan 31, 2021
b1f8caa
make link to other pattern relative rather than absolute
spier Jan 31, 2021
0b748fc
Working in feedback from various threads on the PR.
spier Jan 31, 2021
b52e93d
Adding a new patlet that contains both problem and solution.
spier Jan 31, 2021
3a483d2
Moving pattern to the Initial section in the README. also linking to …
spier Jan 31, 2021
e05c8fa
renamign Problem section. Adding empty Known Instances section to cle…
spier Jan 31, 2021
6e5d2a0
spelling out 'stuff'
spier Jan 31, 2021
0328d15
Merge branch 'master' into patch/open-source-trumps-innersource
spier Feb 5, 2021
e3ff5d1
Found the original of the sketch used in this pattern. yay
spier Feb 5, 2021
2896822
removing now-uncessesary sub-sections in the README
spier Feb 5, 2021
3747876
adding IEEE paper to the references section
spier Feb 5, 2021
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
40 changes: 40 additions & 0 deletions open-source-trumps-innersource.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
## Title
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.

## 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An additional effect possibly worth mentioning is that this will also result in more effort for procurement and supplier management.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've referenced @rrrutledge point into #170.

I've seen @gruetter and @NewMexicoKid agreeing on the possible need to mention the procurement and supplier management point. Can any of you two create a commit suggestion or a commit around this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keeping this comment open, to make it easier to find this comment after the PR is merged.


## 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could any of you two (@gruetter @NewMexicoKid) suggest any possible commit suggestion to modify this or resolve this discussion?

* Internally developed components should have advantages over competing open source. If you can clearly demonstrate this, it can be persuasive.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rrrutledge how about: Internally developed components can be made more robust and better suited towards corporate needs. Reasons for preferring inner source over open source alternatives might include issues with the open source license, use of proprietary and/or patented components, and functional/competitive advantages. The more that such internal components are used within a company, the better the ROI for the inner source development efforts. On the other hand, open source advances can sometimes leap frog internal development and without periodic assessment, it can be difficult to know when to stop investment in inner source development and switch to the adoption of open source components.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I cannot tell if this thread has been worked into the latest version of the pattern already. Will leave the tread open.

* 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have the same problem.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the point of this force is that it can be difficult to fight perception among dispersed and silo'd engineering staff and to communicate (1) that the inner source project exits, (2) that it has advantages over competing open source, (3) that there are legitimate reasons for preferring the inner source over competing open source software.

* 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about the following:

  • Add this .jpg to the repo maybe in /assets/ or something similar such that it can be rendered with the pattern? Also, who created the image and are there possibly any copyrights attached to it that we need to take into account?
  • Should there be some phrasing adding the insight from the image into the text?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "owner" of the picture in gDrive is @NewMexicoKid and it was created 11.10.2016, 18:33.
Not sure if that helps us to figure out where it originally came frame?

I also did a google image search for the picture and parts of the text, but could find anything.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found the original source for this image. Yay :)
https://www.semanticscholar.org/paper/Commodification-of-Industrial-Software%3A-A-Case-for-Linden-Lundell/54d6cb77a86e292ff1845eb910c1a1f258e6cee3


## Resolution
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rrrutledge : Are you ok with merging with the current state of the resolution section (there has been a slight rework), or do you think further rework is needed before merging?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I agree that the Solutions section is asking for a lot right now, I suggest that we just leave this as is and get the pattern published as Initial. That will make it easier for others to find, read, and improve this pattern in the future if anybody has actually found a working solution for this problem. (right now we don't have a Known Instance yet, so this isn't a proven solution yet)

* 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).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this needs to be qualified. It the OSS component has strong copyleft, it might make sense to re-engineer its relevant parts in an IS project.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On 2nd thought, I think we should remove this bullet point, as it doesn't really solve the underlying problem.

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.
* Create a tool with a central view of internally available software, but be aware that people are more inclined to google externally than look internally.

## Resulting Context
Developers do select the best component regardless of whether it is open source or internally developed. Internally developed software components are then more widely reused.

## Author
As told to Padma Sudarsan, 2016-09-30

## Status
Draft, incomplete (in progress)