diffusion models

Do software firms collaborate or compete? A model of coopetition in community-initiated OSS projects

[Background] An increasing number of commercial firms are participating in Open Source Software (OSS) projects to reduce their development cost and increase technical innovativeness. When collaborating with other firms whose sought values are conflicts of interests, firms may behave uncooperatively leading to harmful impacts on the common goal. [Aim] This study explores how software firms both collaborate and compete in OSS projects. [Method] We adopted a mixed research method on three OSS projects. [Result] We found that commercial firms participating in community-initiated OSS projects collaborate in various ways across the organizational boundaries. While most of firms contribute little, a small number of firms that are very active and account for large proportions of contributions. We proposed a conceptual model to explain for coopetition among software firms in OSS projects. The model shows two aspects of coopetition can be managed at the same time based on firm gatekeepers. [Conclusion] Firms need to operationalize their coopetition strategies to maximize value gained from participating in OSS projects.

Implementing Ethics in AI: An industrial multiple case study

Solutions in artificial intelligence (AI) are becoming increasingly widespread in system development endeavors. As the AI systems affect various stakeholders due to their unique nature, the growing influence of these systems calls for eth-ical considerations. Academic discussion and practical examples of autonomous system failures have highlighted the need for implementing ethics in software development. However, research on methods and tools for implementing ethics into AI system design and development in practice is still lacking. This paper be-gins to address this focal problem by providing a baseline for ethics in AI based software development. This is achieved by reporting results from an industrial multiple case study on AI systems development in the health care sector. In the context of this study, ethics were perceived as interplay of transparency, re-sponsibility and accountability, upon which research model is outlined. Through these cases, we explore the current state of practice out on the field in the ab-sence of formal methods and tools for ethically aligned design. Based on our data, we discuss the current state of practice and outline existing good practic-es, as well as suggest future research directions in the area.

Continuous experimentation on artificial intelligence software: a research agenda

Moving from experiments to industrial level AI software development requires a shift from understanding AI/ ML model attributes as a standalone experiment to know-how integrating and operating AI models in a large-scale software system. It is a growing demand for adopting state-of-the-art software engineering paradigms into AI development, so that the development efforts can be aligned with business strategies in a lean and fast-paced manner. We describe AI development as an “unknown unknown” problem where both business needs and AI models evolve over time. We describe a holistic view of an iterative, continuous approach to develop industrial AI software basing on business goals, requirements and Minimum Viable Products. From this, five areas of challenges are presented with the focus on experimentation. In the end, we propose a research agenda with seven questions for future studies.

Time for AI (Ethics) Maturity Model Is Now

There appears to be a common agreement that ethical concerns are of high importance when it comes to systems equipped with some sort of Artificial Intelligence (AI). Demands for ethical AI are declared from all directions. As a response, in recent years, public bodies, governments, and universities have rushed in to provide a set of principles to be considered when AI based systems are designed and used. We have learned, however, that high-level principles do not turn easily into actionable advice for practitioners. Hence, also companies are publishing their own ethical guidelines to guide their AI development. This paper argues that AI software is still software and needs to be approached from the software development perspective. The software engineering paradigm has introduced maturity model thinking, which provides a roadmap for companies to improve their performance from the selected viewpoints known as the key capabilities. We want to voice out a call for action for the development of a maturity model for AI software. We wish to discuss whether the focus should be on AI ethics or, more broadly, the quality of an AI system, called a maturity model for the development of AI systems.

Conducting B2B SaaS Business with a Freemium Model: A Case Study

A survey study on major technical barriers affecting the decision to adopt cloud services

In the context of cloud computing, risks associated with underlying technologies, risks involving service models and outsourcing, and enterprise readiness have been recognized as potential barriers for the adoption. To accelerate cloud adoption, the concrete barriers negatively influencing the adoption decision need to be identified. Our study aims at understanding the impact of technical and security-related barriers on the organizational decision to adopt the cloud. We analyzed data collected through a web survey of 352 individuals working for enterprises consisting of decision makers as well as employees from other levels within an organization. The comparison of adopter and non-adopter sample reveals three potential adoption inhibitor, security, data privacy, and portability. The result from our logistic regression analysis confirms the criticality of the security concern, which results in an up to 26-fold increase in the non-adoption likelihood. Our study underlines the importance of the technical and security perspectives for research investigating the adoption of technology.

Software Startups - A Research Agenda

Software startup companies develop innovative, software-intensive products within limited timeframes and with few resources, searching for sustainable and scalable business models. Software startup ...

Product Innovation through Internal Startup in Large Software Companies: A Case Study

Product innovation is a risky activity, but when successful, it enables large software companies accrue high profits and leapfrog the competition. Internal startups have been promoted as one way to foster product innovation in large companies, which allows them to innovate as startups do. However, internal startups in large companies are challenging endeavours despite of the promised benefits. How large software companies can leverage internal startups in software product innovation is not fully understood due to the scarcity of the relevant studies. Based on a conceptual framework that combines the elements from the Lean startup approach and an internal corporate venturing model, we conducted a case study of a large software company to examine how a new product was developed through the internal startup effort and struggled to achieve the desired outcomes set by the management. As a result, the conceptual framework was further developed into a Lean startup-enabled new product development model for large software companies.

“Failures” to be celebrated: an analysis of major pivots of software startups

In the context of software startups, project failure is embraced actively and considered crucial to obtain validated learning that can lead to pivots. A pivot is the strategic change of a business concept, product or the different elements of a business model. A better understanding is needed on different types of pivots and different factors that lead to failures and trigger pivots, for software entrepreneurial teams to make better decisions under chaotic and unpredictable environment. Due to the nascent nature of the topic, the existing research and knowledge on the pivots of software startups are very limited. In this study, we aimed at identifying the major types of pivots that software startups make during their startup processes, and highlighting the factors that fail software projects and trigger pivots. To achieve this, we conducted a case survey study based on the secondary data of the major pivots happened in 49 software startups. 10 pivot types and 14 triggering factors were identified. The findings show that customer need pivot is the most common among all pivot types. Together with customer segment pivot, they are common market related pivots. The major product related pivots are zoom-in and technology pivots. Several new pivot types were identified, including market zoom-in, complete and side project pivots. Our study also demonstrates that negative customer reaction and flawed business model are the most common factors that trigger pivots in software startups. Our study extends the research knowledge on software startup pivot types and pivot triggering factors. Meanwhile it provides practical knowledge to software startups, which they can utilize to guide their effective decisions on pivoting.

Software Development in Startup Companies: The Greenfield Startup Model

Software startups are newly created companies with no operating history and oriented towards producing cutting-edge products. However, despite the increasing importance of startups in the economy, few scientific studies attempt to address software engineering issues, especially for early-stage startups. If anything, startups need engineering practices of the same level or better than those of larger companies, as their time and resources are more scarce, and one failed project can put them out of business. In this study we aim to improve understanding of the software development strategies employed by startups. We performed this state-of-practice investigation using a grounded theory approach. We packaged the results in the Greenfield Startup Model (GSM), which explains the priority of startups to release the product as quickly as possible. This strategy allows startups to verify product and market fit, and to adjust the product trajectory according to early collected user feedback. The need to shorten time-to-market, by speeding up the development through low-precision engineering activities, is counterbalanced by the need to restructure the product before targeting further growth. The resulting implications of the GSM outline challenges and gaps, pointing out opportunities for future research to develop and validate engineering practices in the startup context.

Building an entrepreneurship data warehouse

The main principle of the Lean Startup movement is that static business planning should be replaced by a dynamic development, where products, services, business model elements, business objectives and activities are frequently changed based on constant customer feedback. Our ambition is to empirically measure if such changes of the business idea, the business model elements, the project management and close interaction with customers really increases the success rate of entrepreneurs, and in what way. Our first paper; “Does Lean Startup really work? Foundation for an empirical study” presented the first attempt to model the relations we want to measure. This paper will focus on how to build and set up a test harness (from now on called the Entrepreneurship Platform or EP) to gather empirical data from Companies and how to store these data together with demographical and financial data from the PROFF-portal in the Entrepreneurial Data Warehouse (from now called the EDW). We will end the paper by discussing the potential methodological problems with our method, before we document a test run of our set-up to verify that we are actually able to populate the Data Warehouse with time series data.

Achieving CMMI Level 2 with Enhanced Extreme Programming Approach

The relationship between agile methods and Software Engineering Institute's CMM approach is often debated. Some authors argue that the approaches are compatible, while others have criticized the application of agile methods from the CMM perspective. Only few CMM based assessments have been performed on projects using agile approaches. This paper explores an empirical case where a project using Extreme Programming (XP) based approach was assessed using the CMMI framework. The results provide empirical evidence pointing out that it is possible to achieve maturity level 2 with approach based on XP. Yet, the results confirm that XP, as it is defined, is not sufficient. This study demonstrates that it is possible to use the CMMI for assessing and improving agile processes. However, the analysis reveals that assessing an agile organization requires more interpretations than normally would be the case. It is further concluded that the CMMI model does not always support interpretations in an agile context.