WordPress » 2007 » 四月 imag1
 
 
你正在浏览四月, 2007
Money or nothing? Trade-offs in FOSS compensation

Friday March 02, 2007
By: 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.”

A dozen tips for testing free software

Tuesday March 13, 2007
By: Joe Barr

When I first began programming in the 1960s, testing was done to prove that code worked. The first big change to that approach came with IBM’s Black Team, which took the opposite tack and tried to break the code — an approach that was radical at the time. In the next popular phase, the color of testing changed, and white box testing, in which you know what a program is supposed to do and check that it does it, was all the vogue.

Those approaches come from the world of closed source, proprietary software. Testing in the FOSS world is different. For one thing, bug reports can come from anywhere, not just from a team assigned to test the product. The transparency of the code invites everyone to explore.

Former Debian Project Leader Martin Michlmayr advises, “If you want to test something, run the latest version. This may sound obvious but apparently it’s not. If you run Debian, upgrade to unstable and maybe pull in some packages from experimental. For other software, try the latest version from the project’s version control system and see what breakage you can find.

“You have to be creative, and you have to be quick. You’d be amazed how many bug reports we get for issues that have already been fixed. It’s therefore important to run the latest version and to check for bugs in the bug tracker. If you cannot run the latest version all the time, at least try to verify whether the issue you see still applies to the latest release.

“Regarding the bit about being creative: we get a lot of bug reports in Debian and really appreciate them. But there are many issues that many people find, and that can be found easily. What really helps is if someone is creative about finding things, or maybe just very patient. You don’t necessarily need to read source code, although this may be a good exercise for someone trying to learn how to code. Someone could also take the manual or man page of a program and compare it with the actual behaviour — I bet there are plenty of examples where the docs are out of date.

“Try to do unusual stuff with the software or test it in unusual environments, such as especially slow hardware or uncommon platforms.”

In addition to Michlmayr, I got tips from GNOME bug master Luis Villa, Debian bug-finder extraordinaire Dan Jacobson, and Dave Freese, author of several ham radio applications for Linux. They came up with these tips for better testing:

* Run the latest version of the software you’re testing
* Check for duplicates before filing a bug report
* Include enough information in your report so the issue can be reproduced
* Don’t apologize for your language
* Use a bug tracking system of some sort
* If possible, write automated unit tests
* If possible, use the code you’re testing under real-life conditions
* Use automated crash reporting tools
* Become familiar with the tools that will be used to compile, link, and test the code
* If possible, maintain a separate environment for testing
* Keep a few back revisions of the code to track when errors appear
* Describe as completely as possible the conditions leading up to a fault
* Your “newbie impressions” are critical — report everything you see
* Be patient with developers

Michlmayr also suggests several pages for additional reading:

How to Report Bugs Effectively
Bug Writing Guidelines
How to Write a Useful Bug Report
Lessons from GNOME Project QA

Testing is a great way for non-programmers and even non-geeks to contribute to the greater good. Get involved with your favorite free software projects and send them a bug report or two.