The document discusses a capability maturity model (CMM) for assessing the maturity of an organization's open source software development practices. It presents a five-level maturity framework from initial to optimizing and maps out how capabilities could be assessed across four categories: people and organization, processes, information, and systems. The CMM is aligned with requirements in the OpenChain specification and ISO 5230 standard to provide a potential framework for determining an organization's open source compliance maturity.

1. These slides do not contain legal advice
Open Chain Maturity Model
Roadmap

2. Capability Maturity Model – What is a CMM?
A framework for determining the degree of capability,
adaptability and resilience of a business function within
an organisation, with the aim of optimising continuous
improvement.

3. Maturity Model – High Level Approach
Indicative levels of maturity
• INITIAL: Minimal knowledge of open source compliance practice and procedure
• REPEATABLE: Some steps towards compliance. Some systems in place, but
application ad hoc
• DEFINED/IMPLEMENTED: Policies, practice and procedure in place, but not
necessarily in operation
• MANAGED: Policies etc. in place, and in operation, and improved as considered
necessary
• OPTIMISING: Policies etc. in place, in operation, and actively managed using
appropriate metrics and a process of continuous improvement.

4. Maturity Model – High Level Approach
59%
38%
64%
50%
5
4
3
2
1
Measured
Maturity
Score
Target
Systems
Information
People &
Organisation
Process
Optimising
Managed
Defined / Implemented
Repeatable
Initial
The capabilities of the organisation that have
been developed to manage open source
software development will be considered
against the requirements of the OpenChain
Specification v2.1, ISO/IEC 5230:2020.
They will be categorised into four types of
capability; people and organisational, process,
information, and systems.
Maturity will be assessed against five levels of
completeness as shown.
The target level will be specific to each
organisation and can be set according to their
ambition and view of business risk and
priorities for delivery.
The gap between target level and measured
level presents defines opportunities for
improvement and is easily converted to
implementation plans,

5. OpenChain Provides a Potential Framework
1. The Specification (ISO 5230:2020) contains the set of characteristics that a quality
Open Source development function possess within an organisation.
2. Each OpenChain requirement can be mapped against a business function, and a
degree of maturity can be assigned to each business function.
3. We propose a hierarchy. Top level requirements will be applicable across all
organisations.
4. Second level requirements can be tailored to the method of implementation chosen by
the organisation.
5. It’s compatible with existing best practice in capability maturity modelling across the
whole range of an organisation’s business functions, not just software development (or
open source software development).

6. ISO Requirements and Processes
Governance Strategy and Oversight
6
3.1.1 Policy
Appoint policy author, owner, exec sponsor
Publish policy
Review policy
Distribute policy
Track awareness of policy
Review performance against policy
objectives
Enablement and Performance Management
3.1.4 Program scope
Define programme scope
Review appropriateness of programme scope
Define risks to be managed
Define benefits to be achieved
3.1.2 Competence
Identify roles and responsibilities
Determine competence required
Determine training need
Assess competence achieved
3.2.2 Effectively
resourced
Review programme resourcing and funding
Track progress against policy objectives
Analyse progress against policy objectives
3.5.1 Contributions
Develop policy for contributions (in and outbound)
Review and maintain policy
Track progress against policy
Review performance (risks and benefits)
3.1.3 Awareness
Communicate open source and contribution
policy
Track awareness of policies
Communicate implications of non-
compliance
Track non-compliance events
Track awareness of contribution policy
Open Chain Delivery
3.6.1 Conformance,
3.6.2 Duration
Review OpenChain
conformance (18 month)
Manage 3rd party
certification
3.1.5 License
Obligations
Identify licenses in use
Document license
obligations
3.3.2 License
Compliance
review license compliance
across distribution modes
Produce contributions
guidelines for contributors
3.3.1 Bill of
Materials
Produce SBOM
Review and approve SBOM
Maintain version and distribution
history
Licence analysis
Produce records of process followed
3.4.1 Compliance
Artifacts
Generate artefacts
Distribute artifacts
Record artifacts
3.2.1 Access
Respond to compliance inquiries
Track nature of response to inquiries
Review performance of inquiry responses

7. Example assessment 3.3.1 Bill of Materials
People and Organisation Capability Processes Capabiliity
Attributes P&O Maturity Questions Process Attributes Process Maturity Questions
Key role holders
Development Team
Leader
Associated roles
DevOps Specialist
Does a role exist for
generating (or
maintaining the system
which generates) SBOMs?
Are role/responsibility
holders suitably trained?
Do role/responsibility
holders have the
necessary competencies?
Key processes
Produce SBOM
Review and approve
SBOM
Maintain version and
distribution history
Produce records of
process followed
Does a process exist
(automated or not) for
generating SBOMs?
Does a process exist for
reviewing and approving
SBOMs?
As part of any process
involving SBOMs, are
suitable records kept?
Information Capability Systems Capability
Information
Attributes
Information maturity
question
Systems Attributes Systems Maturity Questions
Key Information
Component
manifests
Correct SBOMs
SBOM records &
metadata
Are component manifests
made available for
compliance purposes?
Are SBOMs generated?
Do SBOMs contain sufficient
correct data for licence
compliance?*
Are SBOMs generated in a
way which facilitates other
risk management or
operational processes (e.g.
security/vulnerability or
export control)
Are standards (e.g. SPDX,
CycloneDX) used to generate
SBOMs
Are the standards used to
generate SBOMs consistent
across the organisation?
Key systems
Compliance toolchain*
Emerging good practice
Metadata repository
(such as SW360)
Does the compliance
toolchain have functionality
for generating SBOMs?
Where issues are identified
(e.g., a failing test) is it
possible to remedy the issue
in-situ?
Is compliance metadata
stored in a suitable system
such as SW360?

8. Full Profile Assessment
Rapid view of gaps and priorities
Deeper analysis possible by each
of the four capability lenses.
Supports optimisation of open
chain programme