Skip to content

pattern/contained-innersource #13

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

Closed
wants to merge 4 commits into from
Closed

pattern/contained-innersource #13

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
43a30de
added pattern “Contained InnerSource Enables Collaborative Product De…
gruetter Dec 5, 2016
d743f7f
renamed file to contained-innersource.md; edited in revisions
NewMexicoKid Dec 7, 2016
473639b
Simplified Title
nyeates Dec 15, 2016
c42c7fa
Merge branch 'master' into pattern/contained-innersource-enables-coll…
nyeates Feb 2, 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
35 changes: 35 additions & 0 deletions contained-innersource-enables-collaborative-product-development.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
## Title
Contained inner source enables collaborative product development
Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a mouthful ;). How about just Contained InnerSource?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Okay.


## Context
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is there a previously written component of is this a green field situation? I think it matters in the case where one of the BUs is the current owner of the component.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Georg, this is your scenario, so is your question rhetorical?
I had gotten the impression when we were talking about this (in the dim sum place) that it was indeed the case that one BU was the current owner of the component. Is this the case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I assumed this was the Nokia case. In my company, I'm not aware of any example that exactly matches this one. I guess it was a hypothetical thought.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Should we change it so that it matches something that you've seen work? Otherwise, this would just be a pattern idea. Did I misunderstand our discussion in the dim sum dinner? Or mis-document it?

* Multiple business units need a software component.
* It makes sense for the business units to collaborate; each needs some different changes to the code.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe write that the BUs are in agreement that it makes sense to collaborate. This would be more clear to me.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Okay.

Copy link
Contributor Author

@gruetter gruetter Dec 6, 2016 •
edited
Loading

Choose a reason for hiding this comment

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

Btw. @NewMexicoKid , just like in Slack, you can use Emojis to signal you Okay. Tends to keep the comment stream leaner.

* One BU doesn't have the resources to do the development for all the rest.
* InnerSource programs and tools exist.

## Problem
The company needs to develop a software product component; multiple business units use this component.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

That sounds more like context to me. Since the BUs are already in agreement to collaborate and given the solution below, is the problem related to the degree of openness of a collaboration (uncontained)?

Copy link
Collaborator

Choose a reason for hiding this comment

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

We can move this to context. So would the Problem be:
The uncontained inner sourcing of the collaboration is regarded as distracting from the needed efficiency of specific collaborative development with the other BUs sharing the use of this component, but normal development practices do not effectively work with sharing of development resources to work on this component.


## Forces
* The product's importance to company revenue and the committed feature content and dates require a development paradigm that provides known, stable development resources (headcount).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe add a force describing the effect of uncontained InnerSource on collaborative product development. I'm guessing you are thinking about added effort for soliciting and managing contributions?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Not just the added effort but also the effect on controlling the timeline for completion and deployment.

## Sketch (optional)

## Solution
The solution is for the participating BUs to each dedicate development resources to collaboratively add the features that each BU needs to the software component. InnerSource tools and some InnerSource processes are used, but the InnerSource cooperation is contained; there is no attempt to encourage open contribution from participants outside the core group of BUs that have entered into this arrangement.
Copy link
Collaborator

@NewMexicoKid NewMexicoKid Dec 5, 2016 •
edited
Loading

Choose a reason for hiding this comment

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

Is open contribution then irrelevant to this particular pattern? I.e., it doesn't matter whether the owning BU encourages it or discourages or forbids it.
Also, how much of the open source methodology is employed in this solution to enable cooperation across BUs?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is open contribution then irrelevant to this particular pattern?

I don't think so. Not being open = not spending effort on soliciting and managing contributions outside of the group seems to be the feature here. (See my comment below)


## Resulting Context
Product development is successfully completed. Inner sourcing in the classic sense isn't happening, so while the development cooperation that needs to occur happens, the full benefits from inner sourcing are not realized (e.g., exemplary documentation designed to promote further use of the component by others).

## Rationale


## Known instances
* Large company

## Status
* DRAFT pattern (in progress)

## Author
* As told to Tim Yao