Ain’t it the truth?
You can’t twist someone’s words, then call those words harsh.
Speaking as the lead developer on one open-source project and a developer on another, I can say that, at least from those two projects, it’s not a ìfuck youî.
I ask you to look at the situation from the side of the project’s maintainer. When we say ìpatches welcomeî, we say it because your feature or bug is not more important to us than any of the features we already had on the slate or any of the bugs we want or need to fix.
There’s a ratio at work here. On one side is the benefit we’d get from the feature. On the other side is how hard the feature is to implement.
We only have so much work in us in a day, and we’re going to spend it on the things that give us the most benefit. It’s simple self-interest. It’s not a slap at you; it’s just us trying to make ourselves happy with our limited time. Anything we do for others is a combination of generosity and hobby.
Thus, getting your feature higher on our priority list requires changing the ratioóeither making it less work for us to add, or increasing its benefit to us.
There are two parts to the benefit: its direct benefit to us (what we get from using it, which is zero if we won’t use it), and the indirect benefit of satisfying however many people want the feature.
Increasing the benefit is really hard. You basically can’t change how useful we personally would find it, so all you can do is is boost its popularityóthat is, get other users to second your request. But we balance the popularity of a request against how much work it’d be to do, so even an extremely-popular request may still go on the back burner (such as voice/video chat in Adiumóextremely popular, but extremely hard).
That leaves the first way. If you write it yourself, our work to add the feature consists of reviewing and adding the patch. For large features, that’s a significant drop, and can make the difference between ìmay happen somedayî and ìwill be in the next versionî.
So ìpatches welcomeî is not ìfuck youî. It’s ìwe have limited time and other features planned that we consider a better trade for our time than this oneî. There’s only one way to change that: You can’t give us more time in a day, and you probably can’t increase the feature’s benefit to us (not much, anyway), so all you can do is reduce how much time we’d have to trade away, which you would do by writing the feature yourself.
Also, all of the above applies to bug fixes as well: A very minor bug, especially if it requires a lot of work (or even a systemic redesign) to fix, may go unfixed for several versions. A patch could change the work/benefit ratio enough to move it up the slate.
I think paying a programmer to implement a feature in an open source program is a sound proposition. dman’s story above demonstrates how effective this can be. The problems of accountability and how to handle the transaction are standard problems as long as there is one entity with the money and one entity taking the money. All of the problems are solved via the normal feedback loops. Programmer sucks? Don’t hire again or other. Programmer doesn’t have enough cred with people in charge of the program to get implemented feature merged? Don’t hire again. This is all pretty simple capitalism, as mentioned by another commenter.
Combining bounties seems to be where problems will come up. If a bunch of people put money together who decides which programmer does the work? Who decides when implementation is done. etc.
I think despite these problems there are some cases where this makes sense. If a bug has a very clear/simple way to determine successful completion and there is a definite class of developers in the project that have authority to take on a bounty project this can work. A project would have to define this class of developers so that if someone took a bounty project it would be completed successfully. Different project teams would get a reputation of delivering on bounty projects or not.
This is something I proposed a while back on how to deal with piracy.
Imagine a world with no copyright law at all. How could the developers make a living to continue doing what they do? Simple - have a middleman take user money up front and use it to fund development. Perhaps let the users vote on stuff based on money paid.
I thought it was quite elegant, but most the other people debating me disagreed, thinking the results would come too slowly to get your average person interested and judging whether the result was actually given would be a pain in the ass to actually implement for contract enforcement. I don’t know about the latter, but the former sounds like a real concern.
The big problem with sponsoring for specific features in OSS is that even if you pay a developer to code a new feature, there’s no guarantee that it will be accepted and incorporated into the code base, even if it is a useful or needed feature. It takes more than just submitting code to get a feature added to an OSS project. I could see paying someone to write bug fixes, but new features are a different thing.
The companies like IBM that pay their employees to work on OSS aren’t just paying them to develop specific features, they are paying them to join the community around a particular OSS project and influence the development. There’s no direct ROI (in terms of features) for the company.
@Glyph, I think you’re taking offense too quickly.
Keep in mind, for all projects, including yours, the people who have the capacity and time to program are in a minor percentage compared to users. There are different levels of programmer and experience. In your case it might be so specialized you can expect your core audience to be coders, but somebody who asks for a feature in an editor, a game, an application, etc, just want to provide feedback.
To the people who can’t program or those that can but aren’t the low-level C++ hard core junkies, saying code it yourself does appear rude, ESPECIALLY if the person can’t program themselves. When I see people parroting this phrase on Slashdot, etc., it makes me feel hostile towards the whole Open Source movement, because it seems to encourage the stereotypical bad behavior of geeks being intolerant of those unlike them.
Sounds like nice way to get expensive pile of sh^H^H featuresÖ
Why doesn’t everybody that need enhancement to some software and can’t/won’t code them put up a request on elance.com guru.com and other freelance sites? I agree that it’s not easy for anybody to dive into a repo that you’ve never seed but if the original devs are not available for this kind of work, that’s the only way it can happen.
L.
Just yesterday i’ve found a few such requests for work on http://www.otrade.com
So some people do think along the lines of spending money to get a certain feature implemented in an open source project (or just the modifyable part of, say, an MMO).
This idea strikes me as similar to Giles Bowkett’s thoughts on patronage:
http://gilesbowkett.blogspot.com/2008/05/never-hate-only-ever-destroy.html
AOL’s funding helped accelerate release of SQLite 3 by 9-10 months. I don’t see why OSS developers should refuse sponsorship as long as the sponsors don’t force them to change licensing.
Combining bounties should be OK as long as there is one person for that feature/bugfix who is in control of all the combined bounties - ie one person that decides when the code is satisfactory and releases the bounty. If each payer has to decide independently, then the co-ordination costs will be excessive.
Here’s a proposal. This is intended for big FOSS projects with lots of developers, various levels of access to the source code tree, formal bug-tracking systems, and clear release schedules; it should be simplified (a lot) for simpler projects. My mental model projects were Firefox and OpenOffice.org.
-
OSS projects have to sign up for the system; if the maintainers won’t sign on, then you can’t put up a bounty (of course, you can get a new maintainer and fork the project).
-
The bounty system needs to be integrated with the existing bug tracking/feature request system so that the bounties can be attached to a bug. Yes, that’s a feature request; once it’s been implemented in one bug tracker, the maintainers have the choice of moving to a bug tracker that supports it or getting it implemented in the one they use.
-
Having logged a bug/feature request and got it accepted by the maintainers (ie set to ACCEPTED, not WILLNOTFIX or BYDESIGN), the requester then offers a bounty on the bug. This makes that person the controller of that bounty. Only they can accept that a particular patch resolves that issue sufficiently to release the bounty. They have to pay the money into an escrow account at this point.
-
Other people can either add to the bounty that is already there, or create a new separate bounty on the same bug, depending on whether they want to let the existing controller make the decisions.
-
When a patch is there for the bug, there are multiple separate accept/decline decisions on the patch - one by the maintainers who decide whether or not to close the issue in the bug tracker and one by each bounty controller, deciding whether to release the bounty from escrow.
-
If the maintainers accept a fix and the bounty controller doesn’t, then there are two options:
6.1 The maintainers accept that there is more to the issue and the bounty is transferred to another bug (which represents part 2) - the controller may release part of the bounty given that the issue is partially resolved.
6.2 The maintainers now regard the remaining request as a WILLNOTFIX or BYDESIGN issue, in which case either the project forks, or the bounty goes into dispute.
Some reasonable third-party, determined in advance, will have to resolve disputes when they occur, determining what happens. They will not have the option of imposing changes on the maintainers; if you don’t accept the maintainers’ decisions, then your only option is to fork and get new maintainers.
The arbitrator could decide that the implementation was reasonable, the bounty payer is being unreasonable and release the money from escrow, could decide that it’s partially OK and pay a fraction to the developer and a fraction to the bounty payer, or could decide that the implementation is not acceptable and revert the money to the original payers. Note that if there’s an acceptable fork, the payer can shift their money into the fork.
This means that everyone accepts binding arbitration at the start. The project (ie the maintainers) should provide a list of acceptable arbitrators that the bounty payers choose between at the time they put up the bounty. They should also provide a list of acceptable escrow agents.
How does that sound? I could work with that for openoffice.org - and I already have a feature that I could probably get my employer to put a few $K up for in there if there was a sensible mechanism (and I suspect with a few phone calls I could get something really significant sitting in an account - it’s the killer feature for my vertical switching from MS Office and the licensing saving is, vertical-wide, huge).
Also, if this was a standard feature of BugZilla/IssueZilla and of SourceForge’s bug tracker, then it would be easy to tack-on to existing projects, even pretty small ones.
All the coordination issues aside, I think there’s a fundamental reason why this won’t work for most OSS projects. Most laypeople have no idea how much their feature idea would actually cost in fair-market-value developer time. We’ve all seen those ohloh.net calculators of the value of various open-source projects, and for any non-trivial project the numbers are staggering. Boost, for example is computed at 4,144 man-years at a cost of $225 million (!!!) dollars. The only rational reason for people to invest that much effort is because they gain personal value from working on things which interest them. Those economics wither when they start taking orders from others rather than following their own muse, so that leaves fair-market compensation. But it’s hard to imagine anybody but well-funded companies being willing or able to afford the cost of a significant custom feature.
Why isn’t there a service to aggregate and pool funds to sponsor programming particular features or bugfixes in open source software?
There is: http://gnuherds.org/pledges
And many others.
KJB
Those economics wither when they start taking orders from others rather than following their own muse, so that leaves fair-market compensation.
The economics are different, but not withered.
(For me anyway) I take into account my own interest in the project or feature and usually offer a hefty mark-down for code that’s going back into the OSS pool, and shave my hours on ‘interesting’ projects.
As an existing contributor/maintainer (not a gun-for-hire) I’d probably be spending that spare time doing something pretty similar anyway, so the money is just a (very) nice way of directing my attention to real tasks.
There is a large zone where muse and lucre overlap. I like living there.
My company has used another example of how to pay for changes to an OSS application. A particular Apache project we use has a company which provides a commercial distribution and support contracts, and so obviously has a number of committers to the project on staff. We had a support contract with them already, and then paid extra for a number of specific fixes we needed to the OSS codebase itself. These were issues that were not a high priority for most users, but were for us because we’re using the application in an uncommon manner.
With the Apache model, the risk of polluting the OSS codebase with stupid changes is minimized, because changes are voted on by all of the committers. There is some danger where a commercial company employs a large proportion of the committers, but it’s still going to be in that company’s best interests to keep the quality high.
Have you tried to get into some of these C++ open source projects. You spend over 8 hours trying to configure the environment just so, so that it will compile once. Then you add what is a 5-minute fix.
The problem with most Open Source projects is that they are missing the equivalent of VS projects. If I could load up a project and do a 5-minute fix actually in 1 hour or less, I would be more inclined to do it.
But when it takes hours just to build the environment, it takes all the fun out of it.