• Abstract and Figures
• Public Full-text

The Journal of Systems and Software 85 (2012) 1495–1510 Contents lists available at SciVerse ScienceDirect The Journal of Systems and Software journal homepage: www.elsevier.com/locate/jss Shades of gray: Opening up a software producing organization with the open software enterprise model Slinger Jansen a,∗, Sjaak Brinkkemper a, Jurriaan Souer b, Lutzen Luinenburg b a Utrecht University, P.O. Box 80.089, 3508TB Utrecht, The Netherlands b GX Software, Wychenseweg 111, 6538 SW Nijmegen, The Netherlands article info abstract Article history: Software producing organizations are frequently judged by others for being ‘open’ or ‘closed’, where a Received 29 April 2010 more ‘closed’ organization is seen as being detrimental to its software ecosystem. These qualifications can Received in revised form 5 December 2011 harm the reputation of these companies, for they are deemed to promote vendor lock-in, use closed data Accepted 5 December 2011 formats, and are seen as using intellectual property laws to harm others. These judgements, however, are Available online 19 December 2011 frequently based on speculation and the need arises for a method to establish openness of an organization, such that decisions are no longer based on prejudices, but on an objective assessment of the practices of Keywords: a software producing organization. In this article the open software enterprise model is presented that Software ecosystems Product software vendors enables one to establish the degree of openness of a software producing organization. The model has Platforms been evaluated in five interviews, is illustrated using three case studies, and shows that organizational Software development governance openness and transparency are complex variables, that should not be determined based on belief or Organizational openness prejudice. Furthermore, the model can be used by software producing organizations as a reference for further opening up their business, to stimulate the surrounding software ecosystem, and further their business goals. © 2011 Elsevier Inc. All rights reserved. 1. Introduction An OSE creates its own network of collaborators called a soft- ware ecosystem. Software ecosystems are defined as a set of actors Software producing organizations (SPOs) have one goal in com- functioning as a unit and interacting with a shared market for soft- mon: get the software that is being produced to be adopted as ware and services, together with the relationships among them frequently as possible. Different business models exist to obtain (Jansen et al., 2009). These relationships are frequently under- that goal, from open source models where source code is given pinned by a common technological platform or market and operate away for free, to service models where the source code is running on through the exchange of information, resources and artifacts. There a protected server. SPOs have discovered that they can achieve their are several motivators for establishing a software ecosystem, such goals quicker by creating an ecosystem of partners around the prod- as the ability to respond more flexibly to varying requirements for uct, such as developers or resellers. These developers and resellers varying domain specific solutions that are based on the platform will only participate, however, if the SPO opens up: business pro- or quicker adoption than competitors through large partner and cesses that are traditionally closed need to be shared with actors developer networks. Iansiti and Levien (2004) state that organiza- in the ecosystem to help them create value. Such value is created tions in an ecosystem depend on each other mutually for survival by mass-development (open source), mass-customization (open and effectiveness. Therefore, the health of individual organizations configuration), and many other strategies that include opening is not solely affected by itself but heavily depends on the health of up business processes. Traditionally monolithic and closed orga- the complete network of firms. nizations that open up their business processes are named Open An OSE is defined as an organization that produces software and Software Enterprises (OSEs). that has opened up its processes to at least one of the actor types that are present in its software ecosystem. OSEs can be any type of SPO, from independent software vendors to open source organiza- ∗ tions. An actor can be any participant in a software ecosystem. In Corresponding author. Tel.: +31 619884880. this article we identify four types of actors, being developers, value- E-mail addresses: [email protected] (S. Jansen), [email protected] (S. Brinkkemper), [email protected] (J. Souer), added-resellers (VARs), service partners, and customers. Each of [email protected] (L. Luinenburg). these actors has the capability to add value to a SPO, by adding 0164-1212/$ – see front matter © 2011 Elsevier Inc. All rights reserved. doi:10.1016/j.jss.2011.12.007 1496 S. Jansen et al. / The Journal of Systems and Software 85 (2012) 1495–1510 source code, by making sales for the organization, or simply by on prejudiced perception of openness in the SPO’s context. These paying the software organization directly. unfounded decisions can lead to wrong strategic decisions and can When a SPO intends to become an OSE, it must review its busi- potentially make good products less appealing, based on a spec- ness model. Several different business model evaluation techniques ulative qualification towards openness. Two sub-problems were exist, such as the application of Jansen and Brinkkemper’s soft- formulated: (1) there currently is no model that provides managers ware ecosystem modelling methods (Boucharas et al., 2009)orthe an overview of the openness measures that can be taken by an SPO evaluation technique of Rajala et al. (2003) who define a software and (2) there is no way to measure how open an organization is. business model along four axes, being the distribution model, the The results of these problems are that software organizations need services and implementation supplied by the software vendor, the to guess in which way they should open up their processes to lever- revenue logic it applies, and its product strategy. In this article is age the software ecosystems and that software organizations are shown that the business model plays a key part in establishing judged prematurely for being too closed. Both results are detri- how a SPO opens up its processes and that different value adding mental to the software industry. The artifact that is developed is actors, such as third-party developers and VARs, have interest in the OSE model, which addresses the two problems identified. The the opening of different process domains. OSE model can be used as a reference framework by SPOs to estab- Several national initiatives, such as the draft ‘policy on lish which options to open up if an SPO decides to become more Open Standards for eGovernance’ (Ministry of Information and ecosystem friendly. Also, the model can be used by procuring orga- Communication Technology, 2008) in India and the ‘UK Govern- nizations to establish which of the shortlisted products are more ment IT strategy’ (Chief Information Officer Council, 2010), have “open”, by establishing which of the openness options have been called local governments to use ‘open’ software and standards chosen by the supplier of those products. instead of closed alternatives. It is hard for these public organi- In regards to research rigor, the research has been done using zations to establish exactly how open a SPO is, especially because two cycles of the design cycle, where a different evaluation method at present no objective instruments exist. This is detrimental to the was used for each cycle. For the first cycle the artifact was evalu- software industry, since commonly SPOs are unjustly deemed to be ated doing five interviews with experts in the domain of software open or closed, leading to poor purchasing decisions. ecosystems. In the second cycle, three case studies were done to fur- The model presented in this article aims to establish how open or ther establish whether the model was useful and could be applied closed an SPO is. The model’s raison d’etre is found in three aspects. to examples of OSEs. Both research cycles were performed by a First, unjust purchasing decisions are made based on prejudiced different researcher. openness evaluations, thereby not letting the best product or sup- plier win. Secondly, SPOs are unaware of the different openness 2.1. Evaluation interviews options that exist, and they are unaware of how they can safely change their business model and open up their business to com- Five interviews were organized with experts in software ecosys- ply with the requirements of local government and to stimulate tems. These experts were two product managers, a CTO and a CEO the software ecosystem. Thirdly, the model tries to take the focus of a software company, and finally an ecosystem manager. Each away from “open source”, and attempts to show that there is more of the interviewed has had at least 10 years of experience in the to openness than an open software license. software industry. The product managers were both from GX Soft- This article continues with the research approach in Section 2, ware, one of the case study companies. Interviews generally lasted including how design research was performed to create the OSE approximately 90 min and consisted of 10 open ended questions model and how case study research was applied to evaluate the about openness (as shown in Table 1), a model evaluation, and model. In Section 3 the OSE model is presented that lists all the a final case identification. The open ended questions concerned different openness options a SPO has. Furthermore, an openness the definition of an OSE, the different ways in which the inter- measure is presented that assists in objectively assessing the degree viewee perceived openness, and how some companies appeared of openness of a SPO.

Load more

  16

Copy Link