Share: a programming environment for loosely bound cooperation

A CHI paper on an environment social coding. Abstract:

We introduce a programming environment entitled Share that is designed to encourage loosely bound cooperation between individuals within communities of practice through the sharing of code. Loosely bound cooperation refers to the opportunity community members have to assist and share resources with one another while maintaining their autonomy and independent practice. We contrast this model with forms of collaboration that enable large numbers of distributed individuals to collaborate on large scale works where they are guided by a shared vision of what they are collectively trying to achieve. We hypothesize that providing fine-grained, publicly visible attribution of code sharing activity within a community can provide socially motivated encouragement for code sharing. We present an overview of the design of our tool and the objectives that guided its design and a discussion of a small-scale deployment of our prototype among members of a particular community of practice.

This paper focuses on the environment, but would like to see work on the role of community building in programming language design. We tend to design our languages without considering how to support a community of programmers rather than just one lone programmer using the language to instruct a computer.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Summary, interesting bits and discussion

To sum up (besides what the abstract says) :

- They built a program editor (client) that regularly send the current program to a central server for collection. The editor also allows browsing the central code repository and copying code from it; when copy-pasting inside the client, special attribution metadata is saved. The programmer can also manually insert metadata in a conventional structured way (a @saw tag in the comments). When visualizing the code repository, this code sharing relation is clearly and positively materialized.

- They targeted the Processing community which has a good history of "loosely bound cooperation", sharing code while working towards distinct programs/results/goals. They asked for volunteers in a controlled experiment and got 16 people to write code in their tool. Reports were rather positive (yes, it helps code sharing and we feel it helps).

¹: to motivate people to join, they offered two iPods and two Arduino kits, for only 16 volunteers. With those odds, i'll remember to participate more often!

Here are the interesting ideas I noticed in the article. I'm very ignorant of the more social subfields of computer science, so those idea will certainly be very well-known to others.

1. The idea of "loosely bound cooperation". No small insightful quote here, just read the "Background" part of the papers (half a page).

2. The notion of "work space" vs. "exhibition space":

Creating a good shared workspace vs. creating a good
exhibition space. The environment and its mores should
feel like a comfortable place for work in progress as
opposed to being a place just for finished work.

The "shame of our not-good-enough work" effect is known as a hindrance to open collaboration. The article discusses this several times. A "work space" is a place where you should be comfortable putting bad-looking, in-progress stuff.

Now for some more negative points:

- The questions given to the participants of the user-directed study seemed a bit oriented to me. For example, "The features provided by Share increased my ability (made it easier) to address the task". I would have expected something like "The features provided by Share {hindered, didn't had effect on, improved} my ability to address the task". Maybe it's standard in the field to formulate the question in a way that we hope people will answer "yes".

- The way code sharing is encouraged is by actually making it mandatory: the tool provided automatically shares code. This way, indeed users are not inhibited and have lower barriers for sharing code: sharing is an axiom of the system that can't be changed. It's efficient, and maybe that's the way to go, but I can't help thinking that it's also a bit simplistic and we should consider additional techniques to teach people to swim than just throw them in the water.

- I don't really believe in a whole-tool approach where some form of collaboration would be enforced by the use of a single tool to program. The only part of their tool which motivates changing the code editor is the feature that detects copy-paste and adds metadata automatically. The rest is about mining information from the code (including the programmer-added provenance metadata) and visualizing it. I would be interested in seeing future work aimed at producing this information/visualization without changing the programmer environment, possibly proposing or standardizing lightweight metadata (eg. structured-by-convention comments) to facilitate data mining. There are huge codebases out there, what are the attribution methods used in code source? Can we handle them automatically? Could we even spot inspiration (or at least correlation) without explicit mention by the programmers (copy-paste handling meet plagiarism detection techniques)? Interestingly, the authors seem fully aware of this wider question, as they say at the end of the article:

As far as we know there is no existing trackback like system for programmers who share code and we believe that our tool makes an argument (and suggests some techniques) for creating a set of online services and programming conventions that would make it easier to create trackback for programmer communities, even without a specialized tool like Share in communities where switching costs would be prohibitive.