Hillside Group Annual Meeting

I attended lots of great meetings and talks over the past two weeks. I’m going to start posting some notes and observations in reverse chronological order.    (9I)

Last Thursday and Friday, I attended the Hillside Group‘s annual post-OOPSLA meeting, held at the Anaheim Sheraton in Southern California. Richard Gabriel, president of the Hillside Group and one of our advisory board members, and Dirk Riehle, Hillside Group‘s treasurer, invited me to attend.    (9J)

The Hillside Community    (9K)

My parents recently moved to Irvine, which is about 20 minutes south of Anaheim, so I’m always looking for opportunites to go down south and visit. But that’s not why I wanted to attend this meeting. Regular readers of this blog know that Pattern Languages are central to Blue Oxen Associates‘ strategy for understanding and improving collaboration and communities. This is why I asked Richard Gabriel to join our advisory board in the first place, and is ultimately why I wanted to attend this meeting.    (9L)

Hillside Group was founded a decade ago by a bunch of software engineers (including Gabriel, the Gang of Four, and several other gurus in the field) in order to figure out how to write pattern languages for software design. The group hosts several Pattern Languages of Programs (PLoP) conferences every year, which are loosely modeled on writers’ workshops.    (9M)

When a bunch of engineers model their conferences on writers’ workshops, you know that they’re not your run-of-the-mill geeks. When these same engineers are intimately familiar with the works of architect Christopher Alexander, you know that they’re definitely not your run-of-the-mill geeks.    (9N)

All of this was evident throughout the meeting. Those in attendance (about 40 people) were thoughtful and highly self-reflective. Many of them had written books, and many more are writing books. More than anything, I was delighted to see the quality of meta-thinking within the group and a general inclination for action. These are folks who have recognized that Pattern Languages are a wonderful tool that can be applied to many other things besides software design, and have done exactly that. For example, the Hillside Group has a pattern language for shepherding (mentoring new writers), patterns for Pattern Mining, etc.    (9O)

I was struck by the group’s overall camraderie and openness. The interaction was light, easy-going, and usually accompanied by laughter. Shared Language was strongly evident. When meetings were about to begin, self-described group “den mother” Linda Rising would shout, “Group sneeze!” Everyone would stop in their tracks, shout “Hishi,” “Hashi,” or “Hoshi,” and then there would be silence.    (9P)

Hillside Group felt like a community with QWAN. This was not totally unexpected, given that Hillside Group is one of the few communities that are familiar with the term “QWAN.” In addition to being a valuable repository of knowledge about pattern languages in general, Hillside Group is a community worth studying.    (9Q)

Odds and Ends    (9R)

A topic that came up throughout the meeting was how to better leverage asynchronous tools for collaboration. The consensus was that the face-to-face meetings were extremely important and valuable, but that they could be made more efficient with the right tools. One of the key problems raised was that face-to-face meetings often generated a great amount of energy that promptly dissipated once the meetings adjourned and people went back to their busy lives. I think about this problem constantly. I’ve touched on it briefly in a previous blog entry, and hope to discuss it more soon.    (9S)

A tool idea that came out of this discussion was “Cyber Shepherd.” Inspired by Cyber Chair, a tool for managing the conference submissions and review process, Cyber Shepherd would be a tool for managing the pattern language submission and shepherding process.    (9T)

Husband and wife team Tracy Bialik and Russ Rufer introduced the Silicon Valley Patterns Group, which meets twice (!) a week to discuss software patterns. The group has been going on strong for five (!) years. I plan on attending one of their meetings when I return to the Bay Area, but it already seems to be a very good candidate for studying sustainable grassroots communities.    (9U)

Hanyuda Eiiti, a leading Japanese advocate of software patterns, entertained the group with his “Pattern Dance,” a live enactment of the MVC pattern.    (9V)

I got a chance to chat for a bit with Ralph Johnson, one of the Gang of Four, who explained how the Design Patterns book came about, and how Christopher Alexander‘s ideas began seeping into this community. I’ll post tidbits of that story here when the opportunity arises, and I hope to write a full-length article about this at some point.    (9W)

The Value of Models

Nathan Rosenberg, Professor of Economics at Stanford University, gave a talk last Thursday at PARC entitled, “The Endogeneity of Technological Change in 20th Century America.” Endogeneity, as defined by Rosenberg, is the process of responding to changes in market forces.    (97)

According to Rosenberg, up until recently, economic historians viewed technological innovation largely as an exogenous process; that is, independent of market forces. Rosenberg argues that not only is much technological innovation endogenous, but that in the last century, scientific and technological innovation in the U.S. has been especially endogenous.    (98)

Rosenberg made an interesting point about how this endogenous view contrasted with the traditionally linear view of technological innovation. (Donald Stokes explores this topic extensively in his book, Pasteur’s Quadrant; see my previous reference to Stokes.) Engineering disciplines are often thought of as “applied sciences,” whereas in many cases, scientific research is actually an application of engineering disciplines. For example, solid state physics was rarely taught until after the transistor was invented in 1948. Following the transistor, investments in solid-state research increased dramatically, as did the number of physicists who specialized in that field. Similarly, basic research in polymer chemistry at Dupont in the 1920s (which eventually led to the invention of nylon, among other things) didn’t occur until after Dupont had made several advances in chemical engineering. The latter convinced the company that it had the capability to develop advances in polymer chemistry into marketable products.    (99)

Why We Need Models    (9A)

Rosenberg’s topic was stimulating, but something he said early in his talk caught my ear. He stated that he was skeptical that we could derive rigorous models of technological innovation, but that we could derive a great deal of valuable knowledge by considering these models.    (9B)

A group of us at Blue Oxen Associates are currently working on another community case study, and one of the topics we’re exploring is the effects of tools and processes on these communities. One of the researchers asked about how we could set up properly scientific experiments. I responded that I didn’t think it was possible. There are things you can do to make a study more “scientific,” but those things don’t guarantee rigorous results. That said, I don’t think a study has no value if you don’t have a control group. At the Hypertext 2002 Workshop on Facilitating with Hypertext, Jeff Conklin had this memorable line: “All abstractions are wrong, but they can still be very useful.”    (9C)

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)

A Brief History of Purple Numbers

A few weeks ago, Chris Dent posted a brief history of Purple Numbers, noting, “This is likely full of errors as the story as I’ve heard it is incomplete and I was unable to check some things because the network path to California was busted while I was writing.” His account is pretty good, but there are a few holes here and there. Most of my clarifications are nitpicky. In case you, my dear readers, haven’t realized it yet, I am very anal.    (7W)

Chris differentiates NLS from the mouse, hypertext, GUIs, and so forth. NLS was actually the totality of all of these things. Chris also says that NLS had a “graph based document storage model.” This is somewhat of an ambiguous description, and depending on how you read it, is not strictly true. Finally, NLS did not have transclusions, although its architecture could easily have supported them.    (7X)

In between NLS and the first appearance of Purple Numbers on the Bootstrap Institute’s web site, there was a graphical Augment client written in Smalltalk. The first Augment PC client was MS-DOS-based. Doug still uses this! In the early 1990s, a contractor wrote a GUI client for Windows, which displayed statement IDs (what we call node IDs) in purple. According to Doug, the choice of color was either his daughter’s, Christina, or the author of the client. In any case, this is why Purple Numbers are purple.    (7Y)

Bootstrap Institute first used Purple Numbers to display structural location numbers (what we call hierarchical IDs) for Augment documents converted to HTML. Soon afterwards, Frode Heglund suggested making the numbers a live link, so that it would be easy to copy and paste the node’s address.    (7Z)

On January 31, 2001, I released the first version of Purple, which was a collection of Perl and XSLT scripts for adding node and hierarchical IDs to documents and generating HTML with Purple Numbers. I believe my most important contribution at the time was recognizing that node IDs were more useful in a Web context, where documents were largely dynamic, than hierarchical IDs. On April 24, 2001, Murray Altheim released plink, a Java program similar to Purple, except that it worked on XHTML files.    (80)

My OHS Launch Community experiment (June 15 – November 9, 2001) proved to be a fruitful time for Purple Numbers. Murray and I agreed on a standard addressing scheme for Purple Numbers. I implemented a MHonArc filter for adding Purple Numbers to and extracting Backlinks from mailing list archives, and tool that generated HTML with Purple Numbers from Quest Map files.    (81)

I also started thinking about PurpleWiki for the first time, and hacked a first version based on TWiki. This experience gave me a better understanding of the right way to implement PurpleWiki, and it also gave me a healthy distaste for TWiki. When Chris joined Blue Oxen Associates, we made PurpleWiki a priority, and the rest is history. Chris’s account from there is pretty complete.    (82)