Abstract Self-Admitted Technical Debt (SATD) refers to technical compromises explicitly admitted by developers in natural language artifacts, such as code comments, commit messages, and issue trackers. Among its types, Architecture Technical Debt (ATD) is particularly difficult to detect due to its abstract and context-dependent nature. Manual annotation of ATD is costly, time-consuming, and challenging to scale. To reduce labeling effort, this study combines keyword-based filtering, active learning, and explainable AI for ATD detection. We refined an existing dataset of ATD-related Jira issues to obtain an expert-validated seed set used to extract representative keywords. These keywords were then applied to identify more than 103k candidate issues across 10 open-source projects. To assess the reliability of keyword-based filtering, we qualitatively evaluated a statistically representative sample of labeled issues. Building on the resulting dataset, we applied active learning with multiple query strategies to prioritize informative samples for annotation. The results show that Breaking Ties achieved the best performance, with an F1-score of 0.72 and a 49% reduction in annotation effort. To improve transparency, we used SHAP and LIME to explain ATD classification results. Expert evaluation showed that both methods provided useful explanations, with LIME generally preferred for its clarity and ease of use.

Context: Artificial intelligence (AI) techniques, particularly natural language processing (NLP) and machine learning (ML), are increasingly used to support source code understanding, an essential activity in software engineering. Objective: This systematic mapping study investigates how these techniques are applied, guided by four Research Questions (RQs) focusing on the types of tasks, embedding methods & preprocessing techniques used, machine learning models employed, and existing research gaps. Methods: A review of 227 peer-reviewed studies identifies trends and provides a structured mapping addressing each RQ. Results: The findings reveal a dominant shift toward deep learning, especially transformer-based and graph-based models, highlighting underexplored areas such as explainability. Conclusion: This study provides a task-based classification and offers insights and directions for future research in AI-enabled source code understanding, supporting both researchers and practitioners.

The VT legacy system, comprising approximately 2.5 million lines of PL/SQL code, lacks consistent documentation and automated tests, posing significant challenges for refactoring and modernisation. This study investigates the feasibility of leveraging large language models (LLMs) to assist in translating PL/SQL code into Java for the modernised "VTF3" system. By leveraging a dataset comprising 10 PL/SQL-to-Java code pairs and 15 Java classes, which collectively established a domain model for the translated files, multiple LLMs were evaluated. Furthermore, we propose a customized prompting strategy that integrates chain-of-guidance reasoning with n-shot prompting. Our findings indicate that this methodology effectively guides LLMs in generating syntactically accurate translations while also achieving functional correctness. However, the findings are limited by the small sample size of available code files and the restricted access to test cases used for validating the correctness of the generated code. Nevertheless, these findings lay the groundwork for scalable, automated solutions in modernising large legacy systems.

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.

Architectural technical debt (ATD) represents trade-offs in software architecture that accelerate initial development but create long-term maintenance challenges. ATD, in particular when self-admitted, impacts the foundational structure of software, making it difficult to detect and resolve. This study investigates the lifecycle of ATD, focusing on how it affects i) the connectivity between classes and ii) the frequency of file modifications. We aim to understand how ATD evolves from introduction to repayment and its implications on software architectures. Our empirical approach was applied to a dataset of SATD items extracted from various software artifacts. We isolated ATD instances, filtered for architectural indicators, and calculated dependencies at different lifecycle stages using FAN-IN and FAN-OUT metrics. Statistical analyses, including the Mann-Whitney U test and Cliff's Delta, were used to assess the significance and effect size of connectivity and dependency changes over time. We observed that ATD repayment increased class connectivity, with FAN-IN increasing by 57.5% on average and FAN-OUT by 26.7%, suggesting a shift toward centralization and increased architectural complexity after repayment. Moreover, ATD files were modified less frequently than Non-ATD files, with changes accumulated in high-dependency portions of the code. Our study shows that resolving ATD improves software quality in the short-term, but can make the architecture more complex by centralizing dependencies. Also, even if dependency metrics (like FAN-IN and FAN-OUT) can help understand the impact of ATD, they should be combined with other measures to capture other effects of ATD on software maintainability.

The presence of technical debt in legacy systems is an inevitable consequence of years of development. Metrics play a significant role in informing the prioritisation process of maintenance activities to reduce this debt. However, it is important to note that not all metrics are equally important or readily available in real industrial settings. This paper summarises an experience report of refactoring activities performed at a Dutch partnering company, aimed at identifying, prioritising and repaying parts of the architectural technical debt accumulated in two decades of development. Given the size of the refactoring task, a data-driven prioritisation was necessary, and based on the impact that the maintenance activity would have on the base system. However, the metrics available from the monitoring of the system formed a limited set, and were not always focused on architectural aspects. Even so, the impact analysis was performed and resulted in the selection of a subset of components that needed urgent maintenance. The refactoring of the identified components was centred around the well-known SOLID design principles, particularly the Dependency Inversion (DI) principle. Additionally, a set of recurring actions was established into ‘refactoring patterns’ and systematically applied to more than 5,000 source, header and custom domain language files. This work, albeit limited to the period where the activity was planned for, was well received by the industrial collaborator. The patterns have proven very valuable in the process of maintaining such a large project scope. The data-driven approach and the identified patterns have helped the team navigate this large space and consistently refactor similar architectural issues that fall under the same category. • Experience report on architectural TD : The paper reports on identifying, prioritising, and repaying 20 years of architectural Technical Debt at ASML. • Data-Driven prioritisation : The refactoring used a data-driven approach to prioritise components needing maintenance by impact. • Implementation of SOLID principles : Refactoring focused on SOLID principles, especially Dependency Inversion, to enhance code maintainability. • Refactoring patterns : The study applied recurring refactoring patterns to over 5,000 files, aiding large-scale maintenance efforts.

Code duplication across projects is a common challenge in Software Product Line (SPL) development, impacting maintainability and efficiency. This paper reports on an applied research project conducted within RDW, The Netherlands Vehicle Authority, aimed at addressing cross-project code duplication in a multi-application SPL environment. The objective of this work was to investigate the impact of refactoring cross-project duplicated code on maintainability, code reuse, and technical debt within RDW’s Electronic Services System (EDS), composed of 62 applications. We used an action research approach, focusing on two applications to identify, refactor, and package duplicated features into reusable components. SonarQube was used to detect and quantify duplication, and the effectiveness of refactoring was evaluated using code duplication reduction metrics and developer feedback. The refactoring effort led to the removal of 38% of the duplicated code on average, improving code reuse by 33%. Efficiency gains were observed in the second application due to the experience from the first intervention, reducing the time required for code maintenance and updates by 89%. While the study demonstrates that systematically addressing cross-project code duplication in SPLs improves maintainability and reduces technical debt, it also highlights a key limitation: refactoring efforts need to be undertaken early to be feasible. As the number of applications in RDW’s system steadily expanded to 80, the engineers reported that the required refactoring work, although highly beneficial, has become too extensive and time-consuming to be practical. The effort was ultimately left too late, making large-scale refactoring no longer a viable solution. Future strategies should focus on early duplication identification, architectural solutions such as modularization or microservices, and automated dependency management to prevent similar challenges from arising.

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.

Self-Admitted Technical Debt (SATD) refers to circumstances where developers use textual artifacts to explain why the existing implementation is not optimal. Past research in detecting SATD has focused on either identifying SATD (classifying SATD items as SATD or not) or categorizing SATD (labeling instances as SATD that pertain to requirement, design, code, test debt, etc.). However, the performance of these approaches remains suboptimal, particularly for specific types of SATD, such as test and requirement debt, primarily due to extremely imbalanced datasets. To address these challenges, we build on earlier research by utilizing BiLSTM architecture for the binary identification of SATD and BERT architecture for categorizing different types of SATD. Despite their effectiveness, both architectures struggle with imbalanced data. Therefore, we employ a large language model data augmentation strategy to mitigate this issue. Furthermore, we introduce a two-step approach to identify and categorize SATD across various datasets derived from different artifacts. Our contributions include providing a balanced dataset for future SATD researchers and demonstrating that our approach significantly improves SATD identification and categorization performance compared to baseline methods.

Due to the lack of standards at the time they were written, many codebases suffer from reduced code quality. Some of these systems can not be replaced and need to be maintained to guarantee the healthy development of the software. In the context of this paper, we are presenting a case study performed on the legacy codebase of ASML, a leading Dutch company specializing in the design and manufacture of advanced semiconductor lithography equipment. As new policies were enforced within the company, many specific interfaces were deprecated. The presence of such obsolete interfaces in the codebase adds to the overall complexity of the legacy system, while also permitting a future violation of the Interface Segregation Principle, one of the five SOLID design principles. The objective of this paper is to present our experience with refactoring the specified interfaces. Besides performing the clean-up, we were tasked to find an optimal, iterative, and repeatable approach to performing the clean-up of these interfaces while documenting our findings in a reproducible manner for future employees. To discover an efficient clean-up strategy, we used the Action Research methodology. Going through the “Planning”, “Acting”, “Observing” and “Reflecting” phases of this methodology repeatedly, we revised the strategy and executed our refactoring work accordingly. After multiple refactoring operations, our process stabilized and we introduced the “Cleaning-Up Cycle”. We spent less time and had fewer failures per interface as our cycle evolved, despite attempting more complex types of interfaces later. We found the Clean-Up Cycle to represent a valuable strategy when executing this type of refactoring. This was fed back to the ASML team and considered the foundation for future employees continuing our work.

Self-admitted technical debt (SATD) refers to a form of technical debt in which developers explicitly acknowledge and document the existence of technical shortcuts, workarounds, or temporary solutions within the codebase. Over recent years, researchers have manually labeled datasets derived from various software development artifacts: source code comments, messages from the issue tracker and pull request sections, and commit messages. These datasets are designed for training, evaluation, performance validation, and improvement of machine learning and deep learning models to accurately identify SATD instances. However, class imbalance poses a serious challenge across all the existing datasets, particularly when researchers are interested in categorizing the specific types of SATD. In order to address the scarcity of labeled data for SATD identification (i.e., whether an instance is SATD or not) and categorization (i.e., which type of SATD is being classified) in existing datasets, we share the SATDAUG dataset, an augmented version of existing SATD datasets, including source code comments, issue tracker, pull requests, and commit messages. These augmented datasets have been balanced in relation to the available artifacts and provide a much richer source of labeled data for training machine learning or deep learning models.

In DevOps, the traceability of software artifacts is critical to the successful development and operation of project delivery to stakeholders. Before the introduction of end-to-end traceability in DevOps at a Data Analytics team at bp (BP plc), an international integrated energy company, the tracing of artifacts throughout a project life cycle was manual and time-consuming. This changed when traceability become more automated with end-to-end traceability capability as an offering on the platform. This paper reports on the ways of working and the experience of developers implementing DevOps for developing and putting in production a Javascript React web application, with a focus on traceability management of artifacts produced throughout the life cycle. This report highlights key opportunities and challenges in traceability management from the development stage to production.

Systematic literature reviews (SLRs) and systematic mapping studies (SMSs) are common studies in any discipline to describe and classify past works, and to inform a research field of potential new areas of investigation. This last task is typically achieved by observing gaps in past works, and hinting at the possibility of future research in those gaps. Using an NLP-driven methodology, this paper proposes a meta-analysis to extend current systematic methodologies of literature reviews and mapping studies. Our work leverages a Word2Vec model, pre-trained in the software engineering domain, and is combined with a time series analysis. Our aim is to forecast future trajectories of research outlined in systematic studies, rather than just describing them. Using the same dataset from our own previous mapping study, we were able to go beyond descriptively analysing the data that we gathered, or to barely 'guess' future directions. In this paper, we show how recent advancements in the field of our SMS, and the use of time series, enabled us to forecast future trends in the same field. Our proposed methodology sets a precedent for exploring the potential of language models coupled with time series in the context of systematically reviewing the literature.

Software repository hosting services contain large amounts of open-source software, with GitHub hosting over 200 million repositories, from new to established ones. However, these repositories are not easy to find, calling for various attempts to classify their application domains automatically. However, most proposed approaches use artifacts, like README files, as a proxy for the project, losing the information in the source code and the interaction between files. Furthermore, they all focus on the project-level, ignoring the decomposition of software projects into components and modules.This work presents a weak labelling approach based on keyword extraction to annotate source files in a software project.Our findings suggest that using keywords to perform file-level annotations is an effective approach that can capture enough information from the source file so that new labels can be predicted.The long-term goal of our research is to classify source code files and use these annotations to identify semantic components in software projects. In addition, these annotations can be used for semantic reverse engineering, software reuse, and more. We plan to train machine learning models that use our proposed weak supervision to better annotate source files inside software projects.

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.

A key part of software evolution and maintenance is the continuous integration from collaborative efforts, often resulting in complex traceability challenges between software artifacts: features and modules remain scattered in the source code, and traceability links become harder to recover. In this paper, we perform a systematic mapping study dealing with recent research recovering these links through information retrieval, with a particular focus on natural language processing (NLP). Our search strategy gathered a total of 96 papers in focus of our study, covering a period from 2013 to 2021. We conducted trend analysis on NLP techniques and tools involved, and traceability efforts (applying NLP) across the software development life cycle (SDLC). Based on our study, we have identified the following key issues, barriers, and setbacks: syntax convention, configuration, translation, explainability, properties representation, tacit knowledge dependency, scalability, and data availability. Based on these, we consolidated the following open challenges: representation similarity across artifacts, the effectiveness of NLP for traceability, and achieving scalable, adaptive, and explainable models. To address these challenges, we recommend a holistic framework for NLP solutions to achieve effective traceability and efforts in achieving interoperability and explainability in NLP models for traceability.

Abstract Context GitHub is the world's most prominent host of source code, with more than 327M repositories. However, most of these repositories are not labelled or inadequately, making it harder for users to find relevant projects. Various proposals for software application domain classification over the past years have been proposed. However, these several of those approaches suffer from multiple issues, called antipatterns of software classification, that reduce their usability. Objective In this paper, we propose a new taxonomy in the GitHub ecosystem, called GitRanking, starting from a well‐structured data set, composed of curated repositories annotated with topics. The main objective is to create a baseline methodology for software classification that is expandable, hierarchical, grounded in a knowledge base, and free of antipatterns. Method We collected 121K topics from GitHub and used GitRanking to create a taxonomy of 301 ranked application domains. GitRanking (1) uses active sampling to ensure a minimal number of annotations to create the ranking; and (2) links each topic to Wikidata, reducing ambiguities and improving the reusability of the taxonomy. Furthermore, we adopt the conceived taxonomy in a classification task by considering a state‐of‐the‐art classifier. Results Our results show that GitRanking can effectively rank terms in a hierarchy according to how general or specific their meaning is. Furthermore, we show that GitRanking is a dynamically extensible method: it can currently accept further terms to be ranked, and with a minimum number of annotations (). Concerning the classification task, we show that the model achieves an F1‐score of 34%, with a precision of 54%. Conclusion This paper is the first collective attempt at building a ground‐up taxonomy of software domains. Our vision is that our taxonomy, and its extensibility, can be used to better and more precisely label software projects.

E-type open-source software inevitably grows in size and complexity over time, and without performing anti-regressive tasks this type of software has a limited lifespan. In this project, a case study of the effect of such anti-regressive tasks is conducted using Grimoire-Lab Graal as a subject. This process is guided by quality metrics and developer insights. The outcome of this work is a life-cycle of maintenance activities, ultimately resulting in a refactored version of GrimoireLab Graal. After applying anti-regressive actions, commonly used software quality metrics decreased (lower is better). Additionally, after performing an experiment to test the evolution readiness of the software, the complexity of the original software increased significantly, whilst no side effects were measured in the revised software.

Abstract Effort estimation models are a fundamental tool in software management, and used as a forecast for resources, constraints and costs associated to software development. For Free/Open Source Software (FOSS) projects, effort estimation is especially complex: professional developers work alongside occasional, volunteer developers, so the overall effort (in person-months) becomes non-trivial to determine. The objective of this work it to develop a simple effort estimation model for FOSS projects, based on the historic data of developers’ effort. The model is fed with direct developer feedback to ensure its accuracy. After extracting the personal development profiles of several thousands of developers from 6 large FOSS projects, we asked them to fill in a questionnaire to determine if they should be considered as full-time developers in the project that they work in. Their feedback was used to fine-tune the value of an effort threshold, above which developers can be considered as full-time. With the help of the over 1,000 questionnaires received, we were able to determine, for every project in our sample, the threshold of commits that separates full-time from non-full-time developers. We finally offer guidelines and a tool to apply our model to FOSS projects that use a version control system.

Empirical results in software engineering have long started to show that findings are unlikely to be applicable to all software systems, or any domain: results need to be evaluated in specified contexts, and limited to the type of systems that they were extracted from. This is a known issue, and requires the establishment of a classification of software types. This paper makes two contributions: the first is to evaluate the quality of the current software classifications landscape. The second is to perform a case study showing how to create a classification of software types using a curated set of software systems. Our contributions show that existing, and very likely even new, classification attempts are deemed to fail for one or more issues, that we named as the ‘antipatterns’ of software classification tasks. We collected 7 of these antipatterns that emerge from both our case study, and the existing classifications. These antipatterns represent recurring issues in a classification, so we discuss practical ways to help researchers avoid these pitfalls. It becomes clear that classification attempts must also face the daunting task of formulating a taxonomy of software types, with the objective of establishing a hierarchy of categories in a classification.

Component Based Software Engineering (CBSE) seeks to promote the reuse of software by using existing software modules into the development process. However, the availability of such a reusable component is not immediate and is costly and time consuming. As an alternative, the extraction from preexisting OO software can be considered.In this work, we evaluate two community detection algorithms for the task of software components identification. Considering `components' as `communities', the aim is to evaluate how independent, yet cohesive, the components are when extracted by structurally informed algorithms.We analyze 412 Java systems and evaluate the cohesion of the extracted communities using four document representation techniques. The evaluation aims to find which algorithm extracts the most semantically cohesive, yet separated communities.The results show a good performance in both algorithms, however, each has its own strengths. Leiden extracts less cohesive, but better separated, and better clustered components that depend more on similar ones. Infomap, on the other side, creates more cohesive, slightly overlapping clusters that are less likely to depend on other semantically similar components.

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).

Abstract A smart contract (SC) is a programme stored in the Ethereum blockchain by a contract‐creation transaction. SC developers deploy an instance of the SC and attempt to execute it in exchange for a fee, paid in Ethereum coins (Ether). If the computation needed for their execution turns out to be larger than the effort proposed by the developer (i.e., the gasLimit), their client instantiation will not be completed successfully. In this paper, we examine SCs from 11 Ethereum blockchain‐oriented software projects hosted on GitHub.com , and we evaluate the resources needed for their deployment (i.e., the gasUsed). For each of these contracts, we also extract a suite of object‐oriented metrics, to evaluate their structural characteristics. Our results show a statistically significant correlation between some of the object‐oriented (OO) metrics and the resources consumed on the Ethereum blockchain network when deploying SCs. This result has a direct impact on how Ethereum developers engage with a SC: evaluating its structural characteristics, they will be able to produce a better estimate of the resources needed to deploy it. Other results show specific source code metrics to be prioritised based on application domains when the projects are clustered based on common themes.

Students in higher education are traditionally requested to produce various pieces of written work during the courses they undertake. When students' work is submitted online as a whole, both the ethically questionable act of procrastinating and late submissions affect performance. The objective of this paper is to assess the performance of students from a control group, with that of students from an experimental group. The control group produced work as a unique deliverable to be submitted at the end of the course. On the other hand, the experimental group worked on each part for a week, and their work was managed by a wiki environment and monitored by a specifically developed software. Positive effects were noticed in the experimental group, as both students' time management skills and performance increased. Replications of this experiment can and should be performed, in order to compare results in coursework submission.

The evolution of software systems is an inevitable process which has to be managed effectively to enhance software quality. Change impact analysis (CIA) is a technique that identifies impact sets, i.e., the set of classes that require correction as a result of a change made to a class or artefact. These sets can also be considered as ripple effects and typically non-local: changes propagate to different parts of a system.

Software systems continuously evolve to accommodate new features and interoperability relationships between artifacts point to increasingly relevant software change impacts. During maintenance, developers must ensure that related entities are updated to be consistent with these changes. Studies in the static change impact analysis domain have identified that a combination of source code and lexical information outperforms using each one when adopted independently. However, the extraction of lexical information and the measure of how loosely or closely related two software artifacts are, considering the semantic information embedded in their comments and identifiers has been carried out using somewhat complex information retrieval (IR) techniques. The interplay between software semantic and change relationship strengths has also not been extensively studied. This work aims to fill both gaps by comparing the effectiveness of measuring semantic coupling of OO software classes using (i) simple identifier based techniques and (ii) the word corpora of the entire classes in a software system. Afterwards, we empirically investigate the interplay between semantic and change coupling. The empirical results show that: (1) identifier based methods have more computational efficiency but cannot always be used interchangeably with corpora-based methods of computing semantic coupling of classes and (2) there is no correlation between semantic and change coupling. Furthermore we found that (3) there is a directional relationship between the two, as over 70% of the semantic dependencies are also linked by change coupling but not vice versa.

Dependency-based software change impact analysis is the domain concerned with estimating the sets of artifacts impacted by a change to a related artifact. Research has shown that analysing the various class dependency types independently will never completely reveal the impact sets. Therefore, dependency types are combined to improve the precision of estimated when compared to impact sets. Software classes can be linked in different ways; for instance semantically, if their meaning is somewhat related or, structurally, if one class depends on the services of other classes. 'Hidden' dependencies arise when two classes, linked structurally, do not share the same semantic namespace or when semantically dependent classes do not share a structural link. With the goal of revealing hidden dependencies during change impact analysis, we empirically investigated the relationship between structural and semantic class dependencies in object-oriented software systems. Results show that (i) semantic and structural links are significantly associated, (ii) the strengths of those links do not play a significant role and, (iii) a significant number of dependencies are hidden. We propose two refactoring techniques to deal with hidden dependencies, based on existing design patterns. We plan to investigate them further to assert whether either has the potential for reducing refactoring and testing effort.

Context: Conceptual coupling is a measure of how loosely or closely related two software artifacts are, by considering the semantic information embedded in the comments and identifiers. This type of coupling is typically evaluated using the semantic information from source code into a words corpus. The extraction of words corpora can be lengthy, especially when systems are large and many classes are involved.

Context: Information and tracking of defects can be severely incomplete in almost every Open Source project, resulting in a reduced traceability of defects into the development logs (i.e., version control commit logs). In particular, defect data often appears not in sync when considering what developers logged as their actions. Synchronizing or completing the missing data of the bug repositories, with the logs detailing the actions of developers, would benefit various branches of empirical software engineering research: prediction of software faults, software reliability, traceability, software quality, effort and cost estimation, bug prediction and bug fixing.

Because of the distributed and collaborative nature of free / open source software (FOSS) projects, the development effort invested in a project is usually unknown, even after the software has been released. However, this information is becoming of major interest, especially ---but not only--- because of the growth in the number of companies for which FOSS has become relevant for their business strategy. In this paper we present a novel approach to estimate effort by considering data from source code management repositories. We apply our model to the OpenStack project, a FOSS project with more than 1,000 authors, in which several tens of companies cooperate. Based on data from its repositories and together with the input from a survey answered by more than 100 developers, we show that the model offers a simple, but sound way of obtaining software development estimations with bounded margins of error.

It has been suggested that the data from bug repositories is not always in sync or complete compared to the logs detailing the actions of developers on source code.

Online communities are flourishing as social meeting web spaces for users and peer community members. Different online communities require different levels of competence for participants to join, and scattered evidence suggests that females and minorities as participants can be under-represented. Additional anecdotal evidence suggests that women withdraw from unfriendly online communities. Owing to the limited amount of empirical evidence on the matter, this paper provides a quantitative study of the phenomenon, in order to assess the representation and social impact of gender in online communities. This study positions itself within recent and focused international initiatives, launched by the European Commission in order to encourage women in the field of science and technology. Focusing on technical support networks around web content management tools (e.g. Drupal and WordPress) and on questions & answers websites (e.g. StackOverflow), this paper unearths a spectrum of online communities, in which women participate to various degrees.

Abstract Several years of research and evidence have demonstrated that open source software portals often contain a large amount of software projects that simply do not evolve, developed by relatively small communities, struggling to attract a sustained number of contributors. These portals have started to increasingly act as a storage for abandoned projects, and researchers and practitioners should try and point out how to take advantage of such content. Similarly, other online content portals (like Wikipedia) could be harvested for valuable content. In this paper we argue that, even with differences in the requested expertise, many projects reliant on content and contributions by users undergo a similar evolution, and follow similar patterns: when a project fails to attract contributors, it appears to be not evolving, or abandoned. Far from a negative finding, even those projects could provide valuable content that should be harvested and identified based on common characteristics: by using the attributes of ‘usefulness’ and ‘modularity’ we isolate valuable content in both Wikipedia pages and open source software projects. Copyright © 2012 John Wiley & Sons, Ltd.

The public data available in Open Source Software (OSS) repositories has been used for many practical reasons: detecting community structures; identifying key roles among developers; understanding software quality; predicting the arousal of bugs in large OSS systems, and so on; but also to formulate and validate new metrics and proof-of-concepts on general, non-OSS specific, software engineering aspects. One of the results that has not emerged yet from the analysis of OSS repositories is how to help the “career advancement” of developers: given the available data on products and processes used in OSS development, it should be possible to produce measurements to identify and describe a developer, that could be used externally as a measure of recognition and experience. This paper builds on top of the h-index, used in academic contexts, and which is used to determine the recognition of a researcher among her peers. By creating similar indices for OSS (or any) developers, this work could help defining a baseline for measuring and comparing the contributions of OSS developers in an objective, open and reproducible way.

Proponents of the free software paradigm have argued that some of the most established software engineering principles do not fully apply when considered in an open, distributed approach found in free software development. The objective of this research is to empirically examine the Brooks' law in a free software context. The principle is separated out into its two primary premises: the first is based on a developer's ability to become productive when joining a new team; the second premise relates to the quality of coordination as the team grows. Three large projects are studied for this purpose: KDE, Plone and Evince. Based on empirical evidence, the paper provides two main contributions: based on the first premise of Brooks' law, it claims that coordination costs increase only in a very specific phase for free software projects. After that, these costs become quasi-constant. Secondly, it shows that a ramp up period exists in free software projects, and this period marks the divide between projects that are successful at engaging new contributors from others that only benefit from occasional new contributors.

During the last years Free/Libre/Open Source Software (FLOSS) has gained much attention in the software evolution and maintenance research community. This is due to various reasons that range from the availability of the software product to the archival of past software and non-software artifacts in versioning repositories, bug tracking systems and mailing lists, among others. The most interesting aspect of FLOSS is how the evolution and maintenance of a given FLOSS project is affected by other FLOSS projects and their communities. This includes how (technical and non-technical) knowledge flows between projects, the impact of the software dependencies on the evolution of the own software, the impact of the licensing terms and other intellectual property rights on the evolution of the software or how (technical and non-technical) decisions of some FLOSS applications may affect other FLOSS applications.

We have analyzed evolution patterns over two and a half years for a system developed using extreme programming. We find that the system shows a smooth pattern of growth overall, that (McCabe) code complexity is low, and that the relative amount of complexity control work (e.g. refactoring) is higher than in other systems we have studied. To interpret these results, we have drawn on qualitative data including the results of an observational study, records of progress and productivity, and comments on our findings from team members.

Accumulated changes on a software system are not uniformly distributed: some elements are changed more often than others. For optimal impact, the limited time and effort for complexity control, called anti-regressive work, should be applied to the elements of the system which are frequently changed and are complex. Based on this, we propose a maintenance guidance model (MGM) which is tested against real-world data. MGM takes into account several dimensions of complexity: size, structural complexity and coupling. Results show that maintainers of the eight open source systems studied tend, in general, to prioritize their anti-regressive work in line with the predictions given by our MGM, even though, divergences also exist. MGM offers a history-based alternative to existing approaches to the identification of elements for anti-regressive work, most of which use static code characteristics only.

Software evolution and maintenance is largely based on data gathered through years of experience: understanding and improving software is often a matter of how much data is available. Open source software offers the opportunity to analyze closely all the phases in the evolution of a project. What's more, data regarding its evolution is generally available for inspections. Based on simply code analyses, lots of questions about its efficiencies can't be resolved. It would be necessary to study the process from the inside, understanding who or what drove what improvement and so on. Still a quantitative analysis gives several insights about how much code is created and evolved by developers. This study takes a sample of 12 open source projects and gives some statistics to analyze their evolution. The purpose is here to compare what is commonly know in software evolution in traditional environments, and what happens instead in open environments.