RFE payment ?
Posted 12 Nov 2001 at 22:02 UTC by Malx
What whould you think about ability to pay for speciafied feature to be
It could allow some company to make desision - hire programmer to
implement what it needs or just pay to FS developer
of project with most implemented features to add this special one.
This could be implemented as special business request (posted to
web). Then whould be some negotiation about feature/cost/etc.
(during this negotiation some other persons could increase payment for
Then developer whould have a list of requests with values listed. He
whould make preference to most payed/usefull.
Whould this feature work? Is it easy to implement with existing
IMHO this could be implemented as part of SF communities such as
btw. read through SteveMallett diary (12Nov). But I
whould not completely agree to it - There is commercial software
It is closed source and it is not free to distribute. It is not for
historical, but for economical reasons.
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.
It already exists !, posted 13 Nov 2001 at 10:52 UTC by r4f »
Have a look at this page.
It's possible to make donations to Sketch's lead developper
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
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
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
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
: Companies don't really care about
Open Source. They care about support.
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
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
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
listener-supported public radio ;-) (How much less viable can you get
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
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.
Contacting..., posted 14 Nov 2001 at 16:39 UTC by Malx »
Why don't they just contact Z and ask what it takes to get that new
feature in the code?
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.
Realism, posted 26 Nov 2001 at 14:00 UTC by Gregory »
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