collective development in open-source communities

Andrea HemetsbergerUniversity of InnsbruckSchool ofManagement,Austria

Christian ReinhardtUniversity of InnsbruckSchool ofManagement,Austria

Collective Development in Open-SourceCommunities: An Activity TheoreticalPerspective on Successful Online CollaborationAndrea Hemetsberger and Christian Reinhardt

Abstract

Online collaboration is often organized without strong predetermined rules or centralauthority, which is why coordination and ways of organizing cooperation become crucialelements of collaboration. This article investigates how online projects can overcomeproblems of dispersed work, solve inherent contradictions and utilize tensions in theactivity system to develop collaborative artefacts and practices. Empirical evidence isbased on a detailed observation of a successful open-source project — the K DesktopEnvironment (KDE). Our findings show that successful collaboration is based on coat-tailing systems. Coat-tailing means to inextricably bind together individual action andcollective activity through careful design of complexes of technological, mental and cul-tural artefacts.

Keywords: activity theory, co-configurative work, online collaboration, open-source

The Internet has opened up new space for boundary-spanning collaboration andhas generated invaluable technological improvements for the coordination ofonline projects. Organizations have embraced these promising opportunitiesfor global collaboration with external partners, and for user integration in newproduct development. Victor and Boynton (1998) have coined the term ‘co-configurative work’ for these new, technology-enabled forms of 21st-century,post-bureaucratic, networked conglomerates, wherein organizations, users andother external actors share resources, and collaborate. Organization theory hasjust begun to explore the potential, the idiosyncrasies and the drawbacks of thesenew forms of online collaboration. In such online work groups, work is oftenorganized without strong predetermined rules or central authority, which is whycoordination and ways of organizing cooperation become crucial elements ofcollaboration. This article introduces the notion of ‘coat-tailing’ — a term usedto denote the parallel pursuit of individual and collective objectives — as a suc-cessful mechanism for online coordination and cooperation in co-configurative(Engeström 2004) online projects. Our central argument is that online coopera-tion is not just a matter of task coordination but rather a question of overcomingtensions that derive from the alignment of strategic activity and individual actionwithin a highly dispersed group. Coat-tailing means to inextricably bind togetherindividual action and collective activity through careful design of complexes oftechnological, mental and cultural artefacts.

http://oss.sagepub.com/

988 Organization Studies 30(09)

We develop our argument based on a case study of an open-source project —the K Desktop Environment (KDE) — that employs a complex activity systemfor coordination and cooperation. Free and open-source software (F/OSS)projects — such as KDE and Linux, for instance — have been portrayed as themost global and successful examples of user integration and online collaboration(Lee and Cole 2003; von Hippel and von Krogh 2003; von Krogh et al. 2003;von Krogh and von Hippel 2006). In thousands of F/OSS projects, programmerscollaborate online on a large-scale basis and produce software with unprece-dented speed (Cubranic and Booth 1999). Despite the difficulty of mediatedcommunication and work in a highly dispersed group, F/OSS projects mastercomplex group tasks without regular face-to-face contact (Barthelmess andAnderson 2002). Programmers with various levels of expertise and usersdevelop new software by sharing code and collaborating in a decentralized, self-directed and highly interactive process (Kogut and Metiu 2001; Raymond 1999).Despite the benefits to be gained through the integration of users in product

development, such volatile work organizations also face potential drawbacksthrough differences in cultural backgrounds and interests, and increasing com-plexity (Bechky 2003; Kellog et al. 2006), which cause conflicts, tensions andcoordination problems (Orlikowski 2002; Metiu 2006). Successful F/OSS pro-jects can teach us how to cope with these potential pitfalls.This article is intended to shed light on how co-configurative projects can

overcome problems of dispersed work, solve inherent contradictions and utilizetensions in the activity system to develop collaborative artefacts and practices.To this end, we draw on important theories of ‘collective activity’ in the contextof human-computer interaction, and introduce cultural-historical activity theoryas our theoretical framework. Based on the review of this literature and F/OSS-related research, we analyze the complex activity system of the KDE project indepth, and discuss the ways in which our findings contribute to activity theoryand online collaboration.

Human–Computer Interaction and Computer-MediatedCollaboration

Studies in human–computer interaction and computer-mediated collaboration ingeneral show increasing attention to what people do in practice. They are basedon the idea that both human beings and technology can only be understoodwithin a social context. Theories of distributed cognition, situated action, activ-ity theory and actor-network theory are prominent approaches for studyingactivity and action in context, be it situational, social, or in a network.The theory of distributed cognition moves cognitive psychology to the col-

lective level and adopts a system perspective on goal-oriented, coordinatedaction (Hutchins 1993, 1995). It has embraced the notion of embodied cogni-tion, arguing that material and social structures are elements of cognitive sys-tems as well. Humans are adaptive systems, continually producing a rich worldof cultural structures (Nardi 1996). Understanding this system means investigat-ing the coordination among the agents as well as the instruments they use inorder to reach their goal (Nardi 1996; Faraj and Sproull 2000).

by Giorgio Bertini on October 16, 2010oss.sagepub.comDownloaded from


Hemetsberger & Reinhardt: Collective Development in Open-Source Communities 989

In criticizing purely cognitive approaches, situated action models (Lave andWenger 1991; Suchman 1987; Hutchins 1995) put particular emphasis on theflux of ongoing activity and the situational, sometimes improvisatory characterof human action in particular environments. The emphasis is not on functionalaspects or representational states, but on the relationship between the individualand their environment, and how it emerges. This view of the emergent andimprovisatory character of human action is particularly powerful for investigat-ing new, less structured forms of networked organizations. While situated actionapproaches are well suited for in-depth investigation of small socio-technicalsystems and micro-processes of situated knowing, they leave out broader per-spectives of complex activity systems and how they account for successful col-laboration (Engeström 1993). Situated action theories emphasize what peopleare doing in practice, but tend to lose focus of what people want to achieve as acollective entity.Because of its focus on technology, actor-network theory (ANT) has become

a further prominent approach for research into computer-mediated collaboration.It proposes a dynamic view of interaction between society and technology (Latour1996). The idea of the flexible, ongoing action in ANT is particularly appealingwith regard to human agency in the Internet, where individuals immerse them-selves in another world (Turkle 1995) and the difference between human andtechnological actors becomes blurred. Yet its symmetrical view of humanand non-human action has also been criticized (Tuomi 2001); its emphasis onstructures and social practice being inscribed in technology de-emphasizes theextensive human agency on technology itself that happens in online communities(Orlikowski 2000). Structuralist approaches have rather emphasized the situateduse of technologies. When users interact with technologies they also decide howto interact with technology (Orlikowski 2000).Activity theory takes a similar approach in that it defines activity as the cen-

tral unit of analysis (Vygotsky 1978). Cultural-historical activity theory arguesthat social practice should be understood as tool-mediated activity (Leontiev1978, 1981; Cole 1999). This idea of mediation via tools is central to activitytheory (Kaptelinin 1996). At the primary level, tools include physical tools thatmediate people’s thoughts and behaviour. Conversely, people’s thoughts alsoshape technological artefacts and their usage. Vygotsky (1981) argued that men-tal tools are artificial formations and social by nature. They comprise language,mnemotic techniques, schemes, maps, drawings, signs, and other mental arte-facts. More recent conceptualizations of activity theory have moved to a collec-tive, artefact-mediated and object-oriented definition of the activity system(Engeström et al. 1997, 1999; Nardi 1996; Cole et al. 1997). Engeström intro-duced the community as the collective that is interested in an object, rules whichmediate the relationship between a community and the subject of an activity, anddivision of labour as the way the community is related to the object of the activ-ity. Objects are not to be confused with goals. While goals are intentional anddrive action, the object (the Gegenstand of the activity) is the purposefulintended target or idea that includes the collective motive for the activity.Activity theory suggests three interrelated levels of interaction — coordination,

cooperation and co-construction (Engeström et al. 1997; Bardram 1998).Coordination ensures that what people are doing independent of each other results




in the achievement of the common task (Engeström 1987). Cooperation concernshow coordination is achieved, and involves the social interaction of group memberswhen doing things together. Co-construction corresponds to the re-elaboration orre-construction of work practices and demands reflective communication on ameta-level (Engeström 1987). At this level, work itself is the subject of contem-plation (Barthelmess andAnderson 2002). By distinguishing these levels, activitytheory draws particular attention to these boundaries and how they are managedin work groups. In order to manage these boundaries, artefacts need to be estab-lished that serve as anchors between different levels. Anchoring is an importantconcept and focuses on the interconnectivity between mediational artefacts inorder to solve inherent contradictions of an activity system (Engeström 2006a,b).Activity systems need to link everyday activities upwards to the activity as awhole. Accordingly, the overall objective needs to be translated — anchoreddownwards— to the level of the concrete task (Engeström 2006a,b).Activity theory is an approach that explicitly focuses on the dialectical aspects

of the activity system. Research is directed towards contradictions within thesystem, and discourse as an important catalyst for change and the co-constructionof meaning (Wells 2002; Engeström and Blackler 2005). Through collectivereflection, cooperative processes become visible and give rise to awareness forthe need for improvement. Individuals develop a consciousness regarding theircollective actions, and thus are able to initiate change and alter collaboration. Byfocusing on contradictions in existing activity systems, activity theory is partic-ularly well-suited to identifying how complex and highly dispersed activity sys-tems cope with these contradictions and how they use them for improvement.

F/OSS Projects as Co-configurative Activity Systems

In an attempt to address new forms of collaboration, Engeström (2004) inte-grated the concept of co-configuration work into activity theory. Co-configurationis a participatory model that is not confined to collaboration between profes-sionals, and integrates users as active subjects. Users are active in the shapingand reshaping of products and eventually become experts themselves. F/OSSprojects are prototypical examples of co-configurative work, including profes-sionals, experts and users. Collaboration among people with such varying exper-tise necessitates a dynamic, dialogic relationship between multiple actors; it is arelationship characterized by collaborative and discursive construction of tasks(Engeström 2004). Such groups are radically different from conventional teamsor communities of practice (Lave and Wenger 1991; Nardi et al. 2000) in thatmembership at the periphery is fluid.In co-configuration work, participants are required to recognize and engage

with different goals of action and different expertise distributed across groupmembers. Work in F/OSS projects is voluntary; task assignment and decisionscannot be enforced (Demil and Lecocq 2006). Hence, conflicting goals of dif-ferent actors could impede the pursuit of the activity and the achievement of theobject. As a consequence, it is easy to lose sight of the overall objective in suchcomplex collaborative online projects (Blackler et al. 2000). Apart from theextraordinary ideological and motivational grounding of F/OSS projects




(Raymond 1999; Hertel et al. 2003; Zeitlyn 2003), researchers report of distinctbehavioural patterns, rules, norms and use of technology, which help coordinatedifferent goals and tasks (Lee and Cole 2003; von Krogh et al. 2003;Hemetsberger and Reinhardt 2006). Researchers describe F/OSS projects asevolutionary, open, flexible, and thus creative interaction systems (Tuomi 2001;Lanzara and Morner 2003; Kuk 2006).Actor-network based research has portrayed F/OSS projects as ‘technology-

based regimes’ (Lanzara and Morner 2005: 89). Lanzara and Morner (2005)argue that ‘technology can replace formal organizational rules and structures inthe coordination [....] of complex activity systems, by inscribing large compo-nents of collective human agency’ (Lanzara and Morner 2005: 67). The authorsmaintain that the artefacts programmers use can be seen as attractors that orga-nize activities in certain development areas and channel them towards certaindevelopment paths. Development is organized by technological artefacts, suchas concurrent versioning systems of the code base and mailing lists, but also bylicensing agreements. Lanzara and Morner (2005) and Hemetsberger andReinhardt (2006) emphasize the coordinating character of source code itself.They depict code as materialized form of knowledge and a playground for vari-ation and innovation. Mailing lists allow for communicative coordination in par-ticular ways; licensing agreements inscribe legal and contractual rules.Innovation evolves through variation, selection and stabilization (Lanzara andMorner 2005). Lee and Cole (2003) particularly focus on the role of criticismand peer reviewing as mechanisms through which innovations are continuouslycreated, selected and retained in F/OSS projects.F/OSS researchers have reported concordantly that openness of source code and

open communication in mailing lists is not only the ideology but also the rule, andis considered key to successful coordination. Parallel and overlapping activities arepossible without losing sight of the current version of their work (Yamauchi et al.2000; Kuk 2006). Furthermore, it enables incoming members to re-experiencehow code was built, as well as how contributors collaborate in terms of rules anddivision of labour (Tuomi 2001; Lanzara and Morner 2003, Hemetsberger andReinhardt 2006). Tasks are of modular character and are self-selected by contrib-utors according to their expertise and interests (Lanzara andMorner 2003; Lee andCole 2003). Although openness and modularity decreases complexity for the indi-vidual, it increases the complexity of the overall activity. Most researchers agreethat parallel software development, peer review, and user involvement combinedwith ‘openness’ are the most important ingredients of F/OSS collaboration (Fellerand Fitzgerald 2001). What has been left open is how F/OSS projects cope withthe tensions that the pursuit of individual goals and collective activity entail. Ourresearch aims to explore this question in order to gain important insights for thedesign of co-configurative work in highly dispersed groups.

Methodology

This case study is part of a bigger F/OSS research programme. We moved from afirst broad research question — how do members in F/OSS projects collaborateand integrate new members? — to a more detailed account of F/OSS projects as




complex, techno-cultural activity systems. Our research proceeded in severalphases. First, we selected a case that provided deep insight into the collaborationprocess. Secondly, data had to be gathered over a sufficient period of time in orderto achieve theoretical saturation (Goulding 2002). Thirdly, and in parallel withdata generation, we were constantly involved in writing memos, coding, dis-cussing emergent categories and interpretations, and analyzing data. Prior to theselection of an appropriate F/OSS community for investigation, we defined threerequirements. We looked for a successfully established project that had developedappropriate technology and communication structures. In accordance withCrowston et al. (2004), we used (1) the time of existence, (2) the number of mem-bers, and (3) the rate of innovation and diffusion, as indicators. After an extensiveexploration of other open-source projects and careful consideration, we ultimatelyselected the K Desktop Environment (KDE) project for our research purpose.KDE is a desktop environment for UNIX workstations, similar to those found

under MacOS or Microsoft Windows. The lack of a user-friendly contemporarydesktop environment has prevented UNIX from becoming a popular choiceamong typical computer users in homes and offices. In 1996, project founderMatthias Ettrich and a few programmers started a joint enterprise and producedthe first beta version only one year later. Today, KDE is available in its fourthgeneration. KDE is one of the largest F/OSS projects in the world. More than1000 developers around the globe are working and communicating via theInternet. To date, their collaboration has resulted in over four million lines ofcode. KDE is shipped with almost every Linux distribution.

Research Method and Analysis

We chose a grounded theory approach (Goulding 2002; Charmaz 2006) addingnon-participatory elements from Kozinets’s (2002) netnography. After havingchosen KDE, we asked the KDE project leader for permission to observe thecommunity and their communication. We closely monitored the project com-munity for a four-month period in order to gain a deep understanding of whatthey were doing. We observed the community regularly, two to three days aweek, looking atWebsites, tracking chats and scanning the mailing lists. In addi-tion, the research team familiarized itself with the KDE desktop environment inorder to understand the ‘work philosophy’ of its creators. We also includedexternal open-source affiliates in our discussions and attended F/OSS confer-ences in order to observe their culture and grasp their technical jargon.Making our theoretical perspective explicit and focusing on activity theoreti-

cal concepts, such as coordination, cooperation and co-constructive events,helped us concentrate on collective core activities and contradictions with indi-vidual actions that occur in F/OSS collaboration. We carefully avoided usingpreconceptions, for instance theoretical explanations, in analyzing the data(Charmaz 2006). After a first period of intense observation, the particular impor-tance of mailing lists for the pursuit of the core activities in the KDE projectbecame evident. More specifically, we focused on general development listswhich have the highest impact, and focus on the core activities of KDE. Weapplied the procedure of open, axial and selective coding as described byGoulding (2002). After initial coding we entered a focused phase of analysis. We




sampled relevant threads for further analysis and interpretation of the emergentcategories.As the subjects of the threads are mostly task-specific and thus not self-

explanatory, we selected relevant threads via key word search, and by scanningall threads. We analyzed 30 threads in depth, including 278 contributions from143 authors to the general developers mailing list, and 136 contributions from 46authors to the core developers mailing list posted in February and March 2003.The core developers mailing list is used for discussion about the development ofthe main developer tools and strategic activities, whereas the developer list isused for general discussions regarding KDE source code development. Weselected a time span which represents a period of ‘normal’ activity in the com-munity. Periods before a major release (major releases are releases with a changein the second digit as, for instance, the release of KDE 3.1) are mainly concernedwith bug fixing. Therefore, we chose a period after the release of KDE 3.1, butincluding the next KDE 3.1.1 service release.For the purpose of studying co-construction, we engaged in theoretical sam-

pling of instances of contradictions that led to changes of work tools. We addi-tionally analyzed 10 corresponding threads spanning fromAugust 2004 to October2004, including 360 postings on the core developers mailing list concerningKDE’s switch of version control systems (the most important tool for codebasemanagement). We sent four short email questionnaires to four core members,including two developers who initiated the change, and two who are responsiblefor the version control system. Their answers informed our data and interpretationwith motives for the initiation of this major change, with technical details, timingissues and explanation of rules. Once we had achieved theoretical saturation(Goulding 2002), we integrated the findings into a coherent theory. To test our the-ory, we asked for feedback from community members in a standard procedure ofethnographic research methodology called ‘member check’ (Kozinets 2002).

Findings

The KDE Activity System

From an activity theory perspective, the KDE project unfolds as an activity sys-tem with a clear object as formulated in their publicly announced manifesto (see:http://www.kde.org/whatiskde/kdemanifesto.php). The manifesto is not only anexpression of their ideology and will, but also important for the self-selection ofvolunteer contributors because it has the potential to reduce the number of differ-ent motivations in the group. By making the object of their work explicit, F/OSScommunities, although open to the public, restrict access and delineate their activ-ity system. In general, the most distinctive characteristic of F/OSS communitiesis that they are open to anyone willing and able to adhere to their objective. Userintegration is therefore a core activity and is strategically important. KDE’s mainactivity concerns the constant improvement and development of their product —the codebase, which mainly involves cooperation and coordination of individualcontributions. Development, in turn, needs innovation in terms of excellent ideasand excellent developer work tools. Innovation is KDE’s third core activity on acollective level of activity. Table 1 outlines our main findings.




Activities

Culturalartefacts

Technologicalartefacts

Mentalartefacts

Enabling

Newmemberintegration

Culturalentrée

Learningandadoptionof

programmingstyle

Continuousimprovement

Omnipresenceoftheobjectof

theactivity

Open(reading)accessto

communicationandsourcecode

Voluntaryassignmentandself-

selectionoftasks

Structuredcontent:

Blogs,Wiki,Faqs,

Websitecontent,documentation

Sequentialcontent:

Mailinglistsandarchives;online

tutorials

Bugdatabase,wishlists

Retrospectiveexperience

Directexperience

Productiveinquiry

Attractingnewmembers

andavoidingdistraction

Volunteeringandtask

prioritization

Collectivedevelopment

Concerteddevelopment

Mailinglistsas‘helpdesks’

Grantingwriteaccess

Codereuse

Peerreviewandfeedback

Bugdatabase,notificationemails

Versioncontrolsystem,modular

structure

Commits-list,mailfilters,diff

application

Mailinglistdiscourseandarchives

Productiveinquiryofcode

‘Tech-talk’aslanguage

artifact

Productiveredundancy

andrecycling

Openreflectionand

complexityreduction

Collectiveinnovation

Jointconceptualizationof

ideas

Co-constructingtheactivity

system

Consensusandvolunteering

Collectivereflectionand

decision-making

Thepowerofthedoer

Mailinglistdiscourseandarchives,IRC

channels

Rare,butstrategicallyimportantface-to-

facemeetings

Mentalexperimentation

Ideareviewing

Ideagenerationand

sharedunderstanding

Democracyand

meritocracy

Table1.

ActivitiesandArtefactsintheF/OSSActivitySystem

asEnablersofCollaboration



New Member Integration

The integration of expert users is at the core of co-configurative work and hasobvious advantages for F/OSS communities. First, user feedback is integratedinto innovative software solutions. Secondly, it increases opportunities byenlarging the workforce. However, for user integration to be successful, co-configurative workgroups have to cope with some inherent contradictions. Usersmust be made aware of the opportunities to contribute. Yet, users have differentexpertise with regard to usage, and programming. Hence, co-configurative workneeds educational facilities starting at different levels. While communities ofpractice apply an apprenticeship approach where mentor and apprentice workclosely together, F/OSS project members have to rely on remote training andinteractive help from more experienced programmers. However, attracting newmembers should not interfere with the primary task of programming. The goalof user integration, therefore, is to integrate aspirant members with differentexpertise, but to avoid distraction from pursuing core activities. Furthermore,F/OSS projects have to solve the tension between volunteer work and task pri-oritization. The KDE community tries to solve these contradictions throughdesigning the cultural entrée, providing learning opportunities at different levels,and integrating users in continuous improvement.

Cultural Entrée in an Open Community

Aspirant members’ first contact with the KDE community is usually establishedthrough the project’s online contents. These contents mediate contact with thecommunity in a very specific way. A clear mission statement, software down-loads, access to the source code and all mailing lists, and the developers’ sitesymbolize openness, free access, and provide an explicit invitation to participate.Via a ‘Getting involved’ link, users and aspirant developers are invited to visithttp://techbase.kde.org/ — the site which is dedicated exclusively to present andfuture KDE developers. A conglomeration of detailed descriptions and rulesallows the newcomer to become familiar with the community and its activities.For coordination, self-motivation is one of the most important principles of

the KDE development model. Hence, this is also expected from anyone whowants to get involved with the community. The following brief excerpt takenfrom the user mailing list is an example of that mentality:

Hello Everyone,

I am totally new to KDevelop, please let me know what it is, when I saw it for the firsttime I found it as if it is for developing new applications for KDE...

Please tell me how to start with KDevelop... if I want to develop some Applications likewhat we do with visual basic on Windows platform then what is the best (Let me knowwhether I can do something with QT Designer for Developing Applications to run onLinux...)…………….

Thanks & Regards

The reply reads as follows:Maybe you want to wait for Visual Basic for Linux? Perhaps it is available in about50 years. Since you are new to Linux I can give you the astonishing advice to read the





documents which come with your system or are available at http://www.kde.org/. I do notbelieve that someone here has the time to write the documentation especially for you....

...You can believe me that I do not expect this mail to help you, but I could not resist.

Sorry!

(retrieved from: kde-user 2001–08–15)

This discourse tells two important stories. First, KDE is an open, but also apolitical-ideological culture in its basic tenets. Individuals who are thinking interms of competitor work tools do not pass the cultural entrée. As the objectiveand typical working style of F/OSS projects is firmly based on its cultural val-ues, cultural discourse is particularly present in communication with newcom-ers. Second, the above excerpt gives clear and explicit advice as to wherenewcomers should look for their first contact with the community. The harshtone of the answer echoes the writer’s scorn for those who disregard the rules.Here the community seeks to avoid distraction. The technologies used are sim-ple: publicly observable sites, FAQs (frequently asked questions) and discourse.Nevertheless, there are still many cultural tensions with aspirant members. In

order to overcome the ‘newbie’ barrier, the community constantly creates newand simple tools for newcomers that are geared towards the proliferation of cul-ture and rules for collaboration. Since different newcomers invariably ask thesame questions, the information they need can be pre-structured. FAQs and theWiki site are collaboratively created over time and structured from the perspec-tive of the ‘information seeker’. Aspirant developers also benefit from discursiveevents, stored chronologically in mailing list archives; they are encouraged toobserve common practice and discourse before they become a member.Presenting discourse in a sequential order enables internalization of the culturalnorms of the group and their way of thinking. Open communication enablesnewcomers to re-experience community history — which brings aspirant mem-bers a step closer to contributing.

Learning and Adoption of Programming Style

KDE members know that, from the first moment on, participation must be intrin-sically rewarding in order to attract volunteer contributors. Similar to those activ-ities Csikszentmihalyi (1990) portrayed as autotelic, the community designs taskswhich can be mastered quickly and provide immediate feedback and gratifica-tion. The goal is to provide help for different levels of expertise and to offer dif-ferent opportunities to participate. KDE supports the first steps of integration byproviding tutorials on: http://techbase.kde.org/. In contrast to documentation,which only provides an abstract description of how things work, tutorials aremuch more oriented towards the activity of using work tools and coding itself.Once newcomers are familiar with the community’s technology and pro-

gramming style, they engage in small, simple tasks according to their level ofexpertise. Rules for first contributions are briefly described in the ‘How to helpKDE’ for potential contributors. The site includes important cultural corner-stones that foster individual motivation such as the freedom to choose and to dowhat is fun. F/OSS communities must work with the constant contradiction ofhaving a voluntary workforce while at the same time getting things done that




have to be done. Therefore, the community must find ways to encourage partic-ipation in activities that contribute to the common objective. Task prioritizationis partly fostered by discourse which conveys the message that contributorsshould bear the community’s overall objective in mind. Beyond that, the com-munity sincerely appreciates engagement in tasks that contribute to the commonobjective and give the authors credit for this on public contributors’ lists.Despite the myriad of information and the openness of discourse, newcomers

are continually asking where to start contributing. As a matter of fact, KDE hasconstantly struggled with giving the right advice to newcomers willing to con-tribute. This contradiction has triggered discourse and the introduction of dedi-cated mailing lists and websites (http://quality.kde.org/). Yet, quality.kde.orgdoes not convey the intended meaning, as reflected in the following Blog entry.

I think that the name ‘quality team’ was a historical mistake, though. While the intentionis to get new contributors to work on the quality of KDE as a whole by dealing withpolishing, small bugfixes, documentation &c., but the name is poorly chosen.

(retrieved from a member’s Blog: 2006–05–08)

Language artefacts have to be chosen carefully in order to deploy a self-selectionmechanism. Iterative fine-tuning of language artefacts is necessary to resolvethese contradictions. Hence, the community has started to call small tasks forbeginners, such as bug fixes, ‘Junior Jobs’.Initial contributions are further encouraged by propagating a pragmatic

approach of doing. It fosters, of course, learning by doing, but also prevents new-comers from doing ‘invisible’ work. Hence one of the core tenets of the KDEphilosophy reads as follows:

When making a suggestion, change ‘we should..’ to ‘I will..’; grandiose plans are uselessunless you are willing to put in the work.

(retrieved from: http://www.kde.org/whatiskde/devmodel.php)

As the Internet is a space where individuals are only visible through contributingcontent, doing means visibility and thus, progress. This particular meritocraticapproach is enabled by several work tools, including bug tracking technology.

Continuous Improvement

The specific way F/OSS projects handle bug fixing is reputed to be one of themain advantages of their development model (Kuk 2006). The primary advan-tage of the bug tracking system is that the detection of bugs and bug fixing aresplit among individuals with different expertise. Having a large group ofadvanced users testing the software helps in finding problems quickly. Thismakes the system exceptionally well-suited to fostering self-selection of highpriority tasks. This is also why the bug tracking system has not been changed butrather only slightly improved in its basic functionalities. The bug tracking sys-tem is the work tool that enables advanced users to report a bug or a missing fea-ture in a way that enables developers to fix it. User voting for the most hateddefect or the most desired feature further reflects the severity of the problem,which helps with the prioritization of tasks.Bug fixing is a delimited operation modularized from the overall codebase

and thus a good opportunity for new developers to contribute and improve their




programming skills. New members, however, are not allowed to commit a bugfix — in F/OSS jargon a ‘patch’ — directly into the source code repositorythemselves. The maintainer reviews bug fixes before integrating them into thecode or rejecting them. New members benefit from receiving comments onrejections, much like in academic reviewing. This results in the continualimprovement not only of code, but also of developers’ skills. Reviewing andfeedback are invaluable mechanisms which link individual action to the collec-tive activity.

> You might consider asking for SVN write access so you can commit these

> fixes yourself....

Well, I just wanted to see how well am I doing before getting an account:).

When I think I’m ready, I’ll to it. Perhaps, it is time:))).

Thanks, I’ll look into it.(retrieved from: kde-devel 2006–04–13)

Developers who have reached an acceptable level of competence are invited toask for write access to the source code repository so they can integrate patchesto the source code. Being granted write access entails strong social symbolism.It engenders pride on the side of the ambitious developer, expressed here by theuse of emoticons, as it marks the transition from a newcomer to an integratedmember of the KDE project. Hence, it is an important cultural means to fosterexcellence.

Collective Development

In their manifesto the KDE community commits itself to excellence. The out-come of their activity should be no less than the best desktop environment.Continuous improvement is one way the community tries to achieve this excel-lence. Peer reviewing and feedback contributes to this. KDE reuses peerreviewed code, because it prevents the community from reinventing the wheel.However, new ideas develop out of variation and continuous experimentation(Lanzara and Morner 2005). As a consequence, KDE set up technology andrules which enable both reuse and redundancy. This produces an enormousamount of code as well as discourse for collective reflection, which calls for thereduction of complexity. In the following, we describe how the communitysolves these contradictions.

Concerted Development

While user integration increases the knowledge base and helps to evaluate thebenefit of future software solutions, it also broadens the range of tasks andincreases complexity. Task complexity is especially problematic when a hugenumber of developers are involved (Brooks 1995). Modularization breaks thewhole source code down into manageable parts. Consequently, complexity forthe individual is low, as members can work on modularized tasks which fit theirexpertise. Furthermore, specific modules can be used for several applications.The rule of reuse adds to this by forcing contributors to actively search for




modules that are peer-reviewed and can be incorporated in a further piece ofwork. ‘Use available tools rather than re-inventing existing ones!’ is one of thecore tenets of the KDE philosophy. Modularity and reuse, combined, thus con-tribute to both an increase in variety and a reduction in complexity. As thisdynamism is at the core of KDE’s collaborative work, corresponding rules aresometimes fervently defended, and violations provoke unfriendly replies:

>>You saw that our library was not ready yet, so instead of helping

>> finish it, you wrote a new one from scratch?

> Yes, sorry, I wanted to have it working very fast. It took me a day to write

> it and it’s far from being perfect. And now I’m here, don’t I?

So you started a new one, which also is still imperfect.

Classical lose-lose situation.(retrieved from: kde-core-devel 2002–05–08)

In F/OSS projects, several developers work on the same application, sometimeseven on the same module. Concerted action through common artefacts (Bødker1997; Bardram 1998) is therefore crucial. The KDE project uses the version con-trol system SVN (Subversion). Continuous coordination systems (van der Hoeket al. 2004) avoid change collisions in the code base, therefore they are of utmostimportance for the coordination and development of KDE’s codebase. Versioncontrol systems help people see at a glance what others are doing and henceimprove visibility (van der Hoek et al. 2004). In order to make changes in sourcecode visible, SVN provides a very simple tool with the ‘diff’ function. The useof different colours enables developers to quickly scan the changes made in therepository. As with almost every other technology used in the community, itscomplexity-reducing functionality lies in its simplicity. Such work tools not onlycoordinate work and encourage reuse, they also foster productive redundancy.Reuse is only feasible for good, reviewed work; new ideas develop out of con-tinuous experimentation.

Mailing Lists as ‘Help Desks’ and Sources of Inquiry

Mailing lists and IRC channels provide platforms to solve problems and collec-tively think about action. Developers reflect on their work and evaluate simpleideas for implementation. KDE is exploiting the fact that mailing lists open theopportunity for self-selection, whereby help is provided by those developerswho think they are most likely to have a good answer. The communicative inter-actions that emerge can involve a variety of different contributors with differentexpertise. On the Internet it is not important to know who-knows-what (Faraj andSproull 2000); it is sufficient to know where to post or to search for. As theaddressee is the entire group of participants who are subscribed to a mailing list,helping behaviour in mailing lists is extensive.However, the fact that anybody can talk is both an advantage and a disadvan-

tage. Written communication encourages reflection before someone hits the sendbutton. Even so, core developers also admit that ‘social interaction on the mail-ing lists could be drastically improved’. Still, due to the fact that mailing lists arepowerful ‘help desks’, they have never been changed in their basic functionality.




However, the constant influx of new members and an increase in code and sub-projects has led to several refinements of the system. Mailing lists split fromtime to time into new, topic-specific mailing lists in order to keep the amount ofdiscourse on the lists within digestible limits. Furthermore, mailing list digestsreduce the overwhelming number of mails received.Developers can also search mailing list archives. Archived discourse with

experts constitutes an invaluable source for productive inquiry when developerslook for solutions to their coding problems. This search comprises the use of the-ories, concepts, rules of thumb, combinations of these, and other mental reflec-tions that mediate action. Content analysis revealed that developers primarilyuse source code, and error messages in particular, to express their problems.Another common way to express technical problems is to present solutionswhich have already been tried out, in order to make other developers understandthe problem. Code is the common language of the audience and is in itself aninvaluable mental artefact, because it reflects the mental models, abstractionsand theories-in-mind of its creators.

Collective Innovation

Together with the code repository, mailing lists build the project’s platform fortechnical help, but also for reflection, and idea generation. Collective reflectionshapes goals and produces collective ideas that go beyond individual thinking.These collectively produced ideas are the source of innovation. Yet, collectivereflection on new ideas demands shared understanding of the problem or issueinvolved, which is difficult to achieve online. The KDE community uses severalmental artefacts for joint conceptualization of future ideas. Beyond ideas forsoftware applications, KDE is also an innovator of development tools. We willreport on one momentous development to show how contradictions in the activ-ity system initiate co-construction.

Joint Conceptualization of Ideas

Reflecting on problems and conceptualizing new ideas are important creativeprocesses in the KDE community. Developers use the mailing lists to presenttheir ideas, for instance for a new application or feature, and ask others to com-ment on them. Such initial messages generate lively and productive conversa-tions, provoking comments, and comments on comments. Developers are awareof this functionality and actively exploit its potential. Content analysis showedthat developers use various mechanisms to overcome the drawbacks of physicaldistance, for instance recapitulating an idea or elaborating the idea in moredepth. They further support ideas, present different perspectives of the problem,point out flaws, insist on their views, disagree, and defend their own ideas in aconstant process of idea generation and reviewing.However, for joint conceptualizations, KDE developers use other mental

artefacts such as programming language (e.g. plain code; ‘what if, if then’arguments), analogies, and future usage scenarios for collective reflection. Onesimple variant is to use analogies. Similar to what Bechky (2003) described,developers ‘de-contextualize’ their idea from the technical background and put




their thoughts in a comprehensible, everyday context. Contrary to ‘tech-talk’, thelanguage here changes drastically in order to achieve a common understandingof a problem. Analogies have their drawbacks, for instance when the analogydoesn’t hold. Yet, used as a mental artefact, analogies are enablers of collectivereflection and evaluation of ideas. Another common method of supporting thepresentation of an idea is to describe future outcomes or usage scenarios andcollectively develop ideas in a way that describes a ‘virtual reality’, that is, playswith the future realization of the respective idea.

That’s basically the idea. …….The idea is to have several standard KDE-wide wallets,and then allow applications to create their own as well. For instance, there could be a ‘net-work passwords’ wallet, a form data wallet, and a ‘local passwords’ wallet to start. Thisway the user doesn’t need to unlock his passwords to get form data.

Another KDE developer adds his own understanding and develops the idea further:

This would be interesting, I would think that it would be a kde wallet manger which man-ages sub wallets. Any app which belongs to a wallet class would be shared. Apps withspecial concerns could then require a special class onto themselves. The manager wouldallow you to group classes under a single unlock function. So I could do email, fish andkdesu passwords all with one password. ……..

(retrieved from the kde-devel 2003–04–30)

The use of language as a mental artefact enables developers to collectively cre-ate innovative ideas. In the course of the reflection, contributors engage in con-tinuous mental experimentation with ideas. Discussants collectively work tocircumscribe their ideas, thus trying to achieve shared understanding and settinggoals for future action. These processes, of course, do not run smoothly.Analysis has shown that during discourse, ideas are constantly contested. In away, ideas are peer-reviewed. Idea reviewing differs from the peer review ofsource code as described by Lanzara and Morner (2003) because of its empha-sis on generating rather than selecting ideas. Using the reuse rule here would bedetrimental for idea generation. Instead, for innovative and co-constructivetasks, the community has put a focus on doing, which provides the ultimatefeedback — either it works, or it doesn’t!

Co-constructing the Activity System

Work tools are changed or developed when there is tension, be it a technologi-cal or a social problem, or when new opportunities arise (Bardram 1998).Discussions on the object of work are extremely rare; however, the growth of theKDE code- and developers’ base has led to tensions that derive from the usageof work tools, such as the version control system. KDE originally decided towork with the ‘Concurrent Versions System’ (CVS). Their switch from CVS toSVN was one of the most far-reaching changes in recent years. Restrictions inreorganizing and renaming parts of the source code without losing a file’s his-tory, for example, hindered developers from experimenting on more innovativesoftware concepts in parallel. This contradiction triggered discussions amongcore developers. Strategic changes like these are initiated by the core developersteam. Furthermore, decisions with such far-reaching consequences are first dis-cussed face-to-face.




A one-year discussion was held on the core developers mailing list in orderto retrieve opinions from everyone concerned and achieve a shared under-standing of the problems involved. The core developers list is the only listwhere participation is restricted to developers, but it is publicly accessible. Thisreduces the perils of an unmanageable amount of discourse and at the sametime enables all interested members to gain a shared understanding of the ongo-ing issues. Analysis of related threads showed that the decision-making processfollows a particular path. In a first step, all developers are invited to contributeto the discussion. Extensive information on SVN and other version control sys-tems was collected, evaluated and discussed. Developers considered not onlythe impact of the new system on their future work but also the consequences ofthe switch itself.The rules of decision making are consensus and ‘he who does the work

decides’. When mutual consent among KDE developers had become apparent,one of the core developers took over the lead and wrote a task list. This was fol-lowed by a call for active commitment. Task lists and commitments signal aswitch towards action. After decision-making, further discussion is unwanted:

> > Fortunately I can say, that subversion will open soon for performance and

> > acceptance testing and if that passes, we will migrate our CVS as fast as

> > possible (different thread!)

> Why? What are the current shortcomings of CVS that cannot be overcome in

> the future (moving modules?)?

This is AFAIR no longer any part of discussion to prevent the

move from CVS away to SVN. There’re pros and cons, as always.....(retrieved from: kde-core-devel 2005–02–14)

The community sets clear rules: democracy and meritocracy, not in a politicalsense, but as a rule as to how to do things. While democracy manifests itselfthrough open discussions, meritocracy is the way in which those who committhemselves to work are empowered. Although seemingly contradictory, bothentail important functions. As with the strategic decision, open discussionsincrease the knowledge-base and increase acceptance. After finalizing thedecision, further discussions distract from implementation, thus meritocracytakes over.

Discussion

It has been argued that the world of work is going through some major transfor-mations as global, decentralized, participatory, creative online organizations aretaking shape (Engeström 2006b). Our study was intended to enrich the increas-ing body of research in the field of online collaboration and co-configurativework. It contributes to the existing literature in two important ways. First, weaddress and extend the recent assertion in co-configurative work research thatthe overall objective and the goals of activities of the many and diverse actors




have to be ‘anchored’ in order to link coordination and cooperation in complexactivity systems. Second, our research contributes to our knowledge of how todesign online activity systems that are able to cope with the contradictions inher-ent in co-configurative work.Although limited to the case of F/OSS development, it has certainly helped

broaden our knowledge about participatory forms of online collaboration, inte-grating users and various other external partners. A central insight derived fromour findings is that online co-configurative work needs what we may call coat-tailing systems. Coat-tailing is used in different contexts, for instance it can beused to describe how to boost the success of action by connecting it to somethingwhich is already successful. In politics, coat-tailing describes the tendency for apopular political party leader to attract votes for other candidates of the sameparty. The success of cover versions (music that builds upon songs that havealready been popular) has also been explained with the coat-tail effect. In a sim-ilar vein, coat-tailing work systems tie everyday actions to the overall activity ofthe group and thus couple the achievement of individual tasks with the successof the project as a whole. Due to the fluid boundaries of co-configurative groups,and their dispersed character, coat-tailing is of critical importance. As variousactors are constantly contributing in parallel, activity systems have to bedesigned that weave the work of many into the web of activities. Coat-tailingsystems enable ‘doing just one thing together’. However, coat-tailing is not anautomatism. As depicted in Table 1, cultural, technological and mental artefactsneed to be carefully combined to create a coat-tailing system. This in turn sup-ports the main activities of an online group (far left column) by solving the majortensions within the activity system (far right column) that derive from differingindividual and collective goals.Coat-tailing extends the concept of anchoring as described by Engeström

(2004). Contrary to work environments where links between different levels ofactivities are established with particular single artefacts (Engeström 2006b), asfor instance working schedules, in dispersed groups such boundary objects areprone to avoidance (Sapsed and Salter 2004). Dispersed groups, rather, developwhat Kellog et al. (2006) have called a ‘trading zone’ by engaging in the prac-tices of displaying, representation and assembly of work through the use ofInternet technology. Our research supports this assertion. Coat-tailing meanscarefully aligning individual actions and collective activities by taking intoaccount the motivations of the single human actor. Work tools and rules aredesigned to match individual expectations and to enable individual activity,where the collective activity is achieved by ‘piggybacking’ on the fulfilment ofthe individual task. Coat-tailing is a subtle effect as individuals are not neces-sarily aware of it. The bug reporting tool, for instance, invites newcomers tocommit quick and easy self-selected contributions, while enabling prioritizationof tasks at the same time.Creating awareness and visibility is of central importance in online work groups

(van der Hoek et al. 2004; Kellog et al. 2006). Hence, coat-tailing systems needto be open, legible and visible. However, exactly because of these open and flexi-ble structures, online collaboration often suffers from complexity (Orlikowski2000). Therefore, coat-tailing systems are also restrictive and exclusive. First, as




technology’s mediating capacity is strongly dependent on users’ understandingof the properties and functionalities of a technology (Orlikowski 2000), coat-tailing systems need appropriate technology for different users. Second, restric-tions are also strongly conveyed in openly displayed discourse, content, rulesand licensing. Openness thus contributes to access restrictions. Contradictoryas it may sound, this is exactly the characteristic of coat-tailing systems: toembrace contradictions in order to solve them.This is why coat-tailing systems are not a stand-alone solution, nor should they

be thought of as merely technological artefacts. Our findings corroborate struc-turation theorists’ contention that technology alone would fail to result in suc-cessful collaboration without the hidden and overt cultural rules (Orlikowski2002). Technology and culture are closely interwoven to support the parallel pur-suit of the long-term, collective activity and short-term, individual tasks. In orderto resolve contradictions between individual action and the collective activity,combinations of artefacts are applied which flexibly adapt to different situations.Our findings support Engeström’s (2006a,b) proposition that co-configurativework tends to form integrated ‘toolkits’. As a coherent system they foster mentalprocesses and enable action. Coat-tailing systems are geared towards makingpeople do and think. While browsing through open content, newcomers, forinstance, may discover interesting tasks and engage in productive inquiry. Theseinsights also have some broader theoretical implications for the theories of situ-ated action in that they add important insights into how apprentices are enabledto observe practice and to productive inquiry in mediated environments.Our findings add yet another component to online collaboration which is

important for collaborative success in dispersed group work. Coat-tailing sys-tems foster and allow for the pursuit of individual goals and the strategic objec-tive. However, contrary to Engeström (2006a,b), who presents a hierarchicalview of either upwards or downwards ‘anchoring’, we found that online co-configurative systems are designed so as to enable both, and at the same time.Coat-tailing systems enable parallel processing and attainment of strategicobjectives and operative goals. User integration, for instance, takes place simul-taneously on the strategic level of cultural integration and on the operative levelof immediate task involvement. Furthermore, coat-tailing systems are geared tocope with tensions that arise from the pursuit of both. The tensions as well asthe solutions to the strategy–task conflict are inherent in coat-tailing systems.Yet, both are important; tensions are important triggers of change, while solu-tions enable coordinated work. Viewed from this perspective, coat-tailing sys-tems are also important change agents. They enable co-constructive processes ofpermanent fine tuning of workflow technology, mental artefacts and discursiverenegotiations of cultural artefacts.We conclude that, contrary to recent arguments of Lanzara and Morner

(2005), technological artefacts do not become holders, but rather vehicles or, aswe like to put it, enablers of human agency (Kuutti 1996; Orlikowski 2000). Ina similar vein, we departed from the view that structures and sequences ofhuman actions are inscribed in technology (Latour 1996). Although we share theview that technology plays a decisive role in online collaboration, we found thattechnology tends to follow the prescribed cultural rules and norms, rather than



Note

References Bardram, Jacob E.1998 ‘Collaboration, coordination, and

computer support: an activitytheoretical approach to the design ofcomputer supported cooperativework.’ PhD Thesis, Aarhus.

Barthelmess, Paolo, andKenneth M. Anderson2002 ‘A view of software development

environments based on activitytheory’. Computer SupportedCooperative Work 11/1–2: 13–37.

Bechky, Beth A.2003 ‘Sharing meaning across

occupational communities: Thetransformation of understanding ona production floor’. OrganizationScience 14/3: 312–330.

Blackler, Frank, Norman Crump, andSeonaidh McDonald2000 ‘Organization processes in complex

activity networks’. Organization7/2: 277–300.

Bødker, Susanne1997 ‘Computers in mediated human

activity’. Mind, Culture, and Activity4/3, 149–158.

Brooks, Fred P.1995 The mythical man-month: Essays on

software engineering. Reading:Addison-Wesley.

Chaiklin, Seth, and Jean Lave (eds)1993 Understanding practice: Perspectives

on activity and context. Cambridge:Cambridge University Press.

Charmaz, Kathy2006 Constructing grounded theory:

A practical guide through qualitativeanalysis. London: Sage.

Cole, Michael1999 ‘Cultural psychology: Some general

principles and a concrete example’in Perspectives on activity theory.Y. Engeström, R. Miettinen andR. L. Punamäki (eds), 87–106.Cambridge: Cambridge UniversityPress.

Cole, Michael, Yrjö Engeström, andOlga Vasquez (eds)1997 Mind, culture, and activity:

Seminal papers from the laboratoryof comparative human cognition.Cambridge: Cambridge UniversityPress.


the other way round, particularly so in an environment where technology isdeveloped by the collaborators themselves. By focusing attention on contradic-tions within an activity system as potential triggers of co-construction in workdesign, we also opted for a process perspective in order to overcome the short-comings of a purely static view. It is not technologically sophisticated workdesigns but the ability of groups to co-constructively react to tensions in activitysystems which contributes to sustainable online collaboration.Co-configurative work rests on informal relationships, liberal sharing of infor-

mation, meritocracy and openness to external members. Literature has portrayedthese particularities as paradoxical, as these organizations seem to act in acontradictory fashion (Kreiner and Schultz 1993). Yet, co-configurative activitysystems are actually only contradictory when viewed from a coordinativeperspective on the level of individual actions. Viewed from a cooperative per-spective, the paradoxical nature of contradictory human actions vanishes. Byembracing contradictions and weaving them into a coat-tailing system of tech-nological, cultural and mental artefacts, online collaboration can transgress thelimitations of the dispersed group work.

We owe an enormous debt of gratitude to all the KDE community members for their openness, help-fulness and insightful comments regarding our work. May their spirit continue to enlighten their ownlives and those of others. The authors are very grateful to the Senior Editor, Jacky Swan, and thethree anonymous reviewers for their insightful and helpful comments.




Crowston, Kevin, Hala Annabi, JamesHowison, and Chengetai Masango2004 ‘Towards a portfolio of FLOSS

project success measures’.ICSE Open Source Workshop.

Csikszentmihalyi, Mihalyi1990 Flow: The psychology of optimal

experience. NewYork: Harper Collins.

Cubranic, Davor, and Kellogg S. Booth1999 ‘Coordination in open-source

software development’. Proceedingsof the 7th IEEE InternationalWorkshops on Enabling Technologies:Infrastructure for CollaborativeEnterprises.

Demil, Benoît, and Xavier Lecocq2006 ‘Neither market nor hierarchy nor

network: The emergence of bazaargovernance’. Organization Studies27/10: 1447–1466.

Engeström, Yrjö1987 Learning by expanding: An activity

theoretical approach to developmentwork research. Helsinki: OrientaKonsultit.

Engeström, Yrjö1993 ‘Developmental studies of work as a

testbench of activity theory: The caseof primary care medical practice’ inUnderstanding practice: Perspectiveson activity and context. S. Chaiklinand J. Lave (eds), 64–103.Cambridge: Cambridge UniversityPress.

Engeström, Yrjö1999 ‘Innovative learning in work teams:

Analyzing cycles of knowledgecreation in practice’ in Perspectiveson activity theory. Y. Engeström,R. Miettinen and R. L. Punamäki(eds), 377–404. Cambridge:Cambridge University Press.

Engeström, Yrjö2004 ‘New forms of learning in co-

configuration work’. Journal ofWorkplace Learning 16/1&2: 11–21.

Engeström, Yrjö2006a ‘Activity theory and expansive design’

in Theories and practice ininteraction design. S. Bagnara andG. Crampton Smith (eds), 3–24.Mahwah, NJ: Lawrence Erlbaum.

Engeström, Yrjö2006b ‘From well-bounded ethnographies to

intervening in mycorrhizae activities’.Organization Studies 27/12:1783–1793.

Engeström, Yrjö, and Frank Blackler2005 ‘On the life of the object’.

Organization 12/3: 307–330.

Engeström, Yrjö, Katherine L. Brown,Carol Christopher, and Judith Gregory1997 ‘Coordination, cooperation, and

communication in the courts:Expansive transitions in legal work’ inMind, culture, and activity: Seminalpapers from the laboratory ofcomparative human cognition. M.Cole, Y. Engeström and O. Vasquez(eds), 369–385. Cambridge:Cambridge University Press.

Faraj, Samer A., and Lee S. Sproull2000 ‘Coordinating expertise in software

development teams’. ManagementScience 46/12: 1554–1568.

Feller, Joseph, and Brian Fitzgerald2001 Understanding open source

software development. London:Addison-Wesley.

Goulding, Christina2002 Grounded theory: A practical guide

for management, business and marketresearchers. London: Sage.

Hemetsberger, Andrea, andChristian Reinhardt2006 ‘Learning and knowledge-building

in open-source communities:A social-experiential perspective’.Management Learning37/2: 187–214.

Hertel, Guido, Sven Niedner, andStefanie Herrmann2003 ‘Motivation of software developers

in open source projects: An internet-based survey of contributors tothe Linux kernel’. Research Policy32/7: 1159–1177.

Hutchins, Edwin1993 ‘Learning to navigate’ in

Understanding practice: Perspectiveson activity and context. S. Chaiklinand J. Lave (eds), 35–63. Cambridge:Cambridge University Press.

Hutchins, Edwin1995 Cognition in the wild. Cambridge:

MIT Press.

Kaptelinin, Victor1996 ‘Computer-mediated activity:

Functional organs in social anddevelopmental contexts’ in Contextand consciousness: Activity theoryand human computer interaction.B.A. Nardi (ed.), 23–34. Cambridge:MIT Press.



Hemetsberger & Reinhardt Collective Development in Open-Source Communities 1007

Kellogg, Katherine C., Wanda J. Orlikowski,and JoAnne Yates2006 ‘Life in the trading zone: Structuring

coordination across boundaries inpostbureaucratic organizations’.Organization Science 17/1: 22–44.

Kogut, Bruce, and Anca Metiu2001 ‘Open-source software development

and distributed innovation’. OxfordReview of Economic Policy17/2: 248–264.

Kozinets, Robert V.2002 ‘The field behind the screen: Using

netnography for marketing researchin online communities’. Journal ofMarketing Research 39/2: 61–72.

Kreiner, Kristian, and Majken Schultz1993 ‘Informal collaboration in R & D:

The formation of networks acrossorganizations’. Organization Studies14/2:189–209.

Kuk, George2006 ‘Strategic interaction and knowledge

sharing in the KDE developer mailinglist’. Management Science52/7: 1031–1042.

Kuutti, Kari1996 ‘Activity theory as a potential

framework for human–computerinteraction research’ in Contextand consciousness: Activity theoryand human computer interaction.B.A. Nardi (ed.), 17–44. Cambridge:MIT Press.

Lanzara, Giovan F., and Michele Morner2003 ‘The knowledge ecology of open-

source software projects’. Paperpresented at the 19th EGOSColloquium (July), Copenhagen.

Lanzara, Giovan F., and Michele Morner2005 ‘Artefacts rule! How organizing

happens in open source softwareprojects’ in Actor network theory andorganizing. B. Czarniawska and T.Hernes (eds), 67–90. Copenhagen:Copenhagen Business School Press.

Latour, Bruno1996 ‘Social theory and the study of

computerized work sites’ inInformation technology and changesin organizational work. W. J.Orlikowski, G. Walsham, M. R. Jonesand J. I. DeGross (eds), 295–307.London: Chapman & Hall.

Lave, Jean, and Etienne C. Wenger1991 Situated learning: Legitimate

peripheral participation.

Cambridge: Cambridge UniversityPress.

Lee, Gwendolyn K., and Robert E. Cole2003 ‘From a firm-based to a community-

based model of knowledge creation:The case of the Linux kerneldevelopment. Organization Science14/6: 633–64.

Leontiev, Alexei N.1978 Activity, consciousness, and personality.

Englewood Cliffs, NJ: Prentice-Hall.

Leontiev, Alexei N.1981 ‘The problem of activity in

psychology’ in The concept of activityin Soviet psychology. J. Wertsch (ed.).Armonk, NY: Sharpe.

Metiu, Anca2006 ‘Owning the code: Status disclosure

in distributed groups’. OrganizationScience 17/4: 418–435.

Nardi, Bonnie A., (ed.)1996 Context and consciousness: Activity

theory and human computerinteraction. Cambridge: MIT Press.

Nardi, Bonnie A., Steve Whittaker, andHeinrich Schwarz2000 ‘It’s not what you know, it’s who you

know: Work in the information age’.First Monday 5/5 http://firstmonday.org/issues/issue5_5/nardi/index.html

Orlikowski, Wanda J.2000 ‘Using technology and constituting

structures: A practice lens forstudying technology in organizations’.Organization Science 11/4: 404–428.

Orlikowski, Wanda J.2002 ‘Knowing in practice: Enacting a

collective capability in distributedorganizing’. Organization Science13/3: 249–273.

Raymond, Eric S.1999 The cathedral and the bazaar: Musings

on Linux and open source by anaccidental revolutionary. Sebastopol,CA: O’Reilly and Associates.

Sapsed, Jonathan, and Ammon Salter2004 ‘Postcards from the edge: Local

communities, global programs andboundary objects’. OrganizationStudies 25/9: 1515–1534.

Suchman, Lucy1987 Plans and situated actions: The

problem of human–machinecommunication. Cambridge:Cambridge University Press.



Tuomi, Illka2001 ‘Internet, innovation, and open

source: Actors in the network’. FirstMonday 6/1 http://www. firstmonday.org/issues/issue6_1/ tuomi/index.html

Turkle, Sherry1995 Life on the screen: Identity in the age

of the internet. NewYork: Simon &Schuster.

van der Hoek, André, David Redmiles,Paul Dourish, Anita Roberto,Sarma Silva Filho, and Cleidson de Souza2004 ‘Continuous coordination: A new

paradigm for collaborative softwareengineering tools’ in Proceedings ofthe Workshop on WoDISEE Directionsin Software EngineeringEnvironments, 29–36.

Victor, Bart, and Andrew C. Boynton1998 Invented here: Maximizing your

organization’s internal growth andprofitability – A practical guide totransforming work. Boston: HarvardBusiness School Press.

von Hippel, Eric, and Georg von Krogh2003 ‘Open source software and the

‘private-collective’ innovation model:Issues for organization science’.Organization Science 14/2: 209–223.

von Krogh, Georg, and Eric von Hippel2006 ‘The promise of research on open

source software’. ManagementScience 52/7: 975–983.

von Krogh, Georg, Sebastian Spaeth, andKarim R. Lakhani2003 ‘Community, joining, and

specialization in open sourcesoftware innovation: A casestudy’. Research Policy 32/7:1217–1241.

Vygotsky, Lev S.1978 Mind in society. Cambridge, MA:

Harvard University Press.

Vygotsky, Lev S.1981 ‘The instrumental method in

psychology’ in The concept ofactivity in Soviet psychology. J.Wertsch (ed.), 134–143. Armonk,NY: Sharpe.

Wells, Gordon2002 ‘The role of dialogue in activity

theory’. Mind, Culture, and Activity9/1: 43–66.

Yamauchi, Yutaka, Makoto Yokozawa,Takeshi Shinohara, and Toru Ishida2000 ‘Collaboration with lean media:

How open-source softwaresucceeds’. Proceedings of the 2000ACM conference on ComputerSupported Cooperative Work,329–338.

Zeitlyn, David2003 ‘Gift economies in the development

of open source software:Anthropological reflections’.Research Policy 32/7: 1287–1291.


Andrea Hemetsberger is Associate Professor at University of Innsbruck School ofManagement, Austria. She holds a PhD in Marketing from the University of Innsbruck,and has visited Tilburg University in The Netherlands, the Schulich School of Business,Canada, and ESSEC Business School, and Université Paris-Dauphine, France. Herresearch interests revolve around free open-source software research, branding, consumerdevotion and creative consumers. She has published in the Journal of Business Research,Management Learning, Journal of Business-to-Business Marketing, Advances inConsumer Research and the Journal of Macromarketing.Address: Department of Strategic Management, Marketing and Tourism, University ofInnsbruck School of Management, Universitaetsstrasse 15, 6020 Innsbruck, Austria.Email: [email protected]

Christian Reinhardt is a PhD student at University of Innsbruck School of Management,Austria, and independent consultant in the area of (online) community-building and brandmanagement. His research focuses on online collaboration and knowledge creation in freeopen-source software communities. He has published in Management Learning, and haspresented his research in books and at various conferences.Address: University of Innsbruck School of Management, Universitaetsstrasse 15, 6020Innsbruck, Austria.Email: [email protected]

AndreaHemetsberger

ChristianReinhardt



collective development in open-source communities

Documents

online coordination

successful collaboration

online collaborationlee

online work groups

activity theory

collaboration andhas

online cooperation

successful opensource