RFE payment ?

I think something like this tried CoSource (RIP) to achieve. Yes, over a year or so there where a number of requests and successfully completed mini projects, but a few things can be concluded. The number of requests was relatively small. The money amounts in most of the case where ridiculously small. sXc (another RIP) rolled bigger projects (a lot fewer to) with some reasonable amounts of money. Most of the CoSource clients where end users (that's the reason for less money if it was money at all offered), if you would consider gaining an amount of 0 -> 50 USD /mo then it's a valid business ;)

Companies don't really care about Open Source. They care about support. Yes Open Source is a lot more valid than Closed Source, but most would choose to base their business on supported software. Only if it is Open Source and supported then is a more valid choice than Closed Source and supported other way no serious business will consider it, unless having a strong in house development team with experience with the software of course.

The Linux support companies are needed but unfortunately most of them where a bit ahead of the time, just wasn't the right moment, but I think it will be again a time for business in the field.

One of the only strong company which does Open Source and still manages to survive, and all of this for a number of years now is Sendmail. If you look at what is happening, first they offer support, second they offer a value-added product which is especially tunned toward easy configuration and enterprise use. Yes they had, have and will have a good business model.

Have a look at this page. It's possible to make donations to Sketch's lead developper (Bernhard Herzog)'s employer, Intevation.

The following can be found in Sketch's page about donations : "You can buy developer time for Sketch in multiples of USD 10.00 at the Intevation-page at Kagi."

But only on an informal basis, and not for large sums of money.

In an auction, where you compete with other bidders for a limited resource, the highest bid gets exclusive ownership. The optimal strategy is to bid as low as you can but have the highest bid.

In bidding for requested features, you are asking for a new unlimited resource to be created, and everyone else who didn't bid will get it too. The optimal strategy seems to be not to bid at all, but provide clean, well-thought-out specifications instead (which programmers prize above riches).

However, some kind of informal barter/gift economy could benefit developers even if it's not a viable business model for a company. e.g. the sending of Pizza to SAMBA developers. The extreme form of this is the sort of distributed barter in Bruce Sterling's short story "Maneki Neko". (I mostly mention this because it's a great story. Something to aim for perhaps).

Companies already have procedures in place to pay contractors for software development work. My company paid Per Bothner for an enhancement to Kawa that otherwise wouldn't have been high on his priority list. Unless the contract specifies work-for-hire, the programmer retains copyright and can put the code in the released version.

There's a strong "use what everybody else uses" mentality in industry, so it makes sense to let everybody else use what you're using.

Even if there were a web interface available, I would probably contact the maintainer of the free software directly. If s/he was too busy to do the work, I'd ask for a recommendation. None of this lowest- bidder stuff. If you want it done at all, might as well get it done right.

Well, you're half-right. They also rely on the "ease of mind" that a EULA or contract provides them. Granted, who really sues an OEM when their software goes haywire? Doesn't seem to matter to the execs buying this stuff... as long as they have something to flash in front of the board and/or stockholders, that carries a lot of weight.

Honestly, something just doesn't feel right with this proposal. I don't know if it's the lack of successful examples, or just something nagging at me with regards to the thought of money influencing an OSP (Open Source Project). I always preferred the business model of making money on the support services of a mature product. Just my $.02.

Slightly off topic, but when discussing free sofware and money it pays to remember that actual free software development is a less viable business model than listener-supported public radio ;-) (How much less viable can you get than that??)

After all, public radio presenters control the transmitters and can turn them off or nag their listeners relentlessly until they send in wads of money. Free software developers don't have that option -- once you've released the code it's gone!

Personally I am not going to do any more coding or answer any user questions until 100 people email me a ten-dollar pledge. Maybe I'll try to get a deal with Land's End to advertise their fine clothing products in my header files too.

I don't object to the general idea.

I just think that if a company uses software X today, written mostly by programmer Z, and the company wants it to get a new feature that would make it a lot better for the purpose.

Why don't they just contact Z and ask what it takes to get that new feature in the code? Money or no money. This has never happened to me yet. Although I've been doing "private" consulting on software I've written, it hasn't ever been a question of adding features or similar.

I guess that most of the times, a programmer at the company will do it and post patches/ask questions about it instead.

Only when the above becomes very frequent or at least when companies start to compete for attention from Z and Z's team, when there would be a point to start the "bidding" and whatever.

IMHO They are not thinking this is possible. They just not thinking about this possibility at all!
I thinks it is same this - why commercial users do not submit Bugs
People must promote in some way this feature. So I thought of implementing this as a standart feature in big archives of free software.

Just thought about other possibility. You could include into "about", "man" and file "FEATURES" in source dist part about "Commercial requesting of features ".

Better for it to be near "Implemented features" and "todo". Becouse if you trying to find software to solve your tusk fist of all you'll try to read "features" list.

As others have pointed out, this has been tried (CoSource and sourceXchange). I think, though, that the idea is still good, but the implementation wasn't quite right. sourceXchange didn't allow for the pooling of money around a single support request. CoSource was too low-budget, and feature requests were not tied to the specific project.

There's been a lot of talk about how SourceForge is trying to sustain itself. If VA were to focus their efforts around SourceForge toward making open source developers financially successful, they could probably charge those same developers.

There's a lot of ways they could do this (and I may just get around to writing an essay detailing this), but one way would be to have feature auctions as a feature of the projects they host. So, alongside the panel for open bugs, release files and support requests, there would be a panel for feature requests, with monetary value associated with them.

It's important to find ways of raising revenue, which can be used to accelerate the core development of a software product. I like the idea of charging for custom feature requests. This kind of sponsored development model is in some ways very close to ideal. Developers should in my opinion be able to charge for their time spent developing custom features and modifications.

A lot of developers give away a cut down version of a script or product as a promotional tool for their full version. I have to question just how well this works for them.

The structural core of a software product should in my opinion nearly always be open source. Theirs nothing to stop you from developing propriety or sponsored modules which could be sold as enhancements to the product. You also might be able to negotiate some form of time out agreement with your clients, where by the requested enhancements automatically become open source after a certain period of time and there by feed back in to the product.

I agree with Bagder's point one of the most an important things from a developer perspective is to try to find ways of reaching clients directly. There are still far to many middlemen and agents around for my liking in this industry.

``If a man is proud of his wealth, he should not be praised until it is known how he employs it.'' - Socrates