That said, the framework is not a terrible choice, just not mine.
I think accusing the Django core as being incestuous attributes a lot more malice to what they say and do then is warranted. All communities have scaling issues, and all open source communities have growing pains.
The sad part about this is that people who didn't get "their thing" into core is going to use this as self-validation, even if the idea really was bad to begin with.
The examples you give are from communities that have for the most part learned how to deal with those issues (python itself especially, in the talk GvR is actually quoted as having reversed his position on specifically that point).
Communities tend to be one or more orders of magnitude larger than the core team of most projects, and to disregard such an enormous pool of talent is a loss. So what if 90% is junk, let the community sort it out and come to a consensus on which things deserve to be part of contrib or core, and then respect that decision, unless there are really earth shattering reasons not to.
It's growing pains - and even python-core, despite guido's recent change of mind, is still learning, and finding ways to reduce friction. Django core is listening, and will change. There's nothing much to worry about.
And if they don't, they die, and we move on (see, past python web frameworks, and other things which wander into the woods to die).
People were generally really nice in the community. Some of it may also be the more introverted characters attracted to python.
Also, I have lots of friends who are django fans and I hope that django improves on all these fronts. The character of a community is both hard to quantify and hard to change.
The rails community has grown so fast and been so open that it doesn't even seem to have a specific character, which is something I quite like about it.
Interesting observation. Ruby and Python do seem to attract somewhat different personality types. Functionally they're actually very similar.
Most of what is mentioned in this talk are not that much of an improvement, non-issues, or all around horrible ideas.
The fact is though there are major issues with the framework (not mentioned in this talk), and much of it is due to how things are being managed at the moment rather than a lack of ready, willing, and able contributors.
The ORM has quite a few failings. Granted I like the API, though the backend code is nothing short of a cluster-fuck.
The ORM also works quite well for what it does. It doesn't allow you to construct real SQL queries and non-existant objects, but that's it.
It's the restrictiveness compared to e.g. Jinja2 or Mako. With those engines, I can just drop in a Python function and be done with it; with Django template engine you end up writing tons of template tags for the simplest things. It's designed for a particular work environment (designers work on templates, so should not be allowed to do anything dangerous) that I've found to be quite rare in most projects.
> not for making queries like other templating systems
WTF ?
I won't be able to come back to you because it would be too inefficient doing something more advanced than that in the template layer. Because rather than write the python to write template syntax to be interpreted back into python, I simply wrote the logic in one-pass python in the view function. It's more direct, runs faster, and your templates are clearer to designers if you're working in a group project.