• WEs with high similarity guided developers to relevant directories and files. • Eye-tracking revealed the benefits and challenges of using WEs in OSS projects. • Data beyond the title and description is needed to obtain more relevant WEs. • WEs served as a starting point for resolving issues on GitHub. • WEs complement LLMs by offering community-validated solutions. The growing popularity of Open-Source Software projects has raised questions about the challenges novice and inexperienced developers face, especially on code contribution platforms like GitHub. This study investigates the effects of using Worked Examples (WEs) to support these developers in solving coding tasks, using eye-tracking and cognitive effort analysis. The research involved 20 undergraduate students analyzing issues from the JabRef repository, with recommendations of high and low-similarity examples provided by a bot. The findings suggest that highly similar WEs effectively guided participants by helping identify relevant directories, files, and code snippets, serving as starting points for task resolution. However, challenges emerged, such as difficulties locating useful information and risks of false proximity between seemingly similar issues. These results highlight the need for improved recommendation strategies beyond textual similarity, incorporating structural elements such as file and method names, while reducing cognitive load through better presentation of relevant information. This work lays the groundwork for exploring WEs in Open-Source Software projects and opens avenues for further research, including validating findings in other repositories and understanding behavioral patterns in using WEs.

• Analyzed 25,302 questions on Mocking from StackOverflow. • Applied LDA for topic modelling and pyLDAvis for topic visualizations. • Identified 30 topics, performed categorization, constructed topic hierarchy. • Analyzed category and topic-wise question trends, question types, Q&A popularity and difficulty. Mocking is a common unit testing technique that is used to simplify tests, reduce flakiness, and improve coverage by replacing real dependencies with simplified implementations. Despite its widespread use in Open Source Software (OSS) projects, there is limited understanding of how and why developers use mocks and the challenges they face. In this study, we have analyzed 25,302 questions related to Mocking on StackOverflow to identify the challenges faced by developers. We have used Latent Dirichlet Allocation (LDA) for topic modeling, identified 30 key topics, and grouped the topics into five key categories. Consequently, we analyzed the annual and relative probabilities of each category to understand the evolution of mocking-related discussions. Trend analysis reveals that categories such as Mocking Techniques and External Services have remained consistently dominant, highlighting evolving developer priorities and ongoing technical challenges. While the questions on Theoretical category declined after 2010, posts regarding Error Handling grew notably from 2009. Our findings also show an inverse relationship between a topic’s popularity and its difficulty. Popular topics like Framework Selection tend to have lower difficulty and faster resolution times, while complex topics like HTTP Requests and Responses are more likely to remain unanswered and take longer to resolve. Additionally, we evaluated questions based on the answer status- successful, ordinary, or unsuccessful, and found that topics such as Framework Selection have higher success rates, whereas tool setup and Android-related issues are more often unresolved. A classification of questions into How, Why, What , and Other revealed that over 64 % are How questions, particularly in practical domains like file access, APIs, and databases, indicating a strong need for implementation guidance. Why questions are more prevalent in error-handling contexts, reflecting conceptual challenges in debugging, while What questions are rare and mostly tied to theoretical discussions. These insights offer valuable guidance for improving developer support, tooling, and educational content in the context of mocking and unit testing.

ABSTRACT Introduction Open‐source software (OSS) projects thrive on collaborative communities, forming a critical backbone of modern technology. Despite community contributions shaping open‐source development, a gap remains in understanding how community interactions impact project longevity. To address this, our study investigates how discussion volume (as a measure of engagement), sentiment expressed in discussions, issue resolution time, and issue characteristics influence both the resolution process and, crucially, OSS project lifespan. Methods Using a comprehensive GitHub issue dataset, we applied robust statistical analyses and effect size measures across various project lifecycle stages. Results Our findings reveal that while discussion volume weakly correlates with resolution time and sentiment's practical impact is negligible, a counter‐intuitive pattern emerges: longer‐lived projects consistently exhibit extended median issue resolution times, in contrast to faster initial resolutions observed in shorter‐lived projects. Analysis of issue labels suggests this is because shorter‐lived projects tend to address beginner‐friendly issues, whereas enduring projects confront more complex, core development tasks. These findings emphasize that OSS project longevity depends less on rapid initial issue resolution and more on structured, sustained engagement with increasingly complex contributions–underscoring the vital role of qualitative communication and the nature of work in fostering robust communities.

With the increasing popularity of machine learning (ML), many open source software (OSS) contributors are attracted to developing and adopting ML approaches. Comprehensive understanding of ML contributors is crucial for successful ML OSS development and maintenance. Without such knowledge, there is a risk of inefficient resource allocation and hindered collaboration in ML OSS projects. Existing research focuses on understanding the difficulties and challenges perceived by ML contributors through user surveys. There is a lack of understanding of ML contributors based on their activities recorded in the software repositories. In this article, we aim to understand ML contributors by identifying contributor profiles in ML libraries. We further study contributors’ OSS engagement from four aspects: workload composition, work preferences, technical importance, and ML-specific versus SE contributions. By investigating 11,949 contributors from eight popular ML libraries (i.e., TensorFlow, PyTorch, scikit-learn, Keras, MXNet, Theano/Aesara, ONNX, and deeplearning4j), we categorize them into four contributor profiles: Core-Nighttime , Core-Daytime , Peripheral-Nighttime , and Peripheral-Daytime . We find that: (1) project experience, authored files, collaborations, pull requests comments received and approval ratio, and geographical location are significant features of all profiles; (2) contributors in Core profiles exhibit significantly different OSS engagement compared to Peripheral profiles; (3) contributors’ work preferences and workload compositions are significantly correlated with project popularity; and (4) long-term contributors evolve toward making fewer, constant, balanced and less technical contributions.

An increasing number of companies are contributing to open source software (OSS) projects by assigning their employees to advance their business objectives. These paid developers collaborate with volunteer contributors, but the differing motivations of these two groups can sometimes lead to conflicts, which might endanger the OSS project's sustainability. This article presents a multi-method comparative study of paid developers and volunteers in Rust, currently one of the most popular open source programming languages. We compare volunteers and paid developers through contribution behavior, social collaboration, and long-term participation. Then, we solicit volunteers’ perceptions of paid developers and explore the emotions caused when volunteers transition to paid roles. We find that core paid developers tend to contribute more frequently; peripheral paid developers contribute bigger commits and focus more on implementing features; both core and peripheral paid developers collaborate more with volunteers but less intensively than expected; and being paid correlates positively with becoming a long-term contributor. Our study also reveals existing unfamiliarity and prejudices among volunteers towards paid developers, and that volunteer-to-paid transitions can evoke negative community sentiments. This study suggests that the dichotomous view of paid vs. volunteer developers is too simplistic and that further subgroups could be identified. Contributing organizations should become more sensitive to how OSS communities perceive them when they attempt to get involved and make improvements.

Online collaboration communities (OCCs) enable geographically distributed individuals, groups, and organizations to self-organize and contribute to community-owned artifacts. The significance of these artifacts has been underscored by recent advancements in large language models, which leverage community content for training sophisticated models across diverse domains, including productivity, healthcare, and education. This study investigates star contributors—individuals making disproportionately large contributions to focal OCC artifacts. Drawing on theories of collective action and strategic interactions, we hypothesize a curvilinear relationship between star contributors’ contributions and both artifact quality and popularity. Utilizing data from over 21,000 open-source software projects between 2015 and 2019, we find: (1) an inverted U-shaped relationship between the number of star contributors and artifact quality, (2) an inverted U-shaped relationship between the number of star contributors and artifact popularity, (3) that a higher proportion of star contributors’ contributions enhances artifact quality but not popularity, and (4) that environmental dynamism moderates the relationship between the number of star contributors and both artifact quality and popularity. This research advances the conceptualization of star contributors, offering a more nuanced understanding aligned with the fluid boundaries of OCCs compared to traditional core-periphery models. A key implication is that while star contributors positively impact artifact quality and popularity, an excessive proportion of their contributions negatively affects artifact quality.

ABSTRACT The social isolation measures resulting from the COVID‐19 outbreak changed work practices in various sectors, especially with the shift to working from home. However, the implications of the pandemic on the maintenance and evolution of open‐source software (OSS) still deserve further studies. In this paper, we analyze the effects of COVID‐19 on the development activity of OSS and how social isolation changed the productivity of OSS contributors. We conducted a mixed‐method study composed of (i) a mining software repositories analysis of 155 popular and active OSS projects on GitHub, selected from an initial dataset of 1500 repositories based on activity thresholds (commits, pull requests, and size), and (ii) a survey with 57 core developers identified using an established literature‐based heuristic. The mining study analyzed commits, code churn, pull requests, and pull request latency to assess changes before and after the pandemic, applying statistical tests and a mixed‐effects Regression Discontinuity Design. The survey collected self‐reported perceptions of productivity and engagement during the pandemic, enabling triangulation with repository activity trends. Our results show that while core developers' productivity remained stable, there was a sustained decline in newcomer participation and a temporary increase in core developer turnover. In the early days of the outbreak, we observed an increase in accepted pull requests, followed by a stabilization of most activity metrics. Some findings are supported by our survey study, whose results indicate that most of our survey respondents consider that COVID‐19 did not change their productivity substantially. These findings offer insights into OSS resilience and sustainability in the face of large‐scale disruptions, contributing to a broader understanding of the outbreak's impact and providing actionable lessons for managing distributed development in crisis scenarios.

This paper provides a comprehensive overview of the importance of open-source software (OSS), examining the factors to consider when choosing from the diverse range of OSS platforms available today. Open-source programming has been a subject of extensive research and development for decades, serving as a cornerstone for technological innovation. By integrating various features and capabilities, OSS has become a key driver of software development. However, relying solely on a single OSS platform can result in limitations due to the absence of features available on other platforms. This paper explores the suitability of different OSS platforms, recognizing that each has unique features, advantages, and trade-offs. The discussion includes an overview of the history and evolution of OSS, highlighting its significance in software engineering research and education. Historically, these fields have underutilized the vast repositories of data and functional code provided by OSS projects. The philosophy of open source, rooted in the concept of free and collaborative software development, will be analyzed in the context of how software engineering research and education can leverage OSS platforms for innovation. This paper identifies the critical considerations for selecting an optimal OSS platform and discusses how to maximize its potential for programming development and educational purposes.

To improve organizational commitment and foster an AI-driven, contemporary corporate environment characterized by creativity, adaptability, and agility, this study explores the function of transformational leadership in software development teams. Bass and Riggio's transformational leadership model serves as the framework for the technique, which is grounded in a comprehensive review of the literature. In addition to secondary analysis of the publicly available "Open-Source Software Leadership Survey Dataset", accessible at https://opensourcesurvey.org/, we have also included recent 2017–2024 case studies from software leaders like Google and Microsoft, illustrating various practices. This dataset source, which we plan to further investigate in subsequent primary research for more thorough replication, records survey responses on leadership styles, intrinsic and extrinsic motivation, and commitment measures in open-source software projects. Results should illustrate that leaders who outline imaginative project roadmaps, give personalized mentorship in various tools that stimulate intelligence via hackathons, and model ethical open-source practices. Transformational leadership stands out in contemporary management theory as a style that goes beyond the traditional understanding of leadership and people management. Its essence is reflected in the ability of leaders to inspire, motivate, and encourage employees to overcome their own interests and contribute to the realization of a shared vision of the organization. This paper explores the impact of transformational leadership low and high leadership levels on the organization, employee commitment, and innovation, starting from theoretical premises that link personal development with collective performance. Special attention is paid to the role of managers in creating a stimulating work environment that develops trust, initiative, and readiness for change. Through an analysis of relevant literature and the transformational leadership model of Bass and Riggio, the paper indicates that leaders who encourage creativity, independence, and team spirit create the foundations for the sustainable development of employee culture and innovative behavior. The recommendations support inclusive hiring, gamified sprint evaluations, and specialist training in AI-era motivation. Additional information from the dataset shows that transformational teams had lower turnover and higher job satisfaction in Top3 for low leadership (0.20), with qualitative insights highlighting that high leadership group in Top1 scored highest (0.40) in job satisfaction.

ABSTRACT The Open Source Software (OSS) model has emerged as a dominant digital interface for knowledge creation. However, the OSS project owner and contributors form a relationship which is subject to double-sided ‘hidden action’ moral hazard. We formalise this situation using a simple principal-agent model containing two key features of decentralised platform-based open-source innovations: double moral hazard and limited individual rationality under which we introduce an additional participation constraint allowing for low-cost input in OSS collaborations. Our findings reveal that an OSS contributor is prone to moral hazard behaviours such as free riding if private incentives faced by the agent are not aligned with the interests of the project. From the perspective of the principal, moral hazard behaviours can also emerge with the incentives arising from several primary activities. Our study provides an important theoretical basis for understanding the source of market failures in open innovation processes and the mechanism that can potentially curb risk-taking incentives. This research contributes nuanced perspectives on policy responses, experiment designs, and the socio-economic implications of open-source innovations.

Open-source software projects face increasing challenges in maintaining design quality as they evolve, often resulting in technical debt accumulation and reduced maintainability. This study explores the relationship between software modularity, measured using ISO/IEC 25010 quality attributes, Chidamber and Kemerer (CK) object-oriented metrics, and architectural smells (AS) in Java-based open-source software. Six Java-based open-source projects were strategically selected based on varying complexity levels (ranging from 6-994 classes) and different application domains to ensure comprehensive analysis coverage using DesigniteJava to extract AS, CK metrics, and modularity indicators. Correlation analyses showed that architectural smells such as Cyclic Dependency, Ambiguous Interface, and God Component are strongly correlated with CK metrics like Weighted Methods per Class, Depth of Inheritance Tree, and Number of Children. These CK metrics also exhibited strong positive correlations with Cyclomatic Complexity, indicating that structurally complex components also tend to have more complex control logic. Dense Structure was found to negatively correlate with Coupling of Components Conformance, suggesting its effect on modularity compliance. On the other hand, smells like Feature Concentration and Scattered Functionality showed weak or inconsistent correlations with these metrics. The findings highlight the importance of addressing specific architectural smells to improve modularity and software quality.

A Software Bill of Materials ( SBOM ) formally lists the open-source and proprietary components that constitute a software product, including their licenses, versions, vendors, vulnerabilities, and supply chain relationships. SBOMs enable software producers and consumers to gain visibility into the software supply chain and monitor the risks associated with software security, licensing, and more. This paper presents the results of an exploratory mining study investigating the adoption of SBOMs by open-source software projects. To that end, we mined GitHub and identified 186 public software repositories using SBOM generation tools owned by SPDX and CycloneDX . Although the adoption of SBOMs is low, it is increasing. Moreover, SBOMs are under version control or available in public release versions of less than half the software projects analyzed. Finally, only a limited fraction of SBOMs contain minimum/recommended information, and some SBOMs are also uncompliant with existing SBOM standards. Our study reveals that software producers are paying more attention to SBOMs, but even so, these may be incomplete. We urge software producers to adopt SBOMs and meet the new software supply chain standards. As for researchers, we foster further investigations on adopting SBOMs and their correct use. • SBOM adoption by open-source projects is still low but it is rising. • SBOMs are mostly generated via build-integration tools or GitHub Actions. • Less than half of the projects include SBOMs in version control or release artifacts. • Most SBOMs lack full compliance, minimal, or recommended data fields. • Few SBOMs list license info, hashes, or suppliers; none list vulnerabilities.

ABSTRACT Background and Context Teaching Software Engineering (SE) requires combining theory with practice. Worked examples from Open Source Software (OSS) projects connect SE education with real-world practice by offering accessible scenarios that reduce cognitive load and reflect industry standards. Yet, their effectiveness depends on student engagement, for which gamification is a promising strategy. This study was conducted in Brazil, providing insights into gamified worked examples in this context. Objective This study examines how gamifying OSS-based worked examples affects SE students’ learning, focusing on whether it increases situational cognitive engagement – defined as task-specific cognitive involvement – thus improving understanding of complex content. We evaluated a custom-built gamified prototype designed around OSS-derived worked examples and explored potential effects across different learner profiles. Method We conducted an experiment comparing gamified and non-gamified versions with SE students. A quantitative analysis assessed engagement and perceived workload, including stratified analyses by prior knowledge and player profile. Findings The results show a modest but statistically significant difference, with slightly higher engagement in the non-gamified condition. However, the gamified approach benefited specific groups of students, such as novices and certain player profiles. Gamified examples also reduced workload, particularly among novice students. Implications Gamification can support SE learning by enhancing engagement and lowering workload, especially for new students. Differentiated effects highlight the need for tailoring interventions to learner characteristics. The platform shows potential for expansion with adaptive difficulty, feedback, and collaborative features.

Introduction Open-source software (OSS) projects, characterized by distributed development and volunteer contributions, face challenges in prioritizing user-centered design and usability. This difficulty arises because these projects are primarily driven by developers who focus on technical contributions. As a result, usability and user experience (UX) considerations are often neglected, leading to software that may not meet the needs of its broad and diverse users. Methods To address this issue, we explore the potential of using user personas which are fictional characters representing real user groups, to enhance user-centered design in OSS projects. Personas promote empathy and a deeper understanding of user needs, thereby improving alignment between developers and users. We conducted an experimental study on three OSS projects: Moodle, Lichess, and Audacity. Personas were created for each project and refined based on feedback from industry experts. Results Developers rated personas highly for credibility (86%), consistency (79%), and friendliness (86%), highlighting their relevance in OSS projects. A follow-up experiment with students confirmed these findings, with consistency (79%) demonstrating personas' role in improving usability and aligning developers with user needs. Discussion While adoption remains limited due to technical priorities (only 14% of developers and 34% of students found personas useful and expressed willingness to adopt them), personas show significant potential to enhance user-centered design in OSS. Further research is needed to understand developers' reluctance to adopt this technique and explore strategies to integrate personas more effectively into OSS workflows. This study's novelty lies in its empirical exploration of personas within OSS, providing quantitative evidence of their effectiveness in improving usability and user-centered design.

The development of Open-Source Software (OSS) is not only a technical challenge, but also a social one due to the diverse mixture of contributors. To this aim, social-coding platforms, such as GitHub, provide the infrastructure needed to host and develop the code, but also the support for enabling the community's collaboration, which is driven by non-coding contributions, such as issues (i.e., change proposals or bug reports) or comments to existing contributions. As with any other social endeavor, this development process faces ethical challenges, which may put in risk the project's sustainability. To foster a productive and positive environment, OSS projects are increasingly deploying codes of conduct, which define rules to ensure a respectful and inclusive participatory environment, with the Contributor Covenant being the main model to follow. However, monitoring and enforcing these codes of conduct is a challenging task, due to the limitations of current approaches. In this paper, we propose an approach to classify the ethical quality of non-coding contributions in OSS projects by relying on Large Language Models (LLM), a promising technology for text classification tasks. We defined a set of ethical metrics based on the Contributor Covenant and developed a classification approach to assess ethical behavior in OSS non-coding contributions, using prompt engineering to guide the model's output.

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

Write access provisioning and organizational ownership in open source software projects: Exploring the impact on project novelty and survival

Software defect prediction (SDP) plays a pivotal role in ensuring high-quality software development by aiding in the early identification of potential defects. This practice has gained substantial attention in the field of software engineering over the years. Recent advancements in deep learning have primarily focused on extracting general syntactic features from abstract syntax trees (ASTs) for SDP. However, AST-based neural network models might overlook important structural information related to control flows embedded within the source code. Given that software defects are often influenced by control flow patterns, this article proposes a novel SDP approach called control flow graph and graph attention (CFG2AT) network-based SDP. CFG2AT is specifically designed to automatically identify software defects and contains a graph-structured attention unit to effectively capture control flow information. To evaluate the effectiveness of CFG2AT, we carried out extensive experiments using data from 15 versions of six different open-source software projects under both within-project and cross-project defect prediction settings. Experimental results demonstrate that our proposed CFG2AT approach generally outperforms a range of competing methods for defect prediction. The improvement is 7.09%–12.80% in <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">F1</i>, 1.30%–4.15% in area under curve (AUC), and 6.78%–17.54% in Matthews correlation coefficient (MCC) under within-project defect prediction, and 23.76%–44.79% in <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">F1</i>, 8.93%–13.27% in AUC, and 36.92%–94.89% in MCC under CPDP, respectively.

Demystifying issues, causes and solutions in LLM open-source projects

Developers reuse programming-related knowledge (e.g., code snippets) on Q&A sites (e.g., Stack Overflow) that functionally matches the programming problems they encounter in their development. Despite extensive research on Q&A sites, being a high-level and important type of development-related knowledge, architectural solutions (e.g., architecture tactics) and their reuse are rarely explored. To fill this gap, we conducted a mixed-methods study that includes a mining study and a survey study. For the mining study, we mined 984 commits and issues (i.e., 821 commits and 163 issues) from 893 Open-Source Software (OSS) projects on GitHub that explicitly referenced architectural solutions from Stack Overflow (SO) and Software Engineering Stack Exchange (SWESE). For the survey study, we identified practitioners involved in the reuse of these architectural solutions and surveyed 227 of them to further understand how practitioners reuse architectural solutions from Q&A sites in their OSS development. Our main findings are that: (1) OSS practitioners reuse architectural solutions from Q&A sites to solve a large variety (15 categories) of architectural problems, wherein <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Component design issue</i>, <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Architectural anti-pattern</i>, and <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Security issue</i> are dominant; (2) Seven categories of architectural solutions from Q&A sites have been reused to solve those problems, among which <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Architectural refactoring</i>, <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Use of frameworks</i>, and <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Architectural tactic</i> are the three most reused architectural solutions; (3) OSS developers often rely on ad hoc ways (e.g., informal, improvised, or unstructured approaches) to reuse architectural solutions from SO, drawing on personal experience and intuition rather than standardized or systematic practices; (4) Reusing architectural solutions from SO comes with a variety of challenges, e.g., OSS practitioners complain that they need to spend significant time to adapt such architectural solutions to address design concerns raised in their OSS development, and it is challenging to reuse architectural solutions that are not tailored to the design context of their OSS projects. Our findings pave the way for future research directions, including the design and development of approaches and tools (such as IDE plugin tools) to facilitate the reuse of architectural solutions from Q&A sites, and could also be used to offer guidelines to practitioners when they contribute architectural solutions to Q&A sites. Our dataset is publicly available at <uri xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">https://doi.org/10.5281/zenodo.10936098</uri>.