Want to understand DevOps? Look to open source's history
Studying the past in order to not repeat it is something that can be applied to DevOps, too. Expert Chris Tozzi outlines how to understand DevOps by studying open source.
The DevOps revolution is only the latest example a long series cultural shifts that have redefined the technology world over the past decades.
The free and open source software movement is another example -- a kind of parallel that's worth studying, especially if you want to understand DevOps and want to avoid making some of open source's mistakes.
A brief history of free and open source software
To be clear, I don't mean to suggest that free and open source software is a failure. On the contrary, it's been wildly successful. According to the 2015 Future of Open Source survey by North Bridge and Black Duck Software, 78% of respondent companies were powered by open source software. In 2016, the survey found 90% of companies relied on open source for improved efficiency and innovation. Open source code is also foundational to the infrastructure that hosts the internet -- not to mention devices like Android smartphones and even your car.
Yet, it'd be an understatement to say the history of the free and open source software community has been rocky. It has suffered from factionalism, as well as major differences of opinion regarding purpose and direction. Those who want to understand DevOps should take note.
Free and open source software is more than 30 years old. Like DevOps, it's a way of thinking and working.
Mistakes to avoid
Just what are those mistakes? Here's a list of the major ones.
Ambiguous terminology
Shortly after Richard Stallman launched the GNU project in 1984, which marked the start of the free software movement, he wrote a manifesto explaining the project's goals.
Stallman stated repeatedly that he intended to create "free" software, but did not define what "free" meant. It was easy for readers to assume Stallman was referring simply to price, rather than control over source code, but that is what actually mattered to him. This uncertainty engendered a lasting ambiguity that endures to the present, when some uninformed computer users continue to assume that "open source" simply refers to software that costs no money.
The lesson for those wanting to understand DevOps is that terminology needs to be defined specifically and expressly from the start. When DevOps engineers talk about concepts like Agile and continuous delivery, they shouldn't assume everyone else knows what they mean.
Thinking too narrowly
When the free software movement was born in the mid-1980s, developers focused on bringing free code to large computers, like those manufactured by DEC. Personal computers with x86 processors were not a priority.
That turned out to be a mistake. The x86 architecture slowly but steadily assumed the lion's share of the personal computing market, as well as a large part of the server market. DEC hardware, in contrast, is now consigned to museums.
If you want to understand DevOps and avoid this, you need to set your sights broadly. You shouldn't aim to revolutionize just one part of the software delivery process, even if it's the most important one at the moment. You should instead reshape all processes, from development to testing to deployment to assessment.
Disagreeing about end goals
Pretty much everyone who supports free and open source software believes that software source code should be shared freely.
Yet, there is a great deal of disagreement about why code should be shared. Some argue it's primarily about providing functional benefits -- open source code makes innovation easier -- while others focus on moralist arguments; Stallman mentioned the golden rule to justify his free software movement. This debate will probably never be resolved to everyone's satisfaction.
Focus on implementing the essential parts of your DevOps processes and tool set .
The DevOps community faces a similar conundrum. Is the point DevOps simply to make software delivery faster? Once you achieve continuous delivery, are you done with your DevOps transformation? Or, does DevOps mean more than continuous delivery? Should improving software security or quality, for example, also be part of your goals?
These are important questions to answer to understand DevOps, lest the community fracture into competing factions, as has happened in the free and open source software world, where some developers cling to the "free software" label largely because of philosophical disagreements with those who prefer "open source."
Don't overlook the essentials
Arguably, the GNU project fell short of achieving its full potential because GNU developers waited until it was too late to begin developing the most essential part of their operating system: the kernel. They didn't start work on their kernel, named Hurd, until the late 1980s. In the meantime, they wrote a host of useful but less essential programs, like productivity software.
Hurd never came close to being a usable kernel. It may get there someday. Its development remains ongoing. Ultimately, GNU developers were forced -- unhappily at -- to adopt the Linux kernel in order to complete the GNU system. Had GNU started developing a kernel earlier, things may have turned out quite differently. We might be using only GNU software today, and Linux may never have been created. Linus Torvalds wrote that one of his reasons for writing the version Linux in 1991 was that Hurd was not close to completion.
To really understand DevOps and future-proof it, engineers will want to avoid making similar mistakes. Focus on implementing the essential parts of your DevOps processes and tool set , then build out from there. Don't set up a fancy ChatOps tool before you have perfected your continuous integration server. Wait until you have the core parts continuous delivery down before starting to add DevSecOps to your routine.
