This is a part of the Fedora Linux 43 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts today, Wednesday 17th December and closes promptly at 23:59:59 UTC on Wednesday, 7th January 2026.

Interview with Daniel Mellado

  • FAS ID: dmellado
  • Matrix Rooms: #ebpf, #fedora-devel, #rust, #fedora-releng, and a lot of #fedora-* 😉

Questions

Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

I accepted this nomination because I believe FESCo would benefit from fresh perspectives, and I think that these new perspectives will also help to lower the entrance barriers for Fedora.

Governance bodies stay healthy when they welcome new voices alongside experienced members, and I want to be part of that renewal.

Technologies like eBPF are redefining what’s possible in Linux–observability, security, networking–but they also bring packaging challenges that we haven’t fully solved, such as kernel version dependencies, CO-RE relocations, BTF requirements, and SELinux implications.

On FESCo, I want to help Fedora stay ahead of these challenges rather than merely reacting to them. I want to advocate for tooling and guidelines that will help make complex kernel-dependent software easier to package.

How do you currently contribute to Fedora? How does that contribution benefit the community?

I founded and currently lead the Fedora eBPF Special Interest Group. Our goal is to make eBPF a first-class citizen in Fedora, improving the experience for the developers who are building observability, security, and networking tools and figuring out how to package software that has deep kernel dependencies.

On the packaging side, I maintain bpfman (an eBPF program manager) and several Rust crates that support eBPF and container tooling. I’ve also learned the hard way that Rust dependency vendoring is… an adventure. 😅

Before Fedora, I spent years in the OpenStack community. I served as PTL (Project Team Lead) for the Kuryr project, the bridge between container and OpenStack networking and was active in the Kubernetes SIG. That experience taught me a lot about running open source projects: building consensus across companies, mentoring contributors, managing release cycles, and navigating the politics of large upstream communities.

I try to bring that same upstream, community-first mindset to Fedora. My hope is that the patterns we establish in the eBPF SIG become useful templates for other packagers facing similar challenges.

How do you handle disagreements when working as part of a team?

I start by assuming good intent. If someone is in the discussion, it’s because they do also care about the outcome, even though they may have another point of view.

I also try not to speculate about why someone holds a particular view. Assigning motives derails technical conversations fast. Instead, I focus on keeping things facts-driven: what does the code actually do, what do users need, what are the real constraints? Egos don’t ship software, and sticking to concrete data keeps discussions productive.

When disagreements persist, I find it helps to identify what everyone does agree on and use that as a new starting point. You’d be surprised how often this unblocks a stalled conversation.

Also, I think that it’s important to step back. It’s tempting to want the final word, but that can drag things on forever without real progress. Miscommunication happens and not every discussion needs a winner.

What else should community members know about you or your positions?

I believe in Fedora’s Four Foundations: Freedom, Friends, Features, First. What draws me to this community is the “Friends” part: there’s a place in Fedora for anyone who wants to help, regardless of background or technical skill level. Open source is at its best when it’s genuinely welcoming, and I want FESCo to reflect that.

From my time in the OpenStack community, I learned that healthy projects focus on protecting, empowering, and promoting: protecting the open development process and the values that make the community work; empowering contributors to do great work without painful barriers; and promoting not just the software, but the people who build and use it. I try to bring that mindset to everything I do.

I also believe strongly in working upstream. The changes we make should benefit not just Fedora users, but the broader open source ecosystem. When we solve a hard problem here, that knowledge should flow back to upstream projects and other distributions.

I’ll be at FOSDEM 2026. FOSDEM embodies what I love about open source: a non-commercial space where communities meet to share knowledge freely. If you’re there, come say hi.