timing @

     This is just a reminder that people on the project are human beings (at least I am, on this occasion) and that sometimes it helps to account for delays in technology development in terms of events in the lives of individual people. If folks out there have an impression that Chandler is in any way coming along slower than expected, then I would like to take some of the blame for the delay myself. Hey, better that you blame me than our technology approach.
     However, although there has been some actual delay, due to both redesign and personal matters, it's also possible we allowed interested observers to assume we were releasing source code sooner than we knew was possible, because we wanted to recalibrate our own ideas about what could be achieved, given the redesign we've been doing, before putting a public stake in the ground.
     It's not my job to give public disclosures on the topic of project schedules. But I'm happy to drop hints here and there based on my own activity, which I hope allows you to infer more reasonable ideas about schedule, so you have more accurate expectations. So the following paragraph describes what I have planned to say for awhile, which I think helps set the right tone for future schedule baselines imagined by observers.
     I have not yet written any code for Chandler. I have written no Python code. I have written no C++ code. I have not checked anything at all into the source code control system. I'm supposed to be developing the repository for storing Chandler's content, which has been described as one of the most important parts of the backend system. So if I haven't developed much of it yet, at the level of concrete code, then we are hardly at the point at which we can reveal source code in a first public release. However, I'm about to go into a mode where I think about little else besides reaching initial requirements for a first public release (that is, when I'm not thinking about moving).

release @

     At first we referred to our first publication of source code as "the January release". We continue to refer to it as the January release after we had already reached January and found ourselves spending a week after week in meetings to discuss repository and protocol redesign suited for our actual goals. Then we started to reminding ourselves to say "first public release" instead, but old habits died hard. We have an idea for when we want a first public release.
     But I'm not going to tell you when that is. Please do not infer when a release might happen from anything that I say on my weblog. Do not read between the lines. I am not hinting about when we will release. It will be sometime. You'll be told in unambiguous terms when we wish to announce a release date. Yes, I know a vague timeframe has already been discussed, but I won't add any detail to that.
     At my previous jobs where I was allowed to discuss technical matters in open public forums, I sometimes told people the single most prohibited disclosure (as a simple practical matter) was when something would happen. Making forward-looking comments and disclosing design issues ahead of time are both safe as long as one never says what date in the future will see technical features hit the light of day. If you ever say when, then naysayers turn this FUD (fear, uncertainty, and doubt) as soon as possible, and will typically distort the dates later to maximize the impact.
     Amusingly, even if you never announce dates, folks will make them up for you and then cite each other as authorities, so they can blame you later for not making their guessed dates, while attributing the dates to you.

Rys - osa