I think the latter. But it's not just the motivation either; as much as I hate to say this, it's the business people and managers and CEOs who actually know how to spend or invest money in order to improve productivity. Open source projects are run entirely by developers who, by and large, simply would have no clue what to do with the money.

I'm not trying to level criticism here; modern society runs on specialization. Money is just one commodity and by itself doesn't accomplish anything - you need an organizational structure and business plan to go with it. Open source projects have neither; thus, they're unlikely to benefit from any serious investment. And to the *credit* of the developers in charge, they are probably aware of this and that's one of the reasons they eschew sponsorship.

Bottom line - paying someone to perform their hobby does not make it a business.

I suspect something like this is behind a number of major open-source projects. A core team of developers from commercial interests with a common need or spying a services market are probably behind a number of highly visible ones, don't you think?

The financial incentives just aren't as direct as the scenario you describe.

Totally off topic, but I'm trying out Google Chrome and I like it a lot. However, the text on Coding Horror seems blocky and blurry now, and it's difficult to determine normal text from bold text without zooming in. Is this just the fault of the browser, or can I tweak it somehow?

Sounds good.

I'm glad to hear someone challenge the folks who say "The good thing about open source is you can always change it to do what you want." As you say, that's theoretically possible, but not very practical unless you have the skill and a lot of time on your hands. I sometimes cringe at the thought of having to modify code *I* wrote; I can't imagine it would be easier to download and modify a stranger's code.

There are sites to do exactly that. For example: http://fossfactory.org

I'm a little skeptical, but I've met the FOSS Factory guys and they're enthusiastic. (They're not totally altruistic, mind you, but they really do believe in this idea...).

They aren't saying "F**k you" they're saying "Help!" and they mean it. The people maintaining open source software frequently work for a living doing *something else* and don't have any more time to implement new features than you do.

I've also seen "maintainers" for software that are dedicated, but not very skilled... sometimes inheriting a dead or forked project.

Personally, I'd *love* to contribute to open source projects on my spare time, but my employment contract forbids it. :(

I've had an experience where the original owner of the program wanted a feature NOT to be included. I offered to do the programming, but he actively resisted the idea. :(

The first thing that sprung to mind when I read this was Amazon's Mechanical Turk. The second thing that sprung to mind was Stack Overflow.

*lightbulb*

I agree with Old Joe, that quite a lot of this happens by the corporation that wants to sponsor bugfixes (or features) in an open source code-base simply hiring someone to work on that code-base full-time. Apache is perhaps the best-known project where a lot of the code has been contributed in this fashion.

I think what you're proposing is a system that would allow for a contribution smaller than a full-time programmer's salary. It's a good idea; only large corporates and the occasional super-rich individual can afford six-figure annual contributions to anything.

I think it's a great idea; the fact you have already paid out to have some bugfixes prioritised suggests that the market is there. It would need to be run by someone that was very widely trusted - sourceforge, maybe?

There was a startup that wanted to create this escrow service - I think they were called MicroPledge. It didn't really work out that well I think.

http://micropledge.com/

This pretty much what companies do by allowing employees to work on open source projects. And on a larger extreme, examples like the NSA and open source project relating to security, Google employing Andrew Morton, so on and so forth.

As a side note, I once was annoyed by the fact that rsync didn't specify filesizes in human readable formats like other programs ls -h, du -h, df -h) so I rolled up my sleeves and tracked down that function through the libraries and was just set to add it in... when I found rsync does have the -h option. I just missed it in the man page.

Taking the time and trouble to learn an alien code base or contributing financially to a bug fix/feature are each just ways of demonstrating an "investment" in the requested bug fix/feature. When someone asks me to code something, one of the first things I do is evaluate just how much investment the person making the request has committed towards the request. If the person has taken the time to really think things through, taken the time to draw suggested screen layouts or taken the time to sell their idea to others, I am more inclined to tackle the project. If the person has obviously not taken any time to consider the details of their request, I do as you suggest and tell them to code it themselves. Yes, that is a "F**k you".

I know the chances of successfully completing even a minor bug fix is higher when I am not the only one committed and invested in the project.

why bother with money? You could just give SO users reputation points.

So would you consider this model for Stack Overflow? I know you use Uservoice to get feedback, but could monetary sponsorship beat the voting system?

Pooling money for features can result in a customer mindset, where people tend to get agitated if they feel they've paid for something that doesn't meet their expectations or desires.

I wouldn't be surprised to see people either demanding their money back or insisting it be counted in a separate "bucket" that specifies the feature be implemented in a specific way that suits their needs.

I guess there are ways around this, but still...it sounds like a recipe for strife.

I think this would work in theory, not in practice. People making random willy-nilly requests for features in FOSS would lead to low quality FOSS.

First - People are motivated for the quick buck, not writing quality software or "scratching that itch"

Second - It may go against the unix philosophy that much of this software was originally built upon. A major point of the unix philosophy is that one tool should do just one job really well. Imagine someone coming along and saying "I wish apache had a chat client, here is $$$ now go do it".

I feel like there is a third point but I cant quite come up with it right now...

sorry, i meant "people WOULD be motivated for the quick buck ... "

You may take a look at real example:
Crossover has this kind of system. For example, some users want to be able to run Access 2003 on Linux:
http://www.codeweavers.com/compatibility/browse/group/?app_id=150

But still, they have only such a few number of supported apps. Not more than 30.

Sounds like an additional business model for User Voice

It's like this Stallman and his freetards, the source code is freely available... yeah right!
The borders between what open source is and not have actually diminished a lot. And asp.net has a lot of open source I think!

Google is actually kinda doing that with the Summer of Code

So, years ago I was working on implementing a new MTA at my site. I needed a feature and I couldn't find it. I asked on the (normally incredibly helpful) list and got no responses. So I rolled up my sleeves and spent 2 days coding a patch. Like a good citizen I donated it back to the list for inclusion. At that point someone was nice enough to point out that I had implemented a feature that already existed, and my version sucked in comparison. *sigh*. I did learn a ton about the guts of that MTA though and contributed some actually-useful patches over the years.

The good thing about open source is not that I specifically can examine, audit, and change the source code. I don't have the expertise for kernel or device driver hacking, and no immediate desire to gain it. I don't want to have to absorb a large and complicated code base just to make a minor change.

The good thing is that anybody can, which means that, in the time-honored capitalist tradition, I should be able to hire somebody else to do it for me.

Finding somebody to do it may be the hard part. Some people work on open source for reasons that have nothing to do with money, and may not really be compatible with money. Some people may be paid for it, and may want to keep their spare time free. It's hard to know without asking.

I could see this making a lot of sense for software that's plug-in based, but I would *not* want every Tom, Dick and Harry's pet feature to pollute core software packages!

What a usability nightmare.

It's a lot more fun when you call it a "bounty" on the feature/enhancement/bugfix. I've seen the term used for this before, and it always makes me smile--brings new meaning to the phrase "killin' bugs".

Jeff, I hope you pay attention to zurvan2's comments. Normally I wouldn't rag on anything in your posts because I agree with most points (and to be correct, you could translate a request for help in that fashion in either way, as 'Help' or as 'F you!') but he does make a good point that should be considered. :)

I'm not convinced by this idea - simply because of the human element.
I would personally love to work in an open source environment, and be well paid for it, but I just can't see this working.

The problems are these:

1. Who decides when a feature is actually complete?

There's a great deal opportunity here to create problems on both sides - customer to not pay developers even after they put in a lot of hours, just because the requirements weren't clear, or for developers to insist on being paid for producing shoddy work.

This situation would require an ombudsman, who would that be? And how would *they* be paid?

2. Who gets how much money?

Dev1 takes a job and goes dark for months. Customer gives up and asks dev2 to take the job. Dev1 & dev2 produce similar but incompatible code at the same time. What about when dev1 & dev2 cooperate on a task.

3. Who decides what a feature actually is?

If 1000 customers pledge money for a feature, there's a good chance that they actually want 1000 subtly different features. How do you manage those 1000 ideas?

A related idea, 1000 customers each raise individual requests for their specific ideas. The amount of bounty available for each implementation is now 1000 times smaller than it otherwise would have been?

How to you herd the customers?

Basically, there's 2 parties (A & B) and 3 interactions (A-A, A-B, B-B), all of which are easy in the trivial case, but I fear they won't scale at all with human personalities involved.

The second best idea I've heard is the "open company", which I'm watching with interest, although I've no interest in working on a bloated text editor that's almost but not quite open source.

http://e-texteditor.com/blog/2009/opencompany

Open ERP had a sponsorship program where people would say how much they would give for a feature, so any developer could offer the feature, and multiple people could donate to it, if the original donation was too low... I dont really know how well it worked...

Another point, I think its a bit harsh taking a 'do it yourself' as a F U. I know alot of open source enthusiasts are just that, they have to hold down jobs and spend spare time working on their hobbies.

As Zurvan2's comments suggest...

I am sure there are developers who take any suggestion as a slight against their product but there are just as many developers who probably agree with you but don't have the bandwidth.

Some open source projects are easier to work on than others. If it's a bug in Firefox that I want fixed, no way in hell am I going to do it. But for a relatively small app or library that is easy to build and has a reasonably understandable codebase... I've found the DIY option to be very satisfying. Even if I have no way to contribute my improvements back, at least *I* can still reap the benefits.

I understand that people who release their code have zero obligation to do anything beyond that. It's their code, their lives, they can do what they want. There's nothing wrong with that.

Nothing new in this.
I see "bounties" come and go all the time over on drupal.org where I'm a contributor.
Occasionally there is a feature request that I agree with, but doesn't scratch my own itch, so as well as reminding folk that they can try it themselves, I point out that if a few people want it badly enough to throw a few hundred dollars at it, it will certainly happen a lot faster! It doesn't happen a lot, but it does happen.

I did a job like that just last week when someone asked for an extra file format to be supported in an import tool. I gave him some pointers on where in the code he could try doing it himself - he asked me what it would take for me to just do it - I quoted - he said OK - a week later the open source module is better for it!

Simple simple business. And I certainly don't think it corrupts the 'open source' credo at all. There's nothing evil about a programmer getting paid for work that someone else wants them to do. Getting paid for something you were wanting to do anyway is a great thing! And I don't think that sponsored feature creep is any more virulent than hobbiest feature creep. The same vetting process goes in to evaluating whether something is really worth doing.

Bounties aren't new, but they could do with a bit more support as a business model!

Ain't it the truth?

For what I've understand, such thing already exists. Check out http://cofundos.org/

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.

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).

Sorry, i meant to say oDesk: http://www.odesk.com/w/

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.

1. 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).

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

Jeff, I think you are onto something here.

> 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.

Wow, already thinking about something like that.

I was thinking about project mantainers opening a tip jar with a price tag for each requested feature. For instance, sometimes users complain that a software doesn't run on a particular version of a commercial OS. Mantainers could open a tip jar with a tip jar with a price tag matching that of the requested OS plus maybe a dedicated development machine.

Besides FAQ section, projects could also have a FAF (Frequently Asked Features).

@PRMan

If people who manage to make a fix would also try to fix compilation issues for their own platform, we could manage to reach the point where you just download, fix, compile, test and upload in a snap.

I understand that developing a way to deal with dependencies automatically could be - it is! - quite messy, but you know, computer can do the dirty work when given proper instructions.

Cheers

@PRMan
Once you put in the initial effort to get a codebase to compile, you generally don't have to do it again. So your first bug-fix is 8 hours + 5 minutes, and the next one is 5 minutes.

Just about every codebase I've ever worked on that I didn't write myself from the start has taken some up-front effort to configure, from an hour or two to a day or two. If you expect to spend some time with it, then that's just some startup overhead. It's only a problem if you just want to dive in, fix one thing and then stop working on the code.

And, Lele's right -- bad configuration experience is a bug, and if it itches too badly, scratch that itch and share it, and all benefit!

Reminds me of Horde project's bounty system. They encourage contribution to their open-source code base by having 3rd party sponsorship for specific features. I have no idea if it's at all successful but it always seemed like a good idea to me.

http://horde.org/bounties

@Everett, re: blurry font

I had this problem as well, and ended up deleting the "Calibri" font (which I don't use) from my Fonts folder. The site will then use Tahoma, which looks much better on my system.

The idea of providing priority support on an open source project is nothing really revolutionary. It's a whole business model around open source.

I'm creating a threaded comment module for the Elgg social networking web application because I really need that feature. However, I only feel capable of contributing to web applications. Hmm, maybe I should create an aggregated sponsorship system and take a cut of the fund pool. Ka-Ching!

PRMan hit the nail on the head.
Downloading the devenviroment, all dependencies for the devenviroment, all dependencies for the project and then configuring the project often takes over a day.
All for a bugfix that could take 5mins to fix.

As someone who dabbles in the world of Free Software, I think the whole money == new feature idea is not always the right way to think about things. Most of the time the projects are coded in spare time at the weekends or at night. Money is not a factor, unless you can pay someone a full time salary to hack on new features. They already have a job, so don't need paying.

Look at Beautiful Soup. From 3.1 onwards the author basically said "this is no fun any more" and abandoned it. Not because of lack of funds, but because of lack of time and lack of will. In the Free Software world, not everything is about cash. If you code the feature yourself, you are basically donating time to the author. And time is often far more valuable than any monetary donation.

@Val

> And, Lele's right -- bad configuration experience is a bug, and if it itches too badly, scratch that itch and share it, and all benefit!

See? See that? That's a "F*ck you". Right there!

Get your stuff straight and they will come, but don't ask me to fix your own project's configuration experience. Or just say it upfront that you don't give a crap about contributions from developers that work on Windows boxes.

So what if I come up with some VS (VS6, VS7, etc.) project files. And then what? They'll be outdated in two weeks. Am I supposed to maintain them now? I don't want a full time job. I just want to contribute a bug fix or two.

Val, I'm fully aware I'm coming off harsh but the more we air out these grievances, the better for the FOSS paradigm. It is my opinion that OS project owners should make the feature "make it easy for casual contributors to contribute" the top priority at all time, no exceptions, and devote as much time as needed to keep it that way. Yeah, sure, it's not as fun as writing code but, honestly, do you expect casual contributors to do stuff that isn't fun?

If you want *me* to "code it myself" then *you* remove the barriers. Or stop pretending.

I think (from experience) every open source project would be helped by a certain amount of money.

There is a threshold of usefulness--small donations aren't useful. $10,000 *can* be useful. $100,000 is *definitely* useful.

Every project has to decide for itself how to deal with money:

* If it's a one-man project, no problem--the guy takes the money, and implements the feature.

* But for other projects, if you just give them money, they have to have some process or system to deal with it. This only really works when that process is already in place, I think. So if there isn't such a process, and all you care about is specific features or bug fixes, it's normally more effective for a large donator to hire a contractor out of the pool of existing contributors to actually do the work, as long as you alone can afford that.

-Max

This idea already exists in the Perl community

http://www.perlfoundation.org/2009q1_grants_results

http://www.perlfoundation.org/grants

This is a good idea. I see it as a Kiva style thing, people investing money in a project, and those that work on it receive money. It would obviously be a lot more complicated, but it's an interesting idea to ponder.

atwood didnt like expertsexchange.com so he coded stackoverflow.com

Very interesting, Jeff!!
There's a related thread on ALT.NET group that may interest you BTW (It's still in beginning. Things are not warm enough yet).

http://tech.groups.yahoo.com/group/altdotnet/message/20918

The company behind OpenERP has a similar program called Shared Fundings Project.

http://www.openerp.com/buy.html?page=shop.browse&category_id=7

1) People are not giving enough money, even if it is pooled. - You need a set of reasonable time/cost estimators
2) There is no methood to give real money, and return it if not completed - You need to collect real money at the time of the request, and be able to return it if no developer claims it.
3) There is no standard for "complete". There are crazy people out there that will never certify completion because they regret committing the money. - An impartial third party is required to determine "completed", and issue payment.

Overall, there is a whole, non-trival, business in this. It *could* work, and it would work well with the major corporations taking part in the market.

When users ask for a feature in Twisted (http://twistedmatrix.com/), and I tell them to code it themselves, I quite seriously mean that. I *don't* mean "F**k you"; I honestly mean that it would be a rewarding experience in many ways for someone to learn enough to write it themselves. I spend a lot of time reviewing code contributed from people who have followed my advice, painstakingly going through and explaining how it could be made to adhere to the standards of our project so that it can be incorporated, and how it could be better code in general.

And I also mention that you can donate cash to the project. I appreciate your point about donations.

I don't think you know a lot about the psychology of open source projects. I would appreciate it if you didn't speak for all of us in such a blanket way, especially to say that we're all routinely being really rude to our users, when we are actually going out of our way to be polite and helpful, usually for free.

So let me make it clear how I sound when I'm being rude:

"F**k you. Don't speak for me."

Reading Predictably Irrational ... this sounds a bit like the 'social economy' vs 'market economy' issue. Bridging those two is no easy thing.

Would you pay your Mother-in-law to cook something specific for you for Thanksgiving? Would you pay to get out of helping do the dishes after the meal?

I think that is what yoy will run into trying to inject money into many (not all, but many) open source projects.

Talk about reinventing the wheel. Jyeah! (Wayne's World Style)

I've done this kind of work before with AROS, which has a bounty system for wanted features. Despite there being some quite hefty sums available (one bounty for a browser got as high as US$2000 at one point). Most of them just sat there never being touched.

I scored a Nintendo DS out of it, but I found that there was two real problems with it. The major one is that you can offer all the money you like, if people can't code then they can't hope to take advantage of it. And the fact is that for the majority of open-source projects, there just isn't enough interested developers that have the skills to do the hard stuff.

The other problem might be specific to just me. I have a good well-paid job as a sysadmin. I'm a skilled coder, but I do it in my spare time. I have plenty of spare cash from my job already, and can generally buy whatever I need whenever I want. So unless you're putting up enough cash to hire me for long enough to make it worth me taking a leave of absence from my job, anything you can offer is just pennies.

Not everyone can afford to pay for a bug fix for someone elses software. Imagine Micro$oft if we paid for each bug in their software. Its the developers responsibility to fix their software.

Open source IS a much better way to go, but its not within everyones abilities to fix problems. I have found in the past that contacting Open Source developers with info regarding problems or incompatibilities etc is well received. They generally appreciate being informed of glitches and will act to fix in most cases.

If you DO fix a problem yourself then its also a good idea to let the developer know of the solution, even if its not open source.

@W

> So what if I come up with some VS (VS6, VS7, etc.) project files. And then what? They'll be outdated in two weeks. Am I supposed to maintain them now? I don't want a full time job. I just want to contribute a bug fix or two.

Exactly. But why should you have to mantain different platform/tools specific configuration files in the first instance? What's the matter with hand written make files? Use CMake!

<a href="http://www.cmake.org/">http://www.cmake.org/</a>

Tools to ease platform/tools portability are there: use them. Allow mantainers know about them. Problem fixed. Next.

Cheers

The first thing I thought of was the Bounty system at the Seagull Project, a PHP-based CMS.

<a href="http://seagullproject.org/bounties">Seagull Project Bounties</a>

http://seagullproject.org/bounties

Ok, so I didn't see the (no html) staring me right in the face. Sue me!

WINE and CodeWeavers has had a pledge system for years. You pledge for an app you want, and it gets bundled with others pledges. For example:

http://www.codeweavers.com/compatibility/browse/name/?app_id=151

Ironic that the one natural example of this kind of system (that I know of) is for closed-source applications, but the difference between donations and payments is huge. One comes with goodwill, the other with requirements. And it's not just software or FOSS where this kind of change happens. Blood drives are very different if they're donations or payments.

Individual apps have this, but I think an organization that did this for tons of apps could really change tings and be big deal for open source. Do it Jeff!

@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.

The problem isn't getting updates. It's getting them accepted. Most projects will outright deny your changes.

@JRT

Programmers don't own PR degrees usually, neither do users. It shows from both sides.

If you can't program yourself, go rent a coder. Guess, you have just to Google for it.

@Vorlath

Maybe that's true, in most cases. OTOH, a fix must be tested, and if the project lacks a good test suite, it can be not worth the trouble.

One thing that many people are missing is that many open source projects are not simple science experiments that some geek gemmed up in their basement, but a tool developed to help someone solve a bigger problem (Ruby on rails for example). The code had to be developed in the first place and it has to be maintained afterword. They could have saved the framework code internally, but then they have two problems: #1 THEY have to maintain everything themselves #2 There is no preexisting talent pool available from which to draw resources to grow their internal talent pool.

To extend this... If you build code and thousands of people start using it, you get a bunch of free (and often vocal) beta testers. You also get a few dedicated geeks (1 in a thousand maybe) who will dig in and also tell you where a problem lies or they will build a new feature for you.

What's the downside?

I often want to fix things myself, but often use a different language to one I use normally (PHP). Big projects have a lot of internal structure. Often you don't have the latest version so you need to check out the dev. version re-test (often has the same missing the same feature and has the same bug). Which all adds a lot of time.

The main coders could probably do what I want in a short amount of time, so paying them is probably a good idea.

However, I can see some problems with giving them money. Unless there is steady stream of requests coming in or a request has a bounty 5 figure sum attached it's not like they are going to get time off their day job and contracting someone is probably not worth the overhead. The person could be a contractor, but I doubt many of those are open source contributors in their *spare* time and probably only do it when related to their contracting - in which case you can contract them.

I'm sure that sourceforge has a marketplace. I've never used it but had quite a few mails about it. No idea if it actually *does* anything though.

You ask "do you honestly have the kind of time it would take to do that?".

I think you have a point but it was only valid two decades ago and it mostly appeared to the things that were very different (i.e. build system etc). Faced with this problem the open source community created Debian and other systems like it. Debian basically provides a single consistent way to building every significant open source application every written.

You can compile _ANY_ debian application using the command: "debuild -us -uc -b" and by that I mean EVERYTHING. It works for small apps like gedit, it works for big apps like Firefox and it even works for hardcore stuff like the entire Linux kernel.

If you know C very well, you can quickly get up to speed with most C applications (of course hardcore stuff like the kernel has a bit of an extra learning curve). But in general, if I run into an error I can just grep for the error text, start from there and work myself backwards through the IF statement.

What about the risks of fixing something the wrong way due to misunderstanding the architecture of the app? Well, remember that most of the time you don't get direct GIT/SVN access instead you submit a patch to the bugzilla of that project and a maintainer will review and merge the patch. This adds a great quality threshold to the process.

It seems like it would be too hard and not worth it, but it reality I enjoy it and weird as it seems.... it actually WORKS.

rtrtretgrfrgfgf

Public radio and public television in the US have been doing this for decades.

People pledge small amounts, and the station pays for content bought from producers. Some producers specialize in "public [radio,tv]" types of content. Others don't.

Key points:
small individual contributions are aggregated for larger effect.
the producers themselves are not the ones doing the fund-raising.
technical personnel are only involved in their technical capacity.
you have to make a convincing argument, either with the content itself or the people soliciting donation.

Stations even "rate" their content by the amount of pledges it brings in. On radio, Car Talk and Prairie Home Companion are super popular. Even though you can get the content itself on the web, for free, people still donate to support it on radio.

Other public-supported groups, like botanical gardens, have fund-raising drives for specific purposes. In short, the contributions are "earmarked" for only that purpose. That's how "vote for bugs" should be done: contribute to the bugs you want, and your funds are earmarked for that, no matter how long it takes.

Seriously, the problem itself has been solved. It's all in the logistics of deploying it for particular goals: radio, TV, or software.

As many have said in different ways, the problem is a nightmare for requirements gathering. In the normal scenario, someone is the boss and decides when the requirements doc is finished and then it is sent to development. With a bounty system, you have the problem that no two users want the same exact patch and some requirements are mutually exclusive.

User 1 wants a patch with sub-features a,b,c and there is a d sub-feature User 1 doesn't care one way or the other about.

User 2 wants a similar patch with sub-features a,c,d and definitely not b.

How do you combine their bounties?

Jeff, this time you miss it completely. The whole idea of open source is of people contributing time and effort for creating something good, to be proud.
even your own experience in donating to an open source project didnt have the expected result.

the rest I have to say is here:

http://design-to-last.com/index.php/Technical/paying-for-open-source.html

So start it yourself.

(F**k you.)

How would it be in the following scenario:

Feature A : somebody pays a programmer 100 US to do it
Feature B : somebody pays a programmer 200 US to do it
and it so happens Feature A and B are orthogonal so if you implement one you can't implement the other. Should then the one who pays most decide which feature should be added? This I see as a major concern when money starts to play a more dominant role in steering how OSS should be done.

<snip>Why isn't there a service to aggregate and pool funds to sponsor programming particular features or bugfixes in open source software? </snip

There are ... they're called software companies.

Doesn't SourceForge already have such a feature?

Hey Jeff,

check out http://matrix.squiz.net/.

These guys do exactly what you are talking about.

The CMS is free to download and use. If you want a new feature, you pay them to build it and then it becomes part of the core system.

They encourage companies to 'band together' to get various features built cheaply.
It's an awesome business model and one I am seriously considering for my CMS.

I read:
"Sometimes, when people say this:
The source code is freely available. If you feel so strongly about this bugfix/tweak/feature/plugin, why don't you code it yourself?
They're really saying this:
F**k you. "

I thought:
"Well, *that*'s gonna play well on the comments page."

@Anders
"It so happens Feature A and B are orthogonal so if you implement one you can't implement the other. Should then the one who pays most decide which feature should be added?"

1) Give me a sensible example of this situation arising. To begin with, it's pretty rare that you get orthoganal features at all. And when you do, it's normally pretty easy to set up a control to select between the two functionality sets, or to produce two release variants. In open-source, time is the more problematically finite resource.
2) Surely it's better that slightly-too-much is devoted into getting a single feature rolled out, than not-quite-enough effort ending in 2 half-finished non-features.

It's like this Stallman and his freetards, the source code is freely available... yeah right!
The borders between what open source is and not have actually diminished a lot. And asp.net has a lot of open source I think!
codemonkey on March 27, 2009 06:51 AM

----------------------------------------

What's this? A troll, who barely has a grasp of basic grammar and sentence structure, calling people 'freetards'? Shocking!

The word orthogonal is being used wrongly here. If two features were orthogonal then implementing one would have absolutely no influence on the implementability of the other.

That said, features conflict quite frequently.
Security vs. Usability is an extremely common example.
Modularity vs. Performance is another.
Extensibility vs. Consistency.
Standards-compliance vs. new useful non-standard features.
Privacy vs. targeted content.
Simplicity vs. Configurability.
Reliability vs. Performance.
Peak Usability vs. Discoverability/Learnability.
Platform Stability vs. user configurability.
Support for content with certain legal restrictions vs. availability with other legal restrictions (eg. GPLv3 & patented content, codecs for media players, and even directly GPLv2 as a feature vs. non-GPLv2 as a feature -- dual-licensing may not cut it for some cases).

Engineering is about tradeoffs, after all. Sure, in some sense in many cases you could do both, but advances in one consume the advances in the other (especially with respect to performance).

I've recently brought on someone part-time to help with my personal contracts, and the next round of work I'll be handing over is for this person to fix up some failing test cases in the open source projects we depend on, Pinax mostly. I think its a perfectly reasonable way to contribute and more of us with the means to do so should consider it.

you are an enigma. an absolute proven legend, who says stupid things to get clicks. Jeff, don't sell yourself short, even if sleep is not available at the moment.

I think one problem is too many choices, too many open source projects. Which GUI should you contribute to, KDE or Gnome? Which editor, Vim or Xemacs? Which programming language, Perl or Python?

Sure you could say "choose your favourite of each class". But there are so many open source projects, the list is never ending even if I choose just one of each category. Browser? Music player? Video player?

What if I donate $10 and nothing happens? Should I donate $20? $100? What happens if I run into anther bug?

I personally hate this "If you want that fixed, fix it yourself" attitude. According to this attitude I could as well write the whole application myself. Why are you writing an application and release it to the public, if you later on give a sh.. on if it is useful for people or not? What kind of BS attitude is it to release software as "take it as it is or leave it". OpenSource developers always say you don't need commercial software any longer, OpenSource will always fill the the gap. I don't think so. Commercial software is created by people who want to sell this beast, so they won't say "take it or leave it", because "leave it" is very bad for them. If I report a bug to them and this bug has already been reported by a couple of other users, they will fix it. They must fix it, or people will stop buying it and every buyer counts... maybe not if you are working for Microsoft (actually thousand buyers less won't make a difference to them), but for most companies fixing something, that can be fixed in two or three hours is reasonable if this makes you sell 10 more copies (unless the price is too low).

I have found a bug in Firefox, a serious one. One that has been reported and voted for by over 100 people. Has it been fixed? No. I gave them sample source how it must be fixed. Have they used it? No. They wrote me back "please add your code to our existing one, create a diff/patch and we will review it". That is like someone throwing 100 dollar on your table and you say "Please take that bank note, fold it appropriately and put it into my wallet". If you are too lazy to do that yourself, you haven't earned the 100 bucks in the first place. If I already present them with code they only need to copy/paste into their source code and that is already too much work, this is like saying "We give a f... on our users, go elsewhere". Thanks for letting me know, I will.

I see a number of problems with this whole thing.

Just because there is some rent-a-coder deal set up to get hired hands from pool X to implement feature Y for project Z does not mean there's anyone out there actually willing or able to wade waist deep into the guts of project Z from the outside. I'd expect much of the time that it's not all that much easier for the pool X guy to write the feature or fix the bug than the person originally making noise about it. True, the person requesting the whatever might not know anything at all about programming, in which case that user would be totally helpless without going out to buy a book about programming or whatever, but in my experience there isn't as big of a gap between a motivated rookie and an experienced but uninvolved pro as you might think.

The other side of this is that the best way to get something done is to hire the people who already work at the project, and know it from the inside. The issue with this is that your money can't buy features unless you want to buy a LOT of features. I already use all the time I have. Money is nice, but I can't in good conscience take your money and promise to deliver feature Y in exchange for it. Not unless you want to pay me enough to quit my day job while I work for you. If you do, let's make a deal! That would be outstanding! The problem with this is that in the real world it just isn't so easy to tell your employer you will be taking a week or a month or six months off while you work for hire on this little side project. In my case, I put the minimum price at one year. Less than that, it's not worth quitting my job and then dealing with trying to find another one when this temporary gig is gone. I'll even work cheap by programming standards, but so far nobody has been willing to pay $40,000 USD for their pet feature. Such is life.

And then a third issue is that the people in the middle of the thing are invested and involved, and they're using the project as a conduit for realizing their own personal dreams. That's a huge part of what motivates them to volunteer there in the first place. Much of the time, these loud requests come in out of nowhere demanding something that just isn't a priority for the core developers, or which would take the entire project in a direction the core developers do not wish to go. In this case, "write it yourself" really means "I hate this idea, and have no interest in it, but if you're extremely determined, you will be in a better bargaining position to change my mind about this if you dump code in my lap."

Most of the time though, "show me the code" means nothing more than "Yes, I know, and that pisses me off too, but there are only so many hours, and there is SO much work. Why don't you do something useful to help instead of wasting all this energy telling me why you're going back to Windows if I don't comply with your wishes instantly? What? You're not willing to make any effort at all? Well then, in that case, indeed, f**k you!"

That's the upshot of not getting paid, I guess. Sometimes it really does mean "f**k you."

I remember this one guy who wanted to purchase a feature with a six-pack of beer. Sure. I'll work 1-200 hours for a six-pack of beer. Jackass.

Yep, that's exactly how most OSS feels to me. I've gotten the "fix it yourself" many times, and it definitely feels like "F**k You" to me.

Many (not all) OSS projects, even those backed or even developed by "real" companies think of themselves as projects, when they really should think of themselves as products.

If someone uses your project for something that you tell the world your project does and then encounters issues, just telling them "F**k You" results in leaving a rather bad taste in that user's mouth.

I've basically given up on OSS software for now, due to this attitude.

You must use diplomacy when posting a bug report or a feature request.

I have been using debian unstable for two years, and now I think I have posted at least one bug report to almost any free software I have used.

If you read the "guides to posting bug reports", have a lot of patience, and don't get mad at the first negative answer you get, you can usually obtain most of what you ask, with the minimum effort of sending a bug.

I looked at some of the bounties on the FOSS sites listed in these comments, and the vast majority of bounties are US$200 or less. For a even slightly talented developer, these numbers are negliglibly close to zero (given the amount of work involved simply in getting your development environment going).

I thought "what developer is going to take this job?" Possibly a single developer would know a product well enough to earn *all* the bounties logged against the product. More likely you're going to get an unskilled developer writing horrible code (never accepted by the maintainer, if there's an acceptance process). If most business are aware of this, it'd explain why bounties aren't common.

Me, I'd much rather light $200 on fire and wait to find someone to do the work for free, than to hire someone for $200.

I don't think financial incentive for an individual "feature" makes for good project management. That goes for open source or closed source.

FEATURES HAVE TO BE SUPPORTED FOREVER. Is this user willing to continue to foot the bill for that?

Even when they conflict with other features? Even if it prevents other important features from being implemented?

The choice to implement a feature (or sometimes even to fix a bug) has to be viewed in a larger context.

There's a risky way of popularizing sponsorship:
@author: Joe Programmer
@date: 1-Apr-2009
@sponsored-by: Joe Reasonable User
@amount: USD 500
@lines of code: 1234.

Risks:
copyright blurring and misunderstanding.
Daily dueling between sponsor and programmer for "ownership".

Cures:
1. Everything open.

2. "Community rating of the deal" <-- could work effectively, like any village gossip council - unethical sponsors don't like being named and identified as such in source code. Ego massage is an important part of their existence :-)

3. Don't ask a gentleman his salary, look up the source code! ;-)
That way, FOSS programmers can say at their next job interview - i wrote this module that you may be using already!! The small sum of payment might mean that you need to negotiate a lot for a good salary/package/rate, but if you are good enough to write FOSS code with the RTFMs and the STFWs, you should be able to handle corporate slime easily. (But this is an assumption.)

4. ROI statistics for all sections of industry - what huge amount of quality content can be obtained for what little investment - compared to buying from closed-source, legally fortified, ethically void bunch of corporations. This is, was, and will be the tipping point for opensource, whether it be Linux or Java or C# or web apps in any of those platforms.

At Funambol we have a program called Code Sniper https://codesniper.forge.funambol.org that sponsors with money grants the development of new features for the product. The list is pretty open and when somebody of the community asks for something that is not available, our answer is not a simple 'do it yourself' but 'we can sponsor the development, help us find somebody willing to accept the task'. It's not a simple issue in any case and I don't think there is a silver bullet.

Actually, just coding it yourself really is best.

Couldn't this work (maybe better) for closed-source projects?

If you've got some software which people pay to buy, then you have the hassle of deciding whether and how to prevent them copying it freely. There are a whole raft of methods used, but it's all crappy overhead in relation to your core task.

You could use a fund-and-release system to propose functionality improvements (even bug fixes) and collect the payment for your work in advance. See for example the Takoha manifesto (www.takoha.org) for a description of how this could work.

I've done this kind of thing too, in a way... http://blogs.compdj.com/post/Refactoring-someone-elsee28099s-code.aspx

You missed one of the possibilities. In the OS projects I contribute to (Perl modules), there's also the choice of "Write a failing test", if you can't or don't have time to write a feature yourself. The test gives the devs something actually concrete to write towards, and, if accepted, makes them itch cos now the test suite doesn't pass.

Jess

Financial incentives for feature-requests would go a long way to help improve open source software. People may see it as commercialization of the software or corporate takeover (as financial incentives could be used to change project direction). It's more-so a practical donation.. I would work on open source projects if I had free-time to do so (I would prefer to work on open projects as opposed to projects that had lots of NDAs associated with them) - but I'm also in university and have my own place. I need to pay for food, university and housing.

I'm doing it (at least theoretically). People that want a given feature in hippo mocks have three options: do it yourself and send me a diff, pay me to do it or convince me that it's so awesome I'd want my free time spent on it. And to counter the most prevalent comment I've read so far, none of these options require me to merge back the change, but all keep the option open if I deem it a good idea. The mainline is kept up to date and if you have a good feature I will do it for you, make it work in your environment and merge back the good bits.

I'm not sure there is interest in a generic way of doing this.

How can software be any different from other things in life?
If you want something done:
A: You do it yourself.
B: You find someone else who can do it and a suitable motivator (money, coke etc. and in rare cases persuasion.)
C: You tell your kids not to do it