This is a part of the Fedora Linux 44 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Michel Lind (salimma)

  • FAS ID: salimma
  • Matrix Rooms: #Fedora Devel, #Fedora EPEL, #Fedora ELN, #Fedora Golang, #Fedora Python, #Fedora Rust, #Fedora Security Team, #Fedora Social, #CentOS Devel, #CentOS Hyperscale, #CentOS Promo, #CentOS Proposed Updates

Questions

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

I have been active in the Fedora community since almost the very beginning (see also the next question), and an elected member of FESCo since the F40 election cycle. Outside of committee work, I am an experienced packager for multiple programming language ecosystems and maintain tooling intended to improve packaging workflows.

The project is facing some interesting decisions at the moment, in terms of what we produce (which packages, in what formats, for which architectures), how we produce them (what build systems, how we do quality assurance, especially in the face of an avalanche of CVEs), and who our contributors, users, and downstreams are. It needs both experienced hands who knows how things are done and why, as well as familiarity with current industry practices.

I believe I bring both of these to the table. At my day job, I focus on upstream distribution work and integrating improvements into our production fleet, which informs the perspective I bring to my FESCo work. If reelected, I hope to continue contributing that perspective – and I hope I have demonstrated my ability to separate what is best for the project from what is best for my employer.

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

Apart from my FESCo membership, I am an active packager and a member of various packaging SIGs (Rust, Python, Golang). My day job revolves around a large CentOS Stream deployment, so I was a member of the Fedora EPEL Steering Committee, am an active member of the CentOS Hyperscale SIG, and co-founded the Proposed Updates SIG that is forked off to focus on producing timely updates for those who deploy CentOS Stream in production.

I maintain sandogasa, a set of tools and library crates to assist with Fedora and CentOS packaging workflows. They solve some unique needs (e.g. bootstrapping EPEL packages, both those needed at work and also those needed to run Fedora’s mailing list infrastructure), and sometimes provide up to date alternatives to previously-written utilities (e.g. sandogasa-hattrack can surface someone’s Fedora Discussions activity – a platform that was not around when fedora-active-user was written). As these tools mature I hope to see them adopted more as part of project workflows.

I have landed multiple change proposals in the past – most notably around Btrfs and systemd-oomd. Most recently, for the F43 cycle Neal Gompa and I worked on Wayland-only GNOME and for F44 cycle, I landed:

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

In my experience, disagreements are sometimes inevitable. While it is better to have consensus, sometimes that’s not possible, and it is important to recognize those situations and agree to disagree.

It is sometimes easier to understand each other’s positions in less formal situations – I am reminded of our Friends foundational value here. This is where having personal interactions with other community members really helps – we can disagree without taking things personally, or clear things up in a side channel because sometimes some reasons cannot be divulged in public.

In the end, we are all fallible humans, and we all have our own interests and preferences, both personal and work-driven. Being able to understand those we disagree with both make it easier to keep things civil and to find compromises.

Where do you think the Fedora Project should position itself concerning the use of ‘AI’ in software development?

I have a nuanced take on this, so this will likely rub some people the wrong way. I have strong ethical reservations about using (generative) AI, and legal reservations as well, but IANAL so I will not really cover the legal aspects here; I defer to all the legal counsels who have vetted the project’s AI policy and my employer’s legal counsel who must have OKed our AI usage…

There’s the issue of training data provenance – there’s the issue of regulations not catching up yet to either address copyright infringement issues, nor protecting workers from job displacement, nor regulating energy and water usage. I could go on. If you’re “lucky” enough to work on improving the AI itself, while I can’t speak to how that is done at my day job, suffice to say there are horror stories out there, at that company, affiliated companies, and competitors. There are concerns that inappropriate use of AI leads to cognitive decline.

Using AI in software development is, as a large project shipping mission critical software, sadly seems to be verging on inevitable these days – but I’d rather we use it defensively, like how curl uses AI scanners. Using it to help triage issues, like COPR’s Log Detective, is also promising.

We certainly could use some more resources when it comes to fixing CVEs and when it comes to tooling – there are simply not enough volunteers, sadly. Though – this comes up in Debian’s debate about AI usage too – we should be careful not to close off opportunities for new contributors because it’s easier to fix something with LLM assistance than to onboard someone to do it.

I will own up to writing sandogasa mostly with AI assistance. As part of that, I wrote up my personal LLM policy for those curious. As the org name (slopfest) suggests, my colleague and I who have repos there feel conflicted about the use of LLMs; we try to limit it to this GitHub organization, and to tasks that are repetitive and error-prone anyway. Just as artifacts produced by GNU autotools do not need to be GPL licensed, hopefully you can use these tools free of any LLM taint.

Finally, the elephant in the room – the Fedora AI Developer Desktop Initiative, that intends to make it easier to install hardware drivers and development libraries needed to leverage GPUs, including, controversially, the proprietary NVIDIA stack. NVIDIA is worth over USD 5tn. IBM is valued at just over USD 200bn. I think NVIDIA can hire enough people with packaging experience to solve the problems they themselves cause by not open sourcing key headers people want to compile against – and I know they do employ people who know packaging. I think one role distributions like Fedora can do, and large NVIDIA customers especially among the hyperscalers, is to have a common position to negotiate with NVIDIA. If that happens then we might have enough traction to end up with positive outcomes.

Without pushing back against the tide of AI boosterism, I fear that the reputational damage because this is seen to be a top-down initiative would outweigh any benefit – and I still think this could have been a remix and Council was involved unnecessarily early. We used to be perceived as caring strongly about licensing (it took us a long time to ship a subset of RPM Fusion, and Tom Callaway’s work is immortalized in the name of Fedora’s previous licensing system), and I really prefer that we’re not seen to be AI boosters, because a) it does not seem like the right thing to do IMHO and b) the crowd we will attract, and likewise, the existing contributors and userbase we will alienate.

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

I work for Meta – which runs CentOS Stream on millions of bare metal servers and in containers. I hope I have demonstrated over the past two years in FESCo, and over a longer period in my other Fedora and CentOS engagements, that I try to put the community first and not let my employer’s interest override my responsibility to the community.

I recently relocated to Ireland with my wife and kid – it’s a lovely country, and a fascinating bridge between the US we left and Europe, given the presence of US multinationals here and the history of Irish emigration. We are looking forward to attending more European open source conferences in the future once we are more settled in.