Depending on your perspective, you might believe that DevOps and open source go hand in hand. Or you may think that, quite to the contrary, the two have little to do with each other. There are good arguments to be made for both interpretations.
Let’s explore these two ways of thinking about the relationship between DevOps and open source.
Match Made in Heaven?
In certain respects, the two share a great deal of core philosophical overlap. Both movements emphasize collaboration and rapid innovation.
That is part of the reason why many major DevOps tools are open source. Examples include Kubernetes, Docker, Git and Jenkins, to name just a few.
Indeed, it’s hard to imagine any modern DevOps team or CI/CD pipeline that doesn’t rely to a significant extent on open source tools.
The Tension between DevOps and Open Source
On the other hand, it’s an undeniable fact that many other tools and resources that are commonly used by DevOps professionals are decidedly not open source. There are plenty of closed-source CI servers and release automation platforms, for example. (There are also many tools in this category that are built on an open source codebase but require commercial licenses and proprietary extensions for real-world use.)
There is also the public cloud, without which it’s hard to imagine anyone doing DevOps today. Most public cloud services are very proprietary in nature. Not only can you not inspect the source code behind services such as Azure Functions or EC2, but users also have no control over how those services operate. And porting a workload from one cloud to another can be a big challenge.
In these respects, DevOps is far removed from open source.
How They Really Intersect
What to make, then, of the relationship between DevOps and open source? What does it mean that they share important cultural affinities on the one hand, yet DevOps teams hardly shy away from closed-source tools and resources?
The most obvious conclusion, I think, is that DevOps teams are committed to openness, but they balance that priority with an equal commitment to getting results. In cases where production-quality open source tools exist, such as Kubernetes, most DevOps engineers will eagerly adopt them in place of closed-source alternatives.
In some cases, however, closed-source solutions are superior. And sometimes proprietary solutions are the only type of solution available, as in the case of the cloud. There is no open source alternative to AWS, unless you build your own cloud, but that requires having infrastructure.
Some DevOps teams may wish that they could achieve the results they need using only open source tools. But they can’t, and that’s why the relationship between the two can seem contradictory and inconsistent at times.
