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. 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:

  1. just import it from django.
  2. 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.

10 Responses to “DjangoCon and learning from Zope 2”

  1. Mark,

    Your talk seems very thought-provoking while at the same time flame-free… that must be a first, somewhere! :-)

    I’m sure your talk will help dispel the Django fanboy image in favour of the rest of us — Django users/hackers :-)

  2. You talk (and kinda look) like Seth Rogen. Great presentation, one of the best I’ve ever seen this year.

  3. 3Matt

    My feeling on django admin has been for a while that it could get me a certain way with roughing out an application, but knew inevitably I’d want to do things that couldn’t be done in it and at that point have to recode quite a lot. That seems to be the point you’re making with the z-shaped learning curve, although with frameworks that have this problem it’s not just about the learning curve – if you have to stop using (wholesale) the part of the framework that made that common stuff easy you have to reimplement a lot of things. The more powerful the admin interface becomes the further people will get in it before having a bigger redevelopment jolt when they reach its limits.

  4. Adrian, Carlitow: Thanks much!

    Matt: The django newforms-admin (now just admin) is much more flexible in it’s current form that the previous incarnation, but I expect there are plenty of places where it will be easier to do things manually, and this causes some z-shape curve.

    But — the fact is that very large number of things are possible via the django admin, and it really is important to have a very easy way to get started quickly. So, I wouldn’t give it up.

  5. I’ve seen the video. Hope django people think about don’t go the zope 2 way.

    May be also it’s time for we ( turbogearers 2 ) to rethink how can we attract more people , and may be we can hear something about it from django founders.


    Domingo Aguilera ( aka batok )

  6. Mark,

    It was great to meet you and chat during breakfast, and I enjoyed your talk. I’ve heard that some people didn’t take to the criticism too well — I believe it to be vital to the growth of frameworks like Django. Hopefully everyone realizes that Django has its weaknesses and talks like yours and Cal’s can result in addressing them.

  7. Dear Mark,

    i am very impressed by the positive and caring way you convey your concerns. I wished i were able to give “constructive advice / warnings” in such a kind and friendly way. The only critique one could have is that the talk could have been shorter (some repeating in the beginning of the talk). Or considered the given length you could have added some other exmaples, technical details.

    But nonetheless i am really humbled by your ability give friendly warnings.

    demugger – some german guy

  8. demugger,

    Actually, I think you’re doing a great job of providing some constructive feedback to me in the very same message that you talk about not being able to do it well. Perhaps you are better at it than you think ;)

  1. [...] place, or alternatively how it can stifle innovation in the future. This very much builds on parts one and two, which I blogged about over the last few [...]

  2. [...] happens when django developers discover WSGI? Mark Ramm wasn’t full of hot air when he talked about this at DjangoCon or blogged about it later. He was right, and I for one wish I had listened [...]

Comments are currently closed.