There are a lot more basic reasons why Chandler was doomed irrespective of implementation language. The main thing I'd note (from reading Dreaming in Code plus a few blog posts, no real knowledge claimed) was that there was a lot of magical thinking -- open source software would negate Brooks Law, the project could be driven by quality rather than arbitrary dates, that a consensus process would produce innovation rather than mediocrity, that Python was a magic wand that would solve problems automatically, and so on.

As for the importance of scalability, http://www.ietf.org/internet-drafts/draft-iab-protocol-success-01.txt has an anlysis of why protocols (OK, not "projects", but maybe there's some analogies) succeed or fail. Scalability issues don't have much to do with initial success, even though hard scalability bounds do tend to limit "wild success". Factors most associated with initial success are " filling a real need, and being incrementally deployable. When there are competing proposals of comparable benefit and deployability, open specifications and code become significant success factors. Open source availability is initially more important than open spec maintenance." I don't think one could make the case that Chandler fufilled an unmet real world need (there are plenty of email/organizer programs already) or that organizations could incrementally deploy Chandler without disrupting their existing Outlook/Lotus/whatever installations, so those factors alone would tend to predict failure. Perhaps Chandler's open source would have made that a good tiebreaker *if* they had a product that solved real problems that users of the mainstream programs have, and if it Chandler could be incrementally deployed in an organization, but they never got anywhere near that bar.

Likewise, there's the frequent feature of failed projects that there was no clear goal to work for. For example, http://whydoeseverythingsuck.com/2008/01/rip-mitch-kapors-chandler.html argues that there is STILL no agreement on what the target market is.

Another blog post http://www.moskalyuk.com/blog/why-software-projects-fail-and-review-of-dreaming-in-code/1478 has a more extensive comparison between Chandler and traditional theories of software failure.
1. requirements changes made the early decision to use Zope problematic; instead of using Zope rather than reinvent its wheel, the Chandler developers had to become expert on Zope internals.
2. The team of superstars had trouble agreeing on a final architecture.
3. "Feature creep. One of the problems that Chandler had outright was its need to be revolutionary, which required a redesign every now and then".
4. "Code reusability within organization is sometimes pretty decent, ... Code reusability in the open source world is pretty poor."

So, I don't see Python's fingerprints on the knife that killed Chandler.

Mike Champion