01.22.07

Dreaming in Code

Posted in Email, Technology trends at 9:57 pm by ducky

This is a response to Joel Spolsky‘s review of Dreaming in Code, a book about the development of Chandler at the Open Source Applications Foundation.

I was at OSAF for two years. Many of the things Joel says are consistent with my view of how things happened, some are not, and some are fully correct but don’t tell the whole story. Some of the things people on the discussion group are speculating are wrong. I’m going to write responses down in no particular order with no particular story arc. I’ve tried to boldface the thesis topics of each idea.

(Note that I haven’t read Dreaming in Code yet, so am not commenting on the book, just Joel’s review of it and the comments on the discussion group.)

There was an implication that the people at OSAF were lazy and interested in doing as little as possible to keep getting their paycheck. I think that is a grave disservice to the people there. Getting a paycheck isn’t usually that difficult — especially for people of the calibre that OSAF could attract. Top coders want to ship stuff!

However… in a normal company, you have the VP of Marketing representing the customer’s interests and the VP of Engineering representing the developers’ interests (i.e. could it actually ship). The two act as check and balance, so that the customer gets something they want in a reasonable timeframe. Unfortunately, Mitch was acting as the VP of Engineering, and the VP of Marketing, and the customer, and the venture capitalist.

Furthermore, Mitch had been very successful. It seemed reasonable to believe that if he thought we should do X, we should do X. This meant that Mitch didn’t get particularly fierce pushback when perhaps he should have. For example, he was adamant that we should do Chandler peer-to-peer, without a server. Doing a collaborative calendar without a server is really, really, REALLY hard. He eventually clarified that by “server”, he meant “something difficult to administer”, and so OSAF started working on a server.

Mitch has many many many fine points. He is a good and caring human being. He is clever. He has an ambition to make the world a better place. However, he has also been very very wealthy for a very long time, and I think that Mitch’s environment has taught him that that he does not need to be particularly clear in his instructions.

If my husband says to me, “please get me a cake”, I’m going to insist that he tell me what kind of cake, what event it is for, how many people it is for, and when it needs to be ready, and where it needs to end up. However, if my Powerful Boss says, “oh yeah, and order a cake” right before she hops in a cab to go to meet with the President, then I’ve got to figure everything out myself — and I have strong incentive to do so. I’ll go find my boss’ calendar, look through upcoming events on the schedule, guess at which one is likely to need a cake, and phone the boss’ cook to find out what kind of cake the boss likes. If I am really on the ball, I might phone the other participants’ people to find out if there are any food allergies, likes, or dislikes. If I am good, my boss will come back and find out that in fact she did not need to give clear instructions; if I am not good and there is no cake, I most likely would (eventually) find myself no longer employed by Powerful Boss.

This vagueness might be acceptable for cakes, but it’s death for developing code efficiently. For example, Mitch said that by “server”, he meant “something difficult to administer”. Either he changed his mind or he just never realized that he needed to be clear that he meant “something difficult to administer” instead of “always-running software that responds to requests from other computers on the network”.

I think Joel was right that too many designers slowed us down. Something that made it even worse was that the team grew person by person, i.e. was not wholly in place at the onset. Every time we got a new person on the team, there was a significant adjustment period while they lobbied for their own ideas for how things could be done better. For example, Lisa Dusseault is a big WebDAV person. After she started, she lobbied for doing more with WebDAV, saying that Life Would Be Better with WebDAV. She convinced us, and we started doing a lot more with WebDAV. She was probably right, Life Probably Is Better. But changing things around certainly cost us some time.

I think Joel was too harsh on stamping. He is right that being able to send things around by email is not exciting. It’s going the other direction that is more interesting: taking email messages and being able to turn them into things easily. An email message might also be a task: “Could you please frizbat the hongtholt?” An email message might also be a calendar item: “Can we meet next Thursday at 12?” Yes yes, with Outlook you can drag an email message onto your to-do list or calendar, but you still have to (had to?) fill in all the to-do information by hand. Tedious. The text recognition was supposed to do that for you.

I have said before that current to-do list managers suck rocks, and email clients could be much better. Chandler in the Grand Vision would have / could have addressed those. However, we found out very early on that people didn’t care about to-do managers or email clients: in 2003, people’s pain was centered around calendaring: you really had to buy Outlook and run an Exchange server to get halfway decent one, and even Outlook was only halfway decent. There was not a way at the time for a small business or non-profit without an IT staff to coordinate calendars. Period. So we focused on calendaring, which IMHO was the least exciting and revolutionary part of Chandler.

Something that Joel doesn’t mention as being a barrier to getting help from the outside world was that in the time while I was there, we never had a contributor agreement/license in place. So Jane wants to contribute some code: what sort of agreement governs the code that Jane contributes? For most open source projects, that issue is just not thought about because there is no money involved. But with OSAF, there was serious money involved.

First, Mitch Kapor was (is) a wealthy man, and wealth attracts lawsuits. Second, OSAF pays genuine salaries. Third, the plan was always for OSAF to become self-sustaining by providing different (i.e. non-GPL) licenses in addition to (not instead of!) the free GPL licenses.

Hence, we couldn’t really accept much code without a contributor license. That didn’t get done, in large part because our counsel, Mitchell Baker was stretched waaaaay thin also running the Mozilla Foundation. (She’s now only running the Mozilla Foundation, and appears to be doing a fine job of that.)

(Side note — I was absolutely amazed at how much volunteer support we got for NON-coding tasks. From help installing our phone system to CSS stylesheet help on our wiki to advice on video capture tools, the open source community was breathtakingly generous.)

Chandler is an open-source cathedral, not a bazaar. It’s a very different way of doing an open-source project, but that is not inherently wrong or bad. You need cathedrals sometimes.

Finally: Chandler most definitely does have a mascot — one of Mitch’s dogs. 🙂

N.B.  I have zero negative connotations associated with the word “boss”.  It means exactly the same thing as “manager” to me, except is less formal and fewer syllables.  I thus forget that some people attach a negative connotation to it.  I meant no negative connotation in the Powerful Boss paragraph.

Permalink