The power of “no”

Last week, I wrote on Twitter:

Closed-source software gets worse with each release (Microsoft, Adobe, …). Open-source software gets better (OOo, Ubuntu, …). Discuss.

Much interesting discussion did ensue – mostly around the exceptions (Apple, Google).

However, I’m less interesting in the exceptions than I am in the general rule. Sure, you can find plenty of examples of commercial software that’s improving over time, and, yes, there’s plenty of open source software that suffers from bloat and creeping features. Still, it’s hard to ignore the trend: closed source software seems prone to featuritis, to bloatware, to a trend of more bullet points at the expense of elegance. Open source seems mostly immune to these pressures.

I see a simple explanation for this, best summed up in a single word:

“No.”

The Django team has recently emerged from a period of voting on features for the upcoming Django 1.2 release. What’s especially interesting in this context is the list of features we’re choosing not to focus on for the upcoming release. This list includes some biggies:

• Support for IBM’s DB2 database.
• Integration of the Django Debug Toolbar.
• Integration of South (the most popular schema migration library).

Can you imagine a commercial project, faced with pressure from within IBM itself, decided not to devote resources to DB2? That’s precisely the type of feature you need to list yourself as “Enterprise Ready,” and yet we decided not to focus on this feature right now [1].

Django Debug Toolbar is one of the most popular add-ons to Django – in fact, I’d go so far as to say that it’s basically a required tool in the professional Djangonaut’s toolbox. Including it out of the box in Django is a highly requested feature. But we left it out: the lead developer wants it to remain a separate project, so that’s that.

As for South, well… The lack of built-in schema migration might just be Django’s biggest weak spot right now, and South is, more and more, becoming the de facto standard Django solution. Again, though, the developers (both South’s developers and Django’s core team) felt that South would be better served by more time as a separate project where it can develop at its own pace. So it’s not a priority for Django 1.2. Simple as that.

Were Django a typical commercial project, I have no doubts this would have turned out quite differently. A manager, noticing that schema evolution was the #1 requested feature, would have listed it as a must-have for 1.2. A salesman would have promised a big potential client that 1.2 would ship with the debug toolbar. IBM would offer to help sell Django to its clients if we only included DB2 support.

Sure, developers would still have objected in the same way, but those objections would be overturned by management or marketing. Release dates slip while developers scurry to integrate not-quite-baked software… and hey presto, it’s Adobe® Django© CSX™.

Open source cleanly avoids these issues by letting technical voices have the last say. As a maintainer of Django, I spend a lot of my time saying “no,” and there’s no management above me to countermand those orders. There’s only a group of my peers, all concerned with technical quality over all else.