Hey, Let me please explain my view on the position that you and multiple others expressed (so don't take it personally) after drawing a long bold line separating it from the initial topic. If one wants to continue this particular discussion feel free to branch it out into a separate thread instead. ================================== The following is my point of view, yours would surely differ!!! I think the problem with a decline of maintainers is artificially created by ourselves. We are sitting behind the wall that we've built and continue making it higher and thicker. I believe we are wearing contributors out with the mentality of let's have everything done the same way so that others have a chance to take it over when (an example that I heard: you would be hit by the bus while crossing the street and there is nobody else in the project) the project is left unmaintained. We try to do everything possible to keep project or library alive beyond our capacities. Every time an OpenStack project/repo looses last maintainer we spend literally years discussing that and searching somebody who still has some capacity before reaching 200% load. Another aspect is the spaghetti ecosystem that we have built. I can now say I spend more time fighting the dependencies and jobs that get broken without me doing anything before they broke than working on the features. Just for the sake of example, I got report of a mistake in Keystone Open API schema. The fix was fast: 2 minutes of work. But I have figured out that API-ref build job got broken. Investigation led to to the sphinx openapi extension. A direct dependency of it have a transitive dependency controlled by our constraints and was upgraded a week ago. Since my direct dependency does not have a vibrant community and it takes time to get update I am completely blocked with releasing the fix. I gave up and started simply getting rid (hoping for it to be a temporary issue) of building openapi to html as such just to be able to unblock fixes. Another example: I missed to control the commit sha of the releases change when making 2024.1 unmaintained while one change to (yet again) fix jobs in the branch was in the gate (I missed that because of amount of broken things distracting me). So the branch went unmaintained without the fix. Ok. I just cherry-pick it to the unmaintained. Good luck - the fix does not work there, come on, it is just a branch rename. I spent 2 days with different attempts and gave up, this is just unmaintained branch after all. But now I see Brian is messing with it and also "wastes" his time multiple days in a row. And the more you try to fix the more broken it becomes (even more jobs get broken on a daily basis). I think he will also give up. What I am trying to say: - does it make sense how we have build our ecosystem: yes, it does - can it be done easier/better: almost certainly yes While, as said, there are reasons for it to be how it is, we must admit, that there is the other side of the coin that is a consequence of that approach: - OpenStack contribution is very complex - we wear contributors out with the mentality that everything is built similarly and so taking it over another abandoned thing (maybe for a reason) is relatively "easy" - this leads to more and more load and we spend our time in maintenance of everything around instead of a focus on a primary project - we loose concentration fixing multiple things in parallel - we cannot easily innovate (or even try to innovate) because of the mentioned rules and constraints. We even prevent using thing that would simplify the daily work with the rules and constraints of the ecosystem For me personally coding outside of OpenStack brings satisfaction, coding in OpenStack brings frustration every single day. Some know I burned myself down few years ago with that. Now I am again close to that. I thought multiple times already of just giving up on the OpenStack world and just move myself into a different area. I know personally maintainers who left OpenStack because of not seeing future in it and tired of artificial problems. Just to remind, mostly I do the work on a voluntary basis, I am not paid for working on OpenStack. I hope I was able to explain why I see the mentioned approach as dangerous. Another reminder: this is my personal opinion and is not representing the Keystone team Regards, Artem ---- typed from mobile, auto-correct typos assumed ---- On Sat, 8 Nov 2025, 02:21 Takashi Kajinami, <kajinamit@oss.nttdata.com> wrote:
On 11/8/25 4:36 AM, Artem Goncharov wrote:
At the same time, who knows - maybe part of the reason OpenStack
struggles to attract new contributors is that most available Python developers are already here, and bringing in the Rust community could add some fresh air to the ecosystem.
Maybe, I was also thinking about that, but didn't want to explicitly
mention it.
I have a different view about this point. Introducing a new language might be attractive to developers who are willing to learn new things and find python boring and legacy. However we should also be aware of potential increase of the complexity of the whole software stack and our tool chain. For example operators may need to learn how they debug software written in a new language. New developers joining the community may need to learn two sets of language and also different toolings (requirements management, the way to run tests, the way to run format checks, and so on). I have some concerns that these can increase user/developer effort and cause opposite effect.
I'm not saying that this is a hard blocker, but just want to reminds you of potential tradeoff we should consider. I hope that the plan to ease the additional complexity (maybe some documents for users and operators for initial learning) is also discussed as well as the software technology, for example.
Artem.