Search

Developing systems by integrating Open Source Software (OSS) is increasingly gaining importance in the software industry. Although the literature claims that this approach highly impacts Requirements Engineering (RE) practices, there is a lack of empirical evidence to demonstrate this statement. To explore and understand problems and challenges of current system requirement–OSS component matching and mismatches resolution practices in software development projects that integrate one or more OSS components into their software products. Semi-structured in-depth interviews with 25 respondents that have performed RE activities in software development projects that integrate OSS components in 25 different software development companies in Spain, Norway, Sweden, and Denmark. The study uncovers 15 observations regarding system requirements-OSS components matching and mismatch resolution practices used in industrial projects that integrate OSS components. The assessed projects focused mainly on pre-release stages of software applications that integrate OSS components in an opportunistic way. The results also provide details of a set of previously unexplored scenarios when solving system requirement–OSS component mismatches; and clarify some challenges and related problems. For instance, although licensing issues and the potential changes in OSS components by their corresponding communities and/or changes in system requirements have been greatly discussed in the RE literature as problems for OSS component integration, they did not appear to be relevant in our assessed projects. Instead, practitioners highlighted the problem of getting suitable OSS component documentation/information., Peer Reviewed, Postprint (author's final draft)

This report constitutes a documents standard. It describes the major roles, processes, and documents necessary for designing, running, analyzing, synthesizing, recording and disseminating information from controlled experiments. (Other kinds of empirical studies, such as case studies, are not covered.) This description is the result of the authors' experience with replication of controlled experiments, and addresses what was learned about the needs of both the original experimenter and the replicator. To disseminate the information needed for an experimental replication, this document proposes a web-based and thus distributed Experience Library. The corresponding document standard has been designed to make relevant documents and empirical material into a "living" experience base. To this goal, this document describes pragmatic information structures to store, disseminate, comment upon, and update documents on designing and running experiments. We describe how special care must be taken to document otherwise unwritten goals, rationales, and assumptions behind experiments and thus to support more reasoned changes (adaptations and improvements) on replications. An accompanying set of Quality Assurance Rules regulates the evolution and use of this Experience Library. A main web portal is also described which ties together all local Experience Libraries, Document Standards, and Quality Assurance Rules. (Cross-referenced as UMIACS-TR-2201-24)

This report constitutes a documents standard. It describes the major roles, processes, and documents necessary for designing, running, analyzing, synthesizing, recording and disseminating information from controlled experiments. (Other kinds of empirical studies, such as case studies, are not covered.) This description is the result of the authors' experience with replication of controlled experiments, and addresses what was learned about the needs of both the original experimenter and the replicator. To disseminate the information needed for an experimental replication, this document proposes a web-based and thus distributed Experience Library. The corresponding document standard has been designed to make relevant documents and empirical material into a "living" experience base. To this goal, this document describes pragmatic information structures to store, disseminate, comment upon, and update documents on designing and running experiments. We describe how special care must be taken to document otherwise unwritten goals, rationales, and assumptions behind experiments and thus to support more reasoned changes (adaptations and improvements) on replications. An accompanying set of Quality Assurance Rules regulates the evolution and use of this Experience Library. A main web portal is also described which ties together all local Experience Libraries, Document Standards, and Quality Assurance Rules. (Cross-referenced as UMIACS-TR-2201-24)

This report constitutes a documents standard. It describes the major roles, processes, and documents necessary for designing, running, analyzing, synthesizing, recording and disseminating information from controlled experiments. (Other kinds of empirical studies, such as case studies, are not covered.) This description is the result of the authors' experience with replication of controlled experiments, and addresses what was learned about the needs of both the original experimenter and the replicator. To disseminate the information needed for an experimental replication, this document proposes a web-based and thus distributed Experience Library. The corresponding document standard has been designed to make relevant documents and empirical material into a "living" experience base. To this goal, this document describes pragmatic information structures to store, disseminate, comment upon, and update documents on designing and running experiments. We describe how special care must be taken to document otherwise unwritten goals, rationales, and assumptions behind experiments and thus to support more reasoned changes (adaptations and improvements) on replications. An accompanying set of Quality Assurance Rules regulates the evolution and use of this Experience Library. A main web portal is also described which ties together all local Experience Libraries, Document Standards, and Quality Assurance Rules. (Cross-referenced as UMIACS-TR-2201-24)

The success of Component-Based Software Development is based on the ability of an implementer team to select, assemble and integrate third-party and other components with own application software, in order to create a software system that satisfies (most of) the customer/clients stated needs in an economic and flexible way. Nowadays, the reuse of Open Source Software (OSS) components available from the Internet is playing a strategic role in the industry. This chapter aims at providing empirical evidence on current industrial OSS selection practices based on semi-structured interviews performed in 17 European organizations. In particular, the study tackles the following activities: 1) initial identification of available OSS components, 2) closer evaluation of the identified components, 3) conclusive decision-making of the chosen ones, and 4) updating of OSS-relevant experience and knowledge for the actual company. For simplicity we have omitted system-wide integration and testing activities. The results of this study ought to be valuable not just for researchers, as a sobering basis in their quest for practical selection methods; but also for practitioners that regularly drive OSS selection processes with potential to learn from other colleagues’ work., Peer Reviewed, Postprint (published version)

[Context and motivation] There is considerable flexibility in requirements specifications (both functional and non-functional), as well as in the features of available OSS components. This allows a collaborative matching and negotiation process between stakeholders such as: customers, software contractors and OSS communities, regarding desired requirements versus available and thus reusable OSS components. [Problem] However, inconclusive research exists on such cooperative processes. Not much empirical data exists supporting the conduction of such research based on observation of industrial OSS adoption projects. This paper investigates how functional and non-functional requirement mismatches are handled in practice. [Results] We found two common approaches to handle functional mismatches. The main resolution approach is to get the components changed by the development team, OSS community or commercial vendor. The other resolution approach is to influence requirements, often by postponing requirements. Overall, non-functional requirements are satisfactorily achieved by using OSS components. Last but not least, we found that the customer involvement could enhance functional mismatch resolution while OSS community involvement could improve non-functional mismatch resolution. [Contribution] Our data suggests that the selecting components should be done iteratively with close collaboration with stakeholders. Improvement in requirement mismatch resolution to requirements could be achieved by careful consideration of mismatches size, requirements flexibility and components quality., Peer Reviewed, Postprint (author's final draft)

The reuse and integration of Open Source Software (OSS) components provided by OSS communities is becoming an economical and strategic need for today’s organizations. The integration of OSS components provides many benefits, but also risks and challenges. One of the most important risks is the lack of effective and timely OSS community support for dealing with possible integration problems. For gaining an understanding of the common problems that organizations face when integrating OSS components, and the role played by OSS communities, we performed an exploratory study on 25 OSS integration projects from different European organizations. The results show that the main way of reducing integration problems was the use of OSS components from well-established communities; therefore very few integration problems were identified. In most of the cases these problems were successfully solved with the support from the OSS community and/or colleagues. In addition, contrary to the common belief that understanding code from someone else is a hard and undesirable task, some integrators consider OSS code even more understandable than their own code., Peer Reviewed, Postprint (author's final draft)

The success of software development using third party components highly depends on the ability to select a suitable component for the intended application. The evidence shows that there is limited knowledge about current industrial OTS selection practices. As a result, there is often a gap between theory and practice, and the proposed methods for supporting selection are rarely adopted in the industrial practice. This paper's goal is to investigate the actual industrial practice of component selection in order to provide an initial empirical basis that allows the reconciliation of research and industrial endeavors. The study consisted of semi-structured interviews with 23 employees from 20 different software-intensive companies that mostly develop web information system applications. It provides qualitative information that help to further understand these practices, and emphasize some aspects that have been overlooked by researchers. For instance, although the literature claims that component repositories are important for locating reusable components; these are hardly used in industrial practice. Instead, other resources that have not received considerable attention are used with this aim. Practices and potential market niches for software-intensive companies have been also identified. The results are valuable from both the research and the industrial perspectives as they provide a basis for formulating well-substantiated hypotheses and more effective improvement strategies., Peer Reviewed, Postprint (author's final draft)

Adopting OSS products is becoming an economical and strategic need for today organizations. A fundamental part of successful adoption is the informed selection of OSS products that best fit the organization needs. One of the main current problems hampering OSS selection is the vast amount of unstructured, incomplete, evolvable and widespread information about OSS products that highly increases the risks of taking a wrong decision as well as the likelihood to deter the use of an OSS product. In this paper, based on marketing research principles, we aim to inform and provide evidence to OSS communities that help them to envisage improvements on their information rendering strategies to satisfy industrial OSS selectors’ needs. Our results are from the matching between the informational needs of 23 OSS selectors from diverse software-intensive organizations, and the in-depth study of 9 OSS communities of different sizes and domains. The results evidenced specific areas of improvement. It is a first step to raise the awareness of OSS communities and researchers on areas that are required to improve the industrial OSS selection practice., Peer Reviewed, Postprint (author’s final draft)

Born as a movement of collective contribution of volunteer developers, Open source software (OSS) attracts an increasing involvement of commercial firms. Many OSS projects are composed of a mix group of firm- paid and volunteer developers, with different motivation, collaboration practices and working styles. As OSS is collaborative work in nature, it is important to know whether these differences have an impact on project outcomes. In this paper, we empirically investigate the firm-paid participation in resolving OSS evolution issues, the stakeholder collaboration and its impact on OSS issue resolution time. The results suggest that though a firm-paid developer resolves much more issues than a volunteer developer does, there is no difference in issue resolution time between firm-paid and volunteer developers. Besides, the more important factor that influences the issue resolution time comes from the collaboration among stakeholders rather than from measures of individual characteristics., Peer Reviewed, Postprint (author’s final draft)

Context: Open source software (OSS) is changing the way organizations develop, acquire, use, and commercialize software. Objective: This paper seeks to identify how organizations adopt OSS, classify the literature according to these ways of adopting OSS, and with a focus on software development evaluate the research on adoption of OSS in organizations. Method: Based on the systematic literature review method we reviewed publications from 24 journals and seven conference and workshop proceedings, published between 1998 and 2008. From a population of 24289 papers, we identified 112 papers that provide empirical evidence on how organizations actually adopt OSS. Results: We show that adopting OSS involves more than simply using OSS products. We moreover provide a classification framework consisting of six distinctly different ways in which organizations adopt OSS. This framework is used to illustrate some of the opportunities and challenges organizations meet when approaching OSS, to show that OSS can be adopted successfully in different ways, and to organize and review existing research. We find that existing research on OSS adoption does not sufficiently describe the context of the organizations studied, it is furthermore fragmented, and it fails to benefit fully from related research fields. To aid this situation, we offer directions for future research. Conclusion: The implications of our findings are twofold. On the one hand, practitioners should embrace the many opportunities OSS offers, but consciously evaluate the consequences of adopting it in their own context. They may use our framework and the success stories provided by the literature in their own evaluations. On the other hand, researchers should align their work, and perform more empirical research on topics that are important to organizations. Our framework may be used to position this research and to describe the context of the organization they are studying., Preprint

The reuse of Open Source Software components available on the Internet is playing a major role in the development of Component Based Software Systems. Nevertheless, the special nature of the OSS marketplace has taken the “classical” concept of software reuse based on centralized repositories to a completely different arena based on massive reuse over Internet. In this paper we provide an overview of the actual state of the OSS marketplace, and report preliminary findings about how companies interact with this marketplace to reuse OSS components. Such data was gathered from interviews in software companies in Spain and Norway. Based on these results we identify some challenges aimed to improve the industrial reuse of OSS components., Peer Reviewed, Postprint (author's final draft)

The use of Off-The-Shelf software components in Component- Based Development implies many challenges. One of them is the lack of available and well-suited data to support selection of suitable OTS components. This paper proposes a feasible and incremental way to federate and reuse the different efforts for finding, selecting, and maintaining OTS components in a structured way. This is done not only for supporting OTS components selection, but also to overcome reported problems with the integration and maintenance of component repositories. It is based on the “open source collaboration” idea to incrementally build an OTS components reuse infrastructure, enabling automatic support for OTS selection processes., Peer Reviewed, Postprint (author's final draft)