GUIDE TO OPEN SOURCE BUSINESS MODELS

Transcription

1 GUIDE TO OPEN SOURCE BUSINESS MODELS Leveraging a Free and Open Source Software framework to develop commercialization strategies for IT Research & Development projects Editor: Donald Martin Public Research Centre Henri Tudor 2014

2 This document is published by the Public Research Centre Henri Tudor Luxembourg, 2014 It was created with the support of the European Regional Development Fund 1

3 Guide to Open Source Business Models Leveraging a Free and Open Source Software framework to develop commercialization strategies for IT Research & Development projects SUMMARY The objective of this document is to create a practical guide that will present various Free and Open Source Software (FOSS) business models and intellectual property strategies so that R&D programs can successfully leverage FOSS development models and create more effective commercialization strategies.

4 TABLE OF CONTENTS I Free and Open Source Software... 4 I.1 We know what FOSS means. Don t we?... 4 I.2 Impact of FOSS Ideology on the Development of a Business Model... 5 I.3 FOSS Community Projects vs. Institutional R&D Projects... 5 I.4 From Academia to the Business World... 6 II FOSS Business Models... 8 II.1 A (Very) Short Description of What a Business Model Is... 8 II.1.1 Legal Frameworks and FOSS Business Models... 9 II.1.2 Understanding How the Market Views a Software Product... 9 II.1.3 Developing the Value Configuration for Software Business Models II.1.4 Additional Evaluation Parameters Market & Product II.2 Business Model 1: Support Services for FOSS Software Platforms II.2.1 Business Value of FOSS Software vs. Traditional Software II.2.2 FOSS Software Becomes a Commodity But Not Exactly II.2.3 FOSS Services. How Do They Work? II.2.4 What are the Factors for Growth for FOSS Related Services? II.2.5 Factors Impeding the Success of the Service Business Model II.2.6 Support Services Example II.2.7 How IP Impacts the Business Model II.3 Business Model 2: Dual Licensing Strategies II.3.1 Why a Dual Licensing Strategy? II.3.2 Factors Impeding the Success of the Dual Licensing Business Model II.3.3 Dual Licensing Example II.3.4 How IP impacts the Business Model II.4 Business Model 3: Proprietary Extensions or the Open Core Licensing Model II.4.1 Why an Open Core Licensing Strategy? II.4.2 Factors Impeding the Success of the Open Core Business Model II.4.3 Open Core Licensing Example II.4.4 How IP impacts the Business Model II.5 Business Model 4: Leveraging FOSS Software to Sell Other Products or Services II.5.1 Why a FOSS Complementary Product or Service Model? II.5.2 Factors Impeding the Success of the Complementary Product or Service Model II.5.3 Complementary Product or Service Example II.5.4 How IP impacts the Business Model II.5.5 Open Source Governance Models Controlling Open Source for Commercial Ends II.6 What Does This Mean for the Transfer of R&D Results? III Conclusion

5 I Free and Open Source Software Hopefully you are reading this document because you are planning on creating, or are in the process of creating, a free and open source software (FOSS) project. If this is the case, we would like to offer the following as a source of information specific to the domain of FOSS business models. In this document we will not attempt to give a complete and full account of the FOSS eco-system, merely the dynamics of FOSS as it relates to generating sustainable income for its participants. I.1 WE KNOW WHAT FOSS MEANS. DON T WE? To the average person, the phrase free and open source software generally brings to mind the idea of software without a price or the ability to access or modify software code without legal restraints. In fact, there are two terms combined into this phrase that we will need to explore fully before we can begin to discuss the creation of specific business models. The first, free software, specifically addresses the freedom of creation, distribution and use of software for all people. It does not necessarily concern itself with the price of software. The phrase open source software, on the other hand, is usually linked to a specific means of developing and licensing software based on a group effort that has some unique benefits over closed or proprietary software. While the combination of both of these ideologies into one acronym makes for a somewhat accurate and easily understandable classification, it must be remembered that, to a FOSS development community, not all open source software is free. Free software, as defined by the Free Software Foundation/GNU-GPL community that supports it (please see for more information), defines software freedom as having four principal components; the freedom to run a program at anytime for any purpose, the freedom to study how a program works and have the ability to adapt it to your needs, the freedom to re-distribute copies, and lastly, the freedom to improve the code and to release any improvements that you have made to the public. From a FOSS business model perspective, two important sub-rules should be added to this list. The first has to do with the actual distribution of the software. It has long been recognized in the free software community that a reasonable fee can be charged for the physical distribution of the software (i.e. the physical production of a CD. This may also involve fees to cover distribution costs). The second has to do with software manuals. To the free software community, access to the software manual is just as important as access to the source code. In general, free software (as defined by the FSF) does not deal with matters of price or market forces. On the above web site the proponents of free software say that you can charge a price for the distribution of free software. How this might be achieved in a manner that lends itself to a sustainable business model, is not so clearly discussed. As we will see in the following sections, FOSS business models generally focus on services related to the use of FOSS software. The bundling of FOSS software for distribution and the production of software manuals are just two examples of these services. Open source software, as defined by the Open Source Initiative (please see for more information), lists ten criteria that must be adhered to if the software is to be considered truly open source. Many of these ten criteria are similar in nature to the free software movement s principal components (example: source code must be available for review and modification, software can be used by any group for any purpose, etc.). So what is the difference between the FSF and the OSI? In all practicality, the OSI has allowed, or granted, the right to use the open source name (and a library of pre-approved licenses) to software that conforms to its ten criteria but may not be 100% free of usage restrictions as defined by the FSF. An example is 4

6 necessary to make this clear. On their site the OSI lists the NASA Open Source Agreement 1.3 as a valid open source license that can be used for open source software projects. According to the FSF, the same license is not a free software license because of restrictions that NASA has added to the license for code contributions made as a result of a developer working with third parties. In short, any work done under the NASA Open Source License 1.3 can be called open source but it cannot be called free software. Brief Example of Rights Assigned to Different Types of FOSS Licenses Type of License License Name Degree of Freedoms Provided by Copyright Weak Restrictions BSD, MIT Identification of author, original copyright notice must remain with original code, can be used in proprietary code. Mild Restrictions Apache Identification of the author, description of trademark and copyright permissions, can be used in a proprietary product as long as the original work remains under the original license. Strong Restrictions LGPL, GPL Contains strict rules regarding contributions and use in derivative works. Cannot generally be used in proprietary works without close analysis of the software architecture. I.2 IMPACT OF FOSS IDEOLOGY ON THE DEVELOPMENT OF A BUSINESS MODEL No matter what ideological camp you adhere to, FOSS software is usually developed by communities of people who contribute their work based on a common goal. We say usually, because there are some entities that first develop a software internally and then decide later to adopt a FOSS strategy (as may be the case in publically funded R&D programs). In some cases software developers contribute their time and expertise for no monetary reward. In other cases, these experts may work for a company that provides commercial services linked to an open source project or community. Some of these developers are well known by their peers and contribute frequently to the community. Some of the participants are new to software development and use the open source project as a means to develop competencies that will (hopefully) be recognized at a later date by a potential employer. It is vitally important for an R&D institution that wishes to leverage the benefits of a FOSS software project to understand the motivations of the community they may wish to engage. For this reason, one of the first issues that universities or research centers must address is whether they should define their project as free software, as an open source project or simply closed or proprietary. Once this decision has been made, it will be easier to determine what factors will motivate the FOSS community of developers that they hope to attract to the project. I.3 FOSS COMMUNITY PROJECTS VS. INSTITUTIONAL R&D PROJECTS If we look back on successful FOSS projects we see several examples of open source software development programs that began life as a university research initiative. Given the mandate of most public research organizations it is also not surprising to see that some of the first FOSS software licenses are named after the universities that spawned their creation (MIT, UC Berkeley, University of Illinois, etc.). However, what may not be well understood is that most of these initiatives did not lead to direct commercialization efforts by the research institution themselves. A research subject was explored, code was written and then some type of open source license was then applied to the end result. In several cases, it was individuals or groups outside of the university who took the initiative to build a FOSS community or tried to find commercialization opportunities separate from the originally sponsored work. Based on what we have described above, R&D institutions need to be clear in their 5

7 understanding that just because they have created some software that they plan to release under an open source license does not automatically mean that they are part of a FOSS community or that they will be able to immediately capitalize on some of the software development advantages generally associated with FOSS software. If an R&D institution first creates an internal software development program in house but then wants to engage a FOSS community to help develop a true FOSS product or service, the following questions will need to be addressed: How will the new community be motivated to work on what was essentially a closed open source project? Does the R&D institution have the expertise and funding to launch a FOSS community? Will the FOSS community embrace the technical solution/advancement proposed by the institution s R&D work (does it address a real world or practical problem found in today s IT landscape)? Do the technical competencies of the R&D institution align with or complement the FOSS development community? Will they continue to do so in the future? 1 I.4 FROM ACADEMIA TO THE BUSINESS WORLD Before we begin to examine some of the business models available to open source developers, it might be interesting to review a successful application of open source commercialization that began life as a university research project. Later, we can use this example as a way to highlight some of the important issues that must be understood prior to the selection of a particular FOSS business model. In 1991 three researchers, Keith Bostic, Margo Seltzer and Mike Olson from the University of California (Berkeley) Computer Science Research Group (CSRG), created a new version of a dbm 2 library for Berkeley s UNIX operating system. At the time, the US telecommunications company AT&T had started to enforce its intellectual property rights on several of the different UNIX programs used by the academic community and in response to this problem the researchers at the CSRG were engaged in creating a true open source version of UNIX. As part of this initiative, these three researchers were asked to create a novel and highly efficient alternative to the traditional file-based storage library found in other UNIX distributions. The new dbm library was then released as an open source component of the Berkeley BSD 4.4 UNIX operating system. The authors continued to maintain the new code in its open source form as part of their academic research efforts and, as the popularity of the library grew, were able to leverage the UNIX open source community both as a means to improve their work and to have the code adopted for use in several other large scale projects. For four years, the dbm library was used and available freely to the public via an academic open source license. Then, in 1996 a computer science research team at the University of Michigan working on a LDAP server project decided to use the library (now called Berkeley DB) based on its functionality and maturity. Shortly after this work was completed, a small start-up company called Netscape hired some of the same University of Michigan researchers to work on a set of LDAP server tools. It was at this point that Netscape, based on recommendations from the University of Michigan researchers, approached two of the original developers and asked them to create an enhanced version of the library with extended functionalities. The researchers agreed but one of the conditions of their work was that all intellectual property rights for the new code would remain with the researchers. Netscape would get its enhanced LDAP server suite, but the developers would keep the rights to the use of the dbm specific code. 1 Insight provided by Rolf Pawelzik as part of his work on the COCOMO project. 2 Unix library for database management and access 6

8 Because of the popularity of the BSD UNIX system and due to the maturity of the code that had been gained via several years of enhancement and validation via the open source community, the original authors had a unique opportunity to see the commercial potential of what they had developed. By working with Netscape, the researchers realized that there might be the potential to offer both an open source version of the code and a closed version of the code for use in commercial applications. The three founding researchers quickly drafted a special type of open source license and founded a company to begin taking advantage of the new code developed for Netscape. The researchers decided that the license (called the Sleepycat license) would offer both an open source component and a commercial component in what would later be referred to as a dual-licensing strategy. We will explain dual-licensing more thoroughly in the next section, but for now the important point to understand is that the researchers created a software license that forced other developers or users to release their contribution back to the community unless they wanted to use the software for commercial purposes. If a company wanted to use the code in a product or application, the Sleepycat license allowed them to make modifications without returning the code back to the open source community (keeping safe their proprietary information or business secrets but paying a license fee for the right to do so). The researchers were able to accomplish this primarily because of the nature of the Berkeley BSD open source license and the fact that they made sure that they had secured the intellectual property rights to the new library functionalities developed during their work for Netscape. From 1997 until 2006 the company founded by the original research team was able to successfully apply a dual licensing strategy to support both the open source Berkeley DB developer community and their company. Because of the company s ability to obtain revenue from commercial licenses, software developers were hired to contribute to both the open and commercial versions of the software. Contributions from the open source community were available for use provided that the users did not try to commercialize the code or refused to release their new development back into the community. Commercial partners could easily obtain the rights to have new product specific modifications made by the company without the fear that their proprietary information would be made public. In 2006 Sleepycat Software was acquired by Oracle. At the time of the acquisition, it was estimated that there were over 200 million deployments of Berkeley DB library. It is interesting to note that the company, Sleepycat Software had always relied on funding gained from its licensing and support business. In an age where most new software companies require large amounts of venture capital to get their business models up and running, Sleepycat never had to obtain outside funding to support its operations. 7

9 II FOSS Business Models FOSS business won t work unless you serve both those who spend time to save money and those who spend money to save time 3. II.1 A (VERY) SHORT DESCRIPTION OF WHAT A BUSINESS MODEL IS A business model, defined as simply as possible, is a description of the framework in which different actors will create value for one another through the exchange of goods and services for financial consideration. It should not be confused with a business plan or strategy. A business plan focuses on the details of how one company would use its strengths and opportunities to gain competitive advantage in a specific type of business model. A business model is the template upon which a business plan is defined. Figure 1 Components of a Business Model 4 From the above template, we can see that several key objects and their relationships to one another have been defined. Most seem obvious, such as the creation of a value proposition between a customer and a goods or services provider. However each year many businesses fail due to a fundamental lack of understanding of their business model. Companies may not correctly define what the cost structure of their business is or may not completely understand the needs of their target customer. As a fundamental starting point in our examination of FOSS business models, we will use the above framework as a way to formally describe some of the more successful FOSS business models. It is important to note here that FOSS in itself is not a business model. FOSS is a way to produce software. In the next sections we will explore business models that use FOSS as a means to create a different value proposition for customers who need software. Description of the Business Model Components 5 3 From 4 Alex Osterwalder 2006, from Slideshare.com slide 2, at Creative Commons Attribution-ShareAlike 2.5 License 8

10 Infrastructure Offer Customer Finance Core Capabilities Partner Network Value Configuration What is the value proposition? Customer Relationship Distribution Channel Target Customer Cost Structure Revenue Streams Resources and skills necessary to participate in the business model Who are the key partners and why do they participate in the model? What are the primary business activities that will be executed in the model? What exchange will take place between the customer and the provider of goods or services? What relationships exist with the clients? What are the primary communication and distribution avenues by which the customers receive the goods or service? Who are my target customers and in what market segment do they belong? What are my principal costs for this business model? What capital is needed to keep the business in operation? Where does the revenue come from in this model? II.1.1 Legal Frameworks and FOSS Business Models There is no question that FOSS business models rely heavily on intellectual property law. In his book Open Source Licensing Software Freedom and Intellectual Property Law, the author Lawrence Rosen approaches the description of FOSS business models by framing their activities in light of the intellectual property laws that govern the software s use. More simply put, since intellectual property law (specifically copyright) protects the creation and use of FOSS software in the business domain, one should naturally start there in order to determine what business models are possible. To quote the author, it is often more rewarding to consider the exclusions from license rather than the open source grants of license when looking for opportunities for profit 6. While this could be an excellent place to start, defining business models via the legal rights defined in specific licenses may not be the easiest way to approach the subject for non-ip experts. We also have to consider that different countries may interpret copyright law in different ways and so it may not always be feasible to take this approach. While we will point out the intellectual property rights applied in each of the business models listed below, it will be much easier to approach the subject of FOSS business models using our generic business model template. II.1.2 Understanding How the Market Views a Software Product Software is Different from other Types of Products , Osterwalder, Alex, Business Model Design and Innovation Blog, Reviewed 7/ , Open Source Licensing Software Freedom and Intellectual Property Law, Rosen, Prentice Hall, Page 231 9

11 It may seem obvious, but software does not have some of the same manufacturing or economic constraints that other goods and services have. Because of the ease by which software can be modified and distributed, software producers can offer a wide range of product features and different pricing models. As it is easy to copy and distribute, intellectual property protection must be a key component to any business model. Another factor is that consumers of software have a very personal and close relationship to the product. The leveraging of information via software gives the consumer a very immediate and high impact result. Only after the product has been tried can users begin to assign a value to its worth. Another unique factor is that while software can be easily copied and distributed, consumers can be made loyal to a specific software by understanding the concept of switching costs. Customers of software goods will resist abandoning one product for another if they have already invested what they believe are significant resources (time spent learning the API, training fees, maintenance costs already budgeted, etc). A business that understands how to effect the switching costs for both complimentary and competitive products can inhibit competitors from taking market share. Software is also a complex entity that is not just purchased, used and then left in a static state until its next use. Software almost always requires some type of adjustments or modifications. Finally, it has been noted that software consumption is highly influenced by network effects. This simply means that vendors, partners and customers are all dynamically linked when it comes to the determination of the overall value of the software. Those companies that can create positive network effects (feedback, goodwill ) will prosper this is where the true power of the FOSS development comes into play. From these basic components, software business models are developed. Software industry analyst Brent Williams 7 developed an overview of the software market from a customer perspective in order to explain how customers view software use and value: Generic Product Description Software is: High-Risk Industrial Capital Equipment, a variant on standard Capital Equipment. A Standard Industrial Capital Equipment product is defined as: High direct purchase cost (big printing presses, locomotives, etc.) High indirect acquisition cost (personnel training, installation time, complex dependencies on other software in environment, extensive hardware purchases) High lifetime operating cost, emphasis on reliability. Has the added dimension of extreme failure risk (i.e., high contingent cost ). Similar examples: Planes crash (can t buy generic jet engine parts on ebay) People die (radiation therapy machines can t run amok) Stocks plummet (last week s software bug in computing the Dow) Companies go out of business (any large Web site failure or airline reservation site crash) Added dimension of not being able to even measure contingent costs accurately: Fear replaces numbers as decision making criterion safe buy perception. How FOSS fits this model Just as much a high-risk capital good as regular software. Direct purchase cost is lower. Indirect costs may be the same or higher. However, customers may have the perception that using the software should be less costly than a proprietary product. Also, risk may be perceived as higher than proprietary software as there may not be one company or supplier to hold accountable for problems. Same, but FOSS development should lower security and bug issues due to the distributed development / QC functions inherent to FOSS development model. Same. However FOSS products exhibit aspects of a branded consumer luxury good (i.e. Red Hat vs. Novell) Strong brand preference like perfume Bought for abstract reasons - My Linux distro is cooler than your Linux distro! You can have a branded luxury good with commodity ingredients , B. Williams, Open Source Business Models: A Wall Street Look at a Wild 2006 and the Prospects for Even More Fun in 2007, EPL license V1.0 10

12 One of the key problems that software developers (inside or outside of an R&D institution) have is aligning a new technology with a specific business model. ICT technologies develop rapidly and are easy to apply to new areas or industries. However, just because a new technology has been developed does not mean that there will be a market ready to adopt it. From a purley commercial perspective, this is one of the problems with research and innovation. From a business development perspective, it is better to first identify a specific customer need and then apply some type of technology (new or old) to address that need. II.1.3 Developing the Value Configuration for Software Business Models In the above business model component template we have one section labelled Infrastructure. Within that section is a sub-component called Value Configuration. It is in this section that we define the core business activities that a software company (FOSS or otherwise) will develop in order to produce payable products or services. For most software companies, these activities can be grouped into four general activities: Services a company that develops custom software solutions for one or multiple clients. Unless a client requests some type of maintenance or support contract, once the software has been developed and the client pays the invoice the business transaction is complete. Competitors can easily enter the market as long as they can perform the same work (knowledge of software programming for a specific platform or industry). In this model, code is not often reused and customers dictate how the software will evolve. Growth in this model relies on developing a close relationship with specific, heavily software-reliant businesses and then promoting your company s reputation as a trusted supplier generally in only one industry. Product Centered Services in this model a company choses to build services around an existing software platform (or builds services around a platform developed in house). By only supporting a limited number of products, efficiencies can be gained (code reuse, lower training costs, use of standards) and different industries can be serviced by one actor. As platform related services require the support of non-developers (installation/change management support, sales & marketing, etc.) more start-up funding may be required to launch the business. Growth in this model is tied directly to the success and continued development of the platform being supported. Products just as a manufacturer produces a product for a specific market, software companies produce software that tries to solve a specific problem or need for a large number of customers. While the start-up costs are extremely high, there are no costs to copy (and in some cases distribute) the product. Support for the software must be provided, however maintenance for individual customers does not really exist. Costs to develop the software are high as the product must work in different operating environments and should have features that are interesting to a wide range of users. Sales and marketing costs are also great and can act as a barrier to entry for competitors. This model carries the highest risk as the software must first be built prior to interaction with clients and bug fixes can be difficult to distribute to existing customers. Growth in this model depends on the popularity of the product with the widest possible population of users and first mover advantage in the targeted market. Products Distributed as Services this last model is generally referred to as software as a service (SaaS). In simplest terms, a software product is provided to a customer via a generic interface (such as a web browser). Customers may have the option of choosing different pre-defined features or will use a version with reduced features at a lower cost. The customer is generally only charged on a per use basis and does not have to worry about software installation issues, license verification and tracking, or upgrades due to bug fixes. Drawbacks to this model include customer data storage and the need for a robust and secure network to provide connectivity and hosting support to the customer. Revenues for this model tend to be lower than the product model and 11

13 growth occurs only if the customer finds this solution more attractive (cost, hardware flexibility) than a similar offering from a typical software product. Graphical Representation of a Software Companies Value Configuration 8 II.1.4 Additional Evaluation Parameters Market & Product A framework that highlights the structure of a feasible business model is a good starting point, but several FOSS business leaders have identified or confirmed the importance of specific factors that will contribute to the overall success of a FOSS business model. These factors were identified in a presentation made by the former CEO of MySQL AB. 9 Key questions that should be asked when evaluating a FOSS business model: Does the software create a new product category or does it significantly improve upon or challenge products in an existing product category? Is it difficult for consumers to find viable replacements for the product in this category? Are the demands of the target market not being adequately met today? Why? What is size of the developer population that would be interested in adopting this product category? For IT departments, in addition to the FOSS software that has been made available to the development community, what related products, tools or services could be sold to IT managers who need to save time or money? It is this last question that is perhaps the most important in the context of FOSS businesses. As we will see in the next sections, in a business environment developers will support a FOSS application if it , Software Industry Model Map - Version 1.0, J. LeBlanc, Creative Commons License, 9 From 12

14 makes their jobs easier. However, in this same business environment the management structure that supports the developer will need to have a significant reason to authorize the purchase of an additional product or service (typically bundled with other FOSS services like license indemnities or warranties) that may be offered with a free of cost software platform. Thinking in Terms of the Product Through an unscientific review of websites, blogs and grey publications it becomes clear that in addition to questions about software architecture issues and community management planning, todays FOSS project leaders must also focus on defining products or services that will allow them to meet their project sustainability goals. Listed below are some items to consider when developing a product or service within the context of a business model: Customers do not buy technologies, customers buy solutions to problems this statement is meant to emphasize that to a customer it is not the technology that is interesting. It is the efficiency (cost and effort) of the solution to the problem that is valuable. Based on Geoffrey Moore s work in Crossing the Chasm, it has been shown that companies that provide a total or whole solution (product plus compliments) to a customer or market will be more successful than their competitors who do not offer a complete set of products or only a partial solution to a problem 10. From the prolific blogger and recognized FOSS expert Stephen Walli, there are some classic products that are typically created by technology solution companies to address the problems that their customers face 11 : Buy or build complements and include them in the base product. Publish interfaces to encourage complement value add [sic] in an ecosystem of partners. Provide tools and frameworks to ensure partners can easily build complementary products in the ecosystem, providing an even bigger "whole solution" or enabling it to be re-positioned into new markets (i.e. onto new problems). Publish tutorials, how-tos, books, etc. to ensure people understand the product solution and can provide complement value add [sic] in the ecosystem. And publish here is a very loose word. Consider magazines and conferences and user groups here as well, and how the web helps or supplants each. Develop training programs to ensure people understand the product solution. Develop certification programs to ensure a good supply of knowledgeable people on the solution. Provide consulting services to ensure an immediate supply of knowledgeable people on the solution. Really though, it could be other services as well (maintenance, repair, operational, etc.) In the next section, we will explore how most of these components fit into the business model for typical FOSS projects. 10 G. Moore, Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers, , HarperCollins

15 II.2 BUSINESS MODEL 1: SUPPORT SERVICES FOR FOSS SOFTWARE PLATFORMS If FOSS software is free for use and the community of developers that supports its continued development is required to return their contributions back to the community (as stated for example in a GNU/GPL type license), then a natural question for those not familiar with FOSS software is how can anyone create a business model around such a situation. We begin with support services because it is this business model that is the most widely visible and deals directly with all factors found in the most free and open of all FOSS licenses the GNU/GPL. As the name implies, the value proposition of the support services business model relies on the premise that it is not the software by itself that is of value to customers, but the added benefit of different services that makes the software easier for customers to adopt or modify. II.2.1 Business Value of FOSS Software vs. Traditional Software Typically, proprietary software vendors are responsible for both the creation and testing of the code as well as the marketing and support of the product once it is ready for the marketplace. This last dynamic of the proprietary model reveals itself in the following IT industry statistic; on average 60% of the cost of a proprietary software product is devoted to on-going software maintenance 12. Obviously, FOSS software projects change this dynamic because the act of creating and maintaining the software s code is now outside the control of one company. Again, because of the intellectual property laws defining the use of the software, early adopters of FOSS software projects can leverage communities of experts to validate and improve the code while at the same time lowering licensing fees. However, barriers to the adoption of FOSS software generally manifested themselves in concerns with a lack of a central vendor or manufacturer, lack of local (or in-house) technical skills to support the software, and legal risk 13. We should point out that the most successful FOSS projects generally occurred in areas where adopters already had a high degree of technical expertise and the software employed offered a solution to a very specific type of IT problem not necessarily a commercial product designed for a mass market. Apache web server software, MySQL databases and Linux-based operating systems (servers, not PCs) were successful due to their ability to provide a solution that was both more cost effective and, in some cases, more technically efficient than what the proprietary software market could offer at the time. For the general IT market, this is the principal value proposition for the adoption of FOSS software. For FOSS service providers, this is the foundation from which the business services model is built. II.2.2 FOSS Software Becomes a Commodity But Not Exactly As we will see in this document, the rights granted via a FOSS software license directly impacts the type of business model that can be applied. The end result of developers submitting their work under a FOSS license like the GNU/GPL is that it insures that no one software vendor/author can offer a version of the code that is better or more efficient than what can be found with another vendor or author. From a business perspective, because GPL licensed source code is freely available and easy to distribute, it now begins to look and behave less like a product (or set of products) and more like a commodity or a raw material 14. When we talk about the commoditization of software, we refer to the fact that as FOSS developers share code, libraries and modules (components of a software product), , Facts and Fallacies of Software Engineering (Agile Software Development), Glass, Addison-Wesley, Page , The Costs and Risks of Open Source, Giera, Forrester Research, Inc , Open Source: Software as a commodity, McCreesh, 14

16 the cost of developing software drops. And as technical features (and developer knowledge) specific to certain FOSS software becomes incorporated into other FOSS platforms, it become more difficult to establish clear differences between the different offerings. This does not mean that FOSS software behaves like a commodity in the software market place. The below comparison from industry analyst Brent Williams 15 explains the difference more clearly: Generic Commodity Marketplace Behaviour No switching costs to buy from different producer. Market prices are a function of changes in supply and demand. Enterprise Software Marketplace Open Source Software Marketplace Behaviour Behaviour Customers loyal to incumbent vendors. Customers loyal to incumbent distribution vendors. Software supply is infinite (zero Software supply is always infinite (zero duplication costs). duplication costs). Producers can t affect demand, only supply. Pricing moves quickly to find a point of supply/demand equilibrium. Excess profits quickly disappear and producer profits revert to the mean of the economy as a whole. Lowest-cost producer wins in a commodity marketplace, because he can sustain excess profits longer than all other producers. Producers in software create entire markets (nobody knew they needed a relational database until somebody invented one). Producers drive their own demand by differentiating their products from competition. How often do software companies update their price books? Not often. Operating margins for software companies have always been above the level of the economy as a whole, regardless of industry growth rate. Software industry operating profits are at highest level ever, relative to the industry s past. Microsoft spends 25% of revenue on R&D. They are not the lowest-cost producer. Everybody is making excess profits in the software industry. Producers create entire markets. Producers drive their own demand by differentiating their products from competition (maybe in slightly different ways) How often do open source software companies update their price books? Not often. Operating margins for open source software companies have always been above the level of the economy as a whole, regardless of industry growth rate. Open source software industry profits are at highest level ever, relative to the industry s past. Open source vendors may have slightly lower R&D costs than other companies, and may even see marketing benefits as well, on both open source & proprietary offerings. Not sure yet whether everybody is making excess profits in the open source software industry. So while the components that make up FOSS software can become commoditized, the actual software product and services created by a company follows the classic model of the software market. II.2.3 FOSS Services. How Do They Work? So what services can one provide to support open source software? The answer lies in both the market s perception of FOSS software as compared to proprietary software products and in the demand for FOSS software in the marketplace. Some of the original complaints concerning open source software had to do with the perception of the quality of the code (i.e. the level of expertise of the people building the code, the lack of one company to support or guarantee the quality of the work) and a lack of documentation. To address these two issues, FOSS service companies began to create installation packages that would be easy for non-technical users to work with. Some companies, like O Reilly Media, only focused on providing technical documents or user conferences where FOSS developers could meet and improve their skills. Later, as the acceptance of FOSS software grew from early adopters (software developers or hackers ) to more mainstream users (such as government , B. Williams, Open Source Business Models: A Wall Street Look at a Wild 2006 and the Prospects for Even More Fun in 2007, EPL license V1.0 15

17 institutions or corporate clients), the number and complexity of the services grew as well. We have listed below a simple overview of some of these classic FOSS services. Types of Customers Typical FOSS Services Software Developer Corporate or Govt. Client Individual Client SW documentation / User training guides X X X SW distribution / Bundling Personal certification / Training courses X X FOSS community support Interoperability testing X Software certification / Warranties X X X X X X Patches / Special releases (security) Consulting / Custom engineering X X X On demand support / Troubleshooting X X The above services did not appear overnight and certainly not at the same time. FOSS software can be thought of as a disruptive innovation model due to the fact that it fundamentally changes how software is developed and distributed. Interestingly, one of the first challenges in developing FOSS services was not which services to offer, but how to support the FOSS development community so that they could produce software of a higher quality that could compete against the next best alternative in the marketplace proprietary software. The market demand for the services related to the FOSS software would have developed only as a result of the increasing quality, maturity and functionality of the underlying product. Naturally customers had to be educated as to the nature of this new type of software before they could become potential customers for FOSS services. For this reason it was logical for FOSS service providers to help the community organize itself, communicate its successes and actively promote the benefits of FOSS software. Therefore, any organization that wishes to engage in FOSS services should understand that FOSS community support and contributions should be thought of as a significant cost when developing their business model. II.2.4 What are the Factors for Growth for FOSS Related Services? As there are generally a finite number of customers that are both willing and capable of purchasing a specific good or service, it should come as no surprise that one of the first acts of evaluating a business model will be the estimation of the size of the market. For software, we can easily understand that the total market size for an operating system will be different from the market size of a customer relationship management (CRM) platform. After formulating the general market size for the solution you intend to support, the next step is then to determine how many of these customers would be willing to adopt a FOSS software solution as apposed to a proprietary one. For example, as of December 2008, the on-line metrics company Net Applications reports that 90.6% of the global web 16

18 community uses Microsoft Windows while only 0.7% use some form of Linux 16 desktop system. The point that we wish to make here is that, depending on the market in which the FOSS software competes, FOSS service providers face a battle on two fronts. The first front is to try to encourage moving market share away from an existing proprietary solution (thereby increasing the total number of open source users for a particular type of FOSS software). The second front for a service provider is the competition against other FOSS service providers who may be in the same market. Growth Drivers If we accept the assumption that FOSS software is a commodity-like product, then as a service provider there are only a few mechanisms that will contribute to overall growth. Market Growth Drivers In a Weak Competitive Environment In a Strong Competitive Environment Offer a higher quality of service than your competitors Develop highly specialized niche services based on price sensitivity or engineering competencies Increase the number of services offerings for a specific software platform (gain reputation as leading platform expert) Or, extend the number of FOSS platforms that your services support (gain reputation as FOSS expert) Build strong brand awareness among customers Repositioning of the brand to reflect a more specific market strategy Form strategic partnerships to bundle or link services II.2.5 Factors Impeding the Success of the Service Business Model The principal factor behind the success or failure of a FOSS services business model hinges on the functionality, growth and popularity of the FOSS software platform being supported. No matter how good your customer service is, no matter how innovative your marketing program, if your customers do not find the FOSS software that you support to be the best solution for their software needs then you will never have a viable business model. As we have discussed above, providing services for a commodity-like product means that the market must have already exhibited a demand for, or basic understanding of the value of, the software. FOSS software is similar in one way to commodities in that entry into the marketplace is easy for competitors and growth in market share is generally the result of aggressive marketing and branding of services. Also, as mentioned above, it should be recognized that working within a FOSS community does add a cost to the business model that must be taken into account when launching any new initiative. For R&D institutions that are developing new software based on existing FOSS platforms or are developing entirely new software that they would want to make open source, the service business model is not an immediately viable means to transfer the new technology to the market. II.2.6 Support Services Example Probably the best known examples of a FOSS services business model would be found in those companies that support the Linux kernel. There are in fact many different companies that offer

19 services based on the support of Linux. Perhaps the most well-known (and profitable) are Red Hat, Novell and Canonical. Service Offerings Linux Distributors Red Hat (Red Hat Linux) SUSE Novell (Open SuSe) Canonical (Ubuntu) Enterprise server and desktop versions Enterprise server and desktop versions Enterprise server and desktop versions Certification of software builds or hardware compatibility Certification of software builds or hardware compatibility Certification of software builds or hardware compatibility Integration of complementary FOSS software platforms Integration of complementary FOSS software platforms Consulting & Engineering Services Consulting & Engineering Services Consulting & Engineering Services Training/Personal Certification Services Training/ Personal Certification Services Training/ Personal Certification Services Community Support Community Support Community Support Each of these companies will try to gain competitive advantage over the other by employing strategies described in the Market Growth Drivers box listed above. For example, Red Hat purchased the JBOSS open source middleware suite so that it can offer complementary services for connecting Linux-based server operating systems with middleware applications. Another example is the re-branding in 2006 that Novell did for its SUSE Linux 10 version to attract more desktop users away from its competitors. Each of these three competitors strives to make partnerships with VARs (value added resellers) and to gain distribution channels via hardware companies like IBM and Dell. Because of the ease in which new competition can enter the market and create pressures to lower prices, the profit margins of these service companies compared to proprietary software companies are generally much lower 17. II.2.7 How IP Impacts the Business Model Throughout this discussion of service-based business models we have used the GNU/GPL license as a key component in the behaviour of the model. The reason for this is that the use of a less restrictive FOSS license would dramatically change the dynamics of the model. For example, if the Linux software were created and licensed using an academic license, the rules of that license would allow each vendor to create a unique version without having to give the modifications back to the community. The software would no longer be considered a commodity and the Linux community would end up with several, most likely non-compatible, versions of the operating system. Business Model Components Support Services for FOSS Software Infrastructure Core Capabilities Company must have: expert level knowledge of one or more FOSS software platforms, IT infrastructure to support the bundling and distribution of the software, IT infrastructure and staff to support a FOSS community , Red Hat, Novell Face Pressure as Open-Source Doubts Mount, Reiter, Chris, Dow Jones News Wires, 18

20 Partner Network FOSS community, Hardware vendors, Independent Software Vendors (ISVs), IT Consultants and Publishers. An ecosystem that will develop itself based on how efficiently the software solves the technical problem. Value Configuration Software Bundling, FOSS community support, Consulting, Help Desk Support, Documentation/Publications, Advanced IT engineering Offer What is the value proposition? The core value proposition of this model is to provide services that make FOSS software easier and more cost effective for customers to use versus a proprietary solution or other FOSS projects Customer Relationship Company must develop a relationship with both the FOSS development community and the end users of FOSS software (generally weighted more towards businesses than individual users) Customer Distribution Channel Target Customer Internet, Publications and Conferences Several different types of target customers possible. Business that use FOSS software, Developers of FOSS software, the FOSS community itself. Customers who wish to reduce IT costs by transitioning to FOSS platforms. Market segment will depend on platform and competition. Finance Cost Structure Revenue Streams FOSS community support costs, Marketing and Communications costs, IT Infrastructure (servers, in house developers, documentation). Revenue can come from consulting, client-specific engineering or support, help desk support, documentation, software warranties, software bundling and automatic updates II.3 BUSINESS MODEL 2: DUAL LICENSING STRATEGIES At first, the idea of dual licensing seems strange when applied to open source projects. In effect, the licensor is saying that; if you follow a specific set of rules and don t want to use our code in a commercial product, you may use (and distribute) this software without cost. However, if you want to use this software for commercial activities and keep your competitors from seeing your improvements to the code, then you must purchase the rights to do this from me. The ability to use this kind of strategy is based entirely on the ownership of the copyright on the software. Copyright law gives the author of a work the right to license that work as they wish and to whomever they wish. In publishing, it is quite common for an author of a book to negotiate one type of license for one geographical area 19

21 and then another license for distribution in other areas or languages. If you own the copyright, you can control the means by which your work is distributed and used. With open source software, dual licensing generally manifests itself in the following way: an author creates a unique piece of software, or modifies an existing software that uses a non-copyleft 18 (example, academic BSD style) license. Because in each case the author has the right to establish copyright rights over the work that he or she has done (an academic style license does not require developers to return their modifications back to the community), the author can then decide the conditions over which this new or derivative work may be licensed. If the developer chose to modify an existing work under an academic license, the only obligation that the author has is to keep the copyright notice of the previous work intact so that everyone knows who developed the original part and who then developed the derivative part. If the work is original and does not use any copyrighted material from other parties, then the author simply has to choose what license he or she wants to apply. If the author chooses to release the code as open source, then the author needs to choose from one of several types of licenses based on how he or she would like their work to be used. However, this does not mean that the author cannot then offer a different type of license to other users. We will explain this in more detail below. In our earlier Sleepycat example, the developers of the Berkeley DB software had originally released the code under the Berkeley BSD license, an academic non-copyleft license. For several years, the code remained in the domain of the open source community and several modifications and upgrades were made to the code, both from the original authors and by other contributors. However, since the copyright notice remained with the code, it was possible to determine who was responsible for the work. When Netscape approached the three original authors to help them with their project, it was mostly due to the reputation of the developer s technical skills in their domain. Because the original authors requested that Netscape grant them the copyright to the modifications made to the existing Berkeley DB code, the authors now had the ability to do one of several things: 1. They could release the new modifications under the already existing conditions of the Berkeley BSD license 2. They could release the modifications under another license (open source, proprietary or both) 3. They could decide release some of the modifications back to the Berkeley BSD and release other parts under another type of license 4. They could decide not to release the modifications at all In most countries it is a point of law that once an author has released a work under a specific type of license, the author then cannot go back and retroactively change the conditions of the license so that it benefits or penalizes certain types of users. If the author releases their work under a FOSS license (academic or copyleft) to the public, he or she cannot then go to back to certain licensees (or users) and change their conditions of use just because a licensee has found a way to make money using the software. What the copyright holders can do is to create two separate licensing strategies for the software that they have the rights to. While the software under each license may be the same, the software is now seen as separate and governed by two different licensing strategies. II.3.1 Why a Dual Licensing Strategy? The dual licensing strategy is unique in that it tries to utilize the benefits of FOSS development and yet at the same time recognizes that businesses need to develop products and services that cannot be easily copied by their competitors. If a company wishes to create a modification to open source code that is governed only by a copyleft license, then that company would be obligated, under the legal terms of the license, to return the code modifications to the public for use and distribution. However, if the 18 Copyleft is a modification of the term copyright. Copyleft means that you use copyright law to promote the free use and distribution of your copyrighted material (and any derivative works) instead of restricting its use. 20

22 authors of a particular work of software create a dual licensing strategy, then businesses can create (or ask the original authors to create) modifications to the original work without fear that this work would not remain confidential. Typically this occurs when a component of open source code needs to be integrated into a larger software application that will be sold by a commercial entity. In effect what happens is that the original code remains in the FOSS domain under a specific type of open source license. The FOSS community can use and modify this code based on the type of open source license used. The original software grows and matures based on the benefits of FOSS development. However, because the copyright holders have the right to issue a different type of license to companies, these entities can make code modification to the original code in order to develop a separate or proprietary version of the code. The benefits of this strategy to the copyright holders are numerous. First, because some of the development and testing costs for the software have been absorbed by the FOSS development community, the total cost of developing and validating the FOSS licensed version of the software has been lowered. The copyright holder should be able to attract companies away from similar proprietary solutions by offering a lower licensing fee. Prior to their sale to Oracle, MySQL uses this tactic as it offered a per server license that was much less expensive than what Oracle or Microsoft demanded. While it is clear that Oracle or Microsoft offered a more sophisticated product in terms of features or scalability, companies who s applications do not require advanced functionalities but are faced with budget pressures will migrate to the lower cost alternative. This is evident today as many IT departments are looking to reduce costs by replacing mission critical proprietary database software with open source alternatives 19. Another benefit for the dual licensing model is that companies can test the open source version of the software without cost in order to decide whether or not to adopt the software. Again, many IT developers became familiar with the open sourced MySQL software because they had used it both personally and professionally for non-critical web applications. Once consumers gain a certain familiarity with one version of a product, they will naturally try to find additional uses for it. Having the ability to test a product prior to buying it reduces risk and increases innovation. Next, the dual licensing strategy provides an opportunity for the copyright holders to offer advanced consulting or development services to companies who wish to use the software but may not have the expertise to modify the code themselves. The principal point of a dual licensing strategy is to use the author s copyright rights to their business advantage. II.3.2 Factors Impeding the Success of the Dual Licensing Business Model The biggest factor impeding the success of a dual licensing strategy is the inability to identify or create a specific business need for a proprietary version of the FOSS software. In the cases of Sleepycat and MySQL, customers needed to use the software in their applications but could not risk giving their competitors access to their customized solutions via the FOSS license structure. From these two examples, it is clear that the FOSS software is first perceived to be a technical solution that is at least equal to or superior to other commercial alternatives. This brings us to our second factor. If FOSS software cannot differentiate itself as a relevant alternative to commercial software, and if customers do not perceive the FOSS software as being a superior technical solution to other similar FOSS projects, then the dual licensing strategy will not be commercially successful. Again, we need to highlight the importance of a strong community engagement/management process linked to the open source version of the code. Finally, as there will be two versions of the software, close attention needs to be paid to the inclusion of new code into the proprietary version. If the open source version of the code utilizes a strong copyleft license (like the GPL), contributions made by other developers cannot 19 EDS case study, Award-winning use of open source technology drives savings and adds value, (40% TOC ownership reduction for Sabre) 21

23 be automatically moved over to the proprietary version. Any company employing a dual licensing strategy will need to clearly separate the two versions of the code and put procedures in place to insure that the proprietary version does not become contaminated with code from the FOSS version. Developers working on the proprietary version of the code can utilize the FOSS developer s contributions as examples of how to solve certain technical problems; however they must then create their own code and submit it to the proprietary version. In some projects, all external developers who submit code changes, new code contributions or bug fixes must first assign their copyright to the owners of the project before any contributions are accepted 20. II.3.3 Dual Licensing Example Apatar is an open source ETL (Extract, Transform, Load) software application with added data integration functionalities. While the Apatar open source software project was started in 2005, Apatar, Inc., the commercial company that supports both the FOSS project and provides Apatar-based services, was founded much later (2007). There are other FOSS ETL projects (Clover.ETL, Pentaho Project, JasperETL), however Apatar Inc. is a good example of a commercial company providing both a dual licensing structure as well as classic open source services (consulting, training, and development support). Apatar s model closely follows the framework described in the previous section as they rely on their customer s need to developed customizable ETL solutions at a minimal cost. The key difference between the open source version (strong copyleft GPL) and the proprietary version is generally found in custom coded libraries. It is interesting to note that this company does not rely solely on the ability to license two different versions of a software, but combines both the FOSS services and dual license business models in order to remain profitable. II.3.4 How IP impacts the Business Model As stated above, this model relies heavily on the complete control of the copyright of the code. The level of contributions from external FOSS developers may be limited if they are required to assign all copyright (and patent rights) to the project. External developers will do this, however it is important that there are procedures in place to monitor the contributions from the community and make sure that there is never a conflict between the two versions. Business Model Components Dual Licensing Model Infrastructure Core Capabilities Ownership of the copyright of the original code. Identification of a clear market need for a proprietary version of the software. Superior technical knowledge of the software. Ability to separate FOSS and proprietary software development environments. Ability to develop customer specific modifications for different markets or products. Partner Network An open source community that will support the continued development and promotion of the FOSS version of the software. 20 A good example of this is the SugarCRM agreement found at 22

24 Value Configuration Licensing of the proprietary version. Customer specific programming. FOSS support services for the open source version. Sale of training materials and publications. Offer What is the value proposition? Customers receive a license for proprietary version that they can modify as they require. Customers can also use the FOSS version and only pay for support as needed. Customer Relationship Close relationship with customers due to customizable software requirements. Close support of the FOSS community supporting the open source version as some services can be offered to these users. Customer Distribution Channel Software itself is generally available via the internet however the creation of official partner agreements with other service providers can be used as a means to build the customer base and expand services. Target Customer Software resellers. Hardware suppliers in need of custom software. Any industry requiring a customized software solution that is more cost effective than a similar proprietary solution. Finance Cost Structure Developers to maintain or customize the proprietary code base. FOSS community support costs. Marketing of customized solutions or support services to clients. Development of training, publication or support services. Revenue Streams Revenue from licensing and support service contracts. Revenues from other FOSS services. II.4 BUSINESS MODEL 3: PROPRIETARY EXTENSIONS OR THE OPEN CORE LICENSING MODEL Open core software is different from a dual licensed software in that there is generally one open source version of an application (called the core) for which several non-open source extensions or components have been developed. These extensions are proprietary in that they must be purchased from a company or vendor; however they are designed specifically to work with a core application that already provides a significant value proposition to its consumers. In this model, the type of open source license used for the core is not of key importance (however most companies will chose a strong copyleft license as a means to block competitors and show support for external FOSS community developers). What is important is how the proprietary extension adds additional value to the core. As with all FOSS applications, the quality of the open source code will directly correlate to the value of any related products or services that support the application. 23

25 II.4.1 Why an Open Core Licensing Strategy? Open core licensing is a natural extension of the FOSS services business model as it relies on a nocost, high quality FOSS software solution as a means to develop additional products. It is also an extension of the dual license model as it proposes to offer consumers choices based on their needs. As significant revenues from FOSS services can be very difficult to obtain 21, many FOSS related companies look to this business model as a way of increasing their revenue opportunities while still supporting, in a reduced way, the FOSS development model. II.4.2 Factors Impeding the Success of the Open Core Business Model Critics of the open core model point out that one of the most important motivators for the adoption and growth of FOSS software, the avoidance of relying on one company to provide software and support sometimes referred to as vendor lock-in, does not truly exist in the open core model 22. Customers of FOSS products are attracted by the low cost and high level of security that are provided by open access to the code. The open core business model, while relying on a FOSS driven software base, forces its customers to go to one vendor for advanced solutions or additional features. If the vendor is the key supporter of the FOSS community and there are no other similar FOSS-based alternatives, then the open core strategy can provide the foundation for a successful business model. However the customer will still be faced with some type of vendor lock-in that competitors may attack. Another consideration is the level of contribution by the FOSS developer community. Companies utilizing the open core model may find contributions from external developers to be limited as the incentive to provide code may be reduced 23. II.4.3 Open Core Licensing Example MindTouch 24 is a company that supports an open source enterprise content creation and management system called the MindTouch Technical Communications Suite (TCS). The goal of the company is to support the open source community and the TCS application while at the same time providing classic FOSS services (helpdesk support, training, documentation, etc.), the certification of resellers and consultants, and proprietary extensions (both created by MindTouch and their partners). MindTouch is again a classic example of a company that uses a mix of FOSS business models to address the needs of both their customers, partners and development community. II.4.4 How IP impacts the Business Model Success in an open core licensing model relies heavily on a company s ability to assess what software components can be used by their customers without cost and what components will be available for a fee. Some software developers charge for newly developed components and then gradually move them to the open source version. These businesses will need to have control over both the IP developed by the community version and those components developed in-house. Business Model Components Extension or Open Core Model For more on this topic please see

26 Core Capabilities A strong internal development team that can build commercially relevant extensions (like support or development tools). Excellent FOSS community management (needed to communicate how the organisation will support FOSS while at the same time earn a profit). Ability to develop the FOSS community and provide tools and resources for the developers. Infrastructure Partner Network Software vendors (official partnership agreements) and FOSS community developers. Software vendors will provide local support and customization while the FOSS community will support improving the core provided it continues to answer a specific programming need. Value Configuration Licensing of the extensions coupled with traditional FOSS services. Some companies will move proprietary features into the FOSS version after a period of time in order to keep the application relevant to the FOSS community and encourage additional adoption from FOSS only users. Offer What is the value proposition? If the core part of the application is seen to be of a high value to both users and developers, then the sale of additional features designed to enhance the usefulness or total capabilities of the platform would be of interest to customers. This, coupled with additional FOSS services, would increase the value proposition of the company in the eyes of its customers. Customer Relationship Close relationship with customers due to extensions and tools. Close support of the FOSS community supporting the open source version as some services can be offered to these customers. Customer Distribution Channel Software itself is generally available via the internet however the creation of official partner agreements with other service providers can be used as a means to build the customer base and expand services. Target Customer Target customer will depend on the type of application and its industrial domain (health care, financial services, etc.). Target customer will be one who has the financial means to pay for the additional software but not the time or technical expertise necessary to create the proprietary extension. Finance Cost Structure Developers to create, maintain and advance the proprietary extensions or tools. Developers to support the FOSS code base. FOSS community support. Marketing of customized solutions or support services to clients. Revenue Streams Revenue from licensing of extensions or tools and support service contracts. Revenue from FOSS support services and tools. 25

27 II.5 BUSINESS MODEL 4: LEVERAGING FOSS SOFTWARE TO SELL OTHER PRODUCTS OR SERVICES This last business model refers to the approach of using FOSS software to develop revenue streams not directly related to FOSS services or the software itself. In this model, the use of FOSS software complements another product or service. Clearly, the software needs fulfil some purpose for the target market and, as will be explored in the following examples, is generally commercially successful only in situations involving a large customer base. II.5.1 Why a FOSS Complementary Product or Service Model? In section II.3.1 we noted that some software consumers needed the ability to have a closed, proprietary version of a software in order to develop and sell their products. In this new model, the software is given away in order to gain the attention and adoption of as many users as possible or is developed as a means to influence industry practices so that competitors can focus on related products or services. In economics, products that are complements of each other (like cars and fuel) share a link. Changes in the cost or availability of one will impact the other. Making a popular tool or application widely available (high user adoption in a larger target market) can help promote complementary products. II.5.2 Factors Impeding the Success of the Complementary Product or Service Model A company that wishes to utilize this model must be able to commit resources to develop and support the tool or application without negatively impacting its ability to produce the complementary service or product. It is vitally important that the software provide a high degree of value so that related services can leverage all of the positive attributes generally associated with FOSS development (high quality code, scalability, little or no licensing fees, etc.). When using this approach, it is important that companies understand the relationship between how its FOSS software will impact the related services that will be offered and how adoption of the software will impact the development of the related product or service. It is also important that companies that use FOSS software in their products understand the full implications of the open source licenses that they use. Failure to respect the copyright of a software license can expose a company to legal risks. II.5.3 Complementary Product or Service Example Perhaps the first well known use of leveraging FOSS software in this way occurred with the replacement of Netscape s browser. When the Mozilla organisation began to offer its new web browser to users (as a fully open FOSS project), it immediately realized that search engine companies - like Google - would pay to have the software modified so that the Google search bar would always be part of the browser. Google pays the Mozilla corporation, a for profit subsidiary of the not for profit Mozilla Foundation, a large amount of money each year to support the company s FOSS activities. It is a win-win situation for all partners. Mozilla gets funding to pay for sustaining the open source project (in-house development, community management, governance, etc.), and Google does not have to divert resources away from its core business making money from on-line advertisements. 26

28 Software embedded in electronic products is another example of this model. Digium, a provider of PBX (private branch exchange an internal phone network) communications hardware to businesses developed and continues to support the Asterisk open source platform. Sun Microsystems, now Oracle, supported FOSS server operating systems to advance its line of server platforms against competitors like IBM. Some companies have explored what is known as Analytics based monetization 25. Value is derived from identifying what programs and efforts create web content and knowledge that leads to increased performance or knowledge transfer in organizations (companies like Socialcast). By utilizing the information derived from social computing (i.e. corporate or private) the analysis of new types of information can be realized. Companies that focus on obtaining business intelligence data see the value of utilizing FOSS if it leads to new ways of mining data. Finally, Google has recently launched a program that supports the Android FOSS mobile operating system. Google understands the market potential for smart phones and it has positioned itself to add applications and search advertising services to the mobile phone industry by providing a way for handset providers to alleviate mobile phone software development issues (reduced license fees, application developer support) from their overall manufacturing and support costs. II.5.4 How IP impacts the Business Model IP can be an import issue in the creation of a related or complementary product. Hardware suppliers have in the past had problems when the FOSS licensed code (such as Linux) distributed with a product was not available for access as defined in the FOSS license. Companies such as Sitecom 26 have had problems with this issue. TiVo, a company that provides DVR hardware and services to consumers, created a debate when it added digital signatures to the GPL version of the code in its hardware. Users could access the code online, but could not modify the software and then re-install it on their own DVR. This caused some debate in the open source community and lead to the now common term tivoization 27. Description of the Business Model Components Complementary Products or Services Core Capabilities Clear understanding of other markets and business models and how FOSS software plays a role in the model. Ability to provide a complementary service or good that would be of interest to other industries or markets. Ability to market and distribute the tool to the widest possible number of users. Infrastructure Partner Network Partners would be actors in software related industries (hardware OEMs). Partners could also be other software developers who provide related products or services (applications). Participation is interesting to partners of a technical solution can be provided on a large scale and enhances to each partner s business model (low or no cost software tool). Value Configuration Business activities include developing a software solution to reduce partner s manufacturing costs, provide access to new markets or promoting standards that increase business partner efficiencies

29 Offer What is the value proposition? Customer will utilize software solution as a means to lower costs or gain efficiencies. Software provider will leverage customer s market for promoting other goods or services. Customer Relationship Need to develop a solution that addresses as many customers as possible. Use of industry standards groups important. Close cooperation (product design, market segmentation, future product initiatives) is required. Customer Distribution Channel Distribution channel specific to relationship with customer: may be hardware, may be separate software component or platform. Target Customer Target customer is the customer of any manufacturer or service provider who requires software in their product/service. Finance Cost Structure Must be able to support the creation and maintenance of a software solution (FOSS accelerates this). Capital spent on the initiative must be won back from growth in supplier s core business. Significant capital may be required depending on the scope and scale of the final users. Revenue Streams Revenue is directly linked to the sale of complementary goods or services. II.5.5 Open Source Governance Models Controlling Open Source for Commercial Ends While the ability to control the distribution and development of software through intellectual property laws may be widely understood and accepted, a new component for the development of FOSS business models has been added that many software developers may not be aware of. A governance model is used by an organisation to establish a set of guidelines and rules by which the organisation will be run. Individuals who wish to become members of the organisation can see the policies and actors of the organisation and understand how the organisation manages itself. In open source projects, governance models not only describe who the key actors in the project are, but also concepts such as IPR policies, membership guidelines, fees, and what resources different actors will contribute to the project. Governance policies may also define strategic issues such as how often code is released and under what conditions other actors, such as original equipment manufacturers (OEMs), may interact with the project s outputs. With the launch of Google s Android operating system, designed specifically for mobile devices, Google has anticipated that hand-held devices will become the most pervasive computing device used by consumers and that their computing power - thanks to new chip and battery technologies - will only increase in the near future. Google, having learned much from its failed attempt to enter the mobile phone market with its own handset, decided to support an open source program designed to provide an agile and robust software solution that addresses problems specific to these types of devices. The program supports a community, a software developer s kit, an application market place for consumers, and provides its source code to the public under a very liberal FOSS license (Apache). From a FOSS developer community standpoint, Android is a classic open source project. The key difference for Android however, is how it interacts with OEMs. Unlike many open source programs, Google does not make new versions of the code immediately available to the public. In fact, Google has adopted a 28

30 strategy that addresses the business models of the OEMs while at the same time draws on the positive publicity of FOSS software development. Below is a list generated by Andreas Constantinou 28, mobile phone industry expert, in an article outlining the way Google uses its FOSS governance model to control how the software is used and developed: Private Branches of Code Closed Review Process Speed of Evolution Incomplete Software Gated Development Community Anti-Fragmentation Agreement Private Roadmap Android Trademark For handset manufacturers, value is gained from differentiation (ability to customize a handset for a specific market) and third party applications. Google delays the release certain branches of code to the public and makes them only available to OEMs that are part of the Android project. Changes eventually make their way to the SDK so that applications can be developed by third parties. Only Google can accept or promote changes to the code base. Modifications suggested by developers outside of Google may not be accepted. This is somewhat similar to what used to happen with MySQL but more aggressive. Apple and their closed iphone software argue that they need to control the user experience. This is Google s way of doing the same but in an open source model. As Google controls the release / development process, it can release early and often. OEMs must remain close to Google if they want to stay ahead of other competitors. Google, in turn, uses prototype handsets to test new code and plan future releases. The source code available to the public is not complete. It is missing key OEM features like radio integration, international language packs, operator packs. It also does not contain Google closed source applications like Gmail and GTalk. Google maintains tight control over access to the application marketplace for Android. Developers are free to submit a wide range of applications, but OEMs must agree to Google s terms if they want access. The OEM community has developed the Open Handset Alliance (OHA) that concerns a standard called CTS. Google launched the initiative in 2008 and members of the OHA are considered sponsors of the Android project. Google is not very open about its roadmap. If you want to see anything significant, join the OHA. If an OEM wants to use the Android name or logo, they must agree to Google s terms. After reading the above section, traditional FOSS developers would call into question Google s sincerity when it comes to open source as a social force or model for software development equality. However, through the use of industry standards, by developing a firm understanding of a specific industries business model, and by leveraging IP (copyright and trademark), Google has managed to create a global IT platform that does not abuse the type of FOSS license that it uses (Apache) and embraces selected parts of the FOSS business models listed above. With Android, developers are free to utilize the benefits granted via the software s license. However, what is released is carefully controlled to maintain a business model that is beneficial to both Google and the mobile phone industry

31 II.6 WHAT DOES THIS MEAN FOR THE TRANSFER OF R&D RESULTS? As stated in Section I.2, before beginning any software project the team or project stakeholders must rapidly begin to define what the final transfer or valorisation strategy will be for the project. It is easier to do this at the beginning of the project than it is to do it at the end. The goals of all stakeholders (internal developers, administration, potential end users) must be taken into account before a FOSS strategy is selected. If a FOSS strategy has been selected, transfer activities can begin (development of a go to market strategy ) and better planning can be achieved for future resource needs. Project managers can begin tracking copyright issues early and ensure that proper governance policies can be implemented. The developer community will have the information that it needs before committing their hard work and talent. Administrators will be able to monitor key performance indicators better and ensure that funds are not being wasted. And finally if, as the project progresses, there appears to be no valid means to transfer the work for commercial purposes, then all stakeholders will be better informed as to why the effort was not successful and make changes or modifications to their strategy. Code developed under these conditions is not lost as copyright law ensures that the copyright holder has the ability to license their work under different conditions. As long as copyright policies and procedures are followed, the institution will always have the right to leverage its software in any way it chooses via FOSS or proprietary models. 30

32 III Conclusion For a university or public R&D center, the use of FOSS software can lead to rapid advances in research and innovation. However when the time comes to evaluate the potential to transfer FOSSbased projects to the public, great care must be taken so that the full potential of the project s outputs can be successfully realized. As demonstrated above, leveraging the power of FOSS software and communities can lead to increased innovation across different industries, the promotion of technical standards, and even commercial products and services. However for most research institutions, the decision to attempt to commercialize software developed using FOSS components or via a FOSS model - can be a difficult one. Many institutions do not have the resources necessary to audit a projects code base for IP infringement, select the right type of license based on project goals and the type of development done, or begin the long and complex process of creating a FOSS community. However if a university or research center utilizes the information in this document it can greatly increase the success rate for transferring new IT technologies to the public domain or even the marketplace. What is required is a clear understanding of both the technology s value in the target market and its exclusivity (competitor s inability to easily duplicate or execute). Once this has been assessed, FOSS, either as a software production model or as a means to license what has already been developed, can then be evaluated against the goals of the research center and its stakeholders. If the FOSS model makes commercial sense, the research center will have an easier time finding a licensing partner to continue developing the product. If no transfer opportunity is available, at least the IP of the institution has been correctly managed and the potential for future transfer activities has not been lost. 31

33 This document was created with the support of the CoCoMo project (Community Collaboration Monitoring) carried out by a team of the Public Research Centre Henri Tudor in Luxembourg. 32

34