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)

BAR Camp 2005 Redux

Thoughts on BAR Camp. Yeah, yeah, a little late, I know. Less late than the rest of my Wikimania notes, though.    (JQX)

Many Hats    (JQY)

The most bizarre experience for me at BAR Camp was the number of people I knew from different worlds. My brain was constantly context-switching. It made me painfully aware of the number of different hats I wear, all in the name of Blue Oxen Associates.    (JQZ)

  • Purple Numbers guy.    (JR0)
  • Wiki geek.    (JR1)
  • Identity Commons contributor.    (JR2)
  • Doug Engelbart translator.    (JR3)
  • Usability guy!!! Obviously because of the sprints I’ve organized, but awkward for me, since I have no actual background in usability.    (JR4)
  • Pattern Language hat. I’ve been doing the collaboration Pattern Language dog-and-pony show the past few months, and some folks who’ve heard me speak on the subject were there. I’ll be doing a lot more of it too, so stay tuned. Patterns are damn important, useful, and interesting.    (JR5)
  • Facilitation / event organizer hat.    (JR6)
  • Nonprofit hat. The lack of nonprofit contingent was disappointing, but I had a good conversation with Ho John Lee, who’s done some great work in that space. (We were also both wearing our Korean hats, along with Min Jung Kim, a rarity at events like these.) I also met Phil Klein, a nonprofit guy who also participated in our usability sprint the following week.    (JR7)
  • Ex-DDJ hat. Some fogies, young and old, remembered me from my magazine days.    (JR8)

All this was testament both to my ADD and to the job Chris Messina, Andy Smith, and the other organizers did in only one week. Three hundred people walked through the doors over the weekend. Amazing.    (JR9)

Talks    (JRA)

The best part of the event was strengthening familiar ties and building new ones. I met lots of great people, including folks I’d only known on the ‘net. I wasn’t blown away by the talks for the most part, but some stood out.    (JRB)

  • Ka-Ping Yee did two talks, one on voting methods and another on phishing. Sadly, I only caught the tail end of the latter, but the Wiki page is fairly complete. I’ve never seen Ping do anything that I didn’t find interesting or, in many cases, profound, and these talks were no exception. (I’ll have more to say on Ping’s latest work in a later blog post.)    (JRC)
  • Xiong Changnian presented some interesting quantitative analysis of the Wikipedia community. I didn’t have as much of an opportunity to talk with Xiong as I’d like, but for those of you who have interacted with him, try not to be turned off by his bluster. He’s doing some good work, and he seems to mean well.    (JRD)
  • Rashmi Sinha and I did a roundtable on Open Source usability on the first night. Afterwards, we both agreed that we didn’t learn much new, but simply having the conversation and especially listening to a new audience was valuable. One unintended outcome: A participant (who shall remain nameless, but not unlinked!) complained about Socialtext‘s usability, which I dutifully reported on the Wiki. Adina Levin and Ross Mayfield quickly responded, saying they’re looking to hire a usability person. If you’re in the market, let them know.    (JRE)

I was so busy chatting with people, I also ended up missing a bunch of good talks: Rashmi’s tagging session, Rowan Nairn on structured data for the masses, and Tom Conrad‘s Pandora talk, which seemed to generate the most buzz at the camp.    (JRF)

Throwing Great Events    (JRG)

I toyed with the idea of doing a techie session, but in the end, the talk I should have done was one on patterns and throwing great events. BAR Camp was great, and as with all great collaborative events, there were some common patterns:    (JRH)

  • Food. One of the most critical and, amazingly, most overlooked element in an event. Lots of credit goes to Kitt Hodsden, who made sure there were enough snacks to feed a small country, and the sponsors, who kept the beer flowing and underwrote the party on Saturday night.    (JRI)
  • Introduce Yourself. The organizers borrowed the FOO Camp tradition of saying your name and three words to describe yourself, and they did it each day.    (JRJ)
  • Shared Display and Report Out. Folks did a great job of documenting on the Wiki and on their blogs and Flickr. BAR Camp owned the foobar Flickr fight.    (JRK)
  • Backchannel. I’m not a big fan of IRC at face-to-face events, and there were definitely times when I thought it detracted from the face-to-face interactions. But, it was there, and it was useful. It wasn’t logged, though.    (JRL)
  • Permission To Participate. Lots of Open Space techniques were present — again, borrowed from FOO Camp — like the butcher paper for scheduling sessions. Lots of this was also cultural, though. I think this is the hardest thing for folks who do not live in the Silicon Valley to get — the spirit of sharing that comes so naturally to folks here.    (JRM)

I’d do two things differently at the next event:    (JRN)

  • Incorporate a ritual for new attendees to make them feel welcome and to avoid clique-formation.    (JRO)
  • Add slightly more structure. Now that the organizers have done it once, they can use it as a template for the next event — for example, publishing the time slots ahead of time, and actually enforcing them, at least as far as room usage is concerned. Also, I like scheduled Report Out sessions.    (JRP)

In the postmortem, we talked a bit about what BAR Camp is supposed to be, and I really liked how Chris positioned it: As a model for organizing grassroots, free (or very cheap) alternatives to more expensive gatherings. I’m toying with the idea of incorporating BAR Camp-style alternatives to complement some non-free events I’m organizing.    (JRQ)

ChiliPLoP, Day 4

Last Friday was the last day of Chili PLoP. Ofra Homsky, Josh Rai, Linda Rising, Joe Yoder, and I met at our usual spot outside of the dining hall for our morning kickoff. We had two items on our agenda: workshop the patterns we had discussed the day before and that Josh and I had written up, and discuss next steps.    (1DF)

Stone Soup    (1DG)

We started with Collab:StoneSoup and decided to temporarily combine forces with the GivingSpace group, which had independently come up with a pattern of the same name. That experiment resulted in some constructive feedback but was short-lived. The most important lesson was that “Stone Soup” was a completely inappropriate name.    (1DH)

The pattern had arisen from a point I had made the previous day about faith in process. I stated that people about to participate in a new process had to demonstrate a certain amount of faith up-front; otherwise, they risked subconsciously hijacking the process. You want to give the process the chance to succeed or fail on its own merit.    (1DI)

Joe suggested calling this pattern, “Fake It ‘Til You Make It.” Ofra was reminded of a story, “Stone Soup,” which went like this.    (1DJ)

A weary soldier discovered a village in the desert and knocked on every door asking for food. Everyone turned him away.    (1DK)

Undaunted, the soldier took his pot, filled it with water and a large, round stone, and put it over a roaring fire, constantly stirring and tasting.    (1DL)

The curious villagers came out of their houses and watched, until finally, one of them asked how it tasted. The soldier replied, “It’s good, but it needs some salt.” So the villager went inside her home and brought out some salt.    (1DM)

She again asked the soldier how the soup tasted, and he responded that it could use some carrots. So another villager brought some carrots. The process repeated itself until eventually, there was enough tasty soup to feed the entire village.    (1DN)

During our group writing exercise, it quickly became apparent that we all had slightly different understandings of the pattern. Mine focused on the point of view of the participant and on adopting new processes. Everyone else seemed centered on initiating new collaboration, setting up enough structure to make the collaboration seem real, at least until the collaboration became real.    (1DO)

When I started refactoring and combining our work into a single pattern, I decided that there were multiple contexts for the same pattern, but that the solution was the same. I also decided to call it, “Stone Soup” instead of “Fake It ‘Til You Make It,” mostly because the former was a noun phrase. I had reservations, however, and our final day’s proceedings confirmed them. When we combined with the GivingSpace team, it became clear that there were at least three different versions of the Stone Soup story, each with different morals.    (1DP)

After we split with the GivingSpace group, my team continued giving feedback about what I had written. I picked up lots of good advice and promised to incorporate their comments into a revision.    (1DQ)

Kick Off    (1DR)

I was happy when Josh willingly took on the Collab:KickOff pattern, because I didn’t think we were close to Shared Understanding. That said, Josh’s work on the pattern helped us make that leap.    (1DS)

Originally, we called the pattern, “Kick Off Meeting.” I had asked whether the Kick Off meeting was, by definition, the first meeting. Ofra and Joe had said that it was not. However, as we started fleshing out the pattern, it wasn’t clear to me what the distinction was. People were mentioning a lot of things that supposedly happened at Kick Off meetings that I felt would happen regardless of whether or not a meeting was designated, “Kick Off.” The key distinction, in my mind, was whether or not those things would happen well. It wasn’t clear to me that denoting a meeting “Kick Off” was enough to make those things happen well.    (1DT)

Josh’s work on the pattern made some of those flaws apparent. Having something concrete to work from allowed us to quickly zone in on the vital piece — benefits from the ritual celebration of initiating a new project. We decided to remove “meeting” from the name.    (1DU)

In the end, this made perfect sense to me. We had defined collaboration as needing shared, bounded goals. We had also cited a pattern, Grand Finale (discussed in Linda and Mary Lynn Manns‘s upcoming book). It made sense that we also had a pattern for the beginning of a project as well.    (1DV)

Next Steps    (1DW)

One of the things I made clear to the group was that I considered this workshop to be the Kick Off to Blue Oxen Associates‘s ongoing Pattern Language effort. One of my broader goals is to do an ongoing series of workshops involving philanthropic foundations, nonprofits, and a variety of other organizations. These workshops would involve telling stories, mining for patterns, capturing those patterns, reinjecting them into the conversation, refining them, and so on.    (1DX)

In the meantime, I plan on further developing the language that began forming at our workshop with the help of our Collab:PatternsWorkGroup. I also plan on submitting some patterns to the PLoP conference in September.    (1DY)

I had an exceptional time at Chili PLoP. Lots of great people were there, and Arizona is warm and beautiful this time of year. More importantly, I was fortunate to have a great group of participants. Ofra, Josh, Linda, and Joe brought a tremendous amount of experience and enthusiasm to the process, which made the process both enjoyable and productive. I’m looking forward to the challenge of continuing what we started here, including another date at next year’s Chili PLoP.    (1DZ)

ChiliPLoP, Day 3

Last Thursday, my workshop met for a second day. Having agreed on a working definition for collaboration (see Collab:Collaboration), we started working on the Pattern Language. As was the case the previous day, I knew exactly what I wanted to accomplish, and I made that clear when we got started. What differed this day, however, was that Linda Rising, Ofra Homsky, and Joe Yoder — our three experienced Pattern Language authors — led the way in terms of process.    (1CT)

We began by laying out the index cards we had collected the previous day onto a table. The goal was to see what patterns we had and what seemed to be missing. The definition that we had collectively agreed on the day before helped us tremendously with this process. For example, because collaboration — as we defined it — required bounded goals, that meant there were patterns related to the start and end of the collaborative process. There were also patterns related to interaction (meetings for example) and knowledge exchange (Shared Display).    (1CU)

Mapping out our cards also helped us identify gateways to other Pattern Languages, such as Linda and Mary Lynn Manns‘s patterns for introducing new ideas into organizations, Ofra’s patterns for leadership, Jim Coplien and Neil Harrison‘s organizational patterns, and GivingSpace‘s patterns of uplift.    (1CV)

Lots of brainstorming and storytelling happened throughout. My favorite was a story that Joe Yoder told about a factory where he had previously worked, which literally left its financial books open on the factory floor. Anyone who worked at the company could examine the books and suggest improvements. The open books were a form of Think Out Loud that showed that the company treated its operations as a collaborative process involving all of its employees, regardless of position. Tremendously empowering stuff.    (1CW)

Linda, Ofra, and Joe constantly stressed the importance of iteration and cautioned Josh Rai and me about getting too caught up with formality too early in the process. Ever fearful of being berated by Ralph Johnson or Jim Coplien, I would periodically complain, “That name isn’t a noun phrase!” Fortunately, the rest of the group kept me on track. We had plenty of time to weed out and refine our patterns after the brainstorming process.    (1CX)

We ended our brainstorming at lunch, at which point we had 36 cards. After lunch, we picked two patterns — Collab:StoneSoup and Collab:KickOff — and Linda led us through a group pattern writing exercise. (I’ll say more about these two patterns when I describe Day 4.) She gave us a letter-sized piece of paper for each component of the Coplien Form (name, problem, context, forces, solution, rationale, resulting context, known uses, and related patterns). Each of us took one piece of paper, wrote down our ideas, then exchanged it with someone else for another piece of paper. The cycle continued until we all had our say to our satisfaction. Afterwards, we discussed what we had written.    (1CY)

This was the first time Linda had tried this particular exercise, and I think it worked very well. It was particularly good at helping us reach Shared Understanding. We all had slightly different views of both patterns. Actually going through the group writing process helped make these differences explicit, at which point we were able to talk through our differences.    (1CZ)

Because Josh and I were the pattern-writing newbies in the group, we each collected the sheets for one of the patterns and promised to combine, edit, and rewrite them into a readable draft. I chose Collab:StoneSoup; Josh took Collab:KickOff. The plan for Day 4 (which was only a half day) was to workshop our results.    (1D0)

I ended the day with a brief overview of how blogs and Wikis integrated with Backlinks could be used to tie stories with corresponding patterns.    (1D1)

Chili Beer    (1D2)

Since that night was our last in Carefree, I decided to organize a margarita BOF. Earlier, somebody had told us about the Satisfied Frog, a legendary Mexican restaurant and bar that had “a thousand different kinds of margaritas.” This was the obvious place to hold our BOF, so Josh, Jerry Michalski, Gerry Gleason, and I trekked on over.    (1D3)

As with most legends, the facts had been slightly exaggerated. The Satisfied Frog only served one kind of margarita, although in fairness, it did give us the option of frozen versus on-the-rocks and with or without salt.    (1D4)

The restaurant did, however, brew its own special beer — chili beer — which was bottled with a serrano chili pepper. It had a nice kick to it, but it wasn’t overpowering. I recommend it to those with a a penchant for adventure and a bit of a heat tolerance.    (1D5)

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)

Marc Canter added:    (1AW)

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)

Jameth later added:    (1B4)

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)

Dorothea Salo wrote:    (1B8)

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)