Tag Archives: chandler

Design and Commons Based Peer Production

6 Replies

On Tuesday, Chris Messina wrote a post about open source and design, where he laments that open source (whatever that means nowadays) and design seem to be opposed to each other. The crux of the problem seems to be that good design requires a unity about it and that since in open source all voices are heard, you inevitably end up with something that has been glommed together rather than designed. This is something that Mimi Yin and I discussed in our 2007 OSCON talk about the challenges of the Chandler design process. Chris is gloomy on the prospects of open source design processes, because he doesn’t feel that there are any examples that have succeeded. I think that this is a legitimate place to be. I don’t really see any successful open source desktop application which was designed in the kind of open design process that Chris or we at OSAF had in mind.

Is organization the problem?

On the other hand, I think that I’m slightly more optimistic about the situation than Chris is. Chris holds up the idea that there ought to be a design dictator, who drives the design and preserves the unity of the design. I’d point out that there are some open source communities where there are such people. Perhaps the best example that I can come up with are the programming languages. A good language is very hard to design. It needs to have the kind of unity that one expects to find in a good design. In some of the language communities, these designers have titles such as “Benevolent Dictator for Life”, and the community as a whole has recognized their giftedness and given them the ability to make final binding decisions about design issues. This isn’t end user facing desktop or web software, but it’s also not bunches of libraries, or implementations of JSR’s, IETF RFC’s, W3C recommendations or POSIX standards. These situations are very delicate mixes and their success is highly dependent on the particular individuals who are involved, so they tend to be rare. Nonetheless, I do think that its possible for communities to work even if there is a chief designer.

I also don’t think that there needs to be a single chief designer. Chris cited Luke Wroblewski’s description of the design process at Facebook. Very early in that post you read:

The Facebook design team works on product design, marketing, UI patterns, branding, and front-end code. The team consists of 15 product designers, 5 user interface engineers, 5 user experience researchers, 4 communication designers, and 1 content strategist. 25 designers in a company of 1,000.

Design can be done by teams. I think that we all know that, but in many of the discussions that I’ve had on this topic, the focus seems to be on the need for a dictator. The dictator model works, but so does a team model.

I think that the organizational challenges of design (dictator vs team) can be dealt with. If you bootstrap a community with a DNA that is committed to good design, and to the value of a good designer, and if the designer has won the respect of the community, then I can see a path forward on that front.   

The problems that I see

In my mind the problems are:

How do you find a designer or designers who want to work in this kind of environment? We know that not all developers are well suited to distributed development. I’d venture that the same is true for designers. It’s much easier for coders to self select into a project than it is for all other types of contributors, including designers.

How can a non-coding designer win the respect of a (likely) predominantly coding oriented community? If you believe that open source projects should be organized around some notion of merit, then what are the merit metrics for designers? Who evaluates the designers on these metrics? Are the evaluators even qualified to do so? In my examples of communities with designers, those designers are all coders as well.

Can we actually do design using the commonly accepted tools of e-mail, version control, wiki’s and bug trackers? The design process relies very heavily on visual communications. The code (including design and architecture of code) process is predominantly a text based process. It is very difficult to do design efficiently in a distributed setting using the existing stable of tools. This is going to be a challenge not just for designers but for many other problem domains that could benefit from commons-based peer production.

What’s with you and that long word?

I prefer to use Yochai Benker’s term “Commons Based Peer Production” instead of the term open source. The problem with the term open source is that everyone means something different when they use it. Some people just mean licensing. Some people think of a particular community’s set of practices. Others think that it means some kind of fuzzy democracy and mob rule.   
One of the reasons that I went to work at OSAF was to see if it was possible to design a good end-user application via some kind of community oriented design process. As far as I am concerned the jury is still out.

Google Contacts and CardDAV

3 Replies

Earlier this week Mark Nottingham wrote about CardDAV and DAV based protocols:

All of this led me to mutter ‘DAV WTF?’ at the IETF APPS Architecture Workshop the other week. Do we really need to give folks the opportunity to mint more application-specific methods and headers?

Interestingly, Lisa Dusseault — one of the core folks in the DAV world — blogged about this the other day;

Were I to propose CalDAV today it would probably be CalAtom — some things would be easier, some harder, but it would catch a wave instead of drifting in the tail of something that was never much of a popular wave. Oh well, we needed something then, and WebDAV gave the most leverage at the time.

I gave a big sigh of relief when I read that, and I hope that the CardDAV folks take this to heart. Some parts of WebDAV (e.g., properties; see Yaron and Larry on this) deserve to be taken out back and shot — although, as Lisa says, they were necessary because of the state of the art at the time. That doesn’t mean we can’t do better now.

Almost as if in answer, yesterday Google announced the release of the Contacts API, which is AtomPub/GData based. Unlike CardDAV, it’s not based on vCard, which is both a blessing and a curse, since lots of popular contact systems (like the Mac address book) know how to export vCard information, and because vCard provides a very rich model for information about people. I’m not sure whether this is progress or not.

On Scoble’s Chandler interview

1 Reply

A couple of days ago, Scoble paid a visit to the OSAF office in San Francisco and did a video interview with Mimi Yin, the product designer for Chandler, and Katie Parlante, the General Manger of OSAF (and my boss). Of course, I heard about how the interview went, but I was curious to see how the interview would go. Robert and I have talked briefly about Chandler over the years, but not in any detail, and I wanted to know what he thought about what we have done so far. When someone says “I want it”, that’s generally a good indicator, and I was glad to hear that phrase pop out of Robert’s mouth. Also, he asked almost all the questions that I could have wanted him to ask, so if you watch the interview, you’ll get a pretty good idea about some of the most important ideas in Chandler. It should be no surprise that I want to expand/clarify some of the things in the interview, so here goes:

Where’s my Outlook?
If you watch the video, it’s clear that Chandler Desktop today is not very much like Outlook, in the sense that it is not an e-mail centric application. If you believed the Wired-induced hype about Chandler being an Outlook killer, you’re probably disappointed. How did this happen? When we sat down and looked at what people were using PIM’s for, how they worked, and what they needed the most support for, we discovered that there was a big need for supporting groups of people working together as opposed to individuals just managing their own information. That’s why you see an emphasis on sharing and collaborating. A bunch of the infrastructure that we built early on for supporting customized personal information is supporting what you see, so there’s still the capability for doing individual personal information management, but we haven’t focused on those capabilities. Developers take note.

Web-based Chandler
This came across unevenly in different parts of the interview, so I want to make this clear. Chandler Server/Cosmo, which powers our free Chandler Hub service, is a web based version of Chandler. It doesn’t yet have all the features of the desktop version, but we are getting there, and we plan to get all the way there. Not only that, the back end of Chandler Server can provide you with data in a variety of formats/protocols. We want to make sure that you can get data into and out of Chandler Server as easily as possible.

Edit-Update / Sharing (or turning e-mail into a Wiki)
In the interview, Robert latched onto the edit/update features of Chandler. These are still in a primitive state, but you can see the value of them already. He had a great summary of how it works – “you turn e-mail into a wiki”. Exactly. You can create and share a collection with any number of people, and they can all edit/update items in that collection and see each other’s changes, without groveling through endless e-mail reply chains. At one point in the interview, Mimi said something about e-mail being the hub of people’s usage. Truth of the matter is that e-mail is more like the glue that holds batches of information together. Collections of items with edit/update is a different kind of glue.

Plugins/APIs
Robert asked about a Chandler that could slurp data out of Facebook/Twitter/blogs/blog searches and manage all that stuff via the dashboard (the triaging workspace) and Chandler collections. This is a topic near and dear to my heart, and solving that problem is actually the biggest reason that I came to OSAF to work on Chandler. Personal Information Management is no longer about the tiny set of data types that Outlook typically manages. Today, most of my personal information (by volume) lives in the cloud, so any system that is going to manage that information must be integrated with the cloud.

If you look at the Plugins menu of Chandler Desktop, you will see hints at being able to do what Robert asked for. There are demo quality (read: proof of concept) plugins to yank data out of Amazon.com wishlists, EVDB/eventful.com calendars, RSS feeds, and Flickr. We had a plugin for grabbing your del.icio.us bookmarks, but it got way out of sync, but it wouldn’t be too much work to put it back. All these parcels turn their data into Chandler items, which can then be stuck into collections or managed via the dashboard.

On the server, we’re a bit further behind on data type extensibility. It’s possible (I mean it’s code, right?) but it’s going to be a bit more difficult to do because of the server environment. The server does provide good access to calendar data via a number of calendar protocols, including webcal, CalDAV, and Atom feeds. In addition, the AJAXY web UI talks to the rest of the server using Atom feeds and AtomPub, so in theory you could implement a different client by using those feeds and AtomPub. I am quite sure that we will be doing more work on data access API’s for Chandler Server in the months ahead. If you have ideas, suggestions, or code, come by the cosmo-dev mailing list or the cosmo IRC channel.

What’s Left to do?
If you watched the interview, you’ll know that there are a bunch of things that Robert asked about which are not there yet. This is not the 1.0 release of Chandler, and there’s plenty to do. At the same time, the desktop and server are done enough that people can use them and developers can get an idea of what we are trying to do and where we are trying to go. In the server project we’ve already had some good contributions from people outside of the OSAF staff (the hibernate based storage engine, and the minicalendar in the web UI). We’d (the desktop and server projects) love to see even more people get involved.

To keep up on Chandler happenings, visit the Chandler Project blog.

Chandler Preview Release

5 Replies

Last week Chandler hit a milestone that we’ve been calling “Preview”. Preview is a coordinated release of the Chandler Desktop application, the Chandler Server (Cosmo), and a free sharing service, Chandler Hub. Chandler Server not only provides calendar and general item sharing services for Chandler Desktop, it also includes an AJAXy UI that implements a decent slice of the functionality of the desktop. We’ll be working to increase the coverage of that slice over time. Chandler Hub is running on top of the Chandler Server software, and anyone who wants to could run a similar service by grabbing the code and installing it.

Over the years, many people have said to me, “let me know when Chandler is usable”. This is your notice that we now consider Chandler usable. The release numbers on the desktop and server are at 0.7 – so we are not saying that Chandler is feature complete, but the current features are usable. I’ve been using the calendar features for quite some time.

There are some important resources that you should take some time to look at, including:

I’d also like to highlight some of the interesting work that has been going on in the various Chandler projects: Brian Moseley has written a few blog posts about the work that he’s done using REST/Atom to provide services for the AJAX Web UI of Chandler Server. Jared Rhine has written a thorough and thoughtful post about what it means to be/run an “open service”. The OSAF QA team has built Windmill, a great tool for testing AJAXy web applications.

There is plenty of stuff going on in the various projects, and a lot of things left to do. We’d love to work with designers, developers, testers, and writers to bring Chandler to its fullest potential.

Dreaming in Code

2 Replies

Scott Rosenberg mailed me a copy of of his book, Dreaming in Code, as a thank you for an interview that I did with him. This is a book about why software development is hard, and it features the Chandler project as a case study. It feels odd to open up a book and see someone else’s description of part of your life. Of course, I wanted to know what Scott had written about me, so tracing through the index was the first thing that I did. It was interesting to see which events Scott thought were noteworthy: the half-phone/half-IRC demo, the 2005 PyCon sprint, and my memo to Mitch Kapor on the state of the OSAF communites. I was relieved to see that everything about me was accurate. Well, except for one small thing. In my initial mention, I’m credited with “some of the early work on the XML data standard”. I did work on IBM’s XML4J parser, which became Apache’s Xerces-J parser, but I never did any work on the XML spec or standard itself. About half of the book takes place before I worked at OSAF, and I really can’t comment on the accuracy of the stuff that happened before I got there. I wasn’t there, and while I’ve heard some stories I also know that there’s so much more that happened that isn’t in the stories that I’ve been told.

Unfortunately, Dreaming in Code leaves the reader hanging. Scott had to wrap up his book project before we were able to ship a version of Chandler suitable for general usage (there are bleeding edge people using it now), and we are still at least several months away from reaching that goal. One of the reasons that I came to OSAF was to build open source software that non-technical people would want to use, and I (and everyone else working on Chandler and Cosmo) am acutely aware that we haven’t reached that mark yet. Quite a bit has changed since Scott had to leave us, and he posted a follow up that tries to fill in the gap between when the book left off and the present, and Katie Parlante has posted a status update for all of the OSAF projects on the OSAF blog. If you are interested in how the story of Chandler and Cosmo continues, I think that the best thing to do is to look at the mailing lists for the Chandler and Cosmo projects, as well as the OSAF wiki, where you can be up to date on the latest developments.