# Of the Recent Pushes perhaps suggesting an Ansible-Contrib **URL:** \ **Category:** Ansible Project\ **Created:** [May 10, 2013, 9:03pm UTC](https://forum.ansible.com/t/of-the-recent-pushes-perhaps-suggesting-an-ansible-contrib/12792 "2013-05-10T21:03:26Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![rektide](https://avatars.discourse-cdn.com/v4/letter/r/a88e57/32.png) [@rektide](https://forum.ansible.com/u/rektide)\ **Post date:** [May 10, 2013, 9:03pm UTC](https://forum.ansible.com/t/of-the-recent-pushes-perhaps-suggesting-an-ansible-contrib/12792/1 "2013-05-10T21:03:26Z")
Greetings all, I've emailed you today regarding some current affairs- specifically, a rather sizable influx of new modules. So, good news! Just today we have: newrelic\_deployment notification module- [https://github.com/ansible/ansible/pull/2889](https://github.com/ansible/ansible/pull/2889) Campfire Notification Module- [https://github.com/ansible/ansible/pull/2888](https://github.com/ansible/ansible/pull/2888) flowdock notification module- [https://github.com/ansible/ansible/pull/2887](https://github.com/ansible/ansible/pull/2887) And also recently, IRC and MQTT notification modules- jpmens.net/2013/05/08/a-few-notification-modules-for-ansible/ This is fantastic, obviously. Yet I'm not sure how I feel about Ansible adopting the proprietary modules into core. I don't know where the line is drawn: there's already a growing list of proprietary 'cloud' modules in core. Obviously it's up to Michael to accept or deny modules, to say what does belong where, but I'm curious what others here think- what if any line do you see for where contrib modules need to made, versus allowing the module into core? I'd also point to ansible-examples as another reference point: I cannot speak for why it was done, but it's evidence of Ansible core growing to such a large extend that some pruning of what was 'core' was necessary: [https://github.com/ansible/ansible-examples](https://github.com/ansible/ansible-examples) Thanks all, just curious to hear how people come down on this one. -r ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [May 10, 2013, 9:34pm UTC](https://forum.ansible.com/t/of-the-recent-pushes-perhaps-suggesting-an-ansible-contrib/12792/2 "2013-05-10T21:34:51Z")
> This is fantastic, obviously. > > Yet I'm not sure how I feel about Ansible adopting the proprietary modules > into core. I don't know where the > line is drawn: there's already a growing list of proprietary 'cloud' > modules in core. I'm completely open to including SaaS modules in core, as the modules that talk to these services are open source. My goal for Ansible is "batteries included", representing what makes the most sense for everybody to have some really robust stuff we can all contribute to and use. SaaS is just a basic reality at this point, and I don't want ideology to impair effectiveness of operating with cloud tools. In fact, I want Ansible to be as good as possible in interplay with cloud environments. The guideline here is largely one of relevance -- things for popular services are going to be included, things that are very niche may require some traction before they get pulled in. We're probably not going to accept a module to iterface with "kittenwar", but hosted monitoring? Tons of people are using those services. I'd similarly take polished modules for VMware, and VMware is clearly proprietary -- but it's a platform people frequently deploy OSS solutions upon, so I see no reason to limit that. We want one strong logical place to find everything, without having to sift through to find something that's really good... and we get everyone to rally around those modules and make them more awesome, rather than having things fragmented along lots of different sources. This is what has made us very very successful up until this point, and we'll keep doing it. > Obviously it's up to Michael to accept or deny modules, to say what does > belong where, but I'm curious > what others here think- what if any line do you see for where contrib > modules need to made, versus allowing > the module into core? We've tried this in the past. It always comes down to one chokepoint and something isn't really well maintained, or worse, people submit things into contrib instead of core. I think core has been /quite/ successful and we've only bounced a few things. And modules that are not in core are welcome to submit them to the 'contrib' page of the doc site to show were they are, so people can find them. [http://ansible.cc/docs/contrib.html](http://ansible.cc/docs/contrib.html) > I'd also point to ansible-examples as another reference point: I cannot > speak for why it was done, but it's > evidence of Ansible core growing to such a large extend that some pruning > of what was 'core' was necessary: > [https://github.com/ansible/ansible-examples](https://github.com/ansible/ansible-examples) That's not why we did it actually, ansible-examples was there to provide an easy-to-browse example of complete playbooks for deploying applications, without people having to find it in the code tree, because users shouldn't have to be programmers and know how to dive through the code tree to find examples. We are definitely welcoming of new content for this repo, but are also going to audit it ways that would probably be considered mercilious, as these are the "new user, best practices" kind of examples and we want them to be super consistent and so on.