Section 7.5. Open Source Business Models

7.5. Open Source Business Models

All of this may sound plausible enough, but we now need to trace through some real-world business models that vendors use or could use to leverage the benefits of open source to drive revenues and boost profits. Before doing so, it is important to note that an "open source business model" means more than simply supporting Linux as an operating system. In other words, the fact that my CRM system runs on Linux, or that my hardware appliance has Linux as its core, does not make me an open source company. An open source business model means that a vendor somehow engages with the open source community.

With that said, I also need to stress that whatever the importance of open source, not all companies must adopt open source to find success. Open source is the great commodifier, but there will always be those who successfully evade that commodification. Other industries prove instructive on this point.

Take retail, for example. Even as low-cost commodifiers devour middle ground in this market, profits persist up the stack. Wal-Mart is the 8,000-pound gorilla of commodification, cannibalizing groceries, clothing, and just about everything else on which it puts its hands. Still, for all of Wal-Mart's success in low-end fashion, for example, Nordstrom continues to win at the higher-end game. This is more than a case of customer snobberyit has to do with an experience that Nordstrom delivers (superior customer service) that Wal-Mart is structurally incapable of offering. (This same phenomenon exists in coffeewhy are consumers so willing to shell out $4 for a cup of coffee? Because Starbucks has defined a customer experience that transcends Maxwell House at home.)

Another example is the groceries market, as Charles Fishman highlights in the July 2004 issue of Fast Company (http://www.fastcompany.com/magazine/84/wholefoods.html). In just a few short years, Wal-Mart has become the United States' largest grocery chain, yet the title of "Most Profitable Grocery Chain" and "Fastest Growing Grocery Chain" eludes Wal-Mart (and its European competitor, Aldi). No, those titles go to Whole Foods, with remarkable year-over-year growth in the face of a nationwide 2.5% annual compound growth rate: 17% (2003), 21% (2002), 21% (2001), 23% (2000), and 14% (1999). Whole Foods delivers an upscale grocery experience, offering organic foods and superb quality, and Wal-Mart stocks its shelves according to its modus operandi: decent selection at rock-bottom prices. Both chains have found their respective strategies to be highly profitableeveryone else has gobbled their dust. Whole Foods has registered $188 million in profits over the last several years, and Food Lion cleared only $150 million with seven times as many stores and five times Whole Foods' revenues. Safeway, for its part, lost $1 billion in the same period on even greater revenues. The takeaway? There is no room in the middle for undifferentiated players. One either commodifies or evades commodification through innovation. Everyone else languishes.

7.5.1. Both Source (a.k.a. Mixed Source) Model

So, the first business model is for the technical innovator that refuses to join open source commodification at all. But what about those companies that opt for a "both source" model, whereby they offer both open source and proprietary software? This model has promise and peril, requiring the vendor to walk a fine line between the model's divergent business requirements (low-end commodification/standardization coupled with high-end specialization). To the extent that a company marries the two, it must do so with a clear understanding of open source complements and substitutes to its proprietary product portfolio.

Both source offers a way to fill in the gaps left by open source, and to charge a premium for this "service," while still delivering open source software. Such a model seems to be ideal for established players that cannot abandon existing customers of closed source products, and blanch at the thought of losing existing profit margins. Of course, whether a vendor can avert the open source "threat" depends upon whether open source has created a viable substitute to its product. If so, head-on competition with that open source project is likely futile unless it can move significantly upward in the feature set. Even if it can, competing against free and "good enough" is exceptionally difficult.

A both source strategy makes more sense where the vendor can define and contribute to open source complements. In economic terms, a complement is something that completes a whole; in software terms, it is a component of a software solution. So, just as French fries may be considered a complement to a hamburger, so, too, is Apache a complement to IBM's WebSphere product. Importantly, the more complements that exist for a given product, the more desirable that product becomes for customers, so vendors want as many low-cost, high-quality complements to their products as possible. Oracle likes Linux and x86 hardware because it drives down the total cost of a customer's database solution...without lowering the cost of Oracle's software. Customers, thus, can buy more Oracle software, which gives Larry Ellison more time on his boat.

So far, this sounds like a reasonable defensive strategy for vendors that want to toe-dip into the open source community without getting very wet. But both source also allows vendors to take a scorched-earth agenda against their competitors, by skillfully choosing to build open source complements to their proprietary software, complements which cut directly at those areas that competitors have chosen to retain as proprietary. Of course, such a strategy must bear in mind the distinct possibility that the opposing vendor will then choose to open source pieces of its portfolio that injure the first vendor, creating a lot more open source software, but not necessarily any profits for either company.

Still, it is an open question whether this is a solid strategy against upstart competitors with lower costs who can undercut a proprietary product's margins. In addition, a both source strategy works best for vendors with products that have respectable market share. Slapping open source on or around an also-ran product will not sell it. Good technology, good service, and good sales/marketing sell products. Open source, by itself, is as much a losing strategy as closed source, by itself.

Open source complements to a market leader's products make that proprietary product more valuable by lowering the total cost of the product. Hence, while both source may be the easiest step for a closed source company to make, it will help the vendor only if its products were already competing well against other proprietary products. Again, both source offers no panacea for market losers. The lesson? Companies should adopt the both source strategy when they are on top of their games, instead of when they are losing the final sets of their matches. For market losers, a better bet is to make the difficult transition into a pure-play open source vendor, as defined shortly.

7.5.2. Professional Open Source (a.k.a. Services) Model

The dirty little secret of open source is that the term open source community is something of a misnomer. In general, the actual number of contributors to any given project, including the Linux kernel, is tiny. Thus, to "own" an open source project requires little outlay of human resources in terms of numbers, though it may require a significant amount of time to build reputation capital within a given open source community. (Newbies to the Linux kernel, for example, should expect to put in two years or more before they can hope to attain "committer" status in the kernel hierarchy.) Despite the low number of developers required to corner the market on an open source project, the importance of doing so is massive: employing a majority of the developers on a given project roughly equates to intellectual property ownership, as explained earlier.

For this reason, companies that spawn open source projectse.g., JBossare able to completely open source their code without abandoning pricing power. JBoss, for its part, employs roughly 85% of the developers who contribute to the JBoss open source project. JBoss offers its code under the Lesser General Public License (LGPL), which allows users a wide range of action vis-à-vis their code, including the right to fork the JBoss project and start JBoss II.

But no one does that, for reasons already detailed.

Because of the heavy JBoss "ownership" of the committers to the project, the company does not save a great deal of money on development costs. It functions much like any closed source company, except that its development is open for public view and consumption. Any appreciable development savings derive from the bug finds/fixes that JBoss receives from its development community.

Still, the professional open source business model is not really about development savings. Rather, it is about maximizing distribution of one's product; getting it beyond the purchasing firewall/bureaucracy bottleneck to plant the product in the hands of its developer end users so that they can try and then revisit the professional open source vendor for support/service contracts. To get approval to use BEA's Weblogic or IBM's WebSphere, a developer would need to go through a cumbersome process. To use JBoss, she simply needs to click "Click here to download." And while the developer might choose to support herself through newsgroups or other online fora, in production situations she will generally turn to the source of the code (in this case, JBoss). This is the classic open source model, though it is only now starting to be exploited effectively.

7.5.3. Dual-License Model

The dual-license model has been popularized by MySQL, but has been around for some time, most notably deployed by Sleepycat and Trolltech. In the case of a dual-license vendor, that vendor employs not most, but all, of the developers who contribute to the code. Because it employs all of the developers, it also owns all of the copyrights to its work. Then, as the owner of the copyrights, it is entitled to license its software under one or more different licenses.

However, the fact that it owns the copyrights and employs the developers begs the question as to what benefit, if any, it derives from its open source status. The answer, as with the professional open source model, lies in distribution strategy. For a dual-license vendor, open source is less a matter of development and more a matter of distribution for open source vendors. Yes, the dual-license vendor derives benefit from outside developers who contribute code (though MySQL, for example, tends to repurpose/rewrite incoming code to help it better fit its existing code base) and bug fixes, but its primary benefit is in the ability to broadcast its product to the world with customers benefiting from lower prices and less lock-in.

Also interesting, though not a benefit touted by the primary adopters of the dual-license model (MySQL, Sleepycat, Trolltech, and now SugarCRM), is the fact that the dual-license strategy provides the customers with a mechanism to buy their way out of the GPL, if consider this desirable. This is of particular benefit in the embedded world where, for example, Linksys might receive GPL'd code from Broadcom and might want a closed source license to that code, so that it will not have to open source the software running its routers and access points (a purely hypothetical example, of course...). db4objects is promoting its embedded database with precisely this message, one that customers appreciate because however much a vendor may prefer the GPL or another open source license, the fact remains that it may not always be the best fit for a given customer. As such, the dual-license model offers customers a way to pay for the right to choose the license under which to receive software.

7.5.4. ASP Model

Such are the prominent open source models that are easily recognized as such: open source business models deployed by open source companies. But, as Tim O'Reilly has been telling the industry for years, "open source" is a much bigger tent than we may recognize. Tim includes such "infoware" vendors as Google and Amazon in his open source tent. The common denominator between the two? Internet infrastructure powered by open source (Linux and a great deal else), plus an architecture that promotes participation that makes the infoware increasingly valuable.

The enterprise IT industry has also been moving toward a related model for standard enterprise applications, calling it utility computing, on-demand computing, and a range of other names. In this model, IT vendors deliver computing power in a utility fashion: Enterprise Consumer X gets the computing cycles when it needs them, instead of buying all of the hardware/software upfront.

Importantly, customers in this model buy IT (including software) as a service, rather than as a standalone product. As such, customers do not really buy software at all they buy solutions to their business problems. Whether the "guts" of that solution are open or closed source does not matter anymore. Customers simply pay for value, delivered as a service: SP (service property) rather than IP (intellectual property).

This sounds much like software's ASP model, in which software is delivered to the customer over the Internet, hosted on a central server by the vendor, with customers paying for the value they access over the network. A prominent example is Salesforce.com. Whether the software underpinning the service is closed or open source becomes irrelevant. The requirement to release modifications to a given open source project is triggered by distribution: so long as the code itself is not actually distributed (and only the resultant service dictated by the code is), open sourcing of modifications is not required, but voluntary.

7.5.5. Other Models

The aforementioned business models are the primary models in use today by most open source companies. However, some of the most interesting new companies employ equally interesting (and innovative) business models, generally altering the way open source software is supported. For such companies, the real customer benefit of open source is the availability of source code. But, as noted, major vendors such as Novell and Red Hat, which tie their support contracts to specific product builds, obviate this benefit. Gluecode and Specifix resolve this irony and may point to tomorrow's most successful open source business models.

7.5.5.1. Managed source model

Gluecode incorporates three levels of source code support into its model. First, Gluecode conglomerates various Apache packages, tests them, and generally makes them play nicely together so that customers need not worry about visiting Apache.com for themselves. Second, Gluecode develops its own proprietary software to extend Apache's reach and thereby provide a compelling solution for portals/business process management (BPM). Third, and unique to Gluecode, the company offers source-level support to its customers, allowing them to check in their code to Gluecode's CVS repository. Gluecode runs the customer's code against test suites to ensure the customer's modifications or additions work properly with Gluecode's open+closed codebase, enabling the customer to become something more: a development partner.

7.5.5.2. Code-level service model

Specifix does something similar. Focusing on embedded and server deployments of Linux, Specifix allows its customers to modify Specifix's Linux distribution to meet their particular requirements. Instead of invalidating their support agreement with Specifix by doing so, Specifix tracks exactly where the modifications were made and allows the customer to support its own modifications, while continuing to support the original Specifix distribution. The customer may, in other words, opt for the "road less traveled," but Specifix is happy to maintain the more-trafficked road for them, keeping it parallel with the customer's chosen divergence.