I'm going to put my blog on hiatus in order to focus more on internal OSAF issues.

So many of you have demonstrated huge interest in and support for Chandler, and I am incredibly appreciative for that. As the cheers of the crowd spur on the marathon runner, the encouragement and even the sometimes impatient anticipation of Chandler's well-wishers boosts our morale and helps us keep going.

We've already been at this quite a while, and it's evident there is yet a long way to go. There is an inevitable point in a project, and we have reached it, where the most important thing is to focus single-pointedly on execution in order to deliver on the potential there is so much excitement about. So this is precisely what I am going to do.

Every project and every entrepreneur has its weaknesses, and a leader who wants to create a great organization learns to cast an unbiased eye on himself and the undertaking as a whole to figure out how to improve in those areas that are holding back progress. There's a part of the story which is about what's working well and what isn't in the group, and a part of the story about how the leadership of the organization is and is not dealing effectively with the challenges. I aim to look unflinchingly at what I need to do personally, what I need to ask of others, what I need to let go of, and where I need help to get the overall pace of execution to move more quickly, which is the paramount goal. You'll forgive me if I don't reveal all the details in public -- at least not in real time. After all, transparency is not Reality TV.

So many things about OSAF have gone well so far. There is a great and carefully thought-out mission about bringing the open source model to applications development and thereby creating great software. There is an over-abundance of innovative new ideas about personal information management which we are crafting into an executable product design (at long last). We have a team which has many talented indiividuals who are committed to the project. We've even thought through a business model for sustainability. What remains is the sometimes unglamorous process building the complete team and orchestrating the complex software development process efficiently to realize the dreams we have created. It is to that end that I am now trying to turn my energies to.

Apologies for the long absence. I've been traveling extensively as well as dealing a spate of family matters and other non-OSAF matters. I appreciate the continuing thoughtful comments and many helpful hints about getting the most out of IS X apps and Mail.app in particular. I don't think I'm going to be able to respond individually, so I hope this collective thank you suffices.

At OSAF, a huge focus at present in on making a series of decisions about feature priorities for Canoga. There have been many "Sophie's Choice" moments about which features aren't going to make the cut and will have to be deferred. Ruthless focus on nailing down design decisions continues to be at the top of my list.

I'll be speaking at the SDForum at 6:00 on October 23 on "Ubiquitous Open Source: What Does It Mean for the Software Industry?". The event takes place at PARC (formerly Xerox PARC) in Palo Alto. Details here.

Discounted admission $10 in advance, $15 at the door, if you mention you're part of the OSAF community of interest.

On my 15" G4 Powerbook, editing a Word document in Times 12 requires zooming to 150% to make it legible to my demi-century plus eyes (with my cheaters – without them nothing less than 30 point is any good). Times is a nice font for printing and 12 points is a good size to print in. But zooming up causes the spacing between words on the screen to be truly screwed up, rendering the manuever useless after all. I was befuddled until I started playing with fonts at random and found that Verdana 12 has a reasonable size on screen, so I've switched to it.

Why are most of the fonts, like Times, too small to read at normal point size? Does it have anything to do with the increased number of dots per inch on modern screens? Was Verdana designed to overcome this problem? Oughtn't there be a real fix?

I've been using iCal as my principal calendar for a while now and have experimented with using its publish/subscribe and synchronization features.

iCal itself permits a calendar to be published, either to a .Mac account or WebDav server. In the case of the latter, it can be protected by a password. Once published, another client can access and download the calendar, either manually or on an automatic schedule (i.e. by subscription). Presumably the intent was to support publishing of calendars, e.g., sports teams or symphonies, such that people with an interest in the source could subscribe to the calendar to get its events automatically displayed on their own calendars. At the same time, while it has useful behavior for people who wish to share calendars with each other, which is a different use case and not, I suspect, the intended one, it also has a significant limitation.

One of the advantages of iCal's publish/subscribe feature is that it permits individual calendars to be shared. iCal itself supports having multiple calendars which can be overlaid onto a common display grid. So, for instance, Esther (my executive assistant) can maintain and publish my calendar, which I subscribe to. She also keeps her own calendar and does not publish it. She can see both her calendar and mine simultaneously, but I do not see hers, only mine, which is what I want. As far as this goes, that's great. The problem is that in the way Apple has done it, a calendar can have exactly one person with write access. I can read my calendar but I can't edit it. This proved to be unworkable.

Michael Toy told me that Apple's iSync program can be used to synchronize calendars via a .Mac account, so I tried it. iSync will synchronize not only iCal data but address books and Safari bookmarks. The presumed major use case is to synchronize data among several computers belonging to the same person, not to share calendars among a set of people. As with iCal's pub/sub, its usefulness for the latter purpose is mixed, excelling at something pub/sub doesn't do, but failing at something pub/sub does do.

In the iSync paradigm, one or more client computers register with the .Mac server. Once registered, client data is synchronized with the .Mac server, manually and/or automatically. Synchronization is a two way process, so participants can both read and write data. This is a key advantage over pub/sub. In practice, both Esther and I edit my calendar. I have not had a naturally occurring conflict, so my next experiment is to force a conflict to see what happens by changing the same event on two machines without allowing the first one to synchronize to the server and the server to propagate the change.

The disadvantage of iSync relative to pub/sub is that the unit of data synchronization is too coarse. It synchs all of the calendars (or none). So I get Esther's calendar, whether I want it or not. A system which combines the best of Apple's pub/sub and iSync would permit the selective sharing of calendars, address books, and other data sets, allowing read-only or read-write access (and of course do so in an elegant, simple fashion) would be a big step forward. As an added bonus, doing it without requiring involving a server would be a bonus.