In corporate-sponsored open source software development, company-employed developers become “insiders” to the OSS community, and therefore have two roles: they serve as a representative of their employing company, but may also identify as a member of the open source community. This study investigates what happens when identification with the company exceeds identification with the community (and vice versa), and also focuses on consequences when these insider roles come in conflict. Informed by social identity theory and organization-profession conflict theory, we report on two studies that predict identification imbalance to affect company turnover intention. Our first study is based on a survey of employed Linux kernel developers and uses polynomial regression to assess the effect of identification imbalance (and congruence) on company turnover intention. The second study extends our investigation beyond Linux and demonstrates that the effect of identification imbalance on turnover intention is mediated by role conflict. The findings suggest that turnover intention is lowest, when company and community identification match at high rather than low levels. We also find developers’ company career ambition influences how role conflict relates to company turnover intention. This study holds implications for theory and for managers in companies who engage with OSS communities.

Abstract The World Health Organization (WHO) highlights the significant threat that unsustainably long working hours pose to our mental and physical well-being. Aligning with this concern, an Agile principle emphasizes that “Agile processes promote sustainable development.” However, previous work in 2023 debunked this notion of inherent stability in Agile systems, such as the Scrum and Kanban frameworks. In this study, we aim to analyse the relationship between system stability and the tendency of teams to work outside reasonable office hours. We inspect 295 historic Agile projects completed in intive, a software development company. We assess the percentage of late-night, early-morning, or weekend hours where a Product Backlog Item (PBI) was created or resolved and compare this percentage of Unsustainable Hours metric to the Stability Metric and the number of Inventory Days remaining. The analysis showed that almost no correlation exists between the Unsustainable Hours worked and either the system stability or outstanding inventory. These findings indicate that, while working unconventional and potentially excessive hours is a concern, it does not appear to be linked to the stability of Agile systems. This highlights the need for a deeper understanding of individual and team motivations to foster long-term sustainable work practices.

Agile development methods have become a standard in the software industry, including in large-scale projects. These methods share a set of underlying assumptions that distinguish them from more traditional plan-driven approaches. In this article, we adopt Alvesson and Sandberg's problematization approach to challenge three key assumptions that are prevalent in the large-scale agile literature: (1) agile and plan-driven methods are mutually exclusive; (2) self-managing and hierarchically organized teams are mutually exclusive; and (3) agile methods can scale through simple linear composition. Using a longitudinal case study of large-scale agile development, we describe a series of trigger events and episodes whereby the agile approach was tailored to address the needs of the large-scale development context, which was very much at odds with these fundamental assumptions. We develop a set of new underlying assumptions which suggest that agile and plan-driven practices are mutually enabling and necessary for coordination and scaling in large-scale agile projects. We develop nine propositions for large-scale agile projects based on these new alternative underlying assumptions. Finally, we summarize our theoretical contribution in a generic process model of continuously adjusting agile and plan-driven practices in order to accommodate process challenges in large-scale agile projects.

Abstract Agile systems, like the Kanban and Scrum frameworks, are built on assumptions of sustainability and stability, however, there is little empirical evidence on whether such systems are stable in practice or not. Therefore, in this study we aim to inspect the stability of Agile systems by leveraging the concept of stability described in Queueing Theory. We define a novel metric, the Stability Metric, as a way of assessing queueing systems, especially Agile systems. We inspect 926 Jira projects in 14 organizations with over 1.6 million product backlog items using this metric. The analysis showed that 72.89% of these Jira projects were not stable and stable systems, on average, had product backlog sizes 10 times shorter than unstable ones. These results suggest that while the goal of Agile is to create a sustainable, stable way of working, this is not guaranteed, and a better understanding of systems and queues may be required to help design, create, coach, and maintain optimal Agile systems.

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.

Behaviour-Driven Development (BDD) stories have gained considerable attention in recent years as an effective way to specify and test user requirements in agile software development projects. External testing frameworks also allow developers to automate the execution of BDD stories and check whether a fully functional software system behaves as expected. However, other software artifacts may quite often lose synchronization with the stories, and many inconsistencies can arise with respect to requirements representation. This paper reports on preliminary empirical findings regarding the performance of two existing approaches in the literature intended to support consistency assurance between BDD stories and software artifacts. The first approach involves the parsing of BDD stories in order to identify conceptual elements to automatically generate consistent class diagrams, while the second approach seeks to identify interaction elements to automatically assess the consistency of task models and GUI prototypes. We report on the precision of these approaches when applied to a study with BDD stories previously written by Product Owners (POs). Based on the results, we also identify a set of challenges and opportunities for BDD stories in the consistency assurance of such artifacts.

Bitcoin introduced delegation of control over a monetary system from a select few to all who participate in that system. This delegation is known as the decentralization of controlling power and is a powerful security mechanism for the ecosystem. After the introduction of Bitcoin, the field of cryptocurrency has seen widespread attention from industry and academia, so much so that the original novel contribution of Bitcoin, i.e., decentralization, may be overlooked, due to decentralizations’ assumed fundamental existence for the functioning of such crypto-assets. However, recent studies have observed a trend of increased centralization in cryptocurrencies such as Bitcoin and Ethereum. As this increased centralization has an impact the security of the blockchain, it is crucial that it is measured, towards adequate control. This research derives an initial taxonomy of centralization present in decentralized blockchains through rigorous synthesis using a systematic literature review. This is followed by iterative refinement through expert interviews. We systematically analyzed 89 research papers published between 2009 and 2019. Our study contributes to the existing body of knowledge by highlighting the multiple definitions and measurements of centralization in the literature. We identify different aspects of centralization and propose an encompassing taxonomy of centralization concerns. This taxonomy is based on empirically observable and measurable characteristics. It consists of 13 aspects of centralization, classified over six architectural layers: Governance, Network, Consensus, Incentive, Operational, and Application. We also discuss how the implications of centralization can vary depending on the aspects studied. We believe that this review and taxonomy provides a comprehensive overview of centralization in decentralized blockchains involving various conceptualizations and measures.

Large-scale open source communities, such as the Linux kernel, have gone through decades of development, substantially growing in scale and complexity. In the traditional workflow, maintainers serve as "gatekeepers" for the subsystems that they maintain. As the number of patches and authors significantly increases, maintainers come under considerable pressure, which may hinder the operation and even the sustainability of the community. A few subsystems have begun to use new workflows to address these issues. However, it is unclear to what extent these new workflows are successful, or how to apply them. Therefore, we conduct an empirical study on the multiple-committer model (MCM) that has provoked extensive discussion in the Linux kernel community. We explore the effect of the model on the i915 subsystem with respect to four dimensions: pressure, latency, complexity, and quality assurance. We find that after this model was adopted, the burden of the i915 maintainers was significantly reduced. Also, the model scales well to allow more committers. After analyzing the online documents and interviewing the maintainers of i915, we propose that overloaded subsystems which have trustworthy candidate committers are suitable for adopting the model. We further suggest that the success of the model is closely related to a series of measures for risk mitigation---sufficient precommit testing, strict review process, and the use of tools to simplify work and reduce errors. We employ a network analysis approach to locate candidate committers for the target subsystems and validate this approach and contextual success factors through email interviews with their maintainers. To the best of our knowledge, this is the first study focusing on how to scale open source communities. We expect that our study will help the rapidly growing Linux kernel and other similar communities to adapt to changes and remain sustainable.

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.

Crowdsourcing is emerging as an alternative outsourcing strategy which is gaining increasing attention in the software engineering community. However, crowdsourcing software development involves complex tasks which differ significantly from the micro-tasks that can be found on crowdsourcing platforms such as Amazon Mechanical Turk which are much shorter in duration, are typically very simple, and do not involve any task interdependencies. To achieve the potential benefits of crowdsourcing in the software development context, companies need to understand how this strategy works, and what factors might affect crowd participation. We present a multi-method qualitative and quantitative theory-building research study. First, we derive a set of key concerns from the crowdsourcing literature as an initial analytical framework for an exploratory case study in a Fortune 500 company. We complement the case study findings with an analysis of 13,602 crowdsourcing competitions over a ten-year period on the very popular Topcoder crowdsourcing platform. Drawing from our empirical findings and the crowdsourcing literature, we propose a theoretical model of crowd interest and actual participation in crowdsourcing competitions. We evaluate this model using Structural Equation Modeling. Among the findings are that the level of prize and duration of competitions do not significantly increase crowd interest in competitions.

A variety of research methods and techniques are available to SE researchers, and while several overviews exist, there is consistency neither in the research methods covered nor in the terminology used. Furthermore, research is sometimes critically reviewed for characteristics inherent to the methods. We adopt a taxonomy from the social sciences, termed here the ABC framework for SE research, which offers a holistic view of eight archetypal research strategies. ABC refers to the research goal that strives for generalizability over Actors (A) and precise measurement of their Behavior (B), in a realistic Context (C). The ABC framework uses two dimensions widely considered to be key in research design: the level of obtrusiveness of the research and the generalizability of research findings. We discuss metaphors for each strategy and their inherent limitations and potential strengths. We illustrate these research strategies in two key SE domains, global software engineering and requirements engineering, and apply the framework on a sample of 75 articles. Finally, we discuss six ways in which the framework can advance SE research.

Grounded Theory (GT) has proved an extremely useful research approach in several fields including medical sociology, nursing, education and management theory. However, GT is a complex method based on an inductive paradigm that is fundamentally different from the traditional hypothetico-deductive research model. As there are at least three variants of GT, some ostensibly GT research suffers from method slurring, where researchers adopt an arbitrary subset of GT practices that are not recognizable as GT. In this paper, we describe the variants of GT and identify the core set of GT practices. We then analyze the use of grounded theory in software engineering. We carefully and systematically selected 98 articles that mention GT, of which 52 explicitly claim to use GT, with the other 46 using GT techniques only. Only 16 articles provide detailed accounts of their research procedures. We offer guidelines to improve the quality of both conducting and reporting GT studies. The latter is an important extension since current GT guidelines in software engineering do not cover the reporting process, despite good reporting being necessary for evaluating a study and informing subsequent research.

Presents an editorial discusses the current status and activities supported by this publication.

Continuous software engineering refers to the organizational capability to develop, release and learn from software in very short rapid cycles, typically hours, days or a very small numbers of weeks. This requires not only agile processes in teams but in the complete research and development organization. Additionally, the technology used in the different development phases, like requirements engineering and system integration, must support the quick development cycles. Finally, automatic live experimentation for different system alternatives enables fast gathering of required data for decision making. The workshop, the second in the series after the first one at ICSE 2014, aims to bring the research communities of the aforementioned areas together to exchange challenges, ideas, and solutions to bring software engineering a step further to being a holistic continuous process. The workshop program is based on eight papers selected in the peer-review process and supplemented by interaction and discussions at the workshop. The topics range from agile methods, continuous software engineering practices to specific techniques, like visualization and testing.

Crowdsourcing is an emerging and promising approach which involves delegating a variety of tasks to an unknown workforce - the crowd. Crowdsourcing has been applied quite successfully in various contexts from basic tasks on Amazon Mechanical Turk to solving complex industry problems, e.g. InnoCentive. Companies are increasingly using crowdsourcing to accomplish specific software development tasks. However, very little research exists on this specific topic. This paper presents an in-depth industry case study of crowdsourcing software development at a multinational corporation. Our case study highlights a number of challenges that arise when crowdsourcing software development. For example, the crowdsourcing development process is essentially a waterfall model and this must eventually be integrated with the agile approach used by the company. Crowdsourcing works better for specific software development tasks that are less complex and stand-alone without interdependencies. The development cost was much greater than originally expected, overhead in terms of company effort to prepare specifications and answer crowdsourcing community queries was much greater, and the time-scale to complete contests, review submissions and resolve quality issues was significant. Finally, quality issues were pushed later in the lifecycle given the lengthy process necessary to identify and resolve quality issues. Given the emphasis in software engineering on identifying bugs as early as possible, this is quite problematic.

A number of organizations have adopted Open Source Software (OSS) development practices to support or augment their software development processes, a phenomenon frequently referred to as Inner Source . However the adoption of Inner Source is not a straightforward issue. Many organizations are struggling with the question of whether Inner Source is an appropriate approach to software development for them in the first place. This article presents a framework derived from the literature on Inner Source, which identifies nine important factors that need to be considered when implementing Inner Source. The framework can be used as a probing instrument to assess an organization on these nine factors so as to gain an understanding of whether or not Inner Source is suitable. We applied the framework in three case studies at Philips Healthcare, Neopost Technologies, and Rolls-Royce, which are all large organizations that have either adopted Inner Source or were planning to do so. Based on the results presented in this article, we outline directions for future research.

Agile development methods are growing in popularity with a recent survey reporting that more than 80% of organizations now following an agile approach. Agile methods were seen initially as best suited to small, co-located teams developing non-critical systems. The first two constraining characteristics (small and co-located teams) have been addressed as research has emerged describing successful agile adoption involving large teams and distributed contexts. However, the applicability of agile methods for developing safety-critical systems in regulated environments has not yet been demonstrated unequivocally, and very little rigorous research exists in this area. Some of the essential characteristics of agile approaches appear to be incompatible with the constraints imposed by regulated environments. In this study we identify these tension points and illustrate through a detailed case study how an agile approach was implemented successfully in a regulated environment. Among the interesting concepts to emerge from the research are the notions of continuous compliance and living traceability.

Current techniques for modeling software architecture do not provide sufficient support for modeling architectural design rules. This is a problem in the context of model-driven development in which it is assumed that major design artifacts are represented as formal or semi-formal models. This article addresses this problem by presenting an approach to modeling architectural design rules in UML at the abstraction level of the meaning of the rules. The high abstraction level and the use of UML makes the rules both amenable to automation and easy to understand for both architects and developers, which is crucial to deployment in an organization. To provide a proof-of-concept, a tool was developed that validates a system model against the architectural rules in a separate UML model. To demonstrate the feasibility of the approach, the architectural design rules of an existing live industrial-strength system were modeled according to the approach.

It has long been acknowledged that software methods should be tailored if they are to achieve optimum effect. However comparatively little research has been carried out to date on this topic in general, and more notably, on agile methods in particular. This dearth of evidence in the case of agile methods is especially significant in that it is reasonable to expect that such methods would particularly lend themselves to tailoring. In this research, we present a framework based on interviews with 20 senior software development researchers and a review of the extant literature. The framework is comprised of two sets of factors—characteristics of the method, and developer practices—that can improve method tailoring effectiveness. Drawing on the framework, we then interviewed 16 expert XP practitioners to examine the current state and effectiveness of XP tailoring efforts, and to shed light on issues the framework identified as being important. The article concludes with a set of recommendations for research and practice that would advance our understanding of the method tailoring area.

A basic premise of model driven development (MDD) is to capture all important design information in a set of formal or semi-formal models which are then automatically kept consistent by tools. The concept however is still relatively immature and there is little by way of empirically validated guidelines. In this paper we report on the use of MDD on a significant real-world project over several years. Our research found the MDD approach to be deficient in terms of modelling architectural design rules. Furthermore, the current body of literature does not offer a satisfactory solution as to how architectural design rules should be modelled. As a result developers have to rely on time-consuming and error-prone manual practices to keep a system consistent with its architecture. To realise the full benefits of MDD it is important to find ways of formalizing architectural design rules which then allow automatic enforcement of the architecture on the system model. Without this, architectural enforcement will remain a bottleneck in large MDD projects.

Distributed development (DD) of software systems is an issue of increasing significance for organisations today, all the more so given the current trend towards globalisation. In this paper we present a reference model which can be used as a reference point for any company wishing to review their own DD scenario. This is particularised in two forms, one as an exemplar model for a global (GSD) development scenario and one as a particularisation of this for intra-national DD scenarios. By drawing from eight case-studies on DD, we present ten general strategies for successful DD together with our reference model which characterises an ideal DD situation.

In existing global software development (GSD) literature, much focus has been on identifying the challenges that practitioners may face (such as socio-cultural and temporal distance issues), while potential benefits have not been extensively analyzed. We reverse this trend by studying these potential benefits. We question whether they are well-founded assumptions and whether they are attainable in practice. This paper presents findings from a multi-case study at three multi-national companies that have extensive experience in GSD. We identify the benefits mentioned in GSD literature, analyze them with regards to the companies' experiences and then conclude whether or not each benefit is being realized in practice. Our findings reveal that the realization of the assumed benefits cannot be simply taken for granted

Global software development (GSD) is a phenomenon that is receiving considerable interest from companies all over the world. In GSD, stakeholders from different national and organizational cultures are involved in developing software and the many benefits include access to a large labour pool, cost advantage and round-the-clock development. However, GSD is technologically and organizationally complex and presents a variety of challenges to be managed by the software development team. In particular, temporal, geographical and socio-cultural distances impose problems not experienced in traditional systems development. In this paper, we present findings from a case study in which we explore the particular challenges associated with managing GSD. Our study also reveals some of the solutions that are used to deal with these challenges. We do so by empirical investigation at three US based GSD companies operating in Ireland. Based on qualitative interviews we present challenges related to temporal, geographical and socio-cultural distance

The development of information technology (IT) has had a tremendous impact on organisations in recent decades. New information systems (IS) have been introduced into organisations and their effects...

Tailoring of methods is commonplace in the vast majority of software development projects and organisations. However, there is not much known about the tailoring and engineering of agile methods, or about how these methods can be used to complement each other. This study investigated tailoring of the agile methods, eXtreme programming (XP) and Scrum, at Intel Shannon, and involved experienced software engineers who continuously monitored and reflected on these methods over a 3-year period. The study shows that agile methods may individually be incomplete in supporting the overall development process, but XP and Scrum complement each other well, with XP providing support for technical aspects and Scrum providing support for project planning and tracking. The principles of XP and Scrum were carefully selected (only six of the 12 XP key practices were implemented, for example) and tailored to suit the needs of the development environment at Intel Shannon. Thus, the study refutes the suggestion that agile methods are not divisible or individually selectable but achieve their benefits through the synergistic combination of individual agile practices; rather, this study shows that an a la carte selection and tailoring of practices can work very well. In the case of Scrum, some local tailoring has led to a very committed usage by developers, in contrast to many development methods whose usage is limited despite being decreed mandatory by management. The agile practices that were applied did lead to significant benefits, including reductions in code defect density by a factor of 7. Projects of 6-month and 1-year duration have been delivered ahead of schedule, which bodes well for future ability to accurately plan development projects.

The goal of the 5th Workshop on Open Source Software Engineering is to bring together researchers and practitioners for the purpose of building a roadmap of the ways in which various computing application spaces have been impacted by open source software and also by open source development methods, tools and organizational structures.

Building on the success of "Making Sense of the Bazaar" and "Meeting Challenges and Surviving Success" - the 1/sup st/ and 2/sup nd/ Workshops on Open Source Software Engineering (ICSE 2001 and ICSE 2002)-this workshop ("Taking Stock of the Bazaar') brings together researchers and practitioners for the purpose of discussing the diverse array of techniques - as well as supporting tools and social/organizational contexts which can be observed in the domain of open source software.

Open Source Software (OSS) has recently become the focus of considerable interest, yet there remains a need for rigorous analytical inquiry into the subject. This workshop seeks to articulate OSS as an SE paradigm and to address the requirements of OSS in terms of methodology & process, tools & enabling technologies, and human resources & project management. Format: Round-Table Discussion. Size: Maximum 40 participants. Position Papers Required. The Workshop Report will be published in a special issue of IEE Proceedings - Software on Open Source Software Engineering, and workshop participants will be encouraged to submit full research papers based on their position papers for possible inclusion in the special issue.