Make OpenStack Delightful
OpenStack is dead. Yep. Just like BSD, OpenStack has matured to the point where people claim it’s dead. The social media echo chambers amplify that. To quote someone:
OpenStack is not dying, but merely finding its own groove and entering a maturation phase. Any subscriber to openstack-dev can see how the more vocal members of the community try to get out in front of problems, perceived or not. There is one problem that sorely needs to be addressed as OpenStack cools and matures: making the experience Delightful. Yes, capital D. And right now it is anything but.
What is Delightful?
Using Chef (the company, project and ecosystem) as an example, delightful is pretty much subjective. It’s a “you know it when you see it” thing and not a tangible item one can draw on a whiteboard. But what does it mean to make something Delightful? I’ll give you a hint, the code isn’t the first thing on the list, nor the third or fourth. I’ve seen suggestions to a One True Method, and other exclusionary verbiage meant to separate the ‘us’ and the ‘them’. More time is spent down in the weeds figuring out what the meaning of is, is, that there is less time spent on making the OpenStack experience Delightful. Damn it. There I go with that word again.
Does OpenStack need a One True Method? Yes and no. In some ways, it does. OpenStack needs more of a One True Path and less of a prescribed One True Method. Having a clear path forward is part of making things Delightful, but prescribing a method with a hefty Thou Shalt Use is not very Delightful, and can be exclusionary at best. This is particularly so when it comes to introducing third-party dependencies, as deployers are effectively shackled to that choice, until something else comes along to replace it.
But you’re not saying what Delightful means
To me, delightful (little d this time) in the context of OpenStack means that I can go read some documentation and come out with a reasonable production-like deployment, the underlying broad strokes and architectural decisions being left to me. The idea is that I shouldn’t have to self-flagellate to get to production. Though we now have a whole bevy of tooling to choose from, the path to production is still painful no matter which method. An operator still has to duct tape shit together to cover the gaps upstream missed or, more bluntly, couldn’t feasibly cover. If the operator can’t forge a path forward, they will find something that does work, and build upon that. With or without OpenStack. Unfortunately, that results in wasted effort, time and money. It also slows the path to production, due to time wasted evaluating the health and viability of a given method.
Off with their heads!
It’s already happened with Salt, and now Fuel. In those cases, it’s very clear cut on where things have ended. In the case of Fuel, the vendor divested itself of the project and pivoted, leaving no successor. Salt got the boot after the PTL elections resulted in no successor emerging. A flippant comment on the mailing list proclaimed the Chef method as having “effectively died”, increasing the growing perception that Chef is next on the chopping block. All the while I’ve been working in my spare time to improve the experience and make it suck less. This, on top of my day job running a highly complex production OpenStack deployment and balancing some semblance of a budding family. To say I have no social life is an understatement. To read that the project I am working on has “effectively died”, when I’m still pushing patches, is disheartening and tells me where the developer community wants to head. Clearly Chef should have been swept out the door. Just look at them with their three cores, questionable CI and no major corporate backing. Laughable. Obviously not worthy of being an OpenStack Project. There’s meat on the menu tonight, boys.
The Big Tent, the bazaar, the insert label of the week
In the before times, we had StackForge as an incubator for projects that aimed to become an “OpenStack Project”. It was exclusionary, because it clearly defined an ‘us’ and a ‘them’. If you’re not an official project, you’re a ‘them’, and to StackForge you go to bake. Then came the idea of the Big Tent, and suddenly a land rush to shore up teams and make them presentable for judging for inclusion. Everyone could be an “OpenStack Project” so long as you checked these boxes. Things started getting inclusive, a bit too inclusive for some. Suddenly, we were all one big happy family. Unicorns, rainbows, namespace churn. Fun times. Disgusting.
But all good things must come to an end.
Over time, as so happens, projects started waning in contributor count, despite maintaining a non-zero userbase. Despite these downstream users, the upstream projects had started falling on hard times, with nobody bankrolling the development because it’s hard to monetize, eventually reprioritizing the engineers already in the weeds. This brain drain decimated fledgling and established teams alike, resulting in questionable futures for many up and coming projects, and establishing a nice foothold of bitrot closer to home. The problem wasn’t that nobody was using the output, but that there was nobody around to do what needed to be done to either sunset the project gracefully, or continue its life support.
Suddenly, we’re talking ‘us’ versus ‘them’ again. The Big Tent notion is dead, gone and scrapped. Whispers of a cheap “flea circus” connotation. Now we need to start thinking in terms of inclusivity again. Thus the pendulum swings. How to exclude while still including? How to spin it to be a positive without saying you’re enacting what amounts to layoffs? “Friends of OpenStack” and “Core” versus “Non-Core/Peripheral/OpenStack-Hosted” have been kicked around, none of which sound particularly inclusive. It still clearly sends a message that if you’re not an ‘us’, you’re a ‘them’. I could be wrong, but I don’t think that’s the intended message. Marketing loves We Are OpenStack, and I don’t see much in the way of sticking to that.
Reframing the ‘them’ without making it seem like a ‘them’ would be ideal to everyone, especially the ‘them’. The ‘us’ groups would get their delineation back, and they would be able to point and say “there’s the ‘them’, outside the boundaries of ‘us’” The ‘them’ has to be exclusive yet inclusive all at the same time. That looks an awful lot like a marketplace with a different name, but we already use marketplace. It almost looks… bazaar-like, even. Anyone can bring their wares to the bazaar and sell them, but the Bedesten is reserved for the essential vendors, the ones that keep the customers coming back.
I realize this is steeped in metaphor, but bear with me. Through using the tooling in a manner that can allow anyone to offer their wares, that is a step towards delightful. Of course, this means rethinking workflows and getting a better understanding of what the user sees, not necessarily what makes the most sense for development. Most users that find me ask if GitHub is where to go to post issues. I have to correct them and lead them down the path of developing within the OpenStack ecosystem, which results in them being scared off.
Though my experience can be said to be influenced by my own biases to the team to which I contribute time, I’m going to try and remove the self from this one. This is bigger than me and my project. We’re in this together, until we’re not.
Make OpenStack Delightful, not Byzantine. <3