Skip to content

pattern/discover-your-innersource #60

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 5 commits into from
Sep 22, 2017
Merged

pattern/discover-your-innersource #60

Changes from 2 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
15e49c7
Created
Mar 11, 2017
6673b57
Implemented Bob's comment
NewMexicoKid Sep 5, 2017
8879d39
Update dont-bother-looking.md
NewMexicoKid Sep 22, 2017
e4bf834
Update dont-bother-looking.md
NewMexicoKid Sep 22, 2017
121425b
Rename dont-bother-looking.md to discover-your-innersource.md
NewMexicoKid Sep 22, 2017
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
49 changes: 49 additions & 0 deletions dont-bother-looking.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
## Title
* Don't bother looking

## Also Known As
* Not looking for stuff internally

## Context
* 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)
* Users may not know there are common places to find internally developed solutions.
* People don't expect to find solutions internally.
* Many silos in the company; difficult to reach the developer base across those silos (a communications problem).
* People might not want to use internal SW because they don't believe it will be helpful
- 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)

## Solution
Make it easy to find the reusable code.
Copy link
Contributor

@rrrutledge rrrutledge Sep 12, 2017

Choose a reason for hiding this comment

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

Another avenue to explore is making it easy for the reusable code to find you. Create ways for the people running shared internal code to discover which other projects are reasonable candidates for adoption so that they can reach out.

Copy link
Collaborator

@NewMexicoKid NewMexicoKid Sep 12, 2017

Choose a reason for hiding this comment

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

Do you have some examples of what works to solve the discovery problem?

Copy link
Contributor

@rrrutledge rrrutledge Sep 13, 2017

Choose a reason for hiding this comment

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

Search through source code at the company for projects that are candidates to use the shared internal tool and then reach out to committers to those repos.

Copy link
Contributor

@rrrutledge rrrutledge Sep 22, 2017

Choose a reason for hiding this comment

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

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


* Pull in Repo names, descriptions and README.md files into the search engine
Copy link
Contributor

@rrrutledge rrrutledge Sep 12, 2017

Choose a reason for hiding this comment

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

What kind of search engine are we thinking of here?

Copy link
Collaborator

@NewMexicoKid NewMexicoKid Sep 12, 2017

Choose a reason for hiding this comment

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

Probably whatever internal search engine people would use to try to find internally available software.

Copy link
Contributor

@rrrutledge rrrutledge Sep 13, 2017

Choose a reason for hiding this comment

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

That assumes that such a search engine exists. It seems like some enterprise tooling has this kind of functionality built in, so the systems that a company is using may affect its ability to follow this part of the pattern. In my experience systems like GitHub and npmjs try hard to include project search as a first-class feature. I assume that their enterprise editions to the same, so companies using those tools would have an easier time implementing this advice.

Copy link
Member

@MaineC MaineC Sep 13, 2017

Choose a reason for hiding this comment

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

Even if a search engine exists internally, what I find really helpful is to have a one-stop-shop kind of search engine for all relevant communication and documentation. 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.

Copy link
Contributor

@rrrutledge rrrutledge Sep 13, 2017

Choose a reason for hiding this comment

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

Do you have examples of what a good search engine solution would be to aggregate many sources of information like that? I've gotten the impression that it's not an easy problem.

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

@MaineC MaineC Sep 11, 2017

Choose a reason for hiding this comment

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

Something I would add here is establishing a common communication channel across team boundaries. This might not scale beyond a certain organisation size. My expectation would be that people start splitting this one channel into multiple by topic once traffic gets too high.

* Need some very visible lighthouse projects that start using inner source components and make positive statements about the inner source program.

## Known instances

## Desired Resulting Context
* Internal components are easily visible
* Developers looking for code can search for it and find it quickly.
* Developers are now looking internally for software components
* Search results are combined (internal and external)

## Status
Brainstormed pattern idea in progress

## Authors
* Georg Grutter
* Erin Bank
* Padma Sudarsan
* Tim Yao