| There are many different reasons open source projects get funded. The items in this list aren't mutually exclusive; often a project's financial backing will result from several, or even all, of these motivations:
Sharing the burden -
Separate organizations with related software needs often find themselves duplicating effort, either by redundantly writing similar code in-house, or by purchasing similar products from proprietary vendors. When they realize what's going on, the organizations may pool their resources and create (or join) an open source project tailored to their needs. The advantages are obvious: the costs of development are divided, but the benefits accrue to all. Although this scenario seems most intuitive for non-profits, it can make strategic sense for even for-profit competitors. Examples: http://www.openadapter.org/, http://www.koha.org/
Augmenting services -
When a company sells services that depend on, or are made more attractive by, particular open source programs, it is naturally in that company's interests to ensure those programs are actively maintained. Example: CollabNet's (http://www.collab.net/) support of http://subversion.tigris.org/ (disclaimer: that's my day job, but it's also a perfect example of this model).
Supporting hardware sales -
The value of computers and computer components is directly related to the amount of software available for them. Hardware vendors not just whole-machine vendors, but also makers of peripheral devices and microchips have found that having high-quality free software to run on their hardware is important to customers.
Undermining a competitor -
Sometimes companies support a particular open source project as a means of undermining a competitor's product, which may or may not be open source itself. Eating away at a competitor's market share is usually not the sole reason for getting involved with an open source project, but it can be a factor. Example: http://www.openoffice.org/ (no, this isn't the only reason OpenOffice exists, but the software is at least partly a response to Microsoft Office).
Marketing -
Having your company associated with a popular open source application can be simply good brand management.
Dual licensing -
Dual licensing is the practice of offering software under a traditional proprietary license for customers who want to resell it as part of a proprietary application of their own, and simultaneously under a free license for those willing to use it under open source terms (see Section 9.6 in Chapter 9). If the open source developer community is active, the software gets the benefits of wide-area debugging and development, yet the company still gets a royalty stream to support some full-time programmers. Two well-known examples are MySQL (http://www.mysql.com/), makers of the database software of the same name, and Sleepycat (http://www.sleepycat.com/), which offers distributions and support for the Berkeley Database. It's no coincidence that they're both database companies. Database software tends to be integrated into applications rather than marketed directly to users, so it's very well suited to the dual-licensing model.
Donations -
A widely used project can sometimes get significant contributions, from both individuals and organizations, just by having an online donation button, or sometimes by selling branded merchandise such as coffee mugs, T-shirts, mousepads, etc. A word of caution: if your project accepts donations, plan out how the money will be used before it comes in, and state the plans on the project's web site. Discussions about how to allocate money tend to go a lot more smoothly when held before there's actual money to spend; and anyway, if there are significant disagreements, it's better to find that out while it's still academic.
A funder's business model is not the only factor in how it relates to an open source community. The historical relationship between the two also matters: did the company start the project, or is it joining an existing development effort? In both cases, the funder will have to earn credibility, but, not surprisingly, there's a bit more earning to be done in the latter case. The organization needs to have clear goals with respect to the project. Is the company trying to keep a position of leadership, or simply trying to be one voice in the community, to guide but not necessarily govern the project's direction? Or does it just want to have a couple of committers around, able to fix customers' bugs and get the changes into the public distribution without any fuss? Keep these questions in mind as you read the guidelines that follow. They are meant to apply to any sort of organizational involvement in a free software project, but every project is a human environment, and therefore no two are exactly alike. To some degree, you will always have to play by ear, but following these principles will increase the likelihood of things turning out the way you want. |
