Chandler maturing as an Outlook alternative

OSAF just released Chandler version 0.7alpha2. I can tell version 1 is going to be great.

0.7 alpha 2 release notes:
http://chandler.osafoundation.org/newinalpha2.php

Chandler home page:
http://chandler.osafoundation.org/

Thanks for sharing that ahz. I just downloaded it and have begun poking around. So far so good.

I remember hearing about Chandler a few years back, and at the time, the project was in such infancy that you couldn't even download it to try. I'm now using the 0.7 alpha release and am thrilled to see how far it has come. Running the linux port on Kubuntu Breezy (P4x768MB), the program seems a little sluggish - there is a half-second delay after each click before the program springs into action. But I am sure this is going to get ironed out in the coming alpha and beta releases, and I'm also very much looking forward to the general release down the road.

Clement

Hi, I'm the product designer for Chandler. I found this old thread and thought it might be worth replying with an update :smile;

Since Clement's post, we put out a Preview version of Chandler in Sept of 2007 and have been releasing updates monthly since then.

You can download the latest version here.

In the past few months, we've had quite a few users write in from non-profits and in particular, from universities. We've put together a gallery of user stories. We'd love to hear from you if you've tried Chandler. Just send mail to the Chandler Users list.

As for the topic at hand: Outlook/Exchange, if you're looking for a free alternative to Outlook/Exchange for sharing calendars, definitely give Chandler a try.

However, Chandler isn't an open source version of Outlook/Exchange. There are a few key differences worth noting:

Unlike Outlook/Exchange...
- Chandler is intended to work across organizations, not just within 1 organization
- Chandler doesn't require IT support to set up.
- Chandler doesn't require organization-wide adoption to work
- Chandler interoperates with other calendar applications and services via the iCalendar and CalDAV standards

- Chandler isn't a "suite" of applications: Email, To-do list, Journal, Calendar, Contacts. It's 1 application with 2 Views: A Triage List and a Calendar.

- Chandler also is not intended to replace your email client, instead, it works as a complement to email.
- Chandler doesn't yet support Contacts, although users have found some interesting ways to re-purpose Chandler's basic note item to manage contacts like tasks in the Triage List.

Like Outlook/Exchange, you can use Chandler either purely as a personal tool or for collaboration as well.

Thanks!

Mimi

Hi Mimi--

Thanks for your post about Chandler. I've never tried this before but I'm curious--what would be an advantage for a nonprofit to start using Chandler (besides the free part, of course)? With so many tools out there, what benefit could an organization gain by using Chandler?

Best,

Megan

Seeing this notice today, I investigated. I had been keenly interested in Chandler from first hearing about it, but the project stumbled in defining itself. Now it is about integration, to collect and organize scattered information into one place. I like what I see, but I have not yet got any use out of it. You can get a nice intro here. Look at the Flash demos after clicking on the "Demos:" link or on the line of 4 PNG images below "Demos:"

Hi Megan,

Thanks for your interest. In answering your question, I don't want to fall into the trap of stereotyping non-profits because non-profit organizations are as varied as for-profit ones. Still, there are a few aspects of Chandler worth calling out as advantageous to non-profits. Some of them, I enumerated in my previous post, but I will elaborate on them in order to more fully answer your question.

Free versus Low-Cost.

Chandler is free, but as I'm sure you well know, it's not enough for software to be free. To be actually useful, the less tangible cost of "set up" needs to be low as well. So we knew Chandler needed to be able to get going by itself and couldn't assume IT resources. Downloading the application should be a 1-click affair. Setting up to back-up your data and share with others means signing up for an account on the web and entering your user name and password into the Desktop application.

Working well with ad-hoc groups.

When we interviewed users (many from non-profit organizations), we saw that a lot of collaboration tools failed to take hold in an organization because they didn't function well unless everyone was bought-in to using the system. (Smaller organizations especially tended to lack formal IT support and perhaps as a result, also had less stringent requirements about what software you had to use.) So, Chandler was designed with the assumption that not everyone you work with is going to want or need to use it!

This meant that Chandler needed to provide a way for you to collaborate with people who don't use Chandler.

To share with others, you simply send out URLs that allow others to gain full view and edit access to shared task lists and calendars from the web. Or they can subscribe to the shares with Chandler Desktop or applications and services they already use: e.g. Apple iCal, Lightning, Feed Readers, anything that understands ICAL. (Look here for all the ways you can get data in and out of Chandler.)

This is especially useful for ad-hoc collaboration scenarios like organizing groups of volunteers for one-off events.

Another hitch you run into when you don't have formalized organizational IT or you need to work across organizations is that you can't control what platform people are on. There are a lot of new productivity apps on the market today, but most of them are Mac-only. Chandler is cross-platform. It's available on Windows, Mac and Linux and through the web.

Multi-tasking.

Last, but not least, the ability to track lots of different open "threads" and develop and resolve them over time lies at the core of the problem Chandler is trying to solve. Chandler isn't a strict Getting Things Done implementation. But we've gleaned many useful techniques from GTD, the least of which is separating your to-dos into NOW and LATER piles so you can stay focused without losing track of important things you need to review at a later date.

Again, this isn't something that is necessarily unique to non-profits, but I imagine that in a world that is offering more tools and more forums for doing non-profit work, the list of opportunities for new projects never stops growing. At the same time, there is a lack of effective tools that help you create a "command center" for all the different things you do; A central place to track emails, to-dos, ideas, open issues, deadlines, meetings and events, plus something that integrates both personal task management/calendaring and collaboration.

But rather than me explaining why Chandler is good at this kind of thing, here are 2 user stories from a non-profit that uses Chandler to manage their blog and as a lightweight CRM / task list so they can keep track of who they're talking to, about what:

As Jesse pointed out, there are also demos that show what I'm trying to explain.

Thanks for asking!

Mimi

Thanks so much Mimi for the informative & detailed reply.

Best,

Megan

Hi Mimi,

Like Jesse I was very interested in Chandler when it was first announced 6 (7?) years ago, and impressed a personality like Mitch Kapor had come on board - Unfortunately the project really seems to have languished since - and I read now that Mitch has left and the project is winding back on staff and funding.

I guess a lesson we all take from OSS development is the importance of sustainability and longevity; the same mainstays of NPO and other organisational investment strategies (bit hard for any org to justify investing time in something that may not be around in a year or two - noting staff time is usually the highest cost associated with any software deployment; OSS or proprietary).

One of the questions I find NPO's often ask when I recommend an OSS solution is "will it be around in five or ten years?" - I'm interested in the view the Chandler project has on this - how are you managing project sustainability now the largest financier/supporter has left?

Like donc, I would like to have clearer information about the prospects for OSAF and Chandler. As I recall, OSAF struggled for years to define and redefine what the project would be, and I heard that someone wrote a book about the organization's troubles.

Now, with a useful product defined and developed to a functional state, is there enough interest and energy for Chandler to progress at a reasonable pace? Are there acceptable ways to attract more resources -- human, technical and financial -- to the project.

The longevity of any software project, OSS or proprietary, should be a concern. In the common event of a project dying, undergoing radical change or ultimately failing to keep up with the users' needs, the real concern is migration of users and data to something new.

The interesting thing about OSS is that a project will always be around, even if scarcely used. Any user or interested newcomer can use the pieces, or the entire project, for further development. Also, if file formats and data structures are open, migration may entail substantial costs, but no impossible barriers.

Hi,

I'm glad you asked this question. It's one that every emerging product struggles to answer, be they open source or venture-funded start-up. Unlike venture start-ups however, open source projects invest in community because they live and die by them. In this way, non-profits looking for free alternatives to proprietary software can take the initiative to support the open source products they find most useful by participating in the communities that propel them forward.

A minor correction: Mitch Kapor founded OSAF in order to build Chandler. The project would not exist without his initiative and yes, funding. In 2005, Mitch stepped down from an active day-to-day role on the project to become more of an advisor, while continuing to fund the project.

While it took a bigger organization to get to a beta release, we were able to complete the 1.0 with a much smaller team. As it turns out, we can maintain the product and service with a very small team (perhaps eventually a team of volunteers).

For the past 2-3 years, the project has been focused on first delivering a usable product and second, building a user community that would help us iterate and refine the product into 1.0 material through feedback.

Yes, there is a book about the projects' early meandering days (called Dreaming In Code). The last 2-3 years have been more focused. In that time we've delivered a usable product and have built a small but growing user community that has helped us iterate and refine the product for a 1.0 release. The users have not only provided invaluable feedback, but they have also taken up testing new functionality, reporting and investigating bugs, helping new users with questions and sharing stories about personal techniques they've developed as they use Chandler day-to-day.

For us, the next important step is to expand the community to include volunteer developers. It was harder to do this during the "meandering" phase -- volunteer developers sent the project spiraling off in different directions. Now that we have a user community and a 1.0 product, the direction is more concrete.

1. Many people in our user community have expressed interest in fixing bugs and developing new functionality. (However, to turn interest into committed patches, we need to divert a significant portion of our internal engineering resources to helping volunteers succeed.)

2. There is a remarkable degree of agreement amongst our users about how existing bugs should be resolved, what new features are important and how they should work. The devil as always, resides in the details, but at a high level, those who have been active on the project appear to have a shared vision of what it should be going forward.

There is much to do to ensure the continued growth and support for the product, but we are hopeful that a healthy user community will inspire a healthy development community as well.

Last but not least, Jesse makes a good point that as an open source projects, Chandler will always be around for others to simply use or continue to build on in the future. Not the most comforting reason to give non-profits leery of using new software, but worth noting for those thinking about contributing to the project.

I hope this addresses some of your concerns. It is a difficult issue to answer completely, so I am happy to continuing answering questions.

Mimi

Hi Mimi,

Thanks heaps for the detailed response. The Chandler project does sound like its beginning to find legs, and this is surely fantastic news to long-time followers of the project!

I was a little intrigued to read your comment: “It's one that every emerging product struggles to answer, be they open source or venture-funded start-up”. Just by way of observation, these are not mutually exclusive concepts! Venture funding for Open Source start-ups is at an all time high and may well offer opportunities for Chandler. A few pointers [ here and here ]

Your post also suggests some of the challenges faced by Chandler may be unique, or at least not necessarily shared by all OSS developments. By way of intro, I’m on the Board of the Sahana FOSS Disaster Management System, and while I acknowledge comparisons would not be appropriate (two very different projects) I’m sure there are lessons we can share – e.g. the truism of ‘Developers are the worst developers’, (or never trust your application solely to an Application Developer!)…hold as true today as ever . :-)

Just a little background regarding our project developments..

Once the immediacy of the Asian Tsunami had rescinded the Sahana team quickly recognised that in order to be a serious OSS contender we really needed to maximise domain input and direction. This was primarily so coders could cut the code deemed appropriate to a very tangible project, mission and community (i.e. software developers need focus and direction as much as anyone else!). We are blessed and extremely fortunate to have development oriented people like Sanjiva Weerawana (CEO Apache Web Services) and Michael Tiemann (VP Open Source Affairs at Red Hat) on our Board… but we also have prominent disaster managers from around the world sharing equal authorities and responsibilities on the Board governing this project. This diversity was largely the reason Sahana received the OSF award last year for Projects of Social Benefit ahead of such excellent projects as One Laptop per Child and Project Gutenberg.

So please excuse my curiosity, but does Chandler have domain experts governing the project in conjunction with developers? In the field in which you operate I would think these would probably be people recognised in the fields of time and project management, possibly psychology and others with expertise in human communications systems and mechanisms. I just suspect the project might have difficulty finding direction without this sort of leadership.

Another lesson we learned was that volunteers are an absolute key to the success of any OSS development. Far too many OSS projects fail for simply not understanding this point. Volunteers are only ever a liability when not properly managed, yet it seems inevitable that a poor management structure will lay blame on volunteers for projects failing to achieve direction and purpose. Opportunities for sustainability abound when a cohesive volunteer group is properly encouraged and motivated. IMO this is closely linked to the concept that an OSS project is a community - we do not have ‘users’, we only have participants and contributors. The distinction is very important.

Anyway I’ve probably rambled on enough – you can probably tell I am passionate about OSS developments and love to see them succeed!! I certainly wish you well, and again thanks for the great contributions here to date.

Cheers, Don

Mimi -
Thanks so much for your update and for the straightforward responses to some very pertinent questions - that's a pretty rare thing in these days of spin.

Chandler sounds very intriguing. I've done some review of the gallery of user stories and the rest of the site and it looks like there is potential for it to address a need that I have, but being that I'm a one-person IT operation at MNA it would be helpful if you could make the process faster by commenting on Chandler's applicability for my project.

I've been tasked with identifying a solution for the booking of our rooms that are available as rentals for meetings. We need the ability for users to be able to create tentative reservations, which become final upon approval by the rental supervisor. In addition, we need to be able to reserve associated equipment such as projector, laptop, DVD/TV, etc and to be able to submit notes about the setup of a room (number of tables/chairs, configuration, etc). To make sure that nothing gets forgotten it is best if we can have some kind of template that standardizes the input, but we could use an external document for that and then copy/paste the contents into the reservation.

There are lots of hints that make it look like Chandler could be an answer for this, but I'm not quite sure.

I like the idea that Chandler is separate from our Outlook/Exchange infrastructure. My staff seems to stumble at anything in this environment which gets outside of plain e-mail so I'm really looking for something that will not involve using this toolset. I've been looking at Google Apps, but perhaps Chandler is the answer?

Hi Don,

Chandler happens to be an non-profit, open source project. But you are right, there are a variety of "business" opportunities we can pursue in the form of co-branded partnerships, etc. Our priority right now is to continue to grow our user base and jump-start our volunteer developer community, but I agree that real funding for paid staff and open source are not mutually exclusive.

I also agree that there is much we can learn from other well-run open source projects. I am unaware of many open source projects that are successfully serving end-users with volunteer developers who are more often serving someone else's need rather than scratching their own itch. The Sahana Project sounds like one we should study more closely.

Can you tell me more about the relationship between the domain experts and the developers and how they work together? Do you have interaction designers involved in the process?

As for "domain experts governing the project in conjunction with developers", we are in the process of building up our board so your advice is timely!

We've shied away from taking on project management or productivity specialists who espouse a particular methodology. Instead, since the beginning of the project, we've done a lot of user research looking at how people work, in particular how people use email to do personal and collaborative task management. That research was the basis for target user sketches, product scoping and designs. We then iterated and refined those designs based on user feedback. The responsibility for driving these processes fell on the shoulders of Sheila and Katie our product/program manager and general manager and myself as product designer.

However ultimately, (as I'm sure you'd agree) our users are the experts when it comes to what works and what doesn't work. But their feedback is heavily filtered through a design process that is open and accessible to community participation on our development list. We have been shipping releases with this process for 2 years now and while the dynamic will certainly change as our user community grows and we start to attract volunteer developers (knock on wood), we have a solid foundation to build on.

That being said, you make a good point re: open source projects needing domain expertise. We are actively looking for new board members who have a professional stake in solving the kinds of problems Chandler is intended to address.

Thanks for your words of encouragement, they are much appreciated!

Best,
Mimi

Hi Ernie,

Thanks for your interest. Depending on how many people, how many conference rooms and how many pieces of equipment your dealing with, there are a variety of ways you could make this work.

One way of doing it would be to:

1. Create an account on Chandler Hub that everyone on your team can log into.
   
2. Create a separate calendar for each conference room and each piece of equipment.
   
3. Individuals can block out tentative times for conference rooms and equipment.
   
4. The rental supervisor can approve meeting times by changing the event status from tentative to confirmed.
   

For members of your team who decide to use Chandler Desktop, they can subscribe to calendars for conference rooms and equipment they use often so they view and edit them in Chandler Desktop alongside their personal calendars.

I don't want to get too in the weeds without knowing more about your situation, so if you have more question, feel free to follow-up either here or by sending mail to the Chandler-Users list.

Best,
Mimi

Mimi -

Thanks for the guidance. That really helps me focus my research and it looks like Chandler is worth a deeper look!