Here are the results from this week's Ansible survey on surveymonkey. I should say I'm really impressed with their tool, it was very easy to set up, and if anyone needs to run a survey, by all means check them out.
Since the project is still somewhat new (3 months), lots of users are in various degrees of stage and production adoption, and the survey caught a few users
still evaluating other tools. This is expected, but it seems most people are on their way towards rolling things out. Good to see things move this fast, which
can sometimes be hard in IT.
~70% of users want to get away (or not have to use) Puppet, and ~30% want to get away from Chef. As this adds up to 100%, and I doubt folks are using both, I think this is from users evaluating things answering questions, but it is good to know who our audience is. I personally don't think that means less people want to leave Chef, it's less of a systems administration tool than app config tool, so the balance is logical. From what I've read so far, many users view both tools as a huge time sink disproportionate to their importance in the IT space, and want something they can spend less time with. I agree.
About 15% of users are looking to ditch Fabric or Capistrano, or find options to avoid using them -- those shops already doing RPM packaging would have never had to use them anyway, for the most part 
About 50% of users are also looking to replace in-house infrastructure, some of which are fairly evolved.
In terms of other management tools people use, in house tooling was high on the list, and Nagios, Jenkins, and Puppet were common. at least one user was trying to move configuration out of kickstart.
As far as what people are using now, this is pretty interesting.
65% are using /usr/bin/ansible for ad-hoc tasks, with playbook adoption approaching 80%+, slightly more focused on provisioning and administration (general systems administration stuff) than specifically app rollout. I am glad to see playbooks being widely used. Users are split about half and half between the YAML and INI format inventory, it will be interesting to see if that balance changes now that the INI version can do a bit more, but I expect that to remain about the same. 50% of users are using templates, which I think is low because some people who were just learning were taking the survey and may just be copying files out so far. That's fine. Interestingly, about 25% of users write their own modules (that's great!) which means I think modules aren't too hard to develop, which was a major design goal. More surprisingly, about 25% of users are using some form of external inventory file and a little over 10% are using the Python API.
Since many people are still in early levels of Ansible rollout, it's not uncommon to be managing just 10 or 50 hosts, though some people also only have that many number of hosts. I think it's important to make tools that are important for folks with small data centers as well as big ones. There are definitely users that see themselves managing thousands of hosts as well, with extremely widely varying numbers of how many they want to manage in batch. The puppet/chef config management view of "remediate these constantly" doesn't seem to hold for everyone -- implying more of a rollout/updates kind of usage for some, but not all users.
Lots of good input on features, which I think are fair feature requests (not saying I'm going to implement them, but … patches accepted!). Some I like:
* more modules / facts
* contrib repo
* more examples / docs
* log changes when they happen
* be able to use last return results as variables
* set number of forks from playbacks
* including plays in playbooks just like we can include tasks and handlers
* mount module
* support list of yum and apt packages versus one task per package
* module to manage ssh authorized keys, etc
* be able to see the output from playbook actions (maybe)
* a sleep or wait until task of some kind
* a wget module of some kind
* keep on fighting to keep it simple (always!)
* speed (coming, 0.5!)
* reduced output mode for playbooks
* take md5sums before xferring large files
* various doc upgrades to be more example oriented (most coming for 0.4)
* upgrades to OS X support and OS X modules (would be awesome! let's do it)
Some I won't be implementing due to Ansible's goal of being a SIMPLE program, so let's just be clear on that:
* backup files when they change -- I have no interest in building a backup fileserver. If you want backups, there are GREAT tools for that, and I don't want to reinvent the wheel
* no op mode -- requires tons of changes to module implementations, and is usually a lie. This is more important in Puppet where you can't tell what a recipe is going to do. With Ansible, it should be much easier to tell.
* host aliases so I can tag a machine into a role -- this is EXACTLY what groups are for now
* augeas module -- this is totally the wrong way to manage systems
* GSS API based SSH -- won't happen unless libssh2 just happens to support it, because paramiko can't do it
* generic 'package' module -- package systems don't work the same, packages have different names, and this is a lossy abstraction that makes more work than it's worth.
Demographics!
Folks from all over the place, glad to see this! I'll have to share some Google Analytics numbers some time too.
So yeah, great data, thanks everyone. This presents a very good view of the current user base and what people are looking for, and will be extremely helpful for making future decisions. Thanks to all who submitted it!
--Michael