The SZZ method identifies defect-inducing commits by tracing lines modified in defect-fixing commits back to the commits that introduced them. While this method is widely used, it may fail to identify defect-inducing commits that are untraceable at the line-level. To address this limitation, a previous study proposed a Token-SZZ method that tracks changes at the token-level. This approach converts a line-level Git history into a token-level history by decomposing each line into individual tokens. While this method is able to identify defect-inducing commits that the previous SZZ method misses, it also incorrectly identifies many commits as defect-inducing (false positives), resulting in decreased performance. To mitigate this issue, we propose Majority Voting SZZ (MV-SZZ), which consists of two key features: an N-token representation of the Git history and a majority voting mechanism. The N-token representation expands on the token-level concept (where N = 1) by instead using N (N > 1) consecutive tokens as a single line. This allows the method to capture more context for defect identification. The majority voting mechanism identifies the most frequent candidate commit associated with the changed tokens, and selects it as the defect-inducing commit. This approach effectively filters out unrelated tokens and reduces false positives. We compared MV-SZZ with six SZZ methods on both the Developer-IO and Defects4J datasets. MV-SZZ achieved the highest F1 and F0.5 scores on both datasets (F1: 0.587 and 0.580; F0.5: 0.591 and 0.578). Interestingly, we found that the issue of increased false positives due to token-level tracking is not unique to token-level methods; rather, it is a general problem that arises in SZZ methods when more accurate tracking is applied. Moreover, we demonstrated that our majority voting mechanism serves as an effective filtering strategy for SZZ variants in general.

Artificial intelligence is reshaping open source software (OSS) contribution by lowering the cost of producing code, documentation, issue reports, and review interactions. This creates opportunities for broader participation, but also disrupts how maintainers assess contributor effort, competence, and accountability. In response, OSS projects are beginning to regulate AI-mediated contribution through contribution guidelines and other project documentation. This paper presents an empirical study of these emerging policies. We analyze project policies on AI-mediated contributions by evaluating their underlying rationales, rules, and expectations. Our analysis shows that these policies seek to protect scarce maintainer attention, preserve accountability, sustain meaningful review interactions, address legal and quality concerns, and maintain pathways for newcomer learning. Based on these findings, we introduce the AI Contribution Governance Framework, which organizes recurring concerns and governance mechanisms across projects. The framework helps OSS communities develop AI contribution policies and provides researchers with a vocabulary for studying how AI is changing collaborative software production.

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.

Despite the utility that Generative AI (GenAI) tools provide for tasks such as writing code, the use of these tools raises important legal questions and potential risks, particularly those associated with copyright law. As lawmakers and regulators respond to these questions, the views of users can offer relevant perspectives. In this article, we provide: (1) a survey of 574 developers on the licensing and copyright aspects of GenAI for coding, as well as follow-up interviews; (2) a snapshot of developers' views at a time when GenAI and perceptions of it were rapidly evolving; and (3) an analysis of developers' perspectives, yielding insights and recommendations that can inform future regulatory decisions in this evolving field. Our results show the benefits developers derive from GenAI, how they view the use of AI-generated code as similar to using other existing code, the varied opinions they have on who should own or be compensated for such code, that they are concerned about data leakage via GenAI, and other findings, providing organizations and policymakers with valuable insights into how the technology is being used and the concerns that stakeholders believe warrant attention.

Open Source Software (OSS) projects offer valuable opportunities to train the next generation of software engineers while benefiting projects and society as a whole. While research has extensively explored student participation in OSS and its use in software engineering education, student participation in OSS is still low, and the perspectives of students who have never contributed remain underexplored. This study aims to investigate the relationship between students' interest in contributing to OSS and their perceptions of barriers and motivational factors. We developed a theoretical model to understand the relationship between students' perceptions of OSS and their interest in contributing. We then surveyed students majoring in computer science and related fields (N=241). Using structural equation modeling techniques, we tested the model and found that intrinsic and internalized extrinsic motivations are positively associated with interest in contributing to OSS projects, while the impact of extrinsic motivation varies by gender. Comparatively, we found no significant relationship between barriers and interest in contributing. Students suggested several ways to make projects more attractive, including increasing awareness of the importance of OSS. Our findings can help communities better prepare to integrate students and encourage educators to enhance interest in OSS by linking participation to specific motivational factors.

Most modern software products incorporate open-source components, requiring development teams to maintain compliance with each component's licenses. Noncompliance can lead to significant financial, legal, and reputational repercussions. While some organizations may seek advice from legal practitioners to assist with licensing tasks, developers still play a key role in such a process. To this end, it is essential to understand how developers approach license compliance tasks, the challenges they encounter, and the tools that they use. This work studies these aspects of software licensing practices through a study - conducted by a joint team of software engineering and legal researchers - consisting of a survey with 58 software developers and seven follow-up interviews. The study resulted in 15 key findings regarding the current state of practice. We discuss the implications of our findings and offer directions for future research as well as actionable recommendations for licensing tools.

The last decade has seen widespread adoption of Machine Learning (ML) components in software systems. This has occurred in nearly every domain, from natural language processing to computer vision. These ML components range from relatively simple neural networks to complex and resource-intensive large language models. However, despite this widespread adoption, little is known about the supply chain relationships that produce these models, which can have implications for compliance and security. In this work, we conducted an extensive analysis of 760,460 models and 175,000 datasets extracted from the popular model-sharing site Hugging Face. First, we evaluate the current state of documentation in the Hugging Face supply chain, report real-world examples of shortcomings, and offer actionable suggestions for improvement. Next, we analyze the underlying structure of the existing supply chain. Finally, we explore the current licensing landscape against what was reported in previous work and discuss the unique challenges posed in this domain. Our results motivate multiple research avenues, including the need for better license management for ML models/datasets, better support for model documentation, and automated inconsistency checking and validation. We make our research infrastructure and dataset available to facilitate future research.

Software Bills of Materials (SBOMs) have emerged as tools to facilitate the management of software dependencies, vulnerabilities, licenses, and the supply chain. While significant effort has been devoted to increasing SBOM awareness and developing SBOM formats and tools, recent studies have shown that SBOMs are still an early technology not yet adequately adopted in practice. Expanding on previous research, this paper reports a comprehensive study that investigates the current challenges stakeholders encounter when creating and using SBOMs. The study surveyed 138 practitioners belonging to five stakeholder groups (practitioners familiar with SBOMs, members of critical open source projects, AI/ML, cyber-physical systems, and legal practitioners) using differentiated questionnaires, and interviewed 8 survey respondents to gather further insights about their experience. We identified 12 major challenges facing the creation and use of SBOMs, including those related to the SBOM content, deficiencies in SBOM tools, SBOM maintenance and verification, and domain-specific challenges. We propose and discuss 4 actionable solutions to the identified challenges and present the major avenues for future research and development.

“App stores” are online software stores where end users may browse, purchase, download, and install software applications. By far, the best known app stores are associated with mobile platforms, such as Google Play for Android and Apple’s App Store for iOS. The ubiquity of smartphones has led to mobile app stores becoming a touchstone experience of modern living. App stores have been the subject of many empirical studies. However, most of this research has concentrated on properties of the apps rather than the stores themselves. Today, there is a rich diversity of app stores and these stores have largely been overlooked by researchers: app stores exist on many distinctive platforms, are aimed at different classes of users, and have different end-goals beyond simply selling a standalone app to a smartphone user. The goal of this paper is to survey and characterize the broader dimensionality of app stores, and to explore how and why they influence software development practices, such as system design and release management. We begin by collecting a set of app store examples from web search queries. By analyzing and curating the results, we derive a set of features common to app stores. We then build a dimensional model of app stores based on these features, and we fit each app store from our web search result set into this model. Next, we performed unsupervised clustering to the app stores to find their natural groupings. Our results suggest that app stores have become an essential stakeholder in modern software development. They control the distribution channel to end users and ensure that the applications are of suitable quality; in turn, this leads to developers adhering to various store guidelines when creating their applications. However, we found the app stores operational model could vary widely between stores, and this variability could in turn affect the generalizability of existing understanding of app stores.

This paper summarizes the current copyright related risks that Machine Learning (ML) and Artificial Intelligence (AI) systems (including Large Language Models –LLMs) incur. These risks affect different stakeholders: owners of the copyright of the training data, the users of ML/AI systems, the creators of trained models, and the operators of AI systems. This paper also provides an overview of ongoing legal cases in the United States related to these risks.

In software development, developers frequently apply maintenance activities to the source code that change a few lines by a single commit. A good understanding of the characteristics of such small changes can support quality assurance approaches (e.g., automated program repair), as it is likely that small changes are addressing deficiencies in other changes; thus, understanding the reasons for creating small changes can help understand the types of errors introduced. Eventually, these reasons and the types of errors can be used to enhance quality assurance approaches for improving code quality. While prior studies used code churns to characterize and investigate the small changes, such a definition has a critical limitation. Specifically, it loses the information of changed tokens in a line. For example, this definition fails to distinguish the following two one-line changes: (1) changing a string literal to fix a displayed message and (2) changing a function call and adding a new parameter. These are definitely maintenance activities, but we deduce that researchers and practitioners are interested in supporting the latter change. To address this limitation, in this paper, we define micro commits, a type of small change based on changed tokens. Our goal is to quantify small changes using changed tokens. Changed tokens allow us to identify small changes more precisely. In fact, this token-level definition can distinguish the above example. We investigate defined micro commits in four OSS projects and understand their characteristics as the first empirical study on token-based micro commits. We find that micro commits mainly replace a single name or literal token, and micro commits are more likely used to fix bugs. Additionally, we propose the use of token-based information to support software engineering approaches in which very small changes significantly affect their effectiveness.

Stack Overflow, a leading Q&A platform for developers, is a substantial reservoir of Python code snippets. Nevertheless, the incompatibility issues between Python versions, particularly Python 2 and Python 3, introduce substantial challenges that can potentially jeopardize the utility of these code snippets. This empirical study dives deep into the challenges of Python version inconsistencies on the interpretation and application of Python code snippets on Stack Overflow. Our empirical study exposes the prevalence of Python version compatibility issues on Stack Overflow. It further emphasizes an apparent deficiency in version-specific identification, a critical element that facilitates the identification and utilization of Python code snippets. These challenges, primarily arising from the lack of backward compatibility between Python's major versions, pose significant hurdles for developers relying on Stack Overflow for code references and learning. This study, therefore, signifies the importance of proactively addressing these compatibility issues in Python code snippets. It advocates for enhanced tools and strategies to assist developers in efficiently navigating through the Python version complexities on platforms like Stack Overflow. By highlighting these concerns and providing a potential remedy, we aim to contribute to a more efficient and effective programming experience on Stack Overflow and similar platforms.

The sense of belonging to a community is a basic human need that impacts an individual's behavior, long-term engagement, and job satisfaction, as revealed by research in disciplines such as psychology, healthcare, and education. Despite much research on how to retain developers in Open Source Software (OSS) projects and other virtual, peer-production communities, there is a paucity of research investigating what might contribute to a sense of belonging in these communities. To that end, we develop a theoretical model that seeks to understand the link between OSS developer motives and a Sense of Virtual Community (SVC). We test the model with a dataset collected in the Linux Kernel developer community (N=225), using structural equation modeling techniques. Our results for this case study show that intrinsic motivations (social or hedonic motives) are positively associated with a sense of virtual community, but living in an authoritative country and being paid to contribute can reduce the sense of virtual community. Based on these results, we offer suggestions for open source projects to foster a sense of virtual community, with a view to retaining contributors and improving projects' sustainability.

Over the years, Stack Overflow (SO) has accumulated numerous code snippets, with developers going to SO for problem solutions and code references. However, in the case of the Python programming language, Python 3 is not necessarily backward compatible with Python 2. The major implication of this versioning problem is that code written in Python 2 may not be interpreted by Python 3 without modifications. This issue may affect the usability of Python code snippets on SO. We investigate how many Python code snippets on SO suffer from version compatibility issues, and find that about 10% of the snippets exhibit this problem. Moreover, of the code snippets that are interpretable only by Python 2 or Python 3, less than 17% are tagged with the Python version. In this paper, we present a Chrome extension called PyVerDetector. This extension allows the user to select a given version of Python and verifies whether the code snippets on a given SO question are compatible with the user's selected Python version, providing error messages if not. The tool parses snippets and can determine versioning errors due to differences in syntax and also provides the user with a list of Python versions capable of interpreting each code snippet.

We consider the problem of identifying the provenance of free/open source software (FOSS) and specifically the need of identifying where reused source code has been copied from. We propose a lightweight approach to solve the problem based on software identifiers-such as the names of variables, classes, and functions chosen by programmers. The proposed approach is able to efficiently narrow down to a small set of candidate origin products, to be further analyzed with more expensive techniques to make a final provenance determination.By analyzing the PyPI (Python Packaging Index) open source ecosystem we find that globally defined identifiers are very distinct. Across PyPI's 244 K packages we found 11.2 M different global identifiers (classes and method/function names-with only 0.6% of identifiers shared among the two types of entities); 76% of identifiers were used only in one package, and 93% in at most 3. Randomly selecting 3 non-frequent global identifiers from an input product is enough to narrow down its origins to a maximum of 3 products within 89% of the cases.We validate the proposed approach by mapping Debian source packages implemented in Python to the corresponding PyPI packages; this approach uses at most five trials, where each trial uses three randomly chosen global identifiers from a randomly chosen python file of the subject software package, then ranks results using a popularity index and requires to inspect only the top result. In our experiments, this method is effective at finding the true origin of a project with a recall of 0.9 and precision of 0.77.

Free and open source software is widely used in the creation of software systems, whereas many organisations choose to provide their systems as open source. Open source software carries licenses that determine the conditions under which the original software can be used. Appropriate use of licenses requires relevant expertise by the practitioners, and has an important legal angle. Educators and employers need to ensure that developers have the necessary training to understand licensing risks and how they can be addressed. At the same time, it is important to understand which issues practitioners face when they are using a specific open source license, when they are developing new open source software products or when they are reusing open source software. In this work, we examine questions posed about open source software licensing using data from the following Stack Exchange sites: Stack Overflow, Software Engineering, Open Source and Law. We analyse the indication of specific licenses and topics in the questions, investigate the attention the posts receive and trends over time, whether appropriate answers are provided and which type of questions are asked. Our results indicate that practitioners need, among other, clarifications about licensing specific software when other licenses are used, and for understanding license content. The results of the study can be useful for educators and employers, organisations that are authoring open source software licenses and developers for understanding the issues faced when using licenses, whereas they are relevant to other software engineering research areas, such as software reusability.

Communication is critical for the software development teams to maintain project awareness, facilitate project co-ordination and avoid misunderstandings. The features offered in the chatrooms, such as private messaging, group conversations, and code sharing help accommodate the communication needs of the software development teams. Therefore, chatrooms have been increasingly adopted among the developers. Since the last study on Slack performed by (Lin et al. 2016), the audience of Slack has more than doubled possibly leading to an evolution of the ways Slack is used; while another rich community formed around Gitter and remains unstudied. In this paper, we perform an investigative study using qualitative and quantitative techniques to gain insights on the use of popular modern chatrooms, specifically Slack and Gitter. Based on the survey responses from 163 developers, the interviews with 21 developers, and the chatroom data collected from 11 Slack and 770 Gitter rooms, we are able to uncover the reasons behind the use of Slack and Gitter, the perceived impact on the associated projects, and the quality determinants of the two chatrooms. We find that the developers seek knowledge from the chatrooms to obtain timely feedback from experts, and in return share their expertise to build the project community and their reputations. Furthermore, it is perceived by the Gitter developers that the chatrooms have an impact on prioritizing the new features and the bug fixes. In Slack, the most reported impact concerns an increased project awareness, in terms of a better tracking of the work progress. As reported on the developers' survey, both Slack and Gitter chat services have a visible impact on mentoring developers, and sharing the best practices. In terms of quality determinants, a non-ephemeral history and a better history management (e.g., advanced search) could be keys for both chat services to reach their full potential.

That open source software comprises an increasingly large percentage of modern software applications has become conventional wisdom. The exact extent to which open source software constitutes today's applications is indeterminate, however, at least by the standards of the academic software engineering research community. This paper proposes a methodology and associated tool that can analyze Java binaries and determine the proportion of open source that comprises them. This paper also presents empirical measurements of 5 commercial Java software systems, reporting OSS proportions between 76.2% to 99.9% among these 5 systems, including a historical analysis covering 6 versions and 12 years for one of the subject systems.

That open source software comprises an increasingly large percentage of modern software applications has become conventional wisdom. The exact extent to which open source software constitutes today's applications is indeterminate, however, at least by the standards of the academic software engineering research community. This paper proposes a methodology and associated tool that can analyze Java binaries and determine the proportion of open source that comprises them. This paper also presents empirical measurements of 5 commercial Java software systems, reporting OSS proportions between 76.2% to 99.9% among these 5 systems, including a historical analysis covering 6 versions and 12 years for one of the subject systems.