What Do You Want To Know?

General Questions
OpenChain ISO/IEC 5230:2020
OpenChain ISO/IEC 18974:2023
Self-Certification Questions
Cyber Resilience Act (CRA)
NTIA Minimum Elements For a Software Bill of Materials (SBOM)
OpenSSF Open Source Project Security Baseline
The Processes We Use

Ambassador FAQ

 

General Questions

The OpenChain Project is global community of organizations collaborating to create trust in the open source supply chain.

We do this through ISO/IEC 5230:2020, the International Standard for open source license compliance, and OpenChain ISO/IEC 18974:2023, the industry standard for open source security assurance. We also have education, training and certification resources freely available to all parties.

Most importantly, our community acts as a support network where knowledge is shared to reduce friction and increase efficiency across all aspects of open source process management.

Where Can I Find A Formal Description Of The OpenChain Project?

The formal description and structure of the OpenChain Project is contained in the Project Charter. You can find this on GitHub:
https://github.com/OpenChain-Project/Project-Charter-And-Agreements/tree/master/Project-Charter

What Does The OpenChain Project Cover?

The OpenChain Project is focused on building trust in the open source supply chain. Our primary emphasis is on issues related to license, security and other types of compliance. We are working towards a world where open source is predictable, understandable and optimized for internal and external supply chains of any type.

Our global community also works on topics like open source training, open source policy, open source program offices (OSPOs) and more. Everything we do is open to everyone, and it is all freely available.

Who Conforms To The OpenChain Standards?

We maintain a list of organizations decide to publicly announce OpenChain Conformant Programs through our website:
https://www.openchainproject.org/community-of-conformance

However, because our specifications are supply chain standards, they focus on the relationship between customers and suppliers, so most organizations adopt our work without public announcement. For example, a Bitkom survey sponsored by PwC in 2021 indicated that 20% of German companies with more than 2,000 employees are currently using OpenChain ISO/IEC 5230, the international standard for open source license compliance.

The primary way you find out if an organization is OpenChain ISO/IEC 5230 or OpenChain ISO/IEC 18974 conformant is by discussing this in sales communications or procurement negotiations. You can also ask their OSPO (if present) about their conformance status.

How Is The OpenChain Project Organized?

The OpenChain Project has global and local work groups that anyone can be part of. Some examples are the:

Specification Work Group, which identifies and publishes a set of core requirements a quality open source compliance program should satisfy.

Education Work Group, which provides reference material to help organization meet our specification requirements.

You can find a full list of our work groups and other activities on our community page:
https://www.openchainproject.org/community

There are three committees for member companies:

1. Governing Board – Manage policies or rules and procedures for the Project, fund raising, budgeting and so forth.
2. Steering Committee – Development, management and updating of the OpenChain Compliance Specification.
3. Outreach Committee – Designing, developing and executing efforts to build an OpenChain compliance ecosystem throughout relevant supply chains in collaboration with the Governing Board.

Can I Participate In The OpenChain Project?

Yes, of course. Everyone from any company, organization or government is welcome to participate. We also welcome individuals interested in the topics we cover. There is no registration or membership required. Get started here:
https://www.openchainproject.org/community

Can My Company Become An OpenChain Member?

There is no membership requirement to attend our meetings, to join our calls and webinars, or to help edit our standard and reference material. There is currently one membership level for the OpenChain Project: Platinum Membership. This is available to user companies (not vendors) and it provides a seat and a vote on our governing board and our steering committee. To learn more contact the General Manager at scoughlan@linuxfoundation.org.

There is also a partner program for vendor companies to engage with OpenChain. You can learn more here:
https://www.openchainproject.org/partners

How Is The OpenChain Project Related To Other Linux Foundation Process Projects?

The OpenChain Project has various sister standards covering adjacent topics in the area of open source process management. For example, the SPDX Project maintains SPDX ISO/IEC 5962, the International Standard for Software Bill of Materials (SBOM). The Open Source Security Foundation (OpenSSF) has extensive investment in security-related practices and management. The TODO Group has a focus on Open Source Program Offices (OSPOs). The Automated Compliance Tooling Project (ACT Project) supports open source tooling for automation related to management and compliance topics.

We work with all of these projects to help companies find the best solution for their market requirements. The OpenChain Project has perhaps the highest level optic – how to get started with key processes for open source management – and then you can use our sister projects to build out your processes and continually improve your approach.

How Are The OpenChain Standards Related To The OpenSSF Best Practices Badge?

The OpenChain Project and the OpenSSF Best Practices Badge are both Linux Foundation initiatives to identify criteria around open source process quality. The OpenChain Project focuses on the software supply chain. In contrast, the OpenSSF Best Practices Badge focuses on well-run open source projects themselves. These are complimentary initiatives, and both can be used to optimize open source from upstream to deployment and support.

OpenChain ISO/IEC 5230:2020

This is the FAQ for the OpenChain ISO/IEC 5230:2020 specification. We recommend that all contributors to our specification development process take a while to review this section of our FAQ.

We work based on four principles:

1. Build trust around the open source supply chain.
2. Remember that less is more:
   — Define the key requirements of a quality compliance program
   — Do this by solving real pain points in the supply chain
3. Keep our specifications limited to what and why (avoid the how and when)
   — Embrace different implementations to solve challenges
   — Avoid mandating specific process content
4. Be open to all to participate and contribute

What is the objective of OpenChain ISO/IEC 5230:2020?

It is designed to identify the key requirements of a quality open source license compliance program. This means it provides a level of trust about what organizations are doing as they ingest, internally develop and distribute open source software.

Where can I find the current version of OpenChain ISO/IEC 5230:2020?

You can find it on the OpenChain Project conformance page:
https://www.openchainproject.org/get-started/conformance

Does an open source program need to satisfy all the requirements of OpenChain ISO/IEC 5230:2020 to be considered conformant?

Yes. OpenChain ISO/IEC 5230:2020 defines the key requirements of a quality open source license compliance program. To make sure there are no gaps that would lead to poor quality output, a program must satisfy all the OpenChain ISO/IEC 5230:2020 requirements to be considered conforming.

Can software packages be OpenChain ISO/IEC 5230:2020 conformant?

No. OpenChain ISO/IEC 5230:2020 defines a quality open source license compliance program. The program is conformant. The software packages go through the program and therefore benefit from it. The question to ask suppliers is whether the software they supply was prepared under an OpenChain conforming program.

Does all the software in an organization need to be covered by an OpenChain ISO/IEC 5230:2020 conformant program?

No. Organizations are often made from different groups or departments with different programs and release procedures. One example is that engineering may be very different from professional services). An organization decides how much of the total entity to cover with its OpenChain ISO/IEC 5230:2020 conformant program. Many companies start with one part of one group covering one product, and build out from there.

Does the specification serve as a best practice guide?

No. OpenChain ISO/IEC 5230:2020 defines a quality open source license compliance program. It focuses on the “what and why” aspects of a program and not the how or when. A best practices guide must explain how and when to ensure it supports implementation activities. We publish reference material like Playbooks covering these topics, but they are separate to OpenChain ISO/IEC 5230:2020 itself.

How was OpenChain ISO/IEC 5230:2020 developed?

The OpenChain Project developed OpenChain ISO/IEC 5230:2020 via our specification mailing list and calls. The process was (and is) open to everyone. The initial draft of OpenChain ISO/IEC 5230:2020 (then called OpenChain 1.0) was created in the 2015-2016 period and released in late 2016. Since then the OpenChain Project has continually reviewed and maintained the standard in an open, collaborative manner that mirrors how open source software is created.

Does OpenChain ISO/IEC 5230:2020 describe how to comply with the most popular open source licenses?

No. OpenChain ISO/IEC 5230:2020 defines a quality open source license compliance program. It is not designed to identify, breakdown and interpret individual open source licenses. Because open source licenses are legal documents, they will also vary in their interpretation and application across different legal jurisdictions. Local organizations like OSADL (Germany) have worked on license obligation lists relevant for their markets.

Does OpenChain ISO/IEC 5230:2020 provide legal guidance?

No. The specification does not provide legal guidance because that can only come from a legal expert assigned to advise an organization. OpenChain ISO/IEC 5230:2020 does require an organization to designate a legal expert to do this as part of the conformance process. OpenChain ISO/IEC 5230:2020 also requires that a process exists to ensure the appropriate attention is given to license obligation analysis and and fulfillment.

Does OpenChain ISO/IEC 5230:2020 conformance guarantee license compliance?

No, but it significantly increases the probability that license compliance will be achieved for software prepared under an OpenChain ISO/IEC 5230:2020 conformant program.

Do resources exist to assist my organization in achieving OpenChain ISO/IEC 5230:2020 conformance?

Yes. You will find a substantial amount of resources, including self-certification checklists, on the OpenChain website:
https://www.openchainproject.org

What license is OpenChain ISO/IEC 5230:2020 released under?

The version we host on our website (currently called OpenChain 2.1) is licensed under the Creative Commons Attribution License 4.0 (CC-BY-4.0). A copy of the license can be obtained here:
https://creativecommons.org/licenses/by/4.0/legalcode

OpenChain ISO/IEC 18974:2023

This is the FAQ for OpenChain ISO/IEC 18974. We recommend that all contributors to our specification development process take a while to review this section of our FAQ.

We work based on four principles:

1. Build trust around the open source supply chain.
2. Remember that less is more:
   — Define the key requirements of a quality compliance program
   — Do this by solving real pain points in the supply chain
3. Keep our specifications limited to what and why (avoid the how and when)
   — Embrace different implementations to solve challenges
   — Avoid mandating specific process content
4. Be open to all to participate and contribute

What is the objective of OpenChain ISO/IEC 18974?

It is designed to identify the key requirements of a quality open source security assurance program. This means it provides a level of trust about what organizations are doing as they ingest, internally develop and distribute open source software.

Where can I find the current version of OpenChain ISO/IEC 18974?

You can find it on the OpenChain Project conformance page:
https://www.openchainproject.org/get-started/conformance

Does an open source program need to satisfy all the requirements of OpenChain ISO/IEC 18974 to be conformant?

Yes. OpenChain ISO/IEC 18974 defines the key requirements of a quality open source security assurance program. To make sure there are no gaps that would lead to poor quality output, a program must satisfy all the OpenChain ISO/IEC 18974 requirements to be considered conforming.

Can software packages be OpenChain ISO/IEC 18974 conformant?

No. OpenChain ISO/IEC 18974 defines a quality open source security assurance program. The program is conformant. The software packages go through the program and therefore benefit from it. The question to ask suppliers is whether the software they supply was prepared under an OpenChain ISO/IEC 18974 conforming program.

Does all the software in an organization need to be covered by an OpenChain ISO/IEC 18974 conformant program?

No. Organizations are often made from different groups or departments with different programs and release procedures. One example is that engineering may be very different from professional services). An organization decides how much of the total entity to cover with its OpenChain ISO/IEC 18974 conformant program. Many companies start with one part of one group covering one product, and build out from there.

Does OpenChain ISO/IEC 18974 serve as a best practice guide?

No. OpenChain ISO/IEC 18974 defines a quality open source security assurance program. It focuses on the “what and why” aspects of a program and not the how or when. A best practices guide must explain how and when to ensure it supports implementation activities. We publish reference material like Playbooks covering these topics, but they are separate to OpenChain ISO/IEC 18974 itself.

How was OpenChain ISO/IEC 18974 developed?

The OpenChain Project developed OpenChain ISO/IEC 18974 via our specification mailing list and calls. The process was (and is) open to everyone. The initial draft of the OpenChain ISO/IEC 18974 (then called the OpenChain Security Assurance Reference Guide) was created in the 2021 period. It was restructured as the OpenChain Security Assurance Reference Specification in Q1 2022 and released as the OpenChain Security Assurance Specification in Q4 2022. Since then the OpenChain Project has continually reviewed and maintained the standard in an open, collaborative manner that mirrors how open source software is created.

Does OpenChain ISO/IEC 18974 describe how to comply with specific security requirements?

No. OpenChain ISO/IEC 18974 defines a quality open source security assurance program. It is not designed to identify, breakdown and interpret individual security requirements. The specifics of each requirement and obligation must be determined by each company for their respective market space and legal jurisdiction.

Does OpenChain ISO/IEC 18974 provide legal guidance?

No. The specification does not provide legal guidance because that can only come from a legal expert assigned to advise an organization.

Does OpenChain ISO/IEC 18974 conformance guarantee security assurance?

No, but it significantly increases the probability that security assurance issues will arise for software prepared under an OpenChain ISO/IEC 18974 conformant program.

Do resources exist to assist my organization in achieving OpenChain ISO/IEC 18974 conformance?

Yes. You will find a substantial amount of resources, including self-certification checklists, on the OpenChain website:
https://www.openchainproject.org

What license is OpenChain ISO/IEC 18974 released under?

The version we host on our website is licensed under the Creative Commons Attribution License 4.0 (CC-BY-4.0). A copy of the license can be obtained here:
https://creativecommons.org/licenses/by/4.0/legalcode

OpenChain Self-Certification Questions

OpenChain ISO/IEC 5230:2020 and OpenChain ISO/IEC 18974 are designed to build trust around open source as clear and impartial standards. The approach is “less is more” and focus on what and why rather than how and when.

Our resources around self-certification are equally focused. They help organizations quickly understand practical application of the standards.

What is the objective of OpenChain Self-Certification?

OpenChain self-certification is designed to help an organization assess if it meets the requirements of the standard with simple questions or checklists. Organizations of any size can use self-certification as a way of improving their compliance approach and advertising that fact to their supply chain.

How do I scope Self-Certification for my organization?

There are three basic approaches to getting started with OpenChain Self-Certification.

1. A pilot project
2. A narrowly-scoped program
3. A widely-scoped program

Pilot Project

A pilot program is a very narrowly-scoped OpenChain conformant program, often used as a “test case” before applying the program to parts of the product production process. An example would be to run an OpenChain conformant program on a virtual product inside an Open Source Program Office (OSPO), with different OSPO members charged with roles or responsibilities contained in the relevant OpenChain standard.

The type of questions a pilot program is designed to answer include:

• Is our implementation approach covering all the requirements of the relevant standard?
• Do our planned actions and responses match both our internal production processes and the relevant standard?
• Can we begin to expand this pilot towards production teams?

Narrowly-Scoped Program

A narrowly-scoped program covers some aspects of a company production process related to internal or externally deployed software products. This is the most common type of OpenChain conformant program, with the “narrow scope” often starting very small and expanding over time.

An example would be to run an OpenChain conformant program on a team that covers a single codebase inside a company. This would be the narrowest production program.

Another example would be to run an OpenChain conformant program on several codebases or entire products inside the company. This is where most companies operate OpenChain conformant programs.

The type of questions a narrowly-scoped program is designed to answer include:

• Does this cover key open source code?
• Does this contain our IPR risk effectively?
• Does this match or surpass what our customer companies are asking for?

Widely-Scoped Program

A widely-scoped program is the same as a narrowly-scoped program, but generally covers the entire legal entity of the company. This is a rare choice (most companies have plenty of product lines that do not include open source), but some companies choose to create such programs. It does create a badge of distinction in terms of the effort the company places on open source compliance and other matters.

How do I complete the Self-Certification process?

You can use our self-certification questionnaire or checklist. You can access both via this page:
https://www.openchainproject.org/get-started

What if I don’t agree with a submission made by another organization?

Contact the OpenChain Project with the name of the organization you are concerned about and the reason you disagree with their submission. We will get back to you to discuss the matter further. It should be noted that disagreements about conformance are exceptionally rare (we did not encounter one directly yet), but it is important to have a way to make sure the market is using our standards in a fair and balanced manner. You will find our contact details at the link below:
https://www.openchainproject.org/about

Please let us know when you are conformant

Once you complete the process, please let us know so that we can add you to our Community of Conformance on the OpenChain Project website. This is not mandatory but it provides an advantage to you (more of your peers know that you have the key requirements of a quality open source compliance program in place), and it provides an advantage to us because we have more insight into market adoption. You can let us know about your conformance by contacting our helpdesk.

Cyber Resilience Act (CRA):

From the European Commission’s website:

The Cyber Resilience Act (CRA) aims to safeguard consumers and businesses buying software or hardware products with a digital component. […] The Cyber Resilience Act introduces mandatory cybersecurity requirements for manufacturers and retailers, governing the planning, design, development, and maintenance of such products. These obligations must be met at every stage of the value chain. The act also requires manufacturers to provide care during the lifecycle of their products.

The OpenChain Project is actively working to support the open source community in addressing the challenges and opportunities presented by the CRA in the context of a more trusted supply chain. Our existing standards are inherently supportive of the known and likely requirements to emerge from the CRA regulatory environment.

OpenChain ISO/IEC 5230 (license compliance) and OpenChain ISO/IEC 18974 (security assurance) both ask for the creation and archiving of information, helping to ensure organizations can track, review, and adjust processes as needed.

We also work in collaboration with our colleagues over at the Open Source Security Foundation (OpenSSF) around their Global Cyber Policy Working Group. Based on outcomes from this working group, and other relevant activities around the CRA, the OpenChain Project will evolve our support of the open source supply chain.

OpenSSF Global Cyber Policy Working Group

NTIA Minimum Elements For a Software Bill of Materials (SBOM):

From the NTIA website:

The Executive Order (14028) on Improving the Nation’s Cybersecurity directs the Department of Commerce, in coordination with the National Telecommunications and Information Administration (NTIA), to publish the “minimum elements” for a Software Bill of Materials (SBOM). This report builds on the work of NTIA’s SBOM multistakeholder process, as well as the responses to a request for comments issued in June, 2021, and extensive consultation with other Federal experts. 

The outcome of this activity is ‘The Minimum Elements For a Software Bill of Materials (SBOM)
Pursuant to Executive Order 14028 on Improving the Nation’s Cybersecurity.’

How OpenChain Supports The NTIA Minimum Elements For a Software Bill of Materials

OpenChain ISO/IEC 5230 for open source license compliance and ISO/IEC 18974 for security assurance both require the use of a Software Bill of Materials (SBOM) when managing software. OpenChain is fully compatible with and supportive of Executive Order 14028.

We have also developed other guides, reference material or solutions to assist in this area. Three key items are:

• The OpenChain Telco SBOM Guide – a guide to quality in SBOMs for the supply chain
• The OpenChain Telco SBOM Guide Validator – a tool to help automate reviewing SBOM quality
• The OpenChain SBOM Work Group – a group focused on how SBOM-related management in the supply chain can be improved

Note:

It should be noted that the OpenChain ISO standards do not define an SBOM format. The NTIA Minimum Elements cite three formats that may be used to meet their requirements. “These specifications have been developed through open processes, with international participation. In addition to being machine readable, these data formats are also human-readable, better supporting trouble-shooting and innovation. More importantly, these standards have been deemed interoperable for the core data fields and use common data syntax representations.“

The data formats cited by NTIA are:

• Software Package Data eXchange (SPDX)
• CycloneDX
• Software Identification (SWID) tags

The OpenChain Telco SBOM Guide uses the SPDX format. The OpenChain SBOM Study Group is exploring how cross-industry / cross-market guides may be developed in the future.

OpenSSF Open Source Project Security Baseline:

The OpenSSF Open Source Project Security Baseline (OSPS Baseline) is designed to act as a minimum definition of requirements for a project relative to its maturity level.

OpenChain ISO/IEC 18974 supports several aspects of the OSPS Baseline, and is included in the Compliance Crosswalk Matrix to map against the OSPS Baseline.

The Processes We Use:

The OpenChain Project has formal processes for developing and translating standards, and we have processes for opening and closing work groups or study groups. You can find these formal processes outlined on the dedicated processes page.

Ambassador FAQ:

OpenChain Ambassadors help to tell people about our work, help to support our community, and help to organize our meetings and events. Formally speaking, that means Ambassadors should provide support, training, mentorship and guidance to help:

• The OpenChain community through local meetups, events, and content
• Foster strong community collaboration and relationships
• Attract and welcome new community participants
• Provide feedback to the OpenChain Governing Board about community programs and initiatives
• Advocate OpenChain best practices and OpenChain initiatives around the world

We have some special resources to help Ambassadors in this FAQ. They are published publicly as part of our commitment to transparency and sharing knowledge with the community.

OpenChain Work Group Adoption Guide for Ambassadors

Executive Summary

The OpenChain Project requires active ambassador participation in work groups to ensure successful completion of critical initiatives and to foster community engagement. This guide outlines the adoption process and its strategic importance.

Why Adopt a Work Group?

Mission-Critical Impact:

Work group adoption by ambassadors serves two essential functions:

1. **Project Completion**: Direct support accelerates the completion of standards, guides, and training materials
2. **Community Catalyst**: Ambassador presence encourages broader community participation and engagement

Strategic Value:

– Ensures continuity and momentum in key project initiatives
– Provides consistent leadership presence across all work streams
– Creates accountability and structure for deliverables
– Strengthens the connection between governance and community activities

How to Adopt a Work Group

Step 1: Review Available Groups

Visit the participation portal to review meeting schedules and group details:
https://openchainproject.org/participate

Step 2: Select Your Preference

Complete the adoption form to indicate your preferred work group:
https://openchainproject.org/unlisted/2025/10/08/ambassador-help-adopt-a-work-group

Step 3: Commit to Participation

Time Commitment:
– One hour per month (attending the monthly call)

Engagement Expectations:
– Regular attendance at monthly meetings
– Active participation in discussions
– Support for work stream activities
– Encouragement of community involvement

Ambassador Responsibilities

When you adopt a work group, you commit to:

1. Monthly Attendance: Participate in the designated monthly call
2. Active Contribution: Engage in discussions and provide input on work products
3. Community Bridge: Connect the work group activities with the broader ambassador network
4. Progress Support: Help drive initiatives toward completion milestones

The Impact of Your Adoption

Immediate Benefits:
– Accelerated progress on critical deliverables
– Enhanced coordination between work groups
– Improved community engagement metrics

Long-term Value:
– Strengthened governance structure
– Sustainable project development model
– Increased community ownership of outcomes
– Enhanced credibility of OpenChain standards and guides

Call to Action

The success of OpenChain’s key initiatives depends on ambassador leadership and engagement. By adopting a work group, you directly contribute to:

– The evolution of international compliance standards
– The development of practical industry guides
– The growth and sustainability of the open source compliance community

Your one-hour monthly commitment creates exponential value for the entire ecosystem.

Resources

– Meeting Schedule: https://openchainproject.org/participate
– Adoption Form: https://openchainproject.org/unlisted/2025/10/08/ambassador-help-adopt-a-work-group
– Ambassador Resources: Contact the OpenChain Helpdesk for more resources.

OpenChain Community Call Facilitation Guide

Overview

This guide provides comprehensive instructions for facilitating OpenChain community calls, with particular emphasis on the Specification and Education meetings. All community meetings utilize automated recording functionality and permit participant entry up to ten minutes prior to the scheduled start time.

Meeting Structure and Governance

Autonomy and Core Meetings

OpenChain Work Groups and Study Groups operate with substantial autonomy. However, Ambassadors can always usefully lend a hand, and it should be noted that two core meetings maintain central importance to the project’s governance:

1. Monthly Specification and Education Call – North America and Europe Region
2. Monthly Specification and Education Call – Europe and Asia Region

These meetings serve as the formal venues for ISO standards development and revision.

Documentation and Resources

Key meeting presentations are archived in the OpenChain repository:
– Repository location: https://github.com/OpenChain-Project/Meeting-Slides/tree/main/2025/specification-education-monthly
– This repository serves dual purposes:
– Historical documentation of past meetings
– Template resource for future meeting materials
– You will also find slides for other meetings, and can use the resources here to build new slides as needed

Responsibilities

Core Duties

When facilitating a meeting, the moderator should:

1. Provide Meeting Context: Clearly articulate the meeting’s purpose and objectives
2. Cite Compliance Requirements: Reference the anti-trust policy notice at the meeting’s commencement
3. Navigate the Agenda: Systematically progress through agenda items and designated sections

Leadership Structure

Most Work Groups and Study Groups maintain designated chairpersons who provide formal leadership. Examples include:
– Specification Work Group: Chris Wood (2025/2026)
– Education Work Group: Martin Yagi (2025/2026)
– AI Work Group: Matthew Crawford and Dave Marr (2025/2026)
– SBOM Work Group: Norio Kobota (2025/2026)
– Telco Work Group: Marc-Etienne Vargenau (2025/2026)
– Tooling Work Group: Oliver Fendt (2025/2026)

Note on Regional Representation: The Europe/Asia Specification and Education call operates with partial chair representation, as only Martin (Education Chair) attends due to time zone constraints affecting Chris (Specification Chair). In such cases, facilitators utilize consensus items from the preceding North America/Europe call to ensure continuity.

Meeting Materials and Preparation

Slide Deck Utilization

For Specification and Education calls, facilitators may:
– Present relevant sections directly from prepared materials
– Delegate specific sections to Ambassadors or co-chairs as appropriate
– Pause for questions and discussion after each major section

Example Meeting Details

Specification and Education Meeting – Europe/Asia Region
– Date: October 15, 2025
– Time: 08:30 UTC
– Access: https://zoom-lfx.platform.linuxfoundation.org/meeting/98605614769?password=dd739f3e-5991-4c87-b428-39a7b550ca0d

Facilitation Best Practices

Encouraging Participation

The primary challenge in community meetings involves stimulating productive discussion. Effective strategies include:

1. Personal Engagement: Share relevant perspectives and experiences to model participation
2. Active Solicitation: Explicitly request input from participants on specific topics
3. Strategic Questioning: Pose questions that genuinely interest you and may resonate with attendees
4. Adequate Time Allocation: Provide sufficient pause for participants to formulate and share responses

Managing Meeting Dynamics

Low Participation Scenarios

Recognize that meetings may occasionally experience:
– Limited verbal participation
– Abbreviated duration
– General reticence from attendees

These situations are acceptable within the context of long-term community building. Focus on:
– Clearly communicating project goals
– Facilitating pathways for contribution
– Consistently sharing outcomes and progress

High Participation Scenarios

When multiple participants wish to contribute simultaneously:
1. Acknowledge all raised hands or requests to speak
2. Establish a clear speaking order by naming participants in sequence
3. Systematically work through the queue
4. Ensure equitable speaking time distribution

Handling Disruptions

While rare (with isolated incidents during the COVID-19 period), disruptive behavior should be addressed promptly and professionally according to community guidelines.

Key Principles for Success

Successful facilitation of OpenChain meetings relies on:
– Knowledge Synthesis: Recognition that collective expertise drives innovation
– Inclusive Environment: Creating space where all participants feel valued
– Long-term Perspective: Understanding that community building requires patience and consistency
– Clear Communication: Articulating goals, processes, and outcomes effectively

Conclusion

Effective meeting facilitation serves as a cornerstone of the OpenChain Project’s collaborative development model. By following these guidelines, facilitators contribute to the advancement of open source compliance standards and the strengthening of our global community.

End of Current Ambassador Guides

We have a dedicated page explaining our Ambassador Program here: https://openchainproject.org/openchain-ambassadors. That page includes detailed information on who our current ambassadors are, what work groups or study groups they have adopted, and – where applicable – links to their professional social media profiles.