My topic is the collaboration practices of open source software development. OVERVIEW: Open source software has popularised the concept of free, open collaboration through the huge success of projects such as Linux, Apache, and Mozilla. This article from Wired Magazine explores how the concept of open source, propelled by the success of OSS projects, is being applied to all aspects of information compilation, from free scientific journals, to liberally-licensed gene-transfer technology, to freely-editable encyclopaedia Wikipedia. Although this article takes a somewhat liberal interpretation of 'open source', it does a good job of explaining the origins and future of the open source ethos. It also pinpoints two factors behind open source's success: the rise of the Internet, and general exasperation with stifling intellectual property laws. By concentrating on open source as "a broad body of collaborators ... whose every contribution builds on those before" (p. 1), this article successfully links the concept of open source with the broader theme of online collaboration. Open source software developments, along with other incarnations of open source such as Wikipedia, are prime examples of the power of online collaboration. Relying on the work of semi-anonymous participants and loose organisational mechanisms, open source projects create something of value without many of the restrictions of intellectual property. As exemplified in this article, all kinds of organisations can learn from the success of open source's collaborative online approach.

My topic is the collaboration practices of open source software development. You can access this article by logging into ACM via the Curtin Library website. OVERVIEW: Because the production of Open Source Software (OSS) relies heavily on the work of volunteers, the motivation of those volunteers is imperative to the success of any OSS development. Recognising this, this paper seeks to explain the motivations of those who work on OSS projects, using the learning theory of Legitimate Peripheral Participation (Lave & Wenger, 1991) as a guide. Building on this theory, the authors assert that the transient and open nature of an OSS development community appeals to user/developers as an environment to learn and hone their skills through 'legitimate participation'. Having identified the desire to learn as a key motivation for participants, the authors suggest that to attract more users to become OSS developers, leaders of OSS projects should create a list of progressively difficult tasks to foster the learning process and "enable newcomers to move toward the center of the community through continual contributions" (p. 9). Although this paper focuses on learning as a motivation, the authors acknowledge that because OSS is "a very complicated phenomenon" (p. 10), other motivations no doubt play a part. Informed by this and other articles, I would postulate that these other motivations include dissatisfaction with current software options (because "the best hacks start out as personal solutions to the author's everyday problems" (Raymond, 1999)), the desire for participants to gain reputation within the community, and the egoistic benefits of contributing to a program with a flatteringly large population of users. Raymond (1999) recognises the importance of satisfying the egos of "hacker/users" by providing them with a "piece of the action" (p. 29), while an internet-based survey (Hertel et al., 2003) has found that activities within OSS te

determined by participants' own "perceived indispensability and self-efficacy" (p. 1159). Overall, I believe that the community surrounding any given OSS-development is a key factor in the production of motivation, as it provides participants with the opportunity to gain reputation, satisfy one's own ego, and learn through legitimate participation in a project that the participants are personally interested in. References: Lave, J., & Wenger, E. (1991). Situated Learning: Legitimate Peripheral Participation. Cambridge: Cambridge University Press. Raymond, E. (1999). The Cathedral and the Bazaar. Knowledge, Technology & Policy, 12(3), p. 23-49. Hertel, G., Nieder, S., & Herrmann, S. (2003). Motivation of software developers in Open Source projects: an Internet-based survey of contributors to the Linux kernel. Research Policy 32(7), p. 1159-1177.

My topic is the collaboration practices of open source software development. OVERVIEW: This article compiles data taken from online OSS-management tool SourceForge, and provides an excellent overview of the features, advantages, and limitations of this particular tool. SourceForge (http://sourceforge.net/) is an online tool that facilitates collaboration on Open Source Software (OSS) projects. Among the most significant tools that SourceForge provides are forums discussing each project, a file-release tool, a basic task management system, the ability to post documentation (eg. instruction manuals) online, and the all-important Concurrent Versions System (CVS). This article goes into satisfying detail of how CVS works and why it is advantageous to software developers, explaining the CVS process as follows: 1. CVS holds the current version of a program's source code, and allows developers to 'check out' (i.e. download) this source code so that they have their own version to play around with. 2. Once done, developers can 'commit' (or upload) their changes. If possible, the CVS automatically merges this code with any other changes that have been made since the code was checked out. 3. The CVS system retains a copy of all previous versions of the code, and thus allows reversion to previous versions, as well as the existence of multiple 'branches' of the same source code. The main advantage of the CVS tool is that it "[allows] multiple developers to be working on the source code at the same time without conflict" (p. 6), although teams are may be limited slightly by SourceForge's basic task management system which "lacks capabilities for resource and personnel management" (p. 4). SourceForge is one online tool that greatly aids in the co-ordination of open-source projects. Any software developer considering the use of a pre-made online tool for collaboration would bene

Great points! In reading about OSS collaboration, I have found that as well as the benefit of being able to improve something for one's own use, participants are motivated by the learning opportunities and the opportunity to satisfy their own ego.

My topic is the collaboration practices of open source software development. You can access this article by logging into ACM via the Curtin Library website.

OVERVIEW: Open Source Software is software, built largely by volunteers, for which the source code is publicly available (p. 310). Such an approach is useful as a cheaper, high-quality alternative that can compete successfully with commercial products (p. 309, p. 343). This resource delves into the intricacies of Open Source Software (OSS) development by examining two prominent OSS projects: the web server Apache and the Mozilla web browser. In addition to providing detailed findings on the development processes that led to the early releases of both products, this comparative case study gives useful insight into the working practices and organisational structures of open-source developments, along with the tools that shape (and are shaped by) these working practices. As outlined in this paper, "decentralized workspaces" and "asynchronous communication" are very significant concepts in relation to OSS development (p. 317). Because there is no set schedule and contributors can do as much or as little as they like, constant communication through email and USENET groups is identified necessary to keep all contributors up to date. Other key tools used in the development of OSS are Concurrent Version Control Archive or CVS, which keeps track of each change made to the source code (comparable to wiki software); and bug-reporting databases, which enable the wider community to submit reports. The specialised nature of these tools suggests they are often purpose-built for the project, and the paper gives three examples from Mozilla - Bugzilla, Bonsai, and Tinderbox - which support this. In short, both through examining the control mechanisms, contributor involvement, and defect control practices; and through outlining specific tools that are invaluable in OSS development (and how they are used), this paper provides valuable insight into the nature of OSS development processes.