Promoting Governance Levels pattern to Structured

[spier]

Now that this pattern has received its 2nd org confirming the applicability of the pattern (see #764), let's push this pattern to the next maturity level "Structured".

Checklist

from the Contributor Handbook:

• Is validated by at least 1 (one) known instance
• Uses the format described in the Pattern Template - validated in parts by Check: Pattern Syntax Validation
• Follows the Pattern Style Guide
• The title of the pattern is memorable, concise, and descriptive of what the pattern is about. For further tips see Naming Patterns.
• The pattern links to related patterns of this level or higher.
• Links from the pattern to outside resources are working and are referencing a trusted resource - whether links are working is verified by Check: Links
• The pattern is added to at least one phase of the InnerSource Program Mind Map.
  • Status: I added to pattern to one area of the mind map already, just to show how it might work. We should update this before we push the pattern live.
• Spelling & Styles checks pass - see Check: Spelling & Styles

Extras

possibly porting these back to the contributor handbook after this

• URL of the pattern is memorable / the filename will be part of the URL

History

It might help to review previous PRs related to this pattern:

• pattern creation: Adds a pattern draft for making governance levels explicit. #281
• improvements incl adding Flutter Entertainment as known instance: Extending Governance Levels #357
• adding BBC as known instance: Add BBC to users of the Governance Levels pattern #764

[spier]

A question to @MaineC, @tsadler1988, @robtuley, @rrrutledge:

Is what the Governance Levels pattern calls "distributed ownership" the same as what the pattern Group Support describes? If yes, then we could add links from one pattern to the other.

My initial take:
While the group support pattern describes a different reason for this ownership model to emerge, otherwise it seems to be the same concept.

[MaineC]

I think the group support pattern, as well as the explicit shared ownership pattern

https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns%2F1-initial%2Fexplicit-shared-ownership.md

both describe ways to establish shared ownership, while this pattern here describes shared ownership itself.

For this pattern, to make it easier to understand, you could add the open source analogy to each level:

Bug reports welcome: shared source (non OSS)
Contributions welcome: single vendor OSS
Shared ownership: vendor neutral OSS

We had these parallels in the original PR discussion but somehow didn't move them to the pattern itself.

[spier]

Many times our patterns are related to either the InnerSource program, or a specific InnerSource project.

To make it explicit that we are talking about the governance of a specific project, we might add this to the name.
(Also we are using the term "transparent" too frequently)

Disadvantage: We may end up using to term "project" in pattern names too frequently as well, much like "InnerSource".

[spier]

The pattern also mentions the "InnerSource operating model", as an alternative phrasing to "governance levels". Maybe we should pick only of of the two and stick to it throughout the pattern?

[spier]

"Who can contribute" would be another possible name.

[spier]

Flutter calls it the "Inner Source Pyramid"

[MaineC]

InnerSourcePatterns/meta/pattern-template.md

Line 85 in 11e1785

If this pattern is also known under a different name than what is listed unter **Title**, please list those alternative titles here.

... this template lists an extra section called Alias where different pattern names can be listed.

[tsadler1988]

I was thinking something like 'explicitly defined governance' or 'defined project governance'.

[spier]

I have added the Alias section, just in case we want to add some more there.

However finding the one title/name that we can stick to, is still a good thing to do. This name will be used a lot when referencing the pattern, will show up in the URL, etc. So I think it is worthwhile to burn some brainpower on this one :)

Also see Naming Patterns.

And yes, also here applies "naming things is hard" :)

[spier]

More funky names:

• What's my leverage?
• How much say to I get?

[spier]

We had these parallels in the original PR discussion but somehow didn't move them to the pattern itself.

@MaineC I could not find this. Can you point me to it?

This is an interesting case of doing forensics of how the pattern has developed over time :)

[spier]

@robtuley we are finally pushing this pattern to the next stage of maturity, which will also mean that we will get it published in our online book 🥳

I just saw here that Flutter has a new visual for the pyramid, which I would like to integrate into the pattern:
https://innersource.flutter.com/how/pyramid/

Would that be ok?

Also are there any new experience with this approach at Flutter that you would like to add to the pattern?

[MaineC]

@MaineC I could not find this. Can you point me to it?

My brain betrayed me here - apparently in one of the refinements of the pattern we did move the information I thought was only available as PR comment into the pattern itself...

[MaineC]

https://github.com/search?q=repo:InnerSourceCommons/InnerSourcePatterns%20governance%20levels&type=pullrequests#issuecomment-765274307 ... for pattern archaeology - that comment may once have held interesting information, except now it's on a dying platform, so not sure if the snippets I linked can still be reached.

[MaineC]

http://www.joelwest.org/Papers/WestOMahony2008-WP.pdf ... Found the related/ linked paper...

[spier]

@tsadler1988 just realized that your talk Ownership in a DevOps and InnerSource environment - Tom Sadler (BBC) is actually from 2023. Did the BBC make new experiences with the Distributed Ownership model you want to add to this pattern?

[spier]

@MaineC is your org an adopter of this pattern? i.e. do you want to add your org to the Known Instances?

[MaineC]

@spier sure, you can also add Europace AG to the list of users. It's fairly central for us actually as it helps potential contributors with what they can expect from the project they depend on.

[tsadler1988]

I think the group support pattern, as well as the explicit shared ownership pattern...

In my mind, those 2 patterns (and maybe others too, such as Core Team) are specific InnerSource governance/operating/ownership models, whereas this pattern is about communicating those differing models, and raising awareness of which ones are in use by which projects.

Side note - I do wonder if we could classify these models into a few groups e.g. (from hardest to softest ownership):

• Core team + contributors - no TCs outside core team
• Core team + TCs
• Distributed/shared ownership with mandatory participation from teams/individuals involved
• Distributed/shared ownership with optional participation via internal communities

Note it's also possible to slice a project up folder by folder and apply different models as necessary.

EDIT: I realised I'm describing what's already covered by the Pyramid, just slightly differently.

@tsadler1988 just realized that your talk Ownership in a DevOps and InnerSource environment - Tom Sadler (BBC) is actually from 2023. Did the BBC make new experiences with the Distributed Ownership model you want to add to this pattern?

https://www.youtube.com/watch?v=qiaWbu8czPc is my latest talk on ownership, but I don't think I go into detail except to say it's still fairly new but working well so far.

Internally, we've been reviewing this exact thing over the past few weeks so we do have more to share, but there's no talk or blog to reference. Happy to share some insights, let me know and we can discuss elsewhere.

Also, would it be helpful to incorporate some of the diagrams I use? E.g.

[spier]

So much great input in your last comment @tsadler1988!

Let's find a way to work this into this pattern. For that we don't need a blog post as reference either. Most of the time a pattern is written based on the experience of 1-2 organizations anyways, and then further generalized as more different orgs contribute to the pattern (if that happens).

Therefore I have added you to the authors of the pattern already, to make sure that you get props for all of your contributions to this topic.

Do you want to have a chat one of these days about what you discovered at the BBC related to these governance levels?

[tsadler1988]

Do you want to have a chat one of these days about what you discovered at the BBC related to these governance levels?

Sounds good! I have a busy few days but have availability from Tuesday onwards.

[MaineC]

raising awareness of which ones are in use by which projects.

Same here:

We ran into a situation where teams were using PRs also for code that was supposed to be used just by that one team. Others saw that - and in a "if it walks like a duck, and quacks like a duck, it is a duck" kind of way assumed, that the project is open for contributions. What nobody could see from the outside though was the lack of time and focus for mentoring external contributors.

That reminded me of what we see in open source:

Just because two projects have the same license, the promise of what you get back in return for contributions can differ wildly: Ranging from "if you invest your time and expertise, we will share control over the project's future with you" in vendor neutral projects to "write access comes and goes with your employment contract" in single vendor projects.

In open source as well it helps contributors to know more about a project's governance model - to understand that even if the license is the same, projects still differ.

[spier]

@MaineC it does speak for a flourishing InnerSource culture when teams just assume that they can contribute as soon as the see any other PRs on the repo. So in a way I like it :) Also it would be a cool baseline assumption to say "I am sure they will accept contributions, why wouldn't they".

But I can certainly see your point that the maintaining team may not have time to support the external contributors, which then may lead to frustration.

Personally I always saw "talk before code" in this scenario. I just mean that before sending any significant code contribution, I would want to file an issue/discussion to start a conversation or even just go straight to the team and talk to them (f that is an option). That approach should always reveal when contributions are not possible for the given repo.

[MaineC]

Also it would be a cool baseline assumption to say "I am sure they will accept contributions, why wouldn't they".

Referencing back to Open Source: That then has the potential for frustration if there is an expectation of being made committer one day. Clear expectation management helps in that case.

Internally as well: That then has the potential for frustration if the project lacks documentation, mentoring time, testing etc. Clear expectation management helps there as well.

Personally I always saw "talk before code" in this scenario.

That is another ingredient that is needed for contributions to work - and one that also in Open Source has to be taught over and over again. (Which is why it's great to have people first go through InnerSource, so when submitting contributions towards OSS they are already familiar with these basics ;) )

Another thing linked to the Governance levels is the question of "what does it take for a project to be InnerSource ready":

Well, if all you want to achieve, is solve some team internal collaboration challenges, then the bar for InnerSource ready is fairly low.

If you are planning to accept one contributions once every quarter than you can deal with that on a case by case basis, spend more time bringing people up to speed personally.

If you are planning to accept a dozen contributions daily then you'll need more automation, better documentation etc.

If you are planning to go for shared ownership then what it means to be InnerSource ready is yet another level.

Those questions are what we are addressing with the governance level project setup pattern.

Or to link back to Open Source: Depending on how much control each participant is willing to give up, you will end up as a single vendor, vendor neutral foundation based model or something else. Resulting from that will be community behaviours. Circling back to using Open Source that means that you need an understanding of the governance model in order to be able to predict the future of the project.

[spier]

Note to self: Update the Patlet here, once we have decided which Patlet text we want to use.

[spier]

The use of "InnerSource patterns" in here might be confusing.

[spier]

Could we replace "operating model" with "governance level" everywhere, to use this term consistently through out the pattern?

[spier]

Should we say "governance levels" instead of "model names"?