Adding first draft of InnerSource Operational Model #417
Conversation
spier
added
1-initial
spier
requested review from
lenucksi,
NewMexicoKid,
cewilliams and
robtuley
as code owners
There was a problem hiding this comment.
Just some suggestions and comments on this pattern. The sketch is interesting, though I feel like it is missing a dimension of information; i.e., the mapping of patterns to stages in an InnerSource project lifecycle is helpful, but only if you have more of an idea of what problems each pattern solves. If it is possible, it would be helpful to have this sketch be presented as an image map, complete with a link to each pattern and a title/alt text with the pattern patlet.
|
|
||
| InnerSource is typically focused on letting developers work together. There are several patterns focused on specific roles as the Trusted Committer or from a more organization level as the Review Committee. However, it is still not clear how all of this works together. | ||
|
|
||
| This pattern aims at providing an overview to management and Chief level of how the software life cycle may be in a more InnerSource way with the goal of having a place where InnerSource principles may apply to the several people involved: from Product Owners to Contributors. |
There was a problem hiding this comment.
maybe: ...how the software life cycle may be managed in a more InnerSource way..
|
|
||
| This pattern aims at providing an overview to management and Chief level of how the software life cycle may be in a more InnerSource way with the goal of having a place where InnerSource principles may apply to the several people involved: from Product Owners to Contributors. | ||
|
|
||
| This may be seen as well as the glue for other patterns willing to make sense from a development lifecycle perspective. |
There was a problem hiding this comment.
Maybe: This may help provide a helpful framework for connecting patterns to help practitioners make better sense of InnerSource from a development lifecycle perspective.
|
|
||
| ## Context | ||
|
|
||
| The content here is often tied to the applicability of the pattern for other readers: "Do I have this same particular situation?" |
There was a problem hiding this comment.
Maybe: Visitors to InnerSource patterns may often wonder about the applicability of a given pattern to their own situation.
|
|
||
| ## Forces | ||
|
|
||
| As the software production chain involves roles with different goals, this way of working has to be part of everyone involved. Business related people as Product Owners may be reluctant to move into a more collaborative and transparent way of producing software. And this may happen with others as well. |
There was a problem hiding this comment.
Maybe: As the software production chain involves roles with different goals, the InnerSource way of working has to be taken up by everyone involved in the software production chain. For example, business related people as Product Owners may be reluctant to move into a more collaborative and transparent way of producing software. And this reluctance may occur with other roles as well.
Comment
Whenever possible, forces should be stated in a way that indicates the trade-offs (which can hint at the levers by which one can react to a given force). So if Product Owners are reluctant to be more collaborative and transparent, what is motivating them to do so? (Is it a cultural tendency to secrecy to protect proprietary information to gain a strategic advantage? If so, then is it a matter of noting which information needs to be protected vs. which info, when shared, can result in compensating advantages?)
The forces in this pattern likely need to be further brainstormed/developed/analyzed.
There was a problem hiding this comment.
Suggestion added.
With respect to the comment, I agree with you. However, this pattern could be seen as the umbrella for the other discussions. As an example, we're discussing on POs. What if we define more in detail the different stages? Or does it make sense to have this discussion in new patterns? (e.g., InnerSourcing Product Owners).
| The content here is often tied to the applicability of the pattern for other readers: "Do I have this same particular situation?" | ||
|
|
||
| The problem initially exists at the management level where the several business units are defining their needs, tuning the product, and suggesting next steps. A general overview of this process and key moments in the chain where they can influence (e.g., POs discussions) are part of this. | ||
|
|
There was a problem hiding this comment.
This context feels a bit vague. Is the problem that the management of several business units are investigating the adoption of InnerSource as a means of optimizing their SW development and they don't know where to start or how to organize/apply the many patterns that exist in the InnerSource Patterns repository? Then this probably should be stated here in the context.
There was a problem hiding this comment.
Not exactly this. I've added a small paragraph after this in the new commit. The idea with this pattern is that InnerSource works at several levels in the organization. As an example, product owners are sometimes left out of the InnerSource discussions once InnerSource is working, but POs are the ones deciding on next features and next steps. This model takes into account that they exist and how to grow them into this scenario.
Update pattern according to @NewMexicoKid comments. Thanks!
Remove 1 empty line to comply with format rules
There was a problem hiding this comment.
Left some comments inline.
My main question is:
Is this a pattern (i.e. it solves a specific InnerSource problem), or rather a visualization that helps to understand where in the development lifecycle our other patterns can be helpful?
Related question:
For which person/role would the information in this pattern be most beneficial?
Also see my related comments here.
|
|
||
| ## Patlet | ||
|
|
||
| InnerSource is key across all of the software production chain. This includes from idea to delivery to customer. This pattern defines the software development life cycle from an InnerSource perspective. |
There was a problem hiding this comment.
The Patlet does not describe the problem yet that this pattern looks to solve.
There was a problem hiding this comment.
We typically suggest to format the Patlet like this:
- 1st sentence to describe the problem
- 2nd sentence to describe the solution
|
|
||
| The resulting context is that the corporation has defined and is using an operational model to work in a more transparent and collaborative way. This model can be later extended to other projects within the corporation. | ||
|
|
||
| This model is useful as well to compare to other existing models in the company, and check how InnerSource this is. For further reference please check the Maturity Model Pattern. |
There was a problem hiding this comment.
"how InnerSource this is" is hard to read.
Can you elaborate on what you mean here?
Do you mean something like this:
This model is useful as well to compare to other existing models in the company, and check to what extent those support InnerSource (or at least don't prevent it from happening).
| 2. Build where the developer collaboration takes place with other developers, where the user story is translated into code, and | ||
| 3. Usage as the moment in time the software is producing value at the final end users even in other business units or departments. | ||
|
|
||
| These three main areas should at the same time comply with the InnerSource principles (transparency, collaboration, community, etc.). |
There was a problem hiding this comment.
Do we have these principles in writing somewhere?
We have this pattern but I don't think that this is what you are referring to here:
https://patterns.innersourcecommons.org/p/document-your-guiding-principles
| 1. Inception where the idea is discussed and specified (e.g., as user story), | ||
| 2. Build where the developer collaboration takes place with other developers, where the user story is translated into code, and | ||
| 3. Usage as the moment in time the software is producing value at the final end users even in other business units or departments. |
There was a problem hiding this comment.
| 1. Inception where the idea is discussed and specified (e.g., as user story), | |
| 2. Build where the developer collaboration takes place with other developers, where the user story is translated into code, and | |
| 3. Usage as the moment in time the software is producing value at the final end users even in other business units or departments. | |
| 1. [Inception](https://patterns.innersourcecommons.org/p/document-your-guiding-principles) - where the idea is discussed and specified (e.g., as user story) | |
| 2. **Build** - where the developer collaboration takes place with other developers, where the user story is translated into code | |
| 3. **Usage** - as the moment in time the software is producing value at the final end users even in other business units or departments |
Formatting suggestion.
| @@ -0,0 +1,71 @@ | |||
| ## Title | |||
|
|
|||
| An InnerSource Lifecycle Model | |||
There was a problem hiding this comment.
If we rename the title, we should consider changing the filename as well.
|
|
||
| As the software production chain involves roles with different goals, the InnerSource way of working has to be taken up by everyone involved in the software production chain. For example, business related people as Product Owners may be reluctant to move into a more collaborative and transparent way of producing software. And this reluctance may occur with other roles as well. | ||
|
|
||
| ## Sketch (optional) |
There was a problem hiding this comment.
| ## Sketch (optional) | |
| ## Sketch |
Adding first draft of InnerSource Operational Model
Implements #367
Note:
In the initial conversion of this pattern from the issue into markdown I only made absolutely trivial formatting changes, nothing else. Through reviews on this PR we can then improve this pattern collaboratively.