virtual community or butter? (bumbaugh) Mon 19 Feb 07 07:42
The Inkwell is pleased to welcome longtime Well member, Scott Rosenberg. Scott Rosenberg is a writer and editor who cofounded Salon in 1995 and is the author of "Dreaming in Code" (Crown, 2007). He served as Salon's first technology editor, became managing editor in 1999 and served in that position through 2004. In 2005 he took a leave to write "Dreaming in Code" and returned to the company in 2006 as vice president for new projects. Before Salon he worked as a critic for the San Francisco Examiner for a decade, first as its lead theater critic (his work won the George Jean Nathan Award in 1989), then lead movie critic, and finally digital culture columnist. Before joining the Examiner he wrote theater, movie and book reviews for the Boston Phoenix. Christian Crumlish, who will lead the discussion with Scott, has been analyzing application interfaces since 1987, writing about the social implications of technology since 1992, and developing interactive experiences since 1994. He is the curator of the Yahoo! pattern library and he currently serves on the board of directors of the Information Architecture Institute. He has consulted with startups and Fortune 500 companies, including FedEx, Kodak, Visa, Sprint, Charles Schwab, Safeway, Sun, SanDisk, BEA, HTC, Aramark, MediaMelon, Syklist, and GoFish. He is the author of, most recently, The Power of Many: How the Living Web is Transforming Politics, Business, and Everday Life. Christian earned his bachelor of arts in philosophy from Princeton University in 1986. He is the host of the Blog conference on The Well, contributes to You're It! a blog on tagging, and presents other slivers of his identity in blog form at X- POLLEN. He lives in Oakland, California with his fiancÃ©e, Briggs, and his cat, Fraidy. What's up, you two?
Christian Crumlish (xian) Mon 19 Feb 07 10:48
Hey, Scott! I know this book was several years in the making. (I remember when you announced on your Salon blog that you were taking a sort of sabbatical to research a book.) I'd love to start off with the genesis of the project: What was the original inspiration for the book? How did you pitch it to your agent? How did the book's concept evolve over time (if it did)? At what point in the project did the title occur to you? At what point in the writing did you feel like you knew what the lesson, or moral, or meaning of the book was turning out to be?
Clamping down on the internets (scottros) Mon 19 Feb 07 20:34
Five questions in one! I'll try to work my way through, one post per question. First, though, let me just kvell a bit over my own trajectory here. I got my first real online experience on the Well 15, 16, 17 (?) years ago, reading lines of type slowly scrolling at 300 baud. So being here talking with folks about my first book -- it's good. Thanks to inkwell and to everyone at the Well for inviting me to do this. DREAMING IN CODE started, as I describe in the introduction, with my experience as one of the managers of Salon's initially ill-fated redesign project that launched in May 2000. It was the height of the bubble (in retrospect, it was clear that the bust was just beginning as we were struggling to deploy our project, in fact). We made the mistake of tying a total overhaul of Salon's design to a total revamp of its content management software, and then tying all that to several major business initiatives that had calendar deadlines. And the whole thing turned out to be a disaster on launch (though, after several weeks' chaos, we began to clear the rubble and ended up with a perfectly good content management system that we're still using today!). I'd become a father of twin boys six months before, so my memories of that era are filtered through a haze of vague euphoria cut with massive amounts of sleep deprivation. But I definitely felt stunned and bruised by my software-disaster initation: How could this happen? I figured I was just a writer, ignorant of the actual practice of software development and surrounded by people who were talented but green; so I did what I've always done in such situations -- I hit the books. I went and read Frederick Brooks' THE MYTHICAL MAN-MONTH and had the little epiphany that the kind of endless-delays-leading-to-train-wreck-deployment experience I'd been through was what people in the software field had been experiencing at least since Brooks' day, at IBM in the '60s. Even though there were plenty of mistakes we'd made out of our own ignorance and inexperience, knowledgeable veterans hadn't licked the problem, either. I'd toyed for years with the idea of some kind of book about programming and language -- I had a whole folder of code snippets in different languages, I'd been imagining something very artsy and fun but theoretical. But this problem struck me as a better book idea. I didn't want to write a how-to book (plenty of good ones out there already), and I'd always aimed my technology writing at the overlap between the circles of interested outsiders and generalist insiders. Even though most of my journalism has been criticism and columns, for a book I felt that the best approach would be a good old-fashioned narrative spine, cut with more essay-like background material. My initial thought was, I'd go find a half dozen projects and tell their stories and weave the narratives together creatively and use all that material as a way to look at why software is so hard, and what avenues people are pursuing today to make things easier. Around that time -- this would be fall 2002 -- Mitch Kapor announced the Chandler project: open-source, cross-platform, peer-to-peer, free-form personal information management. I'd long been interested in the whole PIM field, I'd written several Salon columns about it. I'd never met Kapor but I knew and admired his work. I thought, perfect, this will be my first project. Kapor was cautious at first but basically open. Once I started following the work on Chandler, in early 2003, I realized how insane my six-projects-in-one concept was: Too Much Information. One project was already pushing my limits. Multiple projects would be too much even for me to get my head around, let alone ask a reader to follow. And Chandler seemed like it had it all: an interesting cast of characters (with names at least some potential readers would have heard of, like Kapor, Andy Hertzfeld and Lou Montulli), an interesting problem to solve, an ambitious set of goals. I felt confident I could use it to get at most of what I wanted to get at. I was up front with Kapor and the rest of the people at the Open Source Applications Foundation about the change, and I think by then they'd seen enough of me to feel they could trust me to tell their story fairly. This was spring 2003, when the Iraq invasion was unfolding, so the joke became that I was an "embedded journalist" in the software team. I'm afraid that in retrospect it's a bitter joke, because both the Iraq fiasco and the Chandler project dragged on years longer than anyone expected or planned. But fortunately the parallel does finally collapse, since, as of today, unlike the U.S. adventure in Iraq, Chandler at least still holds the potential for a positive outcome. OK, that's a full essay just to answer the first question. I'll tackle the others more concisely in a next post...
Christian Crumlish (xian) Mon 19 Feb 07 22:53
go long if you like!
Scott Rosenberg (scottros) Tue 20 Feb 07 10:56
That's a dangerous invitation :-) As far as pitching it to my agent: this was 2003, in the trough between the bust of the old Web bubble and the rise of the new Google-fueled Web economy. So at that time the New York media world, of which book publishing is a subcategory, was pretty down on technology and technology books. I had to make a case that seemed transparently obvious to me -- that software runs our world and its problems are our problems. The good news is, my agent was (and is) both thoughtful and patient, and I worked for probably six months on the proposal -- first by myself and then with him. We didn't take it to publishers until around March 2004. The evolution of the concept I think I covered above. Once we had the proposal I really stuck close to it: I would tell a tale (about Chandler) to try to answer a question (why is it so hard to make software well?). I conceived of the title very early on, even before I connected with the Chandler project. It just seemed a great, pregnant phrase; it contains multiple meanings -- a dream communicated or expressed via code; the actual experience some programmers have of seeing computer code in their dreams; "dreaming" as thinking bold new thoughts and "dreaming" as the opposite of acting in a concrete way. The subtitle, on the other hand, took forever to nail down. I originally wanted something simple and declarative, like "Dreaming in Code: Why Software is Hard." But wiser heads -- mostly, that of my wonderfully talented editor, Rachel Klayman -- prevailed on me to use the subtitle to communicate to people that the book indeed tells a story, of people struggling with technology. One day I was idly scrolling through my RSS feeds and I noticed the title of Julie Powell's book, JULIE AND JULIA -- she was a blogger in the old Salon blogs program who'd cooked her way through Julia Child's cookbook, and turned that saga into a book. Powell's subtitle was "365 Days, 524 Recipes, 1 Tiny Apartment Kitchen," and that inspired me -- so thank you, Julie! (Only now I notice they've actually changed her subtitle for the paperback edition, to "My Year of Cooking Dangerously.") It just took a little time to fine tune the details to end up with "Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software." I document and explain those numbers in the book's endnotes, which are all online over at http://www.dreamingincode.com/endnotes/ To the last question, at what point I felt like I knew the "lesson, moral or meaning" of the book: For me, that's a more challenging question than it seems. I've spent most of my writing career as a critic and a columnist. I'm used to trying to derive lessons and meanings in 1000 words, and I think at times I've been pretty good at that. But for this -- my first book after two decades of full-time professional writing! -- I really wanted to do something different. The nonfiction narratives (and indeed the fictional narratives) that I admire most deliver their stories without any pronounced underscoring of "lesson, moral or meaning." The story stands as what it is and the readers come to their own conclusions. Of course the story's shape will point people more in one direction than another; but there's always room for multiple interpretations. That's what I hoped to achieve with DREAMING IN CODE: I wanted the story to illuminate a certain abstruse realm of human creativity, and I intended to leave room for different readers to draw different conclusions. Of course there are some broad and relatively obvious points: it's likely, for instance, that most readers of my book will conclude that one should be careful about starting a software project with too broad and vague a set of ambitions. But I'm finding, happily, that readers are identifying all sorts of other, less obvious, and sometimes conflicting, lessons in my text. That makes me smile; it tells me I might have managed to write something more complex than a 1000-word essay or column, something that might be worth a reader's twenty bucks. Of course it could also mean I just wasn't clear. But I'm optimistic that this is the valuable and interesting species of ambiguity, not the kind that just leaves you scratching your head.
Christian Crumlish (xian) Tue 20 Feb 07 15:34
That's a great answer. I think that is one of the rewards of longer-form writing, that the work makes its own connections in your readers' minds. You do not have to consciously explicitly place each nugget of goodness there for them to find. I asked about when you discovered the meaning not so much to reduce things to a moral but out of sense of curiosity about how the story hung together for you in the writing. By analogy to the only nonfiction book I've written (not counting how-to/manual type stuff), I completed a first draft before I really knew what the point of the thing was. Then I went back and rewrote it with those insights in mind. We were actually starting our books around the same time and I remember being envious that you had more time for yours (mine needed to be out before the 2004 election). But enough about me... Re the title, I think all those potential meanings come across, though for me the dominant one is the idea of a programmer working so hard that he (or she) is seeing code in their dreams, like the way one used to see tetris in the rivers of white space on a book page or on one's eyelids when falling asleep. Anyway, you've assiduously caught up with me, so I can no longer coast on my original spate of questions. So now I'll steal a question from our host Bruce. He said, "I'm struck by the interweaving of a more-or-less general theory of software development in amongst the OSAF and other test cases. It's in the end, a very rich book for this," and Scott I know that some readers have suggested that Chandler is such a special case that you can't generalize from it, or Chandler has failed so it's not a good case study, and so on Is there more to this story than "what happened to Chandler"?
Paulina Borsook (loris) Tue 20 Feb 07 18:46
scott, when i heard you were working on this project, i immediately thot of 'the soul of a new machine' and 'the inmates have taken over the asylum'. did you read these are part of yr prepwork for the project? or avoid them, so as not to contaminate your own vision?
Scott Rosenberg (scottros) Tue 20 Feb 07 19:59
[Paulina slipped while I was answering Christian, so I'll return to her question, but first, answering post 5, " Is there more to this story than 'what happened to Chandler'?"....] I certainly hope so! It's funny, I always knew that trying to do *two* things at once in the book -- tell a story AND answer a question -- was a risk. If I didn't play it right, it would just be a mess. And even if I did pull it off, inevitably the readers who loved the story might be bummed that I was departing from it to explore some history or background or theoretical question; and the readers who loved the history and the theory and the quest for answers might find the story a distraction. That Bruce and others have found the result rich tells me that there's some group, at least, for whom I hit a good balance. You know, even though this was my first book, I've been writing all my life, I'm 47 now (I was 44 when I got the book deal), and I was determined, at this stage of my game, to attempt something difficult -- not for stunt value, but to hold my interest and, I hope, a reader's. So it was always "more than just Chandler." The book is structured around each phase of the work at OSAF that I observed -- from choosing a programming language and toolset to building a back-end to designing an interface to figuring out how to manage the team and schedule the work, and so on. I tell the story of what happened at OSAF and then dive into the "more than" stuff: the history of that activity, some examples of other approaches, ideas people have had to solve that piece of the problem (and why those ideas have or haven't changed things for the better), and so on. In my chapter on reuse, for instance, I have a long discussion of the dream of a "Universal Snap-In Software Kit," exemplified in the work of Brad Cox, and I ponder why it is that software developers often seem to prefer to write new code from scratch. Or in my chapter on programming languages, I discuss the rivalry between the Perl and Python camps, with reference to the different personalities of those languages' inventors, and I use that as a way in to the whole programming-language-as-religion thing. I wanted the book to be an accurate and entertaining portrait of programming culture. Who are the people building the stuff our civilization runs on, and what are they like? Chandler gave me tons of great opportunities to go down those side paths. I have to say, there aren't too many actual readers of DREAMING IN CODE who've suggested that Chandler is too special a case to generalize from, etc. There's certainly a lot of comment out there on Slashdot and such from people who *haven't* read the book who just dismiss the OSAF team as a bunch of fools. But those who've read the book, I think, see that the Chandler developers are, for instance, wrestling almost from day one with the question of whether the client-based approach (their original choice) or a web-based application would be the best route. They were totally aware of these issues and grappling with them throughout. You can certainly criticize some of the decisions they made, but I don't think anyone can write off their story as irrelevant, simply because thy had so many problems. And, as I repeat whenever I get the opportunity, while Chandler is certainly not a success as of this moment, I don't believe it can or should be written off as a failure -- anymore than Mozilla should have been written off as a failure in the pre-Firefox days. It would have made a more conventionally "good" book if I had a story of triumph to tell. I think that's what a somewhat cranky reviewer in the Financial Times wanted: a code-slinging "Rocky" of some kind. For me, though, the difficulty and the incompleteness of the Chandler story -- while maybe less satisfying for the reader seeking a traditional payoff ending -- ended up being apt and true to the subject. Projects have problems. They take longer than planned. They face tough choices about scaling back their ambitions. This isn't atypical. This is the norm. This is reality. And I've always clung to the belief that reality is interesting. Trying to portray reality is worth one's time.
Scott Rosenberg (scottros) Tue 20 Feb 07 20:08
As for Paulina's question: "The Soul of a New Machine" certainly hangs over my project as an inspiration and something of a problem. An inspiration simply because it's such a great book, it's still fun to read, it introduced a whole generation to the idea that the story of computing is worthy of attention, it's not just plumbing, it's smart people struggling with difficult creative problems. A problem because, you know, Tracy Kidder basically lived with the people he wrote about, and he told the story in a kind of personal way that I was never going to be able to achieve here. So if people were expecting that from DREAMING IN CODE I was going to disappoint them. Also, it's 25 years later, our whole relationship to computing is way different now -- it's not a strange new world for us to be introduced to, it's part of our lives, and we know it as a tangle of problems that are *our* problems, too, not just strange dilemmas facing somewhat strange guys at companies in places like Route 128 and Silicon Valley. Anyway, yes, I reread THE SOUL OF A NEW MACHINE in 2001 or 2002 as my book was gestating in my brain, and then put it down and didn't look at it again. Alan Cooper's THE INMATES HAVE TAKEN OVER THE ASYLUM is a wonderful rant that I refer to in a couple of places in DREAMING IN CODE -- so yes, I read it, too. It's a great argument about the problems with software, and I went and had a great interview with Cooper after reading the book, but I found his argument difficult to connect with my narrative, and I tucked the interview away for possible later use. I'd still like to see if I can turn it into a separate Salon piece. He's got some fascinating insights, but I just couldn't figure out how to get them into my book, and I figured he'd already had the chance to present his perspective at book length!
Paulina Borsook (loris) Tue 20 Feb 07 22:09
yeah, i always thot kidder's book was interesting for some inobvious ways: - how do you write about technical stuff and make it interesting without heroizing everyone and making them larger than life? (the FT 'rocky' problem you refer to). i think kidder is guilty of this, but it makes for entertaining reading - and, if i remember correctly (i read that book LO so many yrs ago), the final product wasnt some amazing paradigm-smashing thing --- and DG is obviously not around any more. so, in its way, not that different from chandler. but kidder sort of cheater by making us fall in love with his team and their challenges... scott, are you noticing a difference between how the non-technical community vs the technical community is responding to your book?
Christian Crumlish (xian) Wed 21 Feb 07 08:00
I love the digressions in the book, btw. The analogy may be strained but in an odd way they remind me of Moby-Dick, with its tangents on ropes, sailing, whales, weather, and so on. Early on in reading the book I had a moment of delight when I realized that you were systematically explaining most of the shared "folkways" of computer geeks, if I can call them that. After years in the geek blogging world I was aware that most of these metaphors and ideas and memes were commonplace among alpha nerds but completely greek to ordinary people. Here I feel like you have opened up an fascinating world to outsiders by explaining these things in humane terms. One thing that can make that sort of task difficult is the fact that once you learn something it's easy to forget what it was like before you knew it, or to empathize with people who have not yet heard of or internalized it. Teachers have to deal with this all the time. Was that a challenge for you, discovering the fascinating edge between what you knew and what your readers might not?
Cynthia Dyer-Bennet (cdb) Wed 21 Feb 07 09:17
(NOTE: Offsite readers with questions or comments may send them to <email@example.com> to have them added to this conversation)
Scott Rosenberg (scottros) Wed 21 Feb 07 09:43
Paulina asked above about the difference between responses from technical and non-technical readers: Since the book has been out under a month now, most of the reactions to date are from the former. My hope of course is that over time the book will find its way to more of the latter. Technically-oriented readers are my early adopters, though! Inevitably among them there is a range of reaction, with a significant number of people who -- understandably -- are looking for answers, guidance, bullet-points or "take-aways." And DREAMING IN CODE is probably frustrating to them. I'm hoping that at least some will come looking for quick fixes but go away with a richer or more subtle understanding of their field. My dream for the book is that developers might read it and feel that their work has been represented faithfully and entertainingly enough that they might want to hand it to a relative or friend and say, "Here, read this if you want to understand what I do all day" -- or, "If you want to know why you sometimes see smoke rising from my forehead, this might help." Christian, I'm delighted that you mentioned "Moby Dick." No, I don't think Mitch Kapor is an Ahabic figure, he's quite the opposite in leadership style. But in mixing up storytelling and descriptive material I definitely had that model in mind. And I loved Melville's chapters on whaling at least as much as the ones that furthered his tale. In my English studies we called this the "encyclopedic narrative." It actually goes back to the epic poetry tradition. (Attentive readers will notice that I begin the book *in medias res*.) This is what I told Jim Fallows when he asked me (while talking to me about a piece he was writing about Chandler) whether DREAMING IN CODE was comedy or tragedy. I puzzled for a minute, then said, "Neither -- it's an epic!"
Scott Rosenberg (scottros) Wed 21 Feb 07 09:51
> Was that a challenge for you, discovering the fascinating edge between what you knew and what your readers might not? Definitely a challenge to make sure that my immersion in all things Web, which has been total since late 1994, didn't make it impossible for me to see things about software and the programming field through the eyes of someone to whom it was all new. Hard to know if I succeeded there -- I'll need to see how readers react. I do have a lot of experience, going all the way back to my Examiner days -- where, as I recall, I started out having to define the World Wide Web as "the graphical portion of the open global Internet" each time I mentioned it -- at introducing complex technical subjects to a wider audience. I've always tried to do so accurately but without talking down to people or simplifying to the point of meaninglessness. One problem I found in reading popular accounts of programming was that the resort to metaphor was sometimes so total that it crowded out actual understanding of the thing the metaphor was supposed to explain. We've seen this in writing about technology with stuff like "information superhighway." In descriptions of programming, you'd get people using construction metaphors and transportation metaphors and sometimes they'd get so elaborate they'd take on a life of their own and become distracting rather than illuminating. Of course if you're Neal Stephenson ("In the Beginning Was the Command Line") you can pull off as elaborate a metaphor as you want...
Ari Davidow (ari) Wed 21 Feb 07 10:03
I've been looking forward to getting a copy of this book for quite some time, and this discussion makes me even more eager. One of the questions that comes up for me is whether the Chandler situation is similar to many humongous projects that never yield results. I'm thinking in particular of two Apple-IBM collaborations from about 10 years ago that churned through ungodly amounts of time and resources and were eventually dropped, or for that matter, the related issue of Apple's next version OS before Jobs came back and they purchased Next and just adopted that. So, are there generalizations out there? Say, if you try to solve to many problems at once you most likely end up solving none?
Christian Crumlish (xian) Wed 21 Feb 07 11:12
So what did you learn from watching the Chandler team struggle with their grand vision? What surprised you? What expectations did you have going in and were they met or confounded?
Scott Rosenberg (scottros) Wed 21 Feb 07 12:21
Ari, I think there are some big differences between Chandler and projects like the Apple/IBM/Taligent/Kaleida stuff (which was very much related to the effort to upgrade or replace the old Mac OS). With the latter, before you even begin to get to the technical and design issues, you had to face the fact that you had two big companies trying to steer the same boat, and their interests and cultures and wishes were inevitably going to clash. Paralysis ho! The Chandler team included some veterans of those efforts, in fact. Chandler has a single chief funder and a single project leader/visionary, so it doesn't face that sort of dual loyalty trouble. But for sure, the larger point is, be extremely careful with your ambitions. At one point in DREAMING IN CODE I quote Linus Torvalds' argument that one should never ever set out to solve a big problem or set of problems -- always start small, he advises. That's certainly one way to avoid trouble, but it's extremely difficult advice for smart, ambitious people to take! Christian, I went in without too many expectations, beyond the simple one of assuming that I was going to be observing talented, experienced people trying to do something interesting, where the outcome was not at all predetermined. I very consciously said to myself, at the start of my work, "Don't write the ending in advance!" You know, I've always been a deadline writer -- I used to write overnight theater reviews, where I had 2-3 hours to try to analyze some new play, judge the production and entertain my readers, and do that all to fit a certain number of column-inches that had been chosen *before I'd seen the play.* Under such conditions you develop a habit of thinking ahead -- how am I going to end this piece? where am I aiming the arrow of my lead so that the motion will carry me through to where I want to be at the end? Writing a book for the first time, I told myself, don't do that! You've got the opportunity, finally, to witness a story and watch it unfold without imposing an order or framework on it too early. Of course eventually that's what a writer has to do, but I was determined to wait as long as possible. If I was surprised at anything as I watched the work at OSAF, it was how this group of developers ended up reinventing and renegotiating so much of the process of their teamwork. I realized that software development is often like the movie industry in this regard. Unless you're at a place like Microsoft with its own vast army of developers and its own internal traditions of project management and team coordination, software development is remarkably like the movie industry: Trained, experienced people hop from project to project (or startup to startup), bringing their own ideas of best practices with them, and at the beginning of a project, there's a lot of work to be done just feeling out stuff like, how exactly are we going to collaborate? how do decisions get made? how are we going to measure our progress? who takes responsibility if progress isn't happening? So I think that any time you have a team that already shares an understanding of this stuff -- whether through corporate tradition or community-building or simply because the individuals have worked together before -- you're way ahead of the game.
Paul Bissex (biscuit) Wed 21 Feb 07 19:33
Hi Scott, hello all. I just finished the book this week, but like Christian I've actually been looking forward to it for many years. In those years my own mix of work has involved more and more programming (and more and more Python, specifically), and the book touches on so many things I've thought about both as a programmer and as a writer that it's hard to know where to start. One thing I appreciated was that you didn't pre-empt earlier parts of your story based on later developments. Naturally, as I sat here in 2007 reading about OSAF's 2002/2003 plans to make a networked PIM, I thought, "They're not doing this on the web! They're doomed! Why isn't he talking about that?" You do talk about it, of course, but later, after walking us through those days when Ajax was a character in the Iliad, not a web technology. How hard was that to do? And if Chandler had met great success with a 1.0 release during the time you were writing, how might those early chapters -- presuming they covered roughly the same period in both our universe and the Chandler-wins alternative universe I'm positing -- have been different?
Lena M. Diethelm (lendie) Wed 21 Feb 07 22:39
Scott, your book was a great read for this non-programmer. I've got <lee> reading it as well but not sure if he'll make it to this discussion.
Ludo, Ergo Sum (robertflink) Thu 22 Feb 07 05:41
>At one point in DREAMING IN CODE I quote Linus Torvalds' argument that one should never ever set out to solve a big problem or set of problems -- always start small, he advises. That's certainly one way to avoid trouble, but it's extremely difficult advice for smart, ambitious people to take! What? and end history as we know it!! We need to keep smart, ambitious people busy with something or else we will really be in trouble. (Then, again, there were those signers of the Declaration of Independence. A fluke, maybe?)
Scott Rosenberg (scottros) Thu 22 Feb 07 08:52
Lena M. Diethelm (lendie) Thu 22 Feb 07 14:49
It's always interesting when there is 1 master (Kapor) and 1 funder (Kapor) vs. ventures that have to seek funding and are more fluid in the top most leadership. There were moments in reading DiC in which I began to think about Ted Nelson & Xanadu not so much because they are alike but because Chandler has had such a permeable time frame. Obviously Mitch & Ted are practically opposite personalities yet it's clear they both have specific passions they want to see realized. What do you think can keep Chandler from becoming Xanadu?
Paul Bissex (biscuit) Thu 22 Feb 07 17:03
(Not to step on Lena's question, but Scott, I wanted to let you know that your book also inspired me to revisit other books on software -- on my desk now I've got _The Mythical Man-Month_, _The Pragmatic Programmer_, and Knuth's _Literate Programming_.)
virtual community or butter? (bumbaugh) Fri 23 Feb 07 08:59
I, too, have been looking over some of those things -- prompted by Scott's book club kind of thing. (Which I'd say more concerning if I were willing to go find a url right now, but about which perhaps Scott will speak and save me the trouble.) Two reminders, in my hostly role: o for more about our guest author, or to buy the book in order to join in, please visit http://www.well.com/conf/inkwell.vue/ o questions or comments from off-site readers may be e-mailed to firstname.lastname@example.org for us to post here
Scott Rosenberg (scottros) Fri 23 Feb 07 12:41
It's great to hear that I've sent some developers back to their history! There's a lot there. The book club thing Bruce refers to is called Code Reads, on my personal blog at http://www.wordyard.com/category/code-reads/. It has been sadly neglected for several weeks because of the book launch but I intend to return to it very soon, hopefully even this weekend or early next week. It's less book-focused than article-focused, because it seems understandably easier to get people to read a shorter article than an entire book. As for Lendie's question about Xanadu: My memory of that project is a little dim, it's been years since I heard Ted Nelson talk about it, but my understanding is that he has always had a vision for a particular kind of hypertext environment that is in some ways richer and more complex than the Web (for instance, links are two-way), but that he's never been able to get past the chicken/egg problem of either (a) developing something compelling enough that people flock to it or (b) getting enough people to flock to something that's only partway there that the vision gets carried along by the flock. Chandler's issues have been quite different; I think Kapor is much more of a pragmatist, he understands what's needed to spark an adoption cycle, he just has yet to get Chandler close enough to that point. (This spring's release will be the next significant test.) The history of the Web's success vs. Xanadu suggests that people will gladly embrace a "just good enough" solution to a problem if it's easy enough and accessible enough and lets them play. When I saw the Web through Mosaic in summer of 1994 I didn't think, "Wow, that's great software," because, you know, it was pretty clunky at that point; I thought, "Wow, I can build my own page!," and then I thought, "If I can do it, tons of other people will too, and that will be even more fun." And that made learning HTML seem worth the (not so huge) time investment. So the lesson for software projects might be, show people how they can do something new and fun or useful, make it accessible, don't even think about making it perfect. The Web itself turns out to be a great platform for developing software that way, and that's one reason Web-based applications are so popular today.
Christian Crumlish (xian) Fri 23 Feb 07 18:38
I'd like to ask you to talk a bit about the GTD (Getting Things Done) personal task / project / productivity system. I was just talking to someone yesterday about how there's a bit of a geek cult around this book and its methods....
Members: Enter the conference to participate