Open Source Summit North America 2025

It’s product release time. The code is stable. You’ve got everything EXCEPT the docs.

How do you create meaningful, prioritized content in a short time frame?

Your writer needs to collaborate with a Subject Matter Expert (SME) who understands the technical and user content. At Grafana, this synergy happens between Field Engineers (FE) and Technical Writers (TW). FEs are a three-in-one SME with the understanding of a developer, sales engineer, and technical support.

How does this collaboration benefit both writers and SMEs?
* TW has a single SME for user needs and cross-product technical expertise.
* FEs get accurate, up-to-date content that helps them and Grafana’s OSS community members get up to speed on products.
* OSS Community members get accurate, up-to-date docs.

In this session, you’ll learn how to:
* Identify the right SME
* Establish a collaborative workflow
* Prioritize work that best addresses the user’s needs

We’ll detail how this collaboration started through a shared love of RPGs, the traps we encountered and lessons learnt, and how a bi-weekly session between two colleagues became the foundation for a model now used across Grafana’s telemetry products.

Documentation thrives on contributions, but many potential contributors hesitate to edit docs because of uncertainty about style, structure, and quality standards. This talk demonstrates how modern tooling can create a supportive environment that empowers non-writers to confidently contribute to documentation. We'll explore a practical toolkit combining templates for clear structure, AI-powered drafting assistance, automated style checking, format linting, content validation, and quality reviews to guide contributors through the docs process. Through these tools and a streamlined editing workflow, teams can create an environment where developers, product managers, support staff, and other non-writers feel confident contributing while maintaining documentation standards. We'll examine real examples of successful implementations and provide practical steps for adding these capabilities to your own docs.

In an era when transparency is often a corporate buzzword, few companies truly embrace it at scale. What happens when a company commits to making nearly all of its internal documentation open source? What are the benefits, risks, and unexpected cultural shifts that arise?

In this session, we’ll take a deep dive into our company’s journey of open-sourcing nearly all documentation—from GitHub issues and design review notes to sprint demos and research documents. We’ll explore the motivations behind this decision, the technical and cultural challenges we faced, and the impact on our customers, employees, and open-source contributors.

Join us as we dissect the practical realities of radical transparency in engineering and product development. Whether you’re considering a similar approach or simply want to understand how transparency at scale affects innovation, security, and collaboration, this session will provide invaluable lessons and strategies.

As part of a broader effort to document the architecture and design of the Linux Kernel, we propose a method to formally describe low level developer intent in the form of testable expectations (i.e. requirements). This will provide a fact based foundation for pass/fail test development, test validation via code coverage tools, support optional traceability to higher level design, and enable tool development for process automation.

This talk is a continuation of the proposal for Linux Kernel Requirements that formally originated at the 2024 Linux Plumbers Safe Systems with Linux Mini-conference, and further updated at the December 2024 ELISA Workshop at Goddard Space Center.

This edition will present the current state of the requirement template design, provide examples of Linux kernel source code instrumented with low level requirements, present technical explanations for template design decisions, and provide an opportunity for feedback from the developer community.

When documentation becomes outdated, projects lose contributors, support burdens increase, and adoption slows. Yet, many open-source projects struggle with maintaining accurate docs as the codebase evolves.

This session presents five proven strategies to turn documentation from a pain point into a sustainable asset:

Integrate Docs into Development: Treat docs like code, updating them alongside new features through PR workflows and docs-driven development.

Establish Governance: Assign documentation ownership with roles like a rotating "Docs Steward" and regular audits to maintain quality.

Master Versioning: Align docs with software releases, automating updates for deprecated features or breaking changes

Leverage Automation: Use tools to validate content, detect outdated material, and auto-generate sections like API docs

Build a Documentation Culture: Create a contributor-friendly environment with templates, recognition, and clear entry points for first-time contributors

Instead of theory, you'll get adaptable frameworks and real-world examples that work across any tech stack. Leave with actionable workflows that make documentation maintenance less painful and more impactful.

In an era of growing concerns over misinformation, surveillance, and data breaches, building a more secure, private, and authentic web has never been more critical.

In this talk, I'll explore the current state of web security, privacy, and authenticity, focusing on key efforts shaping the future of the open web. You'll hear about the latest work in W3C, including advancements in privacy principles, ethical web guidelines, web developer security guidelines, all aimed at creating a more secure, trustworthy, and user-centric web. You'll also learn about how emerging standards like Content Credentials (C2PA) may revolutionise the way we verify the authenticity of digital content, helping to combat misinformation and ensure transparency in the information we consume online.

When faced with a difficult challenge sometimes it helps to look back at lessons from ancient history to guide your thinking. The Open Source Initiative (OSI) is working to create a definition for Open Source AI (OSAID), aiming to apply open source principles to artificial intelligence development, but clearly the 1.0 version is a work-in-progress. Can it find success? How may policy-makers react? Join this session to hear about the latest efforts to define open source AI and what's likely in store for 2025.

Refreshing long-standing policies in OSS communities can be a long and difficult process. Last year at OSS Summit NA, we discussed getting to the mid-point in our journey in developing a new trademark policy for the Rust community. Following a lot of further work, consultation, and iteration, and final board approval, we are now able to reflect on the whole process of redeveloping a legal policy with an OSS community, the pitfalls, challenges, and paths to success.

Software Asset Management (SAM) provides a way to manage software across small, medium and large entities. It is often seen as a way of addressing licensing or for making sure company staff are using permitted software applications and versions.

Open source has traditionally been divorced from SAM, which was focused on proprietary software solutions. Partly this was due to practical matters like different licensing schemes, and partly it was an artifact of separate paths of evolution.

However, in recent years open source has increasingly adopted approaches to licensing, security and other challenges that mirror SAM. Examples include the use of standards like ISO/IEC 5230 for licensing and ISO/IEC 18974 for security, of implementation standards like ISO/IEC 5962 for Software Bill of Materials.

As a consequence, open source is now more closely aligned with SAM. This talk will examine what that means for open source management overhead today, and where it will take us in the future. This talk is intended to equip people in open source strategy, legal and team leadership to navigate changes as smoothly as possible.

Last year we introduced the LF-SBOM, which we are now generating for many projects. Today we will provide an update on this important effort to provide SBOMs for most critical LF projects. We will review the work done to date, and go into more detail on how to use the LF-SBOM specification. We will give real world concrete examples on how to use our SBOM to generate a Security Vulnerability report, and how to generate a report of open source licenses. We will also discuss how to use our SBOMs to meet new regulations (e.g. US CISA and EU CRA) when delivering software to the government sector, and how to use our SBOM as an example when you create one for your own project.

Picture the WHOLE software supply chain, beginning to end; it's a little like that olde tyme classic, "Candyland".

Designed NOT with preschoolers in mind, AI Supply Chain Candy Land is for everyone interested in learning about the software supply chain for AI/ML. Travel through exotic locations like The Peppermint Forest of swirly-twirly dependencies, The Fudgy Swamp of Compliance, and much more!

AI/ML is a fast-moving space within technology. However, everything we've learned in software engineering of the last few decades ALSO applies to this "new" world of AI/ML. We'll apply traditional software supply chain security techniques and, wherever able, tools to help developers and consumers win AI Supply Chain Candyland.

Through an enjoyable and colorful game, with useful examples taken from standards and frameworks, the audience will have a better appreciation and ability to apply supply chain security concepts and tools to the development and support of AI/ML-based solutions.

The EU Cyber Resilience Act (CRA) aims to safeguard European consumers and at first glance it targets only the EU market. But in fact the entire OSS ecosystem falls under its scope as CRA creates mandatory cybersecurity requirements for vendors, distributors, integrators, even enterprise consumers and, in fact, the entire open-source ecosystem by introducing terms like “Manufacturer”, “Steward”, “Individual developer” among others. So, how to ensure **you** stay compliant?

I’ll cover what we, as part of the various working and regulatory expert groups, are doing to help the entire open-source community navigate the actual requirements. We’ll explore how these roles are played together by the leading industry players (yes, revealing some non-trivial scenarios) and what best practices and tools can be used right away for your organization or by you as an individual contributor. Finally, let’s discuss how we together should turn CRA into an opportunity to make open-source better for all.