Chapter 5. Organizations and Money: Businesses, Non-Profits, and Governments

Table of Contents

The Economics of Open Source
Goals of Corporate Involvement
Governments and Open Source
Being Open Source From Day One is Especially Important for Government Projects
Hire for the Long Term
Case study
Appear as Many, Not as One
Be Open About Your Motivations
Money Can't Buy You Love
Hiring From Within the Community
Hiring From Outside The Community
Contracting and Transparency
Review and Acceptance of Changes
Case Study: the CVS Password-Authentication Protocol
Update Your RFI, RFP and Contract Language
Open Source Quality Assurance (OSQA)
Don't Surprise Your Lawyers
Funding Non-Programming Activities
Technical Quality Assurance (i.e., Professional Testing)
Legal Advice and Protection
Documentation and Usability
Funding User Experience (UX) Work
Providing Build Farms and Development Servers
Running Security Audits
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 It, So Don't Try
Don't Bash Competing Vendors' Efforts
"Commercial" vs "Proprietary"
Open Source and the Organization
Dispel Myths Within Your Organization
Foster Pools of Expertise in Multiple Places
Establish Contact Early With Relevant Communities
Don't Let Publicity Events Drive Project Schedule
The Key Role of Middle Management
Hiring Open Source Developers
Hiring for Influence
Evaluating Open Source Projects
Crowdfunding and Bounties

This chapter examines how to use money and organizational capacity constructively in a free software environment. It also discusses some of the adjustments an organization may need to make as it gets involved in free software projects.

When an organization makes an investment in open source, people at all levels have to understand not just how best to structure that investment, but the effects that long-term open source engagement will have on the organization itself. Open source can be transformative — at least when done right. Thus, while the material here should be useful for developers who are paid to work on open source projects, it's really meant for managers and for executives making strategic decisions.

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

The Economics of Open Source

People are still sometimes surprised to learn that most free software is written by paid developers, not by volunteers. But the economics that drive open source are actually quite straightforward: a company needs a particular piece of software to be maintained and developed, and does not need monopoly control of that software. Indeed, it would often be disadvantageous to have a monopoly, because then the entire burden of maintenance would fall on that one company, instead of being shared with others who have the same needs. For example, most companies have web sites and therefore need a web server, but almost no companies need exclusive control over the development of their web server, or intend to sell copies of 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 also 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, when the proportion of truly unpaid volunteers was probably higher[67] than it is now, there were already developers who were paid for their work. There was also a lot of informal subsidy, 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; its office space and network bandwidth are donated, albeit unknowingly, by the organizations those people work for. Those organizations also benefit from the investment, of course, though they may or may not be institutionally aware of it.

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

Financial backing is generally welcomed by open source development communities. Having 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 developer suddenly losing interest) that lurk at the edges of every collaborative endeavor. One important dynamic is that credibility is contagious, to a point. When a large company visibly backs an open source project, people assume the project will receive adequate support in its early stages and have the chance to succeed or fail on its long-term merits; other participants' resultant willingness to invest in the project can then make this a self-fulfilling prophecy.

However, money can also bring a perception of control. If not handled carefully, this 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 impression that design decisions or feature additions are simply available to the highest bidder, they'll leave for 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 sources outside the main funded group, as the "out" developers gradually stop trying to be taken seriously. The buzz of small-scale contribution may continue, in the form of bug reports and occasional small fixes. But there will be fewer and fewer large code contributions from unexpected sources, fewer unexpected opinions offered in design discussions, fewer bug reports that reveal unexpected new uses of the software, and so on. People sense what's expected of them, and live up (or down) to those expectations.

So money needs to be used carefully, and without communicating an intent to control. But it can still buy influence. The trick is that it doesn't buy influence directly. Instead, it buys development credibility, which is convertible to influence through the project's decision-making processes.[68]

In a straightforward commercial transaction, you trade money for what you want, because your counterparty has enough control to guarantee the delivery of the goods. 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, the process is more complex. 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 based on its own merits and on how it fits into the community's vision for the software (see the section called “Contracting” and the section called “Hiring Open Source Developers”). You may have some say in that vision, but you won't be the only voice.

But although money can't purchase influence directly in an open source project, 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 block[69]. 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.[70]

[67] This is an educated guess — I'm not aware of any rigorous research into the question. I do know from personal experience and anecdotal evidence that at least some paid open source work was happening early on.

[68] The report Open Source Archetypes: A Framework For Purposeful Open Source (, as mentioned earlier in Chapter 1, Introduction, may be worth a look if you're trying to understand the ways in which a project should be subject to influence and by whom.

[69] Even though actual votes may be rare, as noted in the section called “Consensus-based Democracy”, the possibility of a vote has great implicit power, so membership in the electorate is still important even if no vote is ever held.

[70] 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 as it 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, and vice versa. It is in neither side's interests to permanently diverge from the other.