Month: March 2004

Just listened to the preface and introduction to Lawrence Lessig’s Free Culture, as read by Kevin Marks and Ralph Levien, while working out on the elliptical machine. Bravo, AKMA for organizing this audiobook project! Here is a consolidation of the mp3 hyperlinks listed at AKMA’s page into an m3u playlist: lessig-freeculture.m3u. Doug Kaye reports the story in a segment of IT Conversations, including interviews with AKMA, Larry Lessig and Simon Carless.

Ed Cone: “Glenn Reynolds, one of the marksmen who has tried to shoot the messenger instead of discussing what it is that Richard Clarke actually has to say, now wants to ignore him.”

I’ve posted a plan for the infrastructure session to the BloggerCon II site. Dave has written elsewhere that BloggerCon shouldn’t begin an end with a day in Cambridge. Let’s get the discussion going beforehand and keep talking about it afterward. New webloggers, what features would you like to understand better? Experienced webloggers, what features would you like to demonstrate?

When I logged in this morning there was a BitTorrent window open and a copy of Free Culture on my hard drive. Simon put this Creatively Licensed work on LegalTorrents, and the Radio plugin did the rest. What a pleasant surprise! I seriously doubt I’ll have the patience or motivation to read the whole thing sitting at the computer, but the chances that I’ll go out and buy a dead trees copy just went up significantly.

Lessons from the 60s

Philip Greenspun cites the software engineering classic The Mythical Man Month today in a response to a question about open source. A key message of that book seems to have been lost on people who are using control arguments to talk down RSS.
In the book Fred Brooks develops the notion of conceptual integrity:

  I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas. (p. 42, 20th anniversary ed.)

You should be able to appreciate his point if you’ve spent much time looking through code that hasn’t been tightly managed, or that has been managed by a succession of different people with different ideas at different times. Such code is generally harder to understand and harder to program against than code that has conceptual integrity.
Brooks submits that

  Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds. (p. 44, 20th anniversary ed.)

This conclusion is entirely rational but also entirely at odds with those who advocate for a democratic software design process. In a recent Guardian story about Dave Winer’s RFC to merge RSS and Atom, Ben Hammersley writes that

  The style of the Atom project differs greatly from the RSS 2.0. Whereas RSS 2.0 is controlled by a steering committee of Dave Winer and two others, Atom has been developed by an adhocracy of interested developers, with decisions reached by consensus.

This statement is interesting. You could read a bias into the word choices, assigning negative connotation to the terms appearing around RSS (“controlled”, “steering committee”) and positive connotation to the terms apearing around Atom (“adhocracy”,”interest”,”consensus”). I think there’s something to this notion, at least in the author’s mind. But from a software engineering standpoint, you would assign the values the other way, because control by a few gives you a chance at achieving conceptual integrity.
We resist the idea, because we’re all brilliant developers and surely our feature ideas are worthy and should be included in the spec. But our gut feeling is wrong on this one. And I think the people in charge of Atom probably know this, even if they don’t talk loudly about it. You can’t have a vote on every feature. At some point somebody has to make decisions, and it’s better to have the same one or two people making all of the decisions guided by a consistent notion of how the system should work. The alternative is chaos.
This fact does not devalue the individual. Everyone should be able to air their ideas for consideration by the system designers. And the system designers should be able to incorporate or shoot these ideas down as they see fit. More importantly, there’s no reason that a person can’t be a leader on one project and a follower on another. Given that we can’t all be leaders, most of us are going to have to learn to be followers most of the time.
None of the above is it at odds with the idea of open standards. The Open Standards principles and practice document does not prescribe the number of people that get to design a standard, nor how those people should be chosen. And it shouldn’t.