For the latest version of this paper see <http://www.hecker.org/writings/setting-up-shop.html>. This is a work in progress; I welcome comments and criticisms and will respond to them as I have time, either individually or in future versions. Note that this draft version of the paper is incomplete; I'll release the remaining sections in future versions of the paper as I complete them.
Disclaimer: This document represents my personal opinions only.
You've no doubt read about Netscape's recent release of the source code for Netscape Communicator; you may also have heard about earlier open-source projects like the Linux operating system kernel and read papers like Eric Raymond's "The Cathedral and the Bazaar" that make a case for open-source development within an extended developer community as a way to create better software. In this paper I discuss why and how a commercial company might build a business or extend an existing business through the creation and distribution of open-source software -- in other words, how to "set up shop" in the "bazaar."
I first discuss particular problems and potential opportunities which might lead you to consider doing something different from "business as usual." I then explore the business proposition for open source software, starting from the proposition that your company is in business to provide customers with something of value and to receive money (or other things of value) in return. Moving to open source for a product can potentially provide better value to your customers, including in particular the ability for your customers or third parties to improve that product through bug fixes and product enhancements. In this way you can create better and more reliable products that likely will more truly reflect your customers' requirements.
However the real key to building a business on open-source software is going beyond that to provide greater value to your customers than your competitors can, and ultimately turning that increased value into increased revenue and profits for your company. In the traditional software business model your company provides all (or almost all) of the value to customers, and you realize revenues and profits in return for that value through traditional software license fees. In an open-source business model much of the value provided to customers will not be provided solely by you, but rather by other developers who are attracted to working on your open-source products and who will thus help augment your resources as opposed to your competitors'. These "outside" developers may be motivated by the prospect of working with software that solves important problems for them and for others, by the possibility of future gain providing related services and creating related products, by the opportunity to increase their own personal knowledge, or by the ego satisfaction of building an enhanced reputation among their peers.
Thus a significant part of your potential success will depend on the work of others who will be working "for free," i.e., open source developers who will contribute their work back to your company and to the developer community at large without demanding or receiving any money or other tangible payment in return. However open-source developers will not (and should not) do this work unless you treat them fairly. This is in part a function of your company's attitudes and actions towards developers working with its products, but is also formalized in the company's choice of an open-source license, specifying the terms and conditions under which the company's open-source products can be used, modified, and redistributed.
There have been several standard license agreements published for use with open-source software. All of them share some common features, most notably making software "free" to users both in terms of being no-cost and in terms of minimizing restrictions on use and redistribution; these features are explainable as necessary for developers to feel fairly treated. If possible you should use one of the existing open-source licenses, or modify one of those licenses to meet your needs; some licenses will work better than others for particular business models. Possible license choices include
Beyond selecting an appropriate license and business model, what else might your company have to do in order to implement an open-source strategy? I discuss various issues your company will have to consider and address when converting one or more products to open source, including
Perceptions about free software (pro and con) have often been more absolute than reality would warrant. To take but one example, even Richard Stallman, often thought the free software advocate most hostile to commercial considerations, did not argue in his "GNU Manifesto" that software development should always be a unpaid or non-profit activity; rather he proposed the abandonment of for-profit business models based on treating software as intellectual property, arguing instead that for-profit software development be done as a professional service. This happens to be one of the open-source business models discussed below. Similarly many commercial software companies have used software originating in the free software community as the basis for commercial products, and in some cases have contributed to the development of free software through donations of money, hardware, or their employees' time.
Events like the growing success of the Linux operating system kernel and associated GNU and other utilities (developed under the free software model) and Netscape's recent release of Communicator source code have focused more public attention on the potential importance of free software to businesses both as users of software and as for-profit producers of it; these events have also led to the recasting of "free" software as "open-source" software, a term that emphasizes more the importance of making source code to software freely available, and also may (at least subliminally) remind people that a company can choose to make source code freely available and still serve its own business interests as a for-profit organization. (Note however that open-source software is still "free" software in the sense that no license fees are charged for use or redistribution of binaries or source code, as well as in the sense that users are free to modify the source and create and distribute derivative works.)
Still, this strategy may seem counter-intuitive or even self-destructive; it goes against years of tried and true commercial software practices. However these are unusual times in the commercial software industry, and may call for unusual measures. In considering a major change in strategy like moving to open source, it may help to consider an historical analogy: When Netscape first made the Navigator web browser available for unrestricted download over the Internet, many saw this as flying in the face of conventional wisdom for the commercial software business, and questioned how Netscape could possibly make money "giving the software away." Now of course this strategy is seen in retrospect as a successful innovation that was a key factor (if not the key factor) in Netscape's rapid growth, and rare is the software company today that does not emulate this strategy in one way or another. It's possible that the current interest in open source may signal another such industry-changing event.
I've written this paper primarily for commercial software vendors considering whether to take a product open-source; however it may also be of interest to their customers considering why and how they might use such products, and to open-source developers curious about the business side of open-source products. My goal is to address some of the practical realities of the business of open-source software, writing as someone who lobbied for an open-source strategy within a major commercial software company (Netscape Communications Corporation) and was a close observer of and sometime participant in the implementation of that strategy.
However it may be that you do in fact have either some present problems or some future opportunities you are concerned about; here are some common areas where commercial software companies might have "pain" or see "gain:"
If these and other potential benefits are of interest to you, please read on and see if and how this might apply to you. Because open source is such a radical departure from traditional commercial software practice, I think it will help to spend some time first going over the basic ideas behind an open-source software business; to start, let's go back to square one and consider the basic principles behind any successful business.
For customers, value is not necessarily associated with particular features of a product. (In fact, products with the same features offered by two different companies may have different value for customers in each case.) More generally, a product has value for customers to the extent that it helps them solve problems; the more problems it can help them solve or the more important the problem it helps them solve, the more value the product has. Customers may solve these problems with the help of the product's actual features (as web browsers like NCSA Mosaic and Netscape Navigator originally helped solve the problem of accessing the Internet without complicated utilities) or they may solve their problems with the help of other product attributes (as a company's brand name and reputation for quality might help solve the problem of making a "safe" buying decision).
To remain successful over time a company can attempt to add additional value to its product line by adding new features to existing products, adding new products, adding new ways to use the products (e.g., services associated with the products), and so on. For your company to continue to grow you need to find new ways to provide value to customers, and new ways to convert that value into money.
But your competitors also can add new features, new products, and new ways to use them, and in many cases they have greater resources with which to do this. If you want to be successful in a competitive market you can attempt to do so by offering particular product value earlier than your competitors, by matching or exceeding the value that your competitors' resources create for their own products, and by creating value for your products and services in ways that your competitors cannot easily duplicate.
In a time of rapid innovation competing successfully means continually having to pursue advantages in relative value deriving primarily from product features (advantages which are often temporary), combined with more strategic attempts to alter the competitive balance in ways with which your competitors are less prepared to cope. Seen in this light a move to more of an open-source business model is not simply a tactical move to solve a particular business problem, but rather can be part of an overall strategy to change the rules of competition in your market space and perhaps in the software industry as a whole.
The idea of source code as "crown jewels" is simply a commonly-used metaphor, and metaphors can be powerful forces for good or ill depending on the context. In this case the metaphor implies that a software company's source code is a precious resource that must be protected at all costs from anyone outside the company who would seek to obtain it or (mis)use it. Thus most commercial software companies release their products' source code only in very special situations, and do so only when accompanied with an array of legal arrangements (including non-disclosure agreements and very tightly-worded terms and conditions regarding redistribution) and a large amount of money changing hands.
But arguably possessing source code in and of itself is irrelevant. Source code acquires true commercial value only if you can use it to create products and/or services that you sell for money, and you can typically do this successfully only in the context of a company with a known brand name and a sustainable market position. (For example, even if I had the source code to Windows it still wouldn't make me Bill Gates.) Similarly, releasing source code for one of your products would not necessarily mean that other companies could duplicate your successes or even adversely affect your business. Those successes are typically a result of much more than the product features implemented in your source code; other factors might include the celebrity of and trust placed in your brand name, the quality and reputation of your services, the effectiveness of your sales and distribution channels, and so on. Those factors could still be very much influenced by you, even in the absence of complete control over the source code itself.
First note that by "source code" for a given product I mean the underlying programming language statements (and related information, e.g., make files, error message files, etc.) which can be read by humans, modified to make changes and additions, and then used to build a functional version of the product or another derivative product reusing some or all of the same source code. For purposes of this discussion we assume that for a given product you would distribute all relevant source code. (In actual practice this may not be possible in all cases, as discussed below; for example, initially you might have to distribute some components of a product in binary form only, or not distribute certain components at all.)
Much software has traditionally been distributed in source code form, and there are several commonly-accepted ways in which having source code for a product can directly increase the value of that product for a customer by helping them solve any of a number of problems:
If you compete with larger companies, this is exactly where their greater resources and experience serve them well; to compete successfully with such companies as time goes on, you must not only create products that are more functional than your competitors' in a generic sense, but must also find ways to approach or match your competitors' whole product value, ways that do not require your company to take on the entire burden of doing so itself (given that your own resources do not equal those of your competitor).
However, for as a commercial company it is not enough just to increase the value of your products; you must also find sustainable ways to have customers reflect that value back to you in the form of increased revenues and profits. Before we consider possible ways to do that as part of an open-source strategy, it's worth reviewing how commercial software companies have traditionally approached this problem, and how this approach might need to change in the open-source case.
Considered strictly from a business point of view right-to-use licensing has several advantages, especially for the software vendor but in many cases for the customer as well. First, right-to-use licenses can be tailored to work in a wide variety of ways; for example, software can be licensed per-user, per-machine, per-CPU (for multiprocessor systems), per-concurrent-user, or for an entire organization or part of an organization (site licensing). Different licensing schemes can also be employed based on the use to which software will be put; for example, using software in support of a particular end use may be done using a separate license from using that same software in support of a different end use, even though the actual users of the software may be the same in both cases. This allows the vendor to offer preferential pricing schemes for certain customers or end uses as appropriate. (For example, the vendor might allow no-charge unrestricted use by all or some noncommercial customers, or might charge less for software used only internally versus software used to provide services to external users.)
Second, software license fees are independent of amounts charged to the customer for services such as technical support, consulting, and systems integration. For US software companies operating under SEC rules this means that software license fees can normally be recognized as revenue immediately at the time the associated product is shipped; by contrast, service fees can be recognized as revenue only over time as the services are actually delivered to customers. This can be an important consideration, especially for small software startup companies that need to grow revenues quickly in order to satisfy investors and fund growth in operations.
Finally, since they are not directly tied to services provided by people, software license fees can be independently negotiated between vendor and customer based on the perceived value embodied in the software itself. (For example, the perceived value might be roughly proportional to the amount of money the software can save the customer. If that amount is large then the perceived value of the software will be high.) At the same time the incremental cost of selling another software license is relatively low (since software can be easily reproduced). Thus assuming that the customer and the overall market judge the perceived value of a software product to be relatively high then (all other things being equal) a software company's gross margin on software licenses will be higher than its gross margin on services, and this will translate rather directly into increased profits for the software company.
Of course these characteristics of traditional right-to-use licenses have their potential downsides as well. Licensing arrangements can be overly complicated and difficult for both vendor and customer to administer. The immediate recognition of revenue from software license fees can produce undesired peaks and valleys in a software company's revenue stream, especially when the number of customers is relatively small and the average revenue per customer relatively large, so that the difference of even a day or two in concluding a few deals may shift a fair amount of revenue into one quarter from the next, or vice versa. And higher gross margins for software licenses are susceptible to price pressure from competitors willing and able to discount software heavily or even to give software away on its own or by bundling it with other software.
My purpose here is neither to argue for the superiority of the traditional software business model nor to claim that it can and must be completely abandoned. Rather I want to emphasize these important points:
First, developers are in large part attracted to working on software that holds the promise of helping them solve problems they themselves consider significant. If you create software that addresses important problems, even if the problems are important only to a subset of the overall developer community, then it is a reasonably safe bet that at least some other developers will find this software promising themselves and worthy of working with, especially if they have access to the underlying source code. (As Eric Raymond notes in the "The Cathedral and the Bazaar," your software need not completely solve a problem, it need only offer a "plausible promise" that it could do so as it is evolved.)
Once attracted to working with your source code, what would keep developers interested in doing so? The answers will vary depending on whether the developers are doing commercial or noncommercial development. Commercial developers will obviously be interested in some way to profit financially from their work. Working with your source code they will likely have a variety of possible approaches open to them:
For noncommercial developers the rewards would be different. They would likely be motivated more by the ego reward of seeing their software used by other people and praised by other developers. They may also be motivated by the ideals of code sharing and general openness found in the open-source developer community. If starting with your source allows them to build more interesting software and if they can distribute that software freely (thus spreading their reputation and/or upholding open-source ideals), then it is likely that some of them would be enthusiastic about working with your code.
Assuming that developers have sufficient positive incentive to work with your source code, you then also have to be concerned with removing obstacles to their participation. This goes back to my comment above about treating open-source developers fairly; licensing in particular is a key area where considerations of fairness are important.
This has the effect of setting the effective license price at zero, since once a (binary or source) copy of the software is given to any user then that user may turn around and redistribute the software to others without charging them a license fee and without owing any license fee to the originator of the software. The Open Source Definition also contains a number of other provisions intended to prevent vendors from weakening or evading this basic guarantee, including the provision that all users and all types of end use be treated equally (so that, for example, businesses cannot be charged a license fee while noncommercial use is exempted).
Why should this be? Part of the reason lies in the origins of free software as a concept; charging for software licenses was (and is) seen by many as antithetical to the interests of users (who would be better off if provided free and unrestricted use of software) and to society as a whole. For example, in the GNU Manifesto Richard Stallman claimed that "[a]rrangements to make people pay for using a program, including licensing of copies, always incur a tremendous cost to society through the cumbersome mechanisms necessary to figure out how much (that is, which programs) a person must pay for" and that
Extracting money from users of a program by restricting their use of it is destructive because the restrictions reduce the amount and the ways that the program can be used. This reduces the amount of wealth that humanity derives from the program.In this view open-source licenses are designed the way they are for essentially utilitarian reasons, in order to promote the use, distribution, and creation of useful software.
However the provisions of the Open Source Definition and of open-source licenses can also be seen not just as guarantees to users in general but also as guarantees to software developers in particular, that they will be treated fairly and given equal opportunity to succeed or fail based on their merits. The underlying problem here is that the original developers of the software are always privileged in a fundamental sense: under existing legal environments they "own" the original code (in the sense of holding copyright to it), they have the power to set license terms for its use and redistribution (as a consequence of copyright), and given that they know most about the software they will likely have the leading role in its continued development (at least initially). This is obviously true in the case of a commercial company converting a proprietary product to open source; it is also true in the case of a noncommercial developer who creates the initial version of an open-source program. (In his paper Homesteading the Noosphere Eric Raymond argues that for all open-source software there will always be one person or organization that has "the exclusive right...to re-distribute modified versions" [emphasis in the original], and thus has a privileged position with respect to it; Raymond sees this right as being a kind of common-law property right.)
Consider the rest of the (actual or potential) developer community who are not thus privileged and who are expected to contribute their labor to the improvement of the open-source product, usually for no direct compensation. Why should they participate in what threatens to be an unfair exchange, unless the gap between privileged and non-privileged developers is minimized? One way to minimize the gap is to eliminate license fees; this prevents the privileged developer(s) from making a direct monetary profit from the unpaid labor of other developers. A second way to minimize the gap is to treat all developers equally in the context of the open-source licensing terms, with no developer having special privileges or advantages as a direct consequence of the license. This helps ensure that in theory all developers have equal opportunity to achieve success, subject only to the skill and resources they can bring to the task, and that neither you nor anyone else can leverage a privileged position to obtain unjust advantage over other developers.
Putting software into the public domain grants the maximum freedom possible to end users and developers. However at the same time it opens the possibility that one or more developers may take the software and use it as a base to create proprietary programs; if those programs become dominant in the market then from a practical point of view the software is no longer open-source, even if one form of it remains available in the public domain. (In fact, users may not even be aware that the proprietary products use public-domain code.)
Because of this potential problem most open-source advocates recommend not making software public-domain; even developers who do not believe in the concept of "intellectual property" still advocate using the mechanism of copyright, if only to be able to use a formal open-source license to promote certain beliefs and practices. (See the GNU General Public License for the best example of this.)
The BSD License has the following main features:
As noted above, the original BSD License was developed in order to release non-commercial software developed as a byproduct of university research, and its legal provisions reflect this heritage: they affirm the academic tradition of giving proper credit to researchers (i.e., the developers) and safeguard the basic legal interests of the university (i.e., the organization employing the developers), but otherwise impose no real restrictions on use of the software. From the point of view of a commercial software company BSD-style licenses contain the minimum terms and conditions that an open-source license would need to have in order to be an effective license at all; from the point of view of open-source developers BSD-style licenses allow the maximum freedom in using the source to create derivative works. This includes the freedom to take open-source software under a BSD-style license and use it to create a proprietary product for which source code is not made available. As a result many open-source advocates recommend not using BSD-style licenses, preferring licenses that require (to a greater or lesser degree) that derivative works of open-source software also be made available as open source.
[W]hen you distribute the same sections [i.e., code not under the GPL] as part of a whole which is a work based on the Program [i.e., a work under the GPL], the distribution of the whole must be on the terms of this License [i.e., the GPL], whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. [notes added]Thus if you use GPL-ed code in a proprietary program containing your own source code, you must make your source code available under the same terms as the original GPL-ed code. (This property of GPL-ed code has led many to compare it to a virus subverting the proprietary "host" program to create more GPL-ed code.)
Two interesting cases are where a proprietary program dynamically links to GPL-ed code or a GPL-ed program dynamically links to proprietary code. The latter case arises when a GPL-ed program uses existing system facilities such as C run-time libraries or GUI toolkit libraries; the GPL contains a special provision (in paragraph 3) exempting proprietary libraries from source code disclosure provisions if they are "normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system."
As to the former case, Richard Stallman has claimed that if a developer uses GPL-ed code to write code designed to be dynamically linked to from a proprietary program (for example, a GPL-ed plug-in module for a proprietary image processing program) then that developer is violating the GPL; Stallman later clarified this to add that if the developer were writing the GPL-ed code "from scratch" then they could grant special permission to use the code in this way, or if using GPL-ed code from other developers could ask those developers to grant such an exemption. This does not however change the intent of the GPL: Stallman still claims that "a GPL-covered plug-in that is designed to be combined with a non-free master program is a form of combined work, and a violation of the GPL." (Of course in the end this is simply Stallman's personal opinion, albeit an opinion that carries considerable weight among many free software developers; what constitutes a "combined work" or "derived work" in general is ultimately a question for the courts, and if a court ever decides a case involving the GPL they may or may not agree with Stallman on this point.)
The fact that GPL-ed code can "taint" initially non-GPL-ed programs means that in effect you can use GPL-ed source code only to create other GPL-ed programs. This is a desirable feature if (like the Free Software Foundation) you wish to encourage the spread of the GNU philosophy. It is also somewhat desirable (or at least tolerable) if you are creating an open-source product from scratch or if you wish to leverage others' GPL-ed code for your product, because the GPL is widely used and accepted in the free software developer community and there is a large base of existing GPL-ed code. However it creates a problem (and deliberately so) for commercial software vendors who wish to build their own proprietary products using GPL-ed code in some way; it also causes many commercial organizations to shy away from using GPL-ed software.
In particular, if you are considering converting a proprietary software product into an open-source product, and if your product includes third-party technology or shares source code with other products of yours, then the GPL would almost certainly not be a good open-source license for you to use because it would be difficult to impossible to put only part of your code under the GPL and still use that code in products in conjunction with third-party code or your own remaining proprietary code. (You could evade this issue initially by releasing your code under both the GPL and another less-restrictive open-source license and then using the less restrictive license when combining your open-source code with other code. However once others began to add their own GPL-ed code to yours then you could no longer use that new code under the less-restrictive license, unless you obtained permission to do so from each and every contributor; that could pose insurmountable problems if the contributed code were in turn based on previously GPL-ed code from others, and so on.)
The GNU Library General Public License (GNU LGPL or plain LGPL) attempts to better address the case of open-source products that are libraries intended to be used with other programs, as opposed to programs in their own right; a program that calls routines in a LGPL-ed library is not considered a derived work for licensing purposes in exactly the same sense that it would be if the library were licensed under the GPL. However other derived works of the LPGL-ed library fall under LGPL terms, exactly as they would if the GPL were used instead. The LGPL may or may not be a good license for you to use for an open-source product, again depending on whether the product is being converted from an existing proprietary product and how third-party and still-proprietary code is used in that product.
First, the MozPL contains a general and relatively rigorous definition of when and how derived works fall under the MozPL license provisions (or are "Covered Code," using the terminology of the license). For MozPL-ed source code considered as a set of source files, modifications of the original source files are considered to also fall under the MozPL, as are new source files incorporating extracts from the original source files. Such modified or new files are required to be licensed under the same terms as the original files, and in particular must be made freely and publicly available in source form. In this way the MozPL is similar to the GPL in mandating sharing of code modifications and seeking to prevent open-source code from being converted to proprietary code.
However unlike the GPL the MozPL explicitly permits MozPL-ed code to be combined with separate proprietary code to create a proprietary program (a "Larger Work" in MozPL terminology) which does not fall under MozPL terms; such a program may be licensed for a fee and its (proprietary) source code need not be made publicly available. As implied above, the separation between the open-source code and the proprietary code is made at the source file boundaries; a given source file is either under the MozPL or under a different license, which may be a proprietary or an open-source license. (The other license must be compatible with the MozPL in the sense that its provisions may not conflict with those of the MozPL; among other things this rules out combining MozPL-ed and GPL-ed code, since the presence of the GPL-ed code would result in the application of GPL terms to the combined code. However the LGPL allows enough flexibility so that LGPL-ed code may be combined with MozPL-ed code.)
Thus an open-source product initially released under the MozPL may be extended with proprietary code to create new proprietary products, as long as the proprietary code is separate (i.e., in separate files) and interacts with the open-source code using a defined API. (This feature of the MozPL is to some extent reminiscent of the LGPL, although the corresponding LGPL terms are more restrictive.) If the enabling code for the API is not already in the open-source product then changes to the open-source product to create the API fall under the MozPL (because they would be modifications to the original MozPL-ed source files) and must be made freely and publicly available by the developer creating the API (which in this case would be the developer creating the proprietary product). This encourages open competition among both commercial and non-commercial developers by allowing others to create alternatives (whether open-source or proprietary) to any proprietary products based on MozPL-ed code.
The NPL is a variant of the MozPL designed specifically for use with the released Netscape Communicator source code. (In practice the NPL was drafted first and the MozPL then generalized from it.) The NPL exists because prior to being released as open source Netscape Communicator already existed as a proprietary commercial product that shared source code with other proprietary products (including Netscape's SuiteSpot servers) and for which source code had been licensed to third parties under existing contracts still in force; the MozPL by itself would not be sufficient to address the consequent legal complications. The NPL duplicates all MozPL provisions and in addition reserves to Netscape two rights not granted to other developers: the right to use NPL-ed code in other products (like the SuiteSpot servers) without having those products fall under the NPL, and the right to relicense NPL-ed source code to third parties on terms other than those in the NPL. The former right is limited in time (to two years), since the shared code in question can be reorganized over time to separate NPL-ed code and proprietary code into different files and libraries. The latter right is not limited in time, since the third-party contracts in question may exist in perpetuity.
In my (admittedly biased) opinion the MozPL (or a MozPL variant, such as an NPL-like license, if necessary) deserves serious consideration as the license of choice for any commercial company looking at creating an open-source product from scratch, converting a proprietary product to open source, or making open-source extensions or additions to proprietary products; it was designed specifically for the requirements of a commercial software company doing both proprietary and open-source development and was created by lawyers and others intimately familiar with commercial software practices. (Thus, for example, the MozPL incorporates legal language typically required in standard commercial software contracts relating to limitations of liability, responsibility for intellectual property claims, arbitration of disputes, and so on.) The major case where the MozPL is not appropriate is where you are building a business based on existing open-source software already under the GPL or a GPL-like license.
Even if you decide not to use the MozPL it is still worth consulting Netscape's material about the MozPL and NPL and the public discussions through which Netscape received advice on and criticisms of the draft licenses; these are especially valuable as background information if you decide to create your own open-source license.
As discussed above, you will not make money through traditional software licensing fees. Thus open-source software is a real-life example of a case considered by many industry visionaries, namely intellectual property that is "free" in the sense that anyone can copy it and use it at no charge. (Alternatively, one could consider open-source software as not constituting intellectual property at all, a view held by some open-source advocates; see also the discussion on licensing above.) For example, Esther Dyson (in Release 2.0 and elsewhere) has assumed that intellectual property considered as "content" will be free or near-free in the future, and has proposed the use of other business models for making money off intellectual property, based generally on either providing services tied to the intellectual property (e.g., as in consulting) or on using the intellectual property to attract people's attention and then realizing money from that (e.g., as in advertising).
Revenue is generated in this model by selling two broad categories of items: physical goods, e.g., media and hard-copy documentation, and/or services, e.g., technical support. Vendors can differentiate themselves by providing more complete and easier-to-use software distributions, in essence simplifying and improving the user's experience with the open-source software in question; they can also differentiate themselves by the quality and pricing of their service offerings.
In this model there is only limited ability to use value-driven pricing; more typically the pricing is determined primarily by the cost to provide goods and services, as there is price competition with other vendors offering comparable goods and services and definite limits to what users are willing to pay for them. However if a vendor's reputation is good then that can be used to justify higher prices than for a "commodity" offering.
If the open-source product shares any source code with the company's proprietary products (for example, they use common libraries) then the open-source license chosen must allow distribution of such source code for the open-source product while allowing the same source code to be used in proprietary products distributed using standard licenses. The company should therefore avoid the use of the GPL or other licenses that aggressively "taint" products incorporating code under the license; a BSD-style license would work fine, and the Mozilla Public License or variants thereof might be appropriate if the common source code is accessed via a set of defined APIs.
Generation of revenue (if any) from the open source product could be done as in the "Support Sellers" model, i.e., by selling media and services. However typically the bulk of revenue generated would be through sales of other software products; having the open-source product could increase sales of such traditional products in various ways:
Corel is using this model for the Netwinder product line to be offered by its Corel Computer subsidiary; Netwinder is essentially a network computer using Linux as its operating system kernel. Corel Computer is porting the Linux kernel to Netwinder and will release all Netwinder driver code as open source under the GPL; it will also release a set of Netwinder development tools based on open-source applications. Another example of companies using this model to some degree is VA Linux Systems and other companies which sell PCs designed and preconfigured to run Linux; unlike Corel VA Linux and its competitors are selling standard PC hardware, but are still using Linux to maximize the utility of their systems (e.g., as network servers or high-end workstations).
In the "Widget Frosting" model most if not all revenue would be generated through sales of the hardware itself. Using open source for the enabling software could increase hardware sales as in the "Loss Leader" scenario, e.g., by increasing the base of developers familiar with the hardware and able to make it perform to full capacity, thus making the hardware more functional, reliable, and useful to its end users.
In this model vendors can differentiate themselves based on the attributes of the underlying hardware, e.g., functionality, performance, reliability, flexibility, and cost; the function of the open-source software is to enable the hardware to fulfill its full potential with regard to these qualities. Since the vendor is selling physical goods for which competitive products exist in most cases, the pricing is typically much more cost-driven than value-driven.
Vendors can differentiate themselves based on the quality of the goods themselves, and can also build some brand loyalty among people who use and like open-source software and who are appreciative of vendors that support it in some way. Since what is being sold here is a physical item as opposed to intellectual property of some sort, pricing will tend to be cost-driven rather than value-driven for the most part, although in some cases brand reputation can justify somewhat higher prices than otherwise possible.
For this model a company would likely use an open-source license that minimized the possibility that its open source software could be turned directly into proprietary software by competitors; examples of such licenses include the GPL and the Mozilla Public License.
Vendors can differentiate themselves based on the attributes of the services themselves; some of these attributes are a function of the open-source software serving as the front end, but as much or more would be a function of the back-end systems. Those back-end systems could be based on proprietary software or on a combination of open-source and proprietary software; in either case, by creating unique and useful services which could not be easily duplicated by competitors a company could justify pricing the service more commensurate with the value experienced by the user. (For example, an on-line gaming service could price itself based on the entertainment value it provides to users relative to alternatives like traditional video games, movies, and cable TV.)
The following business models are more theoretical, in the sense that no companies appear to be actively using them today. However they appear to be at least theoretically feasible, and it may be that in the future one or more companies will be able to implement them successfully.
There would be two main tactical problems to overcome in successfully implementing a "Sell It, Free It" strategy. The first would be deciding exactly the right time in the product's life cycle to convert it to open source; doing it too early might mean unnecessarily forgoing significant license revenues, while doing it too late might lessen the interest of open source developers in contributing to the product's further development. The second problem is related to the first: If customers think the product is likely to be converted to open source at some point then it is more difficult to justify to them why they should buy it now rather than waiting. The problem becomes more tractable if the product's sales cycle is short relative to the product's life cycle (otherwise price reductions or conversion to open source are likely before customers complete their buying decisions) and if product pricing is managed so as to plan for scheduled reductions in license price and at least partially compensate for such reductions with revenue from other sources, such as technical support or professional services.
In a fully-realized "Sell It, Free It" model customers buying the product near the beginning of its life cycle are in essence paying a premium for the value of having the software earlier rather than later, and license pricing can reflect this value. Once the product converts to open source it becomes in essence a commodity, but it can still add value to newer proprietary products, whose license pricing can reflect that added value.
Using this model was not possible with traditional free software products because the product "brand names" (as it were) were typically not formally registered as trademarks. (In the case of Linux this caused a dispute requiring legal action to resolve.) However a commercial product being converted to open source will almost always have associated with it trademarks in the form of product names and logos, and these can remain under the control of the company. For example, even though Netscape released source code for the Netscape Communicator product, only Netscape (or authorized Netscape licensees) can use the source code to create a product called "Netscape Communicator;" products built by others from the source are typically referred to by the name "Mozilla" (from the original code name for Netscape Navigator 1.0).
In general the two product versions (with and without associated trademarks) could be built from identical or near-identical source code; however from the perspective of the market they would be two different products with possibly different perceived value. (For example, the branded product may have undergone additional testing and validation not done with the non-branded product.) If you convert a product to open source then a third party wishing to distribute a product based on that source (for example, for distribution as part of a special on-line service) may also wish to separately pay you for a license to use your trademarks in association with that product. The price of that license can reflect the brand value and reputation that your company (and by association, your trademarks) have in the marketplace.
(I should note that even though I've used Netscape as an example here, Netscape has not publicly announced any plans to license its trademarks as described above.)
In this model the "software franchisor" would not only license brands and trademarks but also supply franchisees with training (e.g., in specific aspects of running an open-source development effort and support seller business) and services (e.g., centralized support for contracting and procurement, advertising and marketing campaigns). Revenues would come from sources such as sales of franchises and royalties based on franchisees' revenues.
However there are possible business models that involve software distributed under licenses that are not quite open-source in the strict sense, but are also not as restrictive as traditional proprietary licenses. One way to explore the space of possible "hybrid" business models is to go back to the Open Source Definition and look at relaxing one or more of its requirements; here are some changes that might be made:
However at least in theory these rights could be separated and could be made conditional on paying some sort of license fee. (Some might object that there are no technical means to enforce such separation; for example, if someone has a copy of the code and can use it to build an executable, there is no way to prevent them from modifying it. This is true, but in practice such considerations have not been a major problem in commercial software licensing; for example, although many software products are now available over the Internet for downloading (e.g., for evaluation use) and thus there is no technical way to enforce payment for a right-to-use license, nevertheless almost all commercial and government organizations do in fact "pay up" and officially acquire licenses if their users end up using the product -- particularly if the organizations are prompted to do so.)
Thus, for example, users could be given a low-cost or even no-cost license to possess a copy of product source code, compile it for internal use, and make bug fixes as necessary, but would be charged a higher license fee if they wished to redistribute modified versions. (Returning bug fixes to the original vendor could be exempted from this restriction.) Such licensing terms would likely not be attractive to many if not most noncommercial developers, but might be acceptable and of interest to many commercial organizations. If the product serves a very specialized market then it is quite possible that only commercial users would be interested in the source code anyway, so that a lack of participation by noncommercial developers would not necessarily always be a drawback.
As a real-life example, Troll Tech distributes a free version of its Qt GUI toolkit , including source code; the Qt Free Edition license originally allowed developers to view, use, and modify the source code, but prohibited them from distributing modifications. (As discussed below, Troll Tech later changed licensing of the Qt Free Edition to loosen this restriction somewhat.)
Thus, for example, noncommercial users could be given a full set of rights to the source (rights to view, use, modify, and redistribute), but the vendor might charge commercial users license fees to obtain all or some of those rights. A real-life example of this was the licensing originally adopted for the X11R6.4 release of the X Window System from The Open Group; X11R6.4 source code was made available under a noncommercial license at no charge; however users wishing to distribute binaries for commercial purposes were required to pay a fee for a separate commercial license. (As discussed below, the Open Group later changed the licensing of X11R6.4, and dropped the distinction between commercial and noncommercial use.) Troll Tech also originally prohibited commercial use of the Qt Free Edition, and sold a separate Qt Professional Edition for that purpose. (As discussed below, Troll Tech subsequently loosened this restriction somewhat.)
Thus, for example, a source license could allow personal use or internal use within an organization at low cost or no cost, but prohibit or require higher license fees for use of the software to provide a service to other users (e.g., on the Internet or as part of an extranet). Alternatively, the license could allow no-charge use of the software on particular operating system and/or hardware platforms (e.g., Linux) but require that a license fee be paid to use the software on other platforms (e.g., Windows 95 or Solaris). As a real-life example, Troll Tech originally restricted the Qt Free Edition to being used only under the X Window System (e.g., on Linux and various Unix-based systems); developers wishing a version of Qt for Windows 95 or other platforms had to license Qt Professional Edition. (The current Qt Free Edition license does not contain this restriction, but as a practical matter there is still only an X version of Qt Free Edition.)
For example, The Open Group aroused widespread controversy when they changed the licensing terms for X11R6.4 to use separate commercial and noncommercial licenses as opposed to the single BSD-style license previously used; among other things this resulted in the threat of a split in X11 development, with the XFree86 Project deciding to not use X11R6.4 or other future releases from The Open Group, instead committing to continuing development based on X11R6.3. Subsequently The Open Group decided to change the licensing of X11R6.4; the current X11R6.4 license is a true open-source license and explicitly allows commercial sale of X11R6.4 without paying royalties. In return the XFree86 project decided to employ X11R6.4 as the basis for their 4.0 release, and later formally joined X.Org, the group established by The Open Group to oversee X development.
Similarly, although Troll Tech attempted to justify its business model to the open-source developer community and established a foundation to help ensure that Qt Free Edition would never become a proprietary product, nevertheless many in that community still saw Troll Tech's licensing policies as inconsistent with the goals of the free software movement. This resulted in a rivalry of sorts between proponents of Qt and the Qt-based K Desktop Environment (KDE) and proponents of the GTK+ toolkit and GNOME desktop environment, which are distributed under the LGPL and GPL. It also resulted in the formation of a separate project (known as Harmony) to build a Qt-compatible library to be distributed under the LGPL. Subsequently Troll Tech changed its licensing of the Qt Free Edition to use a new Q Public License (QPL). The QPL is a true open-source license, and eliminates some of the restrictions of the original Qt Free Edition license; for example, the QPL now allows distribution of modified versions, as well as commercial use of the library. However Troll Tech does require that modifications to Qt Free Edition source code be distributed separately from the base Troll Tech distribution, and also still attempts to make some distinctions between use of Qt in noncommercial and commercial contexts in an effort to support Troll Tech's chosen business model. For example, the QPL requires that applications developed to link to the Qt Free Edition should themselves be open-source applications; development of traditional proprietary software still requires licensing of the Qt Professional Edition.
When converting an existing product or reusing existing code it's likely you'll have to address the following issues:
Unfortunately some open-source licences make it difficult to impossible to share source code between an open-source product and a proprietary product; the presence of code from the open-source product in the proprietary product can trigger licensing provisions that in theory force disclosure of source code from the proprietary product as well. (As discussed previously in relation to the GPL, this "tainting" effect is a feature, not a bug, of the open-source licenses in question.) On the face of it this would preclude (for example) maintaining common libraries used by both sets of products. Short of enforcing a strict separation of code between the products, there are several ways to approach this issue; in either case you must first identify all the source files which are or will be shared, and single them out for special treatment.
This first approach is to use an open-source license that does not taint in any way; a BSD-style license is the obvious choice. If you release all the common code under such a license then it can included in any type of product without any untoward consequences arising from the licensing provisions. If someone outside your company contributes changes under the same license then you are free to incorporate those chances into your common code and still use that code with your proprietary products. (For that matter, you could incorporate such changes directly into a proprietary product.)
If for other reasons you want or need to use a strongly tainting open-source license like the GPL, a second approach is to put your common code under two licenses: your existing proprietary license and the separate open-source license. (Since you hold copyright to the code, as assumed above, you have the right to license it how you please.) When the source files in question are included in your open-source product then the open-source license is in effect; when included in your proprietary products the proprietary license is in effect. The major drawback of this approach is that if someone outside your organization contributes changes to one of the shared source files under the open-source license then you will either have to avoid using the contributed open-source code in the shared routine (because of the possibility of tainting your proprietary products) or ask special permission of the contributor to use the code under the proprietary license as well. Either alternative imposes a burden on your development and legal staff to track changes, secure permissions, and so on. It also raises the possibility of open-source development efforts around your product splitting into two incompatible "forks:" one based on the code as released by you (with only your changes or changes for which you have permission to do dual licensing) and one based on the code with all changes contributed under the open-source license.
If the shared code is in the form of a common library or libraries accessed through a set of defined APIs, then a third approach is to release the common code under an open-source license like the LGPL or MozPL which does not taint across library or source file boundaries. In this case the common library itself is a pure open-source product in and of itself (no dual licensing is needed, and the library can be released as a separate stand-alone open-source product); your proprietary products can call that library under the specific exemptions granted by the license. (The MozPL is somewhat more liberal than the LGPL in this respect, as previously discussed.) Note that the rest of the open-source product (the part that calls the common library) can be under any open-source license compatible with the LGPL or MozPL; this includes all the licenses previously discussed: GPL, MozPL, BSD-style licenses, and the Artistic License.
However it may be that you do not wish such a common library to be open source but rather want to keep it proprietary. (For example, the library may include code you do not have rights to release or do not wish to release, e.g., to protect trade secrets.) This poses no problem for your proprietary products calling that library, and you could use the same (proprietary) license for both sets of code. However if you wish to call the proprietary library from the open-source product, then you'll need to license the open-source code under a license that permits this usage; the MozPL or BSD-style licenses would work here, the GPL would not.
You would also have to face the issue of how open-source developers would be able to create a complete product on their own as part of the open-source development process: If the proprietary library is critical to the functioning of your open-source product, then you would have to supply binary versions of the library for them to link to. Such a library would have to be provided at no charge, in order that the final open-source product (including the library) be licensable at no charge in source or binary form (as specified by the Open Source Definition). You would also have to provide the binary version of the library on all platforms of interest to open-source developers, because they're not going to be able to port it themselves in the absence of library source code. (On the other hand, given that the API to the library is known, they can in the long run simply create a true open-source equivalent to the proprietary library.)
A final note: Many developers and corporate legal staff are not familar with the nuances of open-source licenses and may be very concerned just about the presence of open-source code "within the firewall," and in particular on the same systems or in the same source code repositories as proprietary code. These concerns while exaggerated are nonetheless understandable, given the theoretical possibility of tainting; however these concerns can be easily addressed by familiarizing people with how open-source licenses work and enforcing some minimal policies in dealing with open source. In particular, no open-source license in use today (including the GPL) causes tainting when open-source code resides on the same storage medium with proprietary code (or is "aggregated with" such code, as the GPL puts it). Thus it is perfectly safe, for example, to maintain code for a GPL-ed or other open-source product in the same source repository used to maintain proprietary code, if the open-source code is in a separate part of the repository and is not linked with or otherwise combined with proprietary code.
The first and hardest case is where your license with the technology supplier constrains you to shipping only the binary form of their code, and only embedded in the binary form of your product; the license may also prohibit you from disclosing the APIs by which your product interfaces to the third-party product, with such APIs being considered proprietary to the third-party. If the third-party technology is critical enough to your product and if the license terms and conditions are too restrictive then it is quite possible that you may not be able to release your own source code at all, either for the entire product or for a major component of it. In this case it is probably worth asking the third party to see if their restrictions could be relaxed in some way; it is possible that some middle way exists that would allow you to distribute at least partial source code while still complying with relevant license requirements.
The second case is where the supplied technology is already or could be encapsulated in a wholly separate binary component intended to be accessed by a public API, and the license reflects this usage. One example would be a shared library for a graphical user interface toolkit such as Motif; another more specific example is an add-on module like a browser plug-in. Here you have the option of releasing your own source code (since you are using public APIs), and the end user or developer can separately acquire and license the separate component from the third party. (For example, the required library or libraries might already be included as part of a user's operating system.)
The third case is where the third-party component(s) cannot be made available at all (for whatever reason), but the APIs are still public. Here you have the option of releasing your own code but leaving it up to the customer to find a substitute for any omitted components. Assuming a clever and active open-source developer community working with your source code, this could quite possibly lead to the creation of substitute technology for the original supplier's technology, a substitute that would almost certainly be available under more favorable licensing terms. If you wish you could then potentially adopt the substitute technology instead, or simply accept the existence of two possible versions: a public version using the open-source technology and your own version using the proprietary technology. (This assumes that the open-source license you're using permits you to link your code with proprietary code; for example, the GNU General Public License prohibits this.)
The final case is where the third-party supplier is willing to release their own source code. In the longer term, if the open-source movement proves successful, there may be technology suppliers willing to use it, especially if they come to believe that this is ultimately in their interest by providing them with new ways to make money as well. This should be a major focus of the open-source movement as a whole, because (among other things) outside developers adding features to open-source products could in turn become technology suppliers to the vendors of those products, and to encourage this those vendors should work to ensure that their suppliers would share in some way in the overall rewards of the business.
Bugs and security flaws you need worry less about; if you don't know about them already (and can fix them prior to open-source release) then they will sooner or later be found (and possibly fixed) by developers outside your company. This is by no means a bad thing; rather it's one of the claimed benefits of open source and such investigation and bug fixing should only be encouraged. As for embarrassing comments and the like, these can and should be removed during the work to prepare the source for initial release; you will need to do such "sanitization" work for every source file to be released, with someone assigned to review and if necessary modify each file. (This need not be a single person; rather for each file it should be the person or persons most responsible for the source code in that file.) This sanitization review serves other purposes as well, since (as discussed elsewhere) you will also need to identify source code licensed from third parties, source code affected by export control or other regulations, and source code not intended for release for other reasons.
However you still need to address the sanitization issue for new code developed later. The most straightforward approach to address the issue of public releasability in the long-term is probably to have developers understand that they are "writing for publication" and that each and every line of their code will likely be viewed both by customers and (even more important) by their peers in the developer community. Within the context of an open-source code strategy you can no longer treat source code as an internal-only matter, but will have to exercise just as much care as you (ideally should) exercise with released binaries and documentation. This might require extra editing steps and code reviews, greater adherence to consistent formatting conventions (at least within particular sets of modules), inclusion of proper licensing notices, and related actions; the immediate responsibility for ensuring this happens rests with the module owners (whether they are employed by you or not).
So far I've assumed that you would have compete discretion over whether you wished to release your own source code or not, as well as over how much of that source you would choose to release. However there is one key area, namely security-related and cryptographic code, where you are and will almost certainly continue to be constrained in major ways regarding distribution of binary and source code; given activity in the US Congress and Administration over the past year or two, it is even possible that those constraints will become even more restrictive in the future than they are today. It's therefore useful to review how much freedom of action you are likely to have in this area, and how that might affect your open-source distribution strategy.
Under the current regulatory regime, US companies and individuals are prohibited from exporting from the US (except to Canada) software that implements strong encryption (e.g., using greater than a 40-bit symmetric encryption key). Thus at a minimum you would be prohibited from exporting source code that implemented such cryptography. (However you could distribute such source code within the US and Canada, at least for the present, as long as you take appropriate precautions and implement appropriate controls in your software distribution mechanisms to comply with the relevant regulations.)
However the restrictions are actually more onerous than that. The US government has traditionally refused to permit the export of products in which the supplied weak cryptography could be easily replaced with strong cryptographic implementations developed outside the US. For example, the source code for the S/MIME Freeware Library (SFL) is considered to be an export-controlled item with controlled distribution, even though the source does not actually include any cryptographic code. It's therefore reasonable to conclude that even under the current regulatory regime you will not be able to export source code to security libraries implementing functions such as S/MIME, SSL, PKCS#7, IPSec, etc., and will also be required to remove from the released source code calls to routines in such libraries.
Finally, it's possible that the US government may decide to impose further restrictions in the future as part of attempts to regulate domestic use of cryptography within the US. For example, it may be that US software vendors will be prohibited in the future from shipping any product with encryption functionality unless it implements a key escrow scheme of some type. Assuming that the escrow scheme is enforced by your security library or libraries, you may be prohibited from distributing such security-related source code even within the US and Canada, on the grounds that others (within the US or not) could easily create a derivative work that disabled key escrow.
The ultimate question is where the U.S. government will "draw the line" in terms of attempting to exercise control over the use of cryptography by imposing restrictions on commercial software vendors and noncommercial developers. Given that US software vendors and developers have only limited influence over the future of cryptography regulations, if you decide to pursue a open-source strategy then the best that you can do is simply to distribute your security-related source code to the maximum extent permitted by relevant laws and regulations both in the US and worldwide. For a real-life example of the complications inherent in doing so, see the Mozilla Crypto FAQ.
At first glance this would seem to be impossible. However there is at least one example of a successful project involving distributed and relatively loosely-coordinated development of software products arguably at least as complex and functional as any commercial products, namely the project to create the Linux operating system kernel and the body of free software that runs on top of it. The Linux project offers many lessons on how you might potentially organize software development in the context of an open-source strategy. These are discussed at greater length in the paper "The Cathedral and the Bazaar" by Eric Raymond, but some key points can be summarized here as follows, together with implications for you should you wish to pursue such a strategy:
Further material and inspiration for the current paper came from the public discussions on the Mozilla Public License and Netscape Public License, from the material created by Eric Raymond, Bruce Perens, and other for the OpenSource.Org web site, and from articles, editorials, and user discussions on the slashdot.org web site.
Finally, full credit must be given to two groups of people at Netscape: to the executive management team (Jim Barksdale, Marc Andreessen, Eric Hahn, Mike Homer, etc.) that committed Netscape to an open-source strategy, and especially to those in the Netscape client engineering group and elsewhere who worked long hours to implement that strategy and succeeded in making their 31 March 1998 deadline for source code release, creating an innovative pair of licenses in the MozPL and NPL, and putting mozilla.org and Mozilla source development on a firm footing for the future; all the theorizing in the world would have been fruitless without their efforts.