Understanding why Django's goals are not our goals for our web application
A while back I wrote about how Django's goals are probably not our goals for our web application, but at the time, I didn't have a succinct way of talking about why this was the case. Recently I wrote about a realization I'd come to about product code and utility code, where product code is used as part of delivering your business but utility code sits in the background doing other things. That realization gives me a better way to talk about Django and us.
Right from its beginning as a newspaper's publishing platform, Django has been product code and been used for product code. Probably most large sized Python projects (such as Twisted) see themselves this way and are often used this way, with people building big projects that support the business on top of them (after all, you rarely build big projects if you don't need them). As direct and indirect product code, Django is constantly evolving as the needs of people's businesses pull it in various directions. Django mostly has good API stability, but this stability is to enable people with product code that use Django to move faster.
Our Django based Unix account request handling system is not product code, it's utility code. The business rules and processes for authorizing new accounts are set by policies that are extremely stable, and the department doesn't operate in a way where we suddenly change the sort of accounts that we set up. How the department teaches and what sort of programs it offers have changed (although slowly), but that's as far as it goes.
(Looking back, there actually have been some modest policy changes about some aspects of incoming graduate students. We've patched around these in the account request system in some simple ways, which is actually an interesting story of flexibility and adaptation. But the fundamental ideas of who can have an account here and who decides that haven't changed. University departments are like that, and unlike businesses.)
As we've found out, basing utility code on top of product code is not a great path to happiness. This isn't really surprising since the two are pulling in different directions; utility code wants to be static, while product code needs to evolve as business activities do. Django has done a good job of being stable (in its API) despite that, but there is still work to keep up with it (beyond the shift to Python 3), and that work is not what utility code wants.