Update: February 28th. We referenced a recent spike in issues in Ansible. Red Hat have clarified that Ansible modules have all been merged into the main repository.

At RedMonk we have always taken a keen interest in the configuration management tools space, and have analysed it severaltimes in the past. It is fair to say that configuration management tools are a well-established part of the enterprise software ecosystem at this point.

While a lot of the current interest and coverage among early adopters is focused in the cloud native space, this somewhat distracts from the sheer size of addressable market available for configuration management tool vendors.

All though the need for configuration management tools has been well established, and companies are more than aware of the benefits, a clear majority of large enterprises are still in the very early stages of adoption. Put more simply, if you think the millions of internal applications enterprises are running around the globe are going to migrate to a completely cloud native approach at any time soon, you are sorely mistaken. At the same time enterprises have significant regulatory compliance overheads and need to work with auditors on a regular basis to ensure their technology stacks comply with the relevant regulations.

Given these factors it is obvious why variants of the phrase ‘compliance as code’ are used by all the configuration management tool vendors. This is very direct, and sensible, marketing to CIOs and operations teams. We hear, on a reasonably frequent basis, about compliance and audit teams in large organisations using artefacts such as Puppet manifests and output logs for their auditing needs.

Now the current cloud native focus of many is not an indication that developers are no longer using configuration management these tools – they do, in large numbers. In many of our conversations we hear a clear preference towards tools such as Chef and Ansible from developers. Differences can cause problems, and where operations teams and developers are using differing tools issues can, and do arise.

For the purposes of this analysis, we have limited our scope to the configuration management tools we hear mentioned most frequently, these being Chef, Puppet, Ansible and Salt. While tools such as Hashicorps Terraform are sometimes referenced in the same context, they, in our opinion, fulfil a different need.

Community Migrations?

Firstly, we looked at the relationships between the various communities. Perhaps the most interesting aspect here is the lack of significant crossover between communities. This reflects many conversations we have – once operations teams have decided on a configuration management tool they tend to stick with it.

There is, however, more than enough crossover between communities to merit a slightly more detailed look. As you would expect we see a reasonable cross over between Chef and Puppet, at almost 15% of the overall population. More interestingly is the emergence of Salt as an alternative against all the other tools – particularly Ansible.

As an aside, the second visualisation above has been created using UpsetR, a link to the academic paper describing Upset is given below.

Github Stars & Twitter Followers

Across each of the configuration management tools we see a steady, consistent, level of growth over time, with the notable exception of Ansible which is on a far steeper trajectory. That said the interest level in Salt is substantial.

While Github is always a useful source of information, Twitter followers also provide an interesting reference point. Here we see Puppet having almost as many followers as the other tools combined.

Commercial and Community Contributions

We next looked at the number of commits and issues for the core components of each tool. This obviously does not include plugins and so forth, where the clear majority of user contributions are made, and is just a reflection of the core platform. Where possible we have identified contributions from employees.

Over the last two years Ansible and Salt have been far more active developed, but in many ways this is not surprising given the relative ages of the projects.

Ansible

Red Hat dominate commits to Ansible, while the community creates a significant majority of all issues.

As a side note, there has been a huge spike in the number of issues in Ansible recently which merits some further investigation, and we have asked Red Hat for some clarifications here. Red Hat have clarified that the spike in issues is due to the fact that Ansible modules have all been merged into the main repository.

Chef

Chef employees contribute the majority of commits and issues for the core Chef project.

Salt

SaltStack employees make up most of the commits to Salt. On the issues front it is a somewhat more nuanced, with the community and SaltStack roughly tracking each other for issues logged.

Puppet

PuppetLabs employees are in the majority for both commits and issues for the core Puppet project.

fryansays:

I’m glad you pointed out that the differences in compliance management tools can cause issues. I have run into certain problems using different tools. I’ll look at the suggested ones and others until I find one that works the way I need.