The Chandler Project Blog

I’m pleased to announce that the Chandler project has hit our Preview milestone! We now have public-beta quality releases of our products; we believe them to be full featured enough and stable enough for daily use. Check out a full overview of features (including screenshots and screencasts). Download Chandler Desktop, create an account on Chandler Hub. Check out the source. Get involved in the project, help us build a really great 1.0 release.

Chandler Desktop
We released 0.7.0.1 of the Chandler Desktop yesterday, September 10. (In the spirit of responding to user feedback quicky, we fixed a problem with the release found by a user before we made the announcement).

Chandler desktop adds a central dashboard for managing tasks, notes, events, and messages to the basic calendar functionality found in the 0.6 release. You can share calendars, task lists, messages and notes in collections that can hold whatever you choose to put in them, regardless of data type. The performance has improved greatly, the application has basic search functionality, and now there’s a way to to manage and resolve conflicts on shared data. You can collaborate on individual items via email with the ability to edit and update messages you’ve already received or sent. Although Chandler Preview is not meant to replace your email application, you can configure your IMAP account so that Chandler can see some messages from your regular mail client.

We’re currently planning a 0.7.1 release in about a month, to quickly iterate on the Preview release. We’ll make use of user feedback to identify problems and drive priorities.

Chandler Hub
We upgraded Chandler Hub to the 0.7.0 release of Chandler Server on August 27th.

The latest release of Chandler Hub also adds a dashboard for managing tasks (and other kinds of data) to basic web calendaring features. Friends and family can access shared collections from the web without having to create an account or log in. We’ve focused on workflows that let desktop users share data with others using the web; this release is a major step towards realizing the full Chandler vision on the web as well as the desktop.

We’ll be upgrading the service with small fixes on a weekly basis for the next month or so, fixing minor glitches and adding support for Safari.

Chandler Server
The Chandler Server 0.7.0 release is available for download as a ready-to-run bundle. We’ll be creating 0.7.x releases as we improve the Hub service. In parallel, we’re working on a 0.8 release that is focused on interoperability with other calendar applications and services such as iCal, Google Calendar and Evolution.

Try out Chandler
We believe you can now feel confident putting your data in Chandler. We have migration features to make upgrading easier, and will do our best to support people if they run into problems. (The chandler-users@osafoundation.org mailing list is a great forum for support). These releases do have some bugs and rough edges, so Chandler might not yet be appropriate for mission critical uses. We are using the desktop and hub internally day to day for our office calendar, personal calendars, personal project management, and several small group task lists. We hope you’ll join us using Chandler — let us know how you like it! We’ll use your feedback to make a better 1.0 release.

Get Involved
One of our goals for this Preview milestone is to grow outside involvement with the project. We want users to log bugs. We want designers to collaborate with us on ideas. We want developers to submit patches fixing bugs that annoy them, create desktop plugins with their favorite features, and write clients that take advantage of their data on the server. Check out how to get involved.

The Chandler Project is running an open service named Chandler Hub. Or at least, that’s what we’ve been telling ourselves.

The term “open service” does not have the clear definitions and history of its cousins “open source” and “free software“. We’re trying to figure out, just like everyone else, what it means to be an open service.

There has been a recent surge of chatter about “open services“. The current focus seems to have two branches: 1) attempts to define the term “open service” and 2) discussion of the impact of closed services to the larger Internet public good. This surge was probably triggered by Luis Villa’s recent work for the GNOME Online Desktop project. Luis takes care to catalog excellent references to earlier work as well. There’s a healthy conversation on the Open Knowledge Foundation’s okfn-discuss mailing list, where Rufus Pollack just posted a draft of an open service definition.

How the new titans of web services approach the openness of their offerings has an importance it did not have five years ago. Tim O’Reilly has promoted the view:

…the fundamental challenge of the Web 2.0 era may not be free software but free data, and the right of users to view, delete, modify, or freely transfer to a competing service the data that is stored about them in centralized databases…

OSAF (the Open Source Applications Foundation) with its Chandler Project and related hosted service Chandler Hub, seems positioned within both these areas: free/open software as well as free/open data. The ideals of freedoms and the public good are embedded in OSAF’s DNA and our self-standards are high. We would love to hear about areas we can improve.

A persistent criticism of many of the most popular web services is “Where’s the source?!” Whatever Google’s goals for openness are otherwise, no one realistically expects them to release their revenue-center source code. So people focus on the most important substitute: data access through open standards and open protocols. Groups like MoveMyData envision a generic tool for bulk download/upload of “your data” to sites like Flickr, YouTube, MySpace, and blogger, including your own web servers. Others dream that application-layer protocols like Atompub, CalDAV, or CardDAV, etc will be widely adopted and provide user freedoms through interoperability. Others worry about identity management, so links to treasured pictures online don’t go bad when a service changes operations (the broken URL problem).

The Chandler Hub service though, is the “full package”, multiple open apis for data and fully open source. (We have not quite solved the broken URL problem though.) The Hub is a straight install of Cosmo (the Chandler Server). Cosmo is an Apache 2-licensed open source “PIM sharing server” with a built-in web UI. Coupled with consumer-friendly terms of service, we have the makings of a fully-open hosted service.

OSAF, a non-profit organization, did not build Cosmo specifically to run a service; the original thought was that workgroups might run their own (like SMTP and web servers) and that they would form a loose network of cooperating servers. (The original Chandler vision was even framed in terms of true peer-to-peer, similar to Kragen Sitaker’s 2006 proposal for how to achieve open services).

As OSAF approached its Preview launch, it seemed clear that running a free service, providing easy sharing, synchronization, and a web interface was an important enabler for people trying out the Chandler Project. Some people will not have access to a private server, so without a low-hassle (and free-to-use) service, they would be blocked from using some parts of the Chandler Project.

Whatever the history, we find ourselves today launching a remarkably open service. Do we measure up to emerging definitions of open services?

Villa’s model for open services asks for the full package, source code included. It contains three preconditions:

1. data access (ability to retrieve data in open formats)
2. source access (ability to interact with your data locally once retrieved)
3. hardware access (ability to run on various sized-hardware)

and three rights: use, modify, redistribute.

Users of Chandler Hub have full data access via multiple open standard protocols (Atompub, CalDAV, and Webcal). Full source access available in OSAF’s public subversion repository and hardware access spans from laptops through large, clustered servers. Even our admin scripts and runbook are available.

So it seems fair to say that Chandler Hub rates well on Villa’s preconditions for an open service. Huzzah!

How we’re judged for the three rights of use, modify, and redistribute should depend on our exact and our adherence to those terms. We want to provide every consumer right expected in this area.

The issues in crafting an open terms of service are trickier than they appear: while you own your data, you can’t be mad at us if we “break your stuff” if there were say a server corruption or downtime. It turns out you actually need to grant the service important rights (store, transmit, etc), not the other way around. Also, when you share an item with others where you both have a right to edit, who has a right to delete it later? Some open service definitions expect community-generated data to be licensed under say the Creative Commons licenses, how does that apply to what Chandler Project is doing (with shared, but possibly private data)?

It turns out, that while drafting this post about open services, the Chandler Project just posted our first public terms of service and privacy policy. Experience suggests that there will be at least a couple of places where we did not write down what we actually meant. We’ll need a longer track record before we can be judged on our implementation of our terms, but we encourage you to let us know how our terms of service document looks, how the privacy policy looks, and how you think we’re doing on this critical dimension of an open service.

So there’s our claim: we’re running an open service, providing both open data and open source, backed by a non-profit motivation and consumer-friendly terms. We’d like to accomplish a few things here:

• Get community feedback on our terms of service and privacy policy
• Highlight the importance of the other end of the browser connection in Mozilla’s vision of the Open Web
• Have people working on “open service” definitions consider how the Chandler Hub ranks on their openness scales
• Encourage open service definitions to address further the thorny problem of appropriate terms of service
• Plug the Chandler Hub service. Check out our system and tell us what you think!

Thanks in advance for any feedback you can provide and also thanks for your interest in the Chandler Project!

Mitchell Baker started a conversation about the future of email at Mozilla, looking for people to participate in “a new vision of mail”. OSAF should be engaging in this conversation, looking for ways to collaborate with Mozilla.

We’ve been looking at email as an important part of the Chandler project. Our approach has been to design applications around user problems and goals, in particular for informal groups working together. Our starting point was the observation that people use their Inbox as their task list. Another observation: calendaring is fundamental to task management; integration of messaging with calendaring makes a lot of sense with user workflows. We think that people will benefit from integrating email, tasks, calendar, contacts and other related information in one application, instead of having to do the work of patching together information across software tools, protocols and data formats. We’ve observed people collaborating on shared problems with email; we think there are huge gains to be made by converging personal communication and group collaboration. Email protocols are not the only route for communication; social networking and other messaging paradigms are other important areas to explore.

The Chandler team is currently working on a Preview release expected by the end of August: a usable version of the desktop application, rich web application, and server. We’ll also launch our free hosted service, Chandler Hub (an instance of Chandler Server).

Chandler Desktop will not be a full email client in the Preview release, but great email support is important to our full vision. Our research shows that many people sit in their email client all day as they try and manage their personal information and work on projects with others. Chandler uses email protocols for “sharing” items (calendar events, notes, tasks). It also has enough basic email functionality to allow users to get email into Chandler to manage a task list and calendar, but as a complement to an email client. Filling out Chandler to be a full email client is one of our options for a 1.0 release.

If you want more information about Chandler ideas, you can read the latest draft of our vision document or explore our wiki. A user guide and screencasts will be showing up as well. You can also experience Chandler in action by downloading the desktop, server, and/or creating a free account on Chandler Hub. Even though we haven’t released Preview yet, the recent desktop checkpoints are usable (modulo a few bugs) as is the previous release of the server (it doesn’t have the full Preview feature set). We use it internally to share group task lists and manage an office calendar.

The Chandler team is focused on getting our Preview release out, so we’re pretty busy through August. We anticipate getting interesting feedback from Preview and we’re going to let that guide our next steps.

I’m not yet sure where a collaboration with Mozilla would lead or what it would mean, but I think we’re looking at a similar problem space and it makes sense to see if we can forge a common path and combine resources. We offer a perspective on the problem, a server and a desktop application, and a team of people who are excited about doing creative things with personal information management (including email). Once we have Preview out, I intend for OSAF to participate actively in the conversation about email futures.

We’re closing in on our Preview release, currently on target for launch in late August.

Hub (hub.chandlerproject.org)

The service is running the 0.6.1.1 version of the server, and works well with desktop checkpoints. We maintain our OSAF office calendar on the hub; several OSAF’ers are now using desktop checkpoints with the service to manage shared task lists.

Desktop
The desktop team has hit the code complete deadline for 0.7, and is closing in on Zero Bug Release.

You can download the latest checkpoint now and and give it a spin. It is more stable than the last alpha release or than the 0.6 release, and contains data migration features for upgrades.

Server
The server team hit feature complete for its 0.7 release, and is busy testing and fixing bugs. Upgrading the hub to use the 0.7 version of the server will determine the launch date.

Website and Wiki
We’ve improved our web presence and cleaned up our wiki (though we still have a little work to do before launch). We’re also working on end user documentation.

• http://www.osafoundation.org/
• http://chandlerproject.org/
• http://chandlerproject.org/wikihome

The OSAF team has been busily focusing on our “Preview” releases — functional products that are interesting enough for people to try out and give us meaningful feedback. (”Preview” will not be 1.0 — more like a usable public beta). Our original goal was to have these releases ready this month — we’ve adjusted our schedule to June. The countdown to Preview is tracked on our wiki.

Help us!

If you are adventurous and want to help out the project, we’d love to have people trying out the desktop application and the web application even before we get to Preview. Find bugs and help us make it better! Join the users list, download the latest checkpoint of the desktop application, or check out the web application.

Branding

Chandler was originally a code name for the desktop application. After careful consideration, we decided to use the name for the whole group of products (the desktop application, the online service and the server that runs the service). We’ve chosen a domain name (chandlerproject.org), and we’re working on a new logo. We’re also cleaning up our wiki and our websites as we near Preview. We discuss this work on the general mailing list.

Chandler Desktop

The desktop project hit a feature complete milestone on April 9. New features include recurrence and auto-triage of items in the dashboard, editing and updating items via email, Chandler IMAP folders, context menus, a new sharing format, conflict management, and data migration features. The team is working on performance now, and will spend many weeks after that fixing bugs.

Chandler Server (Cosmo)

“Chandler Server” is our new name for Cosmo. The 0.6 release of Chandler server was described in an earlier post. The server team is currently wrapping up the 0.6.1 release, which implements a new sharing format for data exchange with the desktop application. The team has also started on the 0.7 release, which will allow users to view and edit shared tasks and events in a table.

Chandler Hub (osaf.us)

“Chandler Hub” is our new name for the online service hosted by OSAF, running Chandler server. The service is currently running the 0.6 version of the server. We plan on moving to 0.6.1 in a few weeks, and upgrading to 0.7 in June. Once we’re ready to “Launch” Preview, we’ll use our new domain name (chandlerproject.org).

Scott Rosenberg’s new book about OSAF’s first years comes out this month, titled Dreaming in Code. Scott is a friend of OSAF — he spent a lot of time in our office, hanging out in meetings as a sort of “embedded reporter”. I’m not going to comment on OSAF’s adventures during that time period — you can go read the book for yourself. Instead, I’ll give an update on what OSAF has been up to since Scott’s narrative leaves off, around the end of 2005. At that time, we had narrowed our focus to get a calendar working, cutting out many interesting features. Since then, we’ve made a lot of progress. We’ve added a Dashboard for managing other types of information (including tasks, notes, messages) and improved polish, performance and reliability. The Preview release around April 2007 (described below) should be a good release for people to try out Chandler and Cosmo for the first time.

Cosmo

The Cosmo project was just getting started at the end of Scott’s book.
Cosmo is currently both a web calendar and a server for sharing data. The Chandler desktop application uses the Cosmo server to share data; shared calendars can also be viewed and edited in a browser using a Cosmo URL. Eventually Cosmo’s web client will be as full featured as Chandler, supporting tasks and other types of information. Cosmo’s server implements several standard protocols, so data can be accessed from other clients as well (including Apple iCal and Mozilla Sunbird). One of the big changes at OSAF in the last year has been the increasing importance of the Cosmo project. We’ve been designing Chandler and Cosmo so that they can be used in tandem.

Using Chandler and Cosmo at OSAF

With the release of Chandler 0.6 in late 2005, we started using Chandler and Cosmo at OSAF. Chandler at 0.6 was pretty rough — but we got good feedback and made significant improvements. The most recent milestone, Chandler 0.7alpha4, runs much more quickly on the Intel Mac, has a more polished calendar, and has the first workable Dashboard for tasks and notes. Several of us at OSAF brave the rough edges and use Chandler for our calendaring on a daily basis. Mitch and his assistant Esther are currently using 0.7alpha4 to share a calendar.

Preview

We set a major goal for ourselves last year: GET USERS OUTSIDE OSAF! We’ve been focusing on a “Preview” release for Chandler and Cosmo that will be functional and interesting for end users. While Preview will not include everything we want to accomplish for a 1.0 release, it will provide a tangible, plausible promise of the fully-fledged application we’d like to build.

Setting this goal has been a key step in transitioning to a “ship it” mindset from a more chaotic big tent of interesting ideas. Once Preview is out we can start building a community, since we’ll have something real people can use to solve real problems.

It was important to us that the Preview release contain some of the features that we’ve been excited about from the beginning: “stamping” features to blend tasks, events and notes; and “triage” features to manage important information in one view. It was also important to coordinate Chandler and Cosmo designs. We set a goal of Q1 2007 — my current best guess is that we will hit Preview in early April. Feedback from users will shape the remaining work towards a 1.0 release.

Informal workgroup collaboration

Early in 2006, we did a gut check and reevaluated our priorities. From the beginning of the project we struggled with too many ambitious and sometimes competing goals. The end result of a prioritization exercise was a tighter focus around small workgroup collaboration. Note that we never aspired to be an “Outlook killer” — we’re more passionate about solving problems for informal groups than for enterprises.

To make decisions about the feature set for Preview, we used the technique of identifying target users and the workflows they would use to accomplish their goals. Our keystone user is a person who sits in Chandler every day, using the desktop app for projects and tasks, as well as calendaring. We refer to this type of user as a “Hub”. The Hub interacts with “Casual Collaborators” — people in the Hub’s workgroup who don’t run their life with a calendar and task list or people outside of the group. The Hub might send a URL to the Casual Collaborator, who can then use that URL to access a calendar or task list on Cosmo. An example scenario: individual contributors in a workgroup edit their PTO on a shared office calendar (via Cosmo), which is largely maintained by a project manager (using Chandler). More info on target users and the Preview feature set for Chandler and Cosmo can be found on our wiki.

osaf.us

We’re going to host Cosmo as a free service starting in March or April (when Preview is ready) . Small groups will be able to use the service to share calendars and task lists instead of running their own Cosmo server. Someday we’d like small workgroups to be able to run their own Cosmo server without much hassle, but that will require more work. Braver souls can download Cosmo and try it out, though.

CalDAV and interoperability

CalDAV is an emerging calendaring standard; Scott chronicles a bit of Lisa Dusseault’s involvement breathing life into CalDAV. Cosmo is a CalDAV server and Chandler is a CalDAV client. OSAF remains committed to supporting standards based interoperability — we test against other servers and clients at Calconnect events and fix bugs when we find them.

People

Several people mentioned in Scott’s book are no longer working with OSAF, including Andy Hertzfeld, Michael Toy, and Chao Lam. Lisa Dusseault moved on to focus on IETF work as an Area Director. Each of these people made significant positive contributions to the project. We have new talented developers and designers working on Cosmo and Chandler who don’t appear in the book, appear only briefly, or have taken on new roles. The current team deserves a lot credit for pulling Chandler and Cosmo together as healthy, productive projects. I’m pretty excited about both and am really looking forward to Preview.

Today OSAF released Chandler 0.6.1, an update to its “experimentally usable” calendar. This release fixes a number of bugs that prevented some of our users from downloading and experimenting with the application. The fixes addressed bugs preventing certain calendars from being imported, some sharing errors, and addressing a number of items that support the developer community. A more comprehensive summary and be found in the 0.6.1 Fixed Bugs wiki page.

About a year ago, the product team at OSAF adopted a planning technique we refer to as “stickie” planning. As it sounds, this involves listing product features onto post-it notes, mapping them onto a whiteboard and assigning them to a particular dot release in our product plan. The features are described are fairly coarse-grain. A stickie might be “calendar month view” or “email forward and reply”. We estimate the size of a “stickie unit” to be approximately one month of work for a developer. We realize that the scope of some features are considerably less than 1 “stickie” and some will be more but for planning at this level, it’s adequate to get a ballpark stake in the ground for our next release. It isn’t until we start to drill down and scope out the details that we can understand if some of these projects are larger or smaller, at which point, we return to the stickie board so to speak for another round of refinements.

More recently, we have taken this process one step further in an effort to use our stickies for a longer-term planning initiative. Our application pivots around distinct end-user workflows. Stickie planning around these workflows helps us ensure that our dot releases aren’t simply a bucket of features that may or may not be useful to anyone, but actually meet a coherent set of user needs. This coherent set of user needs can be described as a workflow track. Each of these tracks in turn has distinct stages of usability in the product. By mapping stickies to a track and a phase, we can articulate some notion of a product roadmap. So with a bit of html and css wizardry, what might this thing look like?

NOTE: Until we fix some bugs, this timeline is best viewed using Firefox.

Roadmap

This visual shows a snapshot of a possible path to get us to a usable Chandler 1.0. I say “possible” since we expect to tweak with this on a regular basis depending on how priorities change from release to release.

Across the top are the workflow areas we have identified so far: Calendar, Email, Dashboard, Dev Platform, Sharing/Collaboration, App Basics (a mix of infrastructure work and basic product gestalt).

Each of the colored boxes represents specific stage of feature area usability.

Embryonic: infrastructure in place with no UI
Initial: test UI
Plausible: user model is in place
Dogfood: testable user workflows
Usable: usable workflows for early-adopters

The sub items in each box list what features (stickies) we think we need in order to reach that stage of usability in a particular workflow track (ie. Plausible Sharing). For example, can we call Email plausible without forward and reply? Probably not.

Another benefit of stickie planning is that the graphical and easy-to-change layout allows us to group stickies in a variety of ways that help us answer questions and load balance. Are the different workflow tracks progressing at fairly comparable rates (even if they are at very different stages of usability)? Is work being distributed across the development team evenly? It also helps us recognize patterns and dependencies. In the past two releases, we’ve been able to finish x-number of stickies, what’s the likelihood that we will be able to accomplish more in future releases? Is there an upward trend in stickies across releases? Can we get to a usable Dashboard without first having at least Plausible Email? If not, how can we move these stages around so the features roll out in the right order?

So what’s next in the evolution of this process? We will continue managing our live “stickie” board, capturing a proposal at regular intervals and hope that we don’t run out of post-it-note colors to choose from.

Bear noticed the following:

Mike Taylor to everyone —

There is a subtle quirk in how the auto-link and the markdown plugins
are interacting: if you have a url at the *very end* of a paragraph,
the link will get mangled and the presentation of the wp page gets all
funky.

To work around this quirk you just need to place any character after
your link. A space, period, anything will do the trick.