DRF has stated that they don't wish to be brought under the Django org, as they don't want their releases tied to Django's release timeline.

The value of the ecosystem is that each component does its part and each other component that has interaction with that component reaps the rewards. This leads to a natural evolution of components in the ecosystem (for instance, DRF evolved out of the need for better REST support, since projects like Tasty Pie were lacking thing that the rest of the ecosystem desired).

The idea that anything of value has to be nationalized and assimilated by the framework is a misguided effort to prevent chaos in the ecosystem, but the end result of trying to maintain order in an emergent ecosystem is usually disaster.

OT but gonational you asked a couple weeks back to tell my story. I finally got around to doing it: https://news.ycombinator.com/item?id=15762821

seconded, it's amazing how many people claim to make "REST APIs", but they fall so short in a lot of aspects. DRF makes it almost impossible if used correctly.

Could you elaborate what you mean? Looking at https://en.wikipedia.org/wiki/Representational_state_transfe... I would think that esp. ModelViewSets are pretty RESTful

The way I read the parent comment is that using DRF helps you building a truly RESTful API.

I think the "it" in the sentence:

> DRF makes it almost impossible if used correctly.

Refers to

> claim to make "REST APIs", but they fall so short in a lot of aspects

Yeah or at least brought it "in house" as a Django officially supported app, like Django Channels