Pattern idea: Operational Model for InnerSource

[dicortazar]

This issue opens the discussion about the need for an InnerSource operational model. This is based on past authors experiences.

The following is a draft of the pattern to move this forward as a PR.

InnerSource Operational Model

Title

InnerSource Operational Model

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.

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.

This may be seen as well as the glue for other patterns willing to make sense 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?"

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.

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.

Sketch (optional)

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.

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.

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

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.

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 (optional until merging)

Initial status, opening discussion.

Author(s) (optional)

Igor Zubiaurre Daniel Izquierdo Cortázar

Acknowledgements (optional)

Alias (optional)

[spier]

Hi @dicortazar. How would you prefer to move this forward?

e.g. a) would you like others to provide feedback here on the issue? or b) do you want to convert this into a PR to receive the feedback there (likely on a more granular level then).

Personally I suggest to do (a) first, to see what people thing about the idea of such a pattern.

[mishari]

Hi @dicortazar I would like to propose "Develop" instead of "Build" when I see "Build" I automatically start thinking of CI/CD, this can cause some confusion.

Yes I'm aware that it's part of the SDLC, but I think Develop works better :-)

[spier]

@dicortazar after reading your pattern again, it reminds me more and more our Mindmap.

That mindmap structures all available patterns along the path that an InnerSource Program in an org might take (e.g. Begin => Adoption => Grow => Scale).

Your pattern here groups the patterns along the path of the software development lifecycle that a given org follows. So in that sense it seems like a visualization or meta pattern?

To prevent this pattern from becoming stale in this issue, I would propose to turn it into an PR and get it merged as an initial pattern pretty quickly. That has the benefits that it shows up in our repository and through follow-up PRs in the future it will be easier to give feedback to this.

Would you or Igor like to move this into a PR? Or otherwise I can also do that for you.

[spier]

@dicortazar how should we proceed with this?

How would this information best be presented, so that it becomes the most useful and easy for readers to consume? Could be as a

1. Pattern
2. Mindmap (a new one)
3. Completely differently

Thoughts?

[spier]

@dicortazar @fioddor I am creating a PR for this issue now, as a way for me and others to ask questions about specific parts of the pattern. The eventual goal of this being to merge this as an Initial pattern relatively quickly, as that will increase the likelihood of other orgs finding this pattern.