We’re putting together an agenda for this coming week’s meeting, and I’d love for your input. Some topics I think would be useful so far:
More Q&A time for what Hummingbird is.
Updates on the bootable image artifact and general artifact updates
A discussion on agentic factories like this
???
Edit: Topics that have come in so far:
1. Fedora Podcast guests, 2. demoing how Bluefin uses the Hive factory (similar idea) downstream, 3. end user blog posts celebration (already got some!), 4. Hive demo from the Kubestellar team, 5. moving the hardened images from Project Hummingbird/Red Hat Hardened Images into the Fedora Hummingbird Linux space or what else we could do, 6. the concept of factories in general and managed hosting of the factory, 7. goals for images and CVE scanners.
Keep the ideas coming!
Consider this thread a chance to add topics to the agenda. What would you like to talk about with regard to Hummingbird? (If you suggest a topic and can’t be there to talk about it, please add enough information so I know what to ask for you!)
Bummer is that we have SO much to cover though, it’s not just humminbird it’s everything, bootc, AI, etc. also need to bring in Andy Anderson from Kubestellar. Sorry this started as “I should do a quick catchup” But also it’s an OS factory so it kind of has to be that way …
And also next week is Universal Blue’s fifth birthday and it’s party time in bootc land. The logs are full, we need a data dump - happy to do it in another meeting/avenue, etc. too. It’s a lot sorry!
EDIT: Can someone snag the AI people? Mo/Gordon/adjacent? The AI automation story is so comical someone should at least write it down lol.
I’d love to present Hive (hive.kubestellar.io) to the group in attendance. Hive is a multi-agent orchestration opensource project that supports hosted (claude, copilot, etc) and local agentic frameworks (goose, litellm, vllm, llm-d) to maintain open and closed source repositories in a SaaS model. Request a hive, assign some repos, add your api-key or login to your favorite agentic framework and your off and running.
I think this would be interesting. I am starting to think that Hummingbird, as a community, could serve as a place/platform for people who are interested in Agentic development to discuss latest/greatest tools, best practices, concepts, etc. So, i find this interesting.
Thanks everyone for the great vibes this morning! As luck would have it I had an interview about the effects of AI on OSS projects. As you can see the energy from this morning’s call carried over. This is 5 years of Universal Blue + 25 years of OSS experience in one go.
Many of the things I say in this video will probably be controversial to some folks, but projects are going to have to deal with it:
Thanks for sharing Jorge. I agree with all of your points. Great interview, Jorge. I wanted to share a quick summary for those that may not have had a chance to digest it:
Jorge describes AI’s impact on open source as a “yes” to both good AND bad. The speed of change is unprecedented — faster than cloud, faster than distributed version control. Key themes:St
Maintainer overload: Projects are getting flooded with automated PRs and low-effort “slop” from contributors who lack project context. Expert human oversight remains irreplaceable for architectural decisions.
Documentation becomes critical infrastructure: For AI agents to be useful rather than destructive, projects need robust documentation so both humans AND bots can understand project boundaries.
AI for the boring stuff: AI is best utilized for repetitive, non-core tasks (tests, docs, routine chores) to free up developers for creative and strategic work.
Transparency over stigma: Contributors shouldn’t be forced to hide that they use AI. The measure should be the outcome, not the tool.
Sustainability and local models: Frontier model costs are real, but open-source local models are rapidly improving.
Governance stays human: Vision, community building, empathy, and governance will always require human leadership.
What I’d add from daily practice:
I agree with essentially everything Jorge says here, and I want to extend a few points:
Documentation isn’t just for humans anymore — it’s constitutional. Jorge’s point about investing in docs is exactly right, and I’d push it further than READMEs and architectural documents. I’ve gravitated away from writing specs for every individual feature — that’s trying to make a non-deterministic tool act deterministic. What works is constitutional documentation: guidance on logging standards, container image selection, security posture, privacy expectations, performance targets, coding standards. First principles for your project. When an AI agent (or a new human contributor) has a clear constitution to work from, it can solve entire classes of problems correctly rather than needing hand-holding on each tactical one. This is the insight — with AI, you focus on encoding your project’s first principles, not micro-managing every feature. The Hummingbird factory work is proving this out daily.
Defenders MUST use AI to survive. Jorge mentions security risks, and he’s right. AI-assisted exploit chaining has fundamentally tipped the offense/defense balance. I experienced this firsthand two days ago — my sites got hit by a multi-stage attack where an UpdraftPlus CVE was chained with WordPress core RCE bugs in a patient, automated compromise that would have taken coordinated teams of very smart people before AI. The old sysadmin confidence that careful discipline was enough? That’s gone. But here’s the thing: AI helped me remediate and harden both sites in a few hours of multitasking, work that would have taken me weeks the old way. The attackers are using AI. The defenders don’t have a choice — you either use AI on defense or you lose. This isn’t theoretical for me. I built mcp-trentina specifically because agentic workflows need quarantine pipelines and prompt injection defense. Open source projects need to start thinking about this seriously.
The “factory” pattern is the answer to the slop problem. Rather than accepting random AI-generated PRs, projects can define their own agentic workflows that produce contributions within controlled guardrails. This is fundamentally what Hummingbird’s factory concept does for images — and it’s a model that extends to other types of contributions. Tools like Gatehouse make this concrete: it runs 8 concurrent AI review agents (bugs, security, performance, test coverage, documentation, constitution compliance, consistency, and general review) against every PR — locally, with findings below 80% confidence filtered out and advisory by default so a non-deterministic tool never blocks a merge. Critically, it auto-discovers your project’s constitution and checks code against your rules, not generic ones. And Fullsend takes this further by adding a retrospective agent to the pipeline — after every merge, it analyzes the full workflow and files proposals for process improvements. The factory doesn’t just produce; it learns. Instead of gatekeeping AI out, you channel it through your own infrastructure. The contributions get better, the maintainer load goes down, and the system improves over time.
This is why Hummingbird needs to be the venue for this conversation. Jorge is right that “projects are going to have to deal with it.” The Hummingbird community is already at the intersection of open source, automated image factories, OCI workflows, and agentic development. We’re living this every day. I’d love to see us make agentic development practices, security patterns, and tooling a regular part of our community discussions.
Agentic development makes sharing good ideas easier than ever — and that raises the bar dramatically. This is the part that’s both amazing and uncomfortable. It has never been more fun to discover a great idea in someone else’s project and incorporate it into your own stack. I do this constantly now — I rarely adopt an existing tool wholesale. Instead, I steal the good ideas and code my own version that fits my exact workflow, my preferred language, my specific stack, my specific constitutions for logging, security, and so on. A piece of software has to be very good and very unique for me to adopt it as-is. If it doesn’t fit like a glove, I just build my own. The market dynamics of open source are going to demand this. When it’s trivially easy to reimplement a good idea tuned to your needs, projects can’t coast on “good enough.” The bar for adoption goes way up. That’s a challenge for maintainers, but it’s also an incredibly powerful force for innovation — the best ideas propagate faster than ever, even if the code doesn’t.
Happy 5th birthday to Universal Blue, and thanks to Jorge for saying the things out loud that a lot of us are thinking.
[ all the stuff people need, reproducibility, etc]
And then just to avoid confusion something like
Provide API end points for automation by other agents and systems.
This way we don’t conflate hive and the factory. There are a bunch of these things so a default core factory should be extensible.
I’ll go into more detail on the “Seti at home” thing Andy touched on. A friend of mine goes: “Why can’t I just spend 50 bucks on openrouter and help OSS”. It’s clear that people want to help and have access to these things. We need to give them something to do, if they keep getting yelled at they’ll just go work on something else.
The agent is then given structured informaiton on how to help given the person involved. If it’s a maintainer they’ll get the proper issues, if it’s a random person then they’ll get the “AI version of good-first-issues”. All of this is enforced with github labelling so that the design has to go through a maintainer process. Something like:
User-> “We should add Whisp to bluefin it’s so good”, fills out structured form
Maintainers → Discuss, if consensus reached, adds clanker-queue or whatever to the issues
Person processing the queue → sends PR, workflow enforces attachment of local test result for quality gates.
Maintainer → Human gate, 2 acks needed. Same as before.
Lands on testing branch → Hits opt-in users
Factory to user → "This feature is now in testing, here’s some instructions on how to rebase to it. And here’s a bunch of test results that I’ve been churning on overnight.
Daily stable process fires off, if all e2e passes, promote to stable.
EDIT: The process is the same wether you use an agent or not. One tenet I think we should have is “agents accelerate, the factory MUST be driveable with a manual transmission.”
Each step is a factory integration, images being built etc. The thing should spit out every version of every git branch as a bootc image. I know ya’ll are still talking “rolling vs. stable” but IMO floor it. Build the entire git tree, publish a ton of tags. It is a failure that people think bootc switch’s primary purpose is to switch their desktops. So I guess that tenet is “The factory ships the leading bootc reference architecture”.
EDIT: Also I am finding the need to say “There are human gates here and here.” so it’s clear to people where the control points are. We need to reinforce this. It’s only a matter of time until one of us makes a mistake. This is why I like the testing-first approach and why I strongly believe that orgs should be doubling down on QA.
@fatherlinux , would you want to be my guest for a Fedora Podcast episode about Hummingbird? Here is the draft episode guide: [FPP000: What is Hummingbird](Making sure you're not a bot!)
Hey folks! I am finally back at my desk, and I have the recording from the meeting downloaded. We held the meeting with 19 people (yay!), and the demos were excellent. Lots of great conversations in the chat and in the open floor at the end of the meeting, too.
Here’s a summary generated with Gemini of the meeting, lightly edited by me:
The video captures a Fedora Hummingbird community meeting hosted by @nimbinatus on July 23, 2026. The meeting highlights the growing intersection of Linux distributions and autonomous AI technologies through the following discussions:
Fedora Podcast Connection: Laura seeks a volunteer from the Hummingbird community to appear on the Fedora Podcast with @itguyeric to discuss the initiative. Members @fatherlinux and @castrojo express interest in participating.
Project Bluefin and the Hive Factory:@castrojo presents an overview of Project Bluefin, highlighting its transition toward an autonomous agentic OS factory using Hive, an AI research project from Kubestellar. Built entirely from scratch on a self-bootstrapping Kubernetes cluster utilizing Fedora CoreOS, the factory autonomously builds, tests, and publishes a variety of images (CentOS, Fedora, Aurora, etc.) and integrates automated end-to-end desktop testing. @castrojo challenges the broader community to elevate this prototype into a professional-grade showcase.
Deep Dive into the Hive Architecture:@andan02 demonstrates Hive, explaining its design for placing GitHub repositories on autopilot via agentic workflows called missions. The platform blends deterministic code with non-deterministic local models (such as Gemini and Light LLM) and manages automation via the AI Codebase Maturity Model (ACMM), which spans six levels from inception to full autonomy. Hive utilizes a man-in-the-middle proxy to prevent agents from running amok and explicitly clears their context upon each trigger, relying instead on flat-file beads to maintain localized records.
Fedora Hummingbird Linux and Hardened Images:@fatherlinux summarizes the evolution of Fedora Hummingbird Linux, a container host launched in May that utilizes repackaged Fedora content. He proposes a model where the factory is hosted by Red Hat in a secure, SLSA-compliant environment but entirely controlled by Fedora, positioning Fedora Hummingbird Linux as the upstream for Red Hat Hardened Images.
Community Operations and Logistics:@nimbinatus outlines plans to keep technical communications organized under a specific Fedora discussion thread rather than a Matrix channel due to superior moderation capabilities and searchable threads. Prompted by interest from the group, she plans to establish more frequent working sessions or office hours while keeping the standard monthly meeting cadence. Finally, she proposes moving future monthly meetings from Jitsi to Google Meet for enhanced cloud recording and moderation tools.
As soon as I get the recording somewhere I can link to, I’ll post it!
Sorry Laura long one this week! Most things are working smoothly and images are coming out \o/.
@andan02 and I spiked on some ideas to help people who wanted to help out. The spam isn’t going to go away so the question became: “Can we make that useful?”
Right now people go and they just send an agent to a repo and spam it. Maintainers get mad, banning, Eternal September, etc. What if the factory instead encouraged contributions in an organized, systemic manner? We need a good-first-issue for agents, with all the things that suck about agentic development hidden from the contributors. This will go into hive implementation details but for the purpose of the model just think “what if the factory had AI integration points built in for agents to do things?”
Draft: https://projectbluefin.github.io/review/queue.md - this is a readonly snapshot of some issues that need help - we publish a .json version for the clankers. A maintainer can point an agent to that list and get some work done. “I have 2h to work on this today, find something”.
But most of the problems with the drivebys are the LLMs not having context and operator error. If you had the right setup and a group of people who told you how to do it an LLM could easily do all of this - this is the most documented software on the planet, IMO this is a context problem. First hive lets us cheat:
Draft ux so far: Person who wants to contribute signs up - we’re working on the UX on this page so bear with us. For our contributors they’ll clone the repo and do just donate-clanker and sign up. These are NOT anonymous contributions. The person applies for the hive, and it’s tied to their git account (github in this case via the gh cli) - we don’t want to get into the identitity business! Normal OSS project trust stuff applies.
Then when the right label is applied (a choice made by a human!) the person is assigned an issue. The clanker alias in this case is a VM appliance with the hive stuff, goose, and project context. The agentic skills from the repo are put in the right spot for goose to pick them up. There’s passthrough so whatever model/tool you use is fine. Then the hive prompt with the actual task gets sent to the agent:
Then we do our best to enforce community enhanced skills in the actual repository itself. The documentation becomes the prompt, and each loop strives to make the code the model. Then a nice trick I learned from the aaif spec: you can index your skills with an index.json and a schema to save some token burn. We keep the markdown tables around for new contributors because they can be useful. This forces you to care about your docs and I hate it. LESSON: “If you don’t invest in your docs you will get burned in QA and it will be expensive and you will pay for it at scale.”
Hive also does things like centralized context7 lookups for fresh docs, which we need to keep track of fast moving linux/bootc/systemd, etc. Our entire project knowledge graph is also made available. We don’t ship the universe, we’re trying to optimize for context lookup for these parts. This makes a huge difference at a time when local models are getting better and better. But we need more data:
Kyle is not the first (hanthor and wiulinu were the first two!) but the first I asked to baseline. Here is a pull request for a feature we wanted, that we put in the queue. Kyle is an expert sysadmin so I asked him to just go through the workflow once. These things are slow enough where you can ctrl-c long before it embarrasses you.
Kyle’s local model worked on this, sent it - we did the review and merged it:
In almost exactly 100 days we went from Opus to a local model being able to do this. With each loop we find something that isn’t deterministic and then we fix it. (I’ll get more info on the model Kyle used, etc.)
On the maintainer side Andy and I have been talking about hive exposing a maintainer queue separately - a core maintainer would be given more gnarly bugs, etc. This workflow is different because the first one is designed to give competent people mostly-automated work. This one is maintainer focused so it will need more care. The review setup is designed to have a little side container with your opinion in it, I have mine open the issue it’s working on in a new tab, a new tab to the upstream project docs so I have context - and then I have a local skill with all the instructions to my k8s lab. The context forces the agents to test on the lab and pass tests (eventually), and so on.
Last night I sat there and watched tmux for about 3 hours going through all of the stuff I didn’t want to do. We still have things to fix but each loop gets faster. Once the model nerds start distilling and optimizing these things I bet we can really do some cool stuff!
EDIT: We’re going in the opposite way Steve is going, this article is worth your time!
Happy Friday! Clearing up some backlog - this is with 2 human gates (one to submit to the clanker-queue and one to review with a clanker if you so desire)
