DjangoCon and learning from Zope 2
DjangoCon was a lot of fun. I think Jacob, Adrian, Malcom, and James are a lot of fun to hang out with, and I like them a lot — so it was good to get to see them all. 
I was a bit nerve-wracked about my talk which was hard to write and hard to present, so I missed out on some good times by being too preoccupied.
A TurboGears Guy talks about what Django can learn from Zope
The talk itself was first thing in the morning on after the official gathering at the bar on the previous evening, and I was asked to talk a bit about how django fit into the python web ecosystem, and how things could be better.
My goal with the talk was to shake things up a bit, and hopefully to encourage lots more cross-talk and cross pollination between Django and the rest of the python web developer community.
There is a lot to be admired in Django, and a lot we can learn from them. And at the same time, Ben Bangert, Mike Bayer, Ian Bicking, Armin Ronacher, and many, many others have been doing great things outside of django, which it would be awesome if Django users took on.
I thought the talk was well received, and Simon Wilison filed several tickets in django’s track during the talk, and I had lots of good conversations with folks after the talk was over.
But now that it’s out on YouTube, there seems to be a few people getting riled up about the talk.
I think discussion is good, and people have been saying that it’s hard to watch a 50 min. talk. So I’m going to quickly summarize a couple of points from the talk, and open up some discussion here if people want to do it.
Basically the talk is three 10-12 min talks followed by 10 minutes of QA. The first section is about Zope2 and learning from the mistakes of the past. The second is about how innovation works, and how Django fits into web-innovation in python. The third is about the future and a couple of possible suggestions for a couple of technical changes to Django that could improve things for everybody.
So, feel free to just watch the portions that you want.
Zope 2, history and not repeating the mistakes of the past
The first section is basically an argument that monolithic frameworks can lead to community fragmentation by increasing the cost of switching and by creating an attitude of “uninformed superiority” on both sides of the divide. This is among the lesions that can be learned from examining the history of Zope2.
I have a brief digression where I mention Zope’s z-shaped learning curve in this section which seems to have gathered some criticism. My point is that both through-the-web and the django admin have made getting started very easy, but require you to go back and relearn some stuff when it comes time t customize it beyond a certain point. There is lots of complexity in Zope2 that is avoided by Django, but still I think it’s pretty clear that there is a bit of similarity there. And some danger in the future if Django continues to grow in the wrong way. So, this was intended as a warning about a possible future, not as a critique of the present.
Dependency charts and Django’s “loose coupling”
Another digression in this section seems to have been been controversial. I put a couple of dependency diagrams into the talk the night before I gave it. I did this because I saw a couple things at the conference that made me think that Django developers didn’t really see what was happening in their framework.
I don’t want to be unfair to Django, but I very much thought that it’s important that Django cast of some of the complacency that seems to have grown up in the django community around the slogan “tightly integrated, but loosely coupled.” There’s a lot of great integration in Django, but I’m afraid some of the loose coupling seems to escape me. Take a look at this django dependency diagram. 
And I think you’ll agree that’s not exactly the definition of “loosely coupled.”
The diagram shows that there’s a lot going on inside of the Django package, and a lot of things look like they depend on one another. Someone suggested that they wanted to use the filesystem abstraction code from Django outside Django, and Adrian suggested two possible approaches:
- just import it from django.
- fork it to create a new package.
The first is hampered by the fact that it’s not at all clear as an outsider what importing one module from Django will drag into your application. A quick look at the dependency diagram here, was enough to make me realize that it was not trivial to find out exactly what will happen.
Don’t get me wrong, I think there are good things about the tightly integrated nature of Django. I just want it to be clear, that there is a trade-off, and there’s no way to magically get the benefits of both tight integration and loose coupling at the same time for free. And one of those trade-off’s is that Django can begin to become a bit of a closed system — good stuff can flow in from the outside world, but nothing flows out.
This too encourages the creation of a divide between non-django python web programmers and Djangonaughts.
OK, this has gone on plenty long enough. I’ll blog about parts 2 and 3 of my talk tomorrow.