Open Source Summit + Embedded Linux Conference North America 2026

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 :).