Without open source, there would be no DevOps

No readers like this yet.
Core purpose


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.

User profile image.
Magnus has been in the IT industry for over 20 years, and a technology enthusiast for most of his life. He's presently Founder and Head of Tentacles at Groktopus LLC. https://groktop.us


Ambiguity is often the case when it comes to business management philosophies.

Changes in method are driven by necessity rather than any set of cultural values. More capable machines always change existing relationships.

How could the availability of an all purpose personal communication and computation device connected to a global network not have an impact on a generation in the same way that the explosion in popular music could not have happened without television and easy access to musical instruments?

Development methodologies are descriptive of what is already occurring more so than prescriptions. They provide a language for communicating the facts on the ground.

And I still have no idea what DevOps is...

In reply to by Eli Cummings (not verified)

DevOps is not a job description, it's not a product that can be bought or sold, it's not the role of a person or team. It's best described as a philosophy to inform the way business organizations work together to deliver high-quality, well-tested software to customers on a rapid and efficient cadence. DevOps stresses effective collaboration and communication across all business units in the organization. Such values and behaviors are ideally deeply ingrained in the corporate culture, reinforced by frequent sharing of lessons learned (good and bad). Technical aspects of a DevOps shop include pervasive automation of repetitive tasks (like provisioning and deployment), and a deep understanding of the state of the product infrastructure and the business itself through the use of effective measurement and reporting. DevOps is an approach to solving the nexus between business and technical challenges in a technology-driven business.

In reply to by dgrb (not verified)

and I still have no idea what devops is.. (apart from a well conceived pile of marketing terms that mean very little to anyone not in managment). On the floor as a Systems Admin I have NFI what devops is, hy I should care, or how it should be implemented. It's ruining a 20+ year career for me, and I love and am a big proponent of open source. So you're telling me the thing I love is the reason the thing I hate exists.... great.... Sadly Rehat seem more one of teh companies "touting the term and profiting from any use of it", than a tech leader helping anyone achieve an actual workable "devops" shop/ I know. We've asked for help dozens of times, all we get is more of the same marketing BS that tells us that Redhat have no idea what it means (in terms of implementation) either. So it's up to each business to know it wants it without knowing what it is. Makes for a happy IT department doesn't it.... I'm thinking of going to do a trade, wish I'd done that 20 years ago....

In reply to by magnus919

I don't believe this to be true, or that it's an "all or nothing" argument.

Having an integration between development and operational process to the point that it's an integrated team - or approach - is irrespective of the nature of the technology (open or not). It's the boundaries of the responsibility being blurred, and evolving into something holistic.

Open source almost certainly aided / accelerated / was a catalyst for DevOps ..... though to claim you couldn't of had one without the other, or to claim the credit for one's existence goes to the other isn't something I accept.

Sorry, but great teams were doing development processes essentially indistinguishable from what is now called DevOps long before anything named "Open Source" became tres' chic. There was one apparent difference: rigorous discipline about what goes into a product release and its impact on schedules, and then what goes into production and when. When outages are measured in millions of dollars a minute, one gets vewy vewy caweful about breaking things.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.