AbstractUser Collaboration in Open Source Softwareaws.iwi.uni-leipzig.de/em/fileadmin/user_upload/doc/Issues/Volume_… · well-structured project management web pages and easy-to-access

SPECIAL SECTION: OPEN SOURCE SOFTWARECo

pyrig

ht ©

200

4 El

ectr

onic

Mar

kets

Volu

me

14 (

2): 8

9–10

3. w

ww

.ele

ctro

nicm

arke

ts.o

rgDO

I: 10

.108

0/10

1967

8041

0001

6750

40A b s t r a c t

Open source development is labelled withfree source, fast evolution and extensive usercollaboration. Previous studies primarilytouched on user activities in a few well-known open source projects but lack theempirical data to represent important issuesfacing the open source development com-munity. This paper reports on a survey-basedstudy that investigated user collaboration inopen source development. Among the manyinteresting results, we found open sourceusers themselves to be very experienced soft-ware developers. They are highly motivatedto make their own contributions, workclosely with developers on various tasks,and use electronic communication toolsextensively. Users with different develop-ment experience and contributing to differ-ent category of projects tend to exhibitdifferent motivations and behaviours. Thesefindings confirm the differences betweentraditional and open source user collabora-tion and their implications for future opensource evolution and management are givenand discussed in this paper.

Keywords: collaborative software develop-ment, open source, user collaboration, survey

INTRODUCTION

With the successful delivery ofproducts such as Linux, Apache andSendmail, the open source develop-ment model has been attractingmore and more interests from bothpractitioners and researchers. Opensource is a simple means of releasingsoftware with source code, but onethat brings a series of new social andtechnical challenges including licens-ing, distributed development andproject management, commercialadoption and extensive user collabo-ration. Various research methodshave been adopted to investigate thephenomena of open source develop-ment, including general descriptivediscussion (Raymond 1999; Harsand Ou 2001; Cubranic and Booth1999; Augustin et al. 2002), casestudies (Mockus et al. 2002; Lakhaniand Hippel 2003), and surveys(Zhao and Elbaum 2003; Lakhaniand Hippel 2003; Hertel et al.2003).

With the classic statement ‘Givenenough eyeballs, all bugs areshallow’, (Raymond 1999) clearlyindicates the essence of open sourcedevelopment — user involvement.The concepts of user involvementand innovation are not new to opensource. (Hippel 2001) made anexcellent comparison of user com-munities in open source softwareand traditional manufacturing. Two

conditions, incentive to innovate andincentive to voluntarily reveal inno-vations, are said to be commonfor both communities favoring userinnovation. The difference is thatgenerally the diffusion of opensource innovations, unlike withphysical products, does not needmanufacturer support. Traditionalsoftware engineering disciplinesalready deem user involvement as keyto avoiding software project failure(Jiang et al. 2002) and key to success(Clavadetscher 1998). Many meth-ods and collaborative environmentswere proposed for better communi-cation and collaboration betweendevelopers and users (DeBellis andHaapala 1995; Keil and Carmel1995), though in open source userinvolvement carries different mean-ings. Compared to more controlledand limited user participation, opensource takes a more spontaneous,less organized, and in-depth form ofuser involvement. This type of userinvolvement usually exceeds whatusers are supposed to do in tradi-tional software development settingsand the boundary between usersand developers become blurred asopposed to developer — user linksin commercial settings (Keil andCarmel 1995). The reason is thatusers participate deeply in develop-ment tasks like finding bugs,suggesting new features, inspectingsource code, and submitting patches,

A u t h o r s

Luyin Zhao([email protected]) is a softwareresearcher at Philips Research USA anda part-time PhD student at the StateUniversity of New Jersey — Rutgers.His research interests include softwareengineering in open source, healthcaredecision support systems, anddistributed-object computingtechnologies.Fadi P. Deek([email protected]) is Associate Dean ofthe College of Computing Sciences,Director of the Information TechnologyProgram, and Professor of InformationSystems at New Jersey Institute ofTechnology. He is also a member of theGraduate Faculty — Rutgers UniversityPhD Program in Management.Dr Deek’s research interests includeLearning/Collaborative Systems,Software Engineering, ProgrammingEnvironments, and Computer ScienceEducation.

User Collaboration in Open Source SoftwareDevelopment

LUYIN ZHAO AND FADI P. DEEK

Downloaded By: [Schmelich, Volker] At: 20:01 23 March 2010

90 Luyin Zhao and Fadi P. Deek � User Collaboration in Open Source Software Development

yet taking less responsibilities than core developmentteams. This user group is also defined as ‘innovatinglead users’ in (Hippel 2001; DeFranco-Tommarelloand Deek 2002). From this perspective, the word ‘usercollaboration’ is more appropriate to reflect thissituation.

Collaborative software development is one of the mainapplication domains of groupware and group supportsystems. (Robillard and Robillard 2000) use a case studyto illustrate four types of collaborative tasks in softwareengineering. (Deek and McHugh 2003; DeFranco-Tommarello and Deek 2002) give a good summarizationof groupware technologies for collaborative softwaredevelopment. Core open source development teams aremore likely to adopt certain type of coordination mecha-nism (Wu and Lin 2001) and even groupware. Howeverwe have enough reasons to believe that for open sourcedevelopment, particularly the part of development activi-ties that get users involved, it is inappropriate to copy andpaste groupware and collaboration mechanisms designedfor traditional software development. For example, dueto the voluntarily nature and undefined team roles, thereis little chance to do synchronous collaborative tasksamong members and it is almost impossible to formallysplit and assign development tasks to individuals.Currently, open source collaborative development isachieved by taking advantage of lean electronic mediasuch as email, version control systems, and web pages(Yamauchi et al. 2000; Augustin et al. 2002) as opposedto rich media for group communication and develop-ment (Daft and Lengel 1986; Kuwana et al. 1996). Sofar, how well the current open source setting facilitatesuser collaboration remains unknown.

To address this problem, we first need empirical data asto how users perform and behave in this collaborativedevelopment environment. Although some researcharticles have explored user collaboration in certain typicaland well-known open source projects (Lakhani andHippel 2003; Mockus et al. 2002), in general there is alack of extensive and empirical studies as to how usercollaboration is taking place in a wider range of opensource projects. To this end, we conducted a survey studyto uncover the type of people that actively participate inopen source development as users, to learn about whatmotivates them, the type of tasks they do, how theycollaborate with development teams, the effectiveness ofsuch collaboration, and in what direction open sourcecollaborative environments should be improved andwhat this means to open source projects sponsored bycommercial vendors.

The next section introduces some related work ofstudying open source development using empirical data,followed by the survey methodology description. Wethen present the study’s major findings. The paper endswith a discussion on the implications of this study to thefuture evolution of open source development.

RELATED WORK

Recently, two empirical research methods, case study andsurvey, have been used by researchers to investigate thephenomena of open source development. In these stud-ies, the puzzle of people’s motivation to contribute to‘free’ software is one of the primary interests. Anotherdirection is more development-process oriented, with theobjectives of finding out unique development process(es)followed by open source projects and how they aredifferent from commercial software development.

Hars and Ou (2001) assume two types of motivationthat account for people’s participation in open sourceprojects — internal factors (intrinsic motivation, altruismand community identify) and external factors (futurerewards, including selling products, human capital, self-marketing, peer recognition and personal need). Theassumption was verified by a questionnaire survey tothe open source community with 81 responses. In asimilar survey-based study, (Lakhani and Wolf 2003)conclude that enjoyment-based intrinsic motivation, userneed, intellectual stimulation and programming skillsimprovement are among the major motivations.

Another survey-based case study on Apache webserver, (Lakhani and Hippel 2003), investigated how‘mundane but necessary’ tasks are done among opensource users and what motivated users doing so. UsingApache Usenet log data and 336 replies from a question-naire-based survey, the study revealed the pattern ofactivities in Apache help system. It shows that the user-to-user help system functions effectively, and mostnotably, 98% of the helping efforts provide directlearning benefits to the help providers themselves.

A recent work (Bonaccorsi and Rossi 2003) shiftsattention of motivations from the individual to firm,namely investigating why firms are motivated to invest inopen source and base their business models on opensource. Significant differences are reported to be foundbetween the motivations of individuals (primarily socialmotivations) and firms (primarily economical andtechnological motivations).

In two case studies of development in Apache andMozilla, Mockus et al. (2002) provide information aboutbasic parameters of the process that these two projectsemployed and the outcomes of these processes. Onehypothesis proved by both projects says that open sourcedevelopment usually have a core of developers whocontrol the code base and the number of this core doesnot exceed 10 to 15 people and they contribute to about80% of the total work. Another verified hypothesis statedthat in successful open source developments, a grouplarger by an order of magnitude than the core will repairdefects, and a yet larger group will report problems. Bothhypotheses support the motivation of our study — inves-tigating the characteristics and behaviours of the ‘larger’group of people outside of the core development team.

Using a similar method to that used in this paper,Zhao and Elbaum (2003), as a more mature study than


91Electronic Markets Vol. 14 No 2

(Zhao and Elbaum 2000), investigate the process andquality assurance activities conducted by core develop-ment teams. A questionnaire was administered to opensource core developers registered in freshmeat.net andsourceforge.net and 229 responses were used in dataanalysis. This study found that user participation wasextremely high, which is ‘generating up to 20% of thechanges for almost 50% of the projects, and discovering20–40% of the faults in 20% of the projects’.

SURVEY METHODOLOGY

Sampling in this research was done on a single opensource hosting website www.sourceforge.net for severalreasons. Primarily, this website has become the world’slargest open source hosting site with 64,231 registeredprojects and 651,088 registered users, as of 14 July2003. This number is much larger than any otherhosting site. Also, another reason is that sourceforge haswell-structured project management web pages andeasy-to-access user contact methods.

As already indicated, this research is concerned withusers who download and use open source software aswell as actively participate or contribute to the softwaredevelopment. Henceforth, we refer to this group ofactive users as ‘user’ or ‘users’.

To ensure receiving responses quickly and to avoidunreachable email addresses, we limited our survey torecently active users. Therefore, the sampling starts withthe top 200 active (as ranked by sourceforge) projects asof 10 July 2003. For each project, 12 users (12 was usedbecause it seems to be a reasonably large enough numberto include users that were active in the past few months)who have most recently posted at least one message,including submitting bug reports, suggesting newfeatures, or offering patches were selected. In selectingactual users, efforts were made to distribute users evenlyin the three activities, say four users for each activity.Moreover, in order to study user behaviours across differ-ent software categories, we attempted to distribute thenumber of projects evenly within seven categories asshown in Table 1, with the number of samples eventually

obtained. As a result, 73 projects were finally selected andothers were dropped because of various reasons such asinsufficient number of users and too many projects in thesame category. Because some projects fit in multiplecategories, the total number of users sampled is 846.Personalized emails were sent to the sample populationand 133 responses were received, yielding a respondrate of 15.7%, or on average 1.82 responses per project.We received insufficient responses for the category‘Games/entertainment’, so it is left out in the followingdata analysis.

USER CHARACTERIZATION

Group composition, referring to the membership charac-teristics or subject demographics of a group, is often thefirst step in investigating a collaborative environment(Deek and McHugh 2003). Group characteristics aretypically closely related to the effectiveness of the col-laborative environment. Compared with the traditionalsense of software development, with controlled usergroups of known characterization (Clavadetscher 1998),the open source community consists of a much moredynamic or ad-hoc user group. This is due to the fact thatparticipants are free to contribute and free to leave thecommunity. Therefore, sampling seems to be the mosteffective way to characterize open source user groups.Next, we classify users based on their years of develop-ment experience, motivation to contribute, and numberof projects.

First, it is important to note that in general nearly60% of the users have more than five years of softwaredevelopment experience, as shown in Figure 1. For usersbelonging to the core development team of an opensource project other than the one they contribute to asusers (referred to here as user group 1), the percentage isas high as 64%. Even with users who do not belong toany core development team (referred to here as usergroup 2), 41% of them have more than five years ofdevelopment experience. Comparing this to the findingin (Zhao and Elbaum 2003), 61% of core developershave more than five years of development experience, it isinteresting to note that the user profile is very close to thedeveloper profile in terms of development experience. Inother words, users who collaborate with developers arealmost as experienced as the developers themselves. Theuser profile varies from project categories (Figure 2). Themost obvious observation we can draw is that users of‘database’ projects tend to be least experienced users andusers of ‘software development’ projects seem to be mostexperienced in software development.

On average, 64% of users participate in open sourcedevelopment because of personal development needs, asshown in Figure 3. This percentage is very close to the60% of projects that were started also due to personalneeds (Zhao and Elbaum 2003). Roughly, this number

Table 1. Sampling distribution

Project category Number of users

Communications 151Database 106Games/entertainment 169Internet 183Multimedia 143Software development 174System 168



reflects the percentage of open source communitymembers that were motivated by personal needs. This isconsistent with (Hars and Ou 2001) and (Lakhani andWolf 2003). Also interesting to note is that about 32%of the people participate because of the needs of theiremployers. This proves the fact that besides a few well-known open source products, more and more opensource products are being adopted or sponsored byindustry and organizations. When comparing usergroups 1 and 2, it appears that group 2 users are

motivated more by employer needs while group 1 usersare more motivated in the other categories.

Another aspect we evaluated is whether users of differ-ent software categories tend to have different motivationsto contribute. Figure 4 does indicate big gaps amongdifferent categories. For example, in the category ofmultimedia software, 24% of users contribute because ofemployer needs, but as many as 49% users in the Internetcategory are motivated by employer needs. A similarsituation happens in the motivation ‘just for fun’.

Figure 1. Development experience

Figure 2. Development experience across categories

Figure 3. Motivation to contribute



Compared to users of communication software, users ofsoftware development are much less motivated by havingfun.

As to the issue of how many projects a user is associ-ated with, on average 40% of the respondents areinvolved in more than five projects, as shown in Figure 5.However, in general user group 1 is able to get involvedin more projects than user group 2, especially under thecategory of more than five projects. This is possibly dueto their higher level of experience and motivation, asillustrated by Figure 3.

COLLABORATIVE DEVELOPMENT

Unlike the practices of user collaboration in traditionalsoftware development, open source user collaborationcarries unique characteristics such as taking on extensivedevelopment tasks, forging closer user — developerrelationships and engaging in other active contributions.This section describes how users achieve suchcollaboration.

The majority of users inspect project websites fairlyfrequently — daily (29%) or weekly (52%). Comparedto findings in Zhao and Elbaum (2003), 43% of the

products are released every month and 29% every quar-ter, this indicates that users are able to receive updates ina timely manner even without release notifications fromcore development teams. This type of user activism orproject information pulling can also be seen in Figure 6,which shows 79% of users get project updates by them-selves. The next important source to get project updatesfrom is community discussion (34%). Only 28% of usersreceive updates from developers.

The study also classifies the type of tasks users partici-pate in and to what extent some of these tasks generatediscussions among community members. Figure 7 showsthe various types of tasks, sorted by percent of users. Thetop three ranked tasks are finding bugs, suggestingfeatures, and finding usability problems. This is followedby tasks relevant to source code, including source codereview and submission. Very few users offer administra-tive assistance to projects. Another interesting finding isthat for group 2, the percentage of people is higher thangroup 1 users only in the category of finding usabilityproblems. This finding suggests that a good mix ofparticipants (not only experienced developers) is key toperforming collaborative tasks evenly and to ensuringhigh quality.

Figure 4. Motivation across different categories

Figure 5. Number of projects involved



As is evident from Figure 8, some numbers vary acrossdifferent categories of software. The biggest variancesoccur in the category of ‘database’, in which a higher per-centage of users find usability problems and the categoryof ‘software development’, in which a higher percentageof users tend to review and inspect source code.

Comparing it with Figure 2, the phenomena again high-lights the importance of having a good mix of users withvarious development experience who can spontaneouslyand evenly distribute collaborative tasks. Overall, 64% ofthe respondents feel the collaboration is very effectiveand desirable.

Figure 6. Get project updates

Figure 7. User tasks

Figure 8. User tasks factoring software categories



USE OF COMMUNICATION MEDIA

When developers are geographically dispersed, theircommunication success may depend on utilizing effectiveand well-designed groupware (Nunamaker 1999; Deekand McHugh 2003) with achieving higher media rich-ness as one of the design objectives. Generally speakingthis is true. However, the open source developmentmodel somewhat defies this principal. High motivationplus extensive use of lean media such as email, discussionforum, version control tool, and trackers (for bug, patch,etc.) contribute to the success of such collaboration. Weaddress the usage of these tools below.

As shown in Figure 9, most of the users (81%) useonline forums to search for possible solutions to theirproblems. This is consistent with the findings of dis-cussion archive usage, in which 92% of respondentsindicated that they usually try to search for possiblesolutions in the archive before raising any question fordiscussion. This proves the fact that the online forum isbecoming the primary knowledge base and collectivegroup knowledge repository of the open source commu-nity. Another interesting finding is that group 2 userstend to show more interest in participating or solicitingforum discussions than group1 users.

As to the use of version control tool (CVS), it can beseen that 55% of users check out source code using CVSfor review or other purposes (Figure 10). Also, 27% use

CVS to submit their own code. Compared to the factthat 53% of users did submit source code (Figure 10), itcan be inferred that close to half of the users submitsource code through channels other than CVS. The mainreason is likely due to the discrepancy of submittingsource code using CVS between user group 1 (32%) andgroup 2 (18%). This fact might also imply that users,especially those of group 1, may not be familiar with CVSsystem or CVS is not adequate enough for them tosubmit source code.

As shown in Figure 11, email is still a major communi-cation tool for users to communicate with developers andreceive messages from mailing lists (Yamauchi 2000).Apparently, more emails are used to communicatewith developers than with other users. Also, receivingmessages from mailing lists is another primary use ofemail. Respondents rank these communication tools bytheir importance as follows: mailing lists, discussionforum, trackers, version control tool, and personal emails(Figure 12).

COLLABORATION OUTCOMES

The collaborative relationship between open sourcedevelopers and users is essentially a group problem-solving process, regardless of how people are dispersedgeographically, or what motivations and accountabilities

Figure 9. Online forum usage

Figure 10. CVS usage



they undertake, or even how lean the communicationmedia they use. Although it is too early to argue theappropriateness of lean communication media in accom-plishing collaborative tasks, we can identify clearly somecommunication barriers that researchers try to remove bygroup support systems (Desanctis and Gallupe 1985) inopen source user collaboration. For example, in Figures13 and 14, we can see that voting rarely takes place inprioritizing issues and resolving conflicts. Most oftendevelopers take exclusive responsibility for such decision-makings. About 55% of the respondents agree thattypically issues are prioritized based on developers’ pre-ference. Only 12% of the respondents feel prioritizationswere made by formal or informal voting. Thus, it is clearthat developers are playing a much more influential rolein handling issues raised by users. This type of group

communication may not be consistent with the underly-ing social protocol that open source projects should take.

Even though respondents (57%) are very positive thatdevelopers take timely actions on user contributions andsuggestions, the unbalance appears that developers aremore interested in fixing bugs and flawed featuresthan adding new features (37% against 16% as shown inFigure 15).

As to the benefits of contributing to open sourcedevelopment, apparently, the most popular use of opensource software is to integrate them as components (64%of respondents) and acquire knowledge from participat-ing in development (61% of respondents.) This resultvalidates Ye and Kishida’s (2003) theory: ‘[we] theorizethat learning is one of the motivational forces.’ It is alsointeresting to see that source codes are really reused quite

Figure 11. email usage

Figure 12. Ranking by importance

Figure 13. Issue prioritization



often as reported by the 52% of the respondents whoindicated that they reuse source code in their own soft-ware development (Figure 16). Again, the usage of opensource also varies across different software categories. Asshown in Figure 17, communication software gets thehighest usage rate than other categories, while multime-dia receives the least usage. Re-examining the motiva-tions across software categories in Figure 4, it shouldnot be a surprise since, in general, contributing to multi-media software is less motivated than other categories.

The study also aimed at finding the major collabora-tion difficulties among user group. Responses indicatethat language is still a major communication problemsince 24% of respondents choose the option of ‘hard toexplain problems electronically’. In addition, at least

six users pointed out difficulties of communicatingwith other people with different native languages. Thisproblem also occurs when source codes are commentedand/or documented by languages other than English.

DISCUSSION AND CONCLUSION

The earlier sections of the paper presented findings fromthe survey that gave quantitative evidence for under-standing user collaboration in open source development.In this section, we summarize and discuss implicationsthat can aid future developments of collaborativeenvironment and define relevant management strategiesfor the open source community.

Figure 14. Conflict resolution

Figure 15. Developer follow-up

Figure 16. Benefits



Experienced users

Open source users are already well recognized for theiractive participation in development. However, theiractual level of development experience and capability tocontribute to multiple projects is beyond our expecta-tion. The positive side of this fact is that the ‘virtual opensource development teams’ are actually having contribu-tors who are comparable to core developers in terms ofdevelopment experience. On the other hand, since thefindings also point out that users with less developmentexperience are willing to take more responsibilities incertain collaborative tasks, such as finding usability prob-lems, it is very important for the open source communityto pay attention to this type of user. This should includeoffering a better environment not only to open ‘sources’,but also ‘executables’ to them since without their inputs,a technically perfect software may not be acceptable byother users.

Communication support

As a distributed group problem-solving process, opensource still relies on lean media to achieve collaborativetasks. It is true that factors like incentive, experience andextensive lean media usage favor the success of such col-laborative development. Nonetheless, these factors donot completely remove some barriers of group problemsolving. For instance, a few core developers still playdominant roles in resolving conflict issues or prioritizingissues, which might not be necessarily desirable for theusers or even developers themselves. Although we canexpect to solve such problems using group supportsystems, the right approach is not to carelessly introduceany existing groupware or group support system intoopen source development. If the tasks do not fit thetechnology, the groupware system will not work effec-tively (Zigurs et al. 1999). As the first step of achievingsuch fitting, our survey has already provided useful infor-mation on tasks conducted in the user collaboration.

Knowledge base

Open source is becoming a knowledge base for people toacquire relevant information and skills. People participatein community discussions not only to inprove the soft-ware, but also to learn from participation. Unlike tradi-tional settings, this type of learning occurs across variousprojects as one user may participate in multiple softwaredevelopment projects. The open source developmentmodel truly opens up a completely new area of researchfor knowledge management and for the success ofknowledge management in terms of affecting users’enthusiasm and effectiveness of further contribution.Generally, the present public open source hosting sitesare still lacking good mechanisms specifically designedfor this kind of learning purposes, especially cross-projectlearning.

Language barrier

Due to the special nature of open source, collaboratingusers come from nearly every place around the world.The fact that computers could offer better communica-tion abilities, and what mechanisms to use, to solvelanguage and culture barriers is important as well.Computer-based communication system should be ableto, for example, facilitate a ‘user-to-user’ assistance bydelivering language translation help for users at anacceptable responding speed.

Commercial vendor support

Recently, a growing number of companies, such as SunMicrosystems, Apple and IBM, began to release theirsoftware as open source to take advantage of the enor-mous benefits of voluntarily user collaborative softwaredevelopment. (Glass 2003) points out that, consideringthe ‘with enough eyeballs, all bugs are shallow’ quote, if

Figure 17. Benefits by categories



not enough eyeballs are devoted to a software product,there is every reason to expect that such open-sourcesoftware may be less reliable than it should be. Therefore,the advantage of open source can be materialized only ifa sufficient number of users join the development. Oursurvey findings inform commercial vendors that prior toengaging in open source projects, it is useful to evaluaterelevant factors, such as learning opportunities andcategory of software to be developed, because it isreasonable to expect significantly different amount andtype of user contributions under different circumstances.

Overall, open source is no longer focused on the simpleidea of releasing source code, nor is it a concept ofgetting others involved in modifying one’s source code.The open source development model has become acomplex paradigm for gathering a large number of expe-rienced and sophisticated users to participate in softwaredevelopment together with core development teams.Our study provides succinct results for understanding theuser collaboration side of the open source developmentmodel. There is still much more to learn about thisparadigm and how to better support it, which is alreadyin our on-going and future research directions.

Finally, it is important to mention several factors maycause biases in the results of such studies. AlthoughSourceForge is the largest open source project host site,there are many others that should be included in a morecomprehensive survey. The response rate is always anissue in research studies. The relatively low response ratehere might be the consequence of two reasons: the com-plexity of the questionnaire and computer accessibility ofcasual open source users.

ACKNOWLEDGEMENT

The authors wish to thank all the open source users whotook the time to respond to our survey.

ReferencesAugustin, L., Bressler, D. and Smith, G. (2002) ‘Accelerating

Software Development Through Collaboration’,Proceedings of the 24th International Conference on SoftwareEngineering, 559–63.

Bonaccorsi, A. and Rossi, C. (2003) ‘Comparing Motivationsof Individual Programmers and Firms to Take Part in theOpen Source Movement. From Community to Business’,Sant’Anna School of Advanced Studies, Pisa, Italy, onlineat: http://opensource.mit.edu/papers/bonaccorsirossimotivationlong.pdf

Clavadetscher, C. (1998) ‘User Involvement: Key to Success’,IEEE Software 15(2): 30–2.

Cubranic, D. and Booth, K. S. (1999) ‘CoordinatingOpen-source Software Development’, Proceedings of

IEEE Eighth International Workshop on EnablingTechnologies: Infrastructure for Collaborative Enterprise,61–9.

Daft, R. L. and Lengel, R. H. (1986) ‘OrganizationalInformation Requirements, Media Richness and StructuralDesign’, Management Science 32(5): 554–71.

DeBellis, M. and Haapala, C. (1995) ‘User-Centric SoftwareEngineering’, IEEE Expert 10(1): 34–41.

Deek, F. P. and McHugh J. (2003) Computer-supportedCollaboration with Applications to Software Development,Kluwer Academic Publishers.

DeFranco-Tommarello, J. and Deek, F. P. (2002)‘Collaborative Software Development: A Discussion ofProblem Solving Models and Groupware Technologies’,Proceedings of the 35th Annual Hawaii InternationalConference on System Sciences, 523 –32.

Desanctis, G. and Gallupe, R. B. (1985) ‘A Foundationfor the Study of Group Decision Support Systems’,Management Science 33(5): 589–609.

Glass, R. L. (2003) Facts and Fallacies of SoftwareEngineering, 1st edn, Addison-Wesley.

Hars, A. and Ou, S. (2001) ‘Working for Free? — Motivationsof Participating in Open Source Projects’, Proceedings of the34th Annual Hawaii International Conference on SystemSciences, 2284–92.

Hertel, G., Niedner, S. and Herrmann, S. (2003) ‘Motivationof Software Developers in Open Source Projects: AnInternet-based Survey of Contributors to the LinuxKernel’, Research Policy 32(7): 1159–77.

Hippel, E. (2001) ‘Innovation by User Communities:Learning from Open-source Software’, MIT SloanManagement Review 42(4): 82–6.

Jiang, J. J., Klein, G., Chen, H. and Lin, L. (2002) ‘ReducingUser-related Risks During and Prior to SystemDevelopment’, International Journal of ProjectManagement 20(7): 507–15.

Keil, M. and Carmel, E. (1995) ‘Customer — DeveloperLinks in Software Development’, Communications of theACM 38(5): 33–44.

Kuwana E., Yana, E., Sakamoto, Y., Nakamura, Y. andHorikawa, K. (1996) ‘Computer-supported MeetingEnvironment for Collaborative Software Development’,Information and Software Technology 38(3): 221–8.

Lakhani, K. R. and Hippel, E. (2003) ‘How Open SourceSoftware Works: “Free” User-to-user Assistance’, ResearchPolicy 32(6): 923–43.

Lakhani, K. R. and Wolf, R. G. (2003) ‘Why Hackers DoWhat They Do: Understanding Motivation Effort inFree/Open Source Software Projects’, MIT Sloan School ofManagement Working Paper 4425–03.

Mockus, A., Fielding, R. T. and Herbsleb, J. D. (2002) ‘TwoCase Studies of Open Source Software Development:Apache and Mozilla’, ACM Transactions on SoftwareEngineering and Methodology 11(3): 309–46.

Nunamaker, J. (1999) ‘Collaborative Computing: The NextMillennium’, Computer 32(9): 66–71.

Raymond, E. S. (1999) ‘Linux and Open-SourceSuccess’, IEEE Software 16(1): 85–9.



Robillard, P. N. and Robillard, M. P. (2000) ‘Types ofCollaborative Work in Software Engineering’, Journal ofSystems and Software 53(3): 219–24.

Yamauchi, Y., Yokozawa, M., Shinohara, T. and Ishida,T. (2000) ‘Collaboration with Lean Media: HowOpen-Source Software Succeeds’, Proceedings of the ACMConference on Computer Supported Cooperative Work(CSCW), Philadelphia, PA, 329–38.

Ye, Y. and Kishida, K. (2003) ‘Toward an Understanding ofthe Motivation of Open Source Software Developers’,Proceedings of the 25th International Conference on SoftwareEngineering, 419–29.

Wu, M. W. and Lin, Y. D. (2001) ‘Open Source SoftwareDevelopment: An Overview’, Computer 34(6): 33–8.

Zhao, L. and Elbaum, S. (2003) ‘Software Quality Assuranceunder the Open Source Model’, Journal of Systems andSoftware 66(1): 65–75.

Zhao, L. and Elbaum, S. (2000) ‘A Survey on Quality RelatedActivities in Open Source’, ACM SIGSOFT SoftwareEngineering Notes 25(3): 54–7.

Zigurs, I., Buckland, B. K., Connolly, J. R. and Wilson,E. V. (1999) ‘A Test of Task-Technology Fit Theory forGroup Support Systems’, The DATABASE for Advances inInformation Systems 30(3/4): 34–50.



APPENDIX: QUESTIONNAIRE

Part I: About yourself

1. Your software development experienceA. NoneB. < 1 yearC. 1–5 yearsD. > 5 years

2. Are you a developer of any open source projects?A. YesB. No

(If yes, please answer remaining questions based on your contributions to other open source software of which you arenot a developer.)3. What is your motivation to participate and contribute to open source?

A. Just for funB. To meet personal development needsC. To meet employer needsD. To meet needs of my open source project(s)E. Other

4. How many projects are you involved in?A. 1B. 2C. 3D. 4E. 5 and up.

Part II. About collaboration

5. How often do you visit project web pages?A. DailyB. WeeklyC. MonthlyD. Other ( )

6. What do you do for the open source projects?A. Find bugsB. Find usability problems (e.g. ugly user interface, compiling, installation inconvenience)C. Suggest new featuresD. Review and inspect source codeE. Submit my own source codeF. Offer project administration assistanceG. DocumentationH. Other ( )

7. Please RANK (e.g. BCDEA) the following non-technical-support topics based on their popularity in online groupcommunications

A. Bugs discovered at run-timeB. Bugs discovered in source codeC. Usability problems (e.g. ugly user interface, compiling, installation inconvenience)D. Adding/removing featuresE. Other ( )

8. How do you keep yourself updated with project progress?A. I receive updates from development team periodicallyB. I check out project progress (e.g. new releases) by myself periodicallyC. I receive such information primarily from community discussionsD. I am not kept updatedE. Other ( )



9. How do you feel the effectiveness of solving open source problems as a group of both developers and users?A. Very effective and desirableB. Effective but not so obviousC. IneffectiveD. Not applicable

Part III. About electronic communication media

10. Do you use online forum toA. Solicit discussions to issues I raisedB. Discuss issues raised by other peopleC. Search for possible solutions to my problemD. Track development progressE. Other ( )F. I rarely use it

11. Do you search communication archives before raising or discussing any issues?A. I usually do and often find useful information thereB. I usually do but rarely find useful information thereC. I rarely doD. Not applicable

12. Do you use version control tools (e.g. CVS) toA. Track development progressB. Check out source code for review or other useC. Submit my codeD. Other ( )E. I rarely use it

13. Do you use structured trackers (e.g. Bug tracking, RFEs and Patch submission tools) toA. Track development progressB. Track stuff I submittedC. Give feedbacks on stuff other people submittedD. Other ( )E. I rarely use them

14. I use e-mail toA. Communicate with developersB. Communicate with other usersC. Receive messages from the Mailing listD. Other ( )E. I rarely use it

15. Please RANK (e.g. BCDEA) the following communication tools based on their importanceA. Discussion forumB. Mailing listsC. Version control tool (CVS)D. Structured trackers (e.g. Bug tracking, RFE, Patch submission tools)E. E-mail

Part IV. About collaboration outcomes

16. How issues raised by different people are prioritized for solutions?A. We vote for them formally or informallyB. It depends on developers’ preferencesC. It depends on how much discussion is received on a specific issueD. Other ( )

17. How conflicts on opinions (or submissions) are usually resolved?A. We vote for them formally or informallyB. Usually developers come to resolve conflicts



C. Usually experienced users come to resolve conflictsD. Conflicts are rarely resolvedE. Other ( )

18. How do you describe developers’ follow-up on user contributionsA. Developers often take actions on issues raised by users in a timely mannerB. Developers are more interested in adding suggested new featuresC. Developers are more interested in fixing bugs and other misfeaturesD. Developers are not responsive to user contributionsE. Other ( )

19. Please identify any of the following communication problems pertaining to youA. It is difficult to explain complicated software problems electronicallyB. I have problems communicating with developers because of background differenceC. I have problems communicating with other users because of background differenceD. The informal discussion style is very confusing and messyE. Other ( )F. Not applicable

20. If you are a software developer, how participating in open source community benefits your software developmentA. I reuse source code from open source projectsB. I integrate open source software to my system as component(s)C. I use open source software as a template to start building my systemD. I acquire relevant knowledge from community communicationsE. Other ( )F. Not applicable


Documents

AbstractUser Collaboration in Open Source Softwareaws.iwi.uni-leipzig.de/em/fileadmin/user_upload/doc/Issues/Volume_… · well-structured project management web pages and easy-to-access