I have a friend and fellow member of the Python West Midlands group. Whenever, someone mentions Django, he asks the person "but is it stable?". This has been repeated so much that is has become a local in-joke. However, lets take the question seriously.

To explore this further, we need to ask what does stable mean? I.e. can we replace the word "stable" with something else to provide some more meaningful questions:

• Can Django handle traffic loads?
• Is Django actively maintained, i.e. are bugs being fixed?
• Will the Django API evolve in the most backwards compatible way possible?

Lets take these one at a time.

Traffic loads

Django's frequently-asked-questions says:

Is Django stable?

Yes. World Online has been using Django for more than three years. Sites built on Django have weathered traffic spikes of over one million hits an hour and a number of Slashdottings. Yes, it's quite stable.

The first sentence is a testimony, useful but not a direct answer. In the second sentence, 'stable' is used as in 'strong table', i.e. Django can handle a heavy load, (i.e traffic rather than physical objects).

It goes on to explain that Django has a "shared-nothing" approach, i.e. you can throw more servers directly at whatever bottleneck you have. If the database is the database, then you can add more hardware to the databases, if it is images the are the problem, you can add more hardware to the media servers, and so on.

Is Django maintained?

The next question is whether Django is actively maintained. One simplistic measure is to look at the bug database and see what is going on. In what follows I use "ticket" in the broadest sense, i.e. not just a confirmed code error, but also enhancement requests, invalid bugs and so on.

At time of writing, Django has 1092 open tickets, out of which, 311 are new and unreviewed, I would guess that half of these are valid problems, and half are not.

Meaning the other 781 open tickets have reviewed by someone at least once. Some have been triaged and are waiting to be worked on, some are already being worked on, some will have been closed wrongly and reopened.

In the last three years, 6047 Django tickets have been closed, we can break these down further:

A ticket being fixed is very useful, but a ticket being found to be not a problem or not Django's problem is still useful information, marginally useful perhaps, but still useful if you have that issue.

So Django is three years old, which is pretty new. In that time, they have closed 85% of tickets, while 10.6% of tickets are open but have been read, 4.4% are open and have never been read.

This seems competitive with similar open-source web frameworks:

The 'years' column represents how far the ticket tracker data goes back for, not necessarily the age of the project. There may also be sampling errors caused by differences in the ticket tracker software, or a project might have had a clear-out of closed tickets.

On the whole, it is all impressive stuff, all six open-source projects seem to be on top of things. One nice thing about Pylons is that, at the time of writing, it appears that all of the open tickets have been reviewed to some extent. Some other projects such as Django would benefit from more a few more triagers to review new tickets.

API

This is perhaps what my friend meant, i.e. if one makes a web application using Django in 2008, how much pain will it be for it to still work in 2013?

There is of course a balance to be struck between backwards compatibility on the one hand, and keeping the framework modern enough for meet the needs of today's web applications. It is a difficult balance.

As Joel Spolsky points out in How-Microsoft-Lost-the-API-War, if you change your API such that users of it have to learn new things or change software in any significant way, the risk is that the users of the API will instead decide this moment to jump to the next big thing.

On the other side, changing too slow is also a risk. Apart from people like me when I am feeling retro, does any one really create web applications of any complexity using only the CGI support in the Python standard library? The API has not changed much in the last half-decade which is good, but the standard Python CGI is lacking in any pre-built features so you have to do all the repetitive boilerplate yourself. Also CGI generally has no persistence or caching meaning that it is far more processor intensive.

I don't want to be mean, but all the cool things that people are actually using to make web applications in 2008, such as SQLAlchemy, Django and Pylons are outside the standard library and have very little chance of merging with the standard library. I am not going to mention Python Server Pages, (oh I did - d'oh).

So the balance between backwards compatibility and providing modern features that people want is the life-or-death question for a larger toolkit such as a web framework.

Django provide their answer in a webpage called API-stability, in this document, they explain what seems a reasonable compromise between backwards compatibility, and changes that are required to keep the framework both modern and secure.

Of course, the document is mere policy/propaganda and the real issue is whether they stick to it. However, Django is free software/open source and it is being used by a large number of people. If the Django developers change the API unnecessarily, people will vote with their feet and not upgrade and/or fork the API.

Django Development

So is Django stable? Well given what we looked at above, we can at least say that it does not seem any less stable than any other similar toolkit.

The philosophy of a traditional software application, often goes like this: there is a cycle, starting with the development window, followed by a code freeze, followed by stabilisation, followed by a release, followed by a new cycle.

The current fashion in the Django community is to develop sites using the SVN version of Django. This philosophy is that the mainline branch should be usable at all times, and the latest SVN revision is likely to be less buggy and more secure than previous revisions.

This approach is somewhat all or nothing; you decide yourself to become a web developer using Django and so commit yourself with keeping up with the state-of-the-art. Perhaps this is the only way for a toolkit of such complexity. This investment is perhaps less of an issue if Django becomes the mainstream way to make a web application in Python.

The Django developers do however plan on an eventual 1.0 release, their plans are nicely summarised on a wiki page called VersionOneFeatures. At Version 1.0, the toolkit will (in theory) have a fixed point. After that they plan to do the Pythonic thing of not breaking the API in one step. So if they want to introduce an incompatible change that requires code changes to the user's web application, they will provide a warning in the next release, and then make the incompatible change in the release after.

However, I imagine most people will continue tracking SVN. Since a person needs a certain level of technical skills to use Django at all, then they probably have enough skill to handle some minor API changes.

Stability is a process. Complex software is never finished, it just runs of money or becomes obsolete.

Your turn. What do you think? I would love to know your opinions?