Interviewers: Scott Swigart and Sean Campbell

Interviewee: Katie Parlante

In this interview we talk with Katie Parlante. In specific, we talk about:

• Open Source Applications Foundation and the evolution of Chandler
• Transition at an open source project when a founder leaves
• Chandler releases and feedback from users
• Maintaining inspiration and enthusiasm at OSAF
• On the necessity of bolstering the role of the designer

Sean Campbell: Would you take a minute and introduce yourself, and tell us a little bit about Chandler?

Katie Parlante: OK. I’m president of the Open Source Applications Foundation, and our main project is the Chandler Project.

Chandler is a “note to self” organizer. It’s a personal information manager that’s a desktop application and a web application as well. Both the desktop and the server are open source, so people can download the server and run it themselves. The project makes use of a bunch of different languages, including Python, Java, and JavaScript.

Chandler is the first open source project that I’ve worked on. I’ve worked for a bunch of startups, one of which was Kiva Software, which got bought by Netscape and then turned into AOL. Chandler has been like that kind of startup environment in some ways, and different in others.

Sean: Tell us a bit about the governance and community structure of Chandler. Is the majority of the coding done by a company? What’s the role of community involvement?

Katie: Most of the development and most of the work overall is done by staff members of Open Source Applications Foundation. We’re a non-profit organization that was founded by Mitch Kapor about six years ago. He’s since left the project.

Originally, the purpose of the foundation was to build on a big cluster of ideas he had to see what we could make of it. He hired designers and project managers and coders, and that really formed the core of the team that’s doing most of the work.

From the outset, he wanted it to be a non-profit, and he wanted it to be open source to play with the model of doing innovative software. At the time, he felt constrained by Microsoft’s position, although I think the software world has changed a lot since then.

He saw open source and a non-profit organization as an experiment in being able to innovate and not answer to VC’s like you would in an ordinary startup. You wouldn’t have the same kinds of pressures.

Of course, we have different pressures, but our ideal has always been to pull community in and expand. We’re a highly transparent project, and we have been from the beginning, so at this minimum level we’ve always gotten feedback from a wide community of people.

We have localizers who are volunteers. We have a users list, so the users are talking to the developers a lot. We get them to log bugs, and they give us feedback that we use to prioritize what work we do next. We also use it for ideas on how to market the product better.

All of our development work is done on the development mailing list, and so we have a handful of people who have paid attention to the project for a long time and do really heavy testing and bug logging. Their role goes well beyond being users–they’re pretty knowledgeable, and they help us with good bug reports.

We’ve had a couple of nibbles at people contributing small features. One person did a printing feature. We’re certainly encouraging that.

Sean: How do you think Chandler is uniquely suited to tackle organizing messages, ideas, schedules, and the rest? It seems like Outlook is the app that everybody loves to hate, and of course there are lots of others that people use as well, but where do you feel like Chandler’s headed that maybe somebody else hasn’t gone?

Katie: I think OneNote is the Microsoft product that Chandler is more like than Outlook. Certainly we got a lot of the ideas for Chandler in terms of looking at how people use email and calendars, but at the end of the day, the problem that we’re solving is to provide a better alternative than using Word documents, or Excel spreadsheets, or all sorts of other different products to solve the problem of collecting all the ideas in your head into one trusted space.

It’s what our designer called knowledge work. The goal isn’t elaborate project management or enterprise calendaring, but really this problem of evolving all of the loose ideas and things you need to do into tasks or actions you need to take, and saving all of that together in one trusted place. We look at this user problem more than trying to go after Outlook or trying to go after Thunderbird.

Sean: How did you parse what was out there in existing products that you found to be inspirational? One of the things that strikes me is that mindmapping fits into the schema you described, but I don’t see it in Chandler. You’ve got products like Mindjet and things like that, but is there a specific reason why it didn’t end up in Chandler, or is it just down the line maybe?

Katie: Some of us did look at mindmapping stuff–it just didn’t capture the imagination of the designer. I think her inspiration was really more how people were using email clients to manage tasks.

We’re also maybe not going for what we call a PIM geek, although PIM geeks try out all sorts of PIMs, so we certainly see them in part of our community. But we were really trying to design for a broader audience than that.

Mindmapping software also seems kind of alien to a lot of users, and so, I think we’ve tried to do innovative things that still look familiar and approachable. Also, maybe it’s a matter of doing the things that seem like the basics first.

Scott Swigart: A lot of open source is sort of by developers for developers–they’re building the web server, or kernel, or the developer tools they want.

The expectation for those kinds of projects is on those is that, if someone suggests an idea for a feature, they will also be the one who builds the code. I would guess that for Chandler, that’s not the case. What sort of structure have you set up so that mere mortals can suggest great features and see it show up in the project?

Katie: That’s one of the important reasons we have a staff, because you’re very right that that’s an issue for any kind of consumer open source project. For the developer-to-developer projects, people contribute because they want to scratch an itch. And to torture the metaphor, no one wants to scratch someone else’s itch.

There is a tension in designing usable open source software, where one usability tenet is that you are not your user, so you can’t just assume that what you want is what your user wants. You have to listen and pay attention to the needs of people who aren’t just like you. It can be a challenge to reconcile those things.

I think there’s an ideal that if you have a piece of software a bunch of people are using and that is considered successful, and you’ve painted this vision, and you’ve motivated people, then developers might show up and want to help solve problems for other people.

We’re hoping that can work. In terms of how the process works for us, we have a designer who is really in charge of the design and in charge of prioritizing work according to what users need or have recommended.

We get that information from the user list, but even that user list is probably a little bit biased. It is only people who are willing to sign up to a mailing list and participate, so that cuts out a whole swath of users.

Scott: I’m interested in what happens when a signature founder leaves an open-source project. Linus would of course be the classic example of a founder like that–no one’s immortal, so everybody knows one of these days, for whatever reason, Linus is going to back away and give over the reins.

Part of the issue is that it’s different than in a commercial model where you’re all on the compensation plan. Losing an inspirational founder with the backing that Mitch had, how does the group navigate that change, in terms of losing a chief evangelist as well as a person who may have been able to pull off certain things just by the weight of being around?

Katie: I think Mitch leaving was much more analogous to what happens when the founder of a startup leaves. He certainly set the original vision and pulled the original team there, but he did not play a role like Linus at all. He wasn’t coding, and he hadn’t been directly involved in the project for a couple of years actually. I was meeting with him every week, and he was coaching me and coaching the project.

He participated as a user, but he wasn’t participating in daily decisions. Maybe as with any organization, he had handed off responsibility to other people. He played different roles at different times, but by the time he left, he handed off the running of the organization to me and the design to Mimi, the designer.

Of course, his leaving was a big PR event, and it has had a financial impact on us, given that he’s been the primary funder of the project. The plan all along was for the project to become self-sustaining–Mitch had no intention of funding the project forever.

Scott: How does that work, because that’s the other side of it. There’s the challenge of being an open source project but needing money so the developers can keep developing, and there’s that delicate balancing act of not selling your soul to corporate sponsors at the same time. How have things changed in terms of those challenges?

Katie: We’re currently subsisting on a final grant from Mitch. We have to figure it out, and frankly we don’t know the answer of how we’ll stay funded. It might be that the project will have to merge with a different project. We’re looking at grants from different sources, or we could complete a 1.0 and go more into a shell mode, so basically look more like an organization that’s not paying developers and is just proceeding with volunteer efforts.

Another aspect is that, in addition to the 10 engineers on staff, we have very strong participation by volunteers who left the organization but are still interested in the project and helping out. They’re certainly not helping out as full time employees, but they helped with the build, they help answer questions on the mailing list, they do localization, and they participate in lots of other ways.

So, if we all needed to go get other full time jobs, we could still carry on with the project on our own time.

Scott: What other projects do you look toward as inspiration in the face of that transition? What do you think would be valuable to borrow from other open source projects, like maybe the way they handle governance or the flow of user input? When you look out at the open source community, who are you inspired by and hope to emulate as part of Chandler?

Katie: We’ve been inspired all along by Mozilla, partly because there are people who work at OSAF who are from Mozilla. The folks on our board are from Mozilla, so we know them well.

We’ve seen them go from being kicked out of AOL and starting their new foundation, through hard times to be a huge success now. I think that OSAF has always felt more like a Mozilla than like an Apache, and so we look to them for certain kinds of decision-making or governance principles.

A good example is that with Apache, decision is made by consensus. People are committers on the project, and they vote. Anyone can stop a decision, and people are expected to do that responsibly.

At OSAF, we have found that more of an ownership model works better for us, especially with this design issue where we have the designer looking out for the users’ interest, paying attention to all of the pitfalls that developer judgment can have.

So we have people enrolled as owner/drivers in certain areas, and there’s a cultural responsibility to build consensus and take input from other people, particularly stakeholders. That’s another role in project decisions.

But it’s not quite the same as having the whole organization or the whole project agree on every decision. I think that works pretty well for Apache in a lot of ways, though–there are different kinds of projects than the project we have.

Scott: Can you speak to some of the things that are currently going on in the project from a development standpoint and in terms of features and things like that? And what was the genesis of those?

Katie: Sure. Last September, we did a big “preview” release. We’d had other releases we tried to get people to use before, but that was really a big threshold for us. We said, “Put your data in it, trust it, you can use it. Go for it, and give us feedback.” We debated whether or not we should call it a beta versus preview, but it’s similar to a Google beta.

All of what we’re doing now is informed by what we saw users do with the preview. On the desktop, we saw that some people using it are really excited about it, but some people who we thought would be interested were a little bit put off when they first downloaded it and didn’t know what to make of it. Or they felt like, “Oh no, I have to use some rigid GTD system. I don’t have time to learn and I don’t want to do that,” which was really not what we were going for.

So one of our big efforts was to strip away some user-interface elements that we had really put in there as a plausible promise of future features to come. We pulled away any UI where the back end or the whole functionality set wasn’t fleshed out.

In particular, that meant email. We left some of that behavior either in the detail view or in menus, but not in the main toolbar. So it was more obvious what the product was for when the users first launched it. We also did a few other things to reduce the number of concepts that the users had to learn right away to get started.

That’s been helpful in making Chandler feel more like a note organizer and less like a rigid task project manager. It also helped users who felt like items had to be tasked, which really wasn’t our design. An item could be a project or a task or an idea or a note, not necessarily something that’s done. So, that’s simplified the UI for the user right out of the box, and we’ve also fixed a whole bunch of bugs that users ran into.

On the Web side, we’re focusing on “web widgets”, which are basically little bits of Web functionality that can appear in different contexts. So one of them could be on our web site, or it could be in iGoogle, or it could be that it’s tailored for the iPhone, or an OSX dashboard widget, and so on.

Basically, we can’t expect people to jump wholesale into using Chandler all day long. (Though certainly, that’s when it’s most useful.) So we need to find ways to give people access to Chandler data when they’re not in Chandler. This includes widgets to enter items quickly from different contexts, notifications and reports of what’s been going on in shared collections and what’s coming up. We also wanted to help people who were using Chandler share their data with other people, with very low overhead. So one of the widgets is just the data for one item and the detailed view for one item, to make it easier for someone who’s using Chandler regularly to share one little interesting piece of functionality with other people.

Sean: On a lot of user-facing projects, when the application meets the users, some of the feedback is probably what you expected, and some of it’s not.

Sometimes there are also lots of internal debates about how to respond to certain things. Is the engineering team fairly multidisciplinary? Do you have people who focus more on usability, and other people who focus more on coding?

Katie: We had a 27-person team before the transition, which included a QA team and a build release team. Then we had a group called PPD–product planning and design– and then the engineering team. In a way, it looked a lot like a startup of similar size, except for no marketing organization or sales organization.

On the PPD team, there’s one product designer, Mimi Yin, and it’s her responsibility to look at usability in addition to the whole product design.

We had one program manager, Shelia Mooney, who worked a little more on the project management end and kind of formed the bridge between Mimi and the engineers. We had two development managers, managing development in the two engineering teams–one for the desktop and one for the web.

With the new slimmed down team, I’m the only manager, and the team is flat. Mimi’s stayed on the team, in the same role, although in a way there’s less to that role, since a lot of the product design is done compared to what she had to do at the beginning, so it’s really a lot more about usability, outreach, and marketing.

Sheila is turning more to marketing and business development, and helping me to figure out how we can keep the project going. Instead of a dedicated QA team, that role is filled by the developers, Mimi, Sheila, and I. We have five developers–one on desktop and the rest on the web. They’re expected to have some kind of knowledge of the importance of usability and the importance of paying attention to the user, but they’re really more focused on coding.

It’s part of their responsibility to help users on users’ lists, et cetera, so they do jump in, and really any design decision ends up being a collaboration between Mimi and developers, as well as individual users who bring up interesting problems.

Developers pitch in what they think is happening and give different ideas. And Mimi might have a different take about what the root problem is, and get the conversation focused on what they were trying to do and why there’s different possible solutions that are going to be coherent with the design.

Sean: You mentioned that you guys get some inspiration from Firefox and Mozilla, and you’ve got roots in Netscape as well. When we talked to the Firefox people, one of the things they mentioned is that people kind of thought that Firefox came from out of nowhere overnight, but the team had been working away for a long, long time before that.

As an open source project that’s looking for the lily pad to stand on, you are going through some struggles right now, and the future isn’t 100% certain, as you’ve said. What do you look for at a time like this, and how do you keep the team focused on as you go through a challenging time with the project?

Katie: I think the thing that keeps us going is the comments from the users who are happy. I mean, they might not be happy with that bug or this or that problem, but their overall excitement and enthusiasm for the project is really heartening. I think that positive feedback is an important benefit to working on a transparent project–open source or not.

Knowing the story of Mozilla and Firefox, and knowing that they spent years working on the Mozilla codebase, and knowing that people were harsh on them for not living up to expectations helps, in terms of having a sort of success story. It’s dangerous to make too much of that analogy though, because in many ways they’re in a very different situation. The project they’re building is very critical–keeping the web free and open. That’s how they see their mission, and that’s what keeps them going.

Our motivations are less political that that, and our inspirations aren’t all really open source projects either, per se. They’re just projects that have good design. I think Apple is a huge inspiration in a lot of ways. They’re doing all these interesting things with the iPhone, and they’re pumping great apps out at a rapid pace.

The experiment is to do good design and good things for users and innovate in an open source atmosphere, though I don’t think the success or failure of our project is the last word on that kind of experiment. There are all sorts of other dynamics going on, but certainly happy users motivate us.

Sean: It also seems true that, while on one hand there are some struggles, on the other hand, there was once no such thing as a spreadsheet, and then everybody used them. Is there some feeling that what you are working on is the next thing that could become part of the everyday repertoire of information management apps?

Katie: Yes, there is that sense. Mimi has made the analogy that, when email first came out, a lot of people said, “Why would I use this? This isn’t interesting to me.”

We’re hoping that we’ve at least moved the peg a little bit in terms of the kind of tools that could help people use the computer to manage information.

Sean: Is there anything that you’d like to add to the conversation that we haven’t gotten to?

Katie: I touched on this in some of the other answers, but I think one of the really interesting things that’s happened with the project is addressing how to do application design in an open source project. We don’t see a lot of models for that in other open source projects, and we feel like we’ve been charting our own course there.

The governance models of open source projects tend to focus on harnessing the efforts of developers who are building something for themselves or their company and want to collaborate. Finding good ways to give designers the kind of credit and authority they need can be tricky.

Many times, developers want to just reflexively respond when a user speaks up and asks for a feature or a change in functionality. Similarly a volunteer developer might show up with code they want to add that does something they want as a user. It’s tempting to use those kinds of things as your decision criteria, but that tends to just pile things on top of the existing design and compromise its integrity. It’s difficult to take advantage of that energy while still achieving a high-quality design result.

Another aspect that’s difficult is to get consensus among a bunch of developers to take a novel approach toward something that there’s already a well-established model for. For example, we all tend to think that a proper email client should have this or that feature, because all email clients have it.

If you’re really trying to change a paradigm, or try something new, or do something different, it might be risky. If you have consensus decision making, anyone can object and bring that down. Creating an environment where the designer can take some risks and do something different is very hard.

Sean: I’ve heard people say more than a few times–and I tend to agree–that one of the reasons Apple has been successful with the iPhone and where they’ve headed more generally is that there’s kind of a benevolent dictator of design. If it doesn’t pass the black turtleneck, it just doesn’t pass.

Do you find that you have to have the same thing?

Katie: Absolutely. Mimi fills that role, and that puts a lot of weight on her, but at the same time, she’s not doing her job if she’s not paying attention to what developers and users are telling her. It’s really her job to synthesize that input with the overall design.

It’s not that developers don’t have good design sense. In fact, many of our developers came to the project with a lot of interest and experience in user interface design. It’s more a matter of maintaining checks and balances. When you’re responsible for making the code work, it’s hard to see problems from the user’s perspective. The same person that’s working to make the code performant and bug-free can’t also be the person that’s standing up for what the user wants and needs. Programming and user needs are too often at odds, so you need different people standing up for different interests.

Sean: What do you think are the key lessons learned if another open source project had a similar vision where usability was key? What are a few things you would tell them, if they were starting out tomorrow?

Katie: I would bring people with user experience design into the project, and I would give them authority. I think it’s really critical that they aren’t subservient to the developers.

The designer’s role, even if they’re not writing code, really needs to count and have decision making authority in the project. I’m sure there are different ways of doing that, but at the end of the day their design sense needs to carry weight in how decisions get made. And I think the project needs to respect the background that they have, so they aren’t put in the position of justifying themselves to developers who then get to make the decisions.

Sean: I applaud what you’re trying to do, because there’s obviously a big hole in the ocean that needs to get filled. The mail client doesn’t really fit and other things don’t really fit. Everybody knows it and they try to band aid it, and it’s great that you’ve taken that challenge on.

Katie: Thanks. I’ve enjoyed talking with you.