Who owns DevOps?

There is currently a tension in the DevOps world, between influential purists saying you cannot define, codify, or certify DevOps, and most of the world saying it is bloody well going to anyway if DevOps is to be useful in the mainstream.

While I was at the DevOps Enterprise Summit (DOES) conference in San Francisco last year (superb conference again) I wore a lapel badge indicating the DevOps Foundation certification, for which I am an instructor.

A number of the leading lights in DevOps - the “Illuminati”, the gurus, people I look up to - took exception to me wearing the badge. I'm proud this DevOps movement has such passion but I was quite surprised (and genuinely upset) by the hostility of the resulting conversation.

Here is some of the fallout:

Of course it isn't dying. New certifications are springing up: I count three competing programmes. Demand exceeds supply, and is growing exponentially. Job ads now ask for certification.

When the originators of DevOps - the Illuminati - created the initial ideas, they chose not to create any of

• Custodians
• Definition
• Manifesto
• Governing body
• Framework
• Body of knowledge
• Standard

They had the opportunity to manage DevOps at this time and chose not to. They threw Devops to the wind, put it into the public domain, set it free.

As a result DevOps belongs to the people. DevOps is what the community says it is.
If the community want certification then there will be certification - somebody will meet that need. If they want to define DevOps roles and job descriptions, someone will do it (I bet SFIA will).
If they want a DevOps maturity model or software compliance assessment, they can have one.
If ISO want to make a DevOps standard they can.
If the vendors say they have DevOps in a box then they have DevOps in a box no matter how much we laugh at that idea.
If, say, Axelos decides to produce the sixth ITIL book called Continuous Service(TM) codifying DevOps that would be interesting (although they say they won't).
Or if DASA (the DevOps and Agile Skills Association) or the DevOps Institute were to produce books to accompany their training.
Or Microsoft updated MOF.

I understand this core coterie of DevOps originators has the influence and even the trademarks to constrain such things, to dictate policy, to arbitrate on what is “correct DevOps”. That would be damaging. And it would be ironic: taking DevOps the way ITIL went. I don't see legal challenges happening, it would run counter to the ethos of DevOps.

The community respects the leading thinkers in the space for the astonishing contribution which is DevOps and the transformation it will make to many lives, and to our IT industry.
Unfortunately - because I genuinely regret this - as the DevOps community grows the founders' voices will become diluted. Their voices will become lost completely if the Illuminati retreat to their tower and wash their hands of sordid commercialism. The training providers will become the arbiters of DevOps content and the greater public will forget who the Illuminati even are. Very few people in the broader IT sector have heard of any DevOps thought leaders except Gene Kim and Jez Humble anyway. And why them? Because of their books.

The child has left home and you have to allow it to make its own mistakes and grow. It's not yours any more. You can't take it back home if you don't like the way it dresses or who it hangs out with. It has grown up and developed its own values.

DevOps has crossed the chasm. It is spreading into the mainstream. Growth is exploding. The attendees of DOES and of DevOpsDays no longer represent that community. They are now an inner circle, surrounded by a huge sea of mainstream IT practitioners who want some of that DevOps goodness, who will soon number in the millions. DevOps needs to evolve to meet the needs of a broader business community. Some of this will challenge the purity of the ideology, the sacredness of the vision.

Certification is a good example. If a certificate is what management want in order to send people on training, as evidence of outcome, then we should deliver the certification to meet that business need, in order to bring the message to the widest audience. I think anything that spreads the message of DevOps to more people, and seeds the principles in their minds to begin them on that journey, is something we should all support.

Codification is also pressing. Executives of legacy enterprise won't authorise investing effort in something that is undefined. The purists argue that DevOps isn't a thing, that we have definition and certification for Lean and Agile, that DevOps is constantly changing, that DevOps isn't a thing you can train in. This is head-in-the-sand thinking, ignoring the reality that the world sees it otherwise - being dogmatic about not turning it into dogma. DevOps has conferences, books, vendors, and a worldwide movement. People want it and they'll get it somewhere.

A great irony is that the new DevOps Handbook will codify DevOps, no matter how much the authors may protest that that is not what it is for. I see this as a good thing. The Illuminati need to be leading that movement to codify and certify DevOps, in order to take it in the right direction, to influence the content, to keep it healthy, to retain the vision. To make sure it doesn't suck.

But I’m pretty sure many of them won’t. The venom with which this is discussed shows that DevOps is a cult, not a business concept. Rational discussion of a changing world doesn't seem possible. Take a look at this recent response to the certification debate:

To which I replied “if the DevOps community can’t produce an agile evolving codification [and evolving certification of it] in response to customer demand then who are the real charlatans?”.

The DevOps Illuminati seem to think that the IT world has got it wrong, and will grow out of its need for codification and certification; that they can safely mock and scorn it. I think this is both patronising and wrong. They no longer own DevOps nor control it. They have to move with it or become irrelevant. The world will do codification and certification with or without them, in fact in certification it has already gone without them. And that saddens me greatly because without them will be the worst outcome.

(I'm also saddened that I may break some great working relationships through this. I have to call it as I see it and act in what I believe to be the best interests of DevOps).