People that are aware of OSAF are usually aware of Chandler, not as many are aware of Cosmo. Cosmo started its life as the sharing server for Chandler, but over time Cosmo is going to bring quite a few ideas from Chandler into a web based UI. Our goal is to have both rich desktop client and rich web client access to your Chandler data, so that you have a choice of whichever interface appeals to you the most. The Cosmo project is much younger than Chandler, so it is going to take some time to reach that goal.

Several weeks ago, we found ourselves in need of a new manager for the OSAF engineers working on the Cosmo project, and I agreed to take over those responsibilities. Lots of people who read this blog have talked to me about Chandler in the past, so I wanted you to be aware of what is happening with me and Chandler. You can keep talking to me (and any other contributor to the Chandler project) about Chandler, but you can also talk to me about Cosmo and stuff in the web space.

I also wanted to make you aware that we have two openings for people to work full time on Cosmo. The last time I posted about jobs at OSAF, we got PJE, who has helped tremendously on Chandler, so here I am again. Please use the link if you are interested.

As always, if you are looking to stay up to date on what is happening with Chandler and Cosmo, you should subscribe to one or more of our mailing lists.

I've just posted the details of OSAF's Summer of Code projects on the OSAF blog. If you are a college student looking for something to do this summer, I encourage you to check it it - hurry, the deadline is May 8. If you don't find an OSAF project that interests you, there are plenty of other organizations sponsoring projects. They definitely didn't have anything like this when I was in college...

Mitch Kapor has a new blog up. In addition to Chandler, Mitch is involved with a number of things, including Second Life and Foxmarks.

I've posted a Chandler - Quicksilver integration hack over at the OSAF group blog.

We released Chandler 0.6 today.

After spending lots of effort trying to build up all the application areas at once, we decided to put all of our effort into building out one area, so that people would have something that they could use. The area we decided to build out was the calendar, since there's a real need for a good calendar solution. So this is our first step into calendar land. This version doesn't have every feature that you'd like to see, but it's a good start. The new project web site has some screenshots and some Flash movies that demonstrate some of the features. Features of note include: the ability for two people to share the same calendar (both people can create and update events) via a CalDAV server and support for managing events in different time zones. OSAF is providing an experiment CalDAV service for people who want to kick the tires. This service is using Cosmo, our Java based CalDAV server. Cosmo is licensed under the Apache License, and uses Apache Jackrabbit. There are still some sharp edges, but we are going to start using this version of Chandler as our day to day calendar at OSAF.

On the platform side of things, we've completely done away with our old XML based mechanism for describing Chandler parcels (extensions) and switched over to a system that uses Python to do the same thing. We've spent some decent effort on developer documentation, and we ought to be ready for brave souls to try to write some parcels. There are few sample parcels included in the distribution, including a simple (and I do mean simple) RSS feed reader, an interface to Amazon wishlists, and an interface to Flickr.

As always, bugs, patches, comments, and questions to the Chandler design or development mailing lists.

OSAF is starting a group blog for all of our projects, including the Chandler Personal Information Manager, the Cosmo sharing/calendaring server, and the Scooby calendaring web application.

I hope that this will be a way for those of you who are interested in Chandler, Cosmo, and Scooby to keep up with what is happening with each of the projects.

I'm going to be in San Francisco next week from Monday through Friday. If you'd like to get together, leave a comment or send e-mail.

Yesterday we released version 0.5 of Chandler. The official announcement is here. Mitch's disclaimer about the suitability of 0.5 for end users is here.

0.5 was supposed to be done before PyCon, so that we could say "and everything that we're showing you can be done in the 0.5 drop". Obviously, we didn't make it in time for PyCon. If your are interested in finding out more about how to write a parcel, you can read our PyCon paper. We also have a tutorial that fills in some of the details that we didn't have time to cover for PyCon. Also, you can try out the parcels that were done at the PyCon sprints, which are in bear's subversion repository. There's some additional documentation that we know we need to do as a result of feedback from the sprints, so I'll post again when that information becomes available.

OSAF will be running a Chandler sprint at PyCon in about three weeks. The focus of the sprint is going to be writing parcels for Chandler. Chandler's end user functionality is built using parcels, so the parcels we do at the sprint (and any parcel, for that matter) will be using the same facilities that the "built-in" functionality uses.

A number of OSAF folks will be at PyCon, so this will be a good opportunity to learn your way around the system. We'll provide some tutorial documentation, and you'll be able to sit and talk a live person during the sprint. If you're interested in participating in the sprint enter your name on the sprint page, or send mail to the address there.

Also, if you are interested in PyLucene, Andi Vajda will be one of the OSAF'ers at the sprints, so there will be opportunities to do PyLucene stuff as well.

Update
We'll also be having a BOF session on Thursday the 24th at around 8AM.

I'll be in San Francisco starting next Monday (the 7th) through the end of CodeCon (Sunday the 13th). If you are interested in getting together, leave a comment or send mail.

[ via Chao's blog ]
For those of you following OSAF, News.com has an interview with Mitch Kapor. I learned a bit about the history of Mozilla and Mitch's involvement with Mozilla.org. One of the good things that I've gotten out of working at OSAF has been the chance to work closely with Mitchell Baker, and I'm glad that Mitch took the opportunity to point out her contributions to the project. I know that I've certainly learned a lot from working with her.

I spent the last two days attending the CalConnect.org meetings that were at the UW. I was filling in for Lisa, who took ill at the last minute. This was a good excuse for me to get caught up with what's been going on with the CalDAV spec. The folks that were testing CalDAV interoperability have achieved quite a bit, which is very exciting. I'm not going to steal their thunder, so you'll have to wait until the public test results are posted at CalConnect.org. If you are interested in the calendaring space, you should keep an eye on what's happening with CalConnect (of which OSAF is a member).

Elizabeth Grigg has questions about calendaring stuff:

One thing just from observing this Lightning / Mozilla spec page as well as the Chandler spec page: both projects are in an extraordinary low level of detail at the moment. There is virtually no high level thinking in the specs, which is perhaps fine for the task at hand. It doesn't help us outside observers, though. I would like to know, for both these projects, whether unseating Outlook is the cause celebre or is there something new for users in there somewhere.

As far as Chandler goes, we have a UI spec for the Calendar work we are doing for our 0.5 release (sometime in March). I'm not intimately involved with the calendaring stuff, so reading the spec is the best way to judge whether there will be something new for users there.

The other thing to know about our calendar work is that it will be based on CalDAV, a standard based on iCalendar and WebDAV. CalDAV looks like it is gaining momentum amongst calendar implementors, and if it gets sufficiently adopted, then the existence of interoperable clients and servers would definitely offer something to users: choice. The CalConnect consortium (of which OSAF and Mozilla are members) is working hard on improving interoperability amongst between calendars.

This week I went down to San Francisco to take part in a regular Chandler Westwood Advisory Council meeting. I finally got to meet Oren Sreebny in person. It seems to be an odd pattern that I have to take a trip somewhere in order to meet people that live in Washington State. It happened again at the Creative Commons party on Thursday (it was nice to actually be in the Bay Area and be able to attend). I met Matt May of the W3C, who also lives in Seattle. An odd thing. I did have a very nice time at the party. Not only did I get a chance to meet a few people that I've wanted to meet, I also learned a bit about the new Science Commons initiative. I'm glad that Creative Commons is branching out into this area. We need all the help we can get.

Today Jon Udell wrote about his experiences with the Mozilla calendar, which we've been using at home to maintain a family calendar between Julie's Thinkpad running Windows and my Powerbook (using iCal). We also had some discussion of iCalendar on the Seattle Python User's group mailing list this week. Lisa has already posted her comments on the way that Jon's desired scenario is in line with her goals for CalDAV (click for details on how to get involved).

I wanted to add one more tidbit of information. The WebDAV folks are working a searching mechanism called DASL, which is designed to support multiple query grammars. The basicsearch grammar defined in the DASL draft is (unsurprisingly relationally oriented) but there's no reason that you couldn't use XQuery as one of the grammars for DASL.

OSAF is looking for a server developer to work on WebDAV and (likely) CalDAV stuff. You'll probably be working on Slide, which means that the target language is Java, not Python.

This past Tuesday was my one year anniversary at OSAF. It has been a great experience for me, not only in the technical dimension but in the community dimension. Most of my involvement in the open source community was due to XML/Java stuff that I did at the ASF, and perhaps a little bit due to my involvement with pyblosxom. In the past year, I feel that I'm branching out into the Python community, and I'm looking forward to meeting lots more people as Chandler reaches a state of usability.

Last week when I was in the office, I had my review (it's nice to do that sort of thing in person). I only want to make one comment about the review (other than the fact that I'm not fired ;-)). The word blog/blogging appeared twice in my written review. This was both a surprise and not a surprise to me. Content from the blog occasionally comes up in discussion with folks in the office, and I do occasionally write about OSAF happenings. However, blogging per se, is not really a direct part of my job responsibilities. It is true that OSAF's organization culture places a high value on transparency (I mean, what other organization is posting its management level meeting minutes on a public wiki?), and the my blogging is a personal reflection of that value. But I'm not an OSAF blogger in the sense that Scoble is for Microsoft or Jeremy Zawodny has become for Yahoo. Since I do have some responsibilities for helping to incubate a Chandler community, it's not surprising that blogging might be viewed as a component of that, which it was. The other place where blogging appeared was in the part of the review where you get evaluated on learning about new technologies and keeping up in the field. This occurrence was the one that was surprising. Abstracting away from me, I think it's interesting that the contents of your blog could be used as input for your review, particularly for this sort of criteria. It's not like the blog is a daily diary of the work that I actually did (although from time to time I contemplate starting a second blog at OSAF to record some of that stuff -- right now we use wiki pages). I wonder what other ways blogging will be integrated into the natural flow of people's jobs.

In response to the semi-(in)famous description of life at Electronic Arts, Charles Miller posted a list of ways to create a good working environment for a programmer:

• An office with a door
• …and no phone
• A culture of asynchronous communication
• A fast workstation
• …and two monitors. You wouldn’t believe how much difference a second monitor makes
• …and their operating system of choice
• Good development tools.
• A fast Internet connection
• Snacks and drinks they don’t need to leave the office for
• A good-natured working environment
• Flexible working hours
• Tasks appropriate to their ability
• … and if at all possible, that they find interesting
• Investment (emotional or financial) in the end-product

According to this list, I'm doing pretty good. I have an office with a door, but I do have a phone (and an iSight). OSAF does have a culture of asynchronous communication - couldn't do open source any other way. I don't have a fast workstation, but that's because PowerBook G5's don't exist. But, I do have two displays and Mac OS X, my current workstation OS of choice. I have the best tools that you can get for dealing with Python, and a shiny new fast connection. I have 3 meals a day in the office (at home) and the OSAF San Francisco offices are the best in my career for snacks/drinks, etc. Working hours are flexible, the tasks are doable and interesting, and I have a bunch of investment in both the final product, the organization and its culture, and my co-workers.

Not bad for my first year.

We're not subscribers to Netflix, but I like their notion of an "interest queue". In addition to the queue, there's what I'll call you interest working set, which is 3 DVDs. When you return an item from working set, you get the next item from the queue. I'd love to have a queue like this for books, and I'd also like to be able to specify whether queue requests get satisfied via my local library or via Amazon (or your favorite book retailer)

I love books, and I could quite possibly spend the entire rest of my life reading interesting books. When I was younger, I used to just buy books and have huge piles of them lying all over the place. Actually one of Julie's favorite statistics about me is that when we moved from the East Coast to the West Coast (courtesy of Taligent), the movers came and boxed up 57 boxes of books. A fair number of those are still in our garage, and as I've gotten older, I've taken to relying on libraries for as many books as possible. I've also taken advantage of Amazon's integration of used books, to purchase as many used books as possible.

In an ideal book lover's world, I could easily punch books into my book interest queue (I suppose my Amazon wishlist fills this role, except that it's not a queue), and the queue would first try to check the book out of the library for me. If that failed, it would try to get a used copy in good condition, and only after exhausting these two options would it order a brand new copy (it would have to ask first).

I suppose that this would be a great addition to a Getting Things Done workflow application...

I'll be down in San Francisco from Nov 1 through Nov 4 for a visit to the OSAF home office. The days are pretty full, but I have a few evenings free, so if people are interested in getting together, leave a comment or send e-mail.