Good InnerSource Governance (map against GGI)

[fioddor]

There's are 2 initiatives for describing what good corporate open source governance means. One by the IEEE and another one by of the OSPO Alliance. The first one is on early stages and aims to develop an ISO standard. The second one has released a v1 of their framework.

I'm looking at it with InnerSource glasses to map the differences.

We could describe them first and perhaps eventually create an IS GG framework, but I find both valuable references for ISPOs.

[fioddor]

Here's my very first draft:

GGI Activities	Applicability	Differences
1.1 Inventory	Yes	Sw: IS instead of OS. Skills: include generic OS practices, exclude usual OS products
1.2 Competency growth	Yes	Different:a) Deployments: InnerSource usually deploys to a single instance,b) Motivation: InnerSource is less sexy than open source and the pool of possible contributors is smaller, InnerSource-specific topics:a) Transfer pricing (N/A to open source),b) Outsourcing scenarios require to focus competency growth on product owners, ...
1.3 Supervision	Yes	Different questions: a) Purpose: controlling the redundant developments and ensuring InnerSource software is proactively managed. b) Push/promote: integrating IS components, contibuting upstream. c) Pull/watch/prevent/avoid: identify where IS are de-facto or critical solutions and assess suitability (avoid IS monolith)
1.4 OS Enterprise software	No	Substitute by findability of IS or include in 1.3?
1.5 Manage open Sw dev skills and resources	No. Merge with 1.2	Most of needed skills are the same. + minor IS specifics.
2.1 Manage legal compliance	Yes	InnerSource specific: a) InnerSource license (less, but different challenges. No public innerSource licenses), b) Transfer pricing (N/A for OS), c) Export control (same as OS, but better options for control, since in-house)
2.2 Manage vulnerabilities	Yes	Worse than in OS: Dependencies on privative software and services (usually avoided in open source but usual in InnerSource)
2.3 Manage dependencies	Yes	a) Internal InnerSource dependencies b) Dependencies on privative software and services (usually avoided in open source but usual in InnerSource)
2.4 Manage KPIs	Yes	InnerSource motivation (silo breakage, etc). See metrics pattern.
2.5 Run code reviews	Yes	99% the same + corp. boundary control is an IS-specific need.
3.1 Promote IS best practices	Yes	99% the same, but there are exceptions (pattern?)
3.2 Contribute upstream	No. Merge with 3.4
3.3 Belong to the IS community	Yes	Belong to the corporation: Yes. Belong to the ISC: Less important, but still for cultural growth.
3.4 HR perspective	Yes	100% same (only different inventory of needs).
3.5 Upstream first	Yes	Limited to corp boundaries
4.1 Engage with upstream	Yes	Limited to corp boundaries (internal SIGs)
4.2 Support upstream communities	No? merge with 3.2 and/or 4.3?	Engage with ISC.
4.3 Publicly assert IS	Yes. Merge with 4.2?	Likely dismissed unless: a) plans to go open source in the future, b) hiring motivator
4.4 Engage with vendors	Yes	Secure long term support or knowledge transfer from upstream. Complements the code-consumers pattern.
4.5 OS Procurement policy	No? Merge with 4.4?	Trust relations between companies of the corp.
5.1 InnerSource Charter	Yes	.
5.2 Air Cover	Yes	.
5.3 Digital Sovereignty	Yes	.
5.4 Enabling Innovation	Yes	.
5.5 Enabling Digital Transformation	Yes	.

[fioddor]

My first draft still lacks a review of the 5th GGI's goal.

[fioddor]

This version considers an InnerSource-centric approach. An OSPO-independent ISPO. This is the case in organizations without an OSPO.

If there's an OSPO, the ISPO usually is a part of the OSPO or it works together with it.

[rrrutledge]

Thanks, @fioddor ❗️ Are you at the point where you’re ready for someone to look at this and give some feedback?

[rrrutledge]

It looks exciting! It is OK if one of the preconditions here is that there is no OSPO. Let us know if you want some review on what's here or are still working on it.

[fioddor]

I was working on the GGI version (the one assuming the ISPO is an extension of an existing OSPO). I've been busy lately, though.

I work on the other version and then port it here because of the license: GGI uses CC-BY, which is more permissive than ISC's CC-BY-SA. Porting from GGI to ISC is for free, but from ISC to GGI, it needs explicit approval from the contributors for relicensing.

[rrrutledge]

Oh wow! Hadn’t heard of GGI - that’s neat! If the GGI document fills our needs we can just point to that for now.

[rrrutledge]

@fioddor let us know if you'd still like to work on this now and share within the ISPO working group?

[fioddor]

@fioddor let us know if you'd still like to work on this now and share within the ISPO working group?

Sure. This is happening in the open and any feedback is welcome.

My last updates to the table are:

• The links got broken, so I re-newed them. Now they point to the online handbook.
• I've completed the section 5. It looks very much portable without outstanding adaptations.
• Clarified a bit some remarks.

[rrrutledge]

This would be a great addition to the Managing InnerSource Projects book.

[jeffabailey]

We have to decide where to land this content.

Likely in a new chapter of content.

Let's propose some options and decide where to put it.

[jeffabailey]

More feedback requested.

[jeffabailey]

We can create a new section and link off from this section to this content.

https://innersourcecommons.gitbook.io/managing-inner-source-projects/introduction/framework#governance

[jeffabailey]

@fioddor is there anything we can do to help?

[fioddor]

Started drafting the section in https://github.com/fioddor/managing-inner-source-projects/tree/governance/governance. Pull requests are welcome.

[rrrutledge]

Neat! Is what you have now sufficient to pull request (more can always be added later)?

[fioddor]

Neat! Is what you have now sufficient to pull request (more can always be added later)?

Now it is: https://github.com/InnerSourceCommons/managing-inner-source-projects/pull/40

Still a draft, but at least a consistent one.

[jeffabailey]

Justin: I would like to see more written down about how peoples' definitions of perspective on InnerSource can vary a lot between large & small companies and between definitions based on "behaviors and a "type" of project.

Justin says:So glossary and governance might be two places to put that somewhere

[rrrutledge]

Wow! Issue #40 in this repo is fixed by pull request https://github.com/InnerSourceCommons/managing-innersource-projects/pull/40.

40/40❗

[dellagustin-sap]

PR still in review.

[dellagustin-sap]

PR approved with minor changes required, @jeffabailey will work on the changes and merge it.

[jeffabailey]

Refresher, the changes are the PR feedback items.

[jeffabailey]

Igor to review

[jeffabailey]

@fioddor would you like to share the content you created with the ISC?

• [ ] The ISPO WG newsletter
• [ ] A conference
• [ ] A relevant working group