CIO Insight magazine have a good interview with Scott Rosenberg, who was involved in the Chandler project. In many ways it seems to me like a poster-boy for the Agile movement. If Chandler had been approached in a more agile manner they may not only have shipping code, but I think the shipping code would be, now, for a very different piece of software.
Chandler made quite a splash when the project was launched because the project lead was Mitch Kapoor; creator of Lotus 1-2-3, Notes and the ill-fated but ambitious Groovy, and one of the leading lights in software development. One of the key things in an open source project is the project lead and Mitch is a proper heavyweight. He attracted a lot of very good developers and the project got moving with quite a fanfare.
I remember when the Chandler project was announced. Back then it was a fantastic idea, although ambitious. I still think the idea has a lot of legs. The idea was to produce a Microsoft Outlook killer, but using good UI and engineering design techniques. If you analyse it, Outlook is a pretty terrible application. Most of its users have probably never even thought about it, but the application only barely satisfies common use cases, and those with a lot of laborious work on the part of the user. It is all most people have used though, and people tend not to be terribly introspective about their software.
Mozilla Thunderbird is just as bad, and even less ambitious than Outlook. As an email client, neither of them compares at all well with the power and features of mutt, for example. Mutt however takes ages to learn and is ultimately limited by the capabilities of a terminal.
So, Chandler was supposed to change all this. Bring the sensibilities of a spreadsheet (i.e. a thinly disguised programming environment) to Groupware. To be a Notes for the 21st Century. Satisfy the Real Needs of Groupware users.
This is a Hard Problem. It has all the features of a project that disappears up its own arse, just as Mozilla did. There is a huge scope for architecture with such a large problem, and so that’s what they did: Architecture. Just as Mozilla did. Even though they sensibly chose Python to develop Chandler (unlike C and the homegrown XUL for Mozilla), they indulged in huge amounts of Big Design Up Front, which means that the environment and probably the users are now well ahead of where Chandler was aiming.
Maybe, like the Mozilla project, it will suddenly emerge from obscurity to take over the world. They will have a much more difficult environment for launch than Mozilla did however. The browser incumbent, Internet Explorer, was so appallingly bad it made a very easy target. The incumbents for Chandler will not only be better but will be hosted, browser accessed applications — which provides a set of behaviours that Chandler will find it impossible to replicate.
All of this may not sound like a software problem, but instead a marketing problem. To call it that is to miss much of the point in the real difficulty in software development. The most intractable problem is not avoiding building buggy software. The problem is in building the software that people actually want.