5.0SEJul 1Code
Social Popularity of GitHub Projects: A Lifeline or a Liability?Mohit Kaushik, Kuljit Kaur Chahal
Social coding platforms such as GitHub host millions of repositories, yet many suffer from high mortality rates. Despite this, several survival factors remain poorly understood. Human capital is widely recognized as essential. Social attention, while often assumed to be a lifeline, can become a liability. Structural features that improve onboarding, such as code readability and documentation, may also accelerate the cessation of active development when combined with massive visibility. To examine these dynamics, we analyzed more than 73,000 GitHub repositories using an Accelerated Failure Time (AFT) survival framework, which accounts for the time-varying nature of predictors. Our study identifies human capital as the most critical determinant of project survival. In contrast, excessive social attention emerges as a liability, and when coupled with accessibility features, it amplifies the risk of project inactivity. Importantly, when the number of contributors interacts with social popularity, the protective effect of labor becomes visible, highlighting the need for governance strategies that balance visibility with labor capacity to ensure the long-term resilience of open-source projects.
6.0SEMay 12
The Death Spiral of Open Source Projects: A Post-Mortem Analysis of Pull Request Workflow DynamicsMohit Kaushik, Kuljit Kaur Chahal
Open Source Software projects (OSS) are central to modern technology, yet their survival rates remain low. Prior research has examined project mortality through macro-level indicators such as commit activity, developer abandonment, and ecosystem dependencies, but the micro-level dynamics of the Pull Request (PR) workflow have been largely overlooked. This study provides the first large-scale post-mortem analysis of PR workflows across 1,736 inactive GitHub repositories and 1.3 million human-driven PRs. Using a mixed-method quantitative design, we investigate three dimensions of mortality. First, our comparative descriptive analysis shows that workflow friction, extended review cycles, and negativity penalties are endemic properties of the entire GitHub platform across both active and inactive projects. Rejected PRs consistently attract higher discussion and negativity regardless of project health. Second, our evolutionary analysis identifies a universal ``death spiral" marked by declining innovation rates, exponential backlog growth, rising merge latency. The collapse was defined by silence and disengagement. Labeling formalization remained endemic throughout the lifecycle, while toxicity did not intensify. Finally, our explanatory modeling demonstrates that project lifespan is not determined by workflow efficiency but by inherent value and ecosystem dynamics. Popularity and innovation emerge as strong positive predictors of survival, while friction, rejection rates, labeling formalization, and negativity scale with longevity as byproducts rather than causes of failure. Robustness checks across alternative inactivity thresholds confirm these findings. Together, this work reframes OSS mortality as a socio-technical phenomenon in which abandonment and ecosystem value dominate survival outcomes, while PR-level workflow discipline plays a secondary role.
6.7DCJul 1
CloudyGUI: A Novel Python-based Framework for Auto-Scaling and Cloud Workload AnalysisJyoti Bawa, Mohit Kaushik, Kuljit Kaur Chahal et al.
Purpose: Cloud computing environments are highly dynamic, creating major challenges for resource management. Accurate workload prediction is therefore essential for effective auto-scaling. To address this, we present CloudyGUI, a Python simulation framework with an easy-to-use GUI that allows researchers to test and validate resource management strategies. Methods: This framework employs a three-stage pipeline: workload generation, prediction (utilizing XGBoost and LSTM), and an auto-scaling system based on the MAPE loop. Validation includes internal, intermediate, and external methods to ensure system reliability. Results: CloudyGUI's generated workloads closely match real-world datasets. A two-sample K-S test confirms this alignment, showing strong p-values of 0.19 for CPU and 0.14 for memory. When compared to a command-line tool, the GUI adds only a minimal overhead of 1.4x-4.67x. Furthermore, expert review validates the tool's realism and practical usefulness. Conclusion: CloudyGUI fills a critical gap by providing an accessible and efficient platform for simulating auto-scaling in cloud applications, helping researchers develop advanced cloud management solutions.
A Fine-grained Data Set and Analysis of Tangling in Bug Fixing CommitsSteffen Herbold, Alexander Trautsch, Benjamin Ledel et al.
Context: Tangled commits are changes to software that address multiple concerns at once. For researchers interested in bugs, tangled commits mean that they actually study not only bugs, but also other concerns irrelevant for the study of bugs. Objective: We want to improve our understanding of the prevalence of tangling and the types of changes that are tangled within bug fixing commits. Methods: We use a crowd sourcing approach for manual labeling to validate which changes contribute to bug fixes for each line in bug fixing commits. Each line is labeled by four participants. If at least three participants agree on the same label, we have consensus. Results: We estimate that between 17% and 32% of all changes in bug fixing commits modify the source code to fix the underlying problem. However, when we only consider changes to the production code files this ratio increases to 66% to 87%. We find that about 11% of lines are hard to label leading to active disagreements between participants. Due to confirmed tangling and the uncertainty in our data, we estimate that 3% to 47% of data is noisy without manual untangling, depending on the use case. Conclusion: Tangled commits have a high prevalence in bug fixes and can lead to a large amount of noise in the data. Prior research indicates that this noise may alter results. As researchers, we should be skeptics and assume that unvalidated data is likely very noisy, until proven otherwise.