Kind of.

48 contributors total (Yes, Andrew is doing most) - https://github.com/andrewgodwin/channels/graphs/contributors

It sounds like it wasn't decided to keep 3rd party as much as decided not to not combine yet:

> The feedback I got during the proposal process for putting Channels into Django 1.10 (it did not get in before the deadline, but will still be developed as an external app with 1.10) was valuable; some of the more recent changes and work, such as backpressure and the local-and-remote Redis backend, are based on feedback from that process, and I imagine more tweaks will emerge as more things get deployed on Channels.

https://www.aeracode.org/2016/6/16/philosophy-channels/

You can still use Channels today in 1.8–1.10.

https://blog.heroku.com/in_deep_with_django_channels_the_fut...

This project is very much in the spotlight, was heavily discussed at PyCon, etc. I don't think it's going anywhere.

(Cynical mode engaged)

Here's why you shouldn't be jealous: https://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On...

There are still remote code execution and even SQL injection flaws being discovered in Rails.

The dreadful security record of Rails really seems like the elephant in the room.

Compare to Django https://www.cvedetails.com/product/18211/Djangoproject-Djang...

Channels will eventually be part of Django core; it just didn't make the 1.10 release.

https://groups.google.com/forum/#!topic/django-developers/QR...

It seems to be taking more of a South approach, and I really like this. Shake out conceptual issues, find an API that works well, iterate a bunch. Django release cadence is pretty slow, so having it simmer outside of it makes a ton of sense.

If it's a big hit like South was, it'll get rolled in and we won't have to immediately start deprecating things due to an un-tried design.