What You Can and Can’t Learn from an Open Collaborative Workspace

One of my favorite parts about open collaborative tools is the ability to observe the evolution of collaborative projects.  Platforms like wikis, blogs, social bookmarking, and even discussion forums enable any observer to come in and view the history of any given article, compare versions, and review the progress and process of that page.  But at the same time, it’s important to remember that there’s a lot of work that goes into a collaborative projects that can’t be gleaned from simply watching the changes to wiki pages. So in the name of getting my thoughts down, here’s an incomplete list of some things that you can learn and what you cannot learn from outsider observation (I see some follow up posts to this topic in the future).

What You Can Learn

Who’s literally made the change to the page: You can certainly measure raw, quantitative participation: i.e. Justin has made 20 edits or has posted 7 blogs or has tagged 14 items with 24 tags.  This has a place in evaluating collaborative projects, obviously: in most cases of open collaboration, more participation is better.

You can tell literally what–qualitatively–a user has contributed to the project. The transparency of contributions means that you can see exactly who and when an idea or contribution was made.  So I can see that Justin added 2 paragraphs of content to the wiki page and 3 blogs worth of ideas today.  While this in isoluation is not really important, these contributions can be qualitatively evaluated.  Likewise, you can see who is playing a more facilitative or leadership role in projects.

Social Networks. Certain elements of social networks become visible when you look at collaborative projects in open environments.  Social bookmarks reveal who is tagging content for a project, thereby linking those participants.  Blogs with comments clearly link people to their thoughts, but also to the people behind the contributions at some level.  Similarly, you can discern the strength and weakness of links by looking at actual participation.

What you can’t learn

However, there’s a lot of work that goes into collaborative projects that goes unnoticed and undetected, even in an open collaborative environment.

Triggers, positive and negative.  One of the most interesting aspects of projects that is simply not visible to the outside are triggers for participation.  You may be able to literally see that a person who should be a prolific contributor only contributed once to a big collaborative project; however, what’s not visible is why they haven’t paricipated.  Technical hurdles? Lost interest? Managerial interference? Too Busy?

Rallying. As I’ve said before, collaborative projects require a good amount of leg work behind the scene in order to get off the ground.  So while some of these are visible–blogs, announcements in the wiki, etc–many are not.  Without actually engaging the participants of the projects, you cannot, as an outsider, understand the work done behind the scenes.  So I can’t tell that the project’s leader called colleagues on the phone from 5 different organizations, visited 3 seperate offices to build the network, and spent 3 hours talking to leaders face to face.  All of this activity is important to the success of a project, but it’s not really visible from the outside.

Ghosting Participants. Technology is changing quickly and some folks just can’t or don’t want to keep up with the latest developments and newest tools.  So, from my experience, many times there ends up being one “stuckee” from an organization or office that ends up doing the lionshare of the actual posting of information.  In this case, what looks to be a single prolific contributer may be 5 people’s contributions via a single point of entry.

The Key

As a consultant, nothing’s asked of me more than to provide best practices.  And the best practice for advising clients is that quite simply, you have to look beyond the numbers so that you can actually tell the story of the collaboration. Evaluating and understanding a collaborative success or failure not only takes leg work to track participation and contributions, but also to talk to the contituency, both active and non.

Gardening and the Tragedy of the Commons

Pre-S: I know i’m not good at frequently getting blogs up here; I’ll try to do better.

This post is the confluence of a number of activities in my professional life. For one, I am currently reading The Gridlock Economy by Michael Heller, which talks about the opposite of the tragedy of the commons, which he defines as “Underuse” or the “tragedy of the uncommons” (This idea has further applicability to my work and may warrant a few posts by itself).   The other thing I’m currently working on is the business process, change management, and collaboration consulting piece of a Clearspace deployment for my client’s organization.  One of my tasks for the deployment project is to conceptualize gardening in the space, a term that actually only loosely applies in a non-wiki collaborative environment.

So in thinking about this problem in the context of the tragedy of the commons, it is becoming clear to me that the purpose of gardening and gardeners in a large open collaborative environment is ultimately to mitigate the “tragedy of the commons”.  For those unfamiliar with this problem, the idea comes from an article of Science from 1968, where Garrett Hardin theorized that when multiple individuals acting independently in their own self-interest can ultimately destroy a shared resource even where it is clear that it is not in anyone’s long term interest for this to happen (definition comes from the Wikipedia entry).  For those not

In terms of solutions to the tragedy of the commons, Heller offers three courses of action: Privatization, “cooperative engagement”, and regulation.  In an open collaborative environment, the first one is out: privatizing will ultimately just lead us back to stovepipes and compartmentalization.  Regulation is a fine line to walk, as too much regulation will kill innovation and the free exchange of ideas (additionally, in many cases–like Wikipedia–there’s nobody to actually regulate the space).  I would pose that “cooperative engagement” is the rough equivalent of gardening in an open collaborative environment.

For an open collaborative environment to thrive, it is dependent on this cooperative engagement in order to avoid becoming a victim of overuse.  In a collaborative environment, “overuse” takes the form of users ignoring guidelines and best practices: When one person bucks the larger trend, it damages the environment only slightly.  But when many users start to go against accepted practices, the environment can quickly become a collection of unorganized, unconnected data which ends up having only pockets of usability.

And this is why gardeners do what they do.  This is why in a wiki they hassle people about things like Naming Conventions or using categories or adding links.  Or in a platform like Clearspace suggesting users’ combine workspaces, fill out profiles, or tagging information.  Or, across all platforms, encourgaging open discussion and communication, facilitating discussions of guidelines and best practices, and discouraging violation of agreed guidelines.  It’s because gardeners are fighting the tragedy of the commons.

So what’s the point?

Gardeners play a key role in all open collaborative environments, whether its a more technical variety–organizing content, etc–or whether its facilitation–creating social networks, dispute resolution, and monitoring the health of the community.  In my experience, this collaborative cooperation/engagement of all users/mentorship model is the absolute best way to avoid the tragedy of the commons in large open collaboration environments.