Open Source Summit + Embedded Linux Conference North America 2026

We all want our open source projects to be sustainable, healthy, and successful. Good governance has a much larger impact on sustainability, health, and project success than many people realize. Being proactive about governance before something escalates into a crisis can help avoid misunderstandings and make your projects more sustainable and successful.

A lightweight governance model created at the beginning of a project can provide basic guidance about roles, expectations, and decision-making processes. As the project grows and matures, governance can be expanded over time to become more robust as the project evolves. However, good governance is about more than just defining roles and decision-making processes. It can be part of the process of building a sustainable leadership pipeline and can help to create an intentional culture that encourages participation and contributions from others.

This talk will provide details about the importance of governance, how to define project governance, using governance as a pathway to leadership, creating an intentional culture, and making project ownership (e.g., individual, organization, foundation) decisions.

Project X goes EOL at the end of this sentence; good luck with the CVEs. Project Y has a new license meaning you can’t use it anymore; what do you mean, your team built something important on it? Project Z works great but you built a new feature in your fork, and now you can’t take the upstream patches. Half of your open source environments may have a dependency on some now-defunct project, and now everyone’s scrambling for solutions.



Join experienced open source maintainers to discuss what warning signs can help prevent abrupt retirement or relicensing from taking your end users by surprise. We’ll outline the ways you can get visibility into your software supply chain and become active in the upstreams that matter most for your needs, ensuring that you’re in control of your own destiny no matter what storm of alphabet soup comes your way.

When does maintaining a project become more harmful than helpful? As the leader of the OpenJS Foundation, home to Node.js and more, I will give a candid talk to unpack the hardest question in open source: how do you know when it’s time to let go? Drawing from real-world examples from leading one of the web’s most widely used open source foundations and its JavaScript projects like Lodash, jQuery, and Express, I will explore what it means to responsibly sunset a project, merge with others, or double down on maintenance. You’ll learn how to read the signs for security and sustainability, engage the community, and what it takes to wrap up a project with integrity, especially when billions of developers still rely on it.

FLOSS Mentorship Unconference: A Community Event to Share, Shape, & Scale Mentoring Efforts in Open Source (Open to All Attendees; No Pre-registration Required)

An unconference afternoon for anyone engaged in open source mentorship -- or who would like to be. We’ll build the agenda on-the-spot, then move into focused discussions to share best practices, challenges, and aspirations. Expect to leave with new contacts and a shared action list for better, more sustainable mentoring. Topics crowdsourced day-of – join us just to listen, or to pitch one of your own!

AI is doing real work in open source. Answering questions, reviewing PRs, writing patches. Some communities ban it, others label it. Most will accept it because policing AI is exhausting and the tooling is useful.

Here's what bothers me. Everyone argues about allowing AI contributions. Nobody talks about what we lose when humans stop doing the work. AI can write code. But it can't show up to community calls for two years. It can't help someone push their first PR. It can't convince a burned-out maintainer to stay. Leadership isn't a pull request. It's a relationship.

We have a leadership problem. Projects lose maintainers faster than they grow new ones. AI makes it worse by paving over entry-level work that used to get people involved.

The policy landscape is messy. Apache requires disclosure. OpenTelemetry treats AI as a tool. Linux Kernel won't accept patches without a human behind them. These policies reveal how communities define contribution, accountability, and belonging.

My argument is simple. Stop fighting AI. Start investing in what it can't do. Mentoring. Building trust. Growing leaders. That's what's at risk.

Traditional developer relations relies on metrics that favor product adoption, but successful open source developer relations demands a more nuanced approach. Your organizational role in and goals around open source projects dictate your strategy.

We'll first dissect where and how open source developer advocacy diverges from proprietary developer relations strategies. We’ll then dive into four distinct engagement models, metrics of successful advocacy in each, and why success in one cannot necessarily be transferred to another:
* The Adopter: Companies advocating for an open source technology used heavily internally.
* The Champion: Companies serving as a major contributor to a mature open source project and its ecosystem.
* The Business: Companies building a commercial offering around an existing open source technology.
* The Founder: Companies open sourcing a new project and building its community from zero.

Attendees will leave with a clear framework for diagnosing their organization’s role in the open source ecosystem and an understanding of the which metrics, communication channels, and contribution strategies will actually lead to sustainable community growth and impact.

Open source used to mean something simple: the code is open, the community builds it, and everyone benefits. That world is gone. Today, billion-dollar companies release model weights and call it "open source"

Projects launch with permissive licenses but lock their APIs behind paywalls. Foundations host projects where one vendor controls 95% of the commits. And a new generation of developers is entering open source through AI-generated pull requests they barely understand.

I've spent 7 consecutive Kubernetes release cycles on the release team, helped build and maintain Kargo - a OSS project for GitOps continuous delivery and worked as a CNCF Ambassador helping new contributors navigate this ecosystem

I've watched the definition of "open source" stretch, bend & sometimes break in real time.

This talk is about the real problems developers face today when they try to contribute to, depend on, or build careers around open source projects that don't play by the old rules. I'll share what I've learned about spotting "open-washing" evaluating project health beyond the GitHub star count, and building genuine community in an era where the incentives have fundamentally shifted.

It's no secret that building and sustaining thriving open source communities requires moving beyond sporadic contributions and fostering an ecosystem of engaged members. That process is not simple, and requires a lot of time and effort, which is not often something a maintainer has, which more often than not leads to maintainer burnout or project stagnation.

In this talk, Jeremy will connect the principal of a "flywheel" that we see in everyday life with the principles of Developer Experience, and discuss what a "DevEx Flywheel" should look like. He will explore how things like feedback loops, "time to joy", onboarding, and documentation all contribute to an experience that can enhance contributions, which in turn improves project health, value, and more.

This session will explore what the DevEx Flywheel looks like, and provide actionable strategies for:
- Creating seamless onboarding experiences and amazing documentation
- Implementing tooling and automating workflows by reducing friction
- Fostering welcoming communication and effective feedback loops

Stop hoping for community growth; start engineering it through Developer Experience.

As a maintainer of both Grafana Tempo and CNCF Jaeger, and a dev advocate, we've seen a large increase in LLM-supported contributions. Pull requests, issues, discussions, and design proposals have been flooding into these projects at a rate never before seen. The level of effort to submit a reasonable-looking PR has dropped to nearly 0. The level of effort required to review a reasonable-looking PR has also been reduced with LLM assistance, but not nearly to the same degree.

Within Jaeger and Tempo, we've begun discussing ways to approach these PRs. We want to encourage contributions to OSS projects, but need invested humans on the other side of the PRs in to merge them. Generally, we celebrate the lowering of both language and technical barriers for participation, but as gatekeepers of critical OSS projects, it's our responsibility to only merge stable, well-considered code.

Join to commiserate, discuss, or simply listen to some war stories about what it's like to be an OSS maintainer in the land of LLMs. We'll also survey responses we and others have taken across the OSS community. This submission was entirely human-generated and reviewed. We don't know if that matters :).

The OpenSSF BEAR (Belonging, Empowerment, Allyship, and Representation) Working Group is on a mission to make cybersecurity a place where everyone belongs! We knock down barriers and crank up the volume for underrepresented voices. We've learned that true representation is about building fun, lasting paths for participation.

In this session, we'll take you on a journey through the evolution of BEAR, culminating in the exciting launch of our newest global family member, SIG OSSAfrica (Open Source Security Africa)! We'll share some insights and "Aha!" moments from our monthly Community Office Hours - including those unexpected successful strategies - and get honest about the triumphs and challenges of our mentorship program.

Looking to level up your community game? Whether you want to understand the real-world challenges facing diverse groups in security or just need some practical, battle-tested frameworks for building vibrant community programs, this session is your toolkit. Get ready for an open, fun look at building a truly inclusive open source security community!

Open source projects everywhere are asking the same question: where will the next generation of reliable contributors or maintainers come from? The answer is already here, students, but most projects lack a repeatable, maintainer-friendly system to convert student interest into sustained, high-quality contributions.

This session presents a field-tested, scalable framework for turning students from first-time contributors into long-term community members and technical collaborators. Drawing from real program experience working with student contributor pipelines, we will break down how maintainers and organisations can design contribution pathways that reduce review burden, improve contribution quality, and increase retention, without diluting project standards.

We will cover practical ideas for structuring beginner-to-advanced issue ladders and contributor experience design that keeps students engaged beyond their first pull request. The talk will also address common maintainer concerns around signal-to-noise ratio and review bandwidth when working with early-career contributors.

Open source inclusion strategies often overlook the unique business goals and scaling complexities of large organizations. This talk addresses that disconnect, offering experience-led guidance on establishing effective cross-functional communication channels.
While many programs exist to encourage community inclusiveness, they rarely translate to corporate environments "as-is." Based on challenges observed in previous BoF sessions - although many people were interested in adopting open source, they were also frustrated with the same issues, yet did not have a functioning cross-BU channel in which to discuss. To close this gap I ran several programs to execute that:
• Connect and learn: Align teams through shared interests
• Shift mindsets: Instill an "upstream first" culture and environment
• Break barriers: Identify and remove obstacles preventing contributions
• Drive strategy: Leverage market and company trends to support decision-making
Participants will walk away with actionable strategies to enhance inclusiveness, ensuring that engagement efforts benefit both the organization’s bottom line and the wider open source ecosystem.

Open source has made progress in recognizing neurodiversity, but most conversations remain at the level of awareness and good intentions. What happens on Day 2, after we agree that inclusion matters?

We will examine what is still missing in the open source neurodiversity conversation, critique the narrative of neurotalent, and evaluate whether framing neurodivergent contributors as inherently gifted helps inclusion or creates new pressures. We need to ask: are we reinventing existing initiatives, or does the real gap lie in how our contribution models, communication norms, and governance structures are designed?

Our goal is to tackle structural questions rather than proposing a new label or movement. How can open source communities reduce cognitive friction, clarify expectations, and design processes that support a wider range of thinking styles? What concrete steps move us beyond fundamentals and into sustainable practice? Join Merge Forward to help move open source from a culture of good intentions to one of engineered accessibility.