Digital habitats: stewarding technology for communities

January 1st, 2009 has been the target publication date for the book for a while, but that now seems to be slipping.  We’re working as hard as we can on type faces and layout details and all of that.  At the same time we’re using chapters of the book in a CPsquare workshop called “Connected Futures.”  The discussion with workshop participants last Monday convinced us that the separate and occasional problems we’ve had talking about the polarities in this slide really needed to be addressed:

So Chapter 5 is getting a quick rewrite to talk more carefully about the togetherness / separation and reification / participation polarities.  We hope the rewrite won’t affect the final publication date, but it’s an example of the complications and risks on the way to press.

Coincidentally, I’m reading a thesis from CPsquare’s research and dissertation fest titled “A system that Works for Me - an anthropological analysis of computer hackers’ shared use and development of the Ubuntu Linux system” by Andreas Lloyd.  He gives a precise and insightful observations of how a community of practice deals with the polarities through their technologies and their relationships at the same time. Referencing the thesis or discussing it is out of scope because that would delay publication!  But Lloyd’s work is a good reminder that seeking to be precise about the polarities in Chapter 5 is really worth the risk of taking extra time. The following extended quote starts on page 55:

The Jargon File describes how the importance of not being interrupted is deeply engrained in hacker etiquette:

… if someone appears at your door, it is perfectly okay to hold up a hand (without turning one’s eyes away from the screen) to avoid being interrupted. One may read, type, and interact with the computer for quite some time before further acknowledging the other’s presence (of course, he or she is reciprocally free to leave without a word). The understanding is that you might be in hack mode with a lot of delicate state in your head, and you dare not swap that context out until you have reached a good point to pause.

I experienced this several times in my visits and interviews with Ubuntu hackers, whose partners and friends over time have come to allow room for and be forgiving of these programming­ related eccentricities. In turn, the hackers themselves often take care to balance their time on the computer in relation to their family’s needs, when they reach one of those “good points to pause.” I have found that this duality is also very characteristic for the way that hackers interact with each other on­line where you can’t assume that people are communicative at any given moment. As Ellen Ullman points out, this inability to be interrupted makes hackers somewhat asynchronous to one another – at least in the short term (Ullman 1995:132). This is reflected clearly by the fact that all of the Ubuntu hackers’ preferred on­line communicative means are textual and thus – at least to some extent – asynchronous. Email, newsgroups and web forums postings and bug tracker comments are all based on users reading and replying asynchronously. Even real time communications such as IRC chat channels and Instant Messaging bend to this rule as developers “ping” each other, and if there’s no immediate response, they can ask their question and let the other answer when he has time or attention to spare:

…
09:00	carlos	pitti: ping
[...]
09:07	pitti	carlos: pong
09:08	carlos	pitti: I did a mistake yesterday night and latest Edgy export has the plural form bug (bug #2322)
09:08	Ubugtu	Malone bug 2322 in rosetta “Truncated plural forms” [Critical,In progress] http://launchpad.net/bugs/2322
09:09	carlos	pitti: I’m exporting a new version with that fixed, but it would take around 23 hours
09:09	carlos	am I late to have it in the prerelease version?
09:09	pitti	carlos: ah, then I’ll rebuild the edgy packs this afternoon
09:09	pitti	carlos: it won’t go into RC anyway
09:09	carlos	ok
09:09	pitti	carlos: the plan is to upload the final packs tomorrow
09:10	pitti	carlos: thus I’d like to have today’s in perfect shape
09:10	carlos	I see
09:10	carlos	ok
09:10	carlos	pitti: I will ping you when the new version is available

Here, Carlos needs to notify Pitti of a new bug which he needs to take into consideration when building a group of packages for upload. Since Pitti is busy, the conversation doesn’t continue until Pitti is able to respond and they can coordinate their work. Most of the Ubuntu hackers’ day-to-day interaction takes place on IRC where they can pick up on interesting discussions and be available if someone needs to ask a question. The hackers deftly navigate back and forth between conversations, fluidly participating as the IRC client automatically notifies them when someone “pings” them or even just mentions their online moniker. And even if they miss something, they can always go back to check the chat logs or mail archives as all interactions within the community are recorded and publically archived online. At times, IRC is such an easy and non-intrusive way of quick communication that it supersedes conversation even when developers are in the same room. Mark Shuttleworth enjoys relating the story of how he went out to buy beer during one of the first gatherings of the core Ubuntu developers at his London flat. When he came back he found 18 hackers sitting in his living room, working in silence, exchanging textual information on IRC. [20] This anecdote illustrates how the work environment provided by the system takes precedence over face-to-face discussions simply to avoid breaking the flow state afforded by the computer. [21]

[20] I saw the same trend again and again at conferences, one time even witnessing two hackers quietly sitting in opposite ends of a conference room, having a furious argument on IRC about who should be responsible for fixing a troublesome piece of software, and it didn’t end until one of them looked up and saw the other hacker sitting at the far end of room and contentiously shouted: “Stop being such an arsehole!”

[21] This asynchronous sociality is not only a norm well suited to hackers’ mode of collaboration, but it is at times also a necessity as the Ubuntu hackers are spread across the multiple time zones, mostly in North America, Europe and Australia, making exchanges such as this common:

15:56	mdz	good evening
15:57	zul	afternoon
15:58	ajmitch	morning
15:58	mdz	good UTEvening

It is easy to forget that the Ubuntu community spans the entire globe, since it mostly becomes an issue when it comes to finding IRC meeting hours that fit all members of the community, and meetings typically rotate between being early morning, late afternoon, or late evening to accommodate as many time zones as possible.

Funny how you don’t update mental statistics like, “how long have you been working on the book?”  I’ve been answering the question with “three years” for a long time.  But actually we started working on the project in January 2003, so that makes it four and a half years.

During our meeting yesterday afternoon I was struck by how different the three of us are in our preferences and tastes when it comes to things like fonts, graphic images, and book design.  When you consider how we came to agreement on so many things when it comes to the content of our book, all those differences make me really appreciate the agreements that we forged during those four and a half years of collaboration

We’re working on a book title.  So the end of the project is nigh!

We’re wrapping up our plans and materials for our new workshop, developed and presented by Beth Kanter, Beverly Trayner, Bronwyn Stuckey, Etienne Wenger, John D. Smith, Nancy White, Nick Noakes, Shawn Callahan, Shirley Williams, and Susanne Nyrop.It includes a lot of modeling of learning interactions, stratagems, and tactics using a dozen different social technologies.

We’re designing the workshop to support:

• Getting to know each other, each other’s communities
• Creating “a workshop as laboratory”
• Exploring real communities, from an insider’s perspective to see community orientations & technology integration
• Considering the role and activity of the technology stewards in authentic situations
• Exploring the uses of social technologies to stay in touch as well as for sustained inquiry
• Experiencing the design of learning agendas and then configuring technology to pursue those agendas
• Articulate strategies to introduce new social technologies to a community

• Communities of practice theory glimpse
• Community technology stewardship
• Tools and their Integration
• Scanning the Technology Landscape
• Orientations: community experience and configuration of tools
• A More Distributed Future
• A Learning Agenda

Connected futures workshop starts April 28: http://www.cpsquare.org/edu/CP2W2/

I ran across this slide in a larger deck used by a colleague to deal with a set of technology decisions for the communities of practice in her company:

| View | Upload your own

Apart from the way that Etienne’s classification scheme has been modified slightly to be relevant to the issues on the table, the fact that they’ve gone to the trouble of updating the diagram is a good reminder of how difficult it is to think systematically about all the tools that are out there and how they might work in practice.

Don’t you love technical problems? Our WordPress installation had some sort of major foo and we lost everything. Even the back up was full of garbage.

Thankfully not all is lost. There is the Internet Wayback Machine where we have been able to find most of the posts. We’ll have to reconstruct some of the latter ones where we only have snippets via technorati. We’ll be adding these posts back in as time allows. If there is something in particular you need, let us know and we’ll hunt it up.

But there is one HUGE loss.

We lost all your comments. We love you. We love your comments. So we deeply apologize for their loss! We have some back up plans to avoid this in the future.

Live and learn, eh?

Ruby on Rails is a new and increasingly popular web application framework. Like many technologies today, it has an active community of developers and they have the customary suite of wikis, file repositories, email lists, blogs and RSS feeds. One thing that catches my eye about the Ruby on Rails community is its very active, open-ended, ongoing conversation on an IRC channel. Its shop-talk goes 24 hours a day. Last April, I captured about 12 hours of conversation overnight (Pacific time).

Last week I posted a bit about technology stewardship, particularly community tech stewardship. Beth asked for a definition - a great question. So John Smith, Etienne Wenger and I batted one about for a bit. Here is what we came up with. “Technology stewards are people with enough experience of the working s of a community to understand its technology needs, and enough experience with technology to take leadership in addressing those needs.

Although the whole technology for communities project comes out of our practice with specific communities, during gestation and birthing it’s easy to start worrying about how our thinking may have gotten far removed from actual practice. It’s easy to wonder, “maybe we’re just talking to each other… Maybe it’s a bunch of words that don’t have traction or actually refer to anything that’s real.” Fortunately, to keep ourselves going we’ve gotten some feedback from a friend or two along the lines of “this is great stuff” and “makes sense, but you’ve

Over the course of this project, I have been bookmarking sites via http://www.furl.net and http://del.icio.us - social bookmarking tools. I’ve did not develop too much tagging discipline until I was a ways into the project and have not cleaned up all my tags. Time is a cruel mistress. The tags I’ve been using include: techreport (http://del.icio.us/choconancy/techreport) technologyforcommunity (http://del.icio.us/choconancy/technologyforcommunity) communitiesofpractice (http://del.icio.us/choconancy/communitiesofpractice) communitytechnology (http://del.icio.us/choconancy/communitytechnology) If you come across some good sites, it would be great if you tagged them as well!

A couple people have asked this question, so here’’s a stab at an answer. Actually there are several parts to the answer.

We work like a community of practice. We decided we had to do this study because it was important to us, even if we had no funding and no clear business model when we started. Learning has been a sustaining “by-product” of the project all along. We each come at the technology and related issues from quite different perspectives, have a different network to draw upon, and actually contribute to the conversations in a different way. Having to work mostly at a distance on a project of this scope has pushed us to practice what we”re talking about.

We”ve reached out through our larger community of practice. In the early days of CPsquare, there were several conversations about updating Etienne’’s Tech Study; they were definite inspirations as we got going on this project. We have had access to each of the case studies that will be included in the final report because of the larger community of practice on communities of practice. Gaining access to someone’’s community and to their thinking about what’’s working and what isn”t requires that we have a pretty close relationship with our respondents, so we are fortunate that our community has provided the access we”ve needed. One implication of this somewhat informal approach is that we”ve had to be purposeful about finding as much variance as we can find within our larger community in terms of technology mix, community sponsorship, maturity, leadership, and style.

Seeking a community perspective in each story. The respondents who”ve told us stories about their communities are particularly interested in and sensitive to a range of community & technology issues that we think are very important. As we”ve developed the cases we”ve often interviewed people several times and in some cases interviewed several people from a community. A “community perspective” means both looking for common experience and for diversity in some kind of creative combination. Technologies for communities of practice have to work both for the “old hands” and the “new blood” in a community.

A middle-out perspective on learning, meaning and identity. This means that personal and psychological issues are adjacent to social or commercial issues around a community of practice. All the cases we present show communities that are generating new knowledge, shaping people’’s identity, and giving them a new kind of home that’’s partly based on distance technologies. Although all the cases we”ve looked at have their ups and downs (and are on some level quite fragile) they are all ongoing communities that transcend any one tool. And it turns out that the domain, practice, and community model that Etienne developed in his ”98 book is quite useful for making sense of what distributed communities of practice do.

Not just stories. This response probably emphasizes the cases in our study more than the other parts of it, because that’’s the part of it that we”re all working on at the moment. Describing what “a community perspective” means when it comes to looking at one tool, or describing features in general, or thinking about the future of technologies that are used by communities of practice would be a slightly different slant on the subject.