• "For sharing collections, we are moving away from a P2P model to one requiring a WebDAV server"

• "We will introduce a WebDAV-based Chandler server hosting product"

• "Better Mozilla/OSAF collaboration & integration"

• involvement, perhaps, with The Calendaring and Scheduling Consortium

• the focus of the 0.5 Calendar “Dogfood” release is "Be able to perform basic individual and collaborative calendaring tasks within a small workgroup"

• "Deprecating Canoga as a release target - not targeting groups beyond early adopters"

• "Kibble Q4 2005 Early-adopter usable"

• "Usable, collaborative calendar app comes first"

• "Invest in extensibility, infrastructure and architecture intelligently" (Note to self: don't think of Chandler as the solution to all my problems in terms of personal repositories)

• "Leverage community to validate platform ('Developer Dogfood')"

• a list of what's deferred (see NotSoOutrageousQuestions for a fuller and more detailed list):

  • Full Contacts Management

  • Instant Messaging

  • Sharing Circle and Certificates

  • User-defined Attributes

  • Item Browser

  • IMAP folder reconciliation

  • Item versioning

• Calendar spec for 0.5: CalendarSpec: KibbleProposal

• "OSAF wants to push along CalDAV as a calendaring standard": Calendar Server Extensions for WebDAV (CalDAV)

The list of "Things we learned" is something for us at the Interactive University to take to heart:

• Underestimated cost of ambition

• Hard decisions about product strategy and focus could have been made earlier

• Proved harder to build engineering organization

• Cross-platform and rich clients are hard

• Build and integration work is non-trivial

I will want to better understand Chandler's current model for collections because we are dearly interested in learning from it in for our own SB work or building directly on Chandler's software. I will have to review ItemCollectionsProposal < Chandler < OSAF wiki