There are many different reasons open source projects get corporate support. The list below is just a high-level survey, and the items in it aren't mutually exclusive — often a project's financial backing will result from several, or even all, of these motivations:
Separate organizations with related needs often find themselves duplicating effort, either by redundantly writing similar code in-house or by purchasing similar products from proprietary vendors. As the inefficiency becomes apparent to the different parties, they may pool their resources — often gradually, without at first realizing the overall trajectory of the process — and create or join an open source project tailored to their needs. The advantages of doing so are obvious: the costs of development are divided, but the benefits accrue to all. Although this scenario might seem most intuitive for nonprofits, in practice it happens often among for-profit competitors too.
When a company sells services which 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.
Often a corporation has strategic reasons to establish a technical standard. Releasing an open source implementation of that standard, and shepherding the software into widespread use, is usually the most effective way to get buy-in from others for the standard.
For investors who like to think big, the right open source effort can create a new ecosystem — one in which those investors are more likely to flourish.
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.
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.
Having your company associated with a popular open source application can be good brand management, not just in the eyes of customers but in the eyes of potential employees.
Proprietary relicensing is the practice of offering software under a 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. 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.
Proprietary relicensing is controversial because it is not a open source" model, but rather yokes funding for open source development to a monopoly-based revenue stream. Whether this is a problem for you depends on where you fall on the "open source is just a way of software development" to "open source is a way of life" spectrum. The presence of revenue from a proprietary version does not necessarily mean that the free software version is worse off, and some very well-known and widely-used free software has had corresponding proprietary versions (MySQL[71] is probably the most famous example). However, some developers dislike the thought that their contributions may end up in the proprietary version. Also, the mere presence of the proprietary version suggests the possibility that some of the best salaried developers' attention is going to the proprietary code, not the open source code. This tends to undermine other developers' faith in the open source project, which in turn makes it difficult to develop a truly flourishing ecosystem around the open source version.
None of is meant to persuade you not to do proprietary relicensing. You should just be aware that this strategy is unlike the other business approaches I've listed here, that it requires more care and sophistication to manage successfully, and that it is usually incompatible with the presence of a committed and involved ecosystem of developers from outside your organization, particularly developers who might have their own commercial motivations.
A funder's business model is not the only factor in how that funder relates to an open source community. The historical relationship between the two also matters: did the company start the project, or did it join 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 it 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 maybe it just wants to have a couple of committers around, able to fix customers' bugs and get the changes into the public distribution without any fuss?
Keep the question of goals 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 the principles in this chapter will increase the likelihood of things turning out the way you want.