The Identity Commons i-name fundraiser got Slashdotted today. I haven’t been all that impressed by the comments on Slashdot in the past, but they were useful this time in revealing a fundamental misunderstanding about the Identity Commons infrastructure (and a problem with its messaging). Identity Commons is not centralized. This is not a non-profit version of Microsoft Passport. It was designed from the ground up to be fully distributed. See Fen Labalme‘s post for a deeper explanation and some additional comments on the Slashdot responses. (7VR)
Manifesto Comments, Responses
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)
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)
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)
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)