Of the Recent Pushes perhaps suggesting an Ansible-Contrib

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

Campfire Notification Module-
https://github.com/ansible/ansible/pull/2888

flowdock notification module-
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

Thanks all, just curious to hear how people come down on this one.
-r

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

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

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.