Boundaries of Collaboration
Collaboration can be so strong that it generates hard boundaries. Boundaries can intentionally or unintentionally exclude the possibility to extend the collaboration. Potentially conflict can also occur at these borders.
For example, Book Sprints often develop strong and lasting collaborative relationships centered around the production and maintenance of a book. The intense social environment of a sprint can produce sharp borders around the collaboration. While Book Sprints produce texts that are available on an open license, and within a technical mechanism that allows for remote contributions, this does not in itself collapse the border between the sprint group and those ‘outside’ of the room.
Speed or Velocity. The supposed opposite to slowness. Interesting in relation to the (book) sprint, the experience of time, and the possible value we can attribute to interrupting the constant stream of data and information. Be slow. Different from progress which claims a “future” or some kind of “utopian dimension”, speed remains more abstract in the sense of not necessarily indicating a particular direction. Remember Paul Virilio on questions of speed in his book “Speed and Politics: An Essay on Dromology”, 1977 ; Dromology—‘Dromos’ from the Greek word to race (Virilio 1977:47). Meaning: the ‘science (or logic) of speed’. Read Hiroshi Yoshioka’s ‘The Slowness of Light’ <www.iamas.ac.jp/~yoshioka/SiCS/e-text/en_published_040331_slownessoflight.html> in relation to high-speed technology, where he suggests not opposing speed, but using it for different purposes.
In a recent Book Sprint for the “Google Summer of Code Mentoring Guide”, a group of very experienced Free Software developers (each were also experienced GSoC mentors) collaboratively wrote a book in two days. The collaboration was fluid and intense and generated a very useful text which has since been propagated throughout the GSoC community. Some weeks later a freelance technical editor with free time offered to copy edit the book but the group rejected the offer to collaborate. The reasons for this exclusion were complex, but discussion centered around the group feeling uncomfortable for reasons ranging from ‘not knowing’ the person, to issues about attribution, ownership and quality control.
Excluding potential collaborators in this scenario was intentional and considered by the group to be entirely appropriate. The group felt this was fully consistent with the ideals of Free/Open Content in that freely licensed content does not require compulsory collaboration, it has the potential to enable it, and the group felt that if others wanted to work on the text they were free to fork the text and create their own version.
While it is possible to discuss the groups decision about who they collaborate with, there are also consequences to this exclusivity that must be considered. In this case study it is interesting to note that since the rejection of the offer no work has been done on the ‘shared resource’, and hence the product has not been maintained. In other words, as a result of hard exclusionary boundaries all collaborative activity eventually ceased.