Is the #OpenStack Leopard Changing its Spots?

A short while back I tweeted the following:

This was a result of me reading the minutes of the OpenStack Technical committee from November 3rd, 2015 (full log is here)

What pleasantly surprises me is that this might finally becoming a viable option.

Leopard spots

Let me first go into the background of my trail of thoughts.
I really enjoy working with OpenStack, but I also really hate working with OpenStack. A good old love/hate relationship.

There are amazing things about this community, the way we work, and the software we produce (just to name two).

On the other hand there are really bad things about this community, namely – the way we work, and the software we produce.

One might say that is an oxymoron (I am not calling anyone stupid though). But yes it is true. The OpenStack community produces amazing things – or at least that is until someone (let’s call them an Operator) tries to actually use this in a production environment, and then they find out until it is completely and totally, not ready, in any way for production use.

So this Operator tries to raise his concerns, why this is not useable, these are valid concerns and maybe these should be fixed. But unfortunately they have no way of actually getting this done, because – the feedback loop is completely broken. Operators have no way of getting that information back in. The community has no interest in opening up a new conduit into the developer community – because they are fixated on working in a specific way.

I must stress and honestly say, that this was the case up until approximately a year ago. Since then the OpenStack community has embarked on a number of initiatives that are making this a much easier process, and we are actually seeing some change (see the title of this post).

For me the question actually is – what sparked this change? Up until now I was under the impression that the OpenStack community (and I mean the developers) was of the opinion that they are driving the requirements and development goals, but it seems as of late – this could be shifting.

To me this is going to have a significant effect of what OpenStack is, and how it moves forward.

For better and for worse. Time will tell.

What do you all think? Please feel free to leave your thoughts and comments below.


Pillar #3 - Management

This is third post in the The Three Pillars of DevOps series

Part 1 – The Three Pillars of DevOps
Part 2 – Pillar #1 - Developers
Part 3 – Pillar #2 - Operations Engineers
Part 4 – Pillar #3 - Management
Part 5 – Bringing it all together

In this post we will dive in to the third pillar – Management.


Being part of the Pillar

  1. DevOps is a cultural change

    Most people do not like change. Personally, I do not have an easy time adapting to change, it makes me nervous, uncertain, unsure. Different people take to change in different ways. Adoption of a DevOps way of working is not a small thing.

    Boundaries are no longer clear.
    Who is in charge of what?
    Why do we have to take care of this?
    I have no idea of what this means.

    With any big change you should understand what this will do to your organization. See where you will have problems. Where people will need help. Expect that things are going to change. Over time.

  2. Support both of the other pillars on the journey

    In continuation on the previous point. Help your developers with education. They are no longer responsible for a small part, but rather the big picture.

    Help your Operations Engineers with the world of code, again training, courses, books, seminars, pair programming there are a more than a number of ways.

    Bring in someone to help and coach your teams throughout the journey, going from waterfall to Agile is a huge change, even more so such a culture change. Help them in the beginning, through the ups and downs, and how they can continuously improve themselves and the way they work.
  3. Have patience

    This is going to take time. Quite a lot of time. Give the teams the leeway to adapt and learn along the jurney. Let them learn from their mistakes, pave their own path. Your productivity will probably go down in the short term, which also mean that the bottom line might drop as well.

    Be prepared for this. Remember, if you are in it for the short term, the quick win, then this is the wrong reason. And it will most probably fail. Almost definitely. Your are here for the long term, even if it means losing in the short term.

Not being part of the Pillar (or being Samson)


  1. We should start doing DevOps! Now!

    I went to this interesting seminar where they showed how they are delivering code 10-20 times a day. I want us to start do the same. Next week. Let’s just make some quick changes, merge some teams, get the Devs working together with the Ops, and we should be able to deliver even more often with better quality.

  2. My employees can do double the work, in less time

    So now that we are ‘doing DevOps’ I don’t need so many people on my teams because they are doing the work on both sides of the fence. They can get their work done and also support the applications they are writing from start to finish with less people, and because they are more efficient probably in less time.

  3. There is only one way to get this done.

    Agile, Extreme Programming, Kanban. Rally. We need one tool to monitor and rule it all. One process that everyone has to follow. Everyone has to fit into the box we create. That is the only way we can maintain control.

    The groups have to adapt to the way I want it to work. My way or the highway.

Next up we will look at Part 5 of this series – Bringing it all together.