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.

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.

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.

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.

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.