Today, the OpenStack community released OpenStack 2026.2 Hibiscus, our 34th release.
For users and operators, a new release is an opportunity to explore new features and improvements. For the contributor community, it is a chance to look back at six months of collaboration across project teams, organizations, Special Interest Groups, Pop-up teams, Working Groups, time zones, and thousands of individual contributions.
One of the privileges of serving as OpenStack Technical Committee chair is getting to see just how much work happens across this community that never appears in a release highlights page.
Here is the number that stays with me: Around 600 contributors worked on Hibiscus, up 21% from Gazpacho, and they landed roughly 11,500 changes, up 28% over the previous cycle. That is meaningful growth this far into a project’s life, and it comes from people choosing to invest their time here rather than somewhere else.
There is the code, of course. But there are also the reviews, testing, documentation, release management, security coordination, cross-project discussions, design conversations, mentoring, bug fixes, and sometimes difficult technical decisions that turn thousands of individual contributions into an OpenStack release.
Hibiscus is the result of all of it.
The Problems Change. The Way We Solve Them Doesn’t.
OpenStack has been building cloud infrastructure in the open for 16 years. The infrastructure problems we are solving today are very different from those the community was thinking about in 2010. If there is one throughline in Hibiscus, it is that the community evolved the code and our methods at the same time, without altering the principles with which we work.
AI workloads are putting new demands on compute infrastructure. GPUs and other accelerators are changing how operators think about hardware resources. Confidential computing is creating new approaches to protecting sensitive workloads. Operators continue to push OpenStack to run at greater scale while becoming easier and cheaper to operate.
Our headline work thus clusters around trusted infrastructure for the AI era.
But what I find more interesting is how little the way we respond has changed.
An operator encounters a problem. A contributor proposes an idea. Other contributors challenge it, improve it, test it, and consider how it affects our projects and users. Sometimes we agree quickly. Often we don’t. Eventually, the result becomes part of an upstream project that everyone can use and continue improving.
That process can be messy. It is also one of OpenStack’s greatest strengths.
What is harder to put in a feature list is the shift in how we work. Our security effort this year strengthened the process behind the code as much as the code itself: dozens of advisories coordinated by the Vulnerability Management Team and the researchers who report issues responsibly, so operators are protected before anything becomes public. That is not a feature. It is a discipline, and it is one of the reasons OpenStack gets trusted with workloads that matter.
The newer conversation, and the one I am watching most closely, is how AI-assisted development fits into a project built on human review and consensus. I think that is exactly the right question to be asking now. The answer has to keep human creativity and accountability at the center; a suggestion from an AI model is the start of a review, not a substitute for one. We are working through it the way OpenStack works through every hard change, in the open and in the review queue, and I would rather we take the time to get it right than move fast and quietly hand our judgment away.
Built by Operators, Developers, and Users
OpenStack has always benefited from having the people who operate the software involved in building it.
That relationship matters.
When you’re operating infrastructure at significant scale, theoretical problems become very real ones. Scheduling decisions matter. Upgrade paths matter. Failure modes matter. APIs that seemed reasonable on paper get tested by production environments that nobody could completely anticipate.
Open source gives us a way to bring that experience back upstream.
The same is true as OpenStack encounters new hardware and new workloads. Hardware vendors, cloud providers, telecommunications companies, researchers, enterprises, and individual developers all bring different requirements to the community.
The goal isn’t for every contributor to have the same priorities. They won’t.
The value comes from having a place where those priorities can meet.
The Work You Don’t Always See
Some of the most important work in Hibiscus will never be the headline of a release announcement.
Neutron cut the memory footprint of HA router monitoring by more than fifteen times, and every operator running at scale will feel it. The same goes for the review that caught a bug before you hit it, the flaky test someone finally ran to ground, and the upgrade path a maintainer smoothed so yours would be easier. A community is easy to measure by commits. What is hard to measure is everything that makes those commits reliable and safe to run in production.
A release like Hibiscus gives us an opportunity to recognize that work.
OpenStack Is Still Evolving
There is a tendency to talk about long-running open source projects primarily in terms of longevity. I think evolution is the more interesting measure.
Our evolution now spans confidential computing, heterogeneous accelerators, AI infrastructure, bare metal, hardware architectures, security, and infrastructure efficiency. OpenStack is increasingly deployed alongside Kubernetes and other open source technologies. Contributors regularly work across the boundaries between projects and communities.
That evolution is possible because OpenStack isn’t defined by a single company’s product roadmap.
That means OpenStack can continue changing as the infrastructure industry changes around it.
And Then We Start Again
One of my favorite things about our six-month release cycle is that there isn’t really a finish line.
Hibiscus is out today, but work on Indri, a SLURP release, is already underway.
There are specifications being discussed, patches being reviewed, bugs being fixed. New contributors are learning how our projects work, and experienced contributors are helping them along. Some ideas will make the next release. Others will take longer. Some will change significantly as the community works through them.
That is open source development.
To everyone who wrote code, reviewed a patch, tested a feature, reported a bug, documented an API, investigated a vulnerability, participated in a design discussion, helped another contributor, or otherwise moved OpenStack forward during this cycle: thank you.
So today is a good day to explore what is new in Hibiscus, and a better day to help shape what comes next. Read the release notes and highlights, and join the community leads on OpenInfra Live on October 1 at 14:00 UTC, where the people who built this release will walk through it. And if you run OpenStack but have never sent a patch upstream, Indri is the cycle to start. The roadmap comes from whoever shows up and does the work, and there is room for you.
