Usage, Costs, and Benefits of Continuous Integration in Open-Source Projects

Continuous integration (CI) systems automate the compilation, building, and testing of software. Despite CI rising as a big success story in automated software engineering, it has received almost no attention from the research community. For example, how widely is CI used in practice, and what are some costs and benefits associated with CI? Without answering such questions, developers, tool builders, and researchers make decisions based on folklore instead of data. In this paper, we use three complementary methods to study in-depth the usage of CI in open-source projects. To understand what CI systems developers use, we analyzed 34,544 open-source projects from GitHub. To understand how developers use CI, we analyzed 1,529,291 builds from the most popular CI system. To understand why projects use or do not use CI, we surveyed 442 developers. With this data, we answered 14 questions related to the usage, cost, and benefits of CI. Among our results, we show evidence that supports the popular claim that CI helps projects release more often. We also discovered that 70% of the most popular projects from GitHub use CI, as well as finding that the overall percentage of projects using CI continues to grow, making it important and timely to focus more research on CI

Why Modern Open Source Projects Fail

Open source is experiencing a renaissance period, due to the appearance of modern platforms and workflows for developing and maintaining public code. As a result, developers are creating open source software at speeds never seen before. Consequently, these projects are also facing unprecedented mortality rates. To better understand the reasons for the failure of modern open source projects, this paper describes the results of a survey with the maintainers of 104 popular GitHub systems that have been deprecated. We provide a set of nine reasons for the failure of these open source projects. We also show that some maintenance practices -- specifically the adoption of contributing guidelines and continuous integration -- have an important association with a project failure or success. Finally, we discuss and reveal the principal strategies developers have tried to overcome the failure of the studied projects.Comment: Paper accepted at 25th International Symposium on the Foundations of Software Engineering (FSE), pages 1-11, 201

Towards guidelines for building a business case and gathering evidence of software reference architectures in industry

Background: Software reference architectures are becoming widely adopted by organizations that need to support the design and maintenance of software applications of a shared domain. For organizations that plan to adopt this architecture-centric approach, it becomes fundamental to know the return on investment and to understand how software reference architectures are designed, maintained, and used. Unfortunately, there is little evidence-based support to help organizations with these challenges. Methods: We have conducted action research in an industry-academia collaboration between the GESSI research group and everis, a multinational IT consulting firm based in Spain. Results: The results from such collaboration are being packaged in order to create guidelines that could be used in similar contexts as the one of everis. The main result of this paper is the construction of empirically-grounded guidelines that support organizations to decide on the adoption of software reference architectures and to gather evidence to improve RA-related practices. Conclusions: The created guidelines could be used by other organizations outside of our industry-academia collaboration. With this goal in mind, we describe the guidelines in detail for their use.Peer ReviewedPostprint (published version

Cultural transformation in construction partnering projects

In recent years there has been a growing interest in the use of partnering in construction. Since partnering is seen as changing behaviours and attitudes, cultural transformation cannot be forgotten in the process. Much of the literature tends to presume that cultural alignment is a prerequisite for partnering. Furthermore, the existing research fails to adequately address the complex relationship between individual or group behaviour and organisational culture which, nevertheless, lies at the heart of many prescriptions for improving collaboration within the industry. This paper initially reviews the major cultural and behavioural challenges and their root causes in construction partnering projects. Many commentators place considerable emphasis upon the importance of changing attitudes and cultural transformation to address various challenges in construction partnering. As the first step, this paper proposes a cultural web to understand organisational culture and to identify a substantial range of the elements which must be managed if a strategic and cultural change is to be successful

OSS integration issues and community support: an integrator perspective

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 ReviewedPostprint (author's final draft