pattern/open-source-trumps-innersource #46
Conversation
InnerSrcAdmin
requested review from
nyeates,
NewMexicoKid,
gruetter and
ErinMB
open-source-trumps-innersource.md
Outdated
|
|
||
| ## 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Could any of you two (@gruetter @NewMexicoKid) suggest any possible commit suggestion to modify this or resolve this discussion?
open-source-trumps-innersource.md
Outdated
| ## 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. |
There was a problem hiding this comment.
Might this be a problem for a dedicated pattern/donut? I feel this is not so much related to OSS trumping InnerSource.
There was a problem hiding this comment.
You meant that this one could go to it's own pattern instead, right?
Different Business Lines (BLs) are selecting different SW components to do the same function, resulting in inconsistencies in the user experience.
Will leave this thread open but I think it should not prevent us from merging this PR.
nyeates
added
2 - Do 1st Review
3-validated
Cleaned up the pattern. Ready for review #1. 2017-05-10
open-source-trumps-innersource.md
Outdated
|
|
||
| ## 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 was a problem hiding this comment.
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).
There was a problem hiding this comment.
An additional effect possibly worth mentioning is that this will also result in more effort for procurement and supplier management.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Keeping this comment open, to make it easier to find this comment after the PR is merged.
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.
open-source-trumps-innersource.md
Outdated
| ## 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. |
There was a problem hiding this comment.
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 was a problem hiding this comment.
@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.
There was a problem hiding this comment.
I cannot tell if this thread has been worked into the latest version of the pattern already. Will leave the tread open.
open-source-trumps-innersource.md
Outdated
| * 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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
open-source-trumps-innersource.md
Outdated
| * 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
open-source-trumps-innersource.md
Outdated
| ## Sketch | ||
| See figure 1 in https://drive.google.com/open?id=0B7_9iQb93uBQNlJ0YU5wWmpWYUU | ||
|
|
||
| ## Resolution |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
@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?
There was a problem hiding this comment.
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)
maxcapraro
added
the
Stale
|
Hi @NewMexicoKid @gruetter @rrrutledge (mentioning you as you spent quite some time on this PR already). We have reworked the maturity levels of the InnerSource patterns. The new levels make it more explicit what quality standards are expected for each level. With that we will also try to get PRs merged into master faster. Status of this pattern: We have currently categorized the Pattern in this PR as maturity level Level 2 - Structured. For that level we have two requirements:
How to get this PR merged?
I have no time to work on this, what to do? As this PR is open for a while, it would be completely understandable if your priorities have shifted and you don't time to work on this anymore. In that case please just let us know in a comment below. Then we can decide what to do with this PR on our own. Thank you for your help! 👍 |
|
Thanks @spier for adding this update. |
|
Thanks for this message, @lenucksi. I'm un-opinionated about what happens to my comments :) |
gruetter
requested review from
cewilliams,
lenucksi and
nyeates
as code owners
There was a problem hiding this comment.
Pattern looks good now and ready to merge, IMHO. I have not yet heard of a company which successfully adopted the core of the solution (mandate considering IS SW before OSS). The pattern conforms to the common structure, though. Therefore, I think the proper maturity level is 2-structured, @spier , @lenucksi . I'll update the PR tag accordingly.
open-source-trumps-innersource.md
Outdated
|
|
||
| ## 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 was a problem hiding this comment.
An additional effect possibly worth mentioning is that this will also result in more effort for procurement and supplier management.
open-source-trumps-innersource.md
Outdated
| * 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. |
open-source-trumps-innersource.md
Outdated
| ## Sketch | ||
| See figure 1 in https://drive.google.com/open?id=0B7_9iQb93uBQNlJ0YU5wWmpWYUU | ||
|
|
||
| ## Resolution |
There was a problem hiding this comment.
@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?
gruetter
added
2-structured
There was a problem hiding this comment.
Thanks a lot for the review and work towards resolving open discussions @gruetter, @NewMexicoKid and @rrrutledge!
Pattern looks good now and ready to merge, IMHO. I have not yet heard of a company which successfully adopted the core of the solution (mandate considering IS SW before OSS). The pattern conforms to the common structure, though. Therefore, I think the proper maturity level is 2-structured, @spier , @lenucksi . I'll update the PR tag accordingly.
The contribution handbook has this as a verification requirement for 2-structured:
Is validated by at least one known instance
- Alternatively: key elements of the pattern have been validated in separate contexts and, in consequence, it is justified to believe the full solution will function
What are the key elements that have been validated in separate contexts here if there is no successful instance of deployment?
I've also added a few review comments and commit suggestion after reading the current result. This is a very interesting pattern. 😄
And as a last element: Independent of this being merged as 2-structured or 1-initial we need a follow-up pull request changing moving the file to the according directory structure.
open-source-trumps-innersource.md
Outdated
|
|
||
| ## 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. |
There was a problem hiding this comment.
Could any of you two (@gruetter @NewMexicoKid) suggest any possible commit suggestion to modify this or resolve this discussion?
open-source-trumps-innersource.md
Outdated
| * 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 |
There was a problem hiding this comment.
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?
open-source-trumps-innersource.md
Outdated
|
|
||
| ## 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 was a problem hiding this comment.
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?
lenucksi
added
the
📖 Type - Content Work
Co-authored-by: Johannes Tigges <[email protected]>
…rumps-innersource
…lso call out InnerSource more explicitly.
…file instead of PR, and using new Patlet.
…arly indicate that there are none yet. Adding myself as co-author :)
|
I have reviewed this PR in detail, following this approach:
I opted to move this pattern to I think this pattern has higher chances of improving by getting more readership, which is easier to achieve once merged. Therefore my suggestion for getting this PR merged are this:
Follow a done is better than perfect approach, I will wait until Friday 2021-02-05. Then I will work in any new feedback and get this merged as outlined above. Any feedback from others is welcome, as always! :) |
|
Timer is up :) Found the original image for the one used in the sketch, and copied it to Also added a link to this PR to the pattern, so that anybody working on this in the future can easily find the open conversations in here. |
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