For the past three years Google has run an outstanding summer program for students interested in becoming involved with open source software development. Summer of Code offers students a chance to develop relationships with living, breathing software communities by coordinating with as many as 130 organizations and 900 students on 3 month software projects. Stipends are provided to both the mentor organizations and students, making it a very sweet deal from almost any angle.

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.

Mimi and I were checking out Things the other day, which appears to be a thoughtfully designed task manager for OSX (similar space to Chandler). One of the developers had a recent post that I thought captured something important about good design:

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.

Last week the staff got together in person and took a critical look at where the project is now and what we want to achieve in the next year.

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).

To help focus as a team, we have consolidated our various mailing lists in the following ways:

1. Chandler-dev is now the working list for all things pertaining to the Chandler Project. This includes planning, design and bug prioritization for both Chandler Desktop and Chandler Hub as well as general interest topics like the project wiki, evangelism, community, and governance.

2. Cosmo-dev remains a separate list for those interested in just the server. Planning and project management discussions that used to happen on Cosmo-dev will move to Chandler-dev.

3. General, Design and Service-dev are now inactive. These conversations will move to Chandler-dev. If you are on one of these lists and want to continue following the day to day work of the project, subscribe to Chandler-dev.

4. Chandler-users will remain the best place for users to ask questions and report issues. Email us at chandler-users at osafoundation dot org.

5. Announce will continue to broadcast major releases and other newsworthy information.

All other public lists will stay the same.

We are also maintaining a Chandler Project collection where you can keep up with more day-to-day work. This is where we’re keeping track of feature ideas, upcoming blog posts and meetings.

View-only URL: https://hub.chandlerproject.org/pim/collection/f9fe3636-c489-11dc-dba3-f100459c9336?ticket=37960wr571

Finally, we will be making more use of the blog to discuss design direction, product strategy and to keep everyone abreast of project status and new releases.

Katie’s post OSAF 2.0 Team seems like a good opportunity to introduce myself in this space. When I first joined OSAF I was asked to do this by Pieter Hartsook but a combination of a bad memory and busy schedule has kept this task triaged Later.

I’m originally from a small town about 45 minutes outside of Portland, Maine. My first brush with software development came during the summer of 2006 when, alongside a 6 day-a-week summer camp job, I participated in Google’s inaugural Summer of Code program. My project for the summer found me working with the GNOME Project implementing an experimental “panel extension” system.

I found Chandler while looking for a Linux calendaring client during my senior year at Williams College and after an internship on the Desktop team working on a project to better integrate the Twisted IMAP server into Chandler I was hired full-time as a server/ web front-end developer.

Most of my work since then has straddled HTTP, working mostly at the protocol level on the server and client side, with occasional forays down into the depths of our database layer and up to the shallow waters of user interface implementation. Most recently I’ve been updating our JavaScript code to use the 1.0 release of the Dojo toolkit.

A second project I’ve worked on recently (alluded to in the title of this post) is the first of what I hope to be a series of interesting hacks designed to expand Chandler into the maze of nooks and crannies that is contemporary personal information management. One of the more important lessons I’ve learned while working in this space is that everyone has a different system for tracking and managing the various things they want to accomplish both in work and in life. While semi-standard systems like Chandler’s Triage Workflow and David Allen’s GTD can help, even the most hard-core practitioners will make adjustments to work with their own personal circumstances. As developers of software designed to “serve the way people actually work, independently and together“, I believe it is our job to lead the way in bringing our ecosystem to people’s real needs.

So without further ado, let me introduce chandler.el, a module for interacting with Chandler Server using Emacs, a popular text editing environment. Instructions for installing and using it can be found at the link above. The current implementation is decidedly rough, but is ready for some real world use and feedback.

This offering is definitely on the techie side, but I hope it serves as a proof of concept for a general class of lightweight applications that have the potential to bring Chandler to the system you currently use to track your life. There is currently a discussion on chandler-users@osafoundation.org in which I’ve solicited ideas for more applications like this, please feel free to chime in there or in the comments to this post with yours!

In the future, updates about chandler.el will be posted mainly on my personal blog occident.us alongside information about whatever I happen to be working on or thinking about at the time. If you’re interested in what I do, do check out that space.

Several folks have asked who is staying on for the next phase — who is remaining on the staff.

Mimi Yin continues on as our Product Designer, Sheila Mooney in Program and Product Management, and Jared Rhine running the Hub Service. Jared will add more IT responsibilities, as well as build and release responsibilities to his plate. Mimi, Jared and Sheila will also be helping me with a wide variety of tasks for the organization, as one might expect on a small team.

Grant Baillie, Jeffrey Harris, Brian Kirsch, Randy Letness and Travis Vachon are all developers on the new staff. Phillip Eby continues to have a contracting relationship with OSAF, and is actively participating in strategy discussions with the team. Grant, Jeffrey and Brian had recently been working on the desktop team, Randy and Travis on the server team. Travis was an intern on the desktop team a few summers back, and Brian worked on the server team a few years ago. Going forward, developers will move around and tackle code on either code base depending on what is needed.

For the time being we’ll have a flat organization, and think of ourselves as one team. (Previously we were organized in server, desktop, qa, product, build/release and management teams). We’ve ended all of our older recurring meetings, and now have one daily sync up with the 10 people noted above. We’re currently doing this on the phone while we get our footing, but may eventually transition to IRC.

You should start seeing more posts on this blog about strategy and overall direction. We’re also starting to getting back into the groove of working on the lists.

I’d also like to emphasize that Chandler Project is bigger than these 10 staff members. Several former staff members intend to remain involved in the project. Andi Vajda will continue to maintain PyLucene and PyICU. Heikki Toivonen and Philippe Bossut will continue with Finnish and French translations. Heikki will continue to maintain M2Crypto. I continue to appreciate the counsel of Phillipe and Ted Leung, and am looking to find ways for them to be involved in an advisory capacity. Others have mentioned wanting to remain involved as well — I’m sure new roles will unfold as the next phase shakes out. Chandler Project also includes contributors like Andre Mueninghoff and Davor Cubranic, who helped immensely in getting out our Preview release. We also really appreciate all the users who speak up on the chandler-users list. We look forward to the project growing, even with a smaller paid staff.

OSAF and the Chandler project are going through some big transitions. Yesterday, January 7, we restructured the organization. This is the biggest change since the inception of project six and a half years ago.

In September 2007 we delivered a Preview release of Chandler Desktop, Chandler Server and the Chandler Hub web application. Since then we’ve been gradually acquiring users and building a community of people interested in the project. We now have hundreds of people participating in our users mailing list and thousands of users downloading Chandler and creating accounts on Chandler Hub.

Chandler is an open source, standards-based calendar and task manager built around small group collaboration and a core set of information management workflows modeled on Inbox usage patterns. Users manage and share calendars, tasks, messages, and notes with the Chandler Desktop application and with the Chandler Hub web application.

The next phase of the project is about growing the user base, building the community, and diversifying our funding sources. OSAF has been primarily funded by one person up to this point, Mitch Kapor. Our goal going forward is to modify our organization and our funding model to grow into a publicly supported community project, not propelled by one individual.

I will be leading the next phase of the project, and Mitch will be winding down his role on the project. Mitch will provide transitional financial assistance to support the organization through 2008. Mitch will step down from the board, and I will replace him.

OSAF will maintain a smaller staff during the next phase of the project. While figuring out the new funding model, it is prudent for the organization to reduce expenses. OSAF’s paid staff will go from 27 people to 10 people. While I expect that most former staff members will move on to other endeavors, we certainly welcome them to remain involved with OSAF and Chandler in some capacity. Developers will retain commit privileges, for example.

Strategically, we find ourselves at a crossroads. The new Chandler team will continue to address the needs of informal groups sharing calendars and managing projects together. We’ve gotten a lot of great feedback from our current users, and intend to use that to fix usability problems and shape the next set of feature work. We have several options before us and will be ironing out a more focused plan for the next phase. We will keep everyone updated on this blog.

The Chandler team did a fantastic job shipping the Preview release. Building on this accomplishment, the project has many great possibilities ahead. While saddened to see such a great team come to an end, I’m excited about the project’s opportunities and looking forward to the next chapter.

Yesterday, I sent out the first in a series of newsletters for the Chandler-Users mailing list.

The newsletter is intended to be a summary of list highlights including a ‘Did you know…?’ Tips and Tricks section on using Chandler culled from the Chandler-Users list and a section on Upcoming Features and important Usability and
Workflow issues being discussed on the Design list.

For those that are Facebook aficianados, we’ve started a Chandler group on Facebook. Come join us…

For Preview, we’ve made a huge effort in updating and expanding Chandler Project documentation.

Visit our new Chandler Project website.

From here, you can Download Chandler Desktop, Sign up for a Chandler Hub account as well as find our newly updated Vision Document and Feature List, complete with screenshots and informational demos of both Chandler Desktop and Chandler Hub in action.

For a blow-by-blow list of what’s new and what’s changed since the 0.6 release, see Preview Release Notes.

There is now a consolidated FAQ that covers topics ranging from ‘What license is Chandler under?‘ to ‘Can I use Chandler for Email?‘ and developer questions.

We are also working on a Get Started Guide for step by step instructions on everything from setting up accounts and sharing to a quick overview of Chandler’s core information management workflows. We expect the guide to be a ‘living document’ that will be continually improved to help new users ramp up. Check it out and give us feedback!

If you run into problems using Chandler, take a look at Known Issues and Troubleshooting.

If you think you’re problem is new, subscribe to the Chandler-Users mailing list and send us an email. If you’re pretty sure you know what’s going on, following the directions on the Report a Bug page and log a bug.

Here is an overview of how you can Get Involved, including an up-to-date list of Starter Projects.

Last but not least, if you’re looking to learn more about Chandler as a project, dig through our newly re-organized Project Wiki where you will find an overview of the Desktop, Server and Hub Service, detailed design and developer documentation as well as day-to-day planning, bug-tracking and notes.