فصل 5. Money

This chapter examines how to use money constructively in a free software environment. It 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 how money affects them.

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 benefitted 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.^[38]