Michael DeHaan created Ansible in 2012, but he was ever very interested specifically into systems management technology and didn’t have an IT background of really managing a server fleet himself. He was always more interested in software architecture, design, and programming and tended to work on backend server applications, but not exclusively.

Why there was so much systems management in RTP (where Michael worked) was interesting. We can mostly credit IBM, which is amusing because this story starts with an entity that would later grow to own Ansible some 15 years later.

In the early 2000s, the Research Triangle Park (RTP) region of North Carolina was home to numerous systems management companies , likely due to IBM’s presence there since the 1960s. After the Dot Com crash cost Michael DeHaan a job offer at Nortel in 2001, he ended up at IBM working on RAID controller management software. IBM would later sell that division to Adaptec — following IBM’s pattern of spinning off parts of itself, such as it would later sell the laptop and server divisions to Lenovo.

While most of his time was spent with C, C++, and Java, to fill the time in long Adaptec status meetings, he learned Ruby and upgraded his Perl, using both while getting involved more and more with the company build system.

This period was also a time seeing how the management tools the company was writing were somewhat impractical at scale. There was no way to use them to manage a batch of servers. It was very much a "server as pets" kind of situation.

Had the Java work not been arduous, his Ruby interest would not have happened, then Python would not have happened (as quickly) and …​ so on. This would become key as these languages would grow in popularity to build IT automation tools and open source projects in the near future.

Right next door around the corner from Adaptec’s RTP office was a company called Integrian, which was working on early digital video solutions for recording what happens in front of police cars.

Integrian used Python extensively, including for GUI work. Michael joined Integrian working on utility GUI tools using wxWidgets in Python. It was a fantastic place to work for about six months before some VC actions decided to invest more in overseas locations.

Michael also met his friend Chris Church at Integrian — who would later help build the early Django backend for Ansible Tower and also (later) the first work on Ansible’s windows implementation.

Michael also learned a bit about how to manage engineering teams from how the engineering side of Integrian worked (and from counter-lessons from some other places later).

Michael ended up using his Python experience to join Red Hat.

Michael joined Red Hat around 2006, working on systems management tools in the "Emerging Technologies Group". "ET" was a large organization but the systems management team was about five people within it.

The ET team could mostly develop solutions to help customers without any product focus, however just a few cube rows over, Red Hat was also working on their commercial management stack, Satellite.

At Red Hat, after a request to make something like system-config-kickstart that could also handle virtualisation, Michael started Cobbler — most notably used as a PXE deployment framework. At the time, most PXE automation were handwritten by individual people at different companies, and not shared.

As Michael’s first open source project, Cobbler achieved significant adoption and was used in two top-500 supercomputers, chip design clusters, banks, render farms, and the infrastructure for Call of Duty’s server farms (a popular multiplayer game).

Michael’s manager left early on to join a startup called rPath, and he decided to more or less make the IRC channel for the Cobbler project (below) his boss, which would lay the foundations for how the community efforts at Ansible would later be run.

Uptake in Red Hat and CentOS shops was particularly large, and the CentOS community were particularly good contributors.

Cobbler was different than many other Red Hat "enterprise" open source projects in that there was a very strong community first focus including co-development, whereas in other projects it was more frequent that software was developed and the community was seen as a userbase. This ethos of not really revolving around the company was also common to the Fedora Project.

Cobbler (below) started to indirectly compete with closed-source Satellite, as people mostly needed an easy way to provision systems and get packages onto them. This underscored some early lessons about how GUI management software was often more tricky than managing things with scripts, version control, and automation. The ways people wanted to manage systems at scale was quickly changing.

Cobbler would also start to cross paths with a configuration management tool, Puppet, in very interesting ways, of which Ansible was an alternative.

To avoid Satellite usage, Cobbler was often used in large installations with mrepo, created by Dag Wieërs or yum-utils’s reposync, where Seth Vidal (both mentioned below) was the lead developer. Both of these tools provided package mirroring solutions so users would not have to use GUI management tools like Red Hat’s own Satellite server. Both individuals would later become very involved with Ansible (as detailed further below).

These tools (along with Puppet/CFEngine) would later sort of be rolled up into the idea of "DevOps" but none of these projects were really trying to align with that movement, culture, and term specifically.

(It should be noted that RHEL customers using Cobbler vs Satellite still paid Red Hat and it helped them sell more operating system licenses, so free automation was still commercially useful to the company)

Bare metal provisioning felt pretty smooth, but Cobbler would have probably benefited from using a database and having more of a "team" around it. Missing some potential to lead a team around it would later influence Michael towards leaving towards other places. Michael’s open source efforts sometimes felt a bit less robust to him than when he had time to work on something closed-source and commercial (often a lot of backends and API work) — all kind of a result of having to work in community contributions, interest, support, Q&A, and so on.

There was lots of multitasking.

Cobbler was named "Cobbler" because it makes machines boot, as a Cobbler is someone that makes shoes. Cobbler’s virtualisation helper piece was called "koan", for "kickstart over an network", which could also reprogram the boot loader of a system and reboot it so it would reinstall itself, either to specific configured profiles or to whatever was assigned on the cobbler server.

Cobbler assigned machines to particular roles usually, so this was an early example of trying to avoid configuration drift but applied to the bare metal OS install level. Common field practice was to bootstrap the machine just enough to run a configuration management tool, which was often Puppet.

To try to replicate Cobbler’s open-source success, Michael, Adrian Likins (of up2date fame), and Seth Vidal (author of yum) created Func — a project designed to fill the gaps between Puppet and Cobbler.

Puppet did configuration management well and was popular, but sometimes users needed to do something "now" and arbitrary, and it didn’t fit into config management ideas (which were more formal and declarative) at the time. This was not Puppet’s fault — it is just this other thing didn’t exist. This might include simple one-off tasks like installing software updates and rebooting servers, where puppet was about managing constant state. This could also include simply triggering puppet runs immediately rather than waiting for a periodic timer.

Greg DeKoenigsberg (and a Fedora Project lead) on Red Hat’s Community team suggested Michael, Adrian, and Seth get together to brainstorm new project ideas and this problem (above) is what they decided to work on. This the project "Func" was started, eventually backronym’d to "the Fedora Unified Network Controller". Func was a quasi-reference to Parliament Funkadelic, as chosen by Adrian.

Seth Vidal worked to port certmaster’s PKI from Puppet with Luke Kanies' approval. Among other parts, DeHaan wrote the parallelization feature "forkbomb" and the "hostglob" feature — both of which would become similar to features in Ansible. Adrian wrote other key important components and modules, and also maintained the project as Michael went back to work more on Cobbler and Seth went to work more on Fedora infrastructure and yum.

Ansible’s idea of modules being good community entry points also originated in Func. Compared with Ansible, Func ran a daemon on remote hosts that returned structured data vs using SSH. Some experience with users having PKI/SSL problems (NTP, DHCP, etc) would influence the need for configuration management systems to not rely on PKI systems, which was realized in Ansible.

Func was used in a few neat places including in some aspects of Fedora’s infrastructure systems, at Tumblr, and so on.

In many ways, Ansible’s "runner" (the piece underneath playbooks and the ad-hoc command line tool) was also an iteration on Func — but SSH instead of daemons.

At the same time, various Red Hat work was being applied around the AMQP message bus standard and an implementation called QPID, in partnership with various large customers. There was the idea of using a message bus instead for Func, but there were still complexities around usage and setup. Such a message bus implementation was used in an attempt at a virtual appliance management and orchestration tool, Michael, Adrian, and Scott Seago were asked to write called "virt-factory". Red Hat would later go on to make other attempts at this with various projects and enterprise offerings, ultimately ending up with a version of OpenShift that was more or less a Kubernetes distribution.

In some ways, picking a specific message bus set up for Func would have created a bit of an adoption funnel - if somebody didn’t pick the message bus you picked, would they want to use your tool? This question would continue throughout Ansible’s development but it was fairly clear the idea of needing one was perhaps unimportant — Ansible would find out that people really didn’t want to reconfigure their entire server fleets all at once — that was often too dangerous! Thus it was seen that an over-emphasis on performance could be seductive, but it was a bit of an "engineer trap" because it’s such a fun problem to work on versus user surface areas that make more impacts.

If the message bus technology would have been a bit more mature at the time and easier to use with security features, Func would have probably used those, and Ansible may not have even used SSH. But SSH ended up being the absolute right call and a key (along with language simplicity) to Ansible’s popularity and early adoption.

At Red Hat, Michael wanted to build a config management layer on Func, which he had named Remote Rocket Surgery (there may have been a Wiki page once). But due to some internal politics in the group, building it was not an option. Basically there were people at Red Hat who did not want to compete with Puppet, for some reason.

This delay ended up being good as it provided a lot of idea and time to think about what it would be.

Around 2009, Red Hat experienced acquisitions and reorganization that closed the Emerging Technologies Group. DeHaan was asked to limit Cobbler work to 40% of his time (which he really liked working on), and there was a want to have him work on a merger between Red Hat Satellite Server and JBoss Operations Network that he was not interested in.

Finding a job that replicated that freedom from Red Hat’s "Emerging Technologies" group was difficult. DeHaan first chose an unnamed place he did not like. Wanting to get out of that job, he briefly joined Puppet Labs (described below) for a short time.

As you can perhaps see, Puppet is starting to weave itself into this entire history and the need for Ansible is starting to emerge more strongly as time goes on.

Michael joined Puppet Labs as employee number 13 as a product manager who was also going to help out on the community (open source) side of things (based on the overlap with Puppet in perhaps 25-50% of Puppet install bases at the time), but this did not last long.

While the project was well established, the company was new. If Puppet had been ready for more structure at this stage and travel not almost constant, he would have stayed — and Ansible would not have happened.

However, this was a good chance to observe some community structure to see how it was different from Cobbler and Func. Puppet was a bit more of a user community, than sharing development quite as much — there were some people very notably involved but it felt somewhat different. The company funded most of the core development and the community leaned more towards testing and advocacy and suggestions.

Ironically, the Puppet Labs experience really didn’t influence the course of Ansible too much but did confirm some prior feelings about the maintenance cost of a parser and PKI infrastructure. The team spent a lot of time on the "core" of the system, if anything, the idea that things needed to be internally simple was underscored.

Puppet was developing a GUI at the time, though there were community attempts to make alternatives.

(It is probably also worth pointing out that for a while many people would deploy and manage the operating system with Puppet, but would also use independent tools like capistrano to do deployments. Capistrano was SSH based, but better suited to "imperative" just once kind of tasks, and also did not need a daemon like func. The need to learn two tools would become another driving force in shaping Ansible a bit later)

Michael needed a non-travelling job so he joined WebAssign, which was local to him and where knew a manager from the local photography group.

WebAssign was an powerful online homework solution that is infamously disliked by many thousands of college students. Their backend was mostly all Perl, where Michael introduced some more recent "Modern" OO Perl modules and object oriented design concepts, working to increase code reuse.

While Michael was working on a feature that didn’t really see much adoption, he got to know the IT team pretty well and observed their deployment process.

The IT team would deploy things via scripts but could not adopt Puppet because it was very complicated. They had a rolling update topology using F5 load balancers, but did most of this process with a lot of manual interlocks, and the updates sometimes failed or human errors were inserted. Typically they would set up shop in a conference room to run the scripts through the chain of servers, and this would take possibly 30 minutes or several hours and failures did happen.

Observing this rolling update orchestration problem would be absolutely critical for Ansible’s success, as the "serial" keyword and built-up rolling update support, which did not exist in any other configuration management tools at the time. Ansible was very much designed with this team always in mind, though not explicitly for them specifically. "Orchestration" kind of became a major keyword later in the company’s early history of explaining differences between more configuration-management focused tools.

WebAssign had about 100 servers in a pretty simple three tier architecture. Being able to work closer to IT gave some better understanding of the potential of "DevOps" ideas to break down barriers.

Additionally, a positive three-tier architecture experience there cemented a later desire to push back against very complex cloud systems, micro-services architectures, and so on — while Ansible also did really enable people to deploy those architectures as well.

Leaving WebAssign, Michael joined his old manager at rPath (where he had left from Red Hat), which was building virtual machine image/appliance creation solutions. Part of rPath’s product was really a better "enterprise" version of something like Packer (not created until 2013) but it was hard to use. Due to marketing challenges and product complexity, the company did not survive.

Towards the end of that time, Michael was being asked to implement a Puppet integration to rPath that sort of 'hid' Puppet language, which he absolutely knew how to do, but he was being told how to do it in a way that people would not like (using XML). Ultimately, he thought customers really wanted to just use Puppet if they were going to use Puppet.

While this solution was wrong, it became somewhat apparent that if he did not "solve" Puppet, Puppet was going to keep following him around at various systems management jobs which were most of what existed in the RTP area.

Amidst this frustration (XML!), Michael also missed the fun community aspects of running open-source projects and designing more things on his own.

Looking to more or less recreate the positive parts of the Cobbler experience, Michael started Ansible on nights and weekends.

(This is sort of a prologue to how things got started, and is when the decision that Ansible could be a company happened — the early history of the project occurred in parallel and is detailed below)

When rPath closed, Michael joined Cisco to write Python code for OpenStack, though this really didn’t happen. He got caught up in an endless Puppet effort to write content to automate OpenStack, and the whole team would restart working on the next version of OpenStack every time a version came out. It was very complicated and ironic. (It also used Cobbler for PXE, which was there before Michael joined).

Because everyone was scattered between different offices, it wasn’t a particularly great place to come into.

Since he wanted to write code and not IT automation content, Ansible seemed pretty appealing now — could that be a job? While Ansible was growing in popularity quickly at the time, Cisco was not interested in it, since they had a strategic venture investment in Puppet.

The industry needed an escape not from Puppet itself, but from what consultants were doing with Puppet — or the fact that people needed consultants, or teams of 12 people to write Puppet.

This is an important understanding — the Puppet tool wasn’t the problem but what the tool got people to do tend to do with it. Tools however influence what kinds of tools people create with them. This experience would guide early Ansible development very much — the desire for automation content to be easy to read.

After working on a prototype at night for just two weeks, Michael used Cobbler’s mailing list to send out an announcement. The first release contained just the ad hoc command execution tool, which was essentially an evolution of Func. The playbook language was not written just yet but came very shortly thereafter.

The idea that good projects could more or less "launch" as two week prototypes was established from Func. (Today, there’s more demand for complete systems, probably).

The motivation came from multiple angles - Michael wanted the kind of community experience he had enjoyed with Cobbler, and he kept encountering Puppet integrations he found frustrating. He didn’t hate Puppet — he thought Luke Kanies and his team did great technical work, but he disliked the agent communication setup that often failed, the complex language, and saw how much development effort went into the parser and PKI system. Mostly, he just wanted the community another open source community experience like he had with Cobbler. Could we show people that simple things could "win", even after very minimal efforts? Could he find a way so Puppet wouldn’t keep encountering him at various jobs? Why couldn’t "Remote Rocket Surgery" be remade today?

Playbooks were named after a sports analogy (American football) — rather than defining structured configurations a system must exactly match, they contained a set of properties that could be applied to systems in different scenarios as someone decided. It could be declarative, but could also be run for all other kinds of tasks. Order also mattered, which made things predictable. Rather than having configurations sometimes take many runs to be "right" (as with Puppet and CFEngine’s convergence), they were right after the first run.

Early Ansible was mostly triggered either manually (from someone’s laptop) or from a CI/CD tool like Jenkins. People could also run Ansible locally, and even on "cron" if they wanted periodic configuration.

The name "Ansible" came from science fiction. The first usage is from Ursula K. Le Guin — a device capable of faster-than-light communication, in Rocannon’s World (derived from "answerable," as the device would allow users to receive answers to their messages in a reasonable time, even over interstellar distances). Other sci-fi authors borrowed the idea. Having never read that book, DeHaan actually took the name from Ender’s Game by Orson Scott Card, where the ansible was used to control a large number of remote ships at once, over vast distances — a fitting metaphor for controlling remote servers.

The first commit appeared on GitHub on Thursday, February 23, 2012, with the Git comment Genesis.

An exceedingly vast amount of time was spent trying to make it very easy to understand the documentation. An early conversation with Seth Vidal led to the advice that people should be able to learn and understand the tool and have some success with it doing things in the first 30 minutes, basically during their lunch break. This documentation focus would be a strong driving force for the next several years, taking up some 40% of Michael’s time in the early days. It was important to not only teach how to run the tool, but why and when, and also teach people about some aspects of some related tools they might not know about (such as some SSH features). The docs were written to be random access and kind of "choose your own adventure" so people could be curious about learning new things and keep going back to them. Similarly, they showcased all the modules available in one place so people could browse for ideas about what they could do with the tool.

The online docs were the main form of marketing for Ansible in a way, with various tutorials being written, reblogged, and it being linked to frequently. In order to keep people seeing what was new, there was a concerted effort to not have offline static documentation. Approximately 6 months into the project, there were about 500 people a day visiting the website, which seemed fantastically large at the time.

Because nothing had to be installed on remote hosts, Ansible could be consumed directly from git, and was generally stable that way, but official releases were still made to Fedora and EPEL early on.

The first release, version 0.0.1, was published on March 9, 2012 and was untitled. The codename Baluchitherium was later used for version 0.3 (April 23, 2012) — one of many Van Halen song names that would grace Ansible pre-2.0 releases (DeHaan being a Van Halen fan). The last release in the 1.x range, version 1.9.4, was named Dancing In the Streets and was released on October 9, 2015. (The code names were fun but not important).

A short list of very early commits and contributors, some US and some European, (by chronology, not volume) with the first commit message included:

Seth Vidal was an important figure in Ansible’s pre-history as well as its first year. As the lead developer of yum and a member of the behind Fedora Infrastructure team, he had a lot of experience about how systems were managed in the real world. He also helped write Func (detailed above) with Michael and Adrian Likins.

Seth joined the Ansible project almost immediately. His GitHub account dates to February 24, 2012, only a day after the first commit.

Seth initially helped shape the yum module and broader packaging work, contributed callback and connection plugins, and committed to side repositories. Because of his work on Fedora infrastructure (which was also an early Puppet installation), Seth had a strong grounding in the needs of managing remote systems.

One of Seth’s interesting Ansible contributions was local facts: the ability for managed nodes to expose custom data through *.fact files in /etc/ansible/facts.d, populating the ansible_local namespace. Introduced in Ansible 1.2, this feature was discussed with Jan-Piet Mens at the first AnsibleFest in Boston in 2013.

Seth also thought deeply about how Ansible would work in real environments. In a May 2012 forum post he described structuring playbooks for roughly 100—​150 heterogeneous servers and weighed Ansible’s SSH push model against the performance needs of large fleets — practical systems thinking from someone who had spent years keeping Fedora’s own infrastructure running. He was also a great sounding board, helping Michael with ideas, hard SSH/SSL issues, and being very available over IRC chat.

Michael later recalled that early interest from respected Red Hat figures like Seth was enormously encouraging and provided extra motivation to take it beyond the initial few weeks: "If they were interested, maybe this is barking up the right tree." Sadly, Seth died on July 8, 2013, after a hit-and-run accident while bicycling in Durham, North Carolina. He was only 36. His loss was felt across Fedora, Func, yum, and the Ansible community alike.

Jeroen Hoekx from Lommel, Belgium was the first European to contribute code to Ansible and one of the first to use it in production. By the time Ansible 0.4 was released (May 2012), Jeroen had already made 25 contributions — second only to DeHaan’s 135.

His contributions were substantial: significant inventory work, general bug-fixing, and the Filter Plugin mechanism that underpins Ansible’s data transformation capabilities. He also created several modules that remain in use today:

Jeroen used Ansible in production at HP for consultancy engagements and later to automate the SaaS environment and application deployment at D square/TrendMiner.

On June 6, 2012, Jan-Piet Mens (JP) wrote a blog post about Ansible (https://jpmens.net/2012/06/06/configuration-management-with-ansible) and tweeted about it. JP was heavily involved in Puppet at the time but found it overly complex and disliked Ruby — he was working on a project to automate deployment of DNS servers and grasped at any straw he could find.

(This pattern of "I was almost building a tool like this" was a frequent story of early Ansible adopters. Had Ansible not been written, it is likely someone else would have written something similar.)

Ansible was written in Python — a language JP knew — and he began spotting and fixing issues, submitting his first pull request (#634) on July 20, 2012. JP’s blog post helped introduced Ansible to Europe, sparking interest across the continent.

The first written record on GitHub of JP contributing is dated July 20, 2012, though he may have had previous interactions on the Ansible mailing list. Among JP’s most significant contributions was the online module web documentation generator — the idea that modules and plugins should have inline documentation, extracted on-the-fly with ansible-doc(1). The inspiration came from Unix man pages.

JP’s other notable contributions include:

In the early days, Ansible spread a lot by people blogging about it (as well as tweeting), JP Men’s blog was among the most obvious and popular.

Ansible’s early community growth and growth up through 2015 was mostly viral.

People were spreading Ansible on their own, by reblogging tutorials and sharing their own experiences. One of Michael’s cooler moments was waking up and checking Twitter and seeing a presentation being made totally in Japanese in Japan — with a surprise overflow room.

As Ansible grew, a new challenge arose — trying to keep all the users and contributors happy even though they all wanted to take it in completely different directions. A path had to be charted between all of these different directions. There were a ton of pull requests to add features to test, merge, and help polish up.

DeHaan reflected: "I liked Ansible best when it was smaller and the quality could be kept up better." The mailing list kept growing, eating into weekends, with much time spent merging OSS tickets, communicating, writing documentation, and writing a giant portion of the whole thing.

There was a balancing act between keeping things small and streamlined and doing enough ("batteries included") to fulfill all the things people wanted to do with it.

A lot of time was also spent with new contributors who didn’t know git, often sysadmins newer to Python as well, teaching them how to use the version control system. This led to a lot more early contributions at the time.

Early on, Michael was approached by several different people trying to make a company out of Ansible. He really wanted to bootstrap, but it was difficult getting key users to be on board for something like support revenue. Finally, he decided to accept one of those proposals.

In 2013, Michael DeHaan co-founded AnsibleWorks, a VC-funded startup built around the Ansible Configuration Management tool, because the ansible.com domain was taken. The company later would buy the domain and renamed itself Ansible.

Initially, Michael just intended to sell the web-based Ansible-Tower control interface. Tower was needed because everyone who used Ansible could SSH into servers with their laptops. Companies wanted an audit log and role based access control.

Eventually, others at the company would decide to experiment with support and consultancy offerings, though through 2015 these were never large or that successful. Michael wanted Ansible to remain a product company, because a company that could support a consultancy had reasons to create complex products — as he had seen with Puppet content projects, for example at Cisco.

Some of Tower’s early development (just after the seed round) took place in coffee shops and in meeting spaces at DeHaan’s alma mater’s new university library, which they "snuck into." Chris Church built large chunks of the early Django backend (DeHaan had met Chris at Integrian) with Michael and Chris Houseknecht built the UI layer — which Michael described as a remarkably solid and bug-free interface. Later, more people were added to the Tower team and also to help with all of the community project influx on the mailing list and Github.

While the company also needed a commercial product (revenue), one other reason Ansible Tower was not fully open sourced originally was that it was very hard to coordinate open-source efforts around things like database schemas and API inconsistency — having real meetings with whiteboards made it much easier to keep everybody on the same page. For a project to be good as a real open source project, it needed to be a collaboration.

At Ansible, Michael took care of product management, project management, the community, marketing (all from the web and open-source events), while still writing code on the core product — a lot of it (such as the "roles" feature) on the road while travelling.

Michael gave an early Ansible talk at a meetup event in Durham, NC but did not really present on Ansible for a good while after it started, even while there was a company.

Ansible spread by people giving talks on their own at various meetup groups. The first one was probably at a library somewhere in the midwest USA, and these were all done completely ad hoc and only discovered through finding them on Twitter. Everything was pretty much "viral" and twitter was a large part of the equation.

The very first organized AnsibleFest was in Boston in 2013, a 1-day all-day event, filled with talks from users and a lot of conversations. It was collocated with Red Hat Summit in Boston. There were maybe 40-60 or so attendees.

There would be larger versions of this in following years.

The first European Ansible Meetup is believed to have taken place on Saturday, June 29, 2013, at Don Bosco in Antwerp, Belgium. Approximately 20 people attended, hosted by Robert Keerse of "Don Bosco werken én leren." This meetup also marked the beginning of presentations, training courses, and deeper community engagement.

These meetups were organized through the Meetup website and became a gathering point for the growing European Ansible community, including the Rijsttafel gatherings afterwards.

In January 2015, Michael DeHaan announced he would be leaving Ansible, effective February 1, 2015. The stress of dealing with internal company politics had become too much — though he greatly regretted having to leave the project.

The project had several core team members at Ansible Inc that could continue to assist and organize the community.

James Cammarata was the earliest team members of Ansible Inc on the core product and took over 'lead' features. He had already started "Ansible 2.0" features planned by Michael. James also switched release code names to reference Led Zeppelin songs. James was also responsible for a lot of early work on Ansible Galaxy, an online portal for accessing Ansible community content.

Management of the community team would eventually be picked up by James Tanner, who Michael worked with at rPath. James had already been a key core team member, having developed ansible-vault among lots of other work.

Other community core developers remaining included Brian Coca, who had contributed a vast amount to Ansible before joining the company, and Toshio Kurotami, who was also a member of the Fedora Infrastructure group before at Red Hat.

On October 16, 2015, Red Hat announced it would acquire Ansible. The web-based Tower product continued as Ansible Tower after the acquisition.

Years later, Red Hat introduced Ansible Automation Platform (AAP) as a broader enterprise offering that included Tower and made various architectural changes. By September 2023, support for AAP 1.2 (Ansible Tower 3.8) ended, driving migrations to AAP 2.

In September 2017, Red Hat finally took the step they promised the community after the acquisition of Ansible: it open-sourced the Tower codebase as AWX, the upstream community project behind Ansible Tower. The release did not include the full source history of the project or the original RPM sources and playbooks. Due to this resultant install complexity, it was made compelling to use the commercial versions.

The model followed Red Hat’s Fedora-to-RHEL pattern — development in the open AWX project, with selected releases hardened into the supported Ansible Tower product. Ansible Tower 3.2 was the first version built from AWX. The name itself was not new; it was one of the names that were going to be used for Tower in the very early days, which was in turn a short form of "AnsibleWorks".

Mark Burgess, a post-doctoral fellow of the Royal Society at Oslo University, Norway, began writing CFEngine in 1993 — the first tool to truly do "Configuration Management." This is not exactly the case, though, as admins had always been writing their own scripts. It was however the most obvious common example that people seemed to rally around.

CFEngine was built on Burgess' idea of promise theory — the idea that autonomous agents make promises about their behavior rather than being centrally commanded. This, along with idempotence and convergent systems, formed the foundation of modern configuration management. CFEngine popularized describing the wanted state of a system rather than all tasks to perform. It detected anomalies caused by configuration drift and automatically repaired them.

(Ansible would later assert that configuration drift was not a real world problem if humans didn’t manually mess with machines, though its modules were still useful for similar declarative configuration).

With CFEngine, convergent systems still had problems — when a configuration run was scheduled unattended, it could take several hours before all systems reached the desired state. The in-between states could also be unstable. The idea that system runs should be predictable would be a major factor in Ansible’s early design choices.

Movement to other tools was somewhat provoked by a version change in CFEngine’s syntax, making room for Puppet.

In 2005, Luke Kanies started Puppet Labs around the Puppet configuration management tool, written in Ruby. Puppet had a cleaner configuration language with a well-designed abstraction layer. Many principles were still based on Mark Burgess' initial ideas.

Puppet had a very well designed type/provider model that ensured modules were written to common standards, a feature that was trimmed from Ansible to make it easier to write modules.

Puppet would later implement optional predictable "ordering" features from Ansible as well as "Bolt" which had some resemblance to ad-hoc execution modes.

Both Puppet Forge and Chef (below) would have sites that offer a sharing-space for automation content that would create the desire for Ansible to have something similar (Ansible Galaxy), though Ansible would seek to have as much in the core product as possible so people would not have to hunt for the best community solutions.

In 2022, Puppet was bought by Perforce. Later, community concerns about the future of open-source Puppet led to the OpenVox continuation effort.

Chef, created by Adam Jacob, was a Puppet-like tool with a configuration language coded entirely in Ruby. Chef tended to appeal to developers and particularly Ruby shops, while Puppet continued to be slightly more popular with traditional IT management teams.

In 2020, Chef was bought by Progress Software. The CINC project emerged as a community distribution and continuation path for open-source Chef tooling.

Written in Python by Thomas S. Hatch, Salt Stack used a client-server strategy based around 0mq.

SaltStack was inspired in part by Func as Thomas was a Func user and possibly Cobbler’s adoption of YAML, and Red Hat’s early attempts to build systems management around message bus technology as discussed around lists like et-mgmt-tools at the time.

Salt was mostly not a factor in driving Ansible’s design choices, but was frequently discussed by Ansible users wanting faster configuration. In particular, Michael disliked that Salt’s language was not actually YAML, but a template that produced YAML. It could not be read by machines.

(Chef, being executable code, also could not be read easily by machines or at least not by non-Ruby programs, and Puppet needed to be read by its own parser)

In 2020, SaltStack was bought by VMware. In 2023, VMware was acquired by Broadcom.

Whatever specific configuration management tooling operations engineers encounter, ultimately the technology exists to enable business goals: short time-to-restore, auditable assurance of control, and low ratio of operators per managed systems.

Bill Baker of Microsoft came up with the distinction between treating servers as pets versus treating them like cattle ("from pets to cattle"). We give pets distinctive names and care for them as individuals; with cattle we refer to them by identification number and treat them as livestock. This term was popularized by Randy Bias of Cloudscaling, and was later widely propagated in cloud and operations communities including at CERN.

The connection with Ansible is practical, not origin-story. Ansible made the cattle model easier for traditional sysadmins: agentless over SSH, YAML playbooks, "make N machines look the same." Red Hat later sold that as the mindshift — from pets to cattle — with Ansible as how you get there (alongside Chef/Puppet, then containers/K8s for a more extreme "replace, don’t repair" model).

The integration of Ansible with "cowsay" was unrelated to this and completely just for fun, though perhaps the later association with Ansible and Durham, NC known as "The Bull City" (see also "Bull Durham") were also coincidental. Or were they?