Business Network Management as a Survival Strategy: A Tale of Two Software Ecosystems

Abstract

Software vendors and software service providers can no longer function without taking their software ecosystem into account. Software vendors presently face three challenges in regards to software ecosystems: (1) they require insight into software ecosystems, (2) they require insight into the possible survival strategies that exist for software ecosystem participants, and (3) they require an overview of possible ways in which the organization can open up to the software ecosystem without losing intellectual property. This paper addresses these needs and provides an overview of the de ning characteristics of software ecosystems. To illustrate these de ning characteristics two case studies are provided.

-


 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 


Introduction

a variety of di erent systems, institutions, procedures, social relations or infrastructures whereby persons trade, and software and services are exchanged [ 17 ]. Based on these concepts we de ne a SECO as follows:

Software ecosystem - a set of actors functioning as a unit and interacting with a shared market for software and services, together with the relationships among them. These relationships are frequently underpinned by a common technological platform or market and operate through the exchange of information, resources and artifacts [ 13 ].

ISV (1) (2)

ISV

Sup1 Sup2 Sup3

ISV (3)

Cust1 Cust1

SECO models can have three scope levels of which examples can be found in gure 1, as discussed in [ 4 ]. At each of these scope levels di erent entities are considered. At the organizational scope level (3), the objects of study are the actors and their relationships. At the SECO scope level (2) the objects of study are the Software Supply Networks (SSNs) and their di erent relationships. at the SECOs scope level (1) the objects of study are the SECOs themselves, and the relationships among them. At each scope level di erent research challenges exist, ranging from the e ect of architectural changes on the SECO to the development of overal health metrics for any SECO. These challenges can be further articulated by de ning generic properties on the objects of study, which remain similar as we raise the scope levels. A non-exhaustive list of these generic properties contains such properties as (organizational, SECO, or SECOs) health, interaction, performance, inputs, outputs, competition, value sharing and coordination methods. Relatively little literature has treated each of the three di erent scope levels.

This paper serves three purposes. First, it speci es the de ning external and internal characteristics of SECOs. Second, the paper provides orchestration mechanisms that can be used by software vendors to become more successful and leverage the advantages of SECOs. Finally, two examples of SECOs are used to illustrate how indicators and characteristics can be used to illustrate SECOs and several orchestration techniques are identi ed. The two example cases have been unearthed using traditional case study methods [ 11 ]. Both case studies were preceded by several meetings and the agreement on a case study protocol. The case studies consisted of three parts: software study, several interviews, and document study. The case study reports were reviewed by colleagues and a subgroup from the interviewees.

This paper continues with an explanation of how SECOs can be viewed from the outside. In section 3 the internal characteristics of SECOs are discussed, including a discussion on the health of a SECO. In section 4 insight is provided into the measures that software vendors can take to open up their businesses to the SECO and several orchestration techniques are provided for keystones looking to grow and develop their SECOs. Finally, in sections 5 and 6 two case studies are provided to illustrate examples of organizations that deal with their SECO on a daily basis. 2

Scope Level 1: External View on Ecosystems

In literature many di erent views on SECOs are found. Farbey and Finkelstein [ 7 ] de ne four di erent \rungs" for SECOs. At the rst rung there is just a market relationship with a dominant focal rm, at the second rung there exists some embryonic networking, at the third rung the focal rm has decreased power and stimulates communities of practice, and at the fourth rung there exists a community of creation, where there is no dominant rm and power is distributed. Iansiti and Levien [ 8 ] directly oppose this view of the fourth rung by stating that keystones are the driving forces behind SECOs and provide stability in unstable environments. They further state that in an unstable network, sooner or later a keystone player rises. Den Hartigh et al. [ 6 ] explicitly mention two perspectives being \company level" and \ecosystem level". The company and ecosystem levels are similar to the organizational and SECO scope levels taken in this paper.

Jan Bosch adds two other SECO dimensions to the taxonomy: category and platform [ 3 ]. Category de nes whether the SECO enables participation through building applications on top of an operating system, through application extensions on top of a (product) platform, or by enabling end-users to develop extensions through a domain speci c language. The platform determines whether the platform is a web technology, a desktop technology, or a mobile technology. For example, an application centric web platform is SalesForce, because its application is supplied through the web and SalesForce enables third-party developers to build plug-ins for SalesForce in di erent shapes and sizes, such as mobile and web applications. SalesForce presently contains 80,000 custom applications and 800 components in its force.com component platform. 2.1

De ning Ecosystem Boundaries

In de ning SECOs, the following restriction boundaries are used: { Market - A SECO can be centered around one speci c market, such as the

Computer Aided Design (CAD) market, the portable music player market, or the Dutch small-to-medium enterprise resource planning market. Participants in these market-oriented ecosystems function as a unit (at the least) in that they supply customers with similar products and the loosest relationships amongst them are competitive. { Technology - A SECO can be based on a speci c technology, such as the The Semantics of Business Vocabulary and Business Rules (SBVR) standard, the Ruby programming language, or the Internet Protocol Version 6 (IPv6). Participants in these ecosystems typically are of any kind, although the owner of the technology's intellectual property is generally found to be a keystone player in the SECO. { Platform - SECOs can be focused around one speci c platform or product, such as the Eclipse platform, the Microsoft CRM platform, and the Ruby on Rails framework. Platforms are characterized by the fact that their functionality can be extended by the addition of components (generally in a native format) or the presence of an Application Programming Interface (API). Platform SECOs are generally easily identi ed and enable commoditization of functionality, packaged in components and frequently sold in speci c component marketplaces (such as the iPhone's AppStore or the Android Market).

By de nition the platform supplier is a keystone rm. { Firm - SECOs can also be de ned around one rm, such as the Microsoft SECO, the Google SECO, or the SAP SECO. The rm plays the role of keystone supplier in several platform ecosystems. An interesting property of rm SECOs is that dependent on the strategy of the rm there exists strong or weak cohesion between the di erent participants.

Each of the ecosystem types has a number of factors that can further reduce the scope of the SECO, such as geographic restrictions (European, Dutch, etc.), component speci cation (location-based iPhone Apps, tax regulation components for SAP, etc.), or even license restrictions (open source, GPL, etc.) Furthermore, when a platform supplier supplies just one platform, the platform ecosystem is generally equal to the rm's ecosystem. 2.2

External Characteristics and Performance

SECOs have several external characteristics that identify it to the outside world. The external characteristics provide other organizations a quick insight into the SECO's de ning boundaries and its main properties for a quick analysis of potential opportunities and threats from the SECO. These characteristics are split up into general, participants, and value characteristics. The boundaries that dene the SECO, such as the underlying technology used by participants in the SECO, the platform(s) used in the SECO, and the market(s) in which the SECO plays a role, are a de ning characteristic of SECOs. Other general characteristics are the age of the ecosystem and its history.

A SECO is further de ned by its participants. An outside viewer who is interested in a SECO will want to know who the keystone organizations are, such as platform suppliers, standards organizations, and other organizations that de ne how the SECO acts and develops itself. Furthermore, the outside viewer will want to know what types of customers are active within the SECO. Another aspect that must be considered is a SECO's connectedness to other SECOs. If a SECO is strongly embedded in several other SECOs, its participants will better recover from radical changes in the SECO. Finally, the value of a SECO, i.e., all technology and value streams within it, de ne the external view on a SECO.

The external characteristics provide a one-dimensional view of a SECO. A SECO becomes more interesting when looking at its performance and its most recent developments. Fundamentally, recent developments in value, numbers of participants, customers, and entries of new keystone players can indicate or cause swift changes to the SECO. Another aspect of SECOs that draws from biology, is the concept of SECO health. SECO health is determined by the robustness, productivity, and niche creation within a SECO [ 8 ]. Robustness is a term that describes how well a SECO can recover from major stress, such as the removal of a keystone, the demise of a large part of the niche players, or from a revolutionary technological advancement that competes with a large part of the SECO. Productivity describes the activeness of the SECO, i.e., how much business is created, how much value is added, and how many new players are joining. Finally, niche creation describes the SECO's ability to create new opportunities for new entrants and old actors to jump onto new business opportunities. 3

Scope Level 2: Internal View of a SECO

A SECO is more than just the sum of its parts, i.e., actors such as independent software vendors, customers, resellers, or outsources. Many characteristics de ne the dynamics and identity of a SECO, amongst which are size, types of actors, roles, connectedness, etc. The SECO scope has received more attention from authors such as Iyer [ 1 ] and Iansiti and Levien [ 9 ]. Iansiti and Levien provide comprehensive overviews of the di erent roles actors can play within a SECO and also describe several e ects of strategic choices on the overall health of a SECO. Iyer on the other hand created many di erent SECO models3 that display the development of these models over time. These models provide interesting insights into the life and death of certain technologies and platforms and their accompanying SECOs. Another closely related work is that of Den Hartigh et al. [ 6 ], which studies partner health and network health to assist software vendors in assessing the health of their SECOs. Their operationalization of the health concepts posed by Iansiti and Levien, though pragmatic in nature, provides deep insight into how health concepts can be applied in practice and can be used to control and steer quality in the SECO. 3.1

Ecosystem Roles

In healthy SECOs, i.e., that exert robustness, productivity, and enable niche creation[ 8 ], two roles can be played safely by organizations over a longer period of 3 many di erent visualizations can be found at http://softwareecosystems.com time. The rst role is the role of keystone, i.e., providing a standard or platform technology that provides a fundament for (part of) the ecosystem. The second role is the role of niche player, a player that requires the standard or platform technology provided by the keystone player for creating business value. Other parts have not yet proven successful in the long run. The role of dominator, i.e., an organism that progressively assimilates or eliminates others (keystones, other dominators, and niche players) in an ecosystem, may prove successful for a short period of time, but after the critical mass of the ecosystem has diminished the dominator has to become the sole provider of innovation within the ecosystem, while still providing enough capacity to serve the full customer base of the ecosystem. Several examples have shown that strong dominators either destroy the ecosystem or are regulated by external factors, such that the ecosystem can survive. A second role that is unsuccessful for longer periods of time is the role of a niche player that is mutually dependent on other niche players, with the absence of a keystone. Eventually, the niche player submits to the keystone player or raises another niche player to the level of keystone player by becoming dependent on it. In biology, a keystone is de ned as a species that governs most important ecosystem health, often without being a signi cant portion of the ecosystem itself[ 16 ]. A typical example of a keystone in nature is the jaguar, which, through the wide variety of species it hunts, helps balance the mammalian jungle ecosystem.

Hagel, Brown and Davison [ 10 ] state that SECOs are made up of shapers and participants. Shapers appear to be equivalent to the keystones of Iyer [ 1 ] and Iansiti and Levien [ 9 ]. Hagel, Brown and Davison state that there are three things a keystone player needs: a keystone view, a keystone platform, and the keystone player should exert keystone behavior. The keystone view is identi ed by the fact that the player provides focus, identi es opportunities, and describes fundamental forces for other players in the SECO. The keystone platform should provides leverage, de ne standards and practices, foster specialisation, and increases in value with the number of participants. Finally, the player must act by creating keystone credibility, limit risks for new adopters, and show that a long term commitment can be expected from the player. Fundamentally, keystones aim to improve the overall health of their ecosystems by providing a stable and predictable set of common assets that other organizations use to build their own o erings. More concretely, keystones create and share value within a SECO[ 9 ].

Hagel, Brown, and Davison [ 10 ] also describe followers in the SECO, equivalent to niche players. These belong to any one of the following three: hedgers, disciples, and in uencers. Hedgers participate in two competing SECOs, to minimize risks. A disciple is an early adopter of a keystone technology, and is willing to spread the word about the keystone technology. Finally, an in uencer not only actively participates in the SECO, but exerts its in uence on the keystone player, for instance by ling feature requests, organizing conferences, and forming lobbies. Iyer adds another role to the list of roles, called \broker". The broker is an actor that serves as an interface between two other actors, for example a standards body. Another role is the role of \bridge", which is active in two SECOs and can exert a certain amount of in uence in both. The bridge, better de ned as a property rather than a role, can transfer resources, such as knowledge, money, and people across di erent SECOs. In SECOs a bridge role is generally played by middleware companies who develop software that connects di erent technologies. For the rest of this paper we use the widely recognized roles being: dominators, keystones, and niche players. 3.2

Internal Characteristics

SECO insight provides (potential) actors with the ability to discover opportunities and threats. SECO insight also enables actors to take on a role that in uences the success of a SECO. To get a quick overview of a SECO, several characteristics must be measured.

The rst characteristic is the composition of a SECO, i.e., what types of actors exist, how large are they, what role do they take on, and in what frequencies do they occur. The composition of a SECO explains how it functions and how well it responds to changes. The composition of a SECO also includes the size of the SECO which also largely in uences the stability and success of a SECO. The size of a SECO is measures in number of actors, but more importantly its economic size indicates how successful the SECO is at any moment. For economic measures the work of den Hartigh et al. [ 6 ] provides a useful overview. For each actor in the ecosystem one can gather the following data: earnings before interest and tax over total assets, total revenue over total assets, liquidity, annual solvency development, retained earnings over total assets, total asset growth, and working capital over total assets.

The entry barriers into a SECO can take on several shapes and sizes, and knowledge on the entry barriers provides orchestrators with one of the keys to growing the SECO. As de ned in section 1 the SECO is further de ned by its underlying technologies and platforms. These technologies and platforms de ne what an actor must adopt to become an entrant to the SECO. To become completely embedded in a SECO can be easy (simply add your application to Google's Android Market) or heavily complex (get your component certi ed by SAP to become part of a preferred component program). Another one of these entry barriers is the way in which business opportunities are created and the amount of openness in the SECO.

Stability is a determining characteristic of a SECO, after all it convinces actors that the SECO is here to stay and provides business opportunities. Stability is in large part de ned by the \faithfulness" of members, i.e., how frequently do members leave the SECO. Stability is also gained by su cient orchestration. Orchestration techniques (see section 4.2 for de nitions) are for instance regulation, certi cation, and the introduction of standards. These orchestration techniques are generally used to improve a SECO, but can also be detrimental to a SECO, when the keystone player imposes too con ning regulations. A useful term here is tenancy, which describes the price of participation in a SECO imposed by a strong keystone player. If the price of this tenancy becomes too high, i.e., the costs of operating in the SECO, actors will seek alternatives. Good examples of tenancy are the percentage of the revenue that actors must give up in mobile application stores (30% for the iPhone and Android) to the SECO keystone. 3.3

Performance and Evolution

SECO characteristics provide insight but several other aspects need to be taken into account, such as history and recent development. Actors will generally be discouraged to join a SECO if a dominator is clearly active in the SECO. One such example is the integrated development environment Visual Studio. Visual Studio's recent acquisitions of devBiz and SysInternals, but also their reputation of rebuilding and incegrating useful plug-ins developed by third parties, put it in the dominator category. This is in stark contrast to the Eclipse plug-in SECO, where plug-ins can employ any type of business model without having to fear competition from Eclipse itself.

Finally, one of the most important indicators to studying SECOs is SECO health. Business ecosystem health is rst de ned by Iansiti and Levien [ 8 ]. These health indicators are taken by Den Hartigh et al. [ 6 ] to describe several operational measures for the health of a business ecosystems. Their measures are directly applicable to the SECO domain. Some examples are survival rates, network stability, network connectedness, centrality, costs of upgrading over several versions of the keystone technology, etc. The authors propose that the health indicators developed are used to further develop an instrument that enables actors to be more selective in regards to their partners.

In practice the characteristics de ned above are not always available or measurable. Several questions arise, such has how to gather nancial data on actors. In this case other operational measures can be employed to gain a quick overview. For example, in June of 2009, the component store of Apple's iPhone contains approximately 35,000 applications. This number is much higher than Google Android's with approximately 5,000 applications. If these numbers are related to downloads (1 billion compared to 40 million for the Android market), it is easy to see what mobile application store will generate the most short term revenue. 4

Scope Level 3: Organization Centric Perspective

The organization centric perspective has received some attention in our earlier work [ 12, 5, 4 ]. The organization centric perspective looks at the measures a software-related business can take to create or leverage the surrounding SECO. On the organization level, performance and evolution are dependent on the decisions of entrepreneurs, i.e., not so strongly dependent on the SECOs. Therefore, performance and evolution are considered less relevant on this level for studying SECOs, but are extremely relevant for the entrepreneur. 4.1

Extended Software Enterprise

Moore stated the role of the Extended Enterprise in a business ecosystem in his praised business ecosystem model [ 15 ]. This model can be further decorated to apply to software businesses speci cally, introducing the concept of the Extended Software Enterprise (ESE). An ESE is a software enterprise that has abolished selected barriers surrounding its intellectual property to create value by sharing it with the surrounding SECO. An ESE does not necessarily have a commercial goal, as many organizations have shown, such as the Eclipse Foundation and the Apache Foundation. An ESE is not necessarily the same as a keystone player; niche players can open up their intellectual property as well. For example, a niche player might wish to in uence the SECO by publishing an API to the product of an ecosystem leader. Also, a niche player might want to put customers directly in contact with the keystone player, to divert problems to its original source. A de ning characteristic of an ESE is its willingness to contribute to and pro t from its surrounding ecosystem. The ESE is a software producing organization that manages the company based on the SECO. Any type of SECO actor can be or become an ESE. For example, when a niche player distributes the future release date and road plan of its Apple iPhone application to Apple, that brings the niche player towards being an ESE. On the other hand keystones tend to focus on the SECO much more than niche players, so keystone players will generally t the ESE de nition.

An ESE is characterized by openness, but of course that challenges the business model. An independent software vendor can take steps to become more open from three perspectives. First, from the product perspective, an ESE can choose to modularize its functionality, such that separate parts of it can be exploited. Furthermore, the ESE can share product knowledge that is considered part of the intellectual property. Thirdly, an ESE can create APIs and when possible stimulate end-user development. Another example of a measure an ESE can take is to create reuse policies, create a reuse enabling architecture, and support interchangeable data formats.

From the operational perspective, the ESE can share knowledge in regards to research and development, product management, sales and marketing, and support. For research and development the ESE can choose to open up bug repositories, share newly found innovations, outsource research and development tasks, and even share source code. In regards to product management the ESE can open up the requirements engineering process, such that customers get to vote on important features, share road maps, coordinate release times, etc. In regards to sales and marketing an ESE can share customer and supplier information, market research, and develop innovative licensing methods, such as for instance open source commercial business models. In regards to support, an ESE can decide to use partners to provide support to customers and to share incident databases with the outside world.

From an entrepreneurial perspective, the ESE can share a research, market, and technology vision with its partners. Furthermore, the ESE can share quality criteria, share process knowledge, and even introduce partner certi cation. Also, the ESE can stimulate the use of standards, share its long term plans, and create internal and external component markets. Finally, the ESE can create partner programs, provide insight into the full partner network, and form a lobby together with partners. 4.2

The Role of Orchestration

SECO Orchestration describes the arrangement, coordination, and management of actors and networks in a SECO. SECO orchestration is a task for keystone players in a SECO, although the task is not de ned explicitly and frequently lies in the hands of several players in the SECO. Several common orchestration techniques exist, such as creating a component store, introducing interoperable software standards [ 2 ], legislation of quality standards, introducing quality standards and certi cation programs, sharing of a SECO vision, and explicitly de ning the boundaries of a SECO. For reasons of brevity these coordination techniques can only be discussed brie y. The applicability of orchestration techniques is dependent on the characteristics of the SECO. In a stable SECO in which niche players have been locked-in the introduction of tenancy is applicable, whereas in an open SECO, such as the Eclipse plug-in SECO, that would scare away many of the casual component developers.

Young SECOs commonly su er from bootstrap problems: there are not enough adopters of the keystone technology to get a major return on investment and therefore there are insu cient new niche players to partake in the SECO. The investment to further encourage the development of the SECO is not made, i.e., the potential keystone player cannot a ord to build reliable APIs, write comprehensive documentation, and adopt a long-term SECO view. If su cient resources are available, there are ways to bootstrap a SECO: rst a potential keystone provider should make their technology reusable through APIs, REST calls, plug-in infrastructures, etc. A second step is to encourage niche players to become active in the SECO. There are several ways to do this, such as revenue sharing, introducing direct rewards for niche players, establishing a partner network, etc. The strategy to bootstrap a SECO depends on what convinces a niche player to adopt the keystone technology. In some cases the introduction of a component or plug-in certi cation program might be enough, in others a full standard (such as XBRL) must rst be introduced to get an active community around a technology. Two examples of SECOs that were bootstrapped from the beginning are described in the case studies below. 5

Case 1: GX

GX is a Dutch company with approximately 120 employees, active in the content management systems market in both the Netherlands and the United States. GXs product, GX WebManager (GX WM), is a content management system that is used by many large organizations to build and maintain complex websites and web applications.

GX recently realised that its growth opportunities lie in a partner network of implementers and custom developers. Furthermore, increasing amounts of developers were already developing plug-ins and extra components haphazardly, based on the extendible Java architecture of GX WM. Since 2007 GX has been managing its SECO explicitly. Some interesting steps were taken by GX, such as separating the project and product organizations, making a large part of the company just another implementation partner, equal to third-party implementation partners. The partner network of GX is now steadily growing for three reasons: GX has created a partner-friendly environment, the main product is relatively successful, and there are so many business opportunities that GX needs a partner network to satisfy all customers.

GX did not focus on its partner organization alone: soon a large number of developers surrounded the product and a community started growing. This community desperately needed an API to the product, so that plug-ins could be created, such as multimedia content viewers. As soon as GX created the API, several partner organizations started developing plug-ins, as a way to save on development costs through reuse. Presently, the component exchange contains well over 500 components, which are available for free or for a small sum of money. GX has changed their vision on software development radically. GX wants to be as open an enterprise as possible, mostly because it enables GX to further grow the numbers of developers for GX WMs and more importantly because it enables GX to focus on its own strategy (and thereby the SECO strategy). One of the more successful measures GX has taken is build a component certi cation tool that semi-automatically veri es and certi es third-party plug-ins. The certi cation tool enables GX to quickly see whether the component does not break any interaction standards and that it lives up to GX's quality criteria. 5.1

GX SECO Developments and Health

The SECO appears to be growing rapidly but this could be caused by the fact that the SECO is still young. Its growth must stabilize (in the Netherlands at least) since the content management system market in the Netherlands is saturated compared to developing countries. GXs partners range from small consultancy rms to large internationals. Should we employ the measures on partner and network health of Den Hartigh et al. [ 6 ], an unfair image would arise since some of the smaller consultants take on large parts of the work, whereas some of the larger consultants have only recently entered the partner program. 5.2

GX SECO Conclusions

There are several aspects to the success of GXs SECO. The content management systems market is \SECO friendly" for two reasons. The rst reason is that content management systems can be implemented across di erent domains. The domain speci city has led to GX developing a avour of their product specifically for the governmental market, for instance. The second reason why the content management systems market is \SECO friendly" is that content management systems have many diverse applications that span di erent domains. A YouTube plug-in, for instance, is useful in both the governmental and industrial domain. The multitude of applications was bene cial to GX launching their own component market, since now it is easier for partners to share their own innovations with others. Other examples of such SECO friendly applications are mobile operating systems, large ERP applications, game platforms, and social network applications. 6

Case 2: The Open Design Alliance

The Open Design Alliance (ODA) is an organization that strives for open standards with respect to CAD formats, and more speci cally the dwg le format. The ODA presently has 2,000 members. The ODA develops the ODA platform, which includes the ODA libraries. The ODA Platform can be included in any CAD product to enable reading and writing of dwg formatted les. Currently approximately 28 people work for the ODA, of which 25 are developers. The ODA has four di erent member types, being associate, commercial, sustaining, founding and educational. Each of these membership types has di erent rights, privileges, and costs.

{ Educational members pay a fee of 100 dollars to gain access to the ODA platform for one year, for research and development. One can only be an educational member for one year. { Associate members pay an initial fee of 250 dollars and an annual handling fee of 100 dollars to gain access to the ODA platform for research and development for internal company use only. The libraries can not be redistributed or sold in combination with other products. { Commercial members pay a membership fee of 1,500 dollars to gain access to the ODA libraries for internal use and redistribution to a maximum of 100 customers or four publications of a web-based application. Furthermore, commercial members receive support from ODA developers. { Sustaining members pay a membership fee of 3,000 dollars to sell and distribute the ODA libraries to any number of customers. Furthermore, the ODA will promote the member's contribution, by including member names and logo's in its promotion. { Founding members pay pay a membership fee of 12,000 dollars to gain full access to the source code of the ODA libraries. Furthermore, founding members can make use of the ODA's exclusive consultancy services. Finally, founding members elect and propose candidates for the ODA Board of Directors.

Membership is gained after signing the ODA membership agreement. The ODA maintains its ecosystem by organizing conferences, publishing books and learning materials, and a bi-weekly status report.

The ODA has been created to enable organizations to use the dwg le format in an open manner, which is in sharp contrast with the aims of the dwg format's original creator, AutoDesk. Interestingly, AutoDesk has created its own SECO, including di erent partnership levels, being standard, professional, and premier. The rst two levels are similar to the commercial and sustaining levels of the ODA, where the premier level is comparable to the founding level of the ODA. For AutoDesk memberships do tend to be approximately twice as expensive, and access to source code is never granted. The material for the ODA case study was mostly gathered during an annual ODA conference, organized in the Netherlands. 6.1

ODA SECO Developments and Health

Three SECOs play a part in the ODA's history. First, the rm's SECO consists of all those who use the ODA's components and platform. Secondly, the ODA is a major player in the the dwg technology ecosystem. Finally, the ODA's platform ecosystem is part of the larger CAD SECO. Because the ODA delivers one platform the rm's SECO and the platform SECO are equivalent.

The ODA has an interesting history in the context of SECOs. First, the ODA was founded as a company by eight other companies around 1990, feeling the need to open up the dwg le format. In 1998 the Visio corporation, now part of the Microsoft Corporation, acquired the company. Soon the Visio corporation realised that the expertise within their newly acquired team was not speci c to Visio, but to many others as well. Visio founded the OpenDWG Alliance, or ODA as it is now known in 1998 and opened up its membership to others.

Another interesting development is that the ODA started out as an organization that focused on opening the dwg standard to software vendors of all shapes and sizes. During its lifetime, however, the focus widened to include several other complementing and competing standards into the libraries. As the amount and variety of formats that were included in the libraries increased, the structure of the software evolved as well. Presently, the ODA platform consists of viewers, readers, APIs and documentation that enable developers to access and modify CAD related storage formats. Along with these developments came a name change: the ODA libraries became the ODA platform.

Many of the current utilities in the ODA platform were supplied or purchased from third-parties, which thereby enriched the ODA platform. As these third-party utilities were included in the platform with increasing frequency the ODA realised that the platform needed to facilitate this type of reuse. Recently, the ODA started the Third-party Supplier Program, a program that enables sustaining and founding members to contribute their own components to the platform. The ODA platform is then used as a reseller platform, although the license agreements and billing are arranged by the members themselves. Finally, the ODA platform is trying to be more e ective for its members by focusing on vertical markets. Presently, the ODA platform contains components for the geo-information market, the mechanical design market, and for the architecture market. The ODA is researching other areas that are of interest to its members.

The ODA SECO is relatively healthy. The ODA actively creates business opportunities for third parties and exerts and shares its technology and future vision. The ODA SECO is robust, mostly due to its consortium structure that enables it to survive through technological breakthroughs, internal competition, or even extreme competition from other SECOs, such as the AutoDesk SECO. The ODA SECO is vulnerable too, however, due to its small size and precarious position in regards to the le formats the consortium is trying to keep open. 6.2

ODA SECO Conclusions

The ODA is a rare case of an independent software vendor that is not allowed to make pro t: every dollar made should go back into further development of the platform. This has several implications for the SECO. Because the ODA is run by members, a small layer of management (four people) is required to steer the organization. All other personnel are approximately 25 developers who do nothing but add value to the platform. An interesting e ect of this structure is that the ODA has a high level of credibility with its members, since the members feel they can in uence decisions that are made by the ODA.

The ODA measures its success in the number of members it has. The members are the most valuable asset to the ODA, since they enable, through their membership fee, the ODA to get more developers. The ODA actively brings together its members to create a more active community, since the members are dispersed all over the globe. Members are brought together through conferences, local meetings, an online forum, and a monthly newsletter.

The openness of the ODA SECO is a threat to the business model of the dwg format of AutoDesk, which has led to a number of lawsuits from AutoDesk towards the ODA. These lawsuits are a relatively successful competition strategy, considering that they tend to cost the ODA a lot of money, a resource that is normally used to employ platform developers. The ODA SECO can be considered to be in direct competition with the AutoDesk SECO, since AutoDesk does provide APIs to access the dwg format to its own members. 7

Conclusions and Future Work

Due to the changing state of the software industry SECOs and extended software enterprises are essential concepts to explain the life and death of independent software vendors. This paper provides an overview of these concepts and illustrates them with two case studies. The case studies are used to show di erent examples of measures software vendors can take to thrive in SECOs. The concepts are useful to both researchers who wish to study SECOs and to entrepreneurs who wish to improve their business by leveraging their partner networks.

The overview serves as a jumping board for future research. To begin with, the concept of the extended software enterprise is currently not validated. Secondly, the orchestration techniques described in this paper need to be further validated and annotated with economic data to show the success (or failure) of such measures. Finally, this paper calls for more detailed case studies of SECOs and their speci c characteristics, to further illustrate the e ects of SECOs on independent software vendors.

References

1. N. V. Bala Iyer, Chi-Hyon Lee . Managing in a "small world ecosystem": Lessons from the software sector . Harvard Business Review , ( 5 ), May 2006 .

2. P. Bannerman and L. Zhu . Standardization as a business ecosystem enabler . In Proceedings of the International Workshop on Enabling Service Business Ecosystems (ESBE08) at ICSOC08 , 2008 .

3. J. Bosch . From software product lines to software ecosystems . In Proceedings of the 13th International Conference on Software Product Lines (SPLC) . Springer LNCS , 2009 .

4. V. Boucharas , S. Jansen , and S. Brinkkemper . Formalizing software ecosystem modeling . In Proceedings of the International Workshop on Open Component Ecosystems. ACM , 2009 .

5. S. Brinkkemper , I. van Soest , and S. Jansen . Modeling of Product Software Businesses: Investigation into Industry Product and Channel Typologies , pages 1 { 19 . 2007 .

6. E. den Hartigh, M. Tol, and W. Visscher . The health measurement of a business ecosystem . In Proceedings of the European Network on Chaos and Complexity Research and Management Practice Meeting , 2006 .

7. B. Farbey and A. Finkelstein . Software acquisition: A business strategy analysis . In RE '01: Proceedings of the Fifth IEEE International Symposium on Requirements Engineering , page 76, Washington, DC, USA, 2001 . IEEE Computer Society.

8. M. Iansiti and R. Levien . The Keystone Advantage: What the New Dynamics of Business Ecosystems Mean for Strategy, Innovation, and Sustainability . Harvard Business School Press, August 2004 .

9. M. Iansiti and R. Levien . Strategy as ecology . Harvard Business Review , 82 ( 3 ): 68 { 78 , March 2004 .

10. J. H. III , J. S. Brown , and L. Davison . Shaping strategy in a world of constant disruption . Harvard Business Review , October 2008 .

11. S. Jansen. Applied multi-case research in a mixed-method research project: Customer con guration updating improvement . In Information Systems Research Methods, Epistemology and Applications , A.C. Steel and L.A. Hakim (eds.), 2008 .

12. S. Jansen , S. Brinkkemper , and A. Finkelstein . Providing Transparency In The Business Of Software: A Modeling Technique For Software Supply Networks , pages 677 { 686 . 2007 .

13. S. Jansen , A. Finkelstein , and S. Brinkkemper . A sense of community: A research agenda for software ecosystems . In 31st International Conference on Software Engineering , New and Emerging Research Track, pages 187 { 190 , 2009 .

14. H.-B. Kittlaus and P. N. Clough . Software Product Management and Pricing: Key Success Factors for Software Organizations . Springer Publishing Company, Incorporated, 2009 .

15. J. F. Moore . Predators and prey: A new ecology of competition . Harvard Business Review , 71 ( 3 ): 75 { 86 , May 1993 .

16. R. Paine . A conversation on re ning the concept of keystone species . Conservation Biology , 9 ( 4 ): 962 { 964 , 1995 .

17. a. Sullivan and S. M. She rin . Economics: Principles in action. Pearson Prentice Hall , 2003 .