InnerSourceCommons / InnerSourcePatterns

Proven approaches that can guide you through applying open source best practices within your organization
https://patterns.innersourcecommons.org
Creative Commons Attribution Share Alike 4.0 International
736 stars 180 forks source link

Extract "Code Strategy Assessment Framework" into its own pattern #363

Open spier opened 2 years ago

spier commented 2 years ago

The Unified Source Code Inventory mentions the concept of a Source Code Strategy Assessment Framework.

I believe that such a framework could be useful even for companies that are only using a single version control system, and hence don't need to unify their source code inventory further (because they already have a single inventory).

Therefore I am proposing to pull the Source Code Strategy Assessment Framework into a pattern of its own, which can then be references from the Unified Source Code Inventory and other patterns.

spier commented 2 years ago

@dterol23 what do you think about this idea, given that you contributed the Unified Source Code Inventory including the Source Code Strategy Assessment Framework?

dterol23 commented 2 years ago

Hi @spier, yes, you might be right. I.e. This is the value proposition we pursue as part of the assessment:

Outsider assessment-type feedback on actual InnerSource repositories support practitioners to climb the maturity ladder through continuous improvement.

Maturity ladder is another concept we use where teams/organizations go through 5 levels of maturity (from source inventory to community) so the assessments are helping them to gain feedback and continuous improvement to take such steps. Assessments are composed of two elements: one automated where InnerSource sanity check are encouraged through a set of basic rules (e.g., do you have a meaningful readme...) and the second one is human based when someone tries to consume and contributed to your InnerSource'd repo and he or she gives you actionable feedback (e.g., these are the challenges I found to get a green build after cloning your repo).

It might have some overlap with existing pattern but also some differences. For us, it became a communication tool to prevent a basic answer to the question: "Are you doing InnerSource? and answering yes just because they shared once a repo with other team. From that angle, our concept of ladder is more high level and less detailed. The other different is that includes a foundational layer which is Inventory (i.e. do you know the source code you have?).

In summary, i think we could have three patterns interconnected:

  1. Unified Source Code Inventory
  2. Maturity ladder
  3. Source Code Assessment

What do you think? I think number 2 is more mature at our end so we could definitely write a pattern with our experience. Number 3 is still at discovery phase (testing at scale).