Skip to content
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

Adding first draft of InnerSource Operational Model #417

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Adding first draft of InnerSource Operational Model #417

Changes from 2 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
1b59f73
Adding first draft of InnerSource Operational Model as proposed in #367
spier May 22, 2022
59972b4
Fixing linter issue
spier May 22, 2022
f64e1fc
Turn into list formatting that markdown understands
spier May 22, 2022
0a8097e
Update operational-model.md
dicortazar Nov 28, 2022
2ea3c78
Update operational-model.md
dicortazar Nov 28, 2022
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
68 changes: 68 additions & 0 deletions patterns/1-initial/operational-model.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
## Title

InnerSource Operational Model
spier marked this conversation as resolved.
Show resolved Hide resolved

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

Choose a reason for hiding this comment

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

The Patlet does not describe the problem yet that this pattern looks to solve.

Copy link
Member Author

Choose a reason for hiding this comment

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

We typically suggest to format the Patlet like this:

  • 1st sentence to describe the problem
  • 2nd sentence to describe the solution


## Problem

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.
Copy link
Collaborator

Choose a reason for hiding this comment

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

maybe: ...how the software life cycle may be managed in a more InnerSource way..


This may be seen as well as the glue for other patterns willing to make sense from a development lifecycle perspective.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe: This may help provide a helpful framework for connecting patterns to help practitioners make better sense of InnerSource from a development lifecycle perspective.


## Story (optional)

## Context

The content here is often tied to the applicability of the pattern for other readers: "Do I have this same particular situation?"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe: Visitors to InnerSource patterns may often wonder about the applicability of a given pattern to their own 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.

Copy link
Collaborator

Choose a reason for hiding this comment

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

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.

Copy link
Member

Choose a reason for hiding this comment

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

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.

## 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.
Copy link
Collaborator

Choose a reason for hiding this comment

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

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.

Copy link
Member

Choose a reason for hiding this comment

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

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


## Sketch (optional)
Copy link
Member Author

Choose a reason for hiding this comment

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

Suggested change
## Sketch (optional)
## Sketch


The following is an example of a tentative pattern solution related to this. Existing patterns are now part of this discussion for the software development life cycle.

![OperationalModelForInnerSource](https://user-images.githubusercontent.com/469119/142229499-e05c60e8-0e8f-4f24-9578-ca05ba4cdab0.png)

## Solutions

The proposed solution is a simplified version of a Software Development Lifecycle. This pattern works on three main areas for the software development life cycle that are:

a) Inception where the idea is discussed and specified (e.g., as user story),
b) Build where the developer collaboration takes place with other developers, where the user story is translated into code, and
c) usage as the moment in time the software is producing value at the final end users even in other business units or departments.
spier marked this conversation as resolved.
Show resolved Hide resolved

These three main areas should at the same time comply with the InnerSource principles (transparency, collaboration, community, etc.).
Copy link
Member Author

Choose a reason for hiding this comment

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

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


## Resulting Context

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

Choose a reason for hiding this comment

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

"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).


If applied, this model brings more transparency to any of the decision making process at the company, and it is clear to others the end-to-end process to build software.

## Rationale (optional)

## Known Instances (optional)

## Status

* Initial status

## Author(s)

* Igor Zubiaurre
* Daniel Izquierdo Cortázar

## Acknowledgements (optional)

## Alias (optional)