arXiv subjects

Olivier Nourry

Publications and source records attributed to Olivier Nourry.

6 recordsLinked to original sources

arXiv2026

Cross-Ecosystem Packages As Multilingual: Prevalence, Architecture, and Health

Modern software development increasingly relies on using multiple programming languages. Some software packages are published to multiple package ecosystems such as NPM for JavaScript and PyPI for Python. Little is known about cross-ecosystem packages, especially regarding how they are structured. In this paper, we conduct a large-scale empirical study of over six million packages across six major ecosystems to understand 1) how prevalent cross-ecosystem packages are among all packages, 2) whether there are distinct source code architectural patterns that cross-ecosystem packages use, and 3) whether there are correlations between architectural patterns and project health metrics from GitHub. Results indicate that cross-ecosystem packages constitute a small but important, growing fraction of packages. We identify five distinct architectural patterns. For example, packages that implement code generation from a shared source file or use language bindings are associated with significantly higher community visibility and development activity. Based on our findings, we provide implications for package adopters, maintainers, and researchers. We envision our taxonomy being used for future investigations into several aspects of software development, such as the trade-offs between focusing on one language and translating to other languages using bindings, templating, and wrappers, versus using native code and native functions to support additional languages.

cs.SE↗

arXiv2026

Forecasting Developer Environments with GenAI: A Research Perspective

Generative Artificial Intelligence (GenAI) models are achieving remarkable performance in various tasks, including code generation, testing, code review, and program repair. The ability to increase the level of abstraction away from writing code has the potential to change the Human-AI interaction within the integrated development environment (IDE). To explore the impact of GenAI on IDEs, 33 experts from the Software Engineering, Artificial Intelligence, and Human-Computer Interaction domains gathered to discuss challenges and opportunities at Shonan Meeting 222, a four-day intensive research meeting. Four themes emerged as areas of interest for researchers and practitioners.

cs.SE↗

arXiv2026

Does Programming Language Matter? An Empirical Study of Fuzzing Bug Detection

Fuzzing has become a popular technique for automatically detecting vulnerabilities and bugs by generating unexpected inputs. In recent years, the fuzzing process has been integrated into continuous integration workflows (i.e., continuous fuzzing), enabling short and frequent testing cycles. Despite its widespread adoption, prior research has not examined whether the effectiveness of continuous fuzzing varies across programming languages. This study conducts a large-scale cross-language analysis to examine how fuzzing bug characteristics and detection efficiency differ among languages. We analyze 61,444 fuzzing bugs and 999,248 builds from 559 OSS-Fuzz projects categorized by primary language. Our findings reveal that (i) C++ and Rust exhibit higher fuzzing bug detection frequencies, (ii) Rust and Python show low vulnerability ratios but tend to expose more critical vulnerabilities, (iii) crash types vary across languages and unreproducible bugs are more frequent in Go but rare in Rust, and (iv) Python attains higher patch coverage but suffers from longer time-to-detection. These results demonstrate that fuzzing behavior and effectiveness are strongly shaped by language design, providing insights for language-aware fuzzing strategies and tool development.

cs.SE↗

arXiv2026

Leveraging Mutation Analysis for LLM-based Repair of Quantum Programs

In recent years, Automated Program Repair (APR) techniques specifically designed for quantum programs have been proposed. However, existing approaches often suffer from low repair success rates or poor understandability of the generated patches. In this study, we construct a framework in which a large language model (LLM) generates code repairs along with a natural language explanation of the applied repairs. To investigate how the contextual information included in prompts influences APR performance for quantum programs, we design four prompt configurations with different combinations of static information, dynamic information, and mutation analysis results. Mutation analysis evaluates how small changes to specific parts of a program affect its execution results and provides more detailed dynamic information than simple execution outputs such as stack traces. Our experimental results show that mutation analysis can provide valuable contextual information for LLM-based APR of quantum programs, improving repair success rates (achieving 94.4% in our experiment) and in some cases also improving the quality of generated explanations. Our findings point toward new directions for developing APR techniques for quantum programs that enhance both reliability and explainability.

cs.SE↗

arXiv2025

Large-Scale Empirical Analysis of Continuous Fuzzing: Insights from 1 Million Fuzzing Sessions

Software vulnerabilities are constantly being reported and exploited in software products, causing significant impacts on society. In recent years, the main approach to vulnerability detection, fuzzing, has been integrated into the continuous integration process to run in short and frequent cycles. This continuous fuzzing allows for fast identification and remediation of vulnerabilities during the development process. Despite adoption by thousands of projects, however, it is unclear how continuous fuzzing contributes to vulnerability detection. This study aims to elucidate the role of continuous fuzzing in vulnerability detection. Specifically, we investigate the coverage and the total number of fuzzing sessions when fuzzing bugs are discovered. We collect issue reports, coverage reports, and fuzzing logs from OSS-Fuzz, an online service provided by Google that performs fuzzing during continuous integration. Through an empirical study of a total of approximately 1.12 million fuzzing sessions from 878 projects participating in OSS-Fuzz, we reveal that (i) a substantial number of fuzzing bugs exist prior to the integration of continuous fuzzing, leading to a high detection rate in the early stages; (ii) code coverage continues to increase as continuous fuzzing progresses; and (iii) changes in coverage contribute to the detection of fuzzing bugs. This study provides empirical insights into how continuous fuzzing contributes to fuzzing bug detection, offering practical implications for future strategies and tool development in continuous fuzzing.

cs.SE↗

arXiv2024

Myth: The loss of core developers is a critical issue for OSS communities

Throughout their lifetime, open-source software systems will naturally attract new contributors and lose existing contributors. Not all OSS contributors are equal, however, as some contributors within a project possess significant knowledge and expertise of the codebase (i.e., core developers). When investigating the ability of projects to attract new contributors and how often a project loses contributors, it is therefore important to take into account the expertise of the contributors. Since core developers are vital to the longevity of projects, we therefore aim to find out: can OSS projects attract new core developers and how often do OSS projects lose core developers? To investigate core developer contribution patterns, we calculate the truck factor (or bus factor) of over 36,000 OSS projects to investigate how often TF developers join or abandon OSS projects. We find that 89% of our studied projects have experienced losing their core development team at least once. Our results also show that in 70% of cases, this project abandonment happens within the first three years of the project life. We also find that most OSS projects rely on a single core developer to maintain development activities. Finally, we find that only 27% of projects that were abandoned were able to attract at least one new TF developer. Our analysis shows that it is not uncommon for OSS projects to lose their initial core development team. This is likely due to most OSS project relying on a single core developer to maintain development activities. The first year of development is critical for OSS projects since this is where they are most at risk of losing their core developer(s). Additionally, projects that lose their core developer(s) early seem less likely to survive this event than projects that lost their core developers later on during their life.

cs.SE↗