fioddor
commented
1 year ago 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 | . |
rrrutledge
jeffabailey
dellagustin-sap
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.