Contained InnerSource #84
Conversation
…velopment” from Tim Yao (#12)
…aborative-product-development
gruetter
added
1 - Do 1st Review
3-validated
contained-innersource.md
Outdated
| managing contributions as well as onboarding new contributors, which is | ||
| hard to plan for and my have some effect on the ability to control the | ||
| timeline for completion and deployment. | ||
|
|
There was a problem hiding this comment.
- Code visibility/project transaparency is orthogonal to this particular Pattern. Leaving the code visible (the way other InnerSource projects would be) leaves the door open for future, more extensive collaboration opportunities, but the project may view this as possibly distracting their limited resources if unsolicited contributions are submitted. Keeping the code closed to participating members of the project doesn't activate the Full scale InnerSource benefit of possibly higher quality due to having more eyes on the code but might satisfy potential project needs for secrecy (e.g., there may be legal or contractual obligations for the company to fulfill).
There was a problem hiding this comment.
the project may view this as possibly distracting their limited resources if unsolicited contributions are submitted.
Perhaps the best solutoin then is to propose a small experiment. For instance, leave the repo visible but don't be overly concerned with soliciting contributions. If it becomes a distraction, it can easily be locked down, if contributions turn out to be useful then the team can start to implement small steps to encourage further contribution.
contained-innersource.md
Outdated
| Apply InnerSource methods to facilitate collaboration in a cross divisional | ||
| project but don't invest in soliciting contributions from outside of that | ||
| project. |
There was a problem hiding this comment.
How is this different from traditional walled-off source?
There was a problem hiding this comment.
Oftentimes traditional walled-off source allows anyone within the walls to talk to each other, but there's still just one team that adds code to a given project. All others must get their feature ask or bug fix request prioritized into that team's backlog to get what they want. The approach suggested here doesn't involved any more teams, but uplevels all teams involved to commit pull requests to a project instead of just feature requests.
There was a problem hiding this comment.
Isn't this more of a "step toward" InnerSource, rather than a "pattern of" InnerSource? Do we make such distinctions? I worry that if a pattern like this is adopted, it can be seen as "good enough" by supporters of the status-quo and work against patterns that actually resemble open source.
There was a problem hiding this comment.
Isn't this more of a "step toward" InnerSource, rather than a "pattern of" InnerSource?
I think so. To be fair, I think that the Resulting Context calls that out clearly.
Do we make such distinctions?
We haven't learned how to be that formal about it, yet.
it can be seen as "good enough"
That's true and a good point. @NewMexicoKid is there a place in the pattern format to put caveats or known "gotchas" with a particular pattern?
There was a problem hiding this comment.
In my interpretation of this pattern Contained InnerSource can indeed be seen as a "step towards" InnerSource. However I don't see this as a problem, as a step is better than no step. And if the situation really doesn't allow for more, I would take it :)
One other angle to look at this is to consider the Contained InnerSource idea like a pilot project where the concept can be tried out. One hope is that the developers that experience it may advocate for it more strongly afterwards, and if they do they can use the specific experiences that they have made as examples that the decision makers can more easily relate to.
There was a problem hiding this comment.
That's true and a good point. @NewMexicoKid is there a place in the pattern format to put caveats or known "gotchas" with a particular pattern?
Those go into the Resulting Context section; and it is not uncommon for significant "gotchas" or issues identified there to point to further patterns that could then be applied.
contained-innersource.md
Outdated
| Traditional development practices do not work as effectively for cross | ||
| divisional projects as do InnerSource style practices. However, Management | ||
| does not support adopting InnerSource practices because it regards efforts for | ||
| soliciting and facilitating contributions from outside of the project as | ||
| detrimental for the required efficiency. |
There was a problem hiding this comment.
If management doesn't support it, shouldn't we build tools to help convince them rather than sacrifice the benefits of having internally open repositories? Will a hobbled version of InnerSource convince management of anything?
There was a problem hiding this comment.
I think it's fair to have more than one possible solution that addresses the same problem. @NewMexicoKid would this just be a separate pattern with the same problem statement?
There was a problem hiding this comment.
Yes. There can definitely be different solutions that address the same problem or that may apply when different contexts or forces are at play.
contained-innersource.md
Outdated
| Apply InnerSource methods to facilitate collaboration in a cross divisional | ||
| project but don't invest in soliciting contributions from outside of that | ||
| project. |
There was a problem hiding this comment.
Oftentimes traditional walled-off source allows anyone within the walls to talk to each other, but there's still just one team that adds code to a given project. All others must get their feature ask or bug fix request prioritized into that team's backlog to get what they want. The approach suggested here doesn't involved any more teams, but uplevels all teams involved to commit pull requests to a project instead of just feature requests.
contained-innersource.md
Outdated
| Traditional development practices do not work as effectively for cross | ||
| divisional projects as do InnerSource style practices. However, Management | ||
| does not support adopting InnerSource practices because it regards efforts for | ||
| soliciting and facilitating contributions from outside of the project as | ||
| detrimental for the required efficiency. |
There was a problem hiding this comment.
I think it's fair to have more than one possible solution that addresses the same problem. @NewMexicoKid would this just be a separate pattern with the same problem statement?
maxcapraro
added
the
Stale
lenucksi
added
the
📖 Type - Content Work
spier
added
1-initial
…nnersource-enables-collaborative-product-development
gruetter
requested review from
cewilliams,
lenucksi and
nyeates
as code owners
|
I have updated this pattern to the latest version of our pattern template and worked in some of the feedback from this PR. As the pattern doesn't have a very specific Known Instances yet, I considered this pattern to be Level 1 (initial), rather than Level 2 (Structured). @gruetter Shall we keep this as Level 1 for now, or can you say more about the Known Instance? Also @jamestharpe and @rrrutledge if you have seen this pattern in action since you commented on this in 2019, or want to leave any further ideas on this PR, please do. Personally I would suggest to merge this pattern to the main line as is, so that we can get more eyeballs on in from the rest of the InnerSource Commons community. |
spier
removed
the
Stale
There was a problem hiding this comment.
The cleaned up pattern looks okay to me. Thanks for the effort, @spier , and thanks to @jamestharpe and @rrrutledge for the questions and comments.
|
Thanks for the feedback. Let's give this another week or so to solicit further feedback, and merge the best possible version. |
…aborative-product-development
spier
deleted the
pattern/contained-innersource-enables-collaborative-product-development
branch
Hi guys. Triggered by a suggestion of @NewMexicoKid in this PR, I rewrote the pattern to better reflect the scenario I was thinking of.