When open source software was still getting established in the enterprise five years ago or so, there was a lot of discussion about so-called open core ripoffs. The concern was that anyone and everyone was proclaiming an association with open source software, even if most or all of their products were proprietary. Today, a similar debate has arisen about devops, a convergence of software development and IT operations for optimal speed, efficiency and other advantages.
For those concerned about misuse or abuse of the term “devops” — which has come to be positively associated with rapid releases, collaboration, efficiency and effectiveness rather than the somewhat rogue movement it was considered a few years ago — there may be some lessons in open source software that indicate the movement and the term will endure, regardless of the posers.
When open source software’s credibility and commercial use were not well established, there was much consternation over “open core,” a term used to describe the approach whereby open source software was used as the core in products that were then offered as proprietary or closed solutions.
The concerns were somewhat justified, but I’ve always believed — and history has indicated — that customers and the market are the ultimate judges and sources of definition on technology. In fact, many users and customers of open source software providers actually wanted open core — that is, they wanted the cost, flexibility and other advantages of open source, but they also wanted a vendor to validate, certify and support that software, regardless of whether the offering itself was open source.
In the end, the open core debates and the fear of open source posers did not stop open source software from being positively associated with cost savings, flexibility and other advantages that later transitioned to performance and innovation.
It also didn’t prevent open source software from seeding the cloud computing market, which today is worth billions across a range of infrastructure, development, systems management and other software technologies. The lesson here is that the market determines what is legitimately open source and where to build and invest.
However, here is a key difference between the two trends of open source software and devops that may serve to further blur its definition: The Open Source Initiative defined “open source software” via licensing, thus allowing an actual definition to exist. Nevertheless, I predict that despite the absence of an OSI-like body to lay down a concrete definition of “devops,” we will see a similar, market definition that is driven largely by its success or failure.
As in the case of open source software, it will be the technologies, tools and vendors that provide what customers seek — speed, efficiency, quality, automation, responsiveness and effectiveness — and win market share and define “devops” in doing so. I see the trajectory for the devops trend taking a path similar to the evolution of themodern view of open core by longtime open source proponent Henrik Ingo.
What is the current definition of devops based on today’s market and use cases? It seems devops is blurring more into auto-ops, which includes existing and legacy infrastructure, technology and process. In other words, today’s enterprise devops practitioners are different from the early adopters of devops practices, which tended to be Web 2.0 and technology-savvy startups.
At Devops’ Core
Even a few years ago, though, we were seeing divisional and departmental adoption of devops in large enterprises, which signaled a desire to move more of their infrastructure and application development and release process under devops methodology. One of the biggest issues for those early enterprise adopters was that new devops technologies and practices did not mesh very well with older approaches centered on stability, command and control, and standards such as ITIL.
Newer devops approaches are also somewhat incongruent with traditional IT infrastructure, middleware, and development and deployment tools. However, as the devops trend has evolved in the enterprise, it increasingly has come to include older infrastructure, process and yes, even ITIL.
There seems to be a growing recognition that for devops to continue to succeed and spread in the enterprise, it cannot live in a vacuum devoid of the reality of today’s mixed, heterogenous, varied infrastructure and tools.
As devops evolves among enterprise customers, it increasingly includes bits and pieces of more traditional approaches that represent significant investment and experience for many organizations. There are signs that devops is trickling down to smaller organizations, particularly as more startups and SMBs leverage pure cloud computing strategies to support their applications, services and businesses.
This may impact the market definition of “devops,” but today’s market — both enterprises and SMBs — seems educated and intelligent enough to understand whether a vendor is simply playing lip service to the latest hot trend or is offering software, support and services that enable faster deployments, improved efficiency, quality, uptime and responsiveness. That’s still — and probably always will be — what devops is all about.