The Story of Glormf: Lessons on Language and Naming

Jack Park recently asked about Link As You Think on the Blue Oxen Collaboration Collaboratory. I’ve written several blog posts on the matter, but there’s not much else out there. This was a great excuse for me to tell a few vignettes about Shared Language and the importance of names.    (KMO)

Glormf    (KMP)

This is Glormf, courtesy of the uber-talented cartoonist, Brian Narelle.    (KMQ)

(KMR)

Fen Labalme coined the term (originally spelled “glormph”) at an Identity Commons retreat in July 2003. We were strategizing about next steps, and we found that we were all struggling to describe what it was that we were all working on. Although we all had different views of the proverbial elephant, we were also convinced that we were talking about the same thing. In an inspired moment of clarity, Fen exclaimed, “It’s Glormf!” Much to our delight, Brian was listening to the conversation and drew Glormf for all of us to see.    (KMS)

Glormf’s birth lifted a huge burden off our shoulders. Even though Glormf was mucky, it was also real. We knew this, because it had a name and even a picture, and we could point to it and talk about it with ease. The name itself had no biases towards any particular view, which enabled all of us to use it comfortably. Each of us still had a hard time describing exactly what Glormf was, but if anyone challenged Glormf’s existence, any one of us could point to Glormf and say, “There it is.”    (KMT)

We had created Shared Language, although we hadn’t rigorously defined or agreed on what the term meant. And that was okay, because the mere existence of Shared Language allowed us to move the conversation forward.    (KMU)

Ingy’s Rule and Community Marks (KMV)

Ingy dot Net‘s first rule of starting a successful Open Source project is to come up with a cool name. I like to say that a startup isn’t real until it has a T-shirt.    (KMW)

Heather Newbold once told a wonderful story about how Matt Gonzalez’s mayoral campaign buttons galvanized the progressive community in San Francisco and almost won him the election. As people started wearing the green campaign buttons, she described the startling revelation that progressives in San Francisco had: There are others out there like me. A lot of them. I was amazed to hear her speak of the impact of this recognition, coming from a city that has traditionally been a hotbed of activism.    (KMX)

There’s a pattern in all of these rules and stories. I struggled to come up with a name for this pattern, and the best I could do for a long time was Stone Soup (courtesy of the participants in my 2004 Chili PLoP workshop). I loved the story associated with this name, the parable of how transformational self-awareness can be. But, it wasn’t quite concrete enough for my taste.    (KMY)

I think Chris Messina‘s term, “Community Mark“, is much better. Chris has actually fleshed out the legal implications of a Community Mark, which I recommend that folks read. Whether or not you agree with him on the details, the essence of Community Marks is indisputable: Effective communities have Community Marks. Community Marks make communities real, just as the term “Glormf” made a concept real. That’s the power of Shared Language.    (KMZ)

Pattern Languages and Wikis    (KN0)

Pattern Languages are all about Shared Language. Much of Christopher Alexander‘s classic, The Timeless Way of Building, is about the importance of names. In his book, Alexander devotes an entire chapter to describing this objective quality that all great buildings have. As you can imagine, his description is not entirely concrete, but he does manage to give it a name: “Quality Without A Name.” Call it a copout if you’d like, but if you use the term (or its acronym, “QWAN”) with anyone in the Pattern Language community, they will know what you’re talking about. Shared Language.    (KN1)

Ward Cunningham was one of the pioneers who brought Alexander’s work to the software engineering community. He created Wikis as a way for people to author and share patterns. Not surprisingly, an important principle underlying Wikis is the importance of names. Regardless of what you think about WikiWords, they have important affordances in this regard. They encourage you to think of word pairs to describe things, which encourages more precise names. They discourage long phrases, which also encourages precision as well as memorability. The more memorable a term, the more likely people will use it.    (KN2)

Ward often tells a story in his Wiki talks about using Class-Responsibility-Collaboration Cards to do software design. One of the things he noticed was that people would put blank cards somewhere on the table and talk about them as if there was something written there. The card and its placement made the concept real, and so the team could effectively discuss it, even though it didn’t have a name or description. (Ward has since formalized leaving CRC cards blank as long as possible as a best practice.) This observation helped him recognize the need and importance of Link As You Think, even if the concept (or Wiki page) did not already exist.    (KNG)

Open Source: Propagating Names    (KN3)

One of Blue Oxen‘s advisors, Christine Peterson, coined the term, “Open Source.” In February 1998, after Netscape had announced its plans to open source its browser, a few folks — Chris, Eric Raymond, Michael Tiemann, Ka-Ping Yee, and others — gathered at the Foresight Institute to strategize. At the meeting, Todd Anderson complained that the term, “Free Software,” was an impediment to wide-scale adoption. After the meeting, Christine called up Todd and suggested the term, “Open Source.” They both loved it. But, they didn’t know how to sell it.    (KN4)

So, they didn’t. At the followup meeting a few days later, Todd casually used the term without explanation. And others in the room naturally picked up on the term, to the point where they were all using it. At that point, they realized they had a good name, and they started evangelizing it to the rest of the community.    (KN5)

Names change the way we think about concepts, and so propagating names widely can shift the way people think about things. This is what happened with “Open Source.” This is what George Lakoff writes about in Moral Politics.    (KN6)

The mark of a good name is that people naturally start using it. A name can come from the top down, but it can’t generally be forced onto people.    (KN7)

Patterns at WikiMania 2005

When I first met Christine Peterson (now a Blue Oxen Associates advisor), she told me the story about coining “Open Source.” The sign of a good name, she explained, is when people naturally start using it on their own. At a meeting of developers and evangelists in early 1998, rather than argue strongly in favor of the term, she introduced it subtly. Although the response wasn’t enthusiastic at the first, everyone in the room found themselves using the term, and by the end of the meeting, they all agreed to evangelize it.    (JMS)

Similarly, my strategy for introducing and identifying patterns of high-performance collaboration is to subversively introduce patterns into various communities and then to listen. If people naturally use a pattern in conversation, the name is probably good and the pattern itself is probably real and repeating. As people become familiar with the concept, they are more likely to identify and name other patterns. Over time, the language shifts your thinking, giving you a cognitive framework for thinking about, talking about, and improving collaboration and collaborative tools. Moreover, the process itself is iterative and collaborative, which is both the right way to develop Pattern Languages and also another application of collaborative patterns.    (JMT)

I’ve been giving some variation of a stock talk on patterns for over a year now, including last week at Wikimania 2005. It usually consists of a quick introduction, a few examples, and an interactive portion where I tease out patterns from the audience. The audience banter is always the best part. It’s always different, and it’s provided me with entertaining anecdotes, new patterns, and better pattern names.    (JMU)

Last week, I mentioned four patterns that Wikis facilitate: Permission To Participate, Shared Display, Visible Pulse, and Working Draft. Tim Starling followed my talk with an overview of Mediawiki development, and when he mentioned their IRC channel, he said, “This is our community’s Visible Pulse.” I love it when the process works!    (JMV)

The discussion teased out other patterns, especially Celebration and Initiation. (Linda Rising and Mary Lynn Manns mentions both of these in their book. They have a better name for the latter, but I don’t remember it off-hand.) One person told a great story about both. His team met for the first time in Australia, and before embarking on their project, they brewed beer that they planned on drinking after they finished their project.    (JMW)

Other patterns observed and not observed at the conference and within the community:    (JMX)

  • The Celebration at the end of the conference was great, but the Initiation wasn’t particularly remarkable. This isn’t unusual for conferences, where Initiation tends to be in the form of a keynote.    (JMY)
  • One pattern closely related to Initiation is Introductions. At conferences, this generally comes in the form of name badges, which we had at Wikimania. I think there’s a huge opportunity for further facilitating this pattern at conferences, which is something Blue Oxen Associates is working on. Hacking Days also would have been significantly more effective if we simply went around the room each day and quickly introduced ourselves. It’s one of those patterns that sound obvious when you hear about it, but is often forgotten when actually designing an event.    (JMZ)
  • Conferences usually do Water Cooler well, and Wikimania was no exception. We had long lunches, a party on the last night, an IRC channel, and some organized activities in Frankfurt am Main for stragglers following the conference. In particular, the organizers did two things really well. The Haus der Jugend was an excellent choice of venue, because it was an intimate space where social interaction was practically unavoidable. Most of the participants stayed at the hostel, which meant that there was always an interesting conversation to be had by simply going downstairs and hanging out in one of the common rooms. Plus, most of us who stayed there also had roommates, which is not typical for the conferences I attend. The restaurants and bars — touristy though they were — were in very close proximity, which made it easy to grab a beer and talk. (Food is a closely related pattern.) Finally, Hacking Days served as an unintentional Water Cooler, at least for those of us who were not Mediawiki developers. Coming early is something the organizers should encourage more widely next time.    (JN0)
  • I’m very biased towards highly interactive event design, and it seemed like it would have been especially appropriate for a Wiki conference. That said, the panel format worked better than at most conferences, and I think the Wiki culture of Permission To Participate had a lot to do with that. The audience interacted easily with the presenters at all of the talks I attended, and most of the speakers did a nice job of incorporating feedback into their presentations. One thing they did not do well was actively promote and integrate the conference Wiki as a place to take notes and have additional discussions. Again, this seemed surprising for a Wiki conference — yet another indication that making patterns explicit is a good thing.    (JN1)
  • Another favorite — also found in Linda and Mary Lynn’s book — is Spotlight On Others. This runs rampant throughout the Wikipedia community, which is wonderful. Tim cited me when mentioning Visible Pulse, and by the next morning, Sunir Shah had incorporated Permission To Participate into his talk on conflict resolution. I found this time and again in people’s talks. One reason it occurred so often during the conference is that the organizers used a Wiki to develop the program transparently. People watched other people’s talks develop and incorporated their content even before the conference began.    (JN2)
  • A critical pattern, especially for inter-organizational collaboration, is Neutral Space. Wikipedia would not have been successful if it did not have an open content license (which facilitates Neutral Space) and, to some extent, if it were a for-profit company. At the board panel on the last day, several people brought up the question of online ads. On the one hand, ads have the potential of bringing in a tremendous amount of revenue, which could be put to good use for the community. On the other hand, it breaks the Neutral Space pattern that has served Wikipedia so well. The community was more or less split on this issue. My vote: No ads!    (JN3)

One last pattern that I both observed and missed was Users Talk To Developers, a pattern I first described in, “An Introduction to Open Source Communities.” Previously, I criticized the Mediawiki developers for not practicing it enough. With the whole conference finally behind me, I want to both soften and and strengthen my statement.    (JN4)

Many of the Mediawiki developers came to the project as Wikipedia contributors. Brion Vibber, one of the leaders of the project, probably never would have joined had it not been for the Esperanto Wikipedia, of all things. After having more time to interact and observe the developers, I think that on average, community interaction is more prevalent among the Mediawiki developers than it is with many other projects.    (JN5)

That said, it’s still not nearly what it can and should be. During the sessions on politics and developing countries, several panelists complained that the tools had a way to go to meet their needs, and yet, none of the developers were attending their sessions. Hossein Derakhshan noted that techies are generally not interested in issues outside of their sphere.    (JN6)

Not all the blame falls on developers, however. As great as it would have been to see more developers abandoning the technical sessions in favor of the more social ones, it would have been fantastic to see more Wikipedia contributors attend some of the technical sesssions. Both communities need to learn and respect each other’s language if they truly want to engage collaboratively. Bridges are critical to make this work. Note that this applies not only to Mediawiki, but to all Open Source projects.    (JN7)

Hiding the Agenda

Before last weekend’s sprint, several people approached me about the agenda. I responded by offering a general overview of the weekend (Friday, meet each other and plan for Saturday; Saturday, test, analyze, and maybe implement; Sunday, wrap-up), but I did not offer anything more detailed than that. It made many people nervous, but all I could do was to ask folks to trust me. Why the secrecy? Was I being coy, or was I just disorganized?    (ICV)

For highly interactive events with large, diverse groups, I’ve found that the best processes do not share agendas with participants. There are two reasons for this. First, you want the participants to focus on the work. The facilitators (or in the case of MGTaylor, the KreW) watch the clock for you. Second, you want flexibility in the agenda, so that you can self-organize. On the one hand, participants hate meetings that waste your time. On the other hand, they tend to freak out when they see, “To be planned later.” It’s not lack of organization, it’s an acknowledgement of self-organization. You have to be really confident in your process to make it work.    (ICW)

”Leaping the Abyss”, a book about the MGTaylor process coauthored by Blue Oxen advisor, Christine Peterson, has a great story about why agendas aren’t given in advance, and what effect this can have on participants.    (ICX)

If your design and facilitation are good, it works beautifully. Several people approached me after the event saying how skeptical they were during and at the beginning of the event, and how amazed they were afterwards about how it all came together.    (ICY)

Allen Gunn (Gunner), our facilitator, is good, maybe even a little cocky. On the morning of the first day, he was constantly throwing out statements like, “We’ll make it up as we go along.” I’d laugh to myself and cringe at the same time when I heard him say this, but I knew what he was doing and kept my mouth shut. As Gunner explained to someone afterwards, in a way, he’s hustling the crowd. But, as I noted to the same person, you can only get away with hustling if you win.    (ICZ)

Ross Mayfield on Social Software, Social Networks

Last Friday, I finally got a chance to meet Ross Mayfield, who was speaking at the November meeting of the Bay Area Futurist Salon, held at SAP Labs in Palo Alto. Ross is CEO and founder of Socialtext, a company that is selling social software to companies. Some people have compared Blue Oxen Associates to Socialtext, which is apt in some ways, but is not quite right, as I’ll discuss below. Christine Peterson (one of our advisors) had said great things about Ross and Peter Kaminski (Socialtext‘s CTO), and Ross and I had exchanged some pleasant e-mails. The meeting confirmed Chris’s judgement. Not only is Ross a good guy, he had some interesting things to say about Social Software and Social Networks.    (D8)

Social Software    (D9)

I mostly agreed with what Ross had to say about social software, and I especially liked his overall philosophy about what makes a good tool. I did have a few nitpicks, though. Ross defined Social Software as follows:    (DA)

  • Software that supports group communication    (DB)
  • Software that adapts to its environment, rather than requiring its environment to adapt to it    (DC)

I asked him to clarify the latter statement, and he explained that most collaborative software tries to enforce too much structure. These tools force users to figure out how to fit the data into the tool, whereas the tools should fit the data. In this vein, Ross spoke highly of Wikis and blogs, and also of human filtering (such as Google’s technique of measuring backlinks) as a way of organizing information.    (DD)

I strongly agree with Ross’s philosophy, although I don’t like how he worded it in his slide. His statement is equivalent to the first part of Doug Engelbart‘s philosophy of coevolution of tools and processes; however, it leaves out the second part, which is equally important.    (DE)

Doug says that tools ought to augment human processes. However, as we learn more about the tool, we also must evolve the processes to adapt to the tool. An example that Doug often cites is the bicycle. Riding a bike is not intuitive, but it offers significant performance advantages over a tricycle. (To illustrate this point, Doug likes to show this picture.) “User-friendly” tools can be useful, but they should not be the end-goal.    (DF)

One “semistructured” tool that Ross does not like is e-mail. In predicting its demise, he cited several statistics regarding the amount of time required to deal with e-mail, especially but not exclusively due to spam. Ross introduced a cute term that I had not previously heard: “occupational spam” — e-mails from “legitimate” sources that have no bearing on your life or work whatsoever. This often manifests itself as being cc’d on threads of little or no relevance. Ross claimed that 30 percent of our inboxes consist of occupational spam. I should have asked for a citation on that stat, because it’s an interesting one.    (DG)

One of his main arguments against e-mail as a collaborative tool was that it encourages discursive discourse, and that it’s hard to make any sense of the sum product. I agree entirely with this argument, but would use it as an argument for how to use e-mail effectively rather than against e-mail entirely. Internally at Blue Oxen, our e-mail and Wiki usage complement each other quite nicely. We kick off the discussion using e-mail, and we synthesize the resulting thoughts into the Wiki, with links back to archived e-mail.    (DH)

Social Networks    (DI)

Ross’s presentation on Social Networks was outstanding. He’s obviously thought deeply about these issues, and he’s collected quite a bit of interesting research. He first described his and Valdis Kreb’s Blogmap Project, which mapped relationships between members of Ryze‘s Blog Tribe.    (DJ)

He then discussed the power law of blog space, which states that the distribution of links to a blog is inversely proportional to the blog’s rank. In other words, the number of links to the most popular blog is exponentially greater than links to the next-most popular blog.    (DK)

Ross then proposed three types of collaboration: the publishing model (one-to-many, where the power law applies), the individual’s social network, and small teams. He cited the primatologist Robin Dunbar’s work to suggest that social networks generally numbered about 150, and said that people’s interactions with their social networks generally followed a normal distribution. (Interestingly, he showed his RSS aggregator, which had 146 subscriptions.) Finally, he suggested that the optimal size of teams is about 10, and that the number of interactions between team members tends to be about equal.    (DL)

Socialtext Versus Blue Oxen    (DM)

Socialtext and Blue Oxen are similar in that we both are interested in collaborative tools, and that we both share similar philosophies about tools. Socialtext sells these tools as enterprise applications, however, whereas Blue Oxen is focused on understanding how best to use and improve these tools and on disseminating that understanding widely.    (DN)

In that vein, we both have embarked on similar projects, but with different goals. Ross talked about Socialtext‘s experiences with Social Software supporting face-to-face events, and those tools were available during his talk. We did a similar project with the PlaNetwork 2003 Conference, for which we set up a Wiki, RSS aggregators, and an IRC channel.    (DO)

We host collaboratories, and plan on charging for membership to those collaboratories once our infrastructure is up to snuff. However, we’re not an ASP, although we will make (and already have made) ASP-like services available to communities. Our infrastructure is meant to be cutting-edge and rough around the edges. It’s a way for people to experience first-hand what it’s like to use those tools, an opportunity to learn (and share) how best to use them, and a platform for coevolution. Despite our intentions, we’ve already discovered that even with promises of little/no “official” support, people enjoy using our tools for their real-world collaborative needs. As members, they’ll have free access to these tools for their groups. When they start needing better support and enterprise-level features, we will happily point them towards Socialtext and similar companies.    (DP)