Abstract In many application domains, domain-specific languages can allow domain experts to contribute to collaborative projects more correctly and efficiently. To do so, they must be able to understand program structure from reading existing source code. With high-quality data becoming an increasingly important resource, the creation of data pipelines is an important application domain for domain-specific languages. We execute a mixed-method study consisting of a controlled experiment and a follow-up descriptive survey among the participants to understand the effects of a domain-specific language on bottom-up program understanding and generate hypotheses for future research. During the experiment, participants ( $$n=57$$ ) need the same time (Wilcoxon signed-rank test, $$W = 750$$ , $$p =.546$$ , RBC = .093) to solve program structure comprehension tasks, but submit significantly more correct solutions (McNemar’s test, $$\chi ^{2}_{1} = 11.17$$ , $$p = <.001$$ , OR = 4.8) when using the domain-specific language. In the descriptive survey, participants describe reasons related to the programming language itself, such as a better pipeline overview, more enforced code structure, and a closer alignment to the mental model of a data pipeline. In addition, human factors such as less required programming experience and the ability to reuse experience from other data engineering tools are discussed. Based on these results, domain-specific languages are a promising tool for creating data pipelines that can increase correct understanding of program structure and lower barriers to entry for domain experts. Open questions exist to make more informed implementation decisions for domain-specific languages for data pipelines in the future.

Due to the COVID-19 pandemic that broke out in 2020, companies switched to working from home on a large scale. Now, in 2025, many employees are working from home entirely or are only in the office irregularly. This has created a new working environment for many software professionals that resembles both the distributed software development (DSD) and open source software development (OSS) models. While working from home or a hybrid work environment is relatively new for many organizations (about 5 years), the challenges in DSD and OSS development have already been widely researched. Our research question focuses on best practices derived from OSS and DSD that solve the current challenges of working from home. We conducted a qualitative survey and interviewed fifteen individuals who have experience with DSD or OSS development. In this paper, we present fourteen proposed best practices for remote communication, collaboration, management, and tooling. Using the context-problem-solution pattern, we go beyond presenting high-level practices and suggest actionable details. The results of the study provide insights into this topic with high industry relevance. At the same time, the study contributes to existing academic research on working from home and the consequences of the COVID-19 pandemic. • Some OSS and DSD best practices solve current work from home challenges. • Proposed best practices are in management, communication, collaboration, and tooling. • Management - people-oriented management and promotion of autonomous decision making. • Collaboration - parallel processing of multiple tasks and status communication. • Communication - maintaining personal relationships and personal contact. • Tooling - There are a number of tools that best support distributed software development. • Our theory (actionable patterns) may improve work from home in software development.

The design of effective programming languages, libraries, frameworks, tools, and platforms for data engineering strongly depends on their ease and correctness of use. Anyone who ignores that it is humans who use these tools risks building tools that are useless, or worse, harmful. To ensure our data engineering tools are based on solid foundations, we performed a systematic review of common programming mistakes in data engineering. We focus on programming beginners (students) by analyzing both the limited literature specific to data engineering mistakes and general programming mistakes in languages commonly used in data engineering (Python, SQL, Java). Through analysis of 21 publications spanning from 2003 to 2024, we synthesized these complementary sources into a comprehensive classification that captures both general programming challenges and domain-specific data engineering mistakes. This classification provides an empirical foundation for future tool development and educational strategies. We believe our systematic categorization will help researchers, practitioners, and educators better understand and address the challenges faced by novice data engineers.

Microservices are a popular software architectural style that decomposes a large application into smaller services.These microservices integrate at runtime to deliver business value to the users.With an increasing number of microservices, software projects become more difficult to manage.Specifically, maintaining consistent and up-to-date documentation becomes a challenge that can significantly affect the integration efforts in such projects.In this article, we present MSAdoc, an open source tool that helps to prevent documentation from going out-of-date quickly.The tool (1) enables decentralized documentation close to the source code of each microservice and those who have to document it, (2) aggregates documentation centrally across individual microservices to make the documentation accessible in one place and generate higher-order documentation, while (3) supporting technological heterogeneity by relying on the technology-agnostic JSON format.Using a tool like MSAdoc that implements several best practices, practitioners can accommodate the decentralized nature of microservice-based projects and alleviate the problem of maintaining central documentation that quickly becomes outdated.

Abstract Microservices are a popular architectural style that allows systems to be built from a potentially large number of microservices, all of which can be developed independently and by their own teams. As a resulting benefit, development teams can choose the technologies optimal for their microservices, leading to a diversity of different programming languages, frameworks, and further technology in use. However, this heterogeneity presents challenges as it prevents code reuse and complicates moving individuals between microservices due to knowledge hurdles. We performed 15 expert interviews in a qualitative survey to build a theory on how technological heterogeneity can be balanced in microservice architectures to reach a context-dependent compromise between its benefits and drawbacks. We contribute by (1) gathering empirical data from industry professionals on a research topic that has been acknowledged but has only seen limited exploration so far, (2) developing a comprehensive theory of technology heterogeneity as a major integration challenge in microservice-based projects, (3) proposing a framework to overcome the challenge of balancing technological heterogeneity in microservice architectures, (4) optimizing the theory’s presentation for practical use in industry by using the well-known pattern format, and (5) generating research hypotheses to guide and inspire future investigations into this phenomenon.

Vendor-led open source foundations are open source foundations led by software vendors rather than individual developers or end-user organizations. Our research investigates why vendors create or join such foundations, and how these foundations succeed. We conducted exploratory single-case study research, with the LF Edge foundation as our case. We collected qualitative data in the form of interviews and text documents, and performed qualitative data analysis for building our theory. We identified 18 motives of vendors’ participation in vendor-led open source foundations regarding four aspects: revenue, competition, productivity and innovation, and reputation. To understand how vendor-led open source foundations succeed, we investigated good practices followed by LF Edge applied as preventions for potential problems or solutions for encountered problems. We determined 52 good practices in 20 different contexts, focusing on three dimensions: governance, efficiency and productivity, and sustainability.

Microservices have become an important architectural style for building robust and scalable software systems. A system’s functionality is split into independent units, the microservices, that communicate over a network and can be deployed independently. The shift of complexity into the integration layer necessitates enhanced collaboration among stakeholders, stressing the importance of effective communication. We aim to streamline communication between stakeholders in microservice-based projects by constructing a framework for enhanced clarity, a taxonomy, by answering our research question: “How can microservice integration techniques be classified?” We conducted a thematic analysis of literature and six expert interviews to identify microservice integration techniques and construct a taxonomy. The results of this study are (i) a taxonomy for microservice integration techniques consisting of five main and ten refined categories, (ii) the classification of 121 found integration techniques, (iii) an illustration of the taxonomy usage based on three selected techniques to demonstrate the procedure in case of classification ambiguity, (iv) a comparison of data gathered from literature with the interviews, and (v) comprehensive supplementary materials. The taxonomy offers a structured framework to classify microservice integration techniques and enhances the understanding of the diverse landscape of microservice integration techniques, including organizational ones that are often overlooked. Practitioners can discover integration techniques through the taxonomy and apply them with guidance provided in the supplementary materials. • A hierarchical taxonomy of microservice integration techniques was constructed through a thematic analysis of literature and expert interviews. • Main categories: within service, among services, with external systems. • The level of control over the integration counterpart implies the integration effort. • Organizational, procedural, and social aspects require further research. • Practitioners struggle with the steep learning curve of microservices.

Context User-led open source (OS) consortia (foundations) consist of organizations from industries beyond the software industry collaborating to create open-source software solutions for their internal processes . Initially pioneered by higher education organizations in the 2000s, this concept has gained traction in recent years across various industries. Objective This study has two research objectives. The first objective is to provide an overview of the current state of the art in this field by identifying previously studied topics and gathering examples from different industries. The second objective is to understand the structure of user-led OS consortia and the motivations of organizations for participating in such consortia. Method To gain a comprehensive understanding of this phenomenon, we conducted a systematic literature review, covering the years 2000 to 2023. Furthermore, we performed thematic analysis on 43 selected studies to identify and examine the key characteristics, ecosystems, and the benefits organizations gain from involvement in user-led OS consortia. Results We identified 43 unique papers on user-led OS consortia and provided details on 14 sample user-led OS consortia projects. We defined 19 characteristics of user-led OS consortia and 16 benefits for organizations’ involvement. Additionally, we outlined the key actors and their roles in user-led OS consortia. Conclusion We provided an overview of the current state of the art in this field. We identified the structure of user-led OS consortia and the organizations’ motivations for participating in such consortia.

ABSTRACT A large part of data science projects is spent on data engineering. Especially in open data contexts, data quality issues are prevalent and are often tackled by non‐professional programmers. We introduce and evaluate Jayvee, a domain‐specific language for data engineering aimed at reducing barriers to building data pipelines. We show that a structured DSL can have positive effects on speed, ease of use, and quality for data engineering by non‐professional developers. For this, we present an empirical quantitative study, in which we compare the performance of students as proxies for non‐professional programmers using Jayvee with Python and Pandas. We search for reasons for the empirical findings using a follow‐up interview study on how using a DSL changes how non‐professional programmers build data pipelines. Participants solve a subset of tasks faster, more easily, and with higher quality when using Jayvee compared to Python. Interviewees describe tradeoffs regarding the DSL's more limited features, stricter code structure, and explicit descriptions. Jayvee is found to be more approachable, which leads to a more guided development flow. New data engineering languages should provide good tooling and documentation, plan how to visualize intermediate data and consider new development workflows involving tools like ChatGPT to find adoption.

Abstract Requirements traceability (RT) is the ability to link requirements to other software development artifacts. In pre-requirements (pre-RS) traceability, requirements are linked to their origin, such as interviews with stakeholders, meeting protocols, or legacy systems. Compared with post-RS traceability, which links requirements to source code and other later artifacts, pre-RS traceability has seen much less research. This article presents a systematic literature review of pre-RS traceability based on 77 articles published between 1992 and 2022, aiming to provide a comprehensive overview of its use cases, benefits, problems, and solutions. Through the analysis of existing literature, this review identifies gaps for future research and establishes a foundation for future investigations in the field of pre-RS traceability.

The COVID-19 pandemic in 2020/2021/2022 and the resulting lockdowns forced many companies to switch to working from home, swiftly, on a large scale, and without preparation. This situation created unique challenges for software development, where individual software professionals had to shift instantly from working together at a physical venue to working remotely from home. Our research questions focus on the challenges of software professionals who work from home due to the COVID-19 pandemic, which we studied empirically at a German bank. We conducted a case study employing a mixed methods approach. We aimed to cover both the breadth of challenges via a quantitative survey, as well as a deeper understanding of these challenges via the follow-up qualitative analysis of 15 semi-structured interviews. In this article, we present the key impediments employees faced during the crisis, as well as their similarities and differences to the known challenges in distributed software development (DSD). We also analyze the employees’ job satisfaction and how the identified challenges impact job satisfaction. In our study, we focus on challenges in communication, collaboration, tooling, and management. The findings of the study provide insights into this emerging topic of high industry relevance. At the same time, the study contributes to the existing academic research on work from home and on the COVID-19 pandemic aftermath.

Almost all software, open or closed, builds on open source software and therefore needs to comply with the license obligations of the open source code. Not knowing which licenses to comply with poses a legal danger to anyone using open source software. This article investigates the extent of inconsistencies between licenses declared by an open source project at the top level of the repository and the licenses found in the code. We analyzed a sample of 1,000 open source GitHub repositories. We find that about half of the repositories did not fully declare all licenses found in the code. Of these, approximately 10% represented a permissive vs. copyleft license mismatch. Furthermore, existing tools cannot fully identify licences. We conclude that users of open source code should not just look at the declared licenses of the open source code they intend to use, but rather examine the software to understand its actual licenses.

Requirements traceability is the ability to trace requirements to other software engineering artifacts. Traceability can be classified as either pre- or post-requirements specifications (RS) traceability. Pre-RS traceability is the ability to trace between requirements and their origin. However, the benefits of pre-RS traceability are often not clear. In this article, we systematically lay out the benefits of pre-RS traceability. We present results from both a literature review and a qualitative survey of practitioners involved with documenting and utilizing such trace links. We find that the benefits strongly depend on the practitioners, their tasks, and the project environment. Awareness of these relationships supports a clearer understanding of the benefits of pre-RS traceability and thus motivates successful implementation of the required practices. The results of our research motivates the adoption of pre-RS traceability and present problem areas for future research.

Abstract Using qualitative data analysis (QDA) to perform domain analysis and modeling has shown great promise. Yet, the evaluation of such approaches has been limited to single-case case studies. While these exploratory cases are valuable for an initial assessment, the evaluation of the efficacy of QDA to solve the suggested problems is restricted by the common single-case case study research design. Using our own method, called QDAcity-RE, as the example, we present an in-depth empirical evaluation of employing qualitative data analysis for domain modeling using a controlled experiment design. Our controlled experiment shows that the QDA-based method leads to a deeper and richer set of domain concepts discovered from the data, while also being more time efficient than the control group using a comparable non-QDA-based method with the same level of traceability.

We draw on the concept of episodic volunteering (EV) from the general volunteering literature to identify practices for managing EV in free/libre/open source software (FLOSS) communities. Infrequent but ongoing participation is widespread, but the practices that community managers are using to manage EV, and their concerns about EV, have not been previously documented. We conducted a policy Delphi study involving 24 FLOSS community managers from 22 different communities. Our panel identified 16 concerns related to managing EV in FLOSS, which we ranked by prevalence. We also describe 65 practices for managing EV in FLOSS. Almost three-quarters of these practices are used by at least three community managers. We report these practices using a systematic presentation that includes context, relationships between practices, and concerns that they address. These findings provide a coherent framework that can help FLOSS community managers to better manage episodic contributors.

Free/Libre and Open Source Software (FLOSS) communities are composed, in part, of volunteers, many of whom contribute infrequently. However, these infrequent volunteers contribute to the sustainability of FLOSS projects, and should ideally be encouraged to continue participating, even if they cannot be persuaded to contribute regularly. Infrequent contributions are part of a trend which has been widely observed in other sectors of volunteering, where it has been termed “episodic volunteering” (EV). Previous FLOSS research has focused on the Onion model, differentiating core and peripheral developers, with the latter considered as a homogeneous group. We argue this is too simplistic, given the size of the periphery group and the myriad of valuable activities they perform beyond coding. Our exploratory qualitative survey of 13 FLOSS communities investigated what episodic volunteering looks like in a FLOSS context. EV is widespread in FLOSS communities, although not specifically managed. We suggest several recommendations for managing EV based on a framework drawn from the volunteering literature. Also, episodic volunteers make a wide range of value-added contributions other than code, and they should neither be expected nor coerced into becoming habitual volunteers.

Successful Free/Libre and Open Source Software (FLOSS) projects incorporate both habitual and infrequent, or episodic, contributors. Using the concept of episodic volunteering (EV) from the general volunteering literature, we derive a model consisting of five key constructs that we hypothesize affect episodic volunteers' retention in FLOSS communities. To evaluate the model we conducted a survey with over 100 FLOSS episodic volunteers. We observe that three of our model constructs (social norms, satisfaction and community commitment) are all positively associated with volunteers' intention to remain, while the two other constructs (psychological sense of community and contributor benefit motivations) are not. Furthermore, exploratory clustering on unobserved heterogeneity suggests that there are four distinct categories of volunteers: satisfied, classic, social and obligated. Based on our findings, we offer suggestions for projects to incorporate and manage episodic volunteers, so as to better leverage this type of contributors and potentially improve projects' sustainability.

Commercial use of open source software is on the rise as more companies realize the benefits of using FLOSS components in their products. At the same time, the ungoverned use of such components can result in legal, financial, intellectual property, and other risks. To mitigate these risks, companies must govern their use of open source through appropriate processes. This paper presents an initial theory of industry best practices on getting started with open source governance and compliance. Through a qualitative survey, we conducted and analyzed 15 expert interviews in companies with advanced capabilities in open source governance. We also studied practitioner reports on existing practices for introducing FLOSS governance processes. We cast our resulting initial theory in the actionable format of best practice patterns that, when combined, form a practical handbook of getting started with FLOSS governance in companies.

Inner source (IS) is the use of open source software development (SD) practices and the establishment of an open source-like culture within an organization. IS enables and requires developers to collaborate more than traditional SD methods such as plan-driven or agile development. To better understand IS, researchers and practitioners need to measure IS collaboration. However, there is no method yet for doing so. In this paper, we present a method for measuring IS collaboration by measuring the patch-flow within an organization. Patch-flow is the flow of code contributions across organizational boundaries such as project, organizational unit, or profit center boundaries. We evaluate our patch-flow measurement method using case study research with a software developing multi-industry company. By applying the method in the case organization, we evaluate its relevance and viability and discuss its usefulness. We found that about half (47.9%) of all code contributions constitute patch-flow between organizational units, almost all (42.2%) being between organizational units working on different products. Such significant patch-flow indicates high relevance of the patch-flow phenomenon and hence the method presented in this paper. Our patch-flow measurement method is the first of its kind to measure and quantify IS collaboration. It can serve as a base for further quantitative analyses of IS collaboration.

Inner source is an approach to collaboration across intra-organizational boundaries for the creation of shared reusable assets. Prior project reports on inner source suggest improved code reuse and better knowledge sharing. Using a multiple-case case study research approach, we analyze the problems that three major software development organizations were facing in their product line engineering efforts. We find that a root cause, the separation of product units as profit centers from a platform organization as a cost center, leads to delayed deliveries, increased defect rates, and redundant software components. All three organizations assume that inner source can help solve these problems. The article analyzes the expectations that these companies were having towards inner source and the problems they were experiencing in its adoption. Finally, the article presents our conclusions on how these organizations should adapt their existing engineering efforts.

Effective software engineering demands a coordinated effort. Unfortunately, a comprehensive view on developer coordination is rarely available to support software-engineering decisions, despite the significant implications on software quality, software architecture, and developer productivity. We present a fine-grained, verifiable, and fully automated approach to capture a view on developer coordination, based on commit information and source-code structure, mined from version-control systems. We apply methodology from network analysis and machine learning to identify developer communities automatically. Compared to previous work, our approach is fine-grained, and identifies statistically significant communities using order-statistics and a community-verification technique based on graph conductance. To demonstrate the scalability and generality of our approach, we analyze ten open-source projects with complex and active histories, written in various programming languages. By surveying 53 open-source developers from the ten projects, we validate the authenticity of inferred community structure with respect to reality. Our results indicate that developers of open-source projects form statistically significant community structures and this particular view on collaboration largely coincides with developers' perceptions of real-world collaboration.

Detecting and understanding changes between document revisions is an important task. The acquired knowledge can be used to classify the nature of a new document revision or to support a human editor in the review process. While purely textual change detection algorithms offer fine-grained results, they do not understand the syntactic meaning of a change. By representing structured text documents as XML documents we can apply tree-to-tree correction algorithms to identify the syntactic nature of a change.

The organic growth of wikis requires constant attention by contributors who are willing to patrol the wiki and improve its content structure. However, most wikis still only offer textual editing and even wikis which offer WYSIWYG editing do not assist the user in restructuring the wiki. Therefore, "gardening" a wiki is a tedious and error-prone task. One of the main obstacles to assisted restructuring of wikis is the underlying content model which prohibits automatic transformations of the content. Most wikis use either a purely textual representation of content or rely on the representational HTML format. To allow rigorous definitions of transformations we use and extend a Wiki Object Model. With the Wiki Object Model installed we present a catalog of transformations and refactorings that helps users to easily and consistently evolve the content and structure of a wiki. Furthermore we propose XSLT as language for transformation specification and provide working examples of selected transformations to demonstrate that the Wiki Object Model and the transformation framework are well designed. We believe that our contribution significantly simplifies wiki "gardening" by introducing the means of effortless restructuring of articles and groups of articles. It furthermore provides an easily extensible foundation for wiki content transformations.

A fundamental unit of work in programming is the code contribution ("commit") that a developer makes to the code base of the project in work. An author's commit frequency describes how often that author commits. Knowing the distribution of all commit frequencies is a fundamental part of understanding software development processes. This paper presents a detailed quantitative analysis of commit frequencies in open-source software development. The analysis is based on a large sample of open source projects, and presents the overall distribution of commit frequencies.

Design pattern density is a metric that measures how much of an object-oriented design can be understood and represented as instances of design patterns. Expert developers have long believed that a high design pattern density implies a high maturity of the design under inspection. This paper presents a quantifiable and observable definition of this metric. The metric is illustrated and qualitatively validated using four real-world case studies. We present several hypotheses of the metric's meaning and their implications, including the one about design maturity. We propose that the design pattern density of a maturing framework has a fixed point and we show that if software design patterns make learning frameworks easier, a framework's design pattern density is a measure of how much easier it will become.

Current software development tools let developers model a software system and generate program code from the models to run the system. However, generating code and installing a non-trivial system induces a time delay between changing the model and executing it that makes rapid model prototyping awkard if not impossible. This paper presents the architecture of a virtual machine for UML that interprets UML models without any intermediate code-generation step. The paper shows how to embed UML in a metalevel architecture so that a key property of model-based systems, the casual connection between models and model instances, is guaranteed. With this architecture, changes to a model have immediate effects on its execution, providing users with rapid feedback about the model's structure and behavior. This approach supports model innovation better than today's code-generation approaches.

Today, any large object-oriented software system is built using frameworks. Yet, designing frameworks and defining their interaction with clients remains a difficult task. A primary reason is that today's dominant modeling concept, the class, is not well suited to describe the complexity of object collaborations as it emerges in framework design and integration. We use role modeling to overcome the problems and limitations of class-based modeling. Using role models, the design of a framework and its use by clients can be described succinctly and with much better separation of concerns than with classes. Using role objects, frameworks can be integrated into use-contexts that have not been foreseen by their original designers.

Software design patterns are the core abstractions from successful recurring problem solutions in software design. Composite design patterns are the core abstractions from successful recurring frameworks. A composite design pattern is a pattern that is best described as the composition of further patterns the integration of which shows a synergy that makes the composition more than just the sum of its parts. This paper presents examples of composite patterns, discusses a role-based analysis and composition technique, and demonstrates that composite patterns extend the pattern idea from single problem solutions to object-oriented frameworks.

A good reusable framework, pattern or module interface usually is represented by abstract classes. They form an abstract design and leave the implementation to concrete subclasses. The abstract design is instantiated by naming these subclasses. Unfortunately, this exposes implementation details like class names and class tree structures. The paper gives a rationale and a general metaobject protocol design that encapsulates whole class trees. Clients of an abstract design retrieve classes and create objects based on class semantics specifications. Using abstract classes as the only interface enhances information hiding and makes it easier both to evolve a system and to configure system variants.