We analyse contributor coordination in Kubernetes, a large open source project comparable in scale to a major enterprise software division. Over 11 years, 25,953 contributors created 46,768 issues and 339,332 comments, providing a complete record of collaboration rarely visible in proprietary settings. We examine how contributors organise themselves across technical domains and how coordination affects development outcomes. Our results show that collaboration is highly modular, with contributors interacting 42.9 times more often within domains than across them. Issues related to multiple domains take 4.19 times longer to resolve (due to both coordination complexity and issue difficulty), and coordination within the modules depends on a small subset of contributors. These findings demonstrate how large-scale coordination dependencies can be observed and quantified in open source development, offering a transferable tool for analyzing enterprise-scale software projects.

We present MKR: Mining Kubernetes Repositories, a dataset capturing more than eleven years of development and community interaction in Kubernetes—an open-source platform for automating the deployment, scaling, and management of containerized applications. As the infrastructure backbone for running thousands of applications across diverse environments, Kubernetes has become one of the most widely adopted and influential projects in modern cloud-native computing. Spanning from June 2014 to July 2025, MKR integrates over two million artefacts from GitHub, including 130,832 commits (through July 2025), 83,368 pull requests, 46,768 issues, and 1,795,423 comments (through March 2025). With contributions from 28,890 unique GitHub commenters and 4,931 commit authors, MKR provides a longitudinal record of how Kubernetes has evolved, scaled, and been maintained over time. The dataset supports research on code evolution, long-term maintenance practices such as API deprecation, contributor retention, governance, and the role of automation in development. MKR allows analyses that connect technical change with decision-making, offering a resource for examining the social and technical dimensions of large-scale open source projects.

AI coding agents contribute thousands of pull requests daily to open-source repositories, yet practitioners lack empirical guidance on optimal contribution sizing. We adapt the therapeutic index framework from pharmacology to characterise the relationship between pull request size and integration outcomes. Analysing 33,078 agent-authored pull requests from the AIDev dataset across five AI coding agents, we model dose-response relationships for efficacy (merge probability) and toxicity (review friction). All agents exhibit statistically significant negative relationships between size and merge probability (p < 0.001), differing substantially in baseline performance (47.5% to 82.6%) and dose sensitivity. Task type substantially moderates these relationships: bug fixes exhibit ED50 of 1,467 lines [95% CI: 1,025–2,216] with therapeutic index of 35.2, whilst features show ED50 of 18,234 lines [95% CI: 12,337–28,390] with therapeutic index of 2.3. This 15-fold difference, confirmed by non-overlapping confidence intervals, indicates that bug fixes exhibit wider therapeutic windows whilst feature implementations exhibit narrower windows.

The rapid evolution of blockchain technology has created a diverse ecosystem of platforms, tools, and applications, and understanding how these technologies are adopted and used in practice is essential for advancing Blockchain-Oriented Software Engineering. This paper presents Web3BlockSet, a curated dataset that enables empirical insights into the blockchain ecosystem through the analysis of Mining Software Repositories on GitHub. We collected 391,596 Issues and Pull Requests from organizations that maintain core blockchain technologies and from community developers who create applications. The dataset offers broad categorization across the blockchain stack, a dual perspective of technology vendors and adopters, and rich metadata that supports diverse analytical approaches.

Machine learning algorithms are increasingly being proposed to solve the problem of predicting defect-prone software components. In this literature, computational experiments are the primary means of evaluating and comparing learners and the credibility of findings depends critically on their experimental design and reporting. This paper audits recent software defect prediction (SDP) experiments by assessing their experimental design, analysis and reporting practices against widely accepted norms from statistics, machine learning and empirical software engineering. Our aim is to characterise the current state of practice and evaluate the reproducibility of published findings. We undertook an audit of relevant studies published from the SCOPUS database (2019-2023) focusing on their experimental design and analysis choices e.g., the outcome variables such as F-measure and the type of out of sample (OOS) validation regime, e.g., cross-validation, plus the statistical analysis and inference mechanisms. In all, we evaluated nine different study issues. This was complemented by an assessment of reproducibility using the instrument proposed by González-Barahona and Robles. Our search located approximately 1,585 experiments in SDP (2019-2023), a substantial body of work. From this, we randomly sampled 101 ( $$ \approx 6.4\%$$ ) papers, 61 journal and 40 conference papers. Almost 50% are behind ‘paywalls’. We found considerable divergence in research practice. The number of datasets used ranged 1-365, the number of learners or learner variants evaluated from 1-34 and the number of performance metrics from 1 to 9. Approximately 45% of papers made use of formal statistical inference. We detected a total of 427 issues distributed across 101 papers (median=4) with only one paper being entirely issue-free. In terms of reproducibility, experiments ranged from near perfect to lacking almost all required information. We also found two examples of tortured phrases and potential “paper mill” activity. Approaches to designing and reporting computational experiments varied greatly, but almost half the studies provided insufficient information such that reproduction would be challenging. Overall, our audit suggests that as a research community, we have considerable scope for improvement. Fortunately, many improvements should be neither difficult nor costly to achieve.

Context: Open-source software (OSS) development is often studied as a decentralized process driven by technical goals. However, mature OSS projects operate under external constraints such as security advisories, release deadlines, and ecosystem dependencies. These pressures shape technical decisions and also communication patterns among contributors, including emotional expression. Objective: This study investigates how emotional expression in OSS projects varies across different types of repositories, evolves over time, and relates to the activity of top contributors. The goal is to assess whether emotional dynamics are shaped more by project function than by technical domain or project size. Methods: We analyzed issue comments from 14 OSS repositories spanning over ten years. A transformer-based classifier was used to detect emotions. Emotional patterns were quantified using a composite Emotional Index, and contextual activity. Contributor roles were assessed using a Contribution Index combining code activity, discussion engagement, and sustained involvement. Analyses were conducted at the repository, temporal, and contributor levels. Results: The four most frequent emotions across all repositories were gratitude, curiosity, confusion, and approval. Emotional patterns tend to cluster by functional role rather than technical domain, with repositories converging toward stable emotional profiles over time. High-impact contributors show distinct expression patterns that reflect their role and stage of engagement. Conclusion: Emotional expression in OSS projects follows recurring patterns linked to project function, contributor roles, and maturity. These findings can help anticipate communication challenges during project evolution and support interaction strategies among contributor groups with differing emotional tendencies.

Decentralised finance (DeFi) protocols often claim to implement decentralised governance via mechanisms such as decentralised autonomous organisations (DAOs), yet the structure of their development processes is rarely examined in detail. This study presents an in-depth case analysis of the development activity distribution in Lido, a prominent DeFi liquid staking protocol. We analyse 6741 human-generated GitHub actions recorded from September 2020 to February 2025. Using standard inequality metrics – Gini coefficient and Herfindahl–Hirschman Index – alongside contributors’ interaction network and core–periphery modelling, we find that development activity is highly concentrated. Overall, the weighted Gini coefficient reaches 0.82 and the most active contributor alone accounts for 24% of the total activity. Despite an even split between core and peripheral contributors, the core group accounts for 98.1% of all weighted development actions. The temporal analysis shows an increase in concentration over time, with the Gini coefficient rising from 0.686 in the bootstrap phase to 0.817 in the maturity phase. The contributors’ interaction network analysis reveals a hub-and-spoke structure with high centralisation in communication flows. While a case study of a single protocol, Lido represents a critical test of decentralisation claims given its prominence, maturity, and DAO governance structure. These findings demonstrate that open-source DeFi development can exhibit highly concentrated control patterns despite decentralised governance mechanisms, revealing a persistent gap between governance and operational decentralisation.

Solidity is the predominant programming language for blockchain-based smart contracts, and its characteristics pose significant challenges for code analysis and maintenance. Traditional software analysis approaches, while effective for conventional programming languages, often fail to address Solidity-specific features such as gas optimization and security constraints. This paper introduces micro-patterns - recurring, small-scale design structures that capture key behavioral and structural peculiarities specific to a language - for Solidity language and demonstrates their value in understanding smart contract development practices. We identified 18 distinct micro-patterns organized in five categories (Security, Functional, Optimization, Interaction, and Feedback), detailing their characteristics to enable automated detection. To validate this proposal, we analyzed a dataset of 23258 smart contracts from five popular blockchains (Ethereum, Polygon, Arbitrum, Fantom and Optimism). Our analysis reveals widespread adoption of micro-patterns, with 99% of contracts implementing at least one pattern and an average of 2.76 patterns per contract. The Storage Saver pattern showed the highest adoption (84.62% mean coverage), while security patterns demonstrated platform-specific adoption rates. Statistical analysis revealed significant platform-specific differences in adoption, particularly in Borrower, Implementer, and Storage Saver patterns.

We analyze developer activity across 10 major Ethereum repositories (totaling 129884 commits, 40550 issues) spanning 10 years to examine how events such as technical upgrades, market events, and community decisions impact development. Through statistical, survival, and network analyses, we find that technical events prompt increased activity before the event, followed by reduced commit rates afterwards, whereas market events lead to more reactive development. Core infrastructure repositories like Go-Ethereum exhibit faster issue resolution compared to developer tools, and technical events enhance core team collaboration. Our findings show how different types of events shape development dynamics, offering insights for project managers and developers in maintaining development momentum through major transitions. This work contributes to understanding the resilience of development communities and their adaptation to ecosystem changes.

In online auctions, fraudulent behaviours such as shill bidding pose significant risks. This paper presents a conceptual framework that applies dynamic, behaviour-based penalties to deter auction fraud using blockchain smart contracts. Unlike traditional post-auction detection methods, this approach prevents manipulation in real-time by introducing an economic disincentive system where penalty severity scales with suspicious bidding patterns. The framework employs the proposed Bid Shill Score (BSS) to evaluate nine distinct bidding behaviours, dynamically adjusting the penalty fees to make fraudulent activity financially unaffordable while providing fair competition. The system is implemented within a decentralized English auction on the Ethereum blockchain, demonstrating how smart contracts enforce transparent auction rules without trusted intermediaries. Simulations confirm the effectiveness of the proposed model: the dynamic penalty mechanism reduces the profitability of shill bidding while keeping penalties low for honest bidders. Performance evaluation shows that the system introduces only moderate gas and latency overhead, keeping transaction costs and response times within practical bounds for real-world use. The approach provides a practical method for behaviour-based fraud prevention in decentralised systems where trust cannot be assumed.

Blockchain technology faces significant challenges related to sustainability, including issues with optimisation, as well as high energy and gas consumption—factors that developers may sometimes neglect. We introduce a methodology to analyse the key sustainability topics discussed by Go-Ethereum developers, using thematic analysis of their issues and comments from Github. Our approach uses the BERT model to conduct an in-depth topic analysis, enabling us to study the underlying themes and trends in developer’s conversations regarding energy use and sustainability. We assess the sustainability of the identified topics using the five dimensions outlined in the Sustainability Awareness Framework (SusAF): economic, social, individual, environmental, and technical. Our goal is to shed light on how much attention developers pay to sustainability and energy consumption issues. The findings from this qualitative analysis aim to encourage technologists to incorporate these considerations into their future projects, in order to achieve better outcomes in terms of sustainability and reduced consumption.

Security and reliability in Blockchain software systems is a major challenge in Blockchain Oriented Software Engineering. One of the most critical components to address at the architectural level is the consensus protocol, as it serves as the mechanism for accepting valid transactions and incorporating them into the ledger history. Given that this process is executed by specific blockchain nodes, it is crucial to consider them as a key point of focus for ensuring the integrity of the entire blockchain history. This paper addresses the major challenge of security and reliability in Blockchain software systems by proposing a new protocol for Permissioned Concurrent Proof of Authority (CPoA). This protocol involves selecting a group of nodes as authority nodes, responsible for validating new identities, blocks, and transactions. The protocol is integrated with a framework that subjects validators to a unique eligibility criterion and a combination of reputation, security score, online aging, and general performance indicators related to node reliability, significantly reducing the risk of validator misbehavior and enhancing security, reliability and confidentiality of the entire blockchain compared to other existing approaches.

Developers inevitably make human errors while coding. These errors can lead to faults in code, some of which may result in system failures. It is important to reduce the faults inserted by developers as well as fix any that slip through. To investigate the fault insertion and fault fixing activities of developers. We identify developers who insert and fix faults, ask whether code topic ‘experts’ insert fewer faults, and experts fix more faults and whether patterns of insertion and fixing change over time. We perform a time-based analysis of developer activity on twelve Apache projects using Latent Dirichlet Allocation (LDA), Network Analysis and Topic Modelling. We also build three models (using Petri-net, Markov Chain and Hawkes Processes) which describe and simulate developers’ bug-introduction and fixing behaviour. We show that: the majority of the projects we analysed have developers who dominate in the insertion and fixing of faults; Faults are less likely to be inserted by developers with code topic expertise; Different projects have different patterns of fault inserting and fixing over time. We recommend that projects identify the code topic expertise of developers and use expertise information to inform the assignment of project work.

Contact tracing mobile applications have been emerging as potentially automating surveillance technology to help stem the spread of the novel coronavirus (SARS-COV-2) by tracking individuals and those they come into exposure with. The avalanche of these apps left the software security researchers’ with concerns about vulnerabilities in hastily written software. On the other hand, the COVID-19 pandemic has motivated the recent interest of leveraging blockchain for healthcare-related scenarios, including proposing and developing blockchain-based contact tracing apps. Utilizing the cryptographic concepts of blockchain to secure the collected data could help in winning the level of public engagement required to fight the spread of COVID-19. But will blockchain be a panacea to all the challenges accompanying these apps? Motivated by answering this question and following a twofold process, this paper: (i) explores the current landscape of contact tracing mobile apps, (ii) examines how blockchain technology can contribute positively to this landscape, and (iii) reports on the technical and social challenges that still accompany the deployment of blockchain-based contact tracing apps.

Context: The vast majority of software engineering research is reported independently of the application domain: techniques and tools usage is reported without any domain context. As reported in previous research, this has not always been so: early in the computing era, the research focus was frequently application domain specific (for example, scientific and data processing).

The practice of refactoring has evolved over the past thirty years to become standard developer practice; for almost the same amount of time, proposals for measuring object-oriented cohesion have also been suggested. Yet, we still know very little about their inter-relationship empirically, despite the fact that classes exhibiting low cohesion would be strong candidates for refactoring. In this paper, we use a large set of refactorings to understand the characteristics of two cohesion metrics from a refactoring perspective. Firstly, through the well-known LCOM metric of Chidamber and Kemerer and, secondly, the C3 metric proposed more recently by Marcus et al. Our research question is motivated by the premise that different refactorings will be applied to classes with low cohesion compared with those applied to classes with high cohesion. We used three open-source systems as a basis of our analysis and on data from the lower and upper quartiles of metric data. Results showed that the set of refactoring types across both upper and lower quartiles was broadly the same, although very different in actual numbers. The `rename method' refactoring stood out from the rest, being applied over three times as often to classes with low cohesion than to classes with high cohesion.

The severity of the glaucoma eye disease is usually measured by the Advanced Glaucoma Intervention Studies (AGIS) metric. The metric provides a value between zero and twenty inclusive, where the former represents no evidence of glaucoma and the latter the most advanced of measurements. In a previous study by Montolio et al., the season in which the test was undertaken was shown to affect the value of eye measurements; the lowest sensitivity was found in Summer and the highest sensitivity found in Winter and Spring. In this paper, we partially replicate that study with a different set of data from 2468 patients obtained from Moorfields Eye Hospital, London. We decomposed the data according to the four seasonal dates to determine if extra sensitivity meant that patients' results improved in Winter.

Background: Refactoring has matured over the past twenty years to become part of a developer's toolkit. However, many fundamental research questions still remain largely unexplored. Aim: The goal of this paper is to investigate the highest and lowest quartile of refactoring-based data using two coupling metrics - the Coupling between Objects metric and the more recent Conceptual Coupling between Classes metric to answer this question. Can refactoring trends and patterns be identified based on the level of class coupling? Method: In this paper, we analyze over six thousand refactoring operations drawn from releases of three open-source systems to address one such question. Results: Results showed no meaningful difference in the types of refactoring applied across either lower or upper quartile of coupling for both metrics; refactorings usually associated with coupling removal were actually more numerous in the lower quartile in some cases. A lack of inheritance-related refactorings across all systems was also noted. Conclusions: The emerging message (and a perplexing one) is that developers seem to be largely indifferent to classes with high coupling when it comes to refactoring types - they treat classes with relatively low coupling in almost the same way.

A fundamental goal of software engineering practice is to ensure that code quality is maintained throughout its lifetime. Measuring and maintaining the quality of test code should be as important as measuring production (in-the-field) code. However, test code often seems to be a second class citizen compared to production code in terms of its upkeep and general maintenance. Many of the code features we might expect in test code are either absent or, included when they should not be. In this paper, we investigate four releases of an industrial embedded multi-core system from four perspectives and compare results for test code with corresponding production code. The four perspectives we considered as indicators of code quality. Firstly, we looked at whether test and production code conformed to a set of in-house designated design rules. Secondly, we explored whether test code contained a reasonable proportion of comment to code lines ratio relative to production code. Thirdly, we examined test and production code and the number of assertions in that code. Finally we investigated the relationship between faults and code features. In terms of results, test code did not fare well when compared with production code. An interesting and startling result related to the use of assertions, they were used liberally in test and production code. However, their effect, if triggered, was much larger in production code.

Similar to other industries, the software engineering domain is plagued by psychological diseases such as burnout, which lead developers to lose interest, exhibit lower activity and/or feel powerless. Prevention is essential for such diseases, which in turn requires early identification of symptoms. The emotional dimensions of Valence, Arousal and Dominance (VAD) are able to derive a person's interest (attraction), level of activation and perceived level of control for a particular situation from textual communication, such as emails. As an initial step towards identifying symptoms of productivity loss in software engineering, this paper explores the VAD metrics and their properties on 700,000 Jira issue reports containing over 2,000,000 comments, since issue reports keep track of a developer's progress on addressing bugs or new features. Using a general-purpose lexicon of 14,000 English words with known VAD scores, our results show that issue reports of different type (e.g., Feature Request vs. Bug) have a fair variation of Valence, while increase in issue priority (e.g., from Minor to Critical) typically increases Arousal. Furthermore, we show that as an issue's resolution time increases, so does the arousal of the individual the issue is assigned to. Finally, the resolution of an issue increases valence, especially for the issue Reporter and for quickly addressed issues. The existence of such relations between VAD and issue report activities shows promise that text mining in the future could offer an alternative way for work health assessment surveys.

Issue tracking systems store valuable data for testing hypotheses concerning maintenance, building statistical prediction models and (recently) investigating developer affectiveness. For the latter, issue tracking systems can be mined to explore developers emotions, sentiments and politeness---affects for short. However, research on affect detection in software artefacts is still in its early stage due to the lack of manually validated data and tools.

In this paper, we present an analysis of more than 500 K comments from open-source repositories of software systems developed using agile methodologies. Our aim is to empirically determine how developers interact with each other under certain psychological conditions generated by politeness, sentiment and emotion expressed within developers’ comments. Developers involved in an open-source projects do not usually know each other; they mainly communicate through mailing lists, chat, and tools such as issue tracking systems. The way in which they communicate affects the development process and the productivity of the people involved in the project. We evaluated politeness, sentiment and emotions of comments posted by agile developers and studied the communication flow to understand how they interacted in the presence of impolite and negative comments (and vice versa ). Our analysis shows that “firefighters” prevail. When in presence of impolite or negative comments, the probability of the next comment being impolite or negative is 13 % and 25 %, respectively; ANGER however, has a probability of 40 % of being followed by a further ANGER comment. The result could help managers take control the development phases of a system, since social aspects can seriously affect a developer’s productivity. In a distributed agile environment this may have a particular resonance.

Human Affectiveness, i.e., The emotional state of a person, plays a crucial role in many domains where it can make or break a team's ability to produce successful products. Software development is a collaborative activity as well, yet there is little information on how affectiveness impacts software productivity. As a first measure of this impact, this paper analyzes the relation between sentiment, emotions and politeness of developers in more than 560K Jira comments with the time to fix a Jira issue. We found that the happier developers are (expressing emotions such as JOY and LOVE in their comments), the shorter the issue fixing time is likely to be. In contrast, negative emotions such as SADNESS, are linked with longer issue fixing time. Politeness plays a more complex role and we empirically analyze its impact on developers' productivity.

We present an analysis of the evolution of a Web application project developed with object-oriented technology and an agile process. During the development we systematically performed measurements on the source code, using software metrics that have been proved to be correlated with software quality, such as the Chidamber and Kemerer suite and Lines of Code metrics. We also computed metrics derived from the class dependency graph, including metrics derived from Social Network Analysis. The application development evolved through phases, characterized by a different level of adoption of some key agile practices — namely pair programming, test-based development and refactoring. The evolution of the metrics of the system, and their behavior related to the agile practices adoption level, is presented and discussed. We show that, in the reported case study, a few metrics are enough to characterize with high significance the various phases of the project. Consequently, software quality, as measured using these metrics, seems directly related to agile practices adoption.