During the last two decades a slow but steady change of external factors has set-up new conditions affecting the way in how software producing firms create and leverage innovations. Firms now need to look outside of their boundaries and start interacting with the open environment that encompasses them in order to stay innovative and keep a competitive advantage. To facilitate this shift Requirements Engineering needs to consider the increase and complexity of new requirements sources as well as networks of stakeholders. Based on the research agenda described in this paper we expect to make a contribution by establishing guidelines and tools for how Requirements Engineering should be adapted to cope with possible challenges implied by Open Innovation, foremost in the areas requirements selection and decision making when using Open Source Software as a way to leverage Open Innovation.
The emergence of Open Source Software (OSS) and its pivotal part in many firms' business models in later years has opened up software-intensive firms to an earlier unexposed environment of challenges and opportunities [1,2]. This is further explicated by the paradigm of Open Innovation (OI), which highlights how firms should strive to look beyond their own borders for resources that may advance their internal innovation and technology capabilities [3]. Conversely, consideration should also be taken to how they can profit from exploiting internal unutilized IPR together with resources outside of the firm. As a consequence, firms' borders become permeable for interaction and influence from a continuously evolving set of both known and unknown stakeholders. This openness implies a shift away from traditional marked driven Requirements Engineering (RE) [4], and a need to rethink and adapt the way in how RE practices are structured and executed. Beside the firm's traditional RE process, there is now the advent of an external process applied in the OSS ecosystem of which the firm is now a part of [5]. This is an informal and decentralized process where focus is on collaboration and transparency [6,7]. The challenge for a newly entered firm is to understand this new process, and how to adapt its internal process to bridge the gap between the two [8,9].
The overall goal of our research is to investigate and address our main research question: RQ How should software-intensive firms, engaged in an OSS ecosystem, structure and execute their RE practices in the context of OI?
Specifically, we build on and advance the proposed software engineering framework for fostering OI by Wnuk & Runeson [10] with a ". . . focus on release-planning, stakeholder analysis, trade-off between effort (cost) and value and the degree of innovation in candidate features needed in evolving systems, to take significant future market shares in open innovation software development". Hence, focus will be on requirments selection and decision-making. And as further motivated in Linåker et al. [9], this is condensed into three research area questions, namely: stakeholder management (RQ A), when to open up (RQ B), and prioritization and release planning (RQ C). These are then further characterized below with a third level of research questions to better describe and define the scope of this doctoral thesis.
The influx of new and unknown stakeholders may introduce conflicting interests and strategies, which may diminish a firm's own impact in regards to feature selection and control of product planning [8,11]. Further, as an ecosystem evolves, power structures and influence among stakeholders may fluctuate accordingly. This creates a need for firms already engaged or thinking of entering an OSS ecosystem to have an awareness of past and present ecosystem governance constellation in order to be able to adapt their strategies and product planning to upcoming directions of the ecosystem [5,11]. This leads us to define the main research question for the area of Stakeholder Management as:
This can be further broken down into a series of research questions:
Stakeholder awareness is further needed as input in the planning of what a firm is to contribute, how and when. A balance is needed between contribution and reaping of the benefits implied by the ecosystem membership [8]. Further, care needs to be taken as giving away differentiating IPR may be hurtful both for existing and future business [8,11].
Through selective revealing [12], certain parts of the code could be broken out and contributed. Separating the parts of differentiating value may however still prove difficult [8].
One way of tackling this issue would be to provide certain parts as enablers, while the innovative features are kept internal [13]. Another strategy could be to disclose the technology, but under such circumstances that it will not be of value for competitors, e.g. through licensing [13]. Related questions include when in the product and technology life-cycle this should be done [14], and how. This leads us to define the main research question for the area of When to open up as:
This can be further broken down into a series of research questions: [12])? RQ B2 How to determine when the right moment is to open up the artifact for external involvement? RQ B3 How to determine the way in which an artifact is to be developed (e.g. codevelop, outsource) and with/by whom (e.g. single partners, groups or ecosystems)?
The openness and mixture of an internal and external RE process, both on a strategic and operational level, implies many new challenges to the different practices within RE. Specifically, in regards to requirements selection and decision-making, RE subprocesses such as triage and prioritization needs to consider the influence from both known and unknown stakeholders. Factors of which requirements are commonly weighted upon, such cost and value, needs to framed both from the firm's and ecosystem's perspectives. Innovative requirements may require special processes to avoid cancellation from ordinary processes. Risks and dependencies needs consideration in the release process as that of the ecosystem may be out of the firm's control. This leads us to define the main research question for the area of Prioritization and Release Planning as:
This can be further broken down into a series of research questions:
with those of OSS ecosystems? RQ C3 How should risks and dependencies of features be managed and considered? RQ C4 How should cost and value be defined and considered as a decision factor? RQ C5 What other decision factors may be considered relevant?
The research will build on the foundation of earlier findings, which have been gathered and synthesized in relation to OI in software engineering [10,11], but also more specifically to RE research in the context of openness (e.g. [6,8,15,16]).
As emphasized by Wnuk and Runeson [10], "Studying software engineering for open innovation must be an empirical endeavor since we are addressing complex phenomena in the real world". Hence, main research methods will be of empirical nature. Initially, case studies will be used to conduct exploratory research in regards to the defined questions and how current practices are structured and executed, but also to find areas of improvement [17]. Unit of analysis will be software-intensive firms engaged in OSS ecosystems [5]. Multiple parameters need to be considered in regards to the selection of firms and ecosystems respectively, for example:
-How the OSS project is leveraged in the firm's business model, e.g. as pooled R&D [1], a spinout [1], opensourcing [2], dual-licensing [13], or third-party ecosystem [13]. -The size of the firm, both in regards to the development organization and size of requirements repository. -The size, composition and maturity of the OSS ecosystem, e.g. size of the code base, number of actors, and type of actors. -The governance structure of the ecosystem, e.g. open meritocracy or strict but benevolent dictatorship. -Availability, traceability and structure of data, e.g. commit and issue data of the OSS project, but also internally of the firm.
Triangulation will be needed in order to establish and generalize the RE practices, both from the firm and ecosystem perspectives. Qualitative data will be derived from interviews with firm representatives, both from the strategic and operational levels [9]. Interviews, or possibly surveys with a mix of opened and closed questions will be used when confronting other ecosystem actors. Archival data is a further possible data source as documentation of processes, roadmaps, discussions etc. may be available on both sides. Analysis approach is expected to primarily focus on thematic coding of the data.
Quantitative data will be derived from software repositories of both the OSS projects and the firms. From the firm's perspective, this could include requirements repositories, as well as commit and contribution data. From the OSS ecosystem's perspective, this regards the multiple informalisms across which the OSS requirements are represented and specified [7]. Other than descriptive statistics, social network analysis will play a primary role in the analysis work. Due to the importance and focus on stakeholder management in our research, aspects such as collaboration and interaction between stakeholders in the ecosystems is preferably analyzed through the context of networks, as has been successfully adopted in previous studies [18,19] Consideration should specifically be taken to the different dimensions imposed on the questions as a result of the OI context [9]. And as with any empirical work there will be a need for replication in order to support external validity and to make a strong synthesis [20,21].
In table 1 initial studies are presented. Study 1 focused on establishing clearer relationships between different types of innovations in software producing firms, e.g. that improved software engineering process and tools as process innovation may render product innovations, and reverse. Study 2 followed along these lines and investigated how a large software producing firm used OSS ecosystems to improve their tools and processes from an OI perspective, with the bigger goal to improve their products. In this study we piloted the combination of data from both firm and communities as described earlier.
Both study 1 and 2 provides a further foundation in the understanding of OI in the context of Software Engineering [10,11], hence valuable foundation for all three research areas (RQ A-C).
The purpose of study 3 was to explore how stakeholders interact and collaborate to create a foundation for the research questions in regards to stakeholder management (RQ A). Study 5 is an extension, with the goal to create further understanding of the area, but also to investigate its impact on feature-selection and ecosystem governance.
Study 4 was used to outline and establish a research agenda for RE in OI by surveying available literature, highlighting the three areas further defined in this paper (RQ A-C).
Study 6 and 7 have the purpose to further explore the general RE practices of softwareintensive firms engaged in OSS ecosystems, but from two different sides on the scale in regards to size. These studies will provide foundation and understanding to build on in regards to all the three research areas (RQ A-C).
Study 8 is a planned follow-up study on study 6 to explore the contribution strategy and feature innovativeness classification at the same firm. Goal is to examine trade-offs between cost and benefit of contributing in different areas and levels of the OSS project, hence addressing the research questions related to the topic when to open up (RQ B).
This first phase can be seen as an empirical complement to earlier studies and will serve as a foundation for more narrow and solution-oriented studies later on.
We expect to make a contribution by establishing guidelines and tools for how RE should be structured and executed to cope with possible challenges implied by OI. Focus will foremost be on the areas of requirements selection and decision making, more specifically in regards to: