Online Community Summit: Friday’s Sessions

Posted on Published by Eugene Eric Kim

Notable talks and comments at last Friday’s sessions at the Online Community Summit:    (2F4)

  • Soren Kaplan described iCohere’s work with World Vision, a billion dollar nonprofit with 20,000 employees worldwide. There was an online collaborative process leading up to a conference, using iCohere‘s software.    (2F5)
  • Dave DeForest discussed the online communities at the Motley Fool. There’s a 40:1 read-write ratio on their bulletin boards. The Fool’s strategy for monetizing the communities was to get the readers to pay, and to comp the writers. The comping process is transparent in that participants know that some people are being comped, but the actual process for comping people is not concrete. When the Fool went to a pay model, it had a 90 percent attrition rate. 73 percent of its community participants are also likely to perform another transaction on the Fool.    (2F6)
  • Mark Williams discussed Apple’s support forums. Right now, he’s handling everything — management, development, etc. His managers tell him that the objective is to reduce phone volume, but he sees the two audiences as separate. Robert Labatt noted that Apple does a great job of converging threads on its support forums.    (2F7)
  • Anne McKay posed the following theory, citing last year’s The Atlantic Monthly article on introversion: You need extroverts for a successful online community. I would argue the opposite, although I have no numbers to back me up. We had an interesting discussion about this very topic in the Collaboration Collaboratory about a year ago. It would be interesting to do Myers-Briggs analysis on online communities in a future case study.    (2F8)
  • Steve De Mello told stories of “bad behavior” on some of ezboard’s online communities, and noted that hosts should only deal with black-and-white issues. The best pressure is peer pressure. Gail Williams agreed with Steve’s assessments, and noted that while paid communities helped filter out trolls, they didn’t eliminate them entirely.    (2F9)
  • During a breakout session on metrics, Gail suggested that our biggest problem is understanding and serving lurkers. (See my previous entries on lurkers.)    (2FA)
  • Tom Coates informed folks on the IRC Backchannel about Wiki proxy, a cool little proxy that automatically links terms to Wikipedia.    (2FB)

Finally, Reid Hoffman and Ross Mayfield gave a quick walkthrough of Social Software. I was amazed at the blank stares in the room during this talk. These folks seemed to have some awareness of Social Software, but certainly not a deep understanding. The previous day, Marc Smith said that threaded forums aren’t going away. I agree, but the common wisdom in the group seemed to be that threaded forums tend to be the end-all and be-all of online communities. I strongly disagree with this assessment. Dave asked what Wikis offered that threaded forums do not. That question missed the point: It doesn’t have to be one over the other. (Ross enjoys needling folks by claiming that email and threaded forums are dead, but I don’t think he actually believes it.) My response to Dave was that there’s great potential for integrating Wikis and threaded forums (as I and others do with blogs).    (2FC)

Blue Oxen and the Commons

Posted on Published by Eugene Eric Kim

There’s a fascinating discussion going on in the GivingSpace collaboratory about the commons, instigated by Phil Cubeta. Since that discussion is really focused on the Omidyar Network, I thought I’d throw in my two cents by describing how I see the Blue Oxen Collaboratories fitting into this discussion.    (2DK)

We currently host 22 alpha collaboratories, some of which are private spaces for organizations. The vast majority of them are public, however, and we encourage all of our groups to have public spaces. In fact, we will probably mandate that all of our organizational members have at least some public space in order to use our infrastructure.    (2DL)

We have not yet explicitly licensed the content of those discussions. It’s not an easy problem, although I suspect one of the Creative Commons licenses will work. However, we do know what principles we want the license to espouse:    (2DM)

  • You own your own words.    (2DN)
  • You’re speaking in public, so react accordingly.    (2DO)

Blue Oxen is interested in open discourse, the free exchange of ideas, and most importantly, collective learning. We’re not interested in demanding royalties from someone else’s idea, just because that idea was formulated in our space. We’re interested in facilitating a better ecosystem, and we’re betting that we will benefit far more from a better ecosystem than we would by making claims on other people’s IP.    (2DP)

“Facilitating the ecosystem” is something people hear me say often. It’s why all of our research is available under a Creative Commons license, and why all of our software is developed as Open Source. It’s why we emphasize interoperability with our tools, and why we’re doing our best to make it easy to export content from our collaboratories over to other sites. Our goal is to improve collaboration, and a policy of openness enables us to do that.    (2DQ)

All that said, it’s not as simple or as easy as it sounds. For example, what do you do about requests to remove content from a Wiki or one of our mailing list archives? (We discussed this issue a few months ago at the Collaboration Collaboratory.) Also, what about governance? Our collaboratories are not the commons. Although we try to be as open as possible, I’m not inclined (as of yet) to make the space entirely self-governing. That said, because our tools are Open Source and because we share our knowledge openly, people have the flexibility to create a self-governing commons using our tools and knowledge. In this way, we’re supporting the creation of commons. Again, it’s all about the ecosystem.    (2DR)

There’s also the question of sustainability. We’ve obviously closed off potential sources of revenue by being as open as we have. I strongly believe that we can not only sustain ourselves. We haven’t proven that yet, but I’m confident that we will soon enough.    (2DS)

TPVortex: Intro, Call For Help

Posted on Published by Eugene Eric Kim

In my manifesto for collaborative tools, I cited Backlinks as an example of a common, yet oft-overlooked conceptual construct in collaborative tools. Those who know me well know that my strategy for implementing some of Doug Engelbart‘s ideas (which I crafted over three years ago) has always been to create simple, concrete tools that could easily be shoehorned into existing applications. The plan was to start with Granular Addressability (Purple Numbers), then move on to Backlinks.    (247)

For a number of reasons, now seems to be the right time for me to start shifting my technical focus to Backlinks. The strategy for doing this is to implement a generic, Open Source, Backlink database (dubbed “TPVortex” and integrate it into several existing tools: PurpleWiki, blosxom, MovableType, MHonArc. I’m looking for folks who might be interested in participating in this project.    (248)

The motivation for such a tool is straightforward: Backlinks provide useful, contextual information. Most Wikis already implement Backlinks. Some of them display Backlinks on the main page, which is the correct behavior. Others (including PurpleWiki) do not. In order to implement this properly, you need a Backlink database.    (249)

Once you have a Backlink database, you might as well use it for other applications besides Wikis, such as blogs. We have this integration in PurpleWiki (see Wikis As Topic Maps for the resulting benefits), but again, it would be much nicer to display the Backlinks on the page itself rather than requiring a person to click on a link to see them. In order to implement this properly, the database has to store document metadata, such as title and author, not just the Backlink. For this reason, I think that TPVortex should use an RDF database on the backend.    (24A)

Other thoughts:    (24B)

I welcome help in all forms — comments, critiques, and especially coding. I’ve set up a Wiki page at the Collaboration Collaboratory — Collab:TpVortex — to serve as the center of design discussions. If you’re interested in contributing or commenting, please do it there. Feel free to drop me an email as well.    (24F)

Wiki Linking Using Ontologies

Posted on Published by Eugene Eric Kim

Last weekend, I posted some notes on Markup Free Auto Linking Wiki. The idea is that instead of relying on user syntax for identifying and linking to Wiki pages, the Wiki could do a linguistic scan of the text and link words based on a site-specific ontology.    (242)

I posted my notes mainly as a Blue Sky Idea, but it ended up generating a ton of discussion at the Collaboration Collaboratory. That discussion made me realize that this idea may not be all that blue sky after all, and that — given the proper PurpleWiki:DataBase design — we’re not all that far off from implementing something like this in PurpleWiki.    (243)

Tim Bray on Purple Numbers

Posted on Published by Eugene Eric Kim

I’ve long been a fan of Tim Bray‘s work, and although we had never crossed paths before, I had always assumed it would be instigated by me making some comment about something he had done or written about. (A few months back, I emailed him about ballparks in the Bay Area, because we seem to share a love for the sport, but that doesn’t count.) So I was surprised and pleased to see that Tim had made first contact and had (temporarily, as it turned out) implemented Purple Numbers on his blog. Not surprisingly, this is starting to generate some talk in the blogosphere. In particular, see:    (1G9)

Chris has done an excellent job of quickly addressing many of these issues. I’ll just toss in a few thoughts and references here and will look forward to more feedback.    (1GE)

Stable, Immutable IDs    (1GF)

Several people have pointed out that the IDs need to be stable. In other words, as the paragraphs move around or as new ones are added or deleted, the IDs stick to their original paragraphs. This was a fundamental motivation for Engelbart’s statement identifiers (SIDs), which we have renamed node identifiers (NID).    (1GG)

Both Purple (which needs updating) and PurpleWiki handle this correctly. You’ll notice that the addresses are stable on my blog and on Chris’s, as well as on all of the PurpleWiki installations (e.g. Collab:HomePage, PurpleWiki:HomePage). It’s because we use plugins for our respective blog software that call PurpleWiki‘s parser, which manages NIDs for us.    (1GH)

By using PurpleWiki to handle the purpling, blog content has NIDs unique to both the blog and the Wiki, which allows us to do fun stuff like transclude between the two. We get a similar effect with perplog, the excellent IRC logger written by Paul Visscher and other members of The Canonical Hackers. For example, check out Planetwork:Main Page and the chat logs over there.    (1GI)

Mark Nottingham noted that even if the NIDs are stable in the sense that they are attached to certain paragraphs, the paragraphs themselves are not semantically stable. This is a point on which I’ve ruminated in the past, and we still don’t have a good solution to it.    (1GJ)

History and Other Worthy Projects    (1GK)

I’ve written up my own brief history of Purple Numbers, which fills in some holes in Chris’s account. In it, I mention Murray Altheim‘s plink. Plink is no longer available on the net, because it has been subsumed into his latest project, Ceryle. Everything that I’ve seen about Ceryle so far kicks butt, so if you’d like to see it too, please drop Murray an email and encourage him to hurry up and finish his thesis so that he can make Ceryle available! You can tell him I sent you, and you can forward him the link to this paragraph; he’ll understand.    (1GL)

Matt Schneider is the creator of the PurpleSlurple purple numbering proxy, which will add Purple Numbers to any (well, most) documents on the Web. PurpleSlurple deserves a lot of credit for spreading the meme.    (1GM)

Mike Mell implemented Purple Numbers in ZWiki for last year’s Planetwork Conference (see ZWiki:ZwikiAndPurpleNumbers), which in turn influenced the evolution of Purple Numbers in PurpleWiki. Mike and Matt have both experimented with JavaScript for making the numbers less intrusive.    (1GN)

The latest version of the Compendium Dialogue Mapping tool exports HTML maps with Purple Numbers.    (1GO)

In addition to Murray, Matt, and Mike, several other members of the Blue Oxen Associates Collaboration Collaboratory have contributed to the evolution of Purple Numbers, especially Peter Jones, Jack Park, and Bill Seitz. In addition to his contributions to the technical and philosophical discussions, Peter wrote the hilarious Hymn of the Church Of Purple and excerpts of the Book of the Church Of Purple.    (1GP)

Finally, many good folks in the blogosphere have helped spread the meme in many subtle ways, particularly those noted connectors Seb Paquet and Clay Shirky.    (1GQ)

Evangelism and The Big Picture    (1GR)

Okay, that last section was starting to sound like an award acceptance speech, and although none of us have won any awards, one thing is clear: The contributions of many have vastly improved this simple, but valuable tool. I’m hoping that momentum picks up even more with these recent perturbances. I’m especially heartened to see experiments for improving the look-and-feel.    (1GS)

I want to quibble with one thing that Chris Dent said in his most recent account. (When we have distributed Purple Numbers, I’ll be able to transclude it, but for now, you’ll just have to live with the cut-and-paste):    (1GT)

When he [Eugene] and I got together to do PurpleWiki, we were primarily shooting for granular addressability. Once we got that working, I started getting all jazzed about somehow, maybe, someday, being able to do Transclusion. Eugene was into the idea but I felt somehow that he didn’t quite get it. Since then we’ve implemented Transclusion and new people have come along with ideas of things to do that I’m sure I don’t quite get, but are probably a next step that will be great.    (1GU)

There are many things I don’t quite get, but Transclusions are not one of them, at least at the level we first implemented them. That’s okay, though. Ted Nelson felt the same way about my understanding of Transclusions as Chris did, although for different reasons. (And, I suspect that Ted would have had the same opinions of Chris.) I mention this here not so much because I want to correct the record, but because it gives me an excuse to tell some anecdotes and to reveal a bit about myself.    (1GV)

Anyone who knows Doug Engelbart knows that he complains a lot. The beauty of being an acknowledged pioneer and visionary is that people pay attention, even if they they don’t think much of those complaints. When I first began working with Doug in early 2000, I would occasionally write up small papers and put them on the Web. Doug would complain that they didn’t have Purple Numbers. At the time, I recognized the value of granular addresses, but didn’t think they were worth the trouble to add them to my documents. I also didn’t think they were the “right” solution. Nevertheless, because Doug was Doug, I decided to throw him a bone. So I spent a few hours writing Purple (most of which was spent learning XSLT), and started posting documents with Purple Numbers.    (1GW)

Then, a funny thing happened. I got used to them. I got so used to them, I wanted them everywhere.    (1GX)

A few people just get Purple Numbers right away. Murray was probably the first of those not originally in the Engelbart crowd to do so; Chris followed soon thereafter, as did Matt. The vast majority of folks get the concept, but don’t really find them important until they start using them. Then, like me, they want them everywhere. Getting people past that first step is crucial.    (1GY)

A few nights ago, I had a late night conversation with Gabe Wachob (chair of the OASIS XRI committee) on IRC. (This eventually led to a conversation between Chris and me, which led to Chris’s blog entry, which led to Tim discovering Purple Numbers, which led to this entry. Think Out Loud is an amazing thing.) Gabe knew what Purple Numbers were, but hadn’t thought twice about them. I had wanted to ask him some questions about using XRI addresses as identifiers, and in order to do so, I gave him a quick demonstration of Transclusions. The light bulb went off; all of a sudden, he really, truly got it.    (1GZ)

Richard Gabriel, one of our advisors, is well known for his Worse Is Better essays (among other things). I think Purple Numbers are an outstanding example of Worse Is Better. They fulfill an immediate need, and they cause us to think more deeply about some of the underlying issues. I’d like to see Purple Numbers all over the place, but I’d also like to see a group of deep thinkers and tinkerers consider and evolve the concept. It’s part of a larger philosophy that I like to call The Blue Oxen Way.    (1H0)

This last point is extremely important. Chris has thankfully been a much more enthusiastic evangelist of Purple Numbers than I have, and in the past he’s called me “ambivalent” about Purple Numbers. That’s not so far from the truth. It’s not that I’m any less enthusiastic about Purple Numbers themselves — I am a card-carrying member of the Church Of Purple, and the current attention and potential for wider usage thrill me. However, I’m cautious about evangelizing Purple Numbers, because I don’t want people to get too caught up in the tool itself and forget about the bigger picture. It’s the reason I didn’t mention Purple Numbers at all in my manifesto.    (1H1)

At the Planetwork forum two weeks ago, Fen Labalme, Victor Grey, and I gave the first public demo of a working Identity Commons Single Sign-On system. We were tickled pink by the demo, which to everyone else looked just like any other login system. The reason we were so excited was that we knew the system used an underlying infrastructure that would eventually enable much greater things. The demo itself, unfortunately, didn’t convey that to anyone who didn’t already understand this.    (1H2)

I’m probably a bit oversensitive about this sort of thing, and I’m constantly seeking better balance. But it’s always in the back of my mind. When I talk to people about Blue Oxen Associates, I usually spend more time talking about the sociological aspect of collaboration rather than the tools, even though I have plenty to say about the latter. Can Purple Numbers make the world a better place? I truly, honestly, believe that they can. (This is a topic for another day.) But when I see groups that excel in collaboration (or conversely, those that stink at it), Purple Numbers are usually the furthest thing from my mind. Much more important is the need to identify and understand these patterns of collaboration (of which tool usage is an important part).    (1H3)