by Bryan Kirschner on May 20, 2007 07:53pm
I just read Bill and Sam’s “Business as Usual” post. It made me think about the fact Port 25 was established in part to apply the idea that “transparency increases trust” to the work we do with the lab. So I’m sitting down to do a blog entry that’s a bit longer than usual, but will provide transparency about why “business as usual” for me.
I previously blogged about a project we were starting to look at usability, human-computer interaction (HCI) and design rationale in open source development. I want to share how that came about and what I work on every day, over a period of about 12 months.
Part 1: Andrew Ko at Carnegie-Mellon (hi, Andrew) and folks from Microsoft Research (you rock, HIP) have done fascinating work on “Information Needs in Collocated Development Teams:” (emphasis added):
[In] a two-month field study of software developers at Microsoft. We took a broad look, observing 17 groups across the corporation, focusing on three specific questions:
What information do software developers’ seek?
Where do developers find this information?
What inhibits the acquisition of such information?
In our observations, we found several needs. The most difficult to satisfy were design questions: for example, developers needed to know the intent behind code already written and code yet to be written.
Code itself was a poor conductor—let’s call it bad currency, for reasons that will become apparent later—for transmission of design knowledge. From the MSR paper:
code did not look like design; intent could rarely be inferred from code; programming languages only allowed a single, structural perspective on code, yet there were many other perspectives on which developers reasoned about code
As a result, “the knowledge was primarily stored in the minds of developers. Consequently, developers relied on each other for design knowledge.” A common way to do this was face-to-face contact. Another way to do this was through email.
Part 2: Flore Barcellini (hi, Flore) is a research at INRIA (France) who has done a fascinating analysis of “Thematic Coherence and Quotation Practices in OSS Design-Oriented Online Discussions.” The implication is that traversing threads may be a lot more “lossy” than one might think because the “tree” you can build following transmission of knowledge using quotes can differ (from the abstract):
We show how quotation practices can be used to locate design relevant data in discussion archives. OSS developers use quotation as a mechanism to maintain the discursive context. To retrace the thematic coherence in the online discussions of a major OSS project, Python, we follow how messages are linked through quotation practices. We compare our quotation-based analysis with a more conventional analysis: a thread-based of the reply-to links between messages. The advantages of a quotation-based analysis over a thread-based analysis are outlined.
All but a few open source projects do not receive investment from vendors and do not have material revenue streams—for these “community-driven” projects, face-to-face contact would obviously be prohibitively expensive. So in reliance on code and email to transmit design knowledge, they would seem to be dependent on a lossy medium (code-as-currency) and a lossy mechanism (mail threads).
Part 3: David Nichols and Michael Twidale (hi, Michael) have done research identifying usability & HCI challenges in open source development, thoughtfully articulating some of the issues and possible ways to evolve distributed development.
Part 4: I was left with the impression this is a scenario that is really not good for community-driven OSS—and, by implication, for any resource-constrained distributed development process (something applicable to end-user developers collaborating online, and perhaps small ISVs, communities large in both number and importance to Microsoft’s business).
After reaching this conclusion I contacted the Codeplex team (meet the team) to talk about Microsoft taking a role in developing new functionality that might help this scenario. But first we needed to establish a research program to figure out whether this was a good path to go down, and what to do. That led to contact with Jack Carroll, Paula Bach, and the current project.
The first public session we held on this was a special interest group (Usability and Free / Libre / Open Source Software) at the recent CHI 2007 conference. Jack, Paula, and I moderated. I’ll let notes mostly from Paula sum up one aspect of a great discussion that gave me ideas I’d never thought of before:
About 40 people (1/3 to 1/ 2 of whom were involved in open source projects as contributors or researchers) attended the CHI Special Interest Group (SIG) on Usability and Free/Libre/Open Source Software (FLOSS). The group raised many issues including the “code as currency” issue. In essence, if “code is the only currency’ can there be a “benevolent HCI dictator?” The currency problem arises when HCI people who don’t write code work on FLOSS projects, potentially preventing the common mechanism of the “benevolent dictator” who can arbitrate conflicts over coding from emerging in the design and HCI domain. An interesting benevolent HCI dictator experiment would be to have HCI people design and initiate an open source project (it could even be a rapid prototyping tool that could be used as currency between FLOSS HCI people and developers) and have developers work on the project with an HCI person as the leader. This would be interesting in terms of social dynamics and to see who prevails as the benevolent dictator: would the HCI person remain or would a developer move into the leadership position once code writing began?
This is what we do every day. I hope this provides a bit of a view over time into our daily work to be center of excellence for (1) understanding and (2) finding opportunity with open source: ways for Microsoft and open source to “grow together.”