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

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.

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?

As a tangent: we've seen projects chose expensive COTS over superior InnerSource software, too.

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

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

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?

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.

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

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

I think this is not the problem this pattern addresses. I will add an additional force for this.

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

Proposal: Using corporate licensed InnerSource components instead of using open source components with strong copyleft license avoids having to disclose IP.

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?

I have the same problem.

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.

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?

Yes

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?

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

I have the same reservation.

It may depend on the corporate culture or how this requirement is put in place (there might be a process for finding and evaluating software components or for using open source software). I think it is doable to require this step (we use it in our company).

If this is the core solution of this pattern, then I propose we add language to the context which makes it clear that this solution could be successfully applied.

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

I'll add a link to the InnerSource Portal pattern, instead

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?

@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?

Suggest: Developers select the best component regardless of whether it is open source or internally developed, but they do so with full knowledge of the inner source component, its capabilities, and reasons why it is recommended. Internally developed software components are then more widely and consistently used within the company.

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

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?

We've had quite a few discussions and edits around this. Are there suggestions on who should be included as co-authors to this?

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?

I've slightly changed the phrasing here to make it easier to understand. This reflects my understanding of the rest of the pattern. Please correct if I got the point of the pattern wrong.

This is pretty much equivalent to the Patlet can we deduplicate or remove parts here?

I think this could be phrased clearer, I do not get the full point here. Do you refer to list of suggested OSS / InnerSource solutions? Possibly along the lines of an internal tech radar? Should the external (publicly visible?) GitHub org also list InnerSource solutions?