Chili PLoP – Eugene Eric Kim

The Story of Glormf: Lessons on Language and Naming

Published June 6, 2006 by Eugene Eric Kim

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)

ChiliPLoP, Day 4

Published April 20, 2004 by Eugene Eric Kim

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 1

Published April 14, 2004 by Eugene Eric Kim

Yesterday afternoon, I arrived in Phoenix, Arizona for Chili PLoP
2004. I hitched a ride with Ralph Johnson and Joe Yoder to Carefree,
Arizona, and soon found myself at the Lutheran Retreat Center, where the
conference is being held. (1BJ)

The post-dinner agenda was to discuss the structure of the
conference. Other than the meal schedule (which is strictly
enforced), there is no structure. This is what differentiates
Chili PLoP from Hillside Group‘s other PLoP conferences. The setting is
more relaxed, and the agenda is entirely flexible. (1BK)

Once we got business out of way, the fun began. There were a lot of
great conversations, and a few of us stayed up late into the night
chatting about everything from Pattern Languages to politics. (1BL)

Tom Munnecke got the discussion started by asking about the
generativity of Pattern Languages. This is an ongoing beef that Tom
has with Pattern Languages, a misunderstanding that’s important to
clarify. (1BM)

Tom’s thesis is that society is too problem-centric. For example, our
approach to healthcare is to cure sickness rather than to promote
healthy living. Tom’s GivingSpace project — and the reason he’s here
— is to identify and propagate patterns of uplift. This is a
wonderful effort. It’s related to our work on patterns of
collaboration, and it’s an effort I fully support. (1BN)

Patterns are often defined as solutions to problems in a context.
Tom’s complaint is about the term “problem”; he think it prevents
patterns from being generative. “Problem” in this context, however,
means, “Something that needs a solution,” not, “Something that is
wrong.” In other words, describing things in terms of problems and
solutions does not necessarily prevent the solution from being
generative. (1BO)

In fact, Christopher Alexander stresses the importance of identifying
generative patterns. Linda Rising cited an example first described by
Don Olson (and is also discussed in Linda’s book, The Patterns
Handbook). Beginning skiiers often have a tendency to lean back,
something that will cause them to lose their balance. You could say
that one pattern is, “Don’t Lean Back.” This is not very useful
advice. Leaning back is an instinctive, not conscious action. (1BP)

Don’s suggested pattern is “Hands In View.” This is a conscious action
you can perform, and the end result is that you lean forward. This is
a great example of a generative pattern. (1BQ)

Ralph cited a similar example in software development:
qmail. The motivation for qmail was to
build a secure mail server. The approach, however, was not to
identify and fix every security problem. The approach was to design
small, modular programs that were easy to verify as secure. In other
words, security was an emergent property of the software’s design. (1BR)

Manifesto Comments, Responses

Published April 12, 2004 by Eugene Eric Kim

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)

ChiliPLoP 2004 Hot Topic

Published January 26, 2004 by Eugene Eric Kim

My proposal for a Hot Topic on patterns of collaboration and High-Performance Communities at ChiliPLoP 2004 has been accepted. We’ll be identifying and discussing these patterns and creating and refining the language, building on previous work by Blue Oxen Associates and others. (VD)

PLoP (“Pattern Languages of Programming”) is a workshop devoted to reviewing pattern languages. The Hillside Group sponsors several of these workshops throughout the year. Although the original mission focused on patterns for software engineering, the scope has expanded to cover practically everything, technical and not. As far as I’m concerned, these folks are the experts on writing good Pattern Languages, regardless of topic. (VE)

I’m looking for people who’d like to participate in the workshop. You do not have to be a member of the Hillside Group to attend, although you will have to register for Chili PLoP ($600 before March 1, or $500 for commuter participant). If you’re interested in improving collaboration or learning more about Pattern Languages, I highly encourage you to attend. Chili PLoP 2004 will be held April 13-16 in Carefree, Arizona. Drop me an email if you’re interested in participating or if you have further questions. (VF)