The Web plays a critical role in hosting Web communities, their content and interactions. A prime example is the open source software (OSS) community, whose members, including software developers and users, interact almost exclusively over the Web, constantly generating, sharing and refining content in the form of software code through active interaction over the Web on code design and bug resolution processes. The Semantic Web is an envisaged extension of the current Web, in which content is given a welldefined meaning, through the specification of metadata and ontologies, increasing the utility of the content and enabling information from heterogeneous sources to be integrated. We developed a prototype Semantic Web system for OSS communities, Dhruv. Dhruv provides an enhanced semantic interface to bug resolution messages and recommends related software objects and artifacts. Dhruv uses an integrated model of the OpenACS community, the software, and the Web interactions, which is semi-automatically populated from the existing artifacts of the community.

Some free software projects have been extremely successful. This rise to prominence can be attributed to the high quality and suitability of the software. This quality and suitability is achieved through an elaborate peer-review process performed by a large community of users, who act as co-developers to identify and correct software defects and add features. Although this process is crucial to the success of free software projects, there is more to the free software development than the creation of a ‘bazaar’. In this paper we draw on existing free software projects to define a lifecycle model for free software. This paper then explores each phase of the lifecycle model and agrees that, while the bazaar phase attracts the most attention, it is the initial modular design that accommodates diverse interventions. Moreover, it is the period of transition from the initial group to the larger community based development that is crucial in determining whether a free software project will succeed or fail. 2

“Nightly/daily building and smoke testing ” have become widespread since they often reveal bugs early in the software development process. During these builds, software is compiled, linked, and (re)tested with the goal of validating its basic functionality. Although successful for conventional software, smoke tests are difficult to develop and automatically rerun for software that has a graphical user interface (GUI). In this paper, we describe a framework called DART (Daily Automated Regression Tester) that addresses the needs of frequent and automated re-testing of GUI software. The key to our success is automation: DART automates everything from structural GUI analysis, test case generation, test oracle creation, to code instrumentation, test execution, coverage evaluation, regeneration of test cases, and their re-execution. Together with the operating system’s task scheduler, DART can execute frequently with little input from the developer/tester to retest the GUI software. We provide results of experiments showing the time taken and memory required for GUI analysis, test case and test oracle generation, and test execution. We also empirically compare the relative costs of employing different levels of detail in the GUI test cases. 1.

It has been suggested that the superior quality of many Free Software projects in comparison to their proprietary counterparts is in part due to the Free Software community’s extensive source code peer-review process. While many argue that software is best developed by individuals or small teams, the process of debugging is highly parallizable. This “one and many ” model describes a template employed by many Free Software projects. However, reliance on a single developer or maintainer creates a single point of failure that raises a number of serious quality and reliability concerns – especially when considered in the context of the volunteer-based nature of most Free Software projects. This paper will investigate the nature of problems raised by this model within the Debian Project and will explore several possible strategies aimed at removing or deemphasizing the reliance on individual developers. 1.

Open source projects are typically organized in a distributed and decentralized manner. These factors strongly determine the processes followed and constrain the types of tools that can be utilized. This paper explores how distribution and decentralization have affected processes and tools in existing open source projects with the goals of summarizing the lessons learned and identifying opportunities for improving both. Issues considered include decision-making, accountability, communication, awareness, rationale, managing source code, testing, and release management.

Daily builds and smoke regression tests have become popular quality assurance mechanisms to detect defects early during software development and maintenance. In previous work, we addressed a major weakness of current smoke regression testing techniques, i.e., their lack of ability to automatically (re)test graphical user interface (GUI) event interactions – we presented a GUI smoke regression testing process called Daily Automated Regression Tester (DART). We have deployed DART and have found several interesting characteristics of GUI smoke tests that we empirically demonstrate in this paper. We also combine smoke tests with different types of test oracles and present guidelines for practitioners to help them generate and execute the most effective combinations of test-case length and test oracle complexity. Our experimental subjects consist of four GUI-based applications. We generate 5000-8000 smoke tests (enough to be run in one night) for each application. Our results show that (1) short GUI smoke tests with certain test oracles are effective at detecting a large number of faults, (2) there are classes of faults that our smoke test cannot detect, (3) short smoke tests execute a large percentage of code, and (4) the entire smoke testing process is feasible to do in terms of execution time and storage space. 1

Relying on volunteer labor, open source projects like the Apache web server create commercial quality software. Why developers contribute freely without direct remuneration has been widely debated. We offer empirical evidence that such participation can be explained by existing theories in labor economics. Analyzing panel data covering a four-year period, we find that increases in human capital, measured as project contribution, do not lead to increased wages. In contrast, credentials earned through a merit-based ranking system are associated with significantly increased wages. Our results suggest that status within an open source meritocracy operates as a credible signal of productive capacity. * We thank the open source programmers who have contributed to this study. We also thank the participants of the

This paper proposes and examines a model of the relationship between elements of product design and software quality in open source software (OSS) development projects. Research suggests that product design, or product architecture, affects work processes and outputs in the production of goods and services. In the case of software, we therefore hypothesize that product architecture affects characteristics of subsequent code contributions, which in turn affect product quality. An analysis of 203 software releases in 46 OSS projects hosted on SourceForge.net lends support for the hypothesized relationship between software modularity and software development, suggesting that the degree of software modularity is positively associated with the number of contribution opportunities and the number of code contributions, and negatively associated with contribution size. In addition, we find that software modularity is associated with reduced software complexity, one common measure of software quality. Surprisingly we find that software modularity is associated with an increased number of static software bugs and number of bugs reported, additional measures of software quality. However, opportunities to contribute mediates the relationship between degree of modularity and number of static bugs and bugs reported to yield the expected relationship between modularity and bugs. In addition to proposing and testing relationships between elements of software development and software quality, we introduce new measures of modularity and software quality. Implications are developed for the theory of modularity and the practice of software development.

Position Paper We propose to research the introduction of Software Engineering inventions into Open Source projects (1) to help researchers with creating opportunities for evaluating their tools, methods and process designs in real-life settings, and (2) to help Open Source projects with improving their processes based on state-of-the-art knowledge. Such research will go beyond diffusion and dissemination of inventions to active introduction, and thus increase the chances of adoption. We will discuss the research approach, our preliminary insights, limitations of the approach, and why researchers interested in evaluating their own inventions should be interested in this research.

“Software is largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry. ” — Eric S. Raymond [38] Open source software is not the end of the commercial software industry but it is clearly changing some areas of the industry’s landscape. In this paper we examine the open source development method as it exists in practice today from a technical and social context. We find similar licenses, leadership by meritocracy, and tool-based collaboration across eleven projects and three development portals surveyed. We propose a “walled server ” model to describe open source project information flow and control. We further examine the social context of open source communication and intragroup conflict. We describe five business models observed in today’s open source industry and evaluate when a business should choose to use open source methods over other approaches. We conclude by proposing four areas for future research: open source patronage, competition between open source and proprietary software, open source use as Off-The-Shelf (OTS) software, and transplanting the open source software development method. 1