It occurred to me not everyone is in on the reason for all the dog references of late, e.g.: We're making "dog food". We're doing a release called "Kibble".

Our office at 543 Howard St. in S.F. is dog-friendly by design. Besides the Labradoodles, Cosmo and Chandler (pictured, though not at the office in this shot), our canine office companions include Otto, Luna, Petunia, Siggie, Cujo, Arlo, and other guests.

How are we doing in getting useable software out sooner?

First, some good news: We’re reliably hitting a majority of our bi-weekly milestone goals, perhaps even two-thirds. A good start, room for improvement.

Developers feel like they know what they need to do and aren’t blocked from doing it. Distractions (anything getting in the way of writing code) seem at an acceptable level.

In thinking about incremental improvements to our process, we’ve reached a few decisions.

We will start creating something like functional specs for current feature implementation. Info on the wiki is too diffuse and in reality we rely on coordination through meetings. It’s working, but it could work better, and isn’t going to scale. We want a lightweight approach, i.e., no waterfall methodology here. We’ll start with some simple experiments and evolve it. We’ll write down enough with enough clarity so there is a written record of both the details of the design intent and development approach, analogous to architect’s drawings and construction documents. Sheila Mooney, who’s just joined as in product management will be playing a key role here.

We’re going to make the tracking of progress in two week milestones a little more crisp. No magic bullet, but the bi-weekly milestone review meeting Tuesdays at 4:00 takes on added importance.

We already know a major focus of the 0.5 release will be performance improvement in the repository.

We’re pruning target features from the initial release plan. I’ve urged Chao Lam, Chandler’s Product Manager, to consider focusing on defining a “kibble” release, at 0.7 or 0.8. It’s short of a 1.0 but still has the preponderance of features one needs for regular day-to-day work. It leaves us room to add more features to 1.0 if time permits, but does not compel us to. There will be a number of important features (for example, an integral IM client, a full-featured contact manager) but not crucial which likely are going to slip beyond both “Kibble” and 1.0. Again, watch the design and dev lists in the next few weeks for more details.

We’re getting real about having a “dog food for developers” plan which parallels the end user plan. That is, we’ll have specific goals (and non-goals) for what developers should be able to do with Chandler on a release by release basis. We’ll allocate resources to meet these goals, e.g. documentation work, and we’ll measure progress on a milestone by milestone basis. This is work in progress. Details to be published to the dev list and wiki as you would expect soon.

We’ve identified a few areas where we know we need to have a real plan in place but don’t yet have resources assigned or available to work on it.

-- level of “Kibble” support for PDA’s and smartphones
-- Interoperability with calendars etc.
-- i18n plan
-- user doc

Top two points will be part of the job of new product marketing manager, once hired.

Lisa Dusseault has an update on new developments in the world of calendar standards.

Lisa heads OSAF's Services Working Group and is a long-time participant and leader in IETF work.

I finally took the plunge and bought a Treo 600.

I'd been using AT&T for many years as my mobile phone service provider, despite the fact the reception in my house has always been less than marginal. I discovered that friends with Verizon service in S.F. actually had great reception in my house and elsewhere. When Verizon, the last major carrier to get on board, finally came out with Treo support last month, I took the plunge.

As soon as I get everything working, I will give up my four year old black and white Blackberry.

Now I'm facing the problem of getting up to speed on a new platform and I'm turning to you for help. Basic phone usage is no problem, but I have a short wish list of other things which none of the material which you get with the Treo shed any light on as far as I could tell. So if you have tips, favorite web sites, or specific recommendations please let me know either in a comment or via email. I trust you can figure out or get my email address.

I want to sync my calendar and contacts with iCal and the Macintosh address book, not using the Palm desktop, which is what the supplied software seems to do. to be honest, I haven't even put either of the CD's which came with it in the drive yet.

I'd like to get a good IMAP client for checking mail. Willing to pay if there is not a good free one.

Any recommendations on great headsets, car charger, other cool accessories, or sources of accessories.

An AIM client which will let me use my .Mac IM address on the Treo. The Treo AOL client doesn't like an ID like mkapor@mac.com , even though the AOL client for the Mac thinks it's ok.

Now we get more exotic.

What about ways to sync bookmarks with the Mac?

What about RSS readers?

Many, many thanks in advance.

In a comment, Paul Snively wrote:

This is a good acknowledgement, but you also overlooked the entire field of Process Group Communication systems as exemplified by http://www.cs.cornell.edu/Info/Projects/Ensemble and http://www.spread.org. Spread even already has Python bindings; see http://www.python.org/other/spread.

To be quite honest, it's been rather frustrating to watch the Chandler development process as it seems to be developing virtually everything other than the GUI framework from first principles rather than leveraging the work that's being done by other organizations, particularly with respect to RDF storage and query and reliable decentralized networking. I can't help but think that a good RQL implementation on top of e4Graph, Secure Spread for networking, and KeyNote for trust management would have freed the team up to have made even more progress than it has, by enabling them to focus on application-level issues rather than nitty-gritty infrastructure.

But please take that with a grain of salt; I've been doing software long enough to know how easy it is for folks like me to be back-seat drivers. :-)

I appreciate your frustration. With 20/20 hindsight, we would no doubt have made some decisions differently.

We tried hard in every single respect NOT to develop things from first principles. And, in fact, we are building on far more major open source components than wxWidgets for the GUI. Our repository is layered on top of Berkeley DB and dbxml. We are using the Twisted networking libraries, Lucene for full-text indexing, and OpenSSL for security.

We evaluated lots of other alternatives, as long-time followers of this project will be aware. In particular, we evaluated a variety of RDF stores and found them wanting in terms of performance, reliability, and overall suitability for our needs. Unfortunately, not enough had been done when we made our choice a couple of years ago to move RDF into the practical world of software engineering. One of the overriding requirements was that any infrastructure we adopted should be sufficiently robust and scalable (or sufficiently close that we felt the gap could be closed, especially if we gave it a nudge) as to stand alongside any high-quality, commercially successful proprietary alternative without the least embarrassment or excuse. It's a high bar.

That said, my PC-centric background, and the normal fallibilities of experience and judgment of all teams contributed to how we got where we are.

Even more than this, though, and an area where I'd really have to agree is that I didn't grasp the schedule impact of decision-making based on an unwillingness to compromise key requirements. If I had... well, that takes us into speculation about alternate universes.

Ray Ozzie correctly points out that Groove has solved the serverless coordination problem, including the subnet splitting problem. This is a notable oversight on my part, all the more so as Ray and I go back together 20 years. I was on the Groove board for many years and my Groove stock will ultimately benefit various non-profits I am associated with. So, mea culpa. I've been very focused on open source and working on Chandler. Groove's accomplishment in the peer-to-peer realm is significant.

We've changed our priorities for the network architecture we will use to support sharing and collaboration in Chandler. If you follow OSAF's work here or here, this won't come as a surprise, but as it's a pretty significant shift it's worthy of elaboration and broader discussion.

For small groups, the use of an Microsoft Exchange server to support group calendaring has always been burdensome, but it has been the best available (or least bad) choice in many cases. Exchange is designed to be deployed and supported in medium to large enterprises with dedicated IT personnel administering it. The motivation for Chandler came in part as I saw my wife's small consulting firm struggle with the use of Outlook and Exchange to support critical scheduling functions. I surmised that a serverless (or server optional) architecture could be used to coordinate calendars for small groups, and that became a cornerstone of the Chandler vision. My supposition wasn't based on actual experience with peer-to-peer approaches as much as an intuition, which turned out to be less than fully appropriate.

The long and short of it is that initially Chandler users will share collections of items such as calendars with each other via a WebDAV server. Apple uses a WebDAV-based server for its proprietary .Mac service. Lisa Dusseault, who manages the development group working on WebDAV here, is also a long-time IETF participant and author of a WebDAV book.

Initially, and for the first wave of bleeding edge Chandler adopters, OSAF will be hosting servers itself. From an end-user point of view, the goal is to make sharing data painless and transparent. We are working on a product plan for an open source WebDAV-based server which can be freely deployed and which will become a fundamental part of our offerings. More on this as it develops.

This server will evolve into the server contemplated for the Westwood release of Chandler, the one for higher education. One of the benefits of the new plan is that we have a more direct path to bringing Westwood into existence.

We are also looking at incorporating the server into the client software as an additional option. Assuming we can do this, then those Chandler users who do not want any dependence on an external server can share data with other users directly. There will likely be some limitations to this approach, as the client will have to be online in order to perform this function.

True peer-to-peer coordination without this and other limitations is something which I ruefully understand to be a difficult (some would say unsolved) problem. If you have a lot people all trying to coordinate and there is no central "source of truth", when there is a partial loss of connectivity (say it splits into two subnets each of which is fully connected within itself, but which are isolated from each other) it is a challenge to put Humpty Dumpty back together again and make sure everyone has the most current version of everything. While achieving this is still very much in the long-term Chandler vision, our emphasis on not trying to solve research problems and even more on making useable sooner rather than later (our "dog food" approach) made the choice clear, if painful.

It has also occurred to me there may be another overlooked opportunity here. I think I've unfairly maligned servers in the past. It's not the server I dislike, it's the idea that as an end user I am disempowered if the work I want to do depends on the administration of a piece of software I don't control, can't get access to, and plays by a different set of rules. The PC-era pioneer in me says, "get rid of it". Another approach might be, "tame it and make it serve me".

Electricity comes out of the plug in the wall reliably (in the developed nations). Landline telephones have reliable dial tone. Why can't we have utility-level connectivity for user data? And why can't it be open source? This is a big, ambitious vision, and it's not just about servers per se, but operational reliability as an overall system function (think Google with its hundred thousand servers) but maybe there's something here. More on this later too.

A learning: We wound up focusing on the client software first, not the network architecture. Having had my formative software design experiences in the era of stand-alone PC's, it was easy to repeat the pattern of paying more attention to what is going on on the local machine than to what is happening across the network. While the repository is network-aware, and, in fact, very early versions of Chandler supported a simple form of accessing items from a remote repository, I didn't fully appreciate until this year the importance of considering issues of network availability, reliability, and performance as first-rate issues in and of themselves. You're never too old to learn (or to admit mistakes).