Accountability promotes responsible behavior, particularly in fulfilling obligations, achieving planned outcomes, and serving the collective good. While systems of accountability are well-structured in corporate environments, their role in open-source communities remains less understood. Existing research has explored requirements-gathering processes and motivations for contributing to open source, focusing on individual benefits. However, there is limited research on how these motivations and processes translate into accountability that guides collective actions to meet the needs of diverse stakeholders. This study examines accountability within the Rust community, particularly during the transition from roadmap-based planning to a goal-oriented process with designated owners within various teams. We provide a rich description, based on meeting notes, project documents and blog posts, as well as 21 interviews with a variety of project participants, to draw lessons about accountability in open source. We found that the Rust roadmapping process facilitated various forms of accountability but lost its effectiveness because (a) unfinished work items on the yearly roadmaps were unavoidable and made the process feel disingenuous; (b) the community culture shifted and facilitated a gradual decline of the roadmapping process; (c) external factors such as the pandemic and layoffs at Mozilla led to changes in the community priorities. Our findings suggest that accountability in open source is an emergent phenomenon that arises from participatory work processes around community engagement and that moral accountability, rather than transactional accountability, is crucial to fostering these processes.

Despite the increasing awareness of the importance of managing technical debt in software product development, systematic processes for implementing technical debt management in software production have not been readily available. In this paper we report on the development and field tests of a normative process framework that systematically incorporates steps for managing technical debt in commercial software production. The framework integrates processes required for technical debt management with existing software quality management processes prescribed by the project management body of knowledge (PMBOK), and it contributes to the further development of software-specific extensions to the PMBOK. We partnered with three commercial software product development organizations to implement the framework in real-world software production settings. All three organizations, irrespective of their varying software process maturity levels, were able to adopt the proposed framework and integrate the prescribed technical debt management processes with their existing software quality management processes. Our longitudinal observations and case-study interviews indicate that the organizations were able to accrue economic benefits from the adoption and use of the integrated framework.

Technical debt, defined as the maintenance obligations arising from shortcuts taken during the design, development, and deployment of software systems, has been shown to significantly impact the reliability and long-term evolution of software systems [1], [2]. Although academic research has moved beyond using technical debt only as a metaphor, and has begun compiling strong empirical evidence on the economic implications of technical debt, industry practitioners continue to find managing technical debt a challenging balancing act [3]. Despite the increasing awareness of the importance of managing technical debt in software product development, systematic processes for implementing technical debt management in software production have not been readily available.

A common problem in large urban cities is the huge number of retail options available. In response, a number of shopping assistance applications have been created for mobile phones. However, these applications mostly allow users to know where stores are or find promotions on specific items. What i

Continuous software process improvement (SPI) practices have been extensively prescribed to improve performance of software projects. However, SPI implementation mechanisms have received little scholarly attention, especially in the context of distributed software product development. We took an action research approach to study the SPI journey of a large multinational enterprise that adopted a distributed product development strategy. We describe the interventions and action research cycles enacted over a period of five years in collaboration with the firm, which resulted in a custom SPI framework that catered to both the social and technical needs of the firm's distributed teams. Institutionalizing the process maturity framework got stalled initially because the SPI initiatives were perceived by product line managers as a mechanism for exercising wider controls by the firm's top management. The implementation mechanism was subsequently altered to co-opt product line managers, which contributed to a wider adoption of the SPI framework. Insights that emerge from our analysis of the firm's SPI journey pertain to the integration of the technical and social views of software development, preserving process diversity through the use of a multi-tiered, non-blueprint approach to SPI, the linkage between key process areas and project control modes, and the role of SPI in aiding organizational learning.

We develop an evolutionary model and theory of software technical debt accumulation to facilitate a rigorous and balanced analysis of its benefits and costs in the context of a large commercial enterprise software package. Our theory focuses on the optimization problem involved in managing technical debt, and illustrates the different tradeoff patterns between software quality and customer satisfaction under early and late adopter scenarios at different lifecycle stages of the software package. We empirically verify our theory utilizing a ten year longitudinal data set drawn from 69 customer installations of the software package. We then utilize the empirical results to develop actionable policies for managing technical debt in enterprise software product adoption.

We describe how we studied, in-situ, the operational processes of three large high process maturity distributed software development companies and discovered three common problems they faced with respect to early stage project cost estimation. We found that project managers faced significant challenges to accurately estimate project costs because the standard metrics-based estimation tools they used (a) did not effectively incorporate diverse distributed project configurations and characteristics, (b) required comprehensive data that was not fully available for all starting projects, and (c) required significant domain experience to derive accurate estimates. To address these challenges, we collaborated with practitioners at the three firms and developed a new learning-oriented and semi-automated early-stage cost estimation solution that was specifically designed for globally distributed software projects. The key idea of our solution was to augment the existing metrics-driven estimation methods with a case repository that stratified past incidents related to project effort estimation issues from the historical project databases at the firms into several generalizable categories. This repository allowed project managers to quickly and effectively “benchmark” their new projects to all past projects across the firms, and thereby learn from them. We deployed our solution at each of our three research sites for real-world field-testing over a period of six months. Project managers of 219 new large globally distributed projects used both our method to estimate the cost of their projects as well as the established metrics-based estimation approaches they were used to. Our approach achieved significantly reduced estimation errors (of up to 60%). This resulted in more than 20% net cost savings, on average, per project - a massive total cost savings across all projects at the three firms!

This study develops and empirically tests the idea that the impact of structural complexity on perfective maintenance of object-oriented software is significantly determined by the team strategy of programmers (independent or collaborative). We analyzed two key dimensions of software structure, coupling and cohesion, with respect to the maintenance effort and the perceived ease-of-maintenance by pairs of programmers. Hypotheses based on the distributed cognition and task interdependence theoretical frameworks were tested using data collected from a controlled lab experiment employing professional programmers. The results show a significant interaction effect between coupling, cohesion, and programmer team strategy on both maintenance effort and perceived ease-of-maintenance. Highly cohesive and low-coupled programs required lower maintenance effort and were perceived to be easier to maintain than the low-cohesive programs and high-coupled programs. Further, our results would predict that managers who strategically allocate maintenance tasks to either independent or collaborative programming teams depending on the structural complexity of software could lower their team's maintenance effort by as much as 70 percent over managers who use simple uniform resource allocation policies. These results highlight the importance of achieving congruence between team strategies employed by collaborating programmers and the structural complexity of software.

In this paper, we examined the impact of project-level configurational choices of globally distributed software teams on project productivity, quality, and profits. Our analysis used data from 362 projects of four different firms. These projects spanned a wide range of programming languages, application domain, process choices, and development sites spread over 15 countries and 5 continents. Our analysis revealed fundamental tradeoffs in choosing configurational choices that are optimized for productivity, quality, and/or profits. In particular, achieving higher levels of productivity and quality require diametrically opposed configurational choices. In addition, creating imbalances in the expertise and personnel distribution of project teams significantly helps increase profit margins. However, a profit-oriented imbalance could also significantly affect productivity and/or quality outcomes. Analyzing these complex tradeoffs, we provide actionable managerial insights that can help software firms and their clients choose configurations that achieve desired project outcomes in globally distributed software development.

In this paper, we study the decision making process involved in the five year lifecycle of a Bluetooth software product produced by a large, multi-national test and measurement firm. In this environment, customer change requests either have to be added as a standard feature in the product, or developed as a special customized version of the product. We first discuss the influential factors, such as evolving standards, market share, installed-base, and complexity, which collectively determined how the firm responded to product change requests. We then develop a predictive decision model to test the collective impact of these factors on determining whether to standardize or customize a customer's change request. Finally, we develop and test a customization cost estimation model, for use by software product teams, which specifically accounts for factors unique to the customization stage of a product lifecycle.

We present the results of a three year field study of the software development process choices made by project teams at two leading offshore vendors. In particular, we focus on the performance implications of project teams that chose to augment structured, plan-driven processes to implement the CMM level-5 key process areas (KPAs) with agile methods. Our analysis of 112 software projects reveals that the decision to augment the firm-recommended, plan-driven approach with improvised, agile methods was significantly affected by the extent of client knowledge and involvement, the newness of technology, and the project size. Furthermore this decision had a significant and mostly positive impact on project performance indicators such as reuse, rework, defect density, and productivity.

In this paper, we present the design and evaluation of a near-field communication-based mobile p2p payment application, called mFerio, that is designed to replace cash-based transactions. We first identify design criteria that payment systems should satisfy and then explain how mFerio, relative to those criteria, improves on the limitations of cash-based systems. We next describe mFerio's implementation and user interface design, focusing on the balance between usability and security. Finally, we present the results of a two-phase user study, involving a total of 104 people, that shows that mFerio has low cognitive load and is also fast, accurate, and easy to use - even outperforming cash in terms of speed and cognitive load in common payment situations.

Software firms are increasingly distributing their software development effort across multiple locations. In this paper we present the results of a two year field study that investigated the effects of dispersion on the productivity and quality of distributed software development. We first develop a model of distributed software development. We then use the model, along with our empirically observed data, to understand the consequences of dispersion on software project performance. Our analysis reveals that, even in high process maturity environments, a) dispersion significantly reduces development productivity and has effects on conformance quality, and b) these negative effects of dispersion can be significantly mitigated through deployment of structured software engineering processes.