A number of issues frequently arise as IT teams begin to apply automation to more aspects of the delivery process. If left unchecked these can end up impeding higher level progress. A white paper from CA Technologies explored one of the most frequent issues: “The Open Source Dilemma.”

Open source software (OSS) is generally considered to be an integral part of DevOps, and for a couple of good reasons. It has led to the rapid emergence of innovative tools to meet the requirements of those leading the automation charge, and has also made those tools freely available. DevOps practitioners can adopt solutions to try new ideas and approaches without going through the usual investment justification and procurement process, or even seeking management permission.

But this can lead to a dilemma. Should you encourage freedom among staff to use whatever they want to get the job done, i.e. get out of their way completely, or promote a more structured approach?

Allowing freedom can mean teams are never constrained by limitations of the ‘company standard’ option — a frequent complaint when people are forced to use tools that are a poor fit just because they have already been paid for. When no money is involved, however, it’s all too easy to just grab something that appears to be suitable without conducting proper due diligence, e.g. considering how requirements may change down the line or how colleagues have met the same need. Perceived "coolness" of tools and marketability of associated skills can also influence choices.

This matters because decisions based purely on personal preferences and a parochial view of needs risk duplication of effort, redundant solutions, integration disjoints, and lock-in to tooling that is only partially fit for purpose over the longer term.

Building on the above, there is also a tendency for enthusiasts to sometimes get carried away with the power of their chosen tool, in turn leading to overextension of solutions. With enough scripting it’s perfectly possible to use build automation tools to configure hardware, or ops automation tools to run software builds, but neither is necessarily a good idea.

For the avoidance of doubt, it’s important to reiterate that implementing DevOps at scale is not about throwing out all of your open source software and best of breed solutions, and replacing them with integrated suites of "big iron" commercial software. A big part of DevOps is about getting away from the old rigid approach of forcing broad use of solutions that handle a range of requirements, but none particularly well.

It makes sense, for example, to continue to exploit OSS tools in most areas of DevOps. Even if you elect to pay for enterprise distributions and associated maintenance from commercial providers, you will still benefit from rich community and ecosystem support, and advanced availability of features to enable adoption of new ideas and practices. Sacrificing such things for the sake of standardisation is counterproductive. At the same time, there are some areas in which consistency allows you to optimize efficiency, quality and service levels without compromising agility.

The trick is to know where you need consistency and where open source can be a good option, and to find the balance between freedom and structure.