Software practitioners often encounter workplace unfairness, such as unequal recognition and gender bias. While the link between fairness and job satisfaction has been established in other fields, its relevance to software professionals remains underexplored. This study examines how fairness perceptions relate to job satisfaction among software practitioners, focusing on both general trends and demographic-specific differences. We conducted an online survey of 108 software practitioners, followed by ordinal logistic regression to analyze the relationship between fairness perceptions and job satisfaction in software engineering contexts, with moderation analysis examining how this relationship varies across demographic groups. Our findings indicate that all four fairness dimensions (namely distributive, procedural, interpersonal, and informational fairness) significantly affect overall job satisfaction and satisfaction with job security. Among these, interpersonal fairness has the biggest impact. The relationship between fairness and job satisfaction is stronger for female, ethnically underrepresented, less experienced practitioners, and those with work limitations. Fairness in authorship emerged as an important factor for job satisfaction collectively, while fairness in policy implementation, high-demand situations, and working hours impacted specific demographic groups. This study highlights the role of fairness among software practitioners, offering strategies for organizations to promote fair practices and targeted approaches for certain demographic groups.

The Gentoo ecosystem has evolved significantly over 23 years, highlighting the critical impact of developer sentiment on workforce dynamics such as turnover, retention, and growth. While prior research has explored sentiment at the project level, sentiment-driven dynamics at the component level remain underexplored, particularly in their implications for software stability.

Abstract The pull-based development model facilitates global collaboration within open-source software projects. However, whereas it is increasingly common for software to depend on other projects in their ecosystem, most research on the pull request decision-making process explored factors within projects, not the broader software ecosystem they comprise. We uncover ecosystem-wide factors that influence pull request acceptance decisions. We collected a dataset of approximately 1.8 million pull requests and 2.1 million issues from 20,052 GitHub projects within the NPM ecosystem. Of these, $$98\%$$ depend on another project in the dataset, enabling the study of collaboration across dependent projects. We employed social network analysis to create a collaboration network in the ecosystem, and mixed-effects logistic regression and random forest techniques to measure the impact and predictive strength of the tested features. We find that gaining experience within the software ecosystem through active participation in issue-tracking systems, submitting pull requests, and collaborating with pull request integrators and the ecosystem community benefits all open-source contributors, especially project newcomers. These results are complemented with an exploratory qualitative analysis of 538 pull requests. We find that developers with ecosystem experience make contributions more commonly associated with mature developers. For example, they introduce new features and bug fixes less commonly than dependency updates as part of maintenance. Zooming in on a subset of 111 pull requests with clear ecosystem involvement, we find 3 overarching and 10 specific reasons why developers involve ecosystem projects in their pull requests. For example, when another project has implemented a solution that can be used as a reference implementation. The results show that combining ecosystem-wide factors with features studied in previous work to predict the outcome of pull requests reached an overall F1 score of 0.92. However, the outcomes of pull requests submitted by newcomers are harder to predict. Our study identified some benefits associated with ecosystem-wide collaboration dynamics, laying the groundwork for future work in this direction.

ABSTRACT Background Developers, who are the main driving force behind software development, have central work in handling software components such as modules, libraries, and frameworks, which are the backbone of a project's architecture. Managing these components well ensures the smooth implementation of new features, maintains system integrity, and addresses dependencies efficiently. This clearly needs effective team collaboration as well as task management that, in the end, may significantly boost productivity. Additionally, as human beings, emotional involvement during development may naturally deeply influence developers' interaction and productivity. The emotions expressed in negative and positive sentiments may be triggered by different causes, including successfully overcoming obstacles, receiving positive feedback, facing challenges, or demanding tight deadlines. Objective In this study, we investigated the three aspects (e.g., developers, software components, and sentiments), specifically focusing on how developers' sentiments affect the components they work on or vice versa. Methods We conducted a structured analysis of Gentoo's means of communication, the mailing list of technical discussions, and the developers' activity (e.g., commits) during the software development over 23 years. Results We characterized the components that were affected by sentiments and found that there are differences in the developers' activity in the affected components. Conclusion This study offers implications mainly for investigating the sentiments expressed on the granular level of components and further scrutinizing the components and developers' activity. In addition, our study offers a structured approach that applies to any software project where written communication and development logs are available and several hypotheses that may direct to future works.

Software practitioners often discuss technical and social workplace issues, both in-person and online. One such social issue is fairness. As research on fairness in software engineering expands, it often concentrates on specific issues. This exploratory study provides discussions on Stack Exchange sites, focusing on the experiences and expectations of fairness in software engineering. We also want to identify the fairness aspects software practitioners talk about the most. For example, do they care more about fairness in income or how they are treated in the workplace?

The rise of microarchitectural attacks has necessitated robust detection and mitigation strategies to secure computing systems. Traditional tools, such as static and dynamic code analyzers and attack detectors, often fall short due to their reliance on predefined patterns and heuristics that lack the flexibility to adapt to new or evolving attack vectors. In this paper, we introduce for the first time a microarchitecture security assistant, built on OpenAI's GPT-3.5, which we refer to as μLAM. This assistant surpasses conventional tools by not only identifying vulnerable code segments but also providing context-aware mitigations, tailored to specific system specifications and existing security measures. Additionally, μLAM leverages real-time data from dynamic Hardware Performance Counters (HPCs) and system specifications to detect ongoing attacks, offering a level of adaptability and responsiveness that static and dynamic analyzers cannot match.

Abstract Increasing code velocity is a common goal for a variety of software projects. The efficiency of the code review process significantly impacts how fast the code gets merged into the final product and reaches the customers. We conducted a qualitative survey to study the code velocity-related beliefs and practices in place. We analyzed 75 completed surveys from SurIndustryDevs participants from the industry and 36 from the open-source community. Our critical findings are (a) the industry and open-source community hold a similar set of beliefs, (b) quick reaction time is of utmost importance and applies to the tooling infrastructure and the behavior of other engineers, (c) time-to-merge is the essential code review metric to improve, (d) engineers are divided about the benefits of increased code velocity for their career growth, (e) the controlled application of the commit-then-review model can increase code velocity. Our study supports the continued need to invest in and improve code velocity regardless of the underlying organizational ecosystem.

Build logs from a variety of Continuous Integration (CI) systems contain temporal data about the presence and distribution of compiler warnings. Results from the analysis and mining of that data will indicate what warnings engineers find useful and fix, or continuously ignore. The findings will include resolution times and resolution types for different warning categories. That data will help compiler developers adjust the warning levels according to the ground truth, clarify the diagnostic messages, and improve the non-actionable warnings. The empirical findings will also help engineers to decide what warnings are worth fixing and which ones are not.

This paper investigates how the duration of various code review periods changes over a projects’ lifetime. We study four open-source software (OSS) projects: Blender, FreeBSD, LLVM, and Mozilla. We mine and analyze the characteristics of 283,235 code reviews that cover, on average, seven years’ worth of development. Our main conclusion is that neither the passage of time or the project’s size impact code velocity. We find that (a) the duration of various code review periods (time-to-first-response, time-to-accept, and time-to-merge) for FreeBSD, LLVM, and Mozilla either becomes shorter or stays the same; no directional trend is present for Blender, (b) an increase in the size of the code bases (annually 3–17%) does not accompany a decrease in code velocity, and (c) for FreeBSD, LLVM, and Mozilla, the 30-day moving median stays in a fixed range for time-to-merge. These findings do not change with variabilities in code churn metrics, such as the number of commits or distinct authors of code changes.

Burnout is a work-related syndrome that, similar to many occupations, influences most software developers. For decades, studies in software engineering(SE) have explored the causes of burnout and its consequences among IT professionals. This paper is a systematic mapping study (SMS) of the studies on burnout in SE, exploring its causes and consequences, and how it is studied (e.g., choice of data). We conducted a systematic mapping study and identified 92 relevant research articles dating as early as the early 1990s, focusing on various aspects and approaches to detect burnout in software developers and IT professionals. Our study shows that early research on burnout was primarily qualitative, which has steadily moved to more quantitative, data-driven in the last decade. The emergence of machine learning (ML) approaches to detect burnout in developers has become a de-facto standard. Our study summarises what we now know about burnout, how software artifacts indicate burnout, and how machine learning can help its early detection. As a comprehensive analysis of past and present research works in the field, we believe this paper can help future research and practice focus on the grand challenges ahead and offer necessary tools.

Searchable Symmetric Encryption (SSE) supports efficient yet secure query processing over outsourced symmetrically encrypted databases without the need for decryption. A longstanding open question has been the following: can we design a fast, scalable, linear storage and low-leakage SSE scheme that efficiently supports arbitrary Boolean queries over encrypted databases? In this paper, we present the design, analysis and prototype implementation of the first SSE scheme that efficiently supports conjunctive, disjunctive and more general Boolean queries (in both the conjunctive and disjunctive normal forms) while scaling smoothly to extremely large encrypted databases, and while incurring linear storage overheads and supporting extremely fast query processing in practice. We quantify the leakage of our proposal via a rigorous cryptographic analysis and argue that it achieves security against a well-known class of leakage-abuse and volume analysis attacks. Finally, we demonstrate the storage-efficiency and scalability of our proposed scheme by presenting experimental results of a prototype implementation of our scheme over large real-world databases.

Context: The pull-based development model is widely used in open source projects, leading to the emergence of trends in distributed software development. One aspect that has garnered significant attention concerning pull request decisions is the identification of explanatory factors.Objective: This study builds on a decade of research on pull request decisions and provides further insights. We empirically investigate how factors influence pull request decisions and the scenarios that change the influence of such factors.Method: We identify factors influencing pull request decisions on GitHub through a systematic literature review and infer them by mining archival data. We collect a total of 3,347,937 pull requests with 95 features from 11,230 diverse projects on GitHub. Using these data, we explore the relations among the factors and build mixed effects logistic regression models to empirically explain pull request decisions.Results: Our study shows that a small number of factors explain pull request decisions, with that concerning whether the integrator is the same as or different from the submitter being the most important factor. We also note that the influence of factors on pull request decisions change with a change in context; e.g., the area hotness of pull request is important only in the early stage of project development, however it becomes unimportant for pull request decisions as projects become mature.

Engineers consider the presence of dead code as an undesirable attribute of the code base. The industry lacks methods to quantify the benefits of deleting dead code efficiently. The current approach utilizes a simplistic metric that uses the lines of code (LOC) deleted as a proxy to estimate the benefit gained. However, not all LOC are equal. The research community can support the industry and propose methods and metrics that can help to (a) determine the priority order for dead code removal, and (b) quantify the benefits of dead code removal. Improved metrics can result in a more objective ranking of dead code deletion efforts when compared to other competing tasks.

Using custom memory allocators is an efficient performance optimization technique. However, dependency on a custom allocator can introduce several maintenance-related issues. We present lessons learned from the industry and provide critical guidance for using custom memory allocators and enumerate various challenges associated with integrating them. These recommendations are based on years of experience incorporating custom allocators into different industrial software projects.

Studies on software evolution explore code churn and code velocity at the abstraction level of a company or an entire project. We argue that this approach misses the differences among abstractions layers and subsystems of large projects. We conduct a case study on four BSD family operating systems: DragonFlyBSD, FreeBSD, NetBSD, and OpenBSD, to investigate the evolution of code churn and code velocity across kernel and non-kernel code. We mine commits for characteristics such as annual growth rate, commit types, change type ratio, and size taxonomy, indicating code churn. Likewise, we investigate code velocity in terms of code review periods, i.e., time-to-first-response, time-to-accept, and time-to-merge.Our study provides evidence that software evolves differently at abstraction layers: kernel and non-kernel. The study finds similarities in the code base growth rate and distribution of commit types (neutral, additive, and subtractive) across BSD subsystems, however, (a) most commits contain either kernel or non-kernel code, (b) kernel commits are larger than non-kernel commits, and (c) code reviews for kernel code take longer than non-kernel code.

Increasing code velocity (or the speed with which code changes are reviewed and merged) is integral to speeding up development and contributes to the work satisfaction of engineers. While factors affecting code change acceptance have been investigated in the past, solutions to decrease the code review lifetime are less understood. This study investigates the code review process to quantify delays and investigate opportunities to potentially increase code velocity. We study the temporal characteristics of half a million code reviews hosted on Gerrit and Phabricator, starting from the first response, to a decision to accept or reject the changes, and until the changes are merged into a target branch. We identified two types of time delays: (a) the wait time from the proposal of code changes until first response, and (b) the wait time between acceptance and merging. Our study indicates that reducing the time between acceptance and merging has the potential to speed up Phabricator code reviews by 29--63%. Small code changes and changes made by authors with a large number of previously accepted code reviews have a higher chance of being immediately accepted, without code review iterations. Our analysis suggests that switching from manual to automatic merges can help increase code velocity.

Phabricator is a modern code collaboration tool used by popular projects like FreeBSD and Mozilla. However, unlike the other well-known code review environments, such as Gerrit or GitHub, there is no readily accessible public code review dataset for Phabricator. This paper describes our experience mining code reviews from five different projects that use Phabricator (Blender, FreeBSD, KDE, LLVM, and Mozilla). We discuss the challenges associated with the data retrieval process and our solutions, resulting in a dataset with details regarding 317,476 Phabricator code reviews. Our dataset1 is available in both JSON and MySQL database dump formats. The dataset enables analyses of the history of code reviews at a more granular level than other platforms. In addition, given that the projects we mined are publicly accessible via the Conduit API [18], our dataset can be used as a foundation to fetch additional details and insights.

Code velocity, or the speed with which code changes are integrated into a production environment, plays a crucial role in Continuous Integration and Continuous Deployment. Many studies report factors influencing code velocity. However, solutions to increase code velocity are unclear. Meanwhile, the industry continues to issue guidelines on "ideal" code change size, believing it increases code velocity despite lacking evidence validating the practice. Surprisingly, this fundamental question has not been studied to date. This study investigates the practicality of improving code velocity by optimizing pull request size and composition (ratio of insertions, deletions, and modifications).

The gender gap is a significant concern facing the software industry as the development becomes more geographically distributed. Widely shared reports indicate that gender differences may be specific to each region. However, how complete can these reports be with little to no research reflective of the Open Source Software (OSS) process and communities software is now commonly developed in? Our study presents a multi-region geographical analysis of gender inclusion on GitHub. This mixed-methods approach includes quantitatively investigating differences in gender inclusion in projects across geographic regions and investigate these trends over time using data from contributions to 21,456 project repositories. We also qualitatively understand the unique experiences of developers contributing to these projects through a survey that is strategically targeted to developers in various regions worldwide. Our findings indicate that gender diversity is low across all parts of the world, with no substantial difference across regions. However, there has been statistically significant improvement in diversity worldwide since 2014, with certain regions such as Africa improving at faster pace. We also find that most motivations and barriers to contributions (e.g., lack of resources to contribute and poor working environment) were shared across regions, however, some insightful differences, such as how to make projects more inclusive, did arise. From these findings, we derive and present implications for tools that can foster inclusion in open source software communities and empower contributions from everyone, everywhere.

Background: Personality plays a pivotal role in our understanding of human actions and behavior. Today, the applications of personality are widespread, built on the solutions from psychology to infer personality. Aim: In software engineering, for instance, one widely used solution to infer personality uses textual communication data. As studies on personality in software engineering continue to grow, it is imperative to understand the performance of these solutions. Method: This paper compares the inferential ability of three widely studied text-based personality tests against each other and the ground truth on GitHub. We explore the challenges and potential solutions to improve the inferential ability of personality tests. Results: Our study shows that solutions for inferring personality are far from being perfect. Software engineering communications data can infer individual developer personality with an average error rate of 41%. In the best case, the error rate can be reduced up to 36% by following our recommendations1.

Pull-based development is a widely adopted paradigm for collaboration in distributed software development, attracting eyeballs from both academic and industry. To better study pull-based development model, this paper presents a new dataset containing 96 features collected from 11,230 projects and 3,347,937 pull requests. We describe the creation process and explain the features in details. To the best of our knowledge, our dataset is the most comprehensive and largest one toward a complete picture for pull-based development research.

In 2014, a Microsoft study investigated the sort of questions that data science applied to software engineering should answer. This resulted in 145 questions that developers considered relevant for data scientists to answer, thus providing a research agenda to the community. Fast forward to five years, no further studies investigated whether the questions from the software engineers at Microsoft hold for other software companies, including software-intensive companies with different primary focus (to which we refer as software-defined enterprises). Furthermore, it is not evident that the problems identified five years ago are still applicable, given the technological advances in software engineering. This paper presents a study at ING, a software-defined enterprise in banking in which over 15,000 IT staff provides in-house software solutions. This paper presents a comprehensive guide of questions for data scientists selected from the previous study at Microsoft along with our current work at ING. We replicated the original Microsoft study at ING, looking for questions that impact both software companies and software-defined enterprises and continue to impact software engineering. We also add new questions that emerged from differences in the context of the two companies and the five years gap in between. Our results show that software engineering questions for data scientists in the software-defined enterprise are largely similar to the software company, albeit with exceptions. We hope that the software engineering research community builds on the new list of questions to create a useful body of knowledge.

Existing maintainability models are used to identify technical debt of software systems. Targeting entire codebases, such models lack the ability to determine shortcomings of smaller, fine-grained changes. This paper proposes a new maintainability model - the Delta Maintainability Model (DMM) - to measure fine-grained code changes, such as commits, by adapting and extending the SIG Maintainability Model. DMM categorizes changed lines of code into low and high risk, and then uses the proportion of low risk change to calculate a delta score. The goal of the DMM is twofold: first, producing meaningful and actionable scores; second, compare and rank the maintainability of fine-grained modifications. We report on an initial study of the model, with the goal of understanding if the adapted measurements from the SIG Maintainability Model suit the fine-grained scope of the DMM. In a manual inspection process for 100 commits, 67 cases matched the expert judgment. Furthermore, we report an exploratory empirical study on a data set of DMM scores on 3,017 issue-fixing commits of four open source and four closed source systems. Results show that the scores of DMM can be used to compare and rank commits, providing developers with a means to do root cause analysis on activities that impacted maintainability and, thus, address technical debt at a finer granularity.

The appeal of delivering new features faster has led many software projects to adopt rapid releases. However, it is not well understood what the effects of this practice are. This paper presents an exploratory case study of rapid releases at ING, a large banking company that develops software solutions in-house, to characterize rapid releases. Since 2011, ING has shifted to a rapid release model. This switch has resulted in a mixed environment of 611 teams releasing relatively fast and slow. We followed a mixed-methods approach in which we conducted a survey with 461 participants and corroborated their perceptions with 2 years of code quality data and 1 year of release delay data. Our research shows that: rapid releases are more commonly delayed than their non-rapid counterparts, however, rapid releases have shorter delays; rapid releases can be beneficial in terms of reviewing and user-perceived quality; rapidly released software tends to have a higher code churn, a higher test coverage and a lower average complexity; challenges in rapid releases are related to managing dependencies and certain code aspects, e.g., design debt.

Background Open source software projects show gender bias suggesting that other demographic characteristics of developers, like geographical location, can negatively influence evaluation of contributions too. Aim This study contributes to this emerging body of knowledge in software development by presenting a quantitative analysis of the relationship between the geographical location of developers and evaluation of their contributions on GitHub. Method We present an analysis of 70,000+ pull requests selected from 17 most actively participating countries to model the relationship between the geographical location of developers and pull request acceptance decision. Results and Conclusion We observed structural differences in pull request acceptance rates across 17 countries. Countries with no apparent similarities such as Switzerland and Japan had one of the highest pull request acceptance rates while countries like China and Germany had one of the lowest pull request acceptance rates. Notably, higher acceptance rates were observed for all but one country when pull requests were evaluated by developers from the same country.

People's personality has the potential to explain the behavior in different situations. This understanding of the behavior is required to understand the intricacies of the team, which can then be used to optimize work performance. As an initial step towards optimizing work performance, in this paper, we explore the inferential power of the personality traits in explaining the behavior of contributors in various contexts of software development in GitHub. Analyses of 243 actively discussed projects showed that the contributors with extreme (high or low) levels of contributions are more neurotic compared to the contributors with medium-level of contributions. Analyses of 423 active contributors showed that contributors evolve as more conscientious, more extrovert and less agreeable over the years of participation. The findings of this study match our ideas and are promising for further explorations.

A majority of OSS projects fails due to their inability to garner significant and sustained developer community participation. The problem proliferates when competing projects emerge from the source code of an existing project, a phenomenon called forking of the original project, claiming existing and potential developer community participation. In this study, we empirically analyze the influence of forking on the sustainability of the developer community participation in the original project. Further, we try to explain the observed behavior in terms of the characteristics of the project observed at the time of forking. A large-scale study of 2,217 projects hosted on GitHub shows that 1 in every 5 original projects observes a decline in the sustainability of the developer community participation after forking. We find that the negative effect is more pronounced in projects ported to GitHub from other platforms (≈ 20%), compared to GitHub developed projects (≈ 9%). We also find that the observed behavior can be explained in terms of the characteristics of the competing projects at the time of forking. For instance, in medium sized projects an increase in the maturity of the original project by a year decreases the odds of decline in the sustainability of the developer participation by 23%.

Hiring top talent is essential for any software company's success. After joining the company, new hires often spend weeks or months before making any major contribution and attaining the same productivity level as existing employees. We use the term ramp-up journey to refer to this transition of new hires from novice to experts. There can be several factors, such as lack of experience or lack of familiarity with processes unique to the new company, which influence the ramp-up journey. To understand such aids and impediments in the ramp-up journey, we conducted a study by analyzing data extracted from version control systems of eight large and popular product groups in Microsoft with several thousand software developers. In particular, we studied two aspects of the ramp-up journey. First, we studied time taken to make the first check-in into the version control system, an important milestone in the ramp-up journey indicating the first contribution. Second, we analyzed the time taken to reach the same productivity level as existing employees in terms of check-ins. We further augmented our quantitative study with qualitative results derived by surveying 411 professional developers. Our study produced promising results, including factors such as having a mentor, prior knowledge of required skill sets, and proactively asking questions, that could help reduce the ramp-up journey of new hires.

Software project performance largely depends on the software development team. Studies have shown that interest and activity levels of contributors at any time significantly affect project success measures. This dissertation provides suggestions to enhance contributors' performance and participation intentions to help improve project performance. To do so, we mine historical data in software repositories from a two-pronged approach: 1) To assess contributors' performance to identify strengths and areas of improvement. 2) To measure the influence of factors on contributors' participation and performance, and provide suggestions that help advance contributor's engagement. The methodology used in this study leverage empirical techniques, both quantitative and qualitative, to conduct the analysis. We believe that the insights presented here will help contributors improve their performance. Also, we expect managers and business analysts to benefit from the suggestions to revise factors that negatively influence contributors' engagement and hence improve project performance.

Free/Libre Open Source Software (FLOSS) community management is an important issue. Contributor churn (joining or leaving a project) causes failure of the majority of software projects. In this paper, we present a framework to characterize stability of the community in software maintenance projects by mining Issue Tracking System (ITS). We identify key stability indicators and propose metrics to measure them. We conduct time series analysis on metrics data to examine the stability of the community. We model community participation patterns and forecast future behavior to help plan and support informed decision making. We present a case study of four years data of Google Chromium Project and investigate the inferential ability of the framework.

Contribution and performance assessment is an established practice in organization with its sphere of influence spanning process, policy, people (client) and personnel (employee). Multiple roles in organization (for e.g. employees, project manager, hr manager etc.) view contribution and performance assessment with different perspectives and objectives. However, despite its ability to ensure growth and affluence of organization existing contribution and performance assessment practices are marred with flaws and imperfections. The objective of this work is to serve wide-ranged requirements of software maintenance professionals (in context of contribution and performance assessment) in organization by application of variegated approaches (tools, techniques, models etc.) on software repositories (Issue Tracking System, Version Control System, Source Code Repositories etc.). We study pain-points of practitioners (in context of contribution and performance assessment) and present solution approach by mining software repositories. We implement the approach on real-world data and gather insights from practitioners to validate and improve our research. In this paper, 'SamikshaUmbra' (research umbrella that circumscribe related research threads) we present approach to meet stated research objectives and viable research directions.