CIO Insight: The Chandler project was launched a few years back, when peer-to-peer networks seemed like a good Web alternative. Reading your book with the benefit of hindsight, I thought, uh-oh, this isn't going to end well: These guys were developing at a point of technological change. But your book says that's always going to be the case.

The ground is always shifting. If you try to follow the changes too closely, you will get into trouble, because things keep changing. If you have a project that takes a few years, and you change every six months, you'll get even deeper into a hole. So if you're going to be ambitious and make a big bet, how do you protect against that? The agile movement says to keep horizons so short that you can always change course, and I think there's a lot of good sense in that. We may know that our ultimate destination is that far-off mountain in the distance, but we're going to keep our heads down and just get through the next hundred yards, see that it's working, and go from there. Break things up into small bites. Any opportunity you have to do that should be seized.

CIO Insight: So you endorse an iterative process of release, test and improve, rather than going for a grand-slam introduction of something new and huge and finished?

If we try to design a system that is fully featured and complex and does everything everyone wants it to, we'll never have any system. You can take that same argument and support it with the history of the Internet itself. There are all kinds of amazing and wonderful schemes people had for hypertext environments, and they were very cool and exciting—and then the one that got widely adopted was this very simple HTTP thing. A lot of people thought HTTP was too crude and didn't fulfill the highest aspirations of the software field. And yet here it is, it worked. People understood it, they used it, and it was widely adopted too quickly for the perfectionists to kill it in the cradle. That's a good thing. The fact that the system in its initial deployment did not live up to ideals of perfection mattered far less than the perfectionists said it would.

CIO Insight: In your book's narrative, Kapor's team seemed to dither a lot. They spent a long time doing stuff that I would think you'd do before you really started. It didn't always seem like an engineering project to me.

It was a matter of ambition colliding with practical reality. One reason the whole engineering approach has proven so difficult for the software field is also one of the unique things about software: Once a particular problem is solved, it's almost infinitely cheaper to use the existing solution. There's no cost to make additional copies, and the cost of creating a new piece of software is huge, so once there's a dominant product, there is no reason to write your own version. Even at Microsoft prices, it's cheaper to use Word than to write a new word processor. The only real reason that a team gets together and writes a new piece of software is that they want to do something new, something another product doesn't do, whether it's to add a feature, or to be compatible in a different way with another system.

In the case of Chandler, they had a number of really interesting and ambitious ideas about flexible data, and having a system with an almost spreadsheet-like fluidity that applied to e-mail and calendars and other kinds of personal information. That was an extremely ambitious goal. What you saw there at the beginning of the project was not dilettantism, but people whose job it is to solve hard problems tackling problems that were just too big.

CIO Insight: So is your book a cautionary tale? Where will Chandler end up?

Nobody knows. There are few different scenarios. One is that it will be a respectable footnote in the history of open-source software, but it won't really take root, because so much has happened in the ensuing years. Another possibility is that some small piece of it will turn out to be incredibly useful in some other product. That's one of the things that happens in open source that make it so flexible and gives it a lot of staying power. They're doing a lot of interesting work at the Open Source Applications Foundation. Maybe an underground development will emerge; maybe Chandler will be like a rock band that was respected even though nobody bought the records, and then, years later, 50 bands show its influence.

Mitch [Kapor] is determined and persistent. They plan to ship the calendar in the first part of 2007. It could be that, in a few years, as everyone's coming down off the Web 2.0 high, people will discover it's an interesting, flexible product. It happens: Look at Firefox. Mozilla was written off, Internet Explorer had won the war, it was done, finished, end of story. And now look at it.

1 | 2 | 3