More on Marc Smith and Joshua Tyler

Going through some old notes, I found some other references to both Marc Smith and Joshua Tyler. Marc wrote about Netscan in, “Tools for Navigating Large Social Cyberspaces” (Communications of the ACM, April 2002, pp51-55). Joshua has a paper from when he was at Stanford entitled, “When Will You Read And Reply to My Email? A Study of Rhythms and Temporal Patterns in Email Use.”    (8Z)

HP and Microsoft Study Online Communities

Two articles in recent days highlighted social scientists at Hewlett-Packard (Joshua Tyler) and Microsoft (Marc Smith). Tyler, 25, studies the rhythms of composing and answering e-mails, work that he started while pursuing a master’s degree at Stanford. Smith has been studying USENET newsgroups, and his team at Microsoft has developed software called Netscan.    (8Y)

Mailing List Etiquette and Experimentation

I’ve been an e-mail user for over 10 years, and a mailing list and USENET user for just about as long, so I have strong beliefs about proper mailing list etiquette. That puts me in an interesting position as a participant in the Blue Oxen Collaboratories. On the one hand, these collaboratories are supposed to be shining examples of high-performance collaboration. On the other hand, they’re also supposed to be testbeds for experimentation and coevolution.    (8K)

Sometimes, people use the lists in ways that conflict with my inner sense of etiquette. However, etiquette is a form of social constraint, and if we forget why we find these constraints valuable, our sense of etiquette can impede collaboration.    (8L)

The collaboratories are a perfect place to have metadiscussions about this sort of behavior as it happens, but unfortunately, it’s hard for me to participate or initiate those discussions. Because of my position at Blue Oxen Associates, my commentary can be perceived as law rather than opinion, and I don’t want that to be the case.    (8M)

That, of course, is the reason for this blog — for me to WhineInPrivate in public. Which leads me to today’s topic.    (8N)

Cross-Posting    (8O)

The impetus for this entry was a discussion this morning with Andrius Kulikauskas, who called me all the way from Lithuania. Andrius founded the Minciu Sodas laboratory, which is similar in spirit to Blue Oxen Associates, and he actively participates in our collaboratories.    (8P)

One thing that Andrius does often is cross-post across different forums and mailing lists. I’m not a big fan of cross-posting, but I think there are times when it’s appropriate. The problems are:    (8Q)

  • List participation is often restricted to participants, largely as a way to avoid spam. As a result, people will not necessarily see responses to cross-posts, and it can result in stilted and confusing discussion.    (8R)
  • There is a force at work within effective communities: Know Your Audience. People behave differently depending on their audience, as well they should. You may know the audiences of the lists to which you are cross-posting, but the different members of each list may not, and that will affect how or whether they respond.    (8S)

Andrius and I discussed this a bit over the phone. One of his rationales for cross-posting is that it builds awareness of other communities, and that it encourages interconnectedness. I definitely believe in the former, but I’m not so sure about the latter. Simply knowing that a community exists certainly enables interconnectedness at some level, but cross-posting could also discourage interconnectedness. If there is no Shared Language on the different lists, cross-posts can unintentionally lead to further balkanization of communities.    (8T)

I’m not a big fan of cross-posting, but I tolerate it, and for good reason. When Andrius did it, it forced me to think very hard about why I disliked it. That helped me understand the reason for my feelings, and it also helped me think through some half-baked ideas. For example, when you consider the benefits of cross-posting, it’s clear that the technical balkanization of mailing lists caused by restricting participation to subscribers can be a very bad thing. One advantage with USENET newsgroups or web-based forums is that you don’t have this balkanization. On the other hand, these forums are susceptible to spam. I’m certain there is a technical solution to this problem, although I don’t know what it is yet.    (8U)

Off-Topic Postings    (8V)

A great example of where etiquette can be overly enforced is off-topic postings. I’ve noticed that on some lists, moderators are tyrannical about keeping discussion on-topic. While I understand the reasoning, being too extreme about this can do more harm than good. The nature of online spaces is different from face-to-face spaces, and the former is a more tolerant space for divergent ramblings than the latter. I wrote some thoughts on this in an earlier entry.    (8W)

Another reason for tolerating some off-topic discussions is the Water Cooler pattern. Communities are more effective when people have shared experiences, and informal socializing is a great way for identifying or creating these experiences. Several months ago, there was a discussion about local restaurants on the San Francisco Perl User Group mailing list. This clearly had no relevance to Perl, but it was very interesting, and no one complained. In fact, the original poster asked for recommendations off-list, and several people e-mailed him asking to post the responses on-list instead.    (8X)

PurpleWiki v0.9 Released

PurpleWiki v0.9 is now available. Chris Dent‘s announcement covers the basics. A few words on how we got here, and where we’re going.    (83)

The Wiki Experiment    (84)

When we launched Blue Oxen Associates last December, we made Wikis a core part of our infrastructure. We had two reasons for choosing Wikis. The first was practical. We needed a system for sharing documents and collaborative authoring, and Wikis fit the bill quite nicely.    (85)

The second reason was more philosophical. We wanted a knowledge management system like Doug Engelbart‘s Open Hyperdocument System (OHS), and felt that Wikis already resembled the OHS in many ways. It was immediately usable and useful, while also offering the perfect platform for coevolution.    (86)

PurpleWiki fulfills the following OHS requirements:    (87)

  • Backlinks. This is a core feature of all Wikis, but also one of its most underutilized. In a future version of PurpleWiki, we will create an open API to its Backlink engine, so that other applications (such as blogs) may use it.    (88)
  • Granular Addressability. PurpleWiki‘s site-wide, automatic Purple Number management had the additional benefit of enabling us to quickly experiment and evolve the feature. Node IDs are now document-independent, which has improved usability and enabled features like Transclusions.    (89)
  • Link Types. We’ve added a syntax for specifying link types, and have implemented our first new link type: Transclusions.    (8A)
  • View Control. We can easily add new or customize existing output formats, thanks to PurpleWiki‘s modular architecture. More importantly, we can implement dynamic views, such as a collapsible outline view, of any document on PurpleWiki.    (8B)

PurpleWiki‘s most visible feature is Purple Numbers, but its most important feature is its data architecture. In general, Wikis view the world as a graph of linked documents. PurpleWiki views the world as a graph of linked documents with a unified data model. The data model is sufficiently general and simple to apply to any kind of document. When you use this data model in other applications, you automatically inherit PurpleWiki‘s features. Integrating PurpleWiki with blogs was a piece of cake as a result, and we’ve only begun to explore the ramifications.    (8C)

Next Steps    (8D)

Our roadmap lists several enterprise features we plan on implementing: templates, pluggable database back-ends, mod_perl controller, etc. I consider these important, but relatively mundane. Blue Oxen Associates isn’t in the business of software development; we’re implementing these features because we need them.    (8E)

Blue Oxen Associates is in the business of research and improvement, and of facilitating coevolution. PurpleWiki is an amazing platform for this. One of Chris’s pet projects is to create universal ID space for nodes, possibly based on handles. Think of this as persistent URIs for nodes. Among other things, this will enable us to support Transclusions of content from other sites, not just the site on which PurpleWiki is installed.    (8F)

My long-term interests lie in three areas: the aforementioned open Backlink engine, Wiki page types, and Wiki namespaces. I’ll discuss the latter a bit here.    (8G)

One of the reasons I dislike TWiki is its notion of “webs.” You can partition your Wiki into multiple webs, and each web is contained in its own namespace. The problem with this is that it encourages people to balkanize their Wiki content. That, in my opinion, runs counter to the spirit of Wikis. Early balkanization prevents evolution.    (8H)

Several months ago, Richard Gabriel passed along some insight he had learned from Ward Cunningham: In computer science, you want to keep namespaces separate. With Wikis, you want namespaces to clash. Ward’s idea for SisterSites is one way to create namespace clash. This idea could be taken a step further by allowing site administrators to establish a system of namespace resolution. For example, if a certain page doesn’t exist on a local namespace, the Wiki would search another namespace for that page. If it existed there, the Wiki would simply take the user to that page.    (8I)