In recent years, blockchain technology has seen significant practical growth, yet it has not seen the same advancement from a theoretical perspective. This has led to the creation of numerous blockchains that are very different from each other and behave like isolated worlds. The research and development of theoretical frameworks, which define the fundamental properties of blockchains and define standards to follow for a more homogeneous implementation approach, have become extremely important. A theoretical model can help not only to design blockchains in the future but also to define a set of minimum requirements to be met for the creation of interoperability protocols between existing blockchains. In this work, we propose a theoretical model of blockchain that describes its most significant properties. Starting from our theoretical model, we present Smart Listeners , a blockchain interoperability protocol that finalises an inter-chain transaction with just two transactions: one on the source blockchain and one on the destination blockchain. The protocol is optimistic since changes on the source blockchain occur as if inter-chain transactions were successful. It is hybrid since it combines some properties of watchtowers and oracles in the off-chain components. We provide a benchmark on the performance of the proposed protocol in terms of latency and transactions per second. Finally, we define the minimum requirements that a blockchain should satisfy to allow the application of general-purpose interoperability protocols.

Abstract In this paper, we investigate the strategies adopted by Solidity developers to fix security vulnerabilities in smart contracts. Vulnerabilities are categorized using the DASP TOP 10 taxonomy, and fixing strategies are extracted from 364 commits collected from open-source Solidity projects on GitHub. Each commit was selected through a two-phase process: an initial filter using natural language processing techniques, followed by manual validation. We assessed whether these fixes adhere to established academic guidelines. Our analysis shows that 60.55% of the commits aligned with at least one literature-based recommendation, particularly for well-documented vulnerability types such as Reentrancy and Arithmetic. However, adherence dropped significantly for categories like Denial of Service, Time Manipulation, and Bad Randomness, highlighting gaps between academic best practices and real-world developer behavior. From the remaining 143 non-aligned commits, we identified 27 novel fixing strategies not previously discussed in the literature. To evaluate their quality, we conducted a structured questionnaire involving 9 experts from both academia and industry. Their feedback indicated high perceived effectiveness of the new fixes, especially for vulnerabilities like Reentrancy and Unchecked Return Values. Generalizability received more varied responses, suggesting context-specific applicability. Finally, we performed a post-fix evolution analysis on over 6700 subsequent commits to assess the long-term stability of the fixes. Most patches remained unchanged, confirming their persistence in production code. Our findings offer practical insights into how vulnerabilities are fixed in smart contracts today, reveal promising emerging patterns, and help bridge the gap between academic guidelines and developer practices.

As blockchain systems grow in complexity, secure and efficient smart contract development remains a crucial challenge. Large Language Models (LLMs) like DeepSeek promise significant enhancements in developer productivity through automated code generation, debugging, and testing. This study focuses on Solidity, the dominant language for Ethereum smart contracts, where correctness, gas efficiency, and security are critical to real-world adoption. This study evaluates the capabilities of DeepSeek’s V3 and R1 models, a non-reasoning Mixture-of-Experts architecture and a reasoning-based model trained via reinforcement learning, respectively, in automating Solidity contract generation and testing, as well as identifying and fixing common vulnerabilities. We designed a controlled experimental framework to evaluate both models by generating and analysing a diverse set of smart contracts, including standardised tokens (ERC20, ERC721, ERC1155) and real-world application scenarios (Supply Chain, Token Exchange, Auction). The evaluation is grounded on a multidimensional metric suite covering quality, technical robustness and process characteristics. Vulnerability detection and patching capabilities are tested using predefined vulnerable contracts and guided patch prompts. The analysis spans six levels of prompt complexity and compares the impact of reasoning-based and non-reasoning-based generation strategies. Findings reveal that R1 delivers more accurate and optimised outputs under high complexity, while V3 performs more consistently in simpler tasks with simpler code structures. However, both models exhibit persistent hallucinations, limitations in vulnerability coverage, and inconsistencies due to prompt formulation. The correlation between re-evaluation patterns and output quality suggests that reasoning helps in complex scenarios, although excessive revisions may lead to over-engineered or unstable solutions. Neither model is robust enough to autonomously generate issue-free smart contracts in complex or security-critical scenarios, underscoring the need for human oversight. These findings highlight best practices for integrating LLMs into blockchain development workflows and emphasise the importance of aligning model selection with task complexity and security requirements.

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.

Motivation: Local energy communities represent a compelling use case for Blockchain-based Information Systems (BISs), where mutually distrusting participants must share and verify energy data without relying on centralized authorities. However, integrating real-time IoT monitoring, photovoltaic (PV) generation modeling, and blockchain infrastructures raises challenges of scalability, governance, transparency, and data management. Objective: This study investigates the design of a BIS that integrates IoT-based energy monitoring, PV system simulation, and blockchain transaction management to provide a transparent, efficient, and fair framework for decentralized energy communities. Methods: This study presents a framework design and validation methodology that combines empirical monitoring with simulation-based assessment. Real household electricity consumption was monitored over six days using smart meters interfaced through MQTT to a Raspberry Pi. Photovoltaic generation was simulated using PVsyst with site-specific meteorological data 1642 kWh/m 2 . Energy surplus scenarios were modeled by combining measured consumption with simulated PV output and submitted to a Hyperledger Fabric network to measure transaction performance. Multiple blockchain platforms were evaluated against latency, throughput, energy overhead, and cost metrics. Results: Measured blockchain performance on operational hardware shows permissioned networks with PBFT consensus achieve 2 . 35 ± 0 . 11 second latency and 0 . 99 ± 0 . 07 % energy overhead for 10-household communities. Simulated PV optimization demonstrates that 35° panel tilt increases annual yield by 15.9% over a horizontal baseline (3877 kWh/year baseline; 4495 kWh/year optimised) with 75.1% performance ratio. Infrastructure costs are measured at 240 EUR/household for the validated 10-household baseline and projected to scale to 40 EUR/household at 60-household deployments through fixed cost distribution, with intermediate validation through Hyperledger Caliper simulations confirming sub-linear latency scaling to 20 households (2.68 ± 0.18 s). The 10-household configuration represents a pilot-scale baseline for controlled validation, with demonstrated architectural scalability through simulation. The framework validation demonstrates technical feasibility and quantifies design trade-offs in consensus selection, data management, and system optimization. Conclusion: This work contributes a reproducible validation framework for blockchain-based energy management systems, validated through controlled component testing prior to field deployment. The methodology addresses scalability, governance, and transparency challenges while offering practical design guidelines for implementing fair and efficient local energy communities.

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.

This article focuses on the concept of blockchain soulbound tokens, their potential applications, and their implementation in Ethereum-based blockchains. Soulbound tokens add an important piece to blockchain technology, as they could be the key to building Web3 and a trustworthy decentralized society. Issued and strictly linked to an account, representing the soul of a user, the soulbound token makes it possible to represent a property that only the user can have and that cannot be transferred, but only removed, which enhances security. To evaluate their impact on blockchain development, we first examine the concept of soulbound tokens, their potential applications, and their effective adoption. The application sectors include the creation of digital identity certificates, ownership certificates, reputational certificates, governance, and the healthcare sector. We then report and describe relevant blockchain token standards, including soulbound token standards, provided in the form of Ethereum Improvement Proposals. Finally, to study the efficacy of the implementation of soulbound tokens, we propose a case study that includes the design and development of a decentralized vaccine certification prototype based on soulbound tokens. In our system, the vaccination data produced by the health authority is fully decentralized and implemented as the issuance of soulbound tokens for the benefit of a citizen’s soul account. As a result, the citizen is the only owner of the vaccination data.

Smart contracts have played a pivotal role in the evolution of blockchains and Decentralized Applications (DApps). As DApps continue to gain widespread adoption, multiple smart contract languages have been and are being made available to developers, each with its distinctive features, strengths, and weaknesses. In this paper, we examine the smart contract languages used in major blockchain platforms, with the goal of providing a comprehensive assessment of their main properties. Our analysis targets the programming languages rather than the underlying architecture: as a result, while we do consider the interplay between language design and blockchain model, our main focus remains on language-specific features such as usability, programming style, safety and security. To conduct our assessment, we propose an original benchmark which encompasses a wide, yet manageable, spectrum of key use cases that cut across all the smart contract languages under examination. • We give an abstract overview of smart contract platforms, discussing the impact of different design choices. • We illustrate by examples how different design choices give rise to different programming styles for smart contracts. • We consider 6 leading smart contract languages: Solidity (Ethereum), Rust (Solana), Aiken (Cardano), PyTeal (Algorand), Move (Aptos), SmartPy (Tezos). • We develop an open-source benchmark of use cases of smart contracts, implemented in all the languages in our selection. • Based on our benchmark, we evaluate smart contract languages focussing on their security, code readability, usability, and functionalities.

Context: Crypto-agility, a name that stems from agile methodologies for software development, means the ability to modify quickly and securely cryptographic algorithms in the event of a compromise. The advent of quantum computing poses existential threats to current cryptography, having the power to breach current cryptography systems. Objective: We investigated whether and to what extent agile practices for software development are suited to support crypto-agility, or not. In particular, we discuss their usefulness in the context of substituting current algorithms with quantum-resistant ones. Method: First, we analyzed the literature to define a subset of 15 agile practices potentially relevant to cryptographic software development. Then, we developed a questionnaire to assess the suitability of agile practices for obtaining crypto-agility. We performed a Web search of relevant documents about crypto-agility and quantum resistance and sent their authors the questionnaire. We also sent the questionnaire to cybersecurity officers of four Italian firms. We analyzed and discussed the responses to 32 valid questionnaires. Results: The respondents’ affiliations are evenly distributed between researchers and developers. Most of them are active, or somehow active, in quantum-resistant cryptography and use agile methods. Most of the agile practices are deemed to be quite useful, or very useful to get crypto-agility, the most effective being Continuous Integration and Coding Standards; the least appreciated is Self-organizing Team. Conclusion: According to researchers and developers working in the field, the safe transition of cryptographic algorithms to quantum-resistant ones can benefit from the adoption of many agile practices. Further software engineering research is needed to integrate agile practices in more formal cryptographic software development processes.

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.

Blockchain-based Information Ecosystems (BBIEs) are a type of information ecosystem in which blockchain technology is used to provide a trust mechanism among parties and to manage shared business logic, breaking the traditional scheme of Information Ecosystems dominated by a leading company and leveraging the decentralization of data management, information flow, and business logic. In this paper, we propose architecture and technical aspects concerning creating a BBIE, underlining the advantages supplied and the logic decomposition among the business and storage components. The requirements are derived from the current needs of the collaborative business and the data collected by surveying practitioners. To get these needs we followed the Grounded Theory research approach. We validate our architectural schema against a case study on managing a wine supply chain–involving different companies and supervision authorities. The proposed solution integrates blockchain-based applications with the existing information system as a module of the ecosystem, leveraging on the low costs, scalability, and high-level security because of the restricted access to the network. We must go a long way in deepening and refining the possibilities offered by technology in supporting innovative multi-organizational business models. BBIEs can contribute substantially to paving the way in such a direction.

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.

Solana is a public blockchain platform, launched in April 2018, that aims to increase scalability when compared to other blockchains without compromising decentralization and security. It supports smart contracts and the creation of decentralized applications (DApps). The study aims to collect data from the Solana blockchain and verify some of its properties such as its transactions' throughput, i.e. the rate at which valid transactions are committed into a block by the Solana blockchain during a one second interval of time (TPS). The data were collected over the period of two months (14 October - 15 December) and made public on a GitHub repository. The results of our data analysis show how the average transactions' throughput is about 2812 TPS and that the fees paid by users to have the transactions confirmed are on average much lower than the fees users pay for other blockchains that support the same functions, such as smart contract and the creation of DApps. The paper sheds light on the mechanisms of Solana blockchain that, according to their founders, promises to solve the scalability problem without sacrificing decentralization and security.

We discuss the contribution of the Petri net formalism to the BOSE for Smart Contract design and development. We address this discussion based on the analysis of recently published literature works we obtained by querying Scopus and Google Scholar. Different types of Petri nets, including coloured Petri nets and workflow nets, and different types of tools emerge from our analysis. Our discussion includes the classification into three categories of application of the Petri net formalism in the design and development of Smart Contracts, namely modeling, generation, and verification.

Blockchain and the programs running on it, called smart contracts, are increasingly applied in all fields where trust and strong certifications are required. Our work focuses on industrial applications of blockchains and not on cryptocurrencies or tokens. We use frameworks to compare public and permissioned blockchains specifically suited for industrial applications. We also propose a complete solution based on Ethereum to implement a decentralized application, putting together in an original way, components and patterns already used and proven. This solution is characterized by a set of validator nodes running the blockchain using Proof-of-Authority or similar efficient consensus algorithms, by the use of an explorer enabling users to check the blockchain state, and the source code of the smart contracts running on it. From time to time, the hash digest of the last mined block is written into a public blockchain to guarantee immutability. The right to send transactions is granted by validator nodes to users by endowing them with the Ethers mined locally. Overall, the proposed approach has the same transparency and immutability as a public blockchain, largely reducing its drawbacks.

This paper presents a first investigation to join agile blockchain-oriented software development principles with sustainability software design principles. The development of blockchain-oriented software should always be performed in the awareness of the potential effects generated from its use, especially in a long-term life cycle perspective. In other terms in the awareness of its present and future sustainability. By using the principles of sustainability software design and recognized the role of blockchain-oriented Agile methodologies to manage changes in technology and requirements, we present a new Agile method for the development of blockchain-oriented systems that includes sustainability awareness practices within the development phases, in particular in the requirements and the acceptance tests. This allows to deal with blockchain-oriented systems sustainability immediately and during the incremental and iterative development process. The paper describes the process in its phases and provides an example of an application to the supply chain sector.

The practice of writing smart contracts for the Ethereum blockchain is quite recent and still in development. A blockchain developer should expect constant changes in the security software field, as new bugs and security risks are discovered, and new good practices are developed. Following the security practices accepted in the blockchain community is not enough to ensure the writing of secure smart contracts. The paper aims to study the practice of code cloning among the smart contracts by analyzing two corpora. The first corpus, the "Smart-Corpus", includes smart contracts already deployed in the Ethereum blockchain. The second corpus, the "Open-Zeppelin's Solidity Library", is supervised by a community of developers who constantly take care to increase the security and efficiency of the smart contracts included in the corpus. From the comparative analysis of the corpora, we observe that the smart contracts developers frequently duplicate the code by cloning already existing smart contracts which are not part of the "OpenZeppelin corpus". In particular, we found that 79.1% of smart contracts contain duplicated code and only 18.4% of smart contracts reuse the code by implementing a smart corpus belonging to the OpenZeppelin repository. The paper discusses the advantages and the disadvantages of code duplication in the Ethereum blockchain ecosystem, and suggests to refer to the smart contracts of the OpenZeppelin's Solidity Library. The Ethereum blockchain community can indeed benefit from using the tested code presented in OpenZeppelin's Solidity Library to increase its security.

Summary This article proposes a blockchain oriented platform to guarantee the origin and provenance of food items in a Smart Tourism Region context. Local food and beverage, in fact, can become a good combination to attract tourist and to promote the area provided that their provenance is clearly certified. We designed and developed a blockchain‐based system to manage an agri‐food supply chain for tracking food items. By using smart contracts the platform guarantees transparency, efficiency and trustworthiness. Our system is particularly suitable to manage cold chain since the system interfaces with IoT network devices providing detailed information about data monitoring food such as storage temperature, environment humidity, and GPS data. All involved actors can share data and information in a more efficient, transparent, and tamper proof way than traditional systems. The final consumer can access with transparency to all the agri‐food chain of the purchased product and verify provenance by retrieving all detailed information registered in the blockchain public ledger. The proposed system has been designed according to the ABCDE method, an agile development process recently conceived, to obtain a higher software quality to design a general blockchain system by means software engineering practices. A real case study applied to local products from Sardinia, Italy, is proposed at the end of the article.

Blockchain software development is becoming more and more important for any modern software developer and IT startup. Nonetheless, blockchain software production still lacks a disciplined, organized and mature development process, as demonstrated by the many and (in)famous failures and frauds occurred in recent years. In this paper we present ABCDE, a complete method addressing blockchain software development. The method considers the software integration among the blockchain components—smart contracts, libraries, data structures—and the out-of-chain components, such as web or mobile applications, which all together constitute a complete DApp system. We advocate for ABCDE the use of agile practices, because these are suited to develop systems whose requirements are not completely understood since the beginning, or tend to change, as it is the case of most blockchain-based applications. ABCDE is based on Scrum, and is therefore iterative and incremental. From Scrum, we kept the requirement gathering with user stories, the iterative-incremental approach, the key roles, and the meetings. The main difference with Scrum is the separation of development activities in two flows—one for smart contracts and the other for out-of-chain software interacting with the blockchain—each performed iteratively, with integration activities every 2–3 iterations. ABCDE makes explicit the activities that must be performed to design, develop, test and integrate smart contracts and out-of-chain software, and documents the smart contracts using formal diagrams to help development, security assessment, and maintenance. A diagram derived from UML class diagram helps to effectively model the data structure of smart contracts, whereas the exchange of messages between the entities of the system is modeled using a modified UML sequence diagram. The proposed method has also specific activities for security assessment and gas optimization, through systematic use of patterns and checklists. ABCDE focuses on Ethereum blockchain and its Solidity language, but preserves generality and with proper modifications might be applied to any blockchain software project. ABCDE method is described in detail, and an example is given to show how to concretely implement the various development steps.

In a previous empirical study by Bavota et al., multiple releases of three open-source systems reported the extent to which refactorings induced defect-fixes. In a much earlier study, van Deursen and Moonen (vD&M) provided a test taxonomy in which Fowler's seventy-two refactorings were categorized according to the post refactoring test burden of each (i.e., the changes required to unit tests after each refactoring had been undertaken). A refactoring was categorized as 'Type B' if it required no change to the original tests and 'Type E' if significant changes were necessary. In this paper, we investigate nine refactorings spread across vD&M's taxonomy and the corresponding defect-fix data provided by Bavota et al., to explore the relationship between defect-fixes due to refactoring and vD&M's taxonomy. Results showed that, in contrast to our intuition, the most defect-fix prone refactorings were of Types C and D and not, as we thought, of Type E. The 'Extract method' refactoring stood out as particularly 'defect-fix' inducing, suggesting that while it may solve one problem (i.e., in decomposing an excessively long method), it may well introduce other problems and required defect-fixes as a by-product.

A Blockchain is a global shared infrastructure where cryptocurrency transactions among addresses are recorded, validated and made publicly available in a peer-to-peer network. To date, the best known and important cryptocurrency is the bitcoin. In this paper, we focus on this cryptocurrency and in particular on the modeling of the Bitcoin Blockchain by using the Petri Nets formalism. The proposed model allows us to quickly collect information about identities owning Bitcoin addresses and to recover measures and statistics on the Bitcoin network. By exploiting algebraic formalism, we reconstructed an Entities network associated to Blockchain transactions gathering together Bitcoin addresses into the single entity holding permits to manage Bitcoins held by those addresses. The model allows also to identify a set of behaviors typical of Bitcoin owners, like that of using an address only once, and to reconstruct chains for this behavior together with the rate of firing. Our model is highly flexible and can easily be adapted to include different features of the Bitcoin cryptocurrency system. By exploiting algebraic formalism, we reconstructed an Entities network associated to Blockchain transactions gathering together Bitcoin addresses into the single entity holding permits to manage Bitcoins held by those addresses. The model allows also to identify a set of behaviors typical of Bitcoin owners, like that of using an address only once, and to reconstruct chains for this behavior together with the rate of firing. Our model is highly flexible and can easily be adapted to include different features of the Bitcoin cryptocurrency system.

We present a study of 600 Java software networks with the aim of characterizing the relationship among their defectiveness and community metrics. We analyze the community structure of such networks, defined as their topological division into subnetworks of densely connected nodes. A high density of connections represents a higher level of cooperation between classes, so a well-defined division in communities could indicate that the software system has been designed in a modular fashion and all its functionalities are well separated. We show how the community structure can be an indicator of well-written, high quality code by retrieving the communities of the analyzed systems and by ranking their division in communities through the built-in metric called modularity. We found that the software systems with highest modularity possess the majority of bugs, and tested whether this result is related to some confounding effect. We found two power laws relating the maximum defect density with two different metrics: the number of detected communities inside a software network and the clustering coefficient. We finally found a linear correlation between clustering coefficient and number of communities. Our results can be used to make predictive hypotheses about software defectiveness of future releases of the analyzed systems.

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.

In this work we present an empirical study on the use of inheritance in a curated corpus of Python systems. Replicating a study preformed on Java, we analyzed a collection of 51 software systems written in Python, and investigated how inheritance is effectively used by Python developers in practice through a convenient set of inheritance metrics. Our results suggest that on average fewer classes inherit from other classes than in Java, but more classes are inherited from. We also see a sort of symmetry relating the number of ancestors and the number of descendants in each system.

WETSoM is a gathering of researchers and practitioners to discuss the progress on software metrics knowledge. Motivations for this workshop include the low impact that software metrics have on current software development and the increased interest in research. The goals of this workshop include critically examining the evidence for the effectiveness of existing metrics and identifying new directions for metrics. Evidence for existing metrics includes how the metrics have been used in practice and studies showing their effectiveness. Identifying new directions includes use of new theories, such as complex network theory, on which to base metrics.

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.

A fundamental aspect of a system's performance over time is the number of faults it generates. The relationship between the software engineering concept of "coupling" (i.e., the degree of inter-connectedness of a system's components) and faults is still a research question attracting attention and a relationship with strong implications for performance; excessive coupling is generally acknowledged to contribute to fault-proneness. In this paper, we explore the relationship between faults and coupling. Two releases from each of three open-source Eclipse projects (six releases in total) were used as an empirical basis and coupling and fault data extracted from those systems. A contrasting coupling profile between fault-free and fault-prone classes was observed and this result was statistically supported. Object-oriented (OO) classes with low values of fan-in (incoming coupling) and fan-out (outgoing coupling) appeared to support fault-free classes, while classes with high fan-out supported relatively fault-prone classes. We also considered size as an influence on fault-proneness. The study thus emphasizes the importance of minimizing coupling where possible (and particularly that of fan-out); failing to control coupling may store up problems for later in a system's life; equally, controlling class size should be a concomitant goal.

The term "software entropy" refers to the tendency for software, over time, to become difficult and costly to maintain. A software system that undergoes continuous change, such as having new functionality added to its original design, will eventually become more complex and can become disorganized as it grows, losing its original design structure. A recent study show that software degradation may be measured using the WMC expressed in terms of Shannon entropy. In this paper we extended the empirical analyses also to RFC and CBO since these CK metrics have been shown to be correlated with fault-proneness of OO classes. We analyzed various releases of the publicly available Eclipse and Netbeans software systems, calculating the entropy of some CK metrics for every release analyzed. The validity is shown through a direct measure of software quality such as the number of detected defects. Our results display a very good correlation between the entropy of CBO and RFC and the number of bugs for Eclipse and Netbeans. Complexity and quality metrics are in general computed on every system module while the entropy is just a scalar number that characterizes a whole system, this result suggests that the entropy of some CK metrics could be considered as a global quality metric for large software systems. Our results need, however, to be confirmed for other large software systems.

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.

The distribution of bugs in software systems has been shown to satisfy the Pareto principle, and typically shows a power-law tail when analyzed as a rank-frequency plot. In a recent paper, Zhang showed that the Weibull cumulative distribution is a very good fit for the Alberg diagram of bugs built with experimental data. In this paper, we further discuss the subject from a statistical perspective, using as case studies five versions of Eclipse, to show how log-normal, Double-Pareto, and Yule-Simon distributions may fit the bug distribution at least as well as the Weibull distribution. In particular, we show how some of these alternative distributions provide both a superior fit to empirical data and a theoretical motivation to be used for modeling the bug generation process. While our results have been obtained on Eclipse, we believe that these models, in particular the Yule-Simon one, can generalize to other software systems.

We studied data mining from CVS repositories of two large OO projects, Eclipse and Netbeans, focusing on "fixing-issue" commits.

We analyze the process of software development for large, object oriented, open source software systems. Such systems may be described as complex networks when suitable variables are properly identified. In particular we model the system growth through a Yule process which enable us to fit data extracted from freely available repositories. We consider quantities related to relevant properties of the software system itself, like methods names, instance variable names, number of subclasses of each class. As opposite to a plain analysis of a final product, we perform a dynamic analysis of the product evolution, since we look at how system properties change during the development along different releases. The final goal is to detect statistical features that may be related to software dependability.