Section 5.5. Practical Considerations

5.5. Practical Considerations

Dual licensing works. Using it, businesses can generate revenue based on license fees paid for copies of software. Because the public markets view this revenue as inherently lower margin than services revenue, dual-licensing companies have attractive valuations and can raise capital at parity with proprietary software vendors.

5.5.1. Attractive Margins

Every sustainable business must consistently earn more money than it spends. This is often hard.

One of the key considerations in designing a new business is the margin that the revenue stream can produce. Margin is, at base, the percentage of revenue that is profit. If you pay $100 to build a widget, and you pay a salesperson $100 to sell it, the widget costs you $200. If you charge $400 for it, you have an attractive margin50%. If you charge $205 for it, you have a very thin margin2.5%.

Most technology businesses sell licenses, or services, or a mixture of the two. For example, a company might license its product to customers, and might also sell consulting services to help customers integrate the product into existing IT infrastructures.

Licensing businesses generally have attractive margins. This is because, while it may cost $1 million in payroll to produce a new software program, the second copy of that program is essentially free. Having sunk the cost into building the product, the company can sell as many copies as it likes without paying the developers to start all over again. As a result, selling a new copy of an existing product really just requires paying the sales team that sells it.

Services businesses, by contrast, have much slimmer margins. This is because, to deliver the service, the business must have the people on the payroll who can do the work that is inherent in the services contract. Selling more consulting engagements requires that you hire more consultants. Thus, the costs that a services business incurs on every contract include not just the cost of selling it, but also the cost of fulfilling it.

Of course, very few companies are purely licensing businesses. Most provide at least customer support. However, building attractive margins is easier in a business with a significant licensing component.

Dual-licensing businesses offer two different revenue streams. Proprietary customers pay licensing fees, giving the business a high-margin licensing revenue stream. Both proprietary and open source users may choose to buy consulting or technical support, giving the business a lower-margin services revenue stream. This diversity in the revenue streams can allow the company to weather temporary slowdowns in either its licensing or its services businesses.

5.5.2. Capital

Over the past several years, the success of open source business models, and of dual- licensing models in particular, has caught the attention of the investment community. As investors have learned more about open source and dual licensing, they have begun to make investmentssometimes substantial investmentsin new businesses. In addition, established companies have begun to look at open source as a strategic business advantage, and not just as a low-cost way to bring technology in- house. Major technology vendors have demonstrated their willingness to acquire open source businesses at prices that reward the principals and original investors in those businesses.

Venture capitalists and other sources of early-stage funding for companies look for a few key attributes in open source businesses.

First, of course, the company must have a credible, defensible business model. It is, generally, easier to raise money for a company that uses dual licensing, than for one planning to make money exclusively from services. The big risk for a new services business is that it will demonstrate the viability of a new services opportunity, and thus attract the attention of a large established services player. Popular open source packages have enormous installed bases. Businesses exist today that earn tens of millions of dollars supporting and training those users. That is enough money to interest even a large, established company.

The real problem with providing only services for an open source package is that the strategy is hard to defend against competitors. While it is true that the original authors of an open source package have an advantage in supporting itafter all, they know the most about how it worksfreely available source code permits anyone else to learn the product internals and offer the same service.

Investors and acquirers are generally willing to pay less for a pure services business than for a licensing business, or for a business that combines the two sources of revenues. After all, costs grow in proportion to revenue growth. Every services sale requires staffing to meet the service commitment. Selling licenses for software, on the other hand, is much cheaper; making another copy of an existing product is free.

Second, investors look for open source packages with a solid market presence. The investor typically wants to see a track record of successful deployment to prove that a market exists. Thus, it is very hard to raise money to build a brand-new open source package from the ground up. Indeed, virtually all of the open source businesses funded in the past decade have tried to commercialize on the value of existing open source packages.

This creates a chicken-and-egg problem. The open source package must exist before it can be funded. Somehow, though, the package must get written in the first place. Generally, the open source packages that serve as the foundation for successful businesses were labors of love in the beginning, created by developers working in their spare time for free. Only when they succeeded in building a credible product could they raise money.

Third, and significantly, investors always look at the team in which they are asked to invest. As a rule, no investor will back an unbalanced organizationall engineering, or all marketing, for example. A fundable open source business must combine the technical expertise of a solid group of engineers with experienced management. In particular, the company must be properly staffed to market and sell the licenses or services that the business will offer. This point may seem obvious, but in practice, it is very hard to put together a solid team with the ability to make and execute a business plan that demands both solid product development and execution against a financial plan.

Once an open source business is successful in the market, it can choose to go in a number of directions.

If the business is generating profits, the owners may choose to continue to run it as a privately held company, earning a return on their effort and investment in the form of dividends. As a rule, venture-backed businesses do not have this option. The venture capital community wants to liquidate its investment at a profit within a few years of making the initial investment, and will press management to sell the company at some point. Absent that pressure, however, a strong, profitable, and growing business is a wonderful thing to own.

More commonly, small businesses are acquired by larger businesses, and folded into the bigger company. This rewards the original investors, as well as the principals who started the company and helped to make it successful. The acquisition will most often pay off in cash, stock in the bigger company, or a mixture of the two.

Established companies are willing to buy open source businesses for a variety of reasons. For example, open source technology is often ubiquitous in the market, and controlling that technology can give the big company important advantages over its competitors. In addition, an open source platform can create opportunities to build new proprietary product offerings that run on top of the open source, which creates new service and licensing revenue. The open source business's revenue may, on its own, be enough to capture the attention of the larger company.

The reasons that any particular acquirer chooses to buy any other business depend deeply on the peculiar circumstances of each, so there is no cookbook for building a company to sell. In general, though, a solid customer base, a track record of consistent growth, and a profitable revenue stream are good things.

The last way that small, privately held businesses transform themselves is to offer their stock for sale on the public markets. This is a much less common practice in today than it was six years earlier; a business must, in general, have very high revenues to make this transition. In addition, the demands on the management team in a publicly traded company are very different from, and in many ways more onerous than, the demands on a private company's team. The requirements for reporting financial information to the public markets and the need to manage the public investment community's expectations dramatically change the way that a company president works. As a result, many companies are forced to change their executive teams before offering themselves for sale on the public market.

5.5.3. Choosing Licenses

One of the most important decisions in a dual-licensing business is what the terms will be for both the proprietary and the open source license. This issue is much bigger for the open source license, because that license is never negotiated. People simply download the software and accept the terms. As a result, a mistake in the open source terms is a mistake every single time the software is distributed.

Academic licenses are poorly suited to dual-licensing businesses, but reciprocal licenses generally work well. An academic license simply requires acknowledgment of the owner. Most rational businesspeople would much rather make that acknowledgment than hand over precious capital for use of software. A reciprocal license, by contrast, requires that the customer's own intellectual property be given away under an open source license. There is a very large population of potential customers who are more interested in protecting their intellectual property than in saving money.

As a result, the only kind of open source license that makes sense for a dual-licensing business is a very strong reciprocal license. The best example, of course, is the GNU GPL. Choosing the GPL gives you the benefit of the work already done by the Free Software Foundation, or FSF, in drafting the license and defining the key terms. In addition, the FSF has a strong vested interest in demonstrating the enforceability of the GPL, so, in the event of a dispute over unauthorized use of your dual-licensed product, you have access to a seasoned legal team that knows the subject well

It is almost certainly a mistake to try to draft your own open source license for a dual-licensing business. Doing so requires that you understand and apply the fundamental concepts of open source development and distribution in a new legal license. This is work you do not need to do if you choose an existing license. More importantly, writing a new license from scratch creates the opportunity to make bad mistakes. Finally, drafting a new license will require you to educate the open source and proprietary software business communities about the terms of your own license. This will create friction and inhibit adoption. You want developers concentrating on your software, not on your license.

5.5.4. Need and Pain

The interplay between the software product and its open source license is probably the single most important business issue for dual-licensing companies. The software product must create need in the market. Ideally, it will be so attractive to customers that they simply have to use it. At the same time, the open source license must cause enough pain that some users would rather pay money than endure the pain.

My company makes a product called Berkeley DB. It is an established product with a good reputation, but the only way for our customers to use it is to combine it with software they write themselves. That act of combination gives us leverage, because the resulting work is derived from our software, and we thus can dictate the terms under which the derivation must be licensed.

Our open source license requires that the entire work be released in open source form. Open source users, of course, can do this, but the requirement is poisonous to most proprietary vendors. Our dual-licensing strategy lets the proprietary customers pay for a proprietary license and keep their own intellectual property secret.

Linux is, once again, a good example of a product for which dual licensing would not work. Ignoring the ownership issues raised earlier, no customer needs to create and redistribute derivative versions of Linux. Customers simply want to install and use the operating system on their computers. None of those actions is forbidden by the GPL, so there is no pain.

Of course there are businesses making money distributing Linux, but they are doing so in different ways. Dual licensing works with only certain sorts of software, with very specific ownership characteristics.

Any vendor considering dual licensing must consider both technology and licensing when designing a business model. The software technology must be constructed so that users need to do something specificfor example, combine it with their own intellectual property and distribute the combined work to othersto use it. The open source license must make this activity painful to at least some customers with money. These customers must be willing to pay enough money to avoid that pain to make the business profitable.

On the other hand, the open source license must not be painful to the open source community, or it will undermine the benefits of the cheap and ubiquitous distribution channel that open source licensing provides. Open source users must experience only pleasure in their use of the software, or the product will fail to penetrate the market.

5.5.5. Measuring the Market

Businesspeople generally measure markets in terms of dollarsthe amount of money that customers in the market will spend for a product or service. Dual-licensing businesses need a different metric, because they distribute their software to a combination of paying and nonpaying customers. The result is that a dual-licensing business can have a much larger installed base than a measure of dollars spent would suggest.

Dual-licensing businesses need to look at this issue pragmatically. Put bluntly, a dual- licensing business is never going to get all the money on the table. Some users would rather meet the open source terms than pay money for the software. A dual- licensing business must balance the size of its installed base, and the concomitant opportunity to sell more proprietary licenses, with the money that could be extracted by charging for every use.

The long-term goal of the business is to maximize profits and to grow. By foregoing some revenue in the short term, a dual-licensing business may make its product ubiquitous, which creates additional long-term opportunity. Though you might never get all the money on the table, you can find yourself sitting at a much bigger table this way.

There are two other benefits to a large installed base, even if not everyone in it pays a license fee.One, noted earlier, is that the earth is scorched for competitors: the only way to compete on price with a free product is to pay people to use a competitive one. This is an expensive way to capture customers.

The other, of course, is the opportunity to sell services independently of license fees. A large installed base may be willing to pay for consulting and support, even if it is not willing to pay for the software. Generally, dual-licensing businesses offer these services and book revenue profitably as a result. As a rule, however, dual licensing is more valuable for the license fees that proprietary users pay than for the service fees that open source users are willing to pay.

5.5.6. Piracy

Because open source software is widely available, it is easy for software pirates to make and distribute copies in ways that violate the open source license for the code. Significantly, it is easy for a user to download the software under an open source license, and then to use it in ways that only a paid proprietary license would permit.

Piracy is not, of course, a problem unique to open source or dual-licensing companies. Every software vendorindeed, every software developer who distributes a productruns the risk that unscrupulous users will pirate copies of the product. Individual vendors and umbrella organizations like the Business Software Alliance battle the problem continually.

Piracy is a very real business problem for dual-licensing vendors. The two lines of defense are diligence in protecting intellectual property rights, and consistent and clear explanations of the terms under which the software is distributed.

Diligence in protecting intellectual property rights is relatively simple. Anytime a dual-licensing vendor learns of a misappropriation of its software, it must pursue and resolve the issue. This is no different from the rules that apply to a proprietary software vendor, of course.

Consistent and clear messaging on the license terms is equally important. Open source licensing is now generally well understood by the software industry. By emphasizing the conditions that apply to open source use, and making clear the difference between its paid and proprietary licenses, a dual-licensing vendor can educate its users and capture business before problems crop up.

In general, no responsible business or consumer wants to misappropriate the intellectual property of another. The penalties are large, the risks are unacceptable, and it simply is not fair. Most consumers of software want to obey the law.

Dual-licensing vendors are in exactly the same position as purely proprietary vendors. Digital distribution means that copying is easy. There are pirated copies of both proprietary and dual-licensed software in the world. Vendors of both have the same law behind them and the same recourse against pirates.

5.5.7. The Social Contract

Open source is much more than an ingredient in a business model, of course. The movement predates the dual-licensing model by decades, and its long history has produced a complex and nuanced present. Any business that proposes to use open source technology, including dual-licensing businesses, must understand and participate in the open source movement as it exists today.

The open source community generally cares a great deal about reputation; companies, as well as individuals, gain status by being smart and by contributing to the good of the community. Contribution certainly includes developing open source technology for use by others, and any dual-licensing business will do that. Contribution can also mean, for example, promoting and explaining open source technology in the press and at industry meetingsa task for which businesses are often better suited than individualsand supporting worthy open source projects with staff time and money.

It is unusual in business for an outside group that pays a company no money and that has no legislative authority to have as much influence over a business and its policies as the general open source community does over open source businesses. If a company alienates the open source community, the main advantages of open source distributionubiquity and a large installed basecan disappear in a flood of bad press and ill will on developer discussion lists. Executives at dual-licensing businesses must speak clearly to their open source constituencies. They must show the community the respect it deserves in order to earn the community's respect in return.

Besides merely making friends with the open source community, dual-licensing businesses must pay attention to issues that are unique to the business model.

An unwritten social contract among open source developers says that the community generally will produce software that benefits the community most. This is in some sense driven by Darwinthe people who write open source code work on the problems they consider most important, so if there is widespread pain around a particular issue, there will be widespread attention to addressing it.

The social contract, of course, is not perfect. For example, many open source projects are more poorly documented than their proprietary competitors, because very few programmers enjoy writing documentation, and few will do it without being paid. While proprietary enterprise software is not always more polished than open source, it is generally the case that the drudgery in proprietary development gets more attention than it does in open source projects. A programmer working as a volunteer often lacks the patience to do the exhaustive testing and debugging, interface cleanup, and so on, that commercial licensees of software have come to expect.

The introduction of companies focused on profits into this mix alters the social contract of open source. The change is, in some respects, for the better, but it is a change nonetheless.

Businesses driven by profits will invest to maximize those profits. A large customer willing to pay a significant price for a new feature or for changed behavior in a product will get more attention from a business than will a large number of nonpaying users who all want some different feature or behavior. In business, customers vote with their money. In pure open source, contributors vote with their programming time.

A dual-licensing business will, and should, pay attention to the requirements of its paying customers. The business needs to balance the needs of its paying customers with the needs of the nonpaying open source user community. After all, the company does not want to alienate its open source users and thereby lose the benefits of its open source distribution.

As a rule, this issue requires attention, but seldom causes real problems. Paying customers are usually interested in speed, reliability, or enhancements that make a product more powerful. Those improvements are all useful and interesting to open source users as well, so it seldom happens that the open source community loses and the paying customer wins.

From the point of view of the paying customer, the ability of money to influence the product roadmap is actually a benefit. Many companies considering adopting open source technology are concerned that they have no way to influence the development community to solve real business problems for them. Because dual-licensing companies care about income and profits, customers know that they can get the vendor's attention the old-fashioned way: by pulling out a checkbook.