Open Sources 2.0/Open Source: Competition and Evolution/Open Source and the Commodity Urge: Disruptive Models for a Disruptive Development Process

From WikiContent

Jump to: navigation, search
Open Sources 2.0

Matthew N. Asay

Open source hastens software's natural trend toward standardization/commodification. While technologically innovative companies will always find ample customer interest, the most important innovations for the next decade of software will come from business model innovation, mostly spawned by open source license requirements. Open source builds a new intellectual property regime centered on the source of code, not source code. Protection, in other words, shifts to "owning" the code creator, rather than the product she creates. Those business models that acknowledge this and leverage it will yield better profits than those that attempt a halfway embrace (or rejection) of open source.



We are missing the point. Yes, open source imposes dramatic changes on the software industry, and yes, it is roiling the fortunes of many an established vendor. It will continue to do so, and at an increased pace. Yet despite the sometimes anguished, sometimes giddy reception that open source has provoked in the IT world, open source is not novel. It is not odd.

Open source is simply the software world's mechanism for becoming just like everything else.

All the world's a commodity—or a service to support and distribute commodities: this book that you are reading, the chair that supports you, the restaurant you will eat at tonight—everything—including, increasingly, software, thanks to open source. Open source accelerates the natural progress of software toward commodification, or standardization.

It is critical that IT vendors understand this so that they can deploy (or fight, if they so choose) open source effectively, and more intelligently choose how and where to innovate. Open source does not destroy all value in software innovation; instead, it shifts the control point from the code itself to the creator of the code. In so doing, open source software will not pillage all closed source software. As in other industries, there will continue to be plenty of room for upmarket vendors (e.g., Whole Foods in grocery retailing; Starbucks in coffee; and Nordstom in retail clothing).

That said, there is no room for middling and muddling. Open source will commodify from the bottom up while "upmarket" vendors will dominate "up the stack." Everything else will be a wasteland. Just as Safeway finds itself pummeled by Wal-Mart and Whole Foods so, too, will middle-ground IT vendors find themselves grasping at a dwindling market opportunity.

Open source offers hope, but perhaps not for the reasons normally associated with it. Much has been made about the open source revolution, and with good reason. But perhaps the best reason has little to do with development of source code, and instead has much to do with distribution, marketing, and sales. In other words, what we thought was a software development methodology may have far more importance as a business strategy that undercuts competitors while driving down costs and shifting control to buyers. In such a world, those who understand and leverage open source commodification (or escape it) will thrive—everyone else will be marginalized into economic oblivion. Commodification, the highest stage of capitalism; open source, the highest stage of software.

A Brief History of Software

Once upon a time, software did not matter—hardware did. Software was something that hardware vendors wrote to help them sell hardware. Little more. Software was important because it made hardware operate, but customers understood that they were paying for hardware, and not the software that ran on top of it. (This is still somewhat true of certain areas of the embedded software market.)

As hardware commodified, software grew in importance as a differentiator with these same customers. Not all hardware commodified at the same pace: Solaris servers, for example, handled a workload in a way that commodified hardware could not, and Sun consequently charged a premium. But the real premium increasingly gravitated up the IT stack to the applications that people ran on their hardware. Hardware was important, but only because the applications had to run on something. With the rise of Dell and other commodifiers, however, IT buyers came to care less and less about the "guts" of their computing experiences—they bought systems for the applications they could run, for the productivity they could achieve.

No single company did more to send the applications trend into hyperdrive than Microsoft. Microsoft made software easily consumable by the masses. By simplifying computing, and by doing so at a dramatically lower cost, Microsoft grew the market by competing against nonconsumption and underconsumption, inviting multitudes of average users into the hitherto closed world of computing. Microsoft's Visual Basic lowered the bar of expertise to be a proficient developer, and its Office suite created a market of home and business users who suddenly could create brochures, quality letterhead, etc. Whatever open source developers' feelings about Microsoft, they should acknowledge Microsoft as the natural parent to their own brand of commodification.

For this is what open source is doing: commodifying software. We are now at the point where mainstream software is becoming commodified by the open source community, perhaps pushing all value to the services that support hardware and software. Microsoft, in a sense, is being out-Microsofted.

In this world, customers benefit as vendors focus on solving their business problems, instead of innovating new methods to achieve customer lock-in. Much of today's IT world is composed of expensive, monolithic software "solutions" that end up creating complexity and integration problems, instead of resolving customer problems. That is, today's IT industry is a morass of conflicting standards, complex installations, tepid product interoperability, and expense—all products of the industry's Wild West "level of thinking" in its adolescent years. Increasingly, however, customers are tired of subsidizing the disarray and are turning to open source as a way to get more for less. As open source proliferates, the cost of infrastructure software will plummet, freeing up resources that the CIO can spend on resolving application requirements up the stack.

Vendors, for their part, also benefit from increased use of open source, because it removes the "IP safety blanket." Because code is open, vendors must find innovative ways to satisfy and "lock in" customers. Copyright and patent are fine, but they pit the vendor in an adversarial relationship with the customer, whereas open source control mechanisms tend to force vendors to win by intimately understanding and fixing their customers' business problems. In addition, this commodification of IT will push vendors to move up the stack (and off the stack, into services) to deliver increased customer loyalty/value. Finally, as prices for software drop to match the drop in hardware costs, more buyers will enter the market, increasing the size of the market. Everyone wins.

A New Brand of Intellectual Property Protection

To fully appreciate this trend, it is critical that we better understand the intellectual property regime powering the open source revolution. Intellectual property (IP) law has always been about control. That control benefits creators by holding off would-be competitors long enough to allow the creator to attempt to profit from her innovation. I write a piece of software; I copyright it; I sell it (assuming it is a useful piece of software and I have adequately marketed it so that people know about it). Simple. This has been the software industry's dominant model for decades, and has created a few mammoth software companies that have successfully exploited their IP to generate billions of dollars in revenues. In this model, exclusion (i.e., the ability to keep competitors or customers from copying one's code and distributing it to others) yields profits. In this model, the code itself—locked up and protected—matters most.

In the open source world, at least as defined by the GNU General Public License (GPL), IP continues to play a critical role, but it is a different kind of IP. Dubbed "copyleft," open source IP focuses on keeping code access open rather than closed. And, unlike in the world of proprietary software, the code matters less than the coder—anyone can see the code, but not everyone can replicate the coder's influence on the community to which she contributes her code. By virtue of her contribution, she builds influence in her chosen code community, and this influence translates into a new kind of IP: reputation property instead of intellectual property.

In this new world of open source, reputation property means as much as or more than traditional intellectual property. If I employ the developers on a given project, I have a measure of control over the direction that the open source project will take. But even more importantly, the more developers I employ who work on, say, the PostgreSQL database project, the more likely it is that would-be customers will trust me to be able to support it. Once a company is thought of as the default support vendor for a given project, the harder it becomes to dislodge that vendor. This jibes perfectly with other commodity businesses where brand, price, and service provide the only lock-in, a benevolent lock-in that customers choose instead of one that vendors impose.

In this way, the open source code creator exercises a form of control over her creation, and that control translates into her (and only her) ability to charge a premium for the software. As an open source creator, then, my options for deriving profit from my creation are not more limited, but they are different. Instead of a limited monopoly guarded by law, I have a monopoly guarded by common sense: buyers want to buy from the most qualified source of support. They pay to have access to the source: not the source code, but the source of the code.

This distinction is important. The importance of source code gets trumpeted so often that one would think that every IT buyer on the planet is clamoring for access to source code. They are not. Indeed, Microsoft recently conducted a survey of its customers and found that roughly 60% felt that access to source code was "critical." But when pressed on the matter, 95% said that they would never look at the source, and a whopping 99% said that they would never modify it. (If they did, chances are that such modification would violate their support agreement anyway, whether their vendor was Microsoft, Novell-SuSE, Oracle, Red Hat, etc.) In sum, customers perceive source code access to be important, but are not exactly sure why. As I will detail shortly, the "why" relates to a desire for additional choice and control, and choice and control drive down costs.

Of course, nothing in this chapter should lead one to believe that source code is irrelevant. Source matters. It matters because it lowers switching costs (i.e., the cost of swapping out one vendor's software for a competing vendor's software); because it provides buyers with more control over their IT, as it allows them to shape code to fit their particular needs; and because it provides a mechanism for keeping vendors honest, by forcing them to take responsibility for the quality of their code. In short, source code matters because it shifts control back to the buyer, which forces vendors to offer better software at lower prices. While none of these source code benefits requires the intervention of a vendor, we should not get sucked into the belief that vendors matter but little in the open source world. Instead, open source actually makes vendors more relevant to customers than ever before at dramatically lower prices.

Besides benefiting customers, this GPL licensing scheme offers vendors a way to exercise an incredible amount of control over competitors. By open sourcing my code under the GPL, I push my competitors to follow suit or to increase their R&D efforts to escape commodification. Unfortunately for them, this counterstrategy of a unilateral R&D arms race tends toward paltry results: customers will often opt for the "good enough" product when the price is dramatically lower. Yes, my closed source competitors could simply take my freely accessible source code, "fork" it, and build it into their own products, but they almost never will. Doing so compels them to open source their own software, which they will be disinclined to do. Even if they did so, however, and even if my competitor were not a stodgy old closed source vendor, but rather, an agile open source predator, it would matter little, because open source buyers invariably favor the source of the source, as it were: they trust the creator of the code to support it best.

Open Distribution, Not Source

This has huge implications for the software industry. Disruptive vendors can opt to completely open source their code, relying on reputation property to net them revenues, and further relying on their freely available alternative to competitive products to force competitors to meet them on their home turf. This is not to say that all vendors must adopt an open source strategy, but rather, that they must compete with open source's lower cost structures and superior distribution mechanisms. All must increasingly compete on open source's terms. More detail is needed on why this is so.

The Open Source Weapon

Open source enables a vendor to maximize its market penetration at minimal cost, which is the goal of every IT vendor, but particularly of emerging-growth vendors seeking to displace incumbent vendors. One of the biggest roadblocks to any company's growth is the Bureaucracy Bottleneck—the larger the buyer (and, hence, the larger the opportunity), the more layers of bureaucracy an IT buyer must fight through to try-before-they-buy. Not so with open source, which surreptitiously makes its way into enterprises via free download.

Such distribution fattens a vendor's bottom line without fattening the customer's price tag. MySQL had 10 million downloads in 2003, and by mid-2004 had more than 5 million installations. Of these would-be customers, 5,000 have returned to buy a support contract/license from MySQL, bumping the company's revenues by 100% to $10 million in 2003. The revenue growth is important, but even more so is that it achieved this growth by spending less than 10% of total revenues on sales and marketing activities. By contrast, most public software companies spend 45-50% of total revenues on sales and marketing, and companies of MySQL's size generally spend 21.8% on these activities, according to a study done by In short, open source creates a small universe of prequalified buyers who seek out the vendor, instead of the other way around, with the vendor's primary marketing costs relating to setting up an FTP server and mostly word-of-mouth-type evangelism to developers.

The savings do not stop there. Whether the open source vendor "borrows" much of its code (e.g., Novell, Specifix, Gluecode) or creates it almost entirely in-house and then open sources it (MySQL, SugarCRM, JBoss), open source delivers development-related cost savings. For the "borrowers," the cost savings are obvious: they leverage a well-developed body of code, most of it written by individuals not on their payroll. For the JBosses and MySQLs of the world, which do 85—100% of their own development work, there is still a significant QA savings from the global pool of testers who submit bug fixes and code contributions (which may or may not be used by the vendor)—cheaper to build, cheaper to sell, cheaper to buy.

Proliferating Open Source Beyond the Enterprise

Today, open source largely confines itself to infrastructure software, in part because this is where the widest computing community resides. Community-based open source projects require a sufficient body of developers with aptitude and interest in a given development problem. But as the IT industry begins to recognize the promise of emerging open source business models, community becomes less critical to the success of a project. As this happens, no area of the software stack will be exempt from open source's influence and intrusion.

Significantly, open source business models will pave the way for open source to conquer the Great Middle Class of IT: the small to medium-size enterprise (SME) market. Open source, as a disruptive methodology in the Clayton Christensen sense, will do more than simply allow startup vendors to compete against established vendors in established markets: it will help to create new markets by competing against under-consumption and nonconsumption. The Internet, and open source's unparalleled use of it, is at this trend's core.

In "Does IT Matter?" Nick Carr offers one example of how this worked in another industry: chocolate. Milton Hershey, founder of the Hershey Company, noticed a gap in the chocolate landscape, a gap the railroad could resolve. Until his observation, transportation deficiencies had forced production to stick close to consumption—there was no quick and refrigerated way to ship chocolate over long distances, creating scores of micromarkets for chocolate. With the advent of the railroad, however, Hershey conceived the idea of a national chocolate market, built it, and owned it.

Today, the Internet parallels the railroad infrastructure of Hershey's era. It offers independent software vendors (ISVs) a similar opportunity to that which Hershey had, yet the majority of ISVs are not capitalizing on it. Yes, some traditional ISVs can and do offer their products for download, but this is a makeshift attempt to leverage the Internet. Open source is an Internet phenomenon—it depends upon the Internet and extends the Internet's utility. Open source should disproportionately benefit from the Internet's distribution mechanism, provided companies understand this fact and act accordingly. As I will show shortly, tomorrow's most successful software vendors will triumph to the extent that they develop models that leverage the Internet as a distribution mechanism, and use open source licensing as the rules-based system to govern that distribution.

So, Why Not Freeware?

Let us assume that all of this is true. Open source is great because it enables upstart competitors to undercut established vendors on price while providing their customers Porsche technology at Pinto pricing. But if open source is so important because it allows me to freely distribute my product over the Internet, why is freeware not equally disruptive?[1] Stated another way, if the source code does not matter, and only distribution matters, why not just give the software away as freeware and charge users who require support? Why offer something (access to source code) that simply does not matter?

The easy way out of this apparent quandary is to allow that while open distribution matters most, open source code access is also important. But this does not get us very far. I will therefore detail the reasons that freeware cannot match open source as a distribution strategy. Most importantly, I will explain how the two matter most when they intersect, making distribution without access as hollow as access without distribution.

Don't view. Don't modify. What do you do?

As mentioned earlier, it is an indisputable fact that the vast majority of IT buyers will never view or modify source code, even if offered the ability. There are numerous reasons for this, but the most compelling one is that customers expect to pay for a solution to their problems, and not merely a tool to help them solve their problems. (More on this shortly.) No company can afford the time and human resources necessary to resolve all IT problems; therefore, they take "shortcuts" by buying software that purports to fix certain problems for them. This applies equally well to closed source software and open source software. Most IT buyers just want their software to work, they don't want to have to fiddle with it.

By opting not to view or modify source code, does an IT buyer thereby opt out of any and all of the benefits of access to the source code? Absolutely not. Just because customers do not choose to exercise their rights to view and modify source code does not mean they do not benefit from the right, even when not exercised. On one level, the option to view the source code serves as a surrogate for the actual exercise of this ability. As an example, because I can review the database code that Sleepycat delivers to me, it forces Sleepycat to provide a higher-quality product than closed source vendors would have to offer.

R0ml Lefkowitz of AT&T Wireless gives a tangible example of how this works. In June 2003, R0ml related that he had asked his wife to solicit multiple contractors' bids for a home improvement project. Instead of gathering several bids, however, R0ml's wife procured only one bid. When he asked her why, she responded that she figured the contractor would assume she had collected a number of bids, and so would give her his best bid from the start. The option to exercise choice, then, served her as a useful surrogate for actual choice.

In this way, access to source code motivates the code's vendor to provide a superior product, knowing that it will be open for all to see. It also functions as a security blanket for customers. Hopefully, they will never have to look at the source code. But if Vendor X fails to deliver on its promises, or if it goes out of business, that customer will have the option (unpleasant though it might be) to have some other services firm support the stranded code. Source code access lets buyers rely on their vendors...but not too much. Importantly, the more independent the buyer is from the vendor, the lower the vendor's prices must be. More on this shortly.

As IT buyers have grown comfortable with open source projects, another benefit has emerged. Initially, it is true that buyers will tend to want to avoid tampering with the software they buy. Over time, however, as they grow familiar with a product (closed or open), the buyer's developers will want to make tweaks here or there. They begin to support themselves, in other words, because calling out for support takes unnecessary time (and patience). In a closed source world, however, their ability to tweak the "solutions" they buy is limited. In an open source world, the Amazons of the world have free reign over their IT. Source code access gives customers the ability to experiment with and tailor software to their liking, if they choose, and on their own time table.

Other reasons have been suggested. Developers like to be creative. Like anyone else, they prefer not to have self-expression manacled, and they choose to express themselves in the code they write and modify. On a mailing list in June 2003, Frank Hecker argued that access to source code is critical for developers at the heart of a company's IT infrastructure. Such people want to be able to modify code, and so must have access to source, because they will need to be able to fix any problems they may download into the company. Outside the corporate firewall, Ben Tilly (on the same email list) stipulated that while the majority of developers are not involved in open source, access to source code is critical to that core of developers who do participate. They are the lifeblood of open source communities and are the ones who will openly extend assistance to newbies who just want the code to work without getting their hands dirty.

All of which is a verbose way of repeating the earlier point: source matters, even where it may not directly matter to the end user. Access to source extends benefits to users beyond those chosen few who actually exercise the right to touch source code. Source matters because choice matters. Choice matters for a number of reasons, not the least of which is that choice drives down prices. And choice is amplified by open source, not by freeware, which has its source code closed.

Open source. Open choice. Open wallet.

Many successful software vendors would have us believe otherwise. That is, they want to sell suites of services that take care of all needs, that reduce complexity, and that reduce choice. The primary perpetrator of this strategy is Microsoft, which, as Dana Gardner of Yankee Group notes, wants to "make the end user any offer they can't refuse—to go Windows everywhere" ( One major problem with buying into these monolithic visions is that once in, the switching costs to go with another vendor are prohibitive.

By buying into Microsoft or any other vendor that holds out greatly reduced choice as a way to accomplish moderately reduced complexity, a buyer surrenders his IT destiny to that vendor. He upgrades when the vendor wants him to. It gets new technology when the vendor chooses to innovate. (I would argue, and have on several occasions, that Microsoft's market dominance has caused it to stagnate in terms of innovation. When was the last time Microsoft's Office product significantly improved over the last version? And yet the buyer keeps buying, because he finds himself on the Microsoft treadmill.) And he pays whatever the vendor demands, because the he has no other options. He is a prisoner of the vendor's universe, however expansive the vendor pretends that universe to be.

Over time, buyers who condemn themselves to such vendor-controlled realities will pay more for their IT, both in hard costs and in opportunity costs. Open source offers the opposite vision: maximum freedom to shift among vendors (even while staying with the same or similar code base). Open source therefore costs less in the short term and, especially, in the long term.

If we step outside the IT world for a moment, this point will become even clearer. My wife and I recently redid our landscaping, including our cement work. Or, rather, we wisely chose to hire out the work. True, with a Dummy's Guide to Cement (my "source code," as it were), even I might have been able to figure it out and could have completed the project satisfactorily. Had I opted to do the work myself, the cost would have been X. Because I could have done the work myself for X, my cement contractor was only able to charge me 1.5X. Had he bid higher, I would have had strong incentive to perform the work myself. I had access to the source, so his pricing power was curtailed. (In the same way, access to a closed binary, as with freeware, does not accomplish this same effect of driving costs down.)

The cement contractor ended up performing shoddy work and walked off with a portion of our money, for which he had not completed the associated work. Measuring it out, it will cost us 5-10X to hire a lawyer to compel our cement contractor to satisfactorily complete his 1.5X worth of work. I happen to be a lawyer, but not one that has ever actually practiced law, so I am stuck paying the lawyer's fees: $500/hour to recover $1,500+ in payments owed to me by the contractor.

Perverse world, you say? Yes, I suppose so, but the point is that the delta between the cost of me doing my own cement work and the cost of me doing my own legal work is directly proportionate to the skill set involved and the artificial licenses set up by the legal profession to keep would-be attorneys in "would-be land." I am effectively barred from accessing the "source code" of the legal (and medical, among others) profession, which drives up the price that I must pay.

Again, access to source code, whether in software or cement, offers choice, and choice ensures lower prices. It does not matter that most people will never choose to do their own cement work, just as it does not matter that most IT buyers will never choose to view and modify source code. The important thing is that they could if they were so inclined. That "could" is instrumental in dropping prices through the floor.

Such lower prices, then, allow the CIO to spend more money on developers who can further customize software to meet that specific organization's requirements. Imagine that: IT that works for a customer, rather than against it. That is innovative.

Such innovation is what open source is all about, and is why it continues to make inroads in the enterprise, in embedded devices, and everywhere else. Open source brings choice, and choice saves money. Freeware does not engender such choice. Meaningful choice is not created by cost-free technology; rather, choice is created by the freedom to manipulate code to one's personal (or corporate) advantage, or to have it widely distributed in such a way that one can benefit from others' exercise of that freedom. Access matters little without distribution, and distribution matters little without access. Together, they spell the commencement of a new age of software innovation, innovation that benefits vendors' and buyers' bottom lines.

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 snobbery—it 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 coffee—why 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 ( 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 profitable—everyone 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.

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.

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 projects—e.g., JBoss—are 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.

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.

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

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.

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

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.


Open source propels software toward Commodity Land, a happy place where customers pay for real value and vendors compete on that value, not intellectual property lock-in. Each of the open source business models detailed in this chapter will help to further this trend, making open source mainstream and possibly displacing the traditional, IP-based model as the default.

We are thus on the cusp of a Kuhnian paradigm shift, one that will fundamentally alter the way IT vendors create, sell, and distribute software. Once apparently stymied by the restrictions that open source licensing places on traditional business practices by IT vendors, open source vendors are now finding that open source licensing creates as many opportunities as it closes, changing the nature of software competition for decades to come. This means that incumbent and emerging IT vendors must understand the new rules of engagement to compete effectively. Whether they like to admit it or not, open source will force every software vendor to come to grips with omnipresent, ravenous commodification.

Some may opt for technical innovation over business model innovation, with varying degrees of success. However, such innovators should recognize that while copyright and patent provide potent protections, they also put the vendor in an adversarial relationship with the customer. As such, these traditional intellectual property tools hurt customers as much as (or more than) they do competitors, and will put them at a disadvantage against open source competitors who offer customers choice and value at lower prices. Open source, then, allows vendors to lay waste to their competitors' profit margins by lowering their own costs of distribution, sales, marketing, and development, while simultaneously blessing their customers with increased IT flexibility and a more finely tailored approach to solving their business problems.

Open source, then, offers a new way to innovate, a new way to compete, and a new way to win.


  1. Larry Augustin originally needled me with this question, for which I thank him.
Personal tools