Without open source, there would be no DevOps

If we're going to do DevOps, we have to give up open source. Right? Wait, we're an Agile shop, so we have to give that up, too. Right?

Over the last five years or so, I've talked with a lot of people confused about what it means to "do DevOps,” and clearly concerned about having to give up other things that have already proven their value in order to adopt DevOps. The bad news is, we've not done a good job in the DevOps community of nailing down what DevOps is and what it isn't at an earlier stage in our development.

This ambiguity has fueled ongoing confusion and opportunities for questionable misappropriation of the term "DevOps" for ill-gotten gains. Mostly this comes from carpetbaggers and scallawags that just want to use the word "DevOps" to sell you their tool or service that you'd otherwise not pay any mind to.

In truth, there'd be no DevOps without open source. There is a whole chain of events, dare I say a “perfect storm” of technologies and philosophies rising to prominence that rendered inevitable the rise of DevOps or something like it.

Open source projects rose up that gave us free operating systems that made the modern dynamic web an economic feasibility. Linux and GNU weren't the least of these things. Certainly middleware, relational (and non-relational) databases, and myriad programming languages rose up through the open source community that provided the technical scaffolding needed for DevOps success.

But more to the point, open source was an incubator for cultural developments that rose up with the technology. Eric S. Raymond's disruptive essay The Cathedral and the Bazaar revealed to the world overnight a framework for scaling software projects globally. Many of the values that formed the foundation of the DevOps movement were present, even in this early phase of the open source movement.

As open source matured and tooling begat more tooling which begat rapid development frameworks, continuous integration tools and workflows, unit testing frameworks, and more, we started to see the rise of very sophisticated software applications being stood up and delivered to customers in an absurdly rapid fashion. Open source solutions rose up to replace physical machines with virtual machines, virtual machines with cloud instances, cloud instances with containers. IaaS, SaaS, and PaaS needed DevOps to happen in order to find success.

Not to be overlooked is Linus Torvald's greatest contribution to the open source community. I'm not talking about Linux—I’m referring to Git. Git reimagined Source Code Management (SCM) from the perspective of highly collaborative development teams with lower levels of inherent trust, higher latency, and higher burdens of proof that submitted patches are indeed good. Branching, something that was once a computationally expensive operation, became so cheap as to become a pervasive aspect of modern software development. Similarly, the advent of the pull request has facilitated a whole new wave of open source collaboration.

If you go into any successful DevOps organization and look around, it should not be a surprise that tooling is favored that facilitates highly collaborative development across teams or individuals that may otherwise be very loosely coupled (and, thus, have a lesser trust relationship than collaborators working within one business unit). It's a pretty safe assumption that Git is going to be used in some way, because other SCM solutions like cvs and subversion don't facilitate the sort of pan-organization collaboration that is pervasive in DevOps organizations.

Many DevOps practitioners place an extremely high value on sharing. We share our successes, we share our values and what we've learned from our failures, we share our metrics, and we share our code. And we share our code in such a way that others can meaningfully contribute. This wouldn't be practical in a world without open source. The best of breed proprietary tools in this space are all based off of open source tools, and the cultures that have sprung up from the globally collaborative workflows that they enable.

We have had open source without DevOps. But without open source, I'd contend there would be no DevOps. Successful adoption of DevOps requires a strong culture to support it, and I believe the best DevOps cultures have their roots in open source communities.

This article is part of the Easy DevOps column coordinated by Greg Dekoenigsberg. Share your stories and advice that helps to make DevOps practical—along with the tools, processes, culture, successes and glorious/inglorious failures from your experience by contacting us at open@opensource.com.