“If you don’t eat your meat, you can’t have any pudding. How can you have any pudding if you don’t eat your meat?” –Voltaire

Recently there was a post on O’Reilly Radar that cited an “identity crisis” in the world of DevOps. The post called out a number of issues: namely that there are cliques in DevOps, there is nothing new in DevOps, and there is no product messaging and positioning in the world of DevOps. It ended with the call for DevOps to define itself through a manifesto, similar to the Agile Manifesto or maybe even The Cathedral and the Bazaar.

There has long been a desire to “define DevOps”. Every few months a blog post pops up that says, “Define It,” and goes on to slam the “Knights Templar of DevOps” for holding on so close to the lack of a definition. What many of these “revolutionaries” are not aware of is that the need to define DevOps has already been addressed. The de facto definition exists on Wikipedia, and it was agreed upon by the “Knights” that Wikipedia would hold the definition. This allows the definition to evolve and change over time as the industry evolves and changes. (At this point I should mention that there are no “Knights Templar of DevOps.”)

This also prevents one person or company from being the “definer of DevOps.” It gives ownership of the definition to the community. Compare that with something like ITIL, where the definitions are owned by a company and haven’t evolved much since 2007.

The definition on Wikipedia also gives guide rails for individuals and companies to work inside. If a manifesto is needed, the manifesto is up to the individual organizations that wish to transform themselves. A one-size-fits-all manifesto, as some have asked for, really isn’t effective. Each organization is different, and the guide rails give you the guidance needed to define what works best for your organization.

The DevOps Community has seen tremendous growth over the last several years. 2013 and 2014 were defining years for the community. Looking at the growth of DevOps Days, there is a clear inflection point in 2013 that shows tremendous growth in the conference series.

Having participated in 9 DevOps Days events myself, I can attest to the fact that the growth of the community is nothing short of phenomenal. At many of these conferences I have attended, over 70% of the attendees were new to the DevOps community. Other DevOps conferences have also popped up, such as Camp DevOps and DevOps Enterprise Summit. Couple this with many conferences now having DevOps specific tracks, and I ask, “What cliquey echo chamber?”

And speaking of the DevOps Enterprise Summit, if DevOps is so poorly defined, ambiguous, and amorphous, how can there be an entire conference focusing solely on success stories of large Enterprises? The last thing enterprises want to implement is something that is untested and unproven. Yet somehow many have begun a DevOps journey and have been successful at it.

DevOps is a cultural and professional movement. It is not a product, solution, or something you can buy off the shelf. As such, it’s rather obvious that there wouldn’t a product messaging or marketing positioning. Product and marketing positioning is obviously important when you are  tryingto sell something. It is irrelevant in the context of a community oriented movement focused on transformation.

One of the most  fascinating changes I have seen over the years in technology is the interest in other areas outside of technology. When you look at transformation, it’s important to look outside of the bubble that you live in for ideas of how to change. Yes, DevOps is often focused on ideas that have been discussed at length in other circles. That is a refreshing change in some circles of tech that think that they are the end-all be-all of significant ideas. “Nobody can teach me how to do this better,” was a common refrain when I entered the IT industry, and it still is today. When I did my MBA, the most amazing experience was learning something outside of technology, and thinking about how I could take this learning and make our industry better. Looking outside, learning, and bringing that knowledge back into the community is a defining feature of DevOps.

While the original post makes some interesting points, it seems to be proposing solutions to problems that don’t exist. In some cases, these supposed problems are defining features of the movement (lack of a firm manifesto; no product definition; old wine, new skin.) which has built a vibrant and effective community that is fundamentally transforming the way companies do IT, in spite of any challenges it faces as a growing movement.

Every synthesis of old ideas and new approaches makes some people uncomfortable and others skeptical. Results are what drive adoption, and the results from a DevOps practice are well-documented at this point. Instead of seeing challenges and hoping for a central authority to solve them, let’s continue on the path of sharing our best ideas with one another and constantly improving.

Thanks to Pete Cheslock, Bridget Kromhout, Stathy Touloumis, and George Miranda for the feedback on this post.