GUIDE TO OPEN SOURCE BUSINESS MODELS

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

1 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

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.

3 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 ... 11

II.1.4 Additional Evaluation Parameters – Market & Product ... 12

II.2 Business Model 1: Support Services for FOSS Software Platforms ... 14

II.2.1 Business Value of FOSS Software vs. Traditional Software ... 14

II.2.2 FOSS Software Becomes a Commodity – But Not Exactly ... 14

II.2.3 FOSS Services. How Do They Work? ... 15

II.2.4 What are the Factors for Growth for FOSS Related Services? ... 16

II.2.5 Factors Impeding the Success of the Service Business Model ... 17

II.2.6 Support Services Example ... 17

II.2.7 How IP Impacts the Business Model ... 18

II.3 Business Model 2: Dual Licensing Strategies ... 19

II.3.1 Why a Dual Licensing Strategy? ... 20

II.3.2 Factors Impeding the Success of the Dual Licensing Business Model ... 21

II.3.3 Dual Licensing Example ... 22

II.3.4 How IP impacts the Business Model ... 22

II.4 Business Model 3: Proprietary Extensions or the “Open Core” Licensing Model ... 23

II.4.1 Why an Open Core Licensing Strategy? ... 24

II.4.2 Factors Impeding the Success of the Open Core Business Model ... 24

II.4.3 Open Core Licensing Example ... 24

II.4.4 How IP impacts the Business Model ... 24

II.5 Business Model 4: Leveraging FOSS Software to Sell Other Products or Services ... 26

II.5.1 Why a FOSS Complementary Product or Service Model? ... 26

II.5.2 Factors Impeding the Success of the Complementary Product or Service Model ... 26

II.5.3 Complementary Product or Service Example ... 26

II.5.4 How IP impacts the Business Model ... 27

II.5.5 Open Source Governance Models – Controlling Open Source for Commercial Ends ... 28

II.6 What Does This Mean for the Transfer of R&D Results? ... 30

4

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

W

FOSS

.

D

’

?

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 http://www.gnu.org/philosophy/free-sw.html 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 http://www.opensource.org/docs/osd 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

5 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

I

FOSS

I

D

B

M

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

C

P

.

I

R

D

P

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

6 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

F

A

B

W

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 dbm2 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

7 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.

8

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

(V

)

S

D

W

B

M

I

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 Model4

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 Components5

3

From http://stephesblog.blogs.com/presentations/MySQL_OSBC_200705_handout.pdf

4

Alex Osterwalder 2006, from Slideshare.com slide 2, at http://business-model-design.blogspot.com/2006/11/business-model-template-designing-your.html. Creative Commons Attribution-ShareAlike 2.5 License

9

Infrastructure

Core Capabilities

Resources and skills necessary to participate in the business model

Partner Network

Who are the key partners and why do they participate in the model?

Value Configuration

What are the primary business activities that will be executed in the model?

Offer What is the value proposition?

What exchange will take place between the customer and the provider of goods or services?

Customer

Customer Relationship What relationships exist with the clients? Distribution Channel

What are the primary communication and distribution avenues by which the customers receive the goods or service? Target Customer

Who are my target customers and in what market segment do they belong?

Finance

Cost Structure

What are my principal costs for this business model? What capital is needed to keep the business in operation? Revenue Streams 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

5

2005, Osterwalder, Alex, Business Model Design and Innovation Blog, http://business-model-design.blogspot.com/2005/11/what-is-business-model.html, Reviewed 7/2009

6

10 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 Williams7 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: How FOSS fits this model 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.

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.

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)

Same, but FOSS development should lower security and bug issues due to the distributed development / QC functions inherent to FOSS development model.

Added dimension of not being able to even measure contingent costs accurately:

 Fear replaces numbers as decision making criterion – “safe buy” perception.

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.

7

2007, 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

11 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

12 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 Configuration8

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

8

2008, Software Industry Model Map - Version 1.0, J. LeBlanc, Creative Commons License, http://www.designvsdevelop.com/a-map-of-business-models-in-the-software-industry/

9

13 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 problem10.

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 face11:

 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”, 1991-2002, HarperCollins

11

14

II.2

B

M

1:

S

S

FOSS

S

P

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 maintenance12. 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 risk13. 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 material14. 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),

12

2003, Facts and Fallacies of Software Engineering (Agile Software Development), Glass, Addison-Wesley, Page 115

13

2004, The Costs and Risks of Open Source, Giera, Forrester Research, Inc.

14

2008, Open Source: Software as a commodity, McCreesh, http://www.mealldubh.org/wp-content/uploads/2008/06/temp.pdf

15 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 Williams15 explains the difference more clearly:

Generic Commodity Marketplace Behaviour

Enterprise Software Marketplace Behaviour

Open Source Software Marketplace Behaviour

No switching costs to buy from different producer.

Customers loyal to incumbent vendors. Customers loyal to incumbent

distribution vendors.

Market prices are a function of changes in supply and demand.

Software supply is infinite (zero duplication costs).

Software supply is always infinite (zero duplication costs).

Producers can’t affect demand, only supply.

• 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.

• Producers create entire markets. • Producers drive their own demand by differentiating their products from competition (maybe in slightly

different ways)

Pricing moves quickly to find a point of supply/demand equilibrium.

How often do software companies update their price books? Not often.

How often do open source software companies update their price books? Not often.

“Excess” profits quickly disappear and producer profits revert to the mean of the economy as a whole.

• 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.

• 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.

Lowest-cost producer wins in a commodity marketplace, because he can sustain “excess” profits longer than all other producers.

• Microsoft spends 25% of revenue on R&D. They are not the lowest-cost producer.

• Everybody is making “excess” profits in the software industry.

• 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

15

2007, 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

16 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 X X Personal certification / Training courses X X

FOSS community support

X X

Interoperability testing

X Software certification /

Warranties X X

Patches / Special releases

(security) X X

Consulting / Custom

engineering 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

17 community uses Microsoft Windows while only 0.7% use some form of Linux16desktop 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

 Increase the number of services offerings for a specific software platform (gain reputation as leading platform expert)

 Build strong brand awareness among customers

 Develop highly specialized “niche” services based on price sensitivity or engineering competencies

 Or, extend the number of FOSS platforms that your services support (gain reputation as FOSS expert)

 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

16

18 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

 Certification of software builds or hardware compatibility

 Integration of complementary FOSS software platforms

 Consulting & Engineering Services

 Training/ Personal Certification Services

 Community Support

 Enterprise server and desktop versions

 Certification of software builds or hardware compatibility

 Integration of complementary FOSS software platforms

 Consulting & Engineering Services

 Training/ Personal Certification Services

 Community Support

 Enterprise server and desktop versions

 Certification of software builds or hardware compatibility

 Consulting & Engineering Services

 Training/Personal Certification Services

 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 lower17.

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.

17

2005, Red Hat, Novell Face Pressure as Open-Source Doubts Mount, Reiter, Chris, Dow Jones News Wires, HTTP://msforums.ph/forums/t/24983.aspx

19

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

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)

Distribution Channel Internet, Publications and Conferences

Target Customer

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

FOSS community support costs, Marketing and Communications costs, IT Infrastructure (servers, in house developers, documentation).

Revenue Streams

Revenue can come from consulting, client-specific engineering or support, help desk support,

documentation, software warranties, software bundling and automatic updates

II.3

B

M

2:

D

L

S

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

20 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-copyleft18 (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.

21 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 alternatives19.

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”, http://www.sun.com/third-party/global/eds/collateral/sabre.pdf (40% TOC ownership reduction for Sabre)

22 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 accepted20.

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

23

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

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.

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

B

M

3:

P

E

“O

C

”

L

M

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.

24 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 no-cost, 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 obtain21, 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.

I