This paper provides an excellent overview of the concept of a Community of Practice (CoP), a social network of professionals independent of any one company. According to the author, CoPs are useful in decreasing the learning curve of new employees, supporting faster responses to customer inquiries, and enhancing the generation of new ideas.

Like Kelly and Matthew, I found the author's concerns about conformity within CoPs to be of most interest. 'Information influence' and 'social cascades' occur when a highly-perceived individual's theory is widely supported because of the high perception of that individual, causing the contrary views of other individuals to go unheard.

Open source software development communities, which have been likened to CoPs (Ye & Kishida, 2003), exhibit this problem because of the division between 'core members' and other contributors. For example, a feature request on the KeePass SourceForge site, which was asked by a member of 7 years, received the reply of "Nice idea, thanks! I've now added an 'Export' button in the icon picker dialog" from a core developer (Tracker: Feature Requests, 2011). In contrast, a member of 6 days wanted to know why the source code repository for the project was not open to public view (a valid question, considering it's an open source project), but the reply from the afore-mentioned core developer simply stated that the code repository was "On my PC" (Source code..., 2011). This example demonstrates the vast difference between how the opinions and ideas of highly-perceived members and newer members are treated in Communities of Practice.

The author proposes that maintaining anonymity or providing incentives to debate during initial deliberation phases can help to overcome such problems. I think that mechanisms such as these might contribute to the promotion of a culture of openness, which would in turn address the wider social problem of inequality within CoPs.

References:
Ye, Y. & Kishida, K. (2003). Toward an Understanding of the Motivation of Open Source Software Developers. Proceedings of the 25th International Conference on Software Engineering. Accessed April 15, 2011, from http://portal.acm.org/citation.cfm?id=776867
Tracker: Feature Requests. (2011). Accessed April 17, 2011, from http://sourceforge.net/tracker/?func=detaila&aid=3256113&group_id=95013&atid=609911
Source code repository for KeePass?. (2011). Accessed April 17, 2011, from http://sourceforge.net/projects/keepass/forums/forum/329220/topic/4478457

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.