OCSI Meeting Synopsis

I was in Anaheim yesterday for the Open Collaborative Services Initiative (OCSI, pronounced “oxy”) workshop, which was part of the OMG Technical Meeting. Johannes Ernst, one of the OCSI organizers, invited me to present my manifesto on collaborative tools (which will be published in Dr. Dobb’s Journal and on the Blue Oxen Associates web site).    (WI)

OCSI is an attempt to get collaborative tool vendors to make their tools more interoperable. One of its early goals is to develop a shared architectural blueprint for describing collaborative tools, perhaps initially in the form of a white paper. This has been a refrain of mine for quite some time, and so I was very glad to participate in the group’s second meeting.    (WJ)

As it turned out, there was a tremendous amount of conceptual synergy in the room. I suppose I shouldn’t have been too surprised. At the beginning of my talk, I explained that one of our beliefs (also known as the The Blue Oxen Way) is that Shared Ontology (which results in Shared Language) is a prerequisite to effective collaboration. OMG is a very strong proponent of Model Driven Architecture, which is essentially an instantiation of Shared Ontology. Not surprisingly, there was universal consensus in the room about developing a shared model of collaboration — both on the human-level (e.g. Blue Oxen‘s work with Pattern Languages) and the system-level (the topic of my manifesto).    (WK)

In his introductory remarks, Johannes made several interesting points:    (WL)

  • The word “collaboration” means many different things to different people. This simply underscores the need for a common vocabulary.    (WM)
  • Collaboration seems to be an “it” topic among CEOs and CIOs. However, as often as they mention collaboration and as important as they claim it is, the collaborative tools market has been flat the past few years. At first, this seems to be a contradiction. However, the number of corporate downloads of free IM clients over the past few years indicates that the need for collaboration is real. One of the problems is that tools are not interoperable enough.    (WN)
  • There is no horizontal industry initiative for improving interoperability of collaborative tools. However, several vertical industries have expressed interest. One of the challenges is to get the different industries to realize that they share common needs so as not to duplicate efforts.    (WO)
  • Johannes chatted with a few tool vendors about this problem. Their response: “That sounds great, but I have a product to get out.” The way to get vendors more serious about interoperability is probably bottoms-up — via the user community.    (WP)
  • In this regard, the Open Source community could play an important role. The prequisite for standards is Shared Language and free implementations. We have the latter, but we don’t have the former. If we created Shared Language and if Open Source tool-builders adopted it, we could build a compelling case for standardization. Johannes feels that it is vital to involve both the proprietary and Open Source communities in the OCSI effort.    (WQ)
  • Collaborative interfaces should be as transparent as telephone numbers. When we see a telephone number, we know what to do, regardless of the underlying service provider, protocol (POTS versus VOIP), type of telephone, etc.    (WR)
  • Cut-and-paste is a type of interoperability between collaborative tools. (A poor one, as I and others noted later in the workshop, but also a relatively effective one — a good example of loose-coupling.)    (WS)

Other talks of note:    (WT)

  • David Hartzband, VP of collaboration technology at , provided a four axes view of collaborative tools: synchronous, asynchronous, inline, and contextual. He also observed two trends in the collaborative tools space: business communications convergence (e.g. telephone integrated with email integrated with your documents, etc.) and enterprise application functional convergence.    (WU)
  • Carol Burt, CEO of 2AB, shared her vision for model-driven access management. Not only could such a model have ramifications for those developing secure applications and those selling security software, it could also potentially plug in to an OCSI model for collaborative tools.    (WV)

At the end of the workshop, Joaquin Miller (the other OCSI co-organizer) led a discussion about the next steps within the OMG umbrella. The consensus seemed to be to propose the formation of an OMG SIG, which could potentially evolve into an OMG Task Force. Not being an OMG member myself, the conversation both baffled and fascinated me at the same time. Nevertheless, the folks there seemed to know what they were talking about, which is always an excellent sign.    (WW)

The next meeting will be at the next OMG Technical Meeting in St. Louis next April. We’ll continue to collaborate via an eRoom set up by David and via the OCSI web site. Our action item for now is to share our individual high-level models of collaborative tools in order to identify commonalities and to serve as straw men for additional discussion.    (WX)

Sheldon Chang’s SocialWave Blog

Sheldon Chang, a member of our Collaboration Collaboratory, recently announced a new blog: SocialWeaver: Building Real Communities Online. Sheldon has a startup called SocialWave that builds online communities as a way to strengthen communities within neighborhoods. He’s thought quite a bit about community-building in general and has a lot of interesting things to say, which is why I’m very glad to see him join the blogosphere.    (W1)

In his first post, “A Real Model for the Virtual Community,” Sheldon suggests that people must feel comfortable to build their online identities in order for an online community to be successful. This requirement prevents effective online communities from truly scaling.    (W2)

Sheldon’s blog entry generated some discussion in the collaboratory. John Sechrest discussed latent energy in forums, emphasizing the role that lurkers play in the effectiveness of an online community. He also posed and elaborated a theory of group size: The maximum size of a manageable community is 256 people. (Ross Mayfield described a more scientific theory of group size, based on Robin Dunbar’s research, at his talk last November.)    (W3)

ChiliPLoP 2004 Hot Topic

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)

Tools As Place

When we first launched the Blue Oxen Collaboration Collaboratory, a few people expressed some confusion about the tools. Specifically, one person said, “I’m not sure whether I should post ideas to the mailing list or the Wiki.”    (UG)

Someone I’m working with recently asked a similar question. Our project has a group blog and a Wiki, and this person expressed confusion over where to post a story.    (UH)

In both cases, my answer was, “It doesn’t matter.” Or at least it shouldn’t. My philosophy about collaborative tools is that they shouldn’t lock you in. As long as I can do all of the things I want to do with the information once it’s in a tool, I’m happy. This is not the status quo with today’s collaborative tools, but it’s something we’re working very hard to make happen. You can see some of the fruits of that labor in the tools that we use at Blue Oxen, and the tools that our collaboratory participants have created.    (UI)

That said, certain tools facilitate certain patterns better than others. Blogs seem to facilitate Story Telling better than Wikis. I think the main reason for this is that blogs are designed to be personal spaces, whereas Wiki pages are implicitly deindividualized.    (UJ)

What patterns does email facilitate? Email serviceably facilitates many patterns. That’s a blessing and a curse. It means that email is an all-purpose collaborative tool. But, when groups are using email in conflicting ways, it becomes burdensome. (See Problems With Email for more thoughts on this.)    (UK)

The ideal solution is to use an integrated suite of tools, each of which are there to facilitate specific patterns. If these tools are appropriately interoperable, then there won’t be “wrong” ways to use the tools. But, there will still be optimal ways to use these tools. Discovering what’s optimal requires practice. Hand Holding also helps.    (UL)

Email (and archived mailing lists in particular) plays two important roles in this suite of tools. First, it’s excellent for notification. Second, it’s excellent for Chatter. It can be as real-time as instant messenging, but the end result is more structured.    (UM)

I think there’s a niche for a tool for discourse that is even more structured than email or threaded forums. I don’t think Wikis are the answer. I think group blogs and tightly bound blogs come close, but are not quite right either. I’ve been sketching out the design for a tool I believe will fill that niche, which I’m calling Abelard for now. The design is in its infancy, so I won’t say anything more about it now. However, you’re welcome to view (and contribute to) its Wiki page, which contains a brain dump of the ideas. Comments and questions (in any form — on my Wiki, on your blogs, or via email) are welcome.    (UN)