Without Open Source, There Would Be No DevOps Methodology

What does open source software have to do with DevOps? Not much, you might think. Plenty of DevOps tools and companies are closed-source, and the DevOps methodology  developed independently from the open source movement. Functionally speaking, there is no inherent link between DevOps and open source. Yet, at a conceptual level, open source and DevOps have a lot in common. In fact, DevOps as we know it would not exist if not for the cultural innovations that the open source software movement helped to pioneer.

Let's take a look at just how much DevOps owes to open source.

DevOps Is Not (Only) Open Source
First, allow me to point out the obvious: The DevOps methodology does not overlap entirely, or even mostly, with the open source software ecosystem.

To be sure, some open source technologies are essential for many modern DevOps teams. The world of DevOps would like very different without open source tools like Jenkins, Kubernetes, Chef and Docker containers, to name just a few.

At the same time, however, there are a number of important DevOps technologies that are not open source. The serverless computing services from the major cloud vendors are closed-source, for example, as is almost everything else in the public cloud. Various DevOps automation platforms, microservices security tools and more are not open source. (In the interest of fairness, I won't name names, but closed-source software vendors that target the DevOps market are easy enough to identify.)

The point: Open source code is not a necessary part of DevOps. It's entirely possible to build a successful DevOps platform or service without relying on open source software.

DevOps and Open Source: The Conceptual Link
At a deeper level, however, anyone who succeeds at DevOps owes much to the philosophies and processes that open source programmers helped to pioneer.

All DevOps organizations operate according to the following principles, which originated in significant part within the open source software movement.

It would be a stretch to say that open source programmers invented continuous delivery. But they did introduce the idea that software should be released early and often.

To understand just how innovative the open source community was in this respect, we have to step back in time to the early 1990s (when, technically speaking, the term open source software didn't exist; it was called free software). At the time, users were accustomed to waiting years before new versions of operating systems and applications appeared. And, when they did appear, you typically had to wait for someone to mail a disk to you, because few software packages were available over the Internet.

The slow pace of software development and distribution resulted from the fact that programmers at the time operated according to the mantra described by Fred Brooks in The Mythical Man-Month. Good software is like good food, Brooks said. It takes time to produce. It's better to spend a long time working on a project, and try to sort out all of the bugs before release, than it is to give your users rapid updates.

Then, in 1991, the Linux kernel project appeared on the scene. Linus Torvalds, the then 20-year-old developer behind Linux, adopted a very different mindset from most programmers of the time. He released his minimally vetted source code into the wild and counted on users to help him fix the many bugs that they inevitably encountered.

It can be easy to forget today, but this was a huge deal at the time. To quote the editors of Linux Journal, "The number and frequency of new releases of Linux, and drivers and utilities are amazing to anyone familiar with traditional UNIX development cycles."

This concept of releasing software on a frequent basis--and in small chunks instead of waiting for major platform releases--helped give Linux the momentum it needed to overtake other Unix-like operating systems, as well as Microsoft. It also served as a precedent for what we call continuous delivery today.

In DevOps, the ability to build flexible toolsets, and switch out one tool for another whenever necessary, is an important feature for enabling agile software development. Software delivery is much less efficient if you are locked into particular development tools and release platforms.

Today, DevOps engineers take for granted that most tools are interchangeable, standards and protocols are open, and vendor lock-in is limited.

If it weren't for the open source software movement, however, this might not have been the case. One of the great achievements of the open source community was the promotion of the idea that platform lock-in stifled innovation, and that a better world was possible by embracing the principle of openness.

The desire to avoid lock-in was one reason why open platforms like Linux and the Apache Web server became so popular in the 1990s, a time when closed-source software vendors based their business strategies on locking in customers. It also spurred the reverse-engineering of platforms like Microsoft's SMB protocol via open source projects like Samba.

More than the open-sourcing of code itself, the open source software movement helped to effect the widespread adoption of open standards. Today, even software companies whose business is strictly closed-source have to respect open standards and protocols, because the market would not take them seriously otherwise. That's a good thing from a DevOps perspective.

One of the mantras of the open source software community in the 1990s was what Eric S. Raymond called Linus' Law, which postulates (in Raymond's formulation) that "given enough eyeballs, all bugs are shallow."

Raymond meant that the more people you have looking at code, the easier and faster it will be to discover and identify problems.

In an important sense, this thinking anticipated the principles of constant and continuous collaboration, which are central to DevOps today. The DevOps philosophy prioritizes the removal of "silos" that could limit visibility within the software delivery process and inhibit the ability of different types of engineers to communicate with one another. It does this because of the idea that maximizing visibility into software delivery maximizes the chances of finding bugs and fixing them at an early stage of the delivery pipeline, when they remain easy to address.

This isn't quite the same thing as releasing your source code publicly so that anyone can look at it, as open source programmers do. But the idea that allowing, say, an IT Ops engineer to collaborate closely with developers in the hope that IT Ops might recognize a coding problem not obvious to the developers shares important affinities with Linus' Law.

If, as most DevOps teams do, you adopt continuous delivery and prioritize frequent software releases over the slow, tedious review of code prior to release, you have to accept the fact that you will occasionally release buggy code into production. This risk is part and parcel of continuous delivery.

Rather than living in fear of this risk, DevOps engineers respond to it by embracing the concept of failing forward. In other words, when a problem afflicts their code, they seek to learn from it and fix it quickly in order to build a better product. Failure is in a certain sense a positive thing within DevOps and continuous delivery because it helps organizations to innovate faster.

Failing forward is a concept that open source software developers helped to popularize. The rapid release cycles of platforms like Linux brought with them a higher-than-average risk of bugs, but this was a trade-off for the rapid innovation that these projects were able to achieve. In their early days, some open source projects turned out to have deep problems, but these were eventually addressed by the willingness of open source coders to embrace and learn from failures.

It was because of the embrace of failure that, for example, Mozilla Firefox was able to evolve into one of the most widely used Web browsers--despite the fact that its lead developer called it a "complete failure" in 1999, shortly after the open source Mozilla project was born.

Conclusion
DevOps and open source software are distinct ideologies and movements within the IT realm. However, they share key conceptual affinities. If not for the work of open source developers in pioneering ideas like rapid software releases, resistance to vendor lock-in and the embrace of failure as a path to innovation, DevOps as we know it might not exist.