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.

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.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

and three rights: use, modify, redistribute.

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

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

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

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

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

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

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

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

OSCON wrapups from various OSAF folks have started to appear:

• Adam Christian
• Ted Leung
• Brian Moseley
• Mikeal Rogers
• Matthew Eernisse