Chapter 5. Money and Business

Table of Contents

Types of Corporate Involvement
Hire for the Long Term
Case study
Appear as Many, Not as One
Be Open About Your Motivations
Money Can't Buy You Love
Review and Acceptance of Changes
Case study: the CVS password-authentication protocol
Funding Non-Programming Activities
Quality Assurance (i.e., Professional Testing)
Legal Advice and Protection
Documentation and Usability
Funding User Experience (UX) Work
Providing Hosting/Bandwidth
Providing Build Farms and Development Servers
Sponsoring Conferences, Hackathons, and other Developer Meetings
Open Source and Freedom from Vendor Lock-In
Remember That You Are Being Watched
Case study: You can't fake activity, so don't try
Don't Bash Competing Open Source Products
Don't Bash Competing Vendors' Developers
"Commercial" vs "Proprietary"
Open Source and the Organization
Review Your RFI, RFP and Contract Language
Get the Lawyers Involved Very Early or Very Late
Dispel Myths Within Your Organization
Foster Pools of Expertise in Multiple Places
Decouple Publicity Events from Project Progress
Establish Contact Early with Relevant External Communities
Have a Plan to Handle Negative Reactions
The Key Role of Middle Management
Governments and Open Source
Being Open Source From Day One is Especially Important for Government Projects
Hiring Open Source Developers
Crowdfunding and Bounties

This chapter examines how to use money constructively in a free software environment, and some of the adjustments your organization might want to consider as it gets involved in free software projects. This chapter is aimed not only at developers who are paid to work on open source projects, but also at their managers (and even on up to the executives), who need to understand the social dynamics of the development environment and the effects money and commerce can have there.

Sometimes people are surprised to learn that most free software is written by paid developers, not by volunteers. But when you think about it, it makes sense: a company often needs a particular piece of software to exist, and to be maintained and developed, and yet does not need a monopoly on that software. Lots of companies have web sites and therefore need a web server; far fewer companies need exclusive control over the development of their web server, or need to sell it on a proprietary basis. The same is true of office software suites, operating system kernels, network connectivity tools, educational programs, etc — just as historically it has been true of electric grids, roads, sewer systems, and other goods that everyone needs but no one needs to own. Just as we expect road workers to be paid, we should expect software developers to be paid as well.

Even in the early days of free software, although the proportion of truly unpaid volunteers was certainly higher, there were also paid developers — and a good deal of informal subsidy as well, as there continues to be today. When a system administrator writes a network analysis tool to help her do her job, then posts it online and gets bug fixes and feature contributions from other system administrators, what's happened is that an unofficial consortium has been formed. The consortium's funding comes from the sysadmins' salaries, and its office space and network bandwidth are donated, albeit unknowingly, by the organizations they work for. Those organizations benefited from the investment, of course, although they may not be institutionally aware of it at first.

Today these efforts tend to be more formalized. Corporations have become conscious of the benefits of open source software, and now involve themselves directly in its development. Developers too have come to expect that really important projects will attract funding in one way or another. The question is just how the hierarchical command structures of corporations and the semi-decentralized, non-coercive communities of free software projects can work productively with each other — and more or less agree on what "productively" means.

Financial backing is generally welcomed by open source development communities. Paid developers mean that bug reports are more likely to be listened to, that needed work is more likely to get done, and that the project will be less vulnerable to the Forces of Chaos (e.g., a key founding developer suddenly losing interest). After all, credibility is contagious, to a point. When, for example, Google backs an open source project, people assume the project will have the chance to succeed or fail on its merits, with adequate support in its early stages; their resultant willingness to devote effort to it can then make this a self-fulfilling prophecy.

However, funding can also bring a perception of control. If not handled carefully, money can divide a project into in-group and out-group developers. If developers who aren't officially paid to work on the project get the feeling that design decisions or feature additions are simply available to the highest bidder, they'll head off to a project that seems more like a meritocracy and less like unpaid labor for someone else's benefit. They may never complain overtly on the mailing lists. Instead, there will simply be less and less noise from external sources, as the volunteers gradually stop trying to be taken seriously. The buzz of small-scale activity will continue, in the form of bug reports and occasional small fixes. But there won't be any large code contributions or outside participation in design discussions. People sense what's expected of them, and live up (or down) to those expectations.

Although money needs to be used carefully, that doesn't mean it can't buy influence. It most certainly can. The trick is that it can't buy influence directly. In a straightforward commercial transaction, you trade money for what you want. If you need a feature added, you sign a contract, pay for it, and (if all goes well) the work gets done and the feature eventually lands in the product. In an open source project, it's not so simple. You may sign a contract with some developers, but they'd be fooling themselves—and you—if they guaranteed that the work you paid for would be accepted by the development community simply because you paid for it. The work can only be accepted on its own merits and on how it fits into the community's vision for the software. You may have some say in that vision, but you won't be the only voice.

So money can't purchase influence, but it can purchase things that lead to influence. The most obvious example is programmers. If you hire good programmers, and they stick around long enough to get experience with the software and credibility in the community, then they can influence the project by the same means as any other member. They will have a vote, or if there are many of them, they will have a voting bloc. If they are respected in the project, they will have influence beyond just their votes. There is no need for paid developers to disguise their motives, either. After all, everyone who wants a change made to the software wants it for a reason. Your company's reasons are no less legitimate than anyone else's. It's just that the weight given to your company's goals will be determined by its representatives' status in the project, not by your company's size, budget, or business plan.[44]

This chapter is not about how to find funding sources for your open source project, though it may usefully inform that topic. There are many ways open source projects are funded [45], just as there are many ways all human endeavors are funded. While open source is not compatible with one particular business model — monopoly-based royalty streams based on per-copy sales revenue — it is compatible with many others, and indeed is better suited to some of them than proprietary software is.

Types of Corporate Involvement

There are many different reasons open source projects get corporate support. This list is just a high-level survey. The items in it 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 might seem most intuitive for nonprofits, it often makes strategic sense even for for-profit competitors.

Augmenting services

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.

Creating an ecosystem

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. A good example of this kind of investment, as of this writing in 2014, is the project.

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.


Having your company associated with a popular open source application can be simply good brand management.

Proprietary relicensing

Proprietary relicensing 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 the section called “Proprietary Relicensing” in Chapter 9, Legal Matters: Licenses, Copyrights, Trademarks and Patents). 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 "pure open source play" (as we say in business-speak), 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 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 widely-used project can sometimes get significant contributions, from both individuals and organizations, just by soliciting donations, or by doing an organized crowdfunding campaign. See the section called “Crowdfunding and Bounties” for a detailed discussion of this approach.

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

[44] When companies need to guarantee that certain features and bug fixes land in a specified amount of time, they accomplish this by keeping their own copy (which may be partially or wholly public) of the project, and merging it from time to time with a separate public copy that has its own governance. Google's Android operating system is a classic example: Google maintains its own copy of Android, which it governs pleases, and from time to time merges changes between that copy and the Android Open Source Project. Essentially, Google is on a very long copy-modify-merge loop with respect to the open source project, or perhaps it's the other way around. In any case, it is in neither side's interests to permanently diverge from the other.