If you are in the area, we’d love to see you at the conference! (I will be updating this post with details as to which day we will be presenting.)

Update We will be presenting at 3PM on Tuesday Nov 18th. Here is the full schedule.

Below is the description for our sessions.

Chandler is an open source Note-to-Self Organizer designed for personal and small-group task management and calendaring, created by the Open Source Application Foundation.

Since our Preview release, we’ve had a number of users from a wide range of non-profits (ie. universities, other open source projects, summer camps, green technology, etc). Some are using Chandler individually, others have looped spouses and co-workers in to collaborate on projects and day-to-day tasks. You can read some of their stories here.

We will begin with a quick introduction to Chandler and demo what it is capable of today. However, the focus of the talk will be on newly started re-architecture work that will enable Chandler’s core note, task and calendar management workflows to become the anchor for a fully extensible and customizable information management platform.

To appeal to both everyday users of the software and developers with a technical interest in the project, our presentation will be two-part. First, we will walk through some user scenarios and then we will provide a technical overview of the re-architecture work we’ve been doing.

*****
Session 1: Extending Chandler: Chandler as a Confluence of Workflows

You can try out Chandler’s core information management workflows in the current 1.0 release: Collecting new information. Triaging tasks. Scheduling and reminders. List management and note-taking. Sharing and collaboration. Still, it was always our intention to build on these workflows to include document management, issue-tracking, and CRM (or to be even more specific, grant proposals, newsletters, and donor profiles).

In this session, we will walk through one scenario that demonstrates how Chandler’s workflow can be:

1. Extended to integrate new kinds of information management into the core workflows mentioned above.
2. Customized to meet the specific needs of your organization.

Session 2: Extending Chandler: Technical Overview of the Re-Architecture

Chandler’s re-architecture is focused on providing a framework with:

1. Events driven by Trellis
2. Strict separation of domain model, interaction model, and UI
3. Thorough testing of each layer without depending on higher layers
4. Thoroughly documented entry_points to make extension writing approachable
5. Doctesting so documentation is accurate and isn’t left for the last minute

The re-architecture project is still in its early days. The current documentation is available, and of course so is the source code.

Presenters: Jeffrey Harris, Developer and Mimi Yin, Product Designer.

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.

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?

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.

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.

User Support Hour

When: August 4, 2-3PM PDT
Where: IRC
Channel: #chandler

To kick things off, we’ll be holding User Support Hour. Please join us
if you’d like to share or learn how others use Chandler or simply want
help getting set up or troubleshooting a problem.

Then stick around and provide input for developers:

Scratch Your Chandler Itch

When: August 4, 3-5PM PDT
Where: IRC
Channel: #chandler

If you know a little Python, and would like focused help from the Chandler development team, we have a few projects we think might make good starter projects both for introducing Chandler’s code to new
developers and addressing real pain points in the product. Please feel free to add your own!

• More alarm snooze options
• Shortcut from the reminder pop-up to the item details
• More commands for the Quick Entry field (e.g. for filing items, etc)
• Download flagged emails (IMAP)
• Customize App Bar: Add Tasks, define a “Notes-only” area, etc)
• Print Triage List

See full list.

If you want to participate, start by checking out Chandler using SVN

Hack On Chandler Server

When: August 5, 3-5PM PDT
Where: IRC
Channel: #cosmo

We’ll finish off our community sessions with a session aimed at people conversant with Java or Javascript who’d like to improve the server.

• Port the iGoogle quick entry widget to iPhone, OSX Dashboard, Vista
  Sidebar, Yahoo Konfabulator

• UI for setting up Notifications (via email)
• UI for importing .ics calendar files through web UI

If you want to participate, start by checking out Chandler Server using SVN.

RSVP

We’d like to get a head count of who might participate. If you’re planning on attending, or if you’d like to participate but can’t make those times, please let us know by this Friday.

Thanks,
The Chandler Team

The seminar will be held at the San Francisco Technology Center at 1370 Mission Street near 10th Street on the 4th floor on Tuesday, July 22nd at 5PM.

If you work for a non-profit and would like to attend, please RSVP here.

The thread, originally begun with the title: “Chandler maturing as an Outlook alternative” has grown into a more general discussion of sustainability and open source projects and in particular, our own plans for building a volunteer development community.

Much of the conversation has revolved around how we maintain a user-centered focus as a project as we work to attract volunteer developers. (A challenge all consumer-facing open source projects face.)

Don C in particular has had some useful words of advice based on his experience on The Sahana Project.

As we have in the past, OSAF will be participating in SoC as a mentoring organization this
year. A full list of projects we believe will be both useful to the project in the long term
and stand a high chance of being included in our code base in the short run can be found
here, but
as in past years outside proposals are more than welcome.

Comprehensive information about this year’s program, including important bits like
eligibility
and application instructions
can be found on the the official
FAQ. Student
applications will be accepted from March 24 – March 31, so now is the time to find
a project and put together a solid proposal!

As always, feel free to ask on one of the Chandler Project
mailing lists
or in #cosmo or #chandler on irc.freenode.net for more information.

Of course both Jobs and Schiller know that there are times when you listen to users and times you better not. And the interesting thing is, even when developers don’t listen, they might do it for the best of their users. But how is that?

By all means developers need to follow their vision without asking anybody. They need to think out of the box and innovate. How else could they surprise and ultimately delight?

One of the main responsibilities of a developer is to keep guard over the gestalt of a program. It is all too easy to let your application burst into a universe of hardly connected little features. We have all seen it happen. But it is equally easy to ignore your customers’ needs and to embark on a journey where nobody is following you.

It is not about listening or not, it is about what to do with all the things you have learned from listening. And that is integration. The best feature is worth nothing when not integrated properly. When we read a feature request, we don’t think about doing it or not doing it. After all, if software development is not about satisfying users, then what is it? We are thinking about how we could nicely integrate it with the rest of the application without diluting its identity.

Of course, as an open project, we’ve sort of given up the element of surprise.

One of the project goals has been to experiment with involving users, developers, and other interested parties throughout the design process, making design decisions in conversations on public mailing lists. During that process it can be tempting to use “what the user has asked for” as an objective criteria for making decisions. The quote above does a nice job articulating that doing so can be dangerous for the integrity of a design, without writing off the importance of paying attention to what users are saying.

Mimi did a writeup on OSAF’s open design process last summer in preparation for a presentation she did with Ted Leung at OSCON. She goes into some detail describing how we manage conversations and make design decisions in a way that tries to preserve both the “gestalt” of the design as well as the continued interest of developers who might be pursing individual passions and concerns. Getting this process right continues to be one of the more interesting challenges of the project.

We asked ourselves a series of questions, including: “We have some successful, enthusiastic users who rely on Chandler daily: how are they using it? What are their success stories? How can we build on that and grow the user base?” and “Why do we only have 100s of unique desktop users syncing to the Hub daily when many 1000s of users have downloaded the desktop?”

Looking at users who *are* successful and potential users who run into difficulties, we had this insight: Chandler succeeds at meeting the needs of users who are tracking ‘knowledge work’. What do we mean by this? We’ve observed people tracking ideas and questions for tasks they need to do — the kind of things people otherwise might jot down in notebooks, on scraps of paper or in text files. They selectively add important email messages to Chandler (the ones they might have flagged if they were only using their email client). They share collections of these items with other people as they develop an idea, using Chandler to record the ‘knowledge’ about a shared project. Quick item entry, stamping items onto the calendar or a task list, and items in multiple collections are all signature features that help users evolve their ideas into tasks and projects. While the design includes tasks and a hard calendar landscape, Chandler is not oriented around calendaring per se or around a complicated task and project landscape with many dependencies. We don’t have enterprise scheduling features, for example, or task and project dependencies. Instead of adding more features for calendaring and task/project management over the next year, we’d like to build on Chandler’s more unique strengths, excelling at meeting the needs people who currently find Chandler compelling.

Of course, many users who *do* have similar needs to the successful users run into barriers when trying to use Chandler. The application is too slow for their hardware, they are overwhelmed by non essential functionality visible in the application, they don’t know how to get started, they run into a roadblock when creating an account, etc. We want to remove these barriers.

The flip side of this is that some people who have been drawn to the project are really *not* target users. Chandler doesn’t meet their needs because Chandler is not designed for them. We just don’t have the resources to make all of these people happy — we really do have to focus. More on this in the “what we are not doing” section below.

Another idea that came up in our discussions: we want Chandler to be more viral. We want Chandler to be easy to explain to others. We want Chandler to be found in contexts where people are already spending time. We want Chandler to be of great use to the individual using Chandler on their own, and to be even more useful as that user pulls in other people to collaborate. We want happy users be successful evangelists for Chandler.

What we are doing next

We made some important high level decisions about what we’re going to be focusing on in the next year, and in particular for the next 3-4 months. It was most concrete for us when we discussed exactly what each person would be working on (in particular what each developer would be working on), so I’ll use that to frame our strategy.

Grant Baillie: Incremental progress on the desktop. We decided that we can’t stop and take time out to rewrite the desktop or build a complete web based home for our target users, so that means continuing to maintain the current desktop code base. Grant will focus on bugs and small feature changes that remove barriers for users who otherwise would value Chandler’s feature set. We are not far from a 1.0 version of the desktop. One of the first projects that Grant is working on is a pass at simplifying the UI by removing rarely used email functionality — reducing the number of new concepts that users need to get started.

Travis Vachon and Jeffrey Harris: Web widgets. We’re turning our focus on the web away from replicating the desktop functionality, and toward making Chandler more viral and better at facilitating idea gathering and collaboration for our target users. Travis and Jeffrey are going to build web widgets that might be deployed in different contexts — iGoogle, Facebook, on an iPhone, etc. Widgets will give read/write access to a particular item (instead of a whole collection), allow users to search for a particular item, allow quick entry of items, etc. We’ve started the design work on the chandler-dev list. One requirement for the web strategy is that these widgets should be compelling to a new user who does not use the desktop, in addition to providing features that complement the desktop. Eventually, the widgets can be building blocks for developing out that web based home for our target users.

Brian Kirsch: Thunderbird plugin. Brian has already blogged about this idea; we’ve decided to proceed with it. We think it will be a great way to introduce Chandler ideas to a new audience.

Jared Rhine: Email related features on the Hub. Jared will explore adding email notifications/reports from the service, and email as a way of entering data into the service. Again, these features are a way of making the Hub more viral — data access from other contexts where people spend their time. This work is in addition to Jared’s many other responsibilities (managing the Hub service, build and release management, etc.).

Randy Letness: Chandler Server improvements and support for web widgets. Randy will continue with security work that has long been planned, as well as server support necessary for the new web widgets.

Phillip Eby: Desktop rearchitecture. We will continue to make a modest investment in the rearchitecture project that we embarked upon last year, as the rearchitecture is our path to really solving desktop performance problems. The rearchitecture will also provide a much better platform for other developers to contribute to the project.

Mimi Yin: Product design and strategy. Web strategy and web widget design, Thunderbird plugin design, desktop prioritization, project website improvements, etc.

Sheila Mooney: Evangelism strategy. Develop a pitch and a demo, meet with stakeholders, etc. One of the barriers for potential users and partners is really a marketing barrier — helping people understand what Chandler is intended for.

My job is to manage the project overall and give the project its best shot at thriving beyond the end of the year.

What we are not doing

We are not trying to be an open source Exchange/Outlook competitor. While this would be a worthy goal, it is not our passion and we don’t really have the right product or organization to pull this off. It has been a misperception in the press that this has *ever* been our goal — probably because so many people want an open source competitor to Exchange/Outlook. We have not designed Chandler for enterprise calendaring. Actually, the Microsoft product with the most overlap with our design objectives is probably OneNote.

Being a CalDAV reference implementation is not a priority. We believe that calendaring standards are important and hope that they are adopted in the world, and much of OSAF’s energy in previous years was directed at making that a reality. With our current need to focus, however, our strategic objective wrt calendaring standards is to be able to interoperate with popular clients (e.g. iCal and Lightning). For this reason and because we are not trying to do enterprise calendaring, we will not be implementing CalDAV scheduling.

We are not trying to be a GTD specific tool. Yes, we paid a lot of attention to GTD as we were designing Chandler and we were inspired by ideas from GTD. We also looked at how people who have never heard of GTD really use their inbox to manage their world, and taken inspiration from that as well. When getting into the specifics of Chandler’s design, we focused on user scenarios and workflows that would make our target users successful — not necessarily designing to GTD processes. We’ve recently taken a critical look at how well Chandler meets the needs of someone following the GTD process strictly. In doing so, we realized that we didn’t want to prioritize staff time to work on changes that would make Chandler a GTD specific tool, and that Chandler’s philosophy is different enough from GTD that it would be misleading to call Chandler a GTD tool. We’ll need to change our messaging — our landing page, blog and other places that refer to GTD. That said, we recognize that some developers are interested in features that would help people use Chandler for a GTD process, and we encourage anyone who wants to contribute code for such features.

We are not going to add full email functionality to Chandler desktop, or contacts (at least not in the next year, not on OSAF staff time). Yes, we know that many people want these features, and we’d love to design them and implement them if we had the resources, but we don’t have the resources in the next year. Again, we’d *gladly* accept code contributions that implemented these features, or additional funding to implement them. We are willing to spend time to help make people successful contributing code for these features (or other features that complement the current product).