The Chandler Project Blog

Six months ago, I had to step away from the project unexpectedly due to a family crisis. I’ve really missed working with the team — I’m very proud of them for shipping a solid Chandler 1.0, web and desktop. I’m also so heartened to watch the successful transition to an all volunteer organization. OSAF is lucky to have such great people join the new board and user advisory group — I’m excited to see new energy come to the project. Thank you, Sheila, for stepping in when I needed to be away and keeping things on track!

I have been following the project even as I’ve been away, keeping up with the lists and the blog. When I have a little more free time and energy I’ll be looking for ways to help out — perhaps a bit of coding on Chandler 2.0. Looking forward to seeing what happens in the next phase of the project…

On Wednesday Nov 5th, I’ll be moving two OSAF/Chandler Project servers to our good friends at Hosted @ ISC.  The affected services include Chandler Hub, OSAF mail (such as mailing lists), and the iGoogle widget.  These servers will be on ISC’s gigabit connectivity and large UPSes so we’ll continue to get great infrastructure and ability to grow (particularly in bandwidth costs related to Chandler Hub usage) for free.  This is hugely important for our mission of delivering free and open productivity tools for groups.  Our thanks to ISC for their ongoing support, going on 8 years now.

The outage will last from about 9am to perhaps 2pm or so.  There won’t be any changes other than moving cities and IP addresses, but there may continue to be small problems after that that get fixed over a couple days.  Your patience is appreciated.  Please report any problems you have after the outage to the chandler-users mailing list and IRC channel.

I am very pleased to announce that Eugene Kim, Alex Russell and Andre Mueninghoff will be joining the OSAF board of directors. The Chandler project has undergone significant changes over the past year, starting with the restructuring of the organization in January. We’ve been working for some time now to form a new board, to inject the project with new energy and new ideas. You can read more in their bios below…
_______________________________________________________________________________________________

EUGENE KIM: Eugene is the cofounder and principal of Blue Oxen Associates, a think
tank/consultancy focused on improving collaboration. He has developed
collaborative strategies for a number of organizations, focusing
especially on inter-organizational collaboration and collaborative
learning. Past clients have included World Economic Forum, NASA,
Institute for International Education, and Socialtext.

Eugene’s research centers around identifying patterns of
high-performance collaboration across different domains. He is also a
thought leader in the collaborative tool space, focusing especially on
Wikis, digital identity, and usability. He most recently directed
computer pioneer Doug Engelbart’s HyperScope project.

In addition to his work at Blue Oxen Associates, Eugene serves on the
board of the Leadership Learning Community and the Open Source
Applications Foundation and on the advisory boards of Tomorrow Makers
and Dreamfish.

Previously, Eugene was the Senior Technical Editor at Dr. Dobb’s
Journal. He’s published numerous articles as well as one of the first
books on web application development. He received his A.B. in History
and Science from Harvard University.

Eugene’s thoughts on Chandler: I love Chandler for two reasons. First and foremost, as a tool,
Chandler is useful. It helps me stay organized, and it helps me
collaborate with others. Chandler fulfills a critical need that
prevents groups of all sizes from collaborating effectively.

Second, I love the people involved with the project. I’ve known Mimi
and Katie since they participated (and rocked) our first FLOSS
Usability Sprint three years ago, and I’ve enjoyed meeting the rest of
the team and members of the community since. Moreover, the way they
are incorporating user-centric design with open source development is
cutting-edge, and I believe that it will serve to be a model for many
projects to come.

I’m thrilled to be joining the OSAF board. I think it’s an exciting
time for the Chandler project, and I’m looking forward to being part
of the team.

ALEX RUSSELL: Alex is Director of R&D for SitePen, President of the Dojo Foundation,
and a founder and former project lead of the Dojo Toolkit. He contributes to
the CometD project and is a co-author of the Bayeux specification for Comet.
From ‘06 to ‘08, Alex served as a founding Steering Committee member of the
Open Ajax Alliance.

Before joining SitePen, Alex was a Senior Engineer at JotSpot and Informatica
where he helped build highly interactive web interfaces. His earlier Open
Source involvement included stints as editor of the OWASP Guide to Building
Secure Web Applications and primary author of the netWindows DHTML toolkit.

Alex’s thoughts on Chandler: The mission of Chandler inspired me the very first time I heard of the project. As Chandler has evolved and matured, I find that I’m delighted by the clear utility of the finished product. It takes a very level-headed organization to understand the large shifts from desktop to web that have taken place in the span of the project’s history, and Chandler Hub and Cosmo give me deep faith that the Chandler team is in sync with the needs of users.

ANDRE MUENINGHOFF: Andre is an IT Director experienced in software design and
development, and enterprise application management. He has led
off-shore, near-shore, and on-site teams using lean, agile-oriented
methodologies. In addition to supporting the open source software
movement, Andre invests his spare time in coaching FIRST LEGO League
(FLL) robotics teams.

Andre is a long time user and follower of the project and is a member of the Chandler User Advisory Group.

Andre’s thoughts on Chandler: What excites me is the commitment to the goal of having users be
involved actively in all phases of the development process, particularly
at the front-end of the process. The early goals for the Chandler
application held great promise. The 1.0 release delivers on many of
them, and foreshadows many more. The desktop application rearchitecture
work currently underway is expected to enable the project to be even
more responsive to evolving and new user requirements.
__________________________________________________________________________________

We have also recruited OSAF staffer Jared Rhine to join the board and I will replace Katie Parlante who is resigning her position. Katie will be following up with a blog post of her own. Long time board members Mitchell Baker and John Lilly will be moving on as well. We thank Mitchell and John for their support and involvement in the project over so many years and Katie for her leadership and contributions to the project in all areas of the organization.

We have accomplished a considerable amount over the past 10 months. We released Chandler 1.0, a “Note-to-Self Organizer” designed for personal and small-group task management and calendaring. Our 1.0 offering builds on what we released for Preview and shaped itself from a wide range of feedback we received over the past year. We not only worked on new features, fixing bugs and improving usability but we also spent considerable time on our marketing message and evangelizing how Chandler is useful through the many user stories that appeared on our blog. We introduced the Quick Entry and iPhone widgets to reach out to both the new users and the development community.

As of the end of November 2008, OSAF will be moving to a mostly all-volunteer organization. For this reason, we have been focusing on projects that will set up Chandler for this new phase. In addition to assembling a new board, we have put together a great User Advisory Group that will take on a prominent role supporting the needs of our existing and new users. Grant and Jeffrey have been moving forward with the re-architecture project which is central to building our developer community. They will be staying on staff for some time to see this project through. We have many volunteers who have been and will continue to contribute to the project on many levels. In addition to joining the board, Jared will continue to volunteer to run the Hub service. Mimi will continue to support the user community and help with design issues.

We have been planning for this transition for some time and look forward to all the unknowns and opportunities of this new era.

One common question about Chandler is: Are Chandler Items (Notes, Events, Messages, All of the Above) supposed to represent individual task items or projects? If they are individual tasks? How do you make a project? If they are projects, how do you split off individual tasks?

The real answer is: Neither…and Both. Chandler items are by design, ambiguous about whether they represent tasks or projects, because tasks and projects are in reality, ambiguous. Oftentimes what starts out as a neat line-item task can quickly spiral into a half-dozen issues to resolve, questions to answer, not to mention to-dos to do. Sometimes, Chandler notes are most useful simply as a way of keeping track of lists of individual tasks.

Jos Yule recently wrote into the Chandler-Users list describing how he uses Chandler items to keep track of lists: Bugs, Current Work and a Log.

---

I’ve been using Chandler successfully now since the 7.x release, and
have been quite happy.

I’m using it for both personal and business “stuff”, and i’m trying to
get a feel for how other might be using for Software Development.

Redmine is a web-based software development
tool, with issue tracking, milestones, message boards, wiki’s and
integrated version control tools. It really quite rocks. However, a lot
of the time i feel like it is over-kill for most of my projects. I like
the flexibility that Chandler gives me.

On one of my projects, I’m using the Hub to give access to some of the
projects notes to other stakeholders, coders, artist, audio guys, etc.
… What i’m doing is, in Chandler, i’ve got a collection, Project X,
which is where i keep all my notes related to that project. I then have
a “Project X Public” collection which is published to the Hub, where I
have dragged notes which are to be shared with other team members from
the private “Project X” collection. I’ve got a BUGS note, and a CURRENT
WORK note. This seems to be working so far, but i’m wondering what other
software devs do (if anything)? I haven’t had to get too granular so
far, ie. just a general BUGS note, but I figure that if I need to I can
create a new note for each important bug, and have that in the public
collection too… I’ve also got a LOG note where I record what I’ve been
working on…

Anyway, that’s what i’m doing… How about you?

Note The screenshots below do not include real data.

We are releasing a new Chandler Desktop, version 1.0.2, in order to address a couple of serious issues some users have reported. The following two bugs affect data export and reload:

• 12335 Total data loss on chandler startup – restore not possible
• 12353 Export to .chex fails

There is also a fix that addresses an interoperability problem that came up testing the
iPhone/iPhone Touch Quick Entry widget:

• 12381 Make eim lowercase all keys

You can download the app here,
or by using the “Check for Updates” feature in Chandler.

We are pleased to announce the formation of the Chandler Project User Advisory Group. Over the past 3-6 months, it’s become apparent to us (OSAF staff) that there is a lot of energy in the user community and that a more organized approach to harnessing that enthusiasm would do the project a lot of good.

Open source projects run the gamut when it comes to governance and decision-making. One of the challenges we face is ensuring that users continue to have a prominent voice as a volunteer developer community emerges around the re-architecture effort. The formation of the advisory group is a first step towards taking on that challenge.

So I am happy to say that 3 of our most active users on the users-list have agreed to form v.1 of the User Advisory Group. You probably know them from the list. Davor has been involved in the project for over 3 years. Andre, for over 2 years and Keith for a year and a half. Their contributions have ranged from providing user feedback to painstaking debugging and helping new users get started.

(I’ll hand it over to Davor, Andre and Keith to introduce themselves.)

DAVOR CUBRANIC (Vancouver, Canada)
I have always had interest in personal and group information management. Prior to Chandler, after much searching I had settled on EccoPro as my PIM, and was very happy with its speed and power. Unfortunately, it was also Windows-only, closed-source, abandoned by its developer, and wasn’t designed for syncing outside the LAN. Just around the time that the syncing was starting to become an issue for me (since I needed to maintain my calendar/pile-of-info both from home and office), Chandler started to be stable and capable enough to be used on a day-to-day basis. I slowly left Ecco behind for everything except as a legacy reference store, and—just like Keith—wouldn’t want to live without Chandler any more.

What excites me about the project.
At a project level, it has to be Chandler’s openess and its willingness to explore new forms of personal and small-group information management and collaboration. At a technical level, it’s both the basic idea of creating a distributed system for flexible information management, and the opportunity to see it (re)implemented using some very interesting programming techniques (viz. the Trellis framework, which forms the foundation of the rearchitecture branch).

ANDRE MUENINGHOFF (New Jersey, United States)
As did many past and present users of the venerable Lotus Agenda
(MS-DOS) application, several years ago while searching the web for a worthy replacement, I found the Chandler Project. I was also browsing for new PIM tools to use in my implementation of the (then new) Getting Things Done (GTD) methodology. Given the promise of the early roadmaps for the Chandler application, the ground-breaking thinking, and the warm welcome and support by the Chandler team to newcomers and neophytes, I became and remain hooked as a user and a contributor. As is well documented, the project has had many successes along with its share of challenges. The 1.0 release is an important and satisfying milestone for users. With the help of an active user community, it is my hope that the 1.0 release will be able to be marked as the “end of the beginning” of the Chandler Project.

What excites me about the project.
The early goals for the Chandler application held great promise. The 1.0 release delivers on many of them, and foreshadows many more. Chandler delivers ground-breaking thinking about managing personal workflows, sharing calendars, and small-group collaboration on top of cross-platform support, Web 2.0 tools, and an extensible architecture. Maybe one day Chandler will be able to pick up where Lotus Agenda left off and also sync bidirectionally with my Palm handheld. What excites me is the continued commitment to ensuring users are involved in the front-end of this open source project as the transition to an all volunteer organization is completed.

KEITH WINSOR (Norfolk, England)
Having been a Palm user for years, I found myself looking for a replacement with a future. I had spent years searching for the ultimate PIM, without success. I’d found Chandler some time before and kept half an eye on it, even though at the time it was little more than vapourware. Starting my own business meant I was on the lookout for a way of sharing a PIM and everything just fell into place. I’d be the first to admit there are still one or two rough edges, but I can’t imagine being without Chandler: it just sort of works the way I do.

What excites me about the project.
Chandler seems to me to be the ‘openest’ of open source projects. It genuinely seems that the future direction of Chandler will be driven by the user community and I’m very excited at the prospect of playing a role, however small, in the evolution. It’s already very usable: who knows where it could go from here?

---

We will be working out the scope of roles and responsibilities individual members of the group will take on in the coming weeks. Here is an initial brainstorm of project areas.

A few projects we’d like to start right away include:

• Creating a users web forum. – Davor will be sending out a proposal for comments in the next week.
• Crafting an advisory group “charter”. – To be worked out publicly on the Users-List over the next month.
• Recruiting more members! – Ongoing.

One of the areas we expect to work on continuously is the issue of governance. What “rights and responsibilities” does the advisory group have with respect to volunteers who are writing code or contributing in other “tangible” ways, e.g. writing documentation, submitting art work, etc. What is the make-up of the group? # of people? How are members elected? Are there “term limits”? To get things started, OSAF staff has drafted 3 founding members. Going forward however, we want to establish processes for growing and sustaining the group.

Our first governance project is to look for models in other projects.

• Davor brought up Apache Project’s notion of a “core developer group”.
• What about non-software development models? e.g. Wikipedia “stewards”?

There are a few points of process we think we’d like to implement right away.

• The group will work primarily on the Users List. Mails will be tagged [UAG] in the subject line.
• There is a public, shared Chandler collection to keep track of projects.

I imagine that in the coming weeks, we will be bringing these issues to the users-list, looking for input from the broader community. So stay tuned for more discussions!

Note Some of you may be wondering what my role is specifically with regard to the advisory group. I am not technically a member of the advisory group. However, during this initial period as the group is finding its legs, I expect to be actively involved in getting this rolling.

The Dashboard collection in Chandler has some interesting properties (not all of which, intentional that have proven fertile ground for experimentation by some of our more adventurous users.

Going into Preview, we had a number of theories about what user needs the Dashboard would fulfill. Some of our assumptions have played out, others haven’t. Here is a recap:

1. We thought it was important for users to get a cross-collection view of all their data where the could process items regardless of what collections (groupings, contexts, categories) they had been assigned to. It’s also a handy way to see what’s new across all of your collections without having to click on individual collections one-by-one.

2. On the other hand, given the number of “other people’s collections” an user might subscribe to, we wanted to make sure that people had a way of quarantining FYI subscriptions from the personal collections in their Dashboard. As a result, we implemented a “Keep out of Dashboard” feature that allowed you to quarantine items on a per-collection basis so that they weren’t automatically picked up by the Dashboard.

There are still some behavioral idiosyncracies to be worked out, but it’s been interesting to see how users have made creative use of these 2 relatively simple ways to define the Dashboard view.

1. Some people use the Dashboard get a view across of “their personal stuff” versus “other people’s stuff”. (I use it this way, although I don’t spend very much time in the Dashboard collection.)

2. Some use the Dashboard purely as a place to collect new notes, an “intake” area so-to-speak. Once the note has been “processed” and added to the appropriate collections, it is removed from the Dashboard. In order to make this work, all of your collections must be initially kept out of the Dashboard. (This is analogous to the GTD Collection phase.)

3. Some use the Dashboard as a way of hand-picking a sub-set of NOW items to focus on “Today”. (I imagine these would be users who find themselves regularly ending up with pretty large NOW sections in each collection.) Again, in order to make this work, all of your collections must be initially kept out of the Dashboard.

How are you using the Dashboard?

One of the most common questions we get about Chandler is: Can I sync my Chandler data onto my mobile device?

The answer is Yes! While there aren’t full-featured Chandler mobile apps for all the various mobile platforms, you can sync Chandler data onto any device that can sync with or subscribe to calendars via .iCalendar or CalDAV.

Specifically, that means you can:

1. Publish your collections to Chandler Hub;
2. Subscribe to them with Apple iCal or Google Calendar;
3. Use either Apple iSync or Google Mobile to get your Chandler data onto your mobile device.

---

Notes

You can sync all of your Chandler data to Apple iCal. Non-events will show up as tasks in the To-do list.

Currently Apple doesn’t sync To-do’s onto iPods or the iPhone, so you won’t see Chandler Notes on Apple’s devices. However, Apple iSync will sync To-dos onto Palm devices.

Google Calendar on the other hand, currently does not support tasks at all, so you can only sync events thru Google Calendar.

Apple iCal 3.x (Leopard) supports view-and-edit sharing via CalDAV, meaning you can make changes from your mobile device and they will sync back to Chandler. However, with Apple iCal 2.x (Tiger) and Google, you can only view your Chandler data.

There is a test build that supports 2-way view-and-edit sharing via CalDAV with Google. However, it has not yet been incorporated into the official release of Chandler desktop.

---

Liz Cademy wrote in with a success story linking Chandler to her iPod via iCal and iSync. I too, have been happily syncing 5 of my Chandler collections (events and notes!) to my new pink Palm Centro via iCal and iSync for a couple of weeks now. I’m thinking of finally upgrading from Tiger to Leopard so I can edit as well as view from my phone.

Has anyone else tried syncing to mobile devices in this way?

The Chandler Project is pleased to announce the 1.1.0 release of Chandler Server (Cosmo)!

Chandler Server is a server and Ajax web UI for managing and sharing calendars, events, and tasks. It implements open data standards including CalDAV, WebDAV, Atom, and Atompub.

This release contains two significant features and four bug fixes. Any user can now delete their own account and data by using the settings dialog. Interoperability with some CalDAV implementations including iCal 3 should be improved by support for the CTAG draft standard.

The Chandler Hub has been updated and is now running the 1.1.0 version as well.

Chandler Server 1.1.0 is available for download as a ready-to-run bundle at:

http://chandlerproject.org/serverdownload

and the source code is available from subversion at:

http://svn.osafoundation.org/server/cosmo/tags/rel_1.1.0

Send us feedback at the open mailing list (no subscription required):

chandler-users@osafoundation.org

We look forward to hearing from you!

The issues fixed in this release include:

• [Bug 12283] Users should be able to delete their own Hub accounts
• [Bug 12279] Add support for CTag, Apple’s extension of ETag to a Calendar Collection
• [Bug 11851] Sort triage status by TriageStatusChangedDate
• [Bug 12334] Fix recovery pages
• [Bug 12349] In IE7, in DV, long notes obscure DV header section
• [Bug 12357] Account browser help link broken

Back in January, we underwent a significant reorganization. Our founder Mitch Kapor stepped down from the project and provided enough funding to support paid staff for about a year. In August, we released 1.0 and since then we have seen a notable increase in our user base and continued growth in the user community.

As we head into the 4th quarter, we are now turning our attention to what needs to be done to ensure that Chandler remains a healthy, open source project that continues to serve the needs of its users as we transition from a paid staff to a volunteer-driven organization.

So, we felt it was time to back-up and take stock of what we’ve accomplished with the recent 1.0 release, and talk about our options, both in the short-term (next 3-6 months) as well as with respect to long-term goals.

The question before us is: Given our goals, what is the best use of remaining paid developer time?

---

Our mission remains developing high quality software to help individuals and small workgroups manage tasks and calendars.

We think this means delivering a solution that supports:

• A hosted service to support sharing and personal backup and syncing.
• A desktop application that is stable and performant with an extensible schema.
• The ability to get data in and out of Chandler (Desktop and Server / Service) in a variety of “standard” ways.
• The ability to work with other apps, where APIs and standards exist.

We also remain committed to remaining an open source project by:

• Continuing to grow and solidify the user community, including establishing processes to ensure that users have a voice in development efforts.
• Build a development community around a code base that is well-documented, fully testable, easy to maintain and and modular enough to allow for loose collaboration among developers.

Post 1.0 Priorities: Going forward, we’ve identified the following areas as key to the continued health of the project:

1. Hub Service
2. Support 1.0 users on both Chandler Hub and Chandler Desktop (We continue monthly releases of the desktop and are about to release Chandler Server 1.1.)
3. Community (more posts on this soon!)
4. Desktop Re-architecture Project

Desktop Re-architecture Project

As with any re-architecture effort, ours is a risky one, complicated by unknowns.

• Bug fixes and new feature work will slow down considerably. In the short-term we’ve decided to focus on strengthening Chandler’s “mobile device” support with extensions to Chandler Hub such as a new quick entry iPhone app and the ability to broadcast and receive email notifications. (However, we remain committed to fixing serious blocker bugs as well as helping volunteers interested in fixing bugs and building new features.)
• The timeframe for a fully re-architected, usable Chandler Desktop is still unknown.

Still, one thing that has been clear to us for some time is that the the performance and stability issues we face on the desktop can’t be fixed by continued work on the current code base.

Therefore, the choice we face is one of timing: Either we continue feature work on the current code base and defer the re-architecture to some later date (probably as a volunteer project), or bite the bullet and use remaining paid staff resources to work on re-architecture now.

In the end, we decided to re-architect now for a number of reasons, including:

1. Re-architecture projects are unlikely to be implemented by volunteer developers.
2. A re-architected desktop will be much friendlier to new developers and put Chandler in a stronger position for attracting volunteers, both for fixing bugs and building out new features.

That being said, our first milestone is to get something developers can start hacking on in the next 3 months, even if there isn’t enough UI for end-users to try it out.

---

The significance of 1.0: If we knew all along that we needed to re-architect the desktop, why did we decide put our energies into shipping a 1.0?

Shipping 1.0 has helped us clarify what the re-architecture needs to support. Both from a technical standpoint as well as from a design and user interface perspective.

Preview and 1.0 allowed us to put theory into practice. Through user feedback, we validated the problem space we had identified and workflows we had developed. We also identified what didn’t work and what wasn’t necessary. All of which will be essential in maintaining a sharp focus as we proceed with the re-architecture project.

Last but not least, 1.0 has been instrumental in helping us build a user base and enthusiasm for the project, two things we will need to sustain the project through the re-architecture effort..

Goals of the Re-architecture

• Address performance and stability issues.
• Make it easier for developers to fix bugs and add new features.
• Separate the storage, domain model, interaction and presentation layers of the app in order to parallelize development. (So for example, developers can work on building the interface for a new feature without having to wait for the domain model to be defined.)
• Comprehensive test coverage.
• Extensible schema.
  – Allow developers to add functionality around an expanded range of data types supported by the app. (e.g. Documents, Media, Contacts and Directories, etc)
  – Allow developers and users alike to define custom attributes.

Non-goal: Create a generic developer toolkit.

What we think we can accomplish in the next 3-5 months:
There are a number of paths we can pursue. At a minumum, we know we need to implement fully-tested interaction, domain and storage layers for Chandler. After that, there are a number of different ways to stage added functionality. A few configurations we’ve discussed include:

1) Sharing a simple task list through Chandler Hub. This would involve:

• Ability to import data from current desktop. (aka Port EIM.)
• Baseline sharing support.
• List view.

2) Basic Calendar

• Week view
• Detail view
• Recurrence

3) Initially bypass core Desktop 1.0 features and instead implement add-on apps (e.g. bookmarks manager, personal jogging tracker, reading list). Small, discrete apps that require less upfront investment in infrastructure work and allow us to get usable UI on the re-architecture branch faster.

For a more detailed discussion of our re-architecture plans, see Grant’s write-up on the Chandler-Dev list. Ultimately, our goal is build community interest around the re-architecture work. So please stay tuned for more discussions on the dev list and jump in with questions and feedback.