Marc Canter – Eugene Eric Kim

“Time together in person is too important to spend working.” (21Z)

Reminds me of something Paul Visscher and Jason Cook told me when I had dinner with them a few weeks ago. I was asking about the hacker community in Dayton and whether folks ever got together to do code sprints. Paul responded, “When I get the chance to see these people in person, I’d rather just hang out with them.” Jason told a story of how he went to one local hacker gathering, where everyone was in a circle, staring at their laptops, something he found rather unappealing. (220)

To some degree, it shows how spoiled techies are in the Silicon Valley. There are so many of us here, doing code sprints doesn’t necessarily interfere with socializing. When Seb Paquet met up with me in December, he had just come from Marc Canter‘s party and was in awe of how easy it was to run into cool and interesting folks — not just techies — around here. (Hey Marc, where was my invitation?!) (221)

Manifesto Comments, Responses

Published April 12, 2004 by Eugene Eric Kim

Many thanks to everyone who’s emailed me or blogged about my manifesto. I’ve received great feedback — lots of kind words and constructive comments — both via email and the blogosphere. Because of the good folks at Slashdot, the piece was widely distributed. The last time something I wrote was Slashdotted, the responses were mostly content-free. This time around, quite a few people there had something reasonably substantial to say. (1AS)

Where’s The Beef? (1AT)

The most asked question was, “Where’s the beef?” Krysztof Kowalczyk wrote: (1AU)

It points out problems, shows some meta-solutions but almost no concrete solutions. (1AV)

Marc Canter added: (1AW)

There’s nothing he’s saying that I don’t agree with. I just wish he’d get more specific. Screen shots, Mockups, Design guidelines, Wireframes. APIs. Schemas. We need more Schemas! (1AX)

The point of my backlinks example is that in many cases, concrete solutions already exist; we just haven’t collectively realized it yet. Collaboration can’t happen until we realize that we’re all working on the same problem. There are initiatives for achieving this Shared Understanding, including our Collaboration Collaboratory and OCSI. (1AY)

That’s the more technical part of the “beef.” However, there’s a sociological element that has to come first: We have to understand what it means to collaborate, and we have to understand how we collaborate. Again, pockets of understanding exist, although they are mostly isolated from each other. We need to unify that understanding. (1AZ)

Patterns of Collaboration (1B0)

Blue Oxen Associates is working on that part of the problem. Our approach is to mine for patterns of effective collaboration and to disseminate these patterns widely via a Pattern Language. We’ve hinted at this objective in previous research reports, and we’re further refining it via additional research and other projects. Tomorrow, I’m heading to Carefree, Arizona for Chili PLoP, where I’ll be leading a workshop on patterns of collaboration. (1B1)

On Slashdot, Jameth commented: (1B2)

The manifesto makes grand claims about unifying our collaborative language, but totally understates how difficult this is. The problem usually is that we just do not have a solid model of what can and cannot be done, and we likely never will. (1B3)

Jameth later added: (1B4)

Collaboration methods change day-to-day. Sometimes the methods change due to whim, sometimes due to fashion, and sometimes due to technology. Whatever the reason, collaboration methods are hard to nail down reliably. (1B5)

I’m mostly with Jameth here. If I understated the difficulty of unifying our collaborative language, then I did so in error. It is a tremendous challenge. However, his claim that collaborative methods change day to day is incorrect. Perhaps that’s the case for methods in general, but it’s not the case for effective methods. The problem is that we’ve done a poor job of identifying and sharing these methods. This is exactly the problem we’re trying to address. (1B6)

Metamodeling (1B7)

Dorothea Salo wrote: (1B8)

ARGH! Every time I think the One True DTD business has finally run its course?    (1B9)

…    (1BA)

Tell you what, dear heart. You tell me what the “fundamental constructs” of documents actually are — every document on earth, mind you — and I’ll happily help out with a standard way of expressing ’em.    (1BB)

I absolutely do not believe in this notion of “One True DTD”; in fact, I have spoken adamantly against it in the past. As I explain in the manifesto, the fundamental constructs I’m talking about are graphs. Every document can be expressed as a graph. XML fundamentally relies on this property, as its underlying data model is a graph. The point of my piece is, don’t get too caught up with syntax (although don’t ignore it either); focus on the data model. (1BC)

Response to Marc Canter

Published November 19, 2003 by Eugene Eric Kim

I meet a lot of interesting people in this business, but a few stand out more than others. Anyone who’s met Marc Canter knows what I’m talking about. Marc is a big, boisterous fellow, mostly good-natured, and very outspoken. The guy is sharp and passionate, and has a proven track record of getting things done in the Valley, including cofounding MacroMind (which became Macromedia). He’s also got an incredibly cute baby daughter, which is a bit unfair, because it makes it difficult for me to get mad at him. (B5)

Marc recently complained about Blue Oxen Associates. Among his complaints were: (B6)

Now I have nothing againist Eugene Kim and his stalwarts, but what they created and what they do is pretty lame – compared to what’s going on out there – for free, everyday. What was it about Blue Oxen that Socialtext, Phil Pearson, Dave Winer, Paolo Valdemarin, Clay Shirky, Cory Doctorow, Danny Ayers, Dan Brickley, Lisa Rein, Mitch Kapor, Mark Pilgrim, Aaron Swartz, and hundreds more aren’t doing everyday? (B7)

Why did we need a white paper on why open source is a good thing? Why do we need yet another Wiki – ever if it is purple? (B8)

I just really think that Pierre’s money could be put to better use. (B9)

There are lots of problems with what Marc says, the biggest being that he’s got most of his facts wrong. (BA)

First, Omidyar Foundation has not invested in us. They funded our first research report on the open source software community. We are completely self-funded (by me), surviving on my initial investment and on clients. (BB)

Second, we are not in the business of open source software development. As a company that uses, evangelizes, and works to better understand collaborative tools, we naturally do some development. Our policy is that everything we produce is open source, be it software or research. PurpleWiki happens to be the first of those tools, and so we make it available. (BC)

Is PurpleWiki the Wiki to end all Wikis? That’s not our intent. Our intent is to understand and explore ideas that will help us improve collaboration, and then to disseminate those ideas as widely as possible. PurpleWiki is more than a bunch of purple hash marks spread out on a page. There is a lot of deep thinking behind its architecture, much of which was inspired by Doug Engelbart‘s earlier work. The Purple Numbers are the most visible manifestation, but there are others that will become more apparent eventually. The point is, we want to make those ideas accessible, and if they are useful, we want to help spread those ideas. That goes for all collaborative tools, not just Wikis. (BD)

We’ve done this. For example, we worked closely with Mike Mell who worked closely with Simon Michael to implement Purple Numbers in ZWiki. We host an active community of tool developers who are working together to make their tools more useful and interoperable. We’re always exploring new ways to make a difference. (BE)

Third, our research report was not about why open source software is a good thing. It was a preliminary exploration into why open source communities work. We’re not the first to explore this question, but I think we are especially qualified to explore it for a number of reasons. More importantly, our target audience is not open source developers. These folks don’t need persuading. Our audience is people who know nothing about open source software, except perhaps that it exists. There is an enormous language and experience barrier that prevents these folks from understanding what makes open source communities tick. Our thesis is that all communities — independent of their domain — could benefit from understanding and emulating open source communities. In order to test this thesis, we first have to overcome the language barrier. (BF)

Fourth, Marc listed a bunch of people doing great work in this space as if they were our competitors. They are not. I know several of these folks, have worked with some of them, and hope to work with many more. Our goal at Blue Oxen Associates is to better understand collaboration, so we can help improve it. In order to do that, we need to put our money where our mouths are and collaborate with others working towards the same goal. (BG)

When I founded Blue Oxen Associates, I consciously avoided seeking seed money and going for the big splash up-front. Some of the things we’re trying to accomplish are not obvious, and require further thinking and development. Starting small and growing slowly means we have to focus, sometimes at the expense of interesting projects and work, often at the expense of attention. (BH)

Nevertheless, I’m surprised and flattered by the attention we’ve received thus far. The participants in the communities that we host are incredibly supportive. We have an amazing advisory board. I constantly run into people who know about us and compliment us on our work. And, the blogging community has said some great things about us as well. I’m even flattered that Marc thought enough of us to devote some space on his blog to call us “lame.” Like I said, it’s hard to get mad at a guy who means well and has a cute baby daughter. I hope he’ll continue to follow our work; perhaps “lame” will evolve into something better once he actually understands what we do. (BI)