Author: Bruce Byfield
Payment, of course, is not new to FOSS communities. Companies such as IBM, Novell, Red Hat, and Sun Microsystems have employed developers to work on FOSS for years. However, the issue has received renewed attention in recent months because of the reaction to a project called Dunc-Tank within the Debian community. Dunc-Tank made headlines in the FOSS world when it proposed paying the two Debian release managers for one month each to speed up the distribution’s next release. Despite widespread opposition that included heated discussion, a parody site, and an unsuccessful attempt to impeach Anthony Towns, the Debian Project Leader and a member of Dunc-Tank, for conflict of interest, the proposal for funding went ahead.
The Debian community is still discussing Dunc-Tank, and the arguments on each side should be of interest to the greater FOSS community. To Dunc-Tank supporters, the issue is straightforward: give select members of the community reasonable but not excessive funding, and they can concentrate on their FOSS contributions full-time. To detractors, such payments seem a form of favoritism. Debian developer Joey Schultze, for example, states as a fact that Dunc-Tank “has demotivated a lot of people.” Others cite theoretical research by Luis Villa of GNOME that seems to indicate that payment reduces volunteers’ “sense of self-determination and self-esteem,” making them less likely to participate “because they want to help others, or because it is fun.”
For all the attention that this discussion has attracted, the trouble is that, despite the practical nature of Dunc-Tank, the looseness of its goals means that the discussion on both sides tends to be theoretical. For those with a broader picture of payment in FOSS project, the issues are more complex and context-dependent.
Bounties
One of the most frequently mentioned forms of payment is a bounty, or a reward posted for a specific programming task. In most cases, bounties are for small, specific pieces of work, and are usually worth only a few hundred dollars to those who claim them.
The leaders of projects contacted by Linux.com were unanimous in urging caution about bounties. Although none had a set policy against them, all had learned from experience to be cautious about them. Mostlly, their arguments were similar to those advanced by opponents of Dunc-Tank. Frank Hecker, executive director of the Mozilla Foundation, suggests that the problem with bounties is that they are too contrary to the spirit of volunteerism on the one hand, and not large enough to motivate people on the other. If you are given cash, particularly for development that you might do anyway, Hecker suggests, then the development “becomes work rather than something you’re volunteering to do.” In other words, it risks becoming an obligation rather than an interest, or something done out of a sense of enthusiasm and commitment.
Max Spevack, chair of the Fedora Board, agrees, adding that “It also feels kind of wrong to think about a self-contained piece of [a project] and assign it a value.” Often, doing so requires an executive decision, which again makes the development seem more like ordinary employment.
For such reasons, Hecker maintains that, of all forms of compensation, “Paying bounties is the least likely to succeed.”
This conclusion seems supported by the experience of the now-defunct Bounty Country site, which was briefly run by the developers of Democracy Player. Intended as a site where projects could post bounties, Bounty Country attracted few postings. Democracy Player itself managed to have one successful bounty, but several others were never completed. Nicolas Reville, a Democracy Player developer, suggests that the site might have been more successful as part of a news site or within a specific project, but its lack of success is consistent with the observation of others.
A related but lesser-known type of payment is the anti-bounty, in which developers seek sponsors for work they want to do. According to Boris Mann of Bryght, who has completed at least one successful anti-bounty within the Drupal community, anti-bounties avoid many of the problems of normal bounties. Because they are posted by developers, Mann says, anti-bounties tend to be more realistic about scope, requirements, and costs. More importantly, because a developer is already interested in a project for which he posts an anti-bounty, Mann suggests that payment is less likely to destroy motivation or morale within a project, and more likely to result in a higher rate of completion than ordinary bounties. However, the concept does not appear widespread enough to draw definite conclusions from.
Payment in kind
A second compensation option is payment in kind, which consists of donations from a project to help key contributors advance their work, such as hardware or trips to conferences.
Leaders of large FOSS projects sound as enthusiastic about payment in kind as they are wary of bounties. The difference, Hecker says, is the difference between buying someone a $500 hard drive and giving them $500 cash. “It’s like a gift,” Hecker says. “If you give somebody a birthday gift that’s cash rather than giving them something they can actually use, it’s typically seen as a little more impersonal.” In the context of a FOSS project, payment in kind is also a way of singling someone out — of giving the recipient credit for work already done while enabling him to improve his contribution. In short, it fits into the FOSS culture in a way that cash does not.
Spevack, who explains that Fedora often funds contributors’ expenses to attend conferences like FUDcon, says, “It seems a smarter investment of money because it helps people while also building the community. It seems more win-win [for both the project and the recipient] than just saying, ‘Here’s some money. Thank you.'”
Payment in kind does have the potential to cause resentment among those who do not receive it, but Spevack suggests that, given the meritocracy that prevails in most FOSS projects, it generally should not. “You could ask anyone in the community who the leaders are and everyone would give the same names,” he says. “So it doesn’t create any ill will.”
Just as importantly, because payment in kind is a gift that recognizes a significant contribution, it does not trigger any of the implications of employment, especially when it takes the form of sponsorship for a conference. Talking of the recent FUDcon, Spevack suggests that those whose way to the conference was paid “were energized and pumped up” by the experience of meeting their peers face to face and that “a lot of good work” was done at the conference.
Grants and employment
For Spevack, a different approach, that of grants or offers of employment, is simply a larger version of payment in kind. When Red Hat has open jobs, particularly ones that involve working with Fedora, “we fill them by hiring someone who has been part of the Fedora community,” Spevack says. “And to me that is a perfectly reasonable thing to do for a lot of reasons: they don’t need to get up to speed, they’re already there, and it’s a way to show that we appreciate the work that people in the community do. Things like buying people a ticket to FUDcon are a smaller example of that.”
Hecker points out that, in addition to being a reward for a volunteer’s contributions, grants or employment can also be a way of encouraging development in areas that are being overlooked. For example, the Mozilla Foundation has given grants to encourage the development of accessibility features in Firefox and Thunderbird.
“Unless you’re disabled yourself,” Hecker says, “You usually don’t think much about accessibility issues. So we don’t have a lot of volunteer contributors. What we consequently try to do is build a group of contributors who are already involved in Mozilla one way or the other and get them interested in accessibility by offering them grants.” In at least one or two cases, receiving a short-term grant to work on accessibility has encouraged volunteers to continue with the work after the grant runs out. Grants, Hecker says, “get people interested in work they wouldn’t otherwise be interested in, and they can justify it to themselves because they’re getting compensated for it.”
Choosing the type of payment
The key to introducing payment into FOSS projects, experts agree, is to consider the context. When Google receives funding requests, says Chris DiBona, open source program manager at Google, “Our response is always the same: What good will the money do? Show us how the money helps the project and why you are the one to execute the plan.”
“There isn’t one answer,” DiBona adds. “For every project, you have to consider if money can help at all.”
For Hecker, the important aspect is the motivation of individuals. Although he advises other projects to “avoid money for bug fixes” — a common type of bounty — he goes on to say that the appropriate form of payment depends on the recipient’s preferences. Using the Mozilla Foundation as a example, he says, “A lot of people who are Mozilla volunteers consciously decided that they like it better as a volunteer. They feel motivated as a volunteer, and they wouldn’t necessarily feel motivated as a full-time employee.” For such committed volunteers, payment in kind is likely to be the most appropriate choice if any sort of compensation is given. For others who are more career-minded, a grant or employment is probably a better choice.
“This idea that money automatically kills open source projects is not really true,” Hecker says. “Certain types of schemes can kill motivation, but I don’t think it’s the case in general that introducing money into open source projects in and of itself is going to cause problems. It’s all in the way that it’s handled and in the way that it’s structured.”
Bruce Byfield is a computer journalist who writes regularly for NewsForge, Linux.com, and IT Manager’s Journal.
