Hive is a distributed agents platform, a decentralized system for building applications by networking local system resources. This paper presents the architecture of Hive, concentrating on the idea of an "ecology of distributed agents" and its implementation in a practical Java based system. Hive provides ad-hoc agent interaction, ontologies of agent capabilities, mobile agents, and a graphical interface to the distributed system. We are applying Hive to the problems of networking "Things That Think," putting computation and communication in everyday places such as your shoes, your kitchen, or your own body. TTT shares the challenges and potentials of ubiquitous computing and embedded network applications. We have found that the flexibility of a distributed agents architecture is well suited for this application domain, enabling us to easily build applications and to reconfigure our systems on the fly. Hive enables us to make our environment and network more alive.

Open source development projects typically support an open bug repository to which both developers and users can report bugs. The reports that appear in this repository must be triaged to determine if the report is one which requires attention and if it is, which developer will be assigned the responsibility of resolving the report. Large open source developments are burdened by the rate at which new bug reports appear in the bug repository. In this paper, we present a semi-automated approach intended to ease one part of this process, the assignment of reports to a developer. Our approach applies a machine learning algorithm to the open bug repository to learn the kinds of reports each developer resolves. When a new report arrives, the classifier produced by the machine learning technique suggests a small number of developers suitable to resolve the report. With this approach, we have reached precision levels of 57 % and 64 % on the Eclipse and Firefox development projects respectively. We have also applied our approach to the gcc open source development with less positive results. We describe the conditions under which the approach is applicable and also report on the lessons we learned about applying machine learning to repositories used in open source development.

carl.gutwin, reagan.penner, kevin.schneider @ usask.ca Open-source software development projects are almost always collaborative and distributed. Despite the difficulties imposed by distance, these projects have managed to produce large, complex, and successful systems. However, there is still little known about how open-source teams manage their collaboration. In this paper we look at one aspect of this issue: how distributed developers maintain group awareness. We interviewed developers, read project communication, and looked at project artifacts from three successful open source projects. We found that distributed developers do need to maintain awareness of one another, and that they maintain both a general awareness of the entire team and more detailed knowledge of people that they plan to work with. Although there are several sources of information, this awareness is maintained primarily through text-based communication (mailing lists and chat systems). These textual channels have several characteristics that help to support the maintenance of awareness, as long as developers are committed to reading the lists and to making their project communication public.

Abstract not found

Effective information quality analysis needs powerful yet easy ways to obtain metrics. The English version of Wikipedia provides an extremely interesting yet challenging case for the study of Information Quality dynamics at both macro and micro levels. We propose seven IQ metrics which can be evaluated automatically and test the set on a representative sample of Wikipedia content. The methodology of the metrics construction and the results of tests, along with a number of statistical characterizations of Wikipedia articles, their content construction, process metadata and social context are reported. 1.

Information systems success is one of the most widely used dependent variables in information systems research. In this paper, we identify a range of measures that can be used to assess the success of open source software (OSS) projects. We identify measures based on a review of the literature, a consideration of the OSS development process and an analysis of the opinions of OSS developers. For each measure, we provide examples of how they might be used in a study of OSS development.

This article explores the design perspective's

This paper analyses open source software development as an epistemic community. Open source software develpoment is a learning process where the involved parties contribute to, and learn from the community. It is discovered that theory of epistemic communities does indeed contribute to the understandig of open source software development. But the important learning process of open source development only explained by the introduction of situated learning and legitimate peripheral participation as a theoretical prerspective. This allows the learning process to be part of the activities in the epistemic community. The combination of situated learning and epistemic community is shown to be fruitful and capable of explaining some of the empirical observations. In particular the combination of theories can shed light on the motivational issues and group dynamics.

Some members of the open-source and free software community argue that their code is more secure, because vulnerabilities are easier for users to find and fix. Meanwhile the proprietary vendor community maintains that access to source code rather makes things easier for the attackers. In this paper, I argue that this is the wrong way to approach the interaction between security and the openness of design. I show first that under quite reasonable assumptions the security assurance problem scales in such a way that making it either easier, or harder, to find attacks, will help attackers and defendants equally. This model may help us focus on and understand those cases where some asymmetry is introduced. However, there...

Windowing Toolkit (AWT). 7 Planchette Motion Model Figure 4: Planchette Coordinates. As described above, Applet C at each client sends a desired motion vector to Server C every 3 seconds. At the client, the user's mouse position is read by a local java applet and a "virtual" planchette is displayed in the lower window as it tracks the user's mouse. To make the interface more realistic, planchette motion is based on an inertial model. We treat the vector from the center of the planchette screen to the current mouse position as a force command. Consider the coordinate frame defined in Figure 4. User i specifies desired acceleration #a ix ;a iy #. We model frictional drag on the planchette with a constant magnitude and a direction opposite the current velocity of the planchette. If the current velocity of the planchette is v 0 = #v 0x ;v 0y # and the magnitude of the constant frictional acceleration is a f then afx = a f ,v0x p v 2 0x +v 2 0y ,and afy = a f ,v0y p v 2 0x +v ...