My previous post, which referred to Paul's Oracle of ERVIN, should perhaps also have pointed at Rolf Eike's criticism (and part 2) of the Oracle directly.

Dakon (that's Rolf Eike) points out that words tend to have some generally accepted meaning. So true, although there's various nuances and language is not static (ask Paul about the semantics of "dude"). Some meaning can be lost in electronic transmission where there's a no side-channel information available. (On that note, that's why conferences like Akademy and the Desktop Summit and developer sprints are so important: side-channel communication and a reduction of the barriers to communication).

The word Paul used was collaboration. Let's take a moment to think about what it means. dict:collaboration helps a little. One could put on a Latinist's cap and bells and futz with the word for a bit, but here's my personal sense of the word: It's about working together on some artifact. That's a short and simple definition, which is attractive.

So if you want to know if persons A and B collaborated on artifact X, just ask them: "did you work together on X?" And they'll say yes or no, right?

Well, no. That definition hides a lot of corner cases, which make the definition untenable if we want to analyse patterns of collaboration -- or even just in winnowing pairs of people to potential collaborators.

Let's start with a scenario where the answer is a clear "yes", then carry on into scenarios where things are less clear. I'll try to use names and interactions from KDE development as examples. In a later post I'll consider indicators and what they bring to bear on these scenarios.

  1. Paul and I sit in one room, chat about our definition of collaboration, and one of us types up a paper while the other does some literature checks and produces a biography. Several pints of Guinness and some take-out Peruvian later, we've got a nice article definiting indicators of collaboration. That's a clear yes, because: we worked on a shared artifact (the paper), there was explicit communication about it (chatting), there was a shared goal (production of the paper), the work together was con-temporal (at the same time or in a planned timespan).
  2. I start a paper about Eyeball numers, stick it in SVN, but never get around to finishing it. Sebas picks it up, modifies the text and ends up with a nice joint paper about collaboration through eyeballs. I'll call this a murky yes, because neither of us would have reached the end result without the other. There was neither contemporaneity nor communication, though.
  3. I wrote a plugin for Kate once (katemake, which ran make and parsed gcc output and set up bookmarks). Adrian L. is working on Kate Code Folding. Collaboration? No. Although there's a shared artifact, (we both worked on kate), there is no communication, no shared time, nor a shared goal beyond "improve kate".
  4. I worked on KPilot, which had translations. Rinse worked on the Dutch translation. Collaboration? No, for the lack of direct communication and because there's no shared artifact.
  5. But if I correct an error in the translation? I'm going to still say no, because there's no shared goal and no explicit communication.
  6. Albert fixes up some of my i18n (translation) code and tells both me and Rinse about the new strings that are going to show up in the code. Collaboration? Not between me and Albert, but you could argue that Albert and Rinse have a shared goal and shared artifacts even if Albert does not personally create the files with which Rinse works.
  7. I committed a weird-ass giflib check for Solaris to CMake some years ago. Now Alex asks me what it actually meant and fixes it up as he commits it upstream. I'll call this a murky yes. There's explicit communication, which induces a shared timespan as well. However, my actual work on the artifact falls way outside that period. Of course, Alex has also worked on the same artifacts, but not as part of collaboration.
  8. I change something in libferris so it compiles in Solaris; Ben changes it back so it compiles in Linux again and tells me I'm a doofus (a different kind of animal from the dangeroo). In spite of a shared artifact, communication, etc., I'd say no. Except if there's further communication.

I hope this illustrates some of the special circumstances that may surround the notion of collaboration. Each factor, such as communication, can indicate that there's collaboration going on, but there seem to be cases where the factors I've identified here are the same yet one is, and one isn't, an instance of collaboration.

This suggests that either the factors are incomplete, or that the definition of collaboration I'm using in my mind is just broken.

Now there's one factor I haven't mentioned here, which is intent. I can imagine that this is the most important and most intangible factor in Free Software communities where we're loosely organized. We think about collaboration when we intend to work together, and otherwise we're just .. working together in an uncoordinated fashion?

If I've missed some characteristic of collaboration in this description, please point it out in comments.

And to wrap up, the reason I'm harping on the meaning of collaboration and what characteristics it has, is because of the ALERT project. The models and definitions used by that project need validation, and they're going to need validation along the lines of this kind of description: does the model yield results that match our intuition and if not, what needs adjustment (it may be our intuition).