Thanks for starting this thread, Clark. On 11/13/25 2:46 AM, Clark Boylan wrote:

Hello everyone,

There seems to be a recent sentiment within the community that the policies we've built to guide OpenStack development processes are unwieldy simply by existing. Any bureaucracy is bad by default and we should feel free to ignore it.

I'd like to reject that premise and redirect some of that energy towards (what I think) is a more positive approach to making change.

OpenStack has policies and procedures because it is a loose collective of many individuals and companies working towards some rough common goals. Namely the construction of a suite of software tools that interoperate to provide infrastructure as a service services. That is an incredibly broad set of goals and if we let every individual or subproject tackle this problem independently without any guidelines or constraints it would be pure chaos. Instead, over time we've built rules to help reduce the size of the problem space as we've run into fragmentation or problems that pose unnecessary overhead.

For example we currently expect software to largely be written in Python, Javascript, or Go. We support Linux as the runtime platform. But we go further and list specific Linux distros that we're actually going to bother testing on. We dropped PostgreSQL support because even that was too much overhead when compared to MariaDB and MySQL. Python test tooling is currently expected to use a standard compliant test runner.

Each of these examples are motivated by specific goals. Focusing on specific programming languages gives us consistency between projects so that if I need to fix a bug affecting me outside of my bubble I should have the tools to do so. Constraining programming languages also helps us build tooling around those languages to ensure that we manage packaging, security patching, translations, etc in an effective manner. Linux is a platform that largely provides all of the underlying dependencies that we need to build an infrastructure as a service system. It does so while also being compatible with our Open Source objectives. We could theoretically support OSX or Windows or FreeBSD but doing so would complicate our software and may require us to build additional tools ourselves.

Constraints are good. They limit the scope of the work we have to perform which reduces overhead and hopefully produces a better result. Constraints are also important for our users and operators. Backwards compatibility is a constraint. Being able to upgrade from release X to Y is a constraint. I think the fact that we're here more than a decade after the first release with a sizeable user base is a good indicator that at least some of these constraints have been effective towards our goals.

That said as time marches on our choices may no longer be in alignment with our goals and our goals may no longer be relevant. We can and should reevaluate our goals and from there reevaluate the decisions we've made. I think if we approach the process of making changes from this perspective and do so collaboratively as a community we can ensure the health of our software and community going forward. We should also probably try to be more explicit about these decisions and rely less on tribal knowledge or secret cabals. Informed developers should end up making better decisions whatever decisions are made.

Finally, it probably is worth noting that this sentiment may be driven as a reaction to a community that is very resistant to change. We should be better about reevaluating our goals and decisions around those goals. Maybe this should become a regular process (either as part of the release cycle, or PTG or just annually)? The world isn't static and while some choices we made a decade ago may stand the test of time many probably do not. Let's be more open to that.

I wonder if we can reserve some slots in TC PTG sessions where we can discuss such ideas ? Ideally we want it discussed within a project but given how small each project is nowadays probably extending the audience scope to TC may be helpful. IMO the key point is to start from a small number of members who are actually interested in that topic, and then construct a supporting group (for technical direction as well as actual work) before throwing the idea to the wider audience, and have some discussions with TC can be helpful for that. We may need to make sure that we set the regulation for productive discussions, though, like focusing on finding/joining anyone who may be interested in it, and also defining the rough initial potential path to clear some major concerns (not concerns themselves).

Clark