-
Notifications
You must be signed in to change notification settings - Fork 193
feat: promote discover-your-innersource #780
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
base: main
Are you sure you want to change the base?
Changes from all commits
163c8ce
55182ef
4be02b6
c77a420
3360250
52333fc
bae152f
dd3513c
70a01e3
99ebe10
35f2092
27a45ed
b3fe9d1
211971e
ba32a05
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -4,35 +4,18 @@ | |||||
|
||||||
## Patlet | ||||||
|
||||||
TBD | ||||||
When developers don't look for or can't find internally developed solutions, they may waste time and resources creating redundant software. To solve this, implement a robust internal search engine and processes that encourage the discovery and reuse of internal code. | ||||||
|
||||||
## Also Known As | ||||||
## Problem | ||||||
|
||||||
* Not looking for stuff internally | ||||||
* Don't bother looking | ||||||
* Find it Inside | ||||||
People don't bother looking for internally developed solutions - they might not find the repo at all or be aware of its existence. | ||||||
|
||||||
## Context | ||||||
|
||||||
* Software component(s) are available internally but users can't easily find these. | ||||||
* This problem is more likely to occur in large, federated companies where different organizational units operate as silos. | ||||||
* Historically, the company does not have a culture of sharing code across silos. | ||||||
|
||||||
## Discussion on | ||||||
|
||||||
* Comments may appear in the timeline but not with the file once it is edited (github)? | ||||||
* https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/60 | ||||||
* If only X knew what X knew; the internal search engine is bad. No one can find anything because it is difficult to add things to the search index. | ||||||
* We have similar challenges getting data sources pulled into the search engine. PayPal is building a project called Agora to do this and they are planning to open source it. | ||||||
* Github Enterprise and npmjs have built-in searches on meta-data. Enterprise that opts into these tooling will get some of that functi | ||||||
* Software component(s) are available internally but users can't easily find these. | ||||||
* This problem is more likely to occur where there are silos in the company (e.g., larger companies; smaller companies may have fewer opportunities for reuse of internally developed software). | ||||||
* The company traditionally has been bad at sharing across silos (people don't have the culture of sharing). | ||||||
|
||||||
## Problem | ||||||
|
||||||
People don't bother looking for internally developed solutions - they might not find the repo at all or be aware of its existence. | ||||||
|
||||||
## Forces | ||||||
|
||||||
* No good internal search engine (or not connected to git repositories; and difficult to make this change happen) | ||||||
|
@@ -43,23 +26,26 @@ | |||||
- might not be maintained | ||||||
- might have poor reusability | ||||||
- if someone put out a SW internally, the expectation is that they wouldn't have time to support it (vs. open source options) | ||||||
* Difficulty in adding content to the search index makes it hard for people to find anything | ||||||
|
||||||
## Solution | ||||||
|
||||||
Make it easy to find the reusable code. | ||||||
|
||||||
* Pull in Repo names, descriptions and README.md files into the search engine assuming that a search engine exists. Note: a one-stop-shop kind of search engine for all relevant communication and documentation is difficult to attain. Even when using Github's enterprise offering, people often deploy additional systems like wikis to host content orthogonal to what is in the code repositories, slack channels (or IRC), mailing lists (or even nntp servers), some place to store stuff written down in office formats, search over personal e-mail etc. Several of these systems come with search built-in, but integrating this content in one search box or even just deploying a federated search engine across all sources often doesn't come off-the-shelf. | ||||||
* Consider using existing tools: | ||||||
* GitHub Enterprise and npmjs have built-in searches on meta-data | ||||||
Check failure on line 37 in patterns/2-structured/discover-your-innersource.md
|
||||||
* PayPal's Agora project (planned to be open sourced) addresses similar challenges with data source integration | ||||||
Check failure on line 38 in patterns/2-structured/discover-your-innersource.md
|
||||||
* Implement process change to first check for internal solutions for this problem. | ||||||
* Tool with a central view (but people are more inclined to google externally than look internally) | ||||||
* Concierge service (guide) to help product people find stuff. Might not scale but could be helpful in the beginning. | ||||||
* Need some very visible lighthouse projects that start using inner source components and make positive statements about the inner source program. | ||||||
* Establish a common, asynchronous communication channel (e.g., like slack or metamorph or yammer) across team boundaries. This might not scale beyond a certain organization size. It is possible people will start splitting this one channel into multiple channels by topic once traffic gets too high. Note: having one channel for many users of one tool might be considered an anti-pattern because they can't find it unless they already know about it. | ||||||
* Need some very visible lighthouse projects that start using InnerSource components and make positive statements about the InnerSource program. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This seems unrelated to the problem at hand. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I believe the failure to discover your InnerSource is described here as caused by two potential issues: I would assume the positive examples talking about the benefits of InnerSource components addresses b) Me personally I wouldn't call that lighthouse projects though - most likely because my gut feeling has a very negative co-notation with lighthouse projects. Instead One might talk about early adopters and link to the Crossing the Chasm pattern. |
||||||
* Establish a common, asynchronous communication platform (e.g., chat based) across team boundaries. | ||||||
* This might not scale beyond a certain organization size. | ||||||
* It is possible people will start splitting this one channel into multiple channels by topic once traffic gets too high. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
I think we need a bit of reasoning why one should start with only one communication channel. This might also link to our Communication Tooling pattern. |
||||||
* Note: having one channel for many users of one tool might be considered an anti-pattern because they can't find it unless they already know about it. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't understand that sentence. Maybe instead mention where to mention this communication channel so that downstream users can find it? (E.g. withing the README.md of the project, the CONTRIBUTING.md of the project, ...?) |
||||||
* Encourage (and reward) owners of reusable code to use the same search engine to continually search for products that are candidates for use and adoption of the reusable code but not currently doing so. | ||||||
* Consider creating a marketplace for marketing InnerSource programs (management can use this mechanism to know which InnerSource projects to fund, but seeing how the marketplace reacts). | ||||||
|
||||||
## Known Instances | ||||||
|
||||||
TBD | ||||||
* Consider creating a marketplace for marketing InnerSource programs (management can use this mechanism to know which InnerSource projects to fund, but seeing how the marketplace reacts). - see [Gig Marketplace](../2-structured/gig-marketplace.md) | ||||||
|
||||||
## Resulting Context | ||||||
|
||||||
|
@@ -68,11 +54,16 @@ | |||||
* Developers are now looking internally for software components | ||||||
* Search results are combined (internal and external) | ||||||
* Process changes, establishing a common communications channel, and encouraging and rewarding owners of reusable code to use the same search engine can contribute to changing the corporate culture. Transformation begins from the grassroots but requires strategic involvement of thought leaders. | ||||||
* See [Improved Findability](improve-findability.md) (aka Poor Naming Conventions or Badly Named Piles) as a related pattern. | ||||||
* See [Improved Findability](../1-initial/improve-findability.md) (aka Poor Naming Conventions or Badly Named Piles) as a related pattern. | ||||||
Check failure on line 57 in patterns/2-structured/discover-your-innersource.md
|
||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, we would only link to same maturity or higher. ie omit this link. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm - do we have a way to track the links that we remove from patterns as they move up so that those links can be added back as soon as the patterns one level further below move up as well? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can comment the link to keep the reference but not publish it. Do we like this option? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That sounds like a nice solution. I'm just trying to avoid losing these cross references. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @jeffabailey feel free to try that approach with the commenting.
jeffabailey marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
||||||
## Known Instances | ||||||
|
||||||
* Nike Inc. | ||||||
* WellSky | ||||||
|
||||||
## Status | ||||||
|
||||||
* Initial (brainstormed solution) | ||||||
* Structured | ||||||
|
||||||
## Authors | ||||||
|
||||||
|
@@ -83,4 +74,12 @@ | |||||
|
||||||
## Acknowledgements | ||||||
|
||||||
* Contributions from Russ Rutledge, Ofer Hermoni and Robert Hanmer | ||||||
* Russ Rutledge | ||||||
* Ofer Hermoni | ||||||
* Robert Hanmer | ||||||
|
||||||
## Alias | ||||||
|
||||||
* Not looking for stuff internally | ||||||
* Don't bother looking | ||||||
* Find it Inside |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this mean?