Improving Open Source Software Maintenance

Maintenance is inevitable for almost any software. Software maintenance is required to fix bugs, to add new features, to improve performance, and/or to adapt to a changed environment. In this article, we examine change in cognitive complexity and its impacts on maintenance in the context of open source software (OSS). Relationships of the change in cognitive complexity with the change in the number of reported bugs, time taken to fix the bugs, and contributions from new developers are examined and are all found to be statistically significant. In addition, several control variables, such as software size, age, development status, and programmer skills are included in the analyses. The results have strong implications for OSS project administrators; they must continually measure software complexity and be actively involved in managing it in order to have successful and sustainable OSS products

The Co-Evolution of Test Maintenance and Code Maintenance through the lens of Fine-Grained Semantic Changes

Automatic testing is a widely adopted technique for improving software quality. Software developers add, remove and update test methods and test classes as part of the software development process as well as during the evolution phase, following the initial release. In this work we conduct a large scale study of 61 popular open source projects and report the relationships we have established between test maintenance, production code maintenance, and semantic changes (e.g, statement added, method removed, etc.). performed in developers' commits. We build predictive models, and show that the number of tests in a software project can be well predicted by employing code maintenance profiles (i.e., how many commits were performed in each of the maintenance activities: corrective, perfective, adaptive). Our findings also reveal that more often than not, developers perform code fixes without performing complementary test maintenance in the same commit (e.g., update an existing test or add a new one). When developers do perform test maintenance, it is likely to be affected by the semantic changes they perform as part of their commit. Our work is based on studying 61 popular open source projects, comprised of over 240,000 commits consisting of over 16,000,000 semantic change type instances, performed by over 4,000 software engineers.Comment: postprint, ICSME 201

CloudScent: a model for code smell analysis in open-source cloud

The low cost and rapid provisioning capabilities have made open-source cloud a desirable platform to launch industrial applications. However, as open-source cloud moves towards maturity, it still suffers from quality issues like code smells. Although, a great emphasis has been provided on the economic benefits of deploying open-source cloud, low importance has been provided to improve the quality of the source code of the cloud itself to ensure its maintainability in the industrial scenario. Code refactoring has been associated with improving the maintenance and understanding of software code by removing code smells. However, analyzing what smells are more prevalent in cloud environment and designing a tool to define and detect those smells require further attention. In this paper, we propose a model called CloudScent which is an open source mechanism to detect smells in open-source cloud. We test our experiments in a real-life cloud environment using OpenStack. Results show that CloudScent is capable of accurately detecting 8 code smells in cloud. This will permit cloud service providers with advanced knowledge about the smells prevalent in open-source cloud platform, thus allowing for timely code refactoring and improving code quality of the cloud platforms

Why We Engage in FLOSS: Answers from Core Developers

The maintenance and evolution of Free/Libre Open Source Software (FLOSS) projects demand the constant attraction of core developers. In this paper, we report the results of a survey with 52 developers, who recently became core contributors of popular GitHub projects. We reveal their motivations to assume a key role in FLOSS projects (e.g., improving the projects because they are also using it), the project characteristics that most helped in their engagement process (e.g., a friendly community), and the barriers faced by the surveyed core developers (e.g., lack of time of the project leaders). We also compare our results with related studies about others kinds of open source contributors (casual, one-time, and newcomers).Comment: Accepted at CHASE 2018: 11th International Workshop on Cooperative and Human Aspects of Software Engineering (8 pages

Extracting Build Changes with BUILDDIFF

Build systems are an essential part of modern software engineering projects. As software projects change continuously, it is crucial to understand how the build system changes because neglecting its maintenance can lead to expensive build breakage. Recent studies have investigated the (co-)evolution of build configurations and reasons for build breakage, but they did this only on a coarse grained level. In this paper, we present BUILDDIFF, an approach to extract detailed build changes from MAVEN build files and classify them into 95 change types. In a manual evaluation of 400 build changing commits, we show that BUILDDIFF can extract and classify build changes with an average precision and recall of 0.96 and 0.98, respectively. We then present two studies using the build changes extracted from 30 open source Java projects to study the frequency and time of build changes. The results show that the top 10 most frequent change types account for 73% of the build changes. Among them, changes to version numbers and changes to dependencies of the projects occur most frequently. Furthermore, our results show that build changes occur frequently around releases. With these results, we provide the basis for further research, such as for analyzing the (co-)evolution of build files with other artifacts or improving effort estimation approaches. Furthermore, our detailed change information enables improvements of refactoring approaches for build configurations and improvements of models to identify error-prone build files.Comment: Accepted at the International Conference of Mining Software Repositories (MSR), 201

Identifying Extract Class and Extract Method Refactoring Opportunities Through Analysis of Variable Declarations and Uses

For small software systems, with perhaps a few thousand lines of code, software structure is largely an esthetic issue. When software systems grow large, including perhaps a million or more lines of source code, their structures become much more important. Developing a large system requires teams of developers working in concert to provide a finished product in a reasonable amount of time. That means that many people will read each component to use, test or modify towards accomplishing new features. In the software development life cycle, the maintenance phase is a dominant stage that impacts production cost of the system dramatically. This is mainly because, for a successful system, the maintenance phase lasts until the system\u27s retirement and includes crucial operations such as enhancing performance, fixing newly discovered bugs and adopting/expending the software to meet new user requirements. Moreover, a software component may be modified or fixed by someone who is not the original author of that component. In this case, all the operations conducted during maintenance or initial development may lead to insertion of code into a unit that may be unrelated to the original design concept of that unit. As software systems become large and complex they grow too long to read and understand completely by a single person. After their initial implementations, maintenance operations tend to make the system even less maintainable, increasing the time and effort needed for future maintenance. In this research, we are interested in finding ways to successfully detect code defects and propose solutions to increase the overall maintainability of software systems that are larger than any one person can completely comprehend from its code alone. This process of refactoring software impacts the total production cost of the system positively by improving the quality of software code such as its comprehensibility and readability. To reduce the total development cost for a system, we suggest three main re-factorings. These novel forms of refactoring techniques aim to eliminate code defects such as large classes and long methods. The main goal of these re-factorings is to create smaller and cohesive software units with clear intentions to improve the maintainability of software. We provide analysis and visualization tools to help a user identify candidate code fragments to be extracted as separate unites. With these automation tools, developers do not have to manually inspect a foreign code base to detect possible refactoring opportunities. Through the visual representations we provide, one can observe all suggested re-factorings effectively on large scale software systems and decide whether a particular refactoring needs to be applied. To show the effectiveness of our techniques, we also provide some experiments conducted using these tools and techniques both on our own project\u27s source code and other open-source projects

Nip it in the Bud: Moderation Strategies in Open Source Software Projects and the Role of Bots

Much of our modern digital infrastructure relies critically upon open sourced software. The communities responsible for building this cyberinfrastructure require maintenance and moderation, which is often supported by volunteer efforts. Moderation, as a non-technical form of labor, is a necessary but often overlooked task that maintainers undertake to sustain the community around an OSS project. This study examines the various structures and norms that support community moderation, describes the strategies moderators use to mitigate conflicts, and assesses how bots can play a role in assisting these processes. We interviewed 14 practitioners to uncover existing moderation practices and ways that automation can provide assistance. Our main contributions include a characterization of moderated content in OSS projects, moderation techniques, as well as perceptions of and recommendations for improving the automation of moderation tasks. We hope that these findings will inform the implementation of more effective moderation practices in open source communities

Reuse and maintenance practices among divergent forks in three software ecosystems

With the rise of social coding platforms that rely on distributed version control systems, software reuse is also on the rise. Many software developers leverage this reuse by creating variants through forking, to account for different customer needs, markets, or environments. Forked variants then form a so-called software family; they share a common code base and are maintained in parallel by same or different developers. As such, software families can easily arise within software ecosystems, which are large collections of interdependent software components maintained by communities of collaborating contributors. However, little is known about the existence and characteristics of such families within ecosystems, especially about their maintenance practices. Improving our empirical understanding of such families will help build better tools for maintaining and evolving such families. We empirically explore maintenance practices in such fork-based software families within ecosystems of open-source software. Our focus is on three of the largest software ecosystems existence today: Android,.NET, and JavaScript. We identify and analyze software families that are maintained together and that exist both on the official distribution platform (Google play, nuget, and npm) as well as on GitHub , allowing us to analyze reuse practices in depth. We mine and identify 38 software families, 526 software families, and 8,837 software families from the ecosystems of Android,.NET, and JavaScript, to study their characteristics and code-propagation practices. We provide scripts for analyzing code integration within our families. Interestingly, our results show that there is little code integration across the studied software families from the three ecosystems. Our studied families also show that techniques of direct integration using git outside of GitHub is more commonly used than GitHub pull requests. Overall, we hope to raise awareness about the existence of software families within larger ecosystems of software, calling for further research and better tools support to effectively maintain and evolve them