Getting features into Django

I wrote this post in 2013, more than 10 years ago. It may be very out of date, partially or totally incorrect. I may even no longer agree with this, or might approach things differently if I wrote this post today. I rarely edit posts after writing them, but if I have there'll be a note at the bottom about what I changed and why. If something in this post is actively harmful or dangerous please get in touch and I'll fix it.

Getting new features into Django isn’t easy. It’s that way for a reason — I spoke recently about why conservatism is a virtue — but it does happen. I’d like to do a better job explaining how we decide what goes in and what goes out, so here’s a lightly adapted version of something I posted on the mailing list this evening. It’s three things I look for when I’m trying to determine whether something is “right” for Django or not:

New features should maximize utility

One of the really high bars you have to clear when you propose new things for Django is the bar of utility. It’s not good enough to say that something’s a good idea. It’s not good enough to show that it solves your problem. It’s not even good enough to explain that it solves some bigger problem. You have to demonstrate that what you’re proposing is so useful that a sizable portion of people using Django would be excited by your new thing. One of Django’s real strengths is its stability, but the cost of that strength is that we say “no” a lot.

Let Django be Django

“But framework X does it like this” isn’t a particularly good argument for why Django should do something. Yes, it’s important to understand and follow what’s going on in the greater web world, and yes it’s important to beg, borrow, and steal good ideas. But you have to articulate why an idea is good for Django. After all, if we wanted to be just like Framework X, we’d all just be using Framework X.

In many ways the high quality of our competitors actually frees us up to be more skeptical of what we add to Django. We don’t need to be more like other frameworks because those other frameworks are generally great — if you like them, you should use them!

Instead, we should focus on doing the things we do well.

Flexibility trumps other arguments

So getting something into Django just because it’s neat or solves a problem is a hard road. It’s possible, and it happens, but there’s another kind of thing that gets into Django with a lot less struggle: features that improve flexibility.

Flexibility is a very important goal. Our philosophy of “sensible defaults” doesn’t mean that the default choice should be the only choice! It means that we should provide a reasonable default for most people, but then give people “escape hatches” when those defaults don’t quite work out.

If you can take a look at the feature you’re proposing, then back up a step or two, you’ll often find that the real root of your problem is a lack of flexibility. If you can find a way to solve that problem and introduce extension points such that a whole class of problems become trivially solvable, well… now we’re talking!