Privacy, Security and Performance: The Hard Lessons of Feature Flagging with Todd Baert

Around 90% of commercial software is built on open source, yet only a small fraction of the companies using it give anything back. Meanwhile, the maintainers who keep it running are burning out, and a 2025 survey found 58% of them have considered quitting.In this episode, Brian Wilson and Andi Grabner talk with Sebastian Kister, Chief AI Architect and Lead of OSPO Contribution & Maintainership at Volkswagen Group (assigned by Audi AG). Andi met Sebastian at Cloud Native Days Austria, where his talk on enterprise AI foundations made one point very clear: passive consumption of open source is a long-term risk.Sebastian explains why upstream contribution is a business case and not charity. It shapes the standards your products depend on, extends your product lifecycle, and prevents short-sighted migrations. It also gets you ready for regulation like the EU AI Act and SBOM mandates, and it’s one of the strongest recruiting signals for top engineering talent. He also shows how it can be organized in practice: a group-level OSPO that frees employees to contribute to projects like OpenTelemetry and OpenSearch during work time, and connects the inside world with the outside one.We also dig into:Sovereignty: why it has less to do with geography than with control, business continuity, and being able to leave the room on your own terms.Make or buy: Andi plays devil’s advocate on whether buying enterprise software is a safe alternative to contributing.Evaluating vendors: why contribution should become a criterion when enterprises choose vendors.Writing for AI: whether to write blogs for humans or for AI agents.And yes, the world’s best limoncello of 2025 doesn’t come from Italy. It comes from Sebastian’s distillery in Bavaria.Links we discussedSebastians LinkedIn: https://www.linkedin.com/in/sebastiankister/Cloud Native Austria Talk: https://www.youtube.com/watch?v=zue4cg8lcR0Sebastians new blog: https://sebastiankister.de/keynote/

What does it take to truly observe an AI application? In this episode, we sit down with Giovanni Lima — Open Source Contributor to OpenTelemetry, OpenFeature, and Keptn, and Principal Software Engineer at Dynatrace working on AI Observability.We explore how to instrument AI apps with frameworks like OpenInference, what distributed traces reveal about agent topology, model cost, performance, and accuracy, and why prompt engineering and observability go hand in hand.We also look at emerging trends: internal agentic platforms for back-office automation, and how organizations self-hosting models use observability to optimize hardware, inference, and caching.LinksGiovanni's LinkedIn: https://www.linkedin.com/in/giovanni-liva-101a1532/OpenTelemetry: https://opentelemetry.io/OTel AI Semantic Conventions: https://github.com/open-telemetry/semantic-conventions-genaiOpenInference: https://github.com/Arize-ai/openinference

In the second part of our conversation with Todd, Maintainer of OpenFeature, we learn about why implementing feature flagging is not as easy as at looks at first glance. As a framework developer you need to think about where feature flag evaluations are done. Ideally as close as possible to where your confidential data is you use for making a decision. But that comes with other challenges such as propagating your rule engine potentially to millions of mobile devices.If you think you know all the edge cases then think again and tune in to this episode. Learn about how to not leak any confidential data, how to avoid propagating rules with PII data to millions of devices, and how to build a framework that can evaluate within flags within milliseconds regardless of where your end users execute your code to avoid any impact on end user experience.LinksTodd’s LinkedIn: https://www.linkedin.com/in/toddbaert/OpenFeature: https://openfeature.dev/Introducing OpenFeature Podcast: https://www.spreaker.com/episode/introducing-openfeature-stepping-into-the-footsteps-of-opentelemetry-with-mike-beemer-and-todd-baert--50043067

Feature flagging is almost as old as software engineering – but only since the increased adoption of AIDLC (AI- Delivery Life Cycle) it has really taking off like AI has taken off as the default way to generate code!In this episode we welcome back Todd Baert, Maintainer of OpenFeature, and learn about the many different use cases of Feature Flagging. Todd explains how feature flagging evolved from simple variables that pivot code execution towards dynamic evaluations that are supported by modern frameworks like OpenFeature and feature flag management systems that are based on that cloud native standard.Tune in and learn what the biggest competitors of OpenFeature are, why feature flagging requires less thinking during development than you think and how it mitigates the risk of AI generated code having negative impact on your systems resiliency!LinksTodd’s LinkedIn: https://www.linkedin.com/in/toddbaert/OpenFeature: https://openfeature.dev/Introducing OpenFeature Podcast: https://www.spreaker.com/episode/introducing-openfeature-stepping-into-the-footsteps-of-opentelemetry-with-mike-beemer-and-todd-baert--50043067

What happens when your AI coding tools outpace your delivery platform? Andi Grabner and Brian Wilson find out with Michael Binz, DevRel for Juno - the Internal Developer Platform (IDP) at Dynatrace. Together they walk through the full journey of building an IDP that keeps up with AI-speed engineering. Juno serves as a knowledge base, automation hub, and organizational memory across the entire software delivery lifecycle. If your platform can't scale with your AI ambitions, your 10x engineers are working on a 0.1x foundation. This episode shows you what to do about it.Links we discussed:Michaels LinkedIn: https://www.linkedin.com/in/michael-binz-a1307a111/YouTube Video of their talk: https://www.youtube.com/watch?v=3Ow9rIdv-x8Bluebox: https://www.bluebox.ai Max Headroom: https://www.youtube.com/watch?v=egCOO7Zzq0U

Three years ago, Roman Ferstl — entrepreneur, founder, and returning PurePerformance guest — found himself experiencing something he struggled to explain to anyone who hadn't lived it. In this episode, he joins Andi Grabner and Brian Wilson to talk openly about burnout, anxiety, and depression: how they overlap, how they build on each other, and what the science of sleep, the nervous system, and neuroplasticity reveals about why recovery is genuinely possible. Honest about therapy, medication, and mindfulness — what worked and what didn't — Roman's goal is simple: if even one person listening takes one sentence away that changes something for them, the conversation was worth having. You are not broken. And it can get better.

When AI can generate and optimize code at scale, does that make software greener — or just faster to get wrong - or does it cost more to train and run those AI models then the savings we have optimizing our own software? Anne Currie, co-author of O'Reilly's Building Green Software, joins us to untangle the paradox. US data centers are on track to consume over 10% of the national grid by 2030 with a growing part of that energy going to AI workloads, yet it may also be our best tool for writing more efficient software — if the training data is any good (spoiler: for C, it often isn't; for Rust, it's a different story).In our episode Brian, Andi and Anne get into the fundamentals that most teams are skipping: operational efficiency. Turning off systems you don't need, rightsizing what you do — these unglamorous moves can slash your hosting bill in half, and they're the prerequisite for any code-level green gains to actually matter. Plus: graceful shutdowns, grayouts, and why we'll probably need AI to eventually rewrite itself.Links we discussedAnne's LinkedIn: https://www.linkedin.com/in/annecurrie/Her podcast: https://www.asynchronousunreliable.com/Chapter 3 of her O'Reilly book: https://www.strategically.green/chapter-3-code-efficiencyFull book on Amazon: https://www.amazon.com/dp/1098150627Brian's story on Myst: https://www.youtube.com/watch?v=EWX5B6cD4_4

AI coding tools are everywhere, but how do you prove they're actually making engineers more productive?In this episode of PurePerformance, hosts Brian Wilson and Andi Grabner welcome Michael Reichenbach, Platform Engineer at 1KOMMA5°, to discuss the company's journey toward more than 80% AI-written code. Rather than relying on anecdotes or hype, Michael shares how his team designed a real experiment to measure the impact of AI-assisted development.We explore the metrics they chose, why traditional DORA metrics such as deployment frequency and change failure rate were not the right indicators, and how they instead focused on "Time to Code" from ticket creation and first commit to merged pull request. Michael also explains how AI lowered the barrier for contribution across the organization, enabling even non-engineering teams to prototype and build solutions faster.The conversation also dives into the operational side of AI adoption, including AI observability dashboards, budget controls, Slack alerts, usage monitoring, and the surprising decision to intentionally limit AI spending during their proof of concept.Whether you're evaluating Cursor, GitHub Copilot, or other AI coding tools, this episode offers practical lessons on measuring value, maintaining quality, and scaling AI adoption responsibly.Links we discussedMichael's LinkedIn: https://www.linkedin.com/in/michael-reichenbach/Klaus's LinkedIn: https://www.linkedin.com/in/langenheldt/Talk at Cloud Native Munich: https://www.youtube.com/watch?v=Ntf0h0vFuMQ1Komm5 Website: https://1komma5.com/Kenote from KubeCon: https://youtu.be/P1phxZHJGrA?t=570&is=9DYnbK8VGorMmaXoMichael's YouTube Playlist: https://youtube.com/playlist?list=PLn-u2xOcMlXlVweZ0aB4pu6VM6Xv6895i&si=MZ6jzF-VwIAY3HFF

"There is no single way to deploy OpenTelemetry at scale—and that’s exactly the challenge."As organizations adopt OTel across teams and environments, they face tough questions around standardization, configuration, and operating resilient observability pipelines.To address these challenges, the OpenTelemetry community has introduced Blueprints and Reference Implementations—practical guidance on topics like data standards, consistent agent and collector configuration, pipeline resilience, and intelligent sampling.In this episode, we’re joined by Dan Gomez Blanco, maintainer of the OpenTelemetry End-User SIG, to explore real-world reference architectures from organizations like Skyscanner, Adobe, and Mastodon.Tune in to learn how the community is turning OTel complexity into shared best practices—and how you can contribute your own blueprint

I still hear people say, “OpenTelemetry is vendor-neutral, so you can switch any time!”In this episode, Adriana Villela and Josh Lee (both active OpenTelemetry contributors) help bust that myth.While OTel standardizes instrumentation and signal transport—and unlocks a rich ecosystem of tools—switching vendors isn’t as simple as it sounds. There’s real cost in retraining engineers, migrating dashboards, SLOs, and alerts, and reworking deep integrations across your delivery pipeline.We also dive into a key challenge the community is tackling: helping engineers instrument by value, not by default—making it easier to capture the right signals with high quality instead of just collecting everything.Here the links we discussed:Adriana's LinkedIn: https://www.linkedin.com/in/adrianavillela/Josh's LinkedIn: https://www.linkedin.com/in/joshuamlee/The blog article: https://thenewstack.io/opentelemetry-vendor-neutrality-guide/CND Austria Talk: https://www.youtube.com/watch?v=1gxLseuaTdMKCD Prague Talk: https://www.youtube.com/watch?v=pPXG20CXKxQOpenTelemetry Project Website: https://opentelemetry.io/