OpenChain x OSPOlogy Prague 2026 Presentations & Roundtable Notes

[anajsana]

Creating a thread for the OpenChain x OSPOlogy Prague 2026 presentations, demos, workshop and roundtable notes from the event on October 6, 2026, hosted at the Deloitte Office Prague. Speakers, demo presenters, and workshop and roundtable moderators, please add your presentations, materials, and summary notes as new comments to this thread, using links or PDF uploads.

• The program is available on the event website.

[geekygirldawn]

Roundtable Discussion: [GROUP B] Strategic Approach to Improving your OSPO using CHAOSS

MENTOR: Dawn Foster (TODO Group Ambassador)

Abstract: Metrics can provide deep insights into our open source initiatives, but they can also be overwhelming and require interpretation. Interpreting metrics and understanding what they mean is only useful if you drive appropriate actions to make decisions and improvements based on those metrics. In this roundtable, we’ll use a strategy first approach to discuss how to use metrics, tools, and practitioner guides from CHAOSS to improve the work within your OSPO whether you want to improve OSS projects themselves, assess their viability / risk for your organization, or demonstrate the value and impact of your OSPO.

Since this will be facilitated as a roundtable discussion, here are some links that participants may find helpful

Approach:

• Strategy Before Metrics
• CHAOSS Practitioner Guide Introduction
• OSPOlogy YouTube Panel: Ways to define a metrics strategy in your OSPO

CHAOSS Practitioner Guides (developed jointly within CHAOSS and TODO):

• Practitioner Guide: Getting Started with Contributor Sustainability
• Practitioner Guide: Getting Started with Responsiveness
• Practitioner Guide: Getting Started with Organizational Participation
• Practitioner Guide: Getting Started with Security
• Practitioner Guide: Getting Started with Sunsetting an Open Source Project
• Practitioner Guide: Getting Started with Building Diverse Leadership
• Practitioner Guide: Demonstrating Organizational Value
• Practitioner Guide: Assessing Viability
• Practitioner Guide: Research Software Impact
• Practitioner Guide: Funding Impact Measurement

Metrics:

• https://www.chaoss.community/kbtopic/all-metrics/
• https://www.chaoss.community/kbtopic/all-metrics-models/

Tools:

• CHAOSS Software
• CollectOSS / 8Knot Example
• GrimoireLab Examples: The Document Foundation and Eclipse

Additional Resources:

• https://www.linuxfoundation.org/research/measuring-ospo-value

[anajsana]

Demo Tooling: Agentic AI for OSPOs (Goose + MCP + CHAOSS Security Metrics)

PRESENTER: Ana Jiménez Santamaría

Abstract: How can OSPOs use AI agents to explore open source project health with verifiable evidence and community-developed guidance? This session walks through my experiment building a GitHub Stats MCP server and connecting it to goose. We’ll explore how the harness, model, and MCP tools work together, and how CHAOSS Practitioner Guides provide context for interpreting results to support informed human decisions

Here are the materials to follow along and try the experiment yourself

Presentation:

• Session slides

Step-by-step tutorials:

• Can MCP Help a Small Local Model Shine? Hands-on with Goose
• Building a GitHub Stats MCP Server with Security Metrics
• Taking My GitHub Stats MCP Server to the Cloud

CHAOSS guidance:

• CHAOSS Practitioner Guide Introduction
• Practitioner Guide: Getting Started with Security

Goose and reusable workflows:

• Goose project
• Reusable Recipes
• AI Agents for Air-Gapped Industrial Environments: Why goose? - Hoseong Lee

Groq models:

• https://console.groq.com/docs/models
• Groq API deprecations

[cwege]

Out of the CRA discussion on the topic "Product with Digital Elements" this is the transcript

What is a Product with Digital Elements?

What is placing on the market?

Is the product covered by other regulation?

Granularity of a product

Is a car the product?
Are subsystems products as well?
Being able to download it is an indicator
(distribution as part of commercial activity)
All mobile apps are products (probably)

Web sites are explicitly excluded by CRA

• including remote data processing

Group internal products are also put on the market
(What’s your risk appetite?)

Inner Source?
Likely yes, but these things are more to be discussed

Balance business risk and legal risk

Branded products?

[anajsana]

Keynote - OSPOs and Open Technology

PRESENTER: Nithya Ruff

OSPOs and open technology - slides

[vargenau]

CISA 2026 Minimum Elements in practice

Presenter: Marc-Etienne Vargenau, Nokia

CISA 2026 Minimum Elements in practice.pptx

[lbocinco]

Notes from Breakout Group B: A Strategic Approach to Improving Your OSPO using CHAOSS
Moderator: Dawn Foster
Attendees: mix of OSPO practitioners from both the private and government sectors, along with a student learning where and how to contribute.
(Note: You can find important links, resources, and related topics in the Dawn's comment above).

Discussion about different metrics tools
When it comes to measuring open source health, context is everything. Dawn helped break down when to use which tools:
CHAOSS Tools (CollectOSS & GrimoireLab): These are built with the OSPO in mind. They operate on the assumption that you already know which specific repositories you want to track.

• CollectOSS: Focuses heavily on repository data and uses the 8knot frontend, making it highly customizable. Dawn shared an example on how this tool helps her build dashboards that tell a story to maintainers, with metrics like Time to First Response (how long it takes a human to reply to a PR), Change Request Closure Ratios, Release Frequency, and the Contributor Absence Factor (a.k.a. the "bus factor"—how many people are actually writing the majority of your code).
• GrimoireLab: Great for when you need to pull various repository data sources together and query them to explore deeper trends.
• Ecosyste.ms: Unlike the CHAOSS tools, this is better suited for looking at the broader open source ecosystem, especially when you don't have specific projects in mind yet.

CHAOSS Practitioner Guides
Dawn introduced the CHAOSS Practitioner Guides, which are designed to help you take metrics and turn them into actual practices based on specific project examples. And we are all welcome to contribute to this Practitioner guides, as it was created by the community. Discussion was mostly about two guides based on the questions:

1. Assessing Viability - How do you decide if an open source project is relevant and healthy enough for your company to use?
   Example from one of the attendees that worked on the "engineering mobility" (allowing developers to easily move between different teams). However, by looking at the data, they discovered every single team was using a completely different Java framework, making it nearly impossible for developers to just jump in and help another team.
2. Demonstrating Organizational Value - How do you prove that the open source engineering work your team does actually matters to the company? The goal is to always tie your open source work directly to the things your company actually cares about.

Thoughts from the open discussion

• Metrics need a narrator: We can all look at the exact same dashboard and walk away with entirely different conclusions. Data is just data; being able to tell a compelling story with that data is the real job of an OSPO.
• Making data accessible: One of the attendees shared a story from his own team. He was struggling to get people to actually look at GitHub metrics. His breakthrough came when he integrated an AI chat feature into the repository. Instead of forcing people to read complex dashboards, developers could just ask the AI plain-language questions. The AI would translate the human question into the right query and spit out the relevant data. It completely changed how the team interacted with their metrics!
• Trying to calculate an economic "ROI" for an OSPO is incredibly difficult: While there are plenty of reports out there on the economic impact of open source, the room generally agreed that many rely on flawed assumptions. Because of this, many attendees lean toward storytelling rather than just chasing ROI numbers. For those interested, the Linux Foundation does have a report on "Measuring OSPO Value" that is worth a read.
• Projects vs. Communities: Never forget the difference between an open source project and an open source community. Just because code is public doesn't mean a community exists around it.
• Procurement: We need to start looking at how open source fits into the traditional procurement process, as this is a major hurdle for many companies.
• It’s about humans: At the end of the day, the OSPO network is crucial for growing our communities. The tools are great, but the humans connecting with one another are what actually make it work.

[CsatariGergely]

Notes from the How an OSPO should prepare for CRA? workshop

• Google Slides with references, photos of the whiteboards and the transcript of the whiteboards

What is a Product with Digital Elements?

• See the CRA FAQ for some answers
• Further notes are here

Due diligence

CRA References

• Recital (21)
• Recital (34)
• Recital (35)
• Article 13(5)
• Article 25

Notes

• Supplier due diligence
  • To the extent possible
  • Mitigation measures when the supplier does not provide the SBOM
• Project due diligence (direct open source consumption)
  • Scope of sue diligence
  • Not clear in CRA
    • There is a CEN/CENELEC harmonized standard, but not clear enough
    • Eclipse ORC WG is working on a whitepaper
  • Automation is a must
  • Tools as a basis for the automation
    • OpenSSF Scorecard (a talk about this)
  • OpenSSF ORBIT WG is also working on something
  • GrimoireLab
  • Minder
• Exceptions for risk aware analysis
• Document the results
  • Store and present to the Market Surveillance Authorities on request

SBOM

CRA References

• Recital (22)
• Recital (77)
• Recital (118)
• Annex I, Part II, 1

Notes

• What should be the content of the SBOM?
• How to manage SBOMs?
• Unique and correct package identifyer
  • Identify origin
• VEX: are we affected?
  • Is VEX part of the SBOM?
• Is SBOM a data model or a document
• SBOM is not only for open source
  • Also for COTS
• Is the SBOM provided by default?
  • TEA Protocol
• How many levels of dependencies are in the SBOM?
• What is the chain of suppliers?
  • Are these from Europe?

Vulnerability management

CRA References

• Article 13(6)
  • Report zero day vulnerabilities upstream
  • Patch if needed
  • Provide the fix upstream

Notes

• Audit vulnerability based on SBOM
• Report (new CVEs only?)
  • Steward?
• Strict timelines
  • 24h warning
  • 72h notice
• 2027
  • Actively provide a fix or workaround
  • 14 days to report

Steward

CRA References

• Article 24
  • Security policy
  • Cooperate with MSA
  • Report vulnerabilities
  • Report severe incidents of the platform

Notes

• Too many deterministic factors
  • Research / PoC purposes
  • Abandoned projects
    • Maintainer burnout
    • No funding
• Too long supply chain
  • Non-EU supplier / contract
• Et al.
  • Community, non-compliant projects

References

• CRA: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847
• ORC WG: https://orcwg.org/
• ORC WG Due diligence WP: https://orcwg.github.io/cra-due-diligence/
• TODO Article: https://www.linuxfoundation.org/blog/how-ospos-are-preparing-organizations-for-the-eu-cyber-resilience-act

[umm0]

Operational Compliance in Open Source: OpenChain Business Operations

Panelists:

• Mary (Meixia) Wang, @mary0814
• Marcel Kurzmann, @mkurzman
• Ummo Schwarting, @umm0

Note

→ Panel Slide Deck

---

OpenChain Business Operations Study Group:

• CRA Checklist:
  → https://cra-compliance.openchainproject.org/
• Topic backlog / suggestions:
  → https://github.com/OpenChain-Project/OpenChain-Business-Operations/issues
• Study Group meetings:
  → EU/ASIA on Monday 11:00 UTC (bi-weekly)
  → NA/EU on Tuesday 14:00 UTC (bi-weekly, alternate week)
• Mailing list
  → https://lists.openchainproject.org/g/OpenChain-BusinessOps-Study-Group

SPDX Operations

• Weekly meeting on Fridays at 14:00 UTC
• Mailing list: https://lists.spdx.org/g/spdx-operation

[Masato-oss]

A Living Framework for Automotive SBOMs

Masato Endo (Toyota): https://github.com/Masato-oss
Ayumi Watanabe (Hitachi): https://github.com/AWatanabe418
Keisuke Takase
Mary (Meixia) Wang (OpenChain): https://github.com/mary0814

Automotive SBOM GitHub: https://github.com/OpenChain-Project/Automotive-SBOM
Automotive SBOM 1.0 PR: https://www.linuxfoundation.org/press/linux-foundation-releases-openchain-automotive-sbom-framework-1.0-for-greater-reliability-and-traceability-in-automotive-software

Slides of this seesion:
20261006_OSPOlogu_Automotive_SBOM_Framework_v1.0.pdf

[NikolaBabadzhanov]

Community-led discussion (Unconference session)

Mentor:

• Nikola Babadzhanov

Note taker:

• Prashant Baghel

---

Topic 1: SBOM standards

• If a standard is working, don't touch it. Moving SBOM standards is a big gap. How do you reach SPDX 3.0 with all the inconsistencies?
• SPDX 3.0 is not really an SBOM. It is closer to a meta model.
• Observation: standards may become obsolete eventually, but not right now.
• Who cares about the format? What matters is that the content of the data stays the same. A consistent set of data is the real goal, and the formats are unnecessary on top of that.
• Reaching one universal format is the ultimate question. Until then it is a big waste of effort.
• Open question: at release you may load an SPDX 2 SBOM, but when a vulnerability patch is found you generate a 3.0 one. What can the community do about this?
• Some pushes for a particular format may come from higher up.
• Telecom SBOM and Auto SBOM are subsets of the same data.
• Your SBOM is only as good as your data. Bad data gives a bad SBOM.
• Open question: some vendors give source, some give binary. Do we need a build SBOM or a runtime SBOM? For security we need runtime. Many types of SBOM come from upstream.
• At minimum, get an SBOM from the vendor. Compare the binary with the SBOM they shared, pick the correct info, then feed it to your own database.
• The problem is not on the tech side. It is on the vendor side, in communicating what we actually need.
• Use cases are license compliance and security. For security you need reachability context. Checking which calls are actually made is a runtime security issue.
• License compliance is fairly simple.
• Git history: having the data matters even after 10 or 20 years have passed.
• AI was not an issue 5 years ago.

Topic 2: Trust

• Software Heritage and Google's index have huge databases, but they work in isolation. No one is talking to each other.
• Companies can't use that data because of lawyers and liability.
• The info needed to generate an SBOM already exists, but we keep scanning because we don't trust each other.
• rust in the supply chain is technically possible, but morally we are not there. Lawyers are bound by liability.
• AI changes the picture. Enterprises or individuals can now rewrite existing code in another language, fix earlier issues, and release it as open source. This can hurt the contributors and maintainers who built the original code.
• The Chardet case came up as an example. A Python library was rewritten with AI and moved from LGPL to MIT, and the original author objected. Whether this is legal is still being argued.
• This is not limited to one project. The same approach can be tried on almost any software, including old legacy software.
• At some point AI stops being enough, and we still have to tell it what is needed. You need a person who understands the software. The software may become legacy, but the person who understands it can do more.
• Where do we draw the line? An AI ethics manifesto came up as one idea.
• Values may matter more than trust, morals or ethics.
• It gets harder the deeper you go into the supply chain. Whom do you trust?
• Some people are keeping critical things alive and may not have the capacity to do so.
• Open question: will AI be covered in ISO/IEC 5230 or 18974