Abstract With the advancement of AI models, more software systems are adopting AI as a component to facilitate automation. Pre-trained models (PTMs) have become a cornerstone of AI-based software, allowing for rapid integration and development with lower training cost. However, their adoption also introduces failure modes such as data leakage and biased outputs, that may require careful handling by downstream developers. While previous research has proposed taxonomies of these technical concerns and various mitigation strategies, how downstream developers address these issues during the development of general AI-based software when reusing PTMs remains unexplored. Understanding downstream developers’ perspectives is essential because they directly influence how these potential failure concerns translate into practice, such as determining whether immediate risks like data leakage or model bias are recognised, mitigated, or inadvertently overlooked in real-world deployments. This study investigates downstream developers’ concerns, practices and perceived challenges regarding practical AI failures during the development of AI-based software. To achieve this, we conducted a mixed-method study, including interviews with 16 participants, a survey of 86 practitioners, and an analysis of 874 AI incidents from the AI Incident Database. Our results reveal that while developers generally demonstrate strong awareness of potential AI failures, their practices, especially during the preparation and model selection phases, are often inadequate. The lack of concrete guidelines and policies leads to significant variability in the comprehensiveness of their approaches throughout the development lifecycle, with additional challenges such as poor documentation and knowledge gaps, further impeding effective implementation. Based on our findings, we offer suggestions for AI model contributors, developers of AI-based software, researchers, and policy makers to enhance the integration of failure mitigation measures aimed at mitigating direct harms from AI failures.

Large Language Models (LLMs) increasingly automate software engineering tasks. While recent studies highlight the accelerated adoption of “AI as a teammate” in Open Source Software (OSS), developer interaction patterns remain under-explored. In this work, we investigated project-level guidelines and developers’ interactions with AI-assisted pull requests (PRs) by expanding the AIDev dataset to include finer-grained contributor code ownership and a comparative baseline of human-created PRs. We found that over 67.5% of AI-co-authored PRs originate from contributors without prior code ownership. Despite this, the majority of repositories lack guidelines for AI-coding agent usage. Notably, we observed a distinct interaction pattern: AI-co-authored PRs are merged significantly faster with minimal feedback. In contrast to human-created PRs where non-owner developers receive the most feedback, AI-co-authored PRs from non-owners receive the least, with approximately 80% merged without any explicit review. Finally, we discuss implications for developers and researchers.

Pre-trained models (PTMs) have gained widespread popularity and achieved remarkable success across various fields, driven by their groundbreaking performance and easy accessibility through hosting providers. However, the challenges faced by downstream developers in reusing PTMs in software systems are less explored. To bridge this knowledge gap, we qualitatively created and analyzed a dataset of 840 PTM-related issue reports from 31 OSS GitHub projects. We systematically developed a comprehensive taxonomy of PTM-related challenges that developers face in downstream projects. Our study identifies seven key categories of challenges that downstream developers face in reusing PTMs, such as model usage, model performance, and output quality. We also compared our findings with existing taxonomies. Additionally, we conducted a resolution time analysis and, based on statistical tests, found that PTM-related issues take significantly longer to be resolved than issues unrelated to PTMs, with significant variation across challenge categories. We discuss the implications of our findings for practitioners and possibilities for future research.

Fairness is one of the socio-technical concerns that must be addressed in software systems. Considering the popularity of mobile software applications (apps) among a wide range of individuals worldwide, mobile apps with unfair behaviors and outcomes can affect a significant proportion of the global population, potentially more than any other type of software system. Users express a wide range of socio-technical concerns in mobile app reviews. This research aims to investigate fairness concerns raised in mobile app reviews. Our research focuses on AI-based mobile app reviews as the chance of unfair behaviors and outcomes in AI-based mobile apps may be higher than in non-AI-based apps. To this end, we first manually constructed a ground-truth dataset, including 1,132 fairness and 1,473 non-fairness reviews. Leveraging the ground-truth dataset, we developed and evaluated a set of machine learning and deep learning models that distinguish fairness reviews from non-fairness reviews. Our experiments show that our best-performing model can detect fairness reviews with a precision of 94%. We then applied the best-performing model on approximately 9.5M reviews collected from 108 AI-based apps and identified around 92K fairness reviews. Next, applying the K-means clustering technique to the 92K fairness reviews, followed by manual analysis, led to the identification of six distinct types of fairness concerns (e.g., “receiving different quality of features and services in different platforms and devices” and “lack of transparency and fairness in dealing with user-generated content” ). Finally, the manual analysis of 2,248 app owners’ responses to the fairness reviews identified six root causes (e.g., “copyright issues”) that app owners report to justify fairness concerns.

README files play an important role in providing installation-related instructions to software users and are widely used in open source software systems on platforms such as GitHub. Software projects evolve rapidly alongside their dependencies in dynamic software ecosystems, requiring frequent updates to installation instructions. These instructions are crucial for users to start with a software project. Despite their significance, there is a lack of systematic understanding regarding the documentation efforts invested in README files and the triggers behind them. To fill the research gap, we conducted a qualitative study, investigating 400 GitHub repositories with 1,163 README commits that focused on updates in installation-related sections. Our research revealed six major categories of changes in the README commits, namely pre-installation instructions, installation instructions, post-installation instructions, help information updates, document presentation, and external resource management. We further provide detailed insights into modification behaviours and offer examples of these updates. We also studied the triggers for the documentation updates, which led to three categories including errors in the previous documentation, changes in the codebase, and need for documentation improvement. Based on our findings, we proposed a README template tailored to cover the installation-related sections for documentation maintainers to reference when updating documents. We further validated this template by conducting an online survey and a pull request study, identifying that documentation readers find the augmented documents based on our template to be generally of better quality, and documentation maintainers find it useful. We further provide recommendations to practitioners for maintaining their README files, as well as motivations for future research directions. These recommendations encompass completeness, correctness and up-to-dateness, and information presentation considerations. The proposed research directions include the development of automated tools, in particular for documentation updates, and conducting empirical studies to enhance comprehension of the needs of documentation users.

Background: The development of AI-enabled software heavily depends on AI model documentation, such as model cards, due to different domain expertise between software engineers and model developers. From an ethical standpoint, AI model documentation conveys critical information on ethical considerations along with mitigation strategies for downstream developers to ensure the delivery of ethically compliant software. However, knowledge on such documentation practice remains scarce. Aims: The objective of our study is to investigate how developers document ethical aspects of open source AI models in practice, aiming at providing recommendations for future documentation endeavours. Method: We selected three sources of documentation on GitHub and Hugging Face, and developed a keyword set to identify ethics-related documents systematically. After filtering an initial set of 2,347 documents, we identified 265 relevant ones and performed thematic analysis to derive the themes of ethical considerations. Results: Six themes emerge, with the three largest ones being model behavioural risks, model use cases, and model risk mitigation. Conclusions: Our findings reveal that open source AI model documentation focuses on articulating ethical problem statements and use case restrictions. We further provide suggestions to various stakeholders for improving documentation practice regarding ethical considerations.

Self-Admitted Technical Debt (SATD) encompasses a wide array of sub-optimal design and implementation choices reported in software artefacts (e.g., code comments and commit messages) by developers themselves. Such reports have been central to the study of software maintenance and evolution over the last decades. However, they can also be deemed as dreadful sources of information on potentially exploitable vulnerabilities and security flaws. Objective: This work investigates the security implications of SATD from a technical and developer-centred perspective. On the one hand, it analyses whether security pointers disclosed inside SATD sources can be used to characterise vulnerabilities in Open-Source Software (OSS) projects and repositories. On the other hand, it delves into developers' perspectives regarding the motivations behind this practice, its prevalence, and its potential negative consequences. Method: We followed a mixed-methods approach consisting of (i) the analysis of a preexisting dataset containing 8,812 SATD instances and (ii) an online survey with 222 OSS practitioners. Results: We gathered 201 SATD instances through the dataset analysis and mapped them to different Common Weakness Enumeration (CWE) identifiers. Overall, 25 different types of CWEs were spotted across commit messages, pull requests, code comments, and issue sections, from which 8 appear among MITRE's Top-25 most dangerous ones. The survey shows that software practitioners often place security pointers across SATD artefacts to promote a security culture among their peers and help them spot flaky code sections, among other motives. However, they also consider such a practice risky as it may facilitate vulnerability exploits. Implications: Our findings suggest that preserving the contextual integrity of security pointers disseminated across SATD artefacts is critical to safeguard both commercial and OSS solutions against zero-day attacks.

Abstract Psychological safety continues to pique the interest of scholars in a variety of disciplines of study. Recent research indicates that psychological safety fosters knowledge sharing and norm clarity and complements agile values. Although software quality remains a concern in the software industry, academics have yet to investigate whether and how psychologically safe teams provide superior results. In this study, we explore how psychological safety influences agile teams’ quality-related behaviors aimed at enhancing software quality. To widen the empirical coverage and evaluate the results, we chose a two-phase mixed-methods research design with an exploratory qualitative phase (20 interviews) followed by a quantitative phase (survey study, N = 423). Our findings show that, when psychological safety is established in agile software teams, it induces enablers of a social nature that advance the teams’ ability to pursue software quality. For example, admitting mistakes and taking initiatives equally help teams learn and invest their learning in their future decisions related to software quality. Past mistakes become points of reference for avoiding them in the future. Individuals become more willing to take initiatives aimed at enhancing quality practices and mitigating software quality issues. We contribute to our endeavor to understand the circumstances that promote software quality. Psychological safety requires organizations, their management, agile teams, and individuals to maintain and propagate safety principles. Our results also suggest that technological tools and procedures can be utilized alongside social strategies to promote software quality.

Mobile software apps ("apps") are one of the prevailing digital technologies that our modern life heavily depends on. A key issue in the development of apps is how to design gender-inclusive apps. Apps that do not consider gender inclusion, diversity, and equality in their design can create barriers (e.g., excluding some of the users because of their gender) for their diverse users. While there have been some efforts to develop gender-inclusive apps, a lack of deep understanding regarding user perspectives on gender may prevent app developers and owners from identifying issues related to gender and proposing solutions for improvement. Users express many different opinions about apps in their reviews, from sharing their experiences, and reporting bugs, to requesting new features. In this study, we aim at unpacking gender discussions about apps from the user perspective by analysing app reviews. We first develop and evaluate several Machine Learning (ML) and Deep Learning (DL) classifiers that automatically detect gender reviews (i.e., reviews that contain discussions about gender). We apply our ML and DL classifiers on a manually constructed dataset of 1,440 app reviews from the Google App Store, composing 620 gender reviews and 820 non-gender reviews. Our best classifier achieves an F1-score of 90.77%. Second, our qualitative analysis of a randomly selected 388 out of 620 gender reviews shows that gender discussions in app reviews revolve around six topics: App Features, Appearance, Content, Company Policy and Censorship, Advertisement, and Community. Finally, we provide some practical implications and recommendations for developing gender-inclusive apps.

Software documentation captures detailed knowledge about a software product, e.g., code, technologies, and design. It plays an important role in the coordination of development teams and in conveying ideas to various stakeholders. However, software documentation can be hard to comprehend if it is written with jargon and complicated sentence structure. In this study, we explored the potential of text simplification techniques in the domain of software engineering to automatically simplify GitHub README files. We collected software-related pairs of GitHub README files consisting of 14,588 entries, aligned difficult sentences with their simplified counterparts, and trained a Transformer-based model to automatically simplify difficult versions. To mitigate the sparse and noisy nature of the software-related simplification dataset, we applied general text simplification knowledge to this field. Since many general-domain difficult-to-simple Wikipedia document pairs are already publicly available, we explored the potential of transfer learning by first training the model on the Wikipedia data and then fine-tuning it on the README data. Using automated BLEU scores and human evaluation, we compared the performance of different transfer learning schemes and the baseline models without transfer learning. The transfer learning model using the best checkpoint trained on a general topic corpus achieved the best performance of 34.68 BLEU score and statistically significantly higher human annotation scores compared to the rest of the schemes and baselines. We conclude that using transfer learning is a promising direction to circumvent the lack of data and drift style problem in software README files simplification and achieved a better trade-off between simplification and preservation of meaning.

Social engineering cyber-attacks such as phishing emails pose a serious threat to the safety of many organizations. Given that the effectiveness of these attacks heavily relies on poor human decision making, an improved understanding of the individual characteristics that increase cybersecurity vulnerability could inform more targeted training. The current study aimed to identify whether several factors, including phishing email detection ability, confidence in one's phishing identification decisions, general attitudes towards one's level of responsibility and efficacy, and employee satisfaction and loyalty to the organization, may predict behavior in a naturalistic phishing simulation in an employment setting. We followed up employees of a large organization who had been recently targeted by a phishing simulation and asked them to complete a survey that included a phishing detection task. The employees’ behavior in the phishing simulation was ranked according to its safety: reporting the suspicious email, neither reporting nor clicking on the embedded link, and clicking on the link. We found that fewer years of employment at the organization and lower employee satisfaction and loyalty predicted increasingly unsafe behavior in the simulation. This suggests that newer and unsatisfied employees are most vulnerable to phishing attempts and might benefit most from targeted cybersecurity training.

Psychological safety continues to inspire researchers’ curiosity in various fields of study. It has been shown to enhance teams’ performance, efficiency, and learning, among other corollaries. Researchers are stretching the boundaries of these early findings to identify further effects of psychological safety. Recent work shows that psychological safety promotes knowledge sharing, norm clarity, and complements agile values. Studies show that psychological safety enhance agile values and practices, and some practitioners went as far as to claim “agile doesn’t work without psychological safety.” Yet, researchers have not explored its antecedents. In this study, we sought to understand how psychological safety materializes in agile software development teams. We opted for a two-phase mixed-methods study; an exploratory qualitative phase (18 interviews) followed by a quantitative phase (survey study, N = 365) to broaden the empirical coverage and test phase one’s findings. Our findings show that psychological safety is established in agile software teams when individuals, the team, and the leadership adopt and promote strategies conducive to promoting a psychologically safe workplace. While openness and no blame towards team members are the “butter and bread” of psychological safety, collective-decision making within the team and the leadership ownership remain the pillars of a psychologically safe workplace. Conversely, team autonomy, technical practices providing a safety net and slack time were not found to promote psychological safety. To institutionalize psychological safety in agile software teams, individuals, teams, and the leadership should consolidate their effort to adopt no blame, openness, collective decision-making in the team, and assuming the ownership of promoting a psychologically safe workplace.

Several studies have shown that automated support for different activities of the security patch management process has great potential for reducing delays in installing security patches. However, it is also important to understand how automation is used in practice, its limitations in meeting real-world needs and what practitioners really need, an area that has not been empirically investigated in the existing software engineering literature. This paper reports an empirical study aimed at investigating different aspects of automation for security patch management using semi-structured interviews with 17 practitioners from three different organisations in the healthcare domain. The findings are focused on the role of automation in security patch management for providing insights into the as-is state of automation in practice, the limitations of current automation, how automation support can be enhanced to effectively meet practitioners’ needs, and the role of the human in an automated process. Based on the findings, we have derived a set of recommendations for directing future efforts aimed at developing automated support for security patch management.

Numerous security attacks that resulted in devastating consequences can be traced back to a delay in applying a security patch. Despite the criticality of timely patch application, not much is known about why and how delays occur when applying security patches in practice, and how the delays can be mitigated. Based on longitudinal data collected from 132 delayed patching tasks over a period of four years and observations of patch meetings involving eight teams from two organisations in the healthcare domain, and using quantitative and qualitative data analysis approaches, we identify a set of reasons relating to technology, people and organisation as key explanations that cause delays in patching. Our findings also reveal that the most prominent cause of delays is attributable to coordination delays in the patch management process and a majority of delays occur during the patch deployment phase. Towards mitigating the delays, we describe a set of strategies employed by the studied practitioners. This research serves as the first step toward understanding the practical reasons for delays and possible mitigation strategies in vulnerability patch management. Our findings provide useful insights for practitioners to understand what and where improvement is needed in the patch management process and guide them towards taking timely actions against potential attacks. Also, our findings help researchers to invest effort into designing and developing computer-supported tools to better support a timely security patch management process.

Background: Security tools play a vital role in enabling developers to build secure software. However, it can be quite challenging to introduce and fully leverage security tools without affecting the speed or frequency of deployments in the DevOps paradigm. Aims: We aim to empirically investigate the key challenges practitioners face when integrating security tools into a DevOps workflow in order to provide recommendations for overcoming the challenges. Method: We conducted a study involving 31 systematically selected webinars on integrating security tools in DevOps. We used a qualitative data analysis method, i.e., thematic analysis, to identify the challenges and emerging solutions related to integrating security tools in rapid deployment environments. Results: We find that whilst traditional security tools are unable to cater for the needs of DevOps, the industry is moving towards new generations of security tools that have started focusing on the needs of DevOps. We have developed a DevOps workflow that integrates security tools and a set of guidelines by synthesizing practitioners' recommendations in the analyzed webinars. Conclusion: Whilst the latest security tools are addressing some of the requirements of DevOps, there are many tool-related drawbacks yet to be adequately addressed.

Several disastrous security attacks can be attributed to delays in patching software vulnerabilities. While researchers and practitioners have paid significant attention to automate vulnerabilities identification and patch development activities of software security patch management, there has been relatively little effort dedicated to gain an in-depth understanding of the socio-technical aspects, e.g., coordination of interdependent activities of the patching process and patching decisions, that may cause delays in applying security patches. We report on a Grounded Theory study of the role of coordination in security patch management. The reported theory consists of four inter-related dimensions, i.e., causes, breakdowns, constraints, and mechanisms. The theory explains the causes that define the need for coordination among interdependent software/hardware components and multiple stakeholders’ decisions, the constraints that can negatively impact coordination, the breakdowns in coordination, and the potential corrective measures. This study provides potentially useful insights for researchers and practitioners who can carefully consider the needs of and devise suitable solutions for supporting the coordination of interdependencies involved in security patch management.

Mobile apps exploit embedded sensors and wireless connectivity of a device to empower users with portable computations, context-aware communication, and enhanced interaction. Specifically, mobile health apps (mHealth apps for short) are becoming integral part of mobile and pervasive computing to improve the availability and quality of healthcare services. Despite the offered benefits, mHealth apps face a critical challenge, i.e., security of health-critical data that is produced and consumed by the app. Several studies have revealed that security specific issues of mHealth apps have not been adequately addressed. The objectives of this study are to empirically (a) investigate the challenges that hinder development of secure mHealth apps, (b) identify practices to develop secure apps, and (c) explore motivating factors that influence secure development. We conducted this study by collecting responses of 97 developers from 25 countries - across 06 continents - working in diverse teams and roles to develop mHealth apps for Android, iOS, and Windows platform. Qualitative analysis of the survey data is based on (i) 8 critical challenges, (ii) taxonomy of best practices to ensure security, and (iii) 6 motivating factors that impact secure mHealth apps. This research provides empirical evidence as practitioners' view and guidelines to develop emerging and next generation of secure mHealth apps.

Context: With the growing popularity of rapid software delivery and deployment, the methods, practices and technologies of Continuous Software Engineering (CSE) are evolving steadily. This creates the need for understanding the recent trends of the technologies, practitioners' challenges and views in this domain. Objective: In this paper, we present an empirical study aimed at exploring CSE from the practitioners' perspective by mining discussions from Q&A websites. Method: We have analyzed 12,989 questions and answers posted on Stack Overflow. Topic modelling is conducted to derive the dominant topics in this domain. Further, a qualitative analysis was conducted to identify the key challenges discussed. Findings: Whilst the trend of posted questions is sharply increasing, the questions are becoming more specific to technologies and more difficult to attract answers. We identified 32 topics of discussions, among which "Error messages in Continuous Integration/Deployment" and "Continuous Integration concepts" are the most dominant. We also present the most challenging areas in this domain from the practitioners' perspectives.

Mobile systems offer portable and interactive computing, empowering users, to exploit a multitude of context-sensitive services, including mobile healthcare. Mobile health applications (i.e., mHealth apps) are revolutionizing the healthcare sector by enabling stakeholders to produce and consume healthcare services. A widespread adoption of mHealth technologies and rapid increase in mHealth apps entail a critical challenge, i.e., lack of security awareness by end-users regarding health-critical data. This paper presents an empirical study aimed at exploring the security awareness of end-users of mHealth apps. We collaborated with two mHealth providers in Saudi Arabia to gather data from 101 end-users. The results reveal that despite having the required knowledge, end-users lack appropriate behaviour , i.e., reluctance or lack of understanding to adopt security practices, compromising health-critical data with social, legal, and financial consequences. The results emphasize that mHealth providers should ensure security training of end-users (e.g., threat analysis workshops), promote best practices to enforce security (e.g., multi-step authentication), and adopt suitable mHealth apps (e.g., trade-offs for security vs usability). The study provides empirical evidence and a set of guidelines about security awareness of mHealth apps.

Context: Governments are providing more and more support for academia-industry collaborations for industry led research and innovation via Cooperative Research Centers (CRC). It is important to understand the processes and practices of such programs for transferring scientific R&D to innovation. Goal: We aimed at empirically investigating the processes and practices implemented in the context of one of the Australian CRCs, aimed at transferring big data research to innovative software solutions for national security. Method: We applied case study method and collected and analyzed data from 17 interviews and observations of the participants of the studied CRC program. Findings: We present the innovation process implemented in the studied CRC. We particularly highlight the practices used to involve end-users in the innovation process. We further elaborate on the challenges of running this collaborative model for software technology innovation.

Context: Continuous Delivery and Deployment (CD) practices aim to deliver software features more frequently and reliably. While some efforts have been made to study different aspects of CD practices, a little empirical work has been reported on the impact of CD on team structures, collaboration and team members' responsibilities. Goal: Our goal is to empirically investigate how Development (Dev) and Operations (Ops) teams are organized in software industry for adopting CD practices. Furthermore, we explore the potential impact of practicing CD on collaboration and team members' responsibilities. Method:We conducted a mixed-method empirical study, which collected data from 21 in-depth, semi-structured interviews in 19 organizations and a survey with 93 software practitioners. Results: There are four common types of team structures (i.e., (1) separate Dev and Ops teams with higher collaboration; (2) separate Dev and Ops teams with facilitator(s) in the middle; (3) small Ops team with more responsibilities for Dev team; (4) no visible Ops team) for organizing Dev and Ops teams to effectively initiate and adopt CD practices. Our study also provides insights into how software organizations actually improve collaboration among teams and team members for practicing CD. Furthermore, we highlight new responsibilities and skills (e.g., monitoring and logging skills), which are needed in this regard.

Continuous Deployment (CD) has emerged as a new practice in the software industry to continuously and automatically deploy software changes into production. Continuous Deployment Pipeline (CDP) supports CD practice by transferring the changes from the repository to production. Since most of the CDP components run in an environment that has several interfaces to the Internet, these components are vulnerable to various kinds of malicious attacks. This paper reports our work aimed at designing secure CDP by utilizing security tactics. We have demonstrated the effectiveness of five security tactics in designing a secure pipeline by conducting an experiment on two CDPs - one incorporates security tactics while the other does not. Both CDPs have been analyzed qualitatively and quantitatively. We used assurance cases with goal-structured notations for qualitative analysis. For quantitative analysis, we used penetration tools. Our findings indicate that the applied tactics improve the security of the major components (i.e., repository, continuous integration server, main server) of a CDP by controlling access to the components and establishing secure connections.

Context: A growing number of software organizations have been adopting Continuous DElivery (CDE) and Continuous Deployment (CD) practices. Researchers have started investing significant efforts in studying different aspects of CDE and CD. Many studies refer to CDE (i.e., where an application is potentially capable of being deployed) and CD (i.e., where an application is automatically deployed to production on every update) as synonyms and do not distinguish them from each other. Despite CDE being successfully adopted by a large number of organizations, it is not empirically known why organizations still are unable or demotivated to have automatic and continuous deployment (i.e., CD practice). Goal: This study aims at empirically investigating and classifying the factors that may impact on adopting and implementing CD practice. Method: We conducted a mixed-method empirical study consisting of interviewing 21 software practitioners, followed by a survey with 98 respondents. Results: Our study reveals 11 confounding factors that limit or demotivate software organizations to push changes automatically and continuously to production. The most important ones are "lack of automated (user) acceptance test", "manual quality check", "deployment as business decision", "insufficient level of automated test coverage", and "highly bureaucratic deployment process". Conclusion: Our findings highlight several areas for future research and provide suggestions for practitioners to streamline deployment process.

Context: Software engineering is a knowledge intensive activity that is supported by documenting and sharing the required knowledge through a wide variety of artifacts. Global Software Development (GSD) teams heavily rely on artifacts as a vital means of knowledge sharing. However, there is little empirical knowledge about the key reasons and practices of using artifacts in GSD for knowledge sharing to support common understanding of technical specifications. Objective: This study aims at empirically studying the key motivators, practices, and drawbacks of artifact-based knowledge sharing for achieving common understanding of technical specifications in the context of GSD. Method: We conducted an exploratory case study in an organization that was involved in several GSD projects. Results: Our findings revealed the key challenges that necessitated the use of artifacts for sharing technical specification knowledge. We also present the practices that make up the artifact-based knowledge sharing system in the studied case. Finally, we shed some light on the caveats of knowledge sharing practices adopted by the studied company. The findings can provide useful insights into the artifact-based knowledge sharing practices and how it can be complemented by having certain level of social ties among distributed team members, even through asynchronous means.

Shared understanding of Software Engineering (SE) processes, that we call process knowing, is required for effective communication and coordination and communication within a team in order to improve team performance. SE Process knowledge can include roles, responsibilities and flow of information over a project lifecycle. Developing and sustaining process knowledge can be more challenging in Global Software Development (GSD). GSD distances can limit the ability of a team to develop a common understanding of processes. Anecdotes of the problems caused by lack of common understanding of processes in GSD are pervasive, but there is no reported empirical effort aimed at exploring the solutions to enable process knowing in GSD. We report a case study aimed at understanding an effort to enable process knowing for improving processes in GSD. The findings provide useful insights into the potential challenges of lack of process knowing and how an organization can enable process knowing for achieving the desired results that also help in increasing social interactions and positive behavioral changes.

Growing popularity of Global Software Development (GSD) has resulted in an increasing number of cross-organizational teams that are formed according to Extended Team Model (ETM). There is little known about the structures (work, social, and communication) that may exist in ETM and what affordances those structures provide to support collaboration and coordination. This paper reports a case study that has studied the structures of an ETM in GSD and how those structures provide affordances for dealing with known GSD challenges. This study has revealed that whilst the current structures in the studied team help deal with different GSD challenges, these structures appear to have certain challenges inherent in them and the affordances they provide. We make a few recommendations for improving the current structures to deal with the observed challenges. Our findings are expected to provide insights into the types of structures and associated challenges for implementing ETM in GSD.