Rumors of Chandler’s Death Are Greatly Exaggerated

I don’t usually like to blog about my client work, but in this case I’ll make an exception, since so many other people are blogging about it who don’t have any idea what they’re talking about.

A lot of these people, it seems, think that the Chandler project is dead, dying, or a “failure” of some kind.  And that’s simply not true.

Could the project have delivered more, in less time?  Sure, absolutely.

Does it have anything to do with the tools used?  Absolutely not.

Is the project dead?  Not at all.

Did it achieve its original goals?  No.

Is it likely to achieve its original goals?  I’m inclined to say no.

Does that matter?  Hardly!

Why?  Because in addition to creating a nice desktop application that:

• does online/offline calendars with overlays, recurrence and timezone support, date parsing, etc.
• has an extensible sharing framework that allows peer-to-peer or server sync with a variety of protocols, including CalDAV and gData
• allows plugins to extend the data model and include that data in peer and server sharing
• has an Eclipse-like plugin model allowing extenders and extendees with sophisticated UI extensibility

and a nice CalDAV server with an AJAX UI, the Chandler project has also funded (through paid developer time) a lot of open source libraries and tools, especially for Python.  Here’s a partial list of other projects that are or were funded by Chandler, in whole or in part:

• setuptools and EasyInstall
• Windmill
• PyLucene
• PyICU
• jcc
• zanshin
• simplegeneric
• vobject
• Trellis
• PEP 342 and related features of Python 2.5
• wxPython
• m2crypto

I’m sure I’ve missed some, even among the things that I personally worked on.

Anyway, the point is that between the client, server, and libraries, the Chandler project has produced quite a lot of working code, all of which would remain useful and beneficial to the community,  even if the organization had already been disbanded.

But it hasn’t disbanded.  On Tuesday I’ll be in San Francisco, meeting with the other members of the team, as we hash out our strategy for moving forward.  It is certainly possible that we’ll decide to just wrap up the outstanding work on bug fixes, quality improvement, and so on for the existing packages, and not try to continue past the end of this year.  It’s also possible that we’ll decide to push forward with new feature work, or focus on integrating our cool calendar/plugin platform with other open source applications.  Really, there are quite a few possibilities there.

What a lot of people outside OSAF don’t get about this is that the re-org is a good thing.  Don’t get me wrong – it’s not so good for the people who got laid off.  But for the project, it was a godsend.

See, out of all the junk that people have been writing for years and years about the project, almost nobody has actually seen what the real problem is, why Chandler didn’t get anywhere near the original, highly-ambitious goals.

Sure, people have pointed fingers at lots of things, and the idea that there was plenty of time and resources with no hard deadlines is often brought up as a culprit.  But that’s not quite right, either.

Having worked on, in, and around the project for about three years now, I can tell you quite simply what the problem was, and why the re-org fixes that problem.

There was no objective basis for decision-making.

It’s that simple, really.  Without an objective basis, there was no way to argue from anything except opinion, with nobody’s opinion being more important than anyone else’s.  There was no benevolent dictator but Mitch, and Mitch had already stopped being available day-to-day before I even started working for them.  (And I’ve heard that even when he was the benevolent dictator, he was perhaps sometimes a bit too benevolent – i.e., inclined to just let people choose their own direction/vision for what the project was going to be.)

Thus, there was no unified design, architecture, vision, nothing.  We had fiefdoms, not because anybody wanted to shut anybody else out, but because the natural response of a good developer faced with chaos is to find a way to organize the part that he or she can deal with.  It was easier for each person to just go and focus on the things he or she cared about, than to try to build consensus in the absence of an objective idea of what “success” was supposed be.

Now, you can point to inadequate specification, lack of constraints, and all sorts of other contributing factors as to why there was no objective criteria for success.  But to me, those aren’t really central.  You could have every single one of those things correct, for example, and still find some other way to create a culture that lacks objective criteria!

And it’s the lack of these common, objective criteria that does you in, regardless of why the criteria are lacking.  Without them, you can’t really have productive discussions or planning, whenever the necessary action crosses organizational boundaries.  (Since different sub-groups will have their own views and criteria, with no common criteria to sync against.)

Anyway, next week, we’re actually going to sit down and work on defining some objective criteria for the Chandler project as a whole, going forward.  Those criteria may not be what Mitch originally had in mind, and they may be considerably less ambitious.  But, my sincere hope is that they will be sufficiently objective, to allow us a chance at achieving them this year.

So, if and when the project is really dead, we’ll certainly say so.  In the meantime, IMO, the obituaries are more than a little premature.  We’re only pinin’ for some criteria, you see.  😉