On Wed, Jan 18, 2012 at 10:27 AM, Adam Vande More <amvandem...@gmail.com> wrote:
> On Wed, Jan 18, 2012 at 11:49 AM, Julian Elischer <jul...@freebsd.org>wrote:
>
>>
>> we really need a bud-submitting-user advocate..
>>
>> Someone (need not have a commit bit) who doesn't take charge of the patch,
>> but, rather,
>> acts as a project manager in hte process of getting it in.
>> i.e. finding, and then pinging the approriate developer, and occasionally
>> nagging them or
>> finding an alternate dev if the first choice is unresponsive.
>>
>> diplomatic skill would be important.. maybe a woman might be best in
>> this job as the developers tend to not want to be rude to women :-) .
>>
>
> I've suggested this before without much response, but since this thread
> seems to be encouraging repetition I'll give it another go. ;)
>
> I think a bounty system would be very effective(e.g. micro-donations of
> recent political campaigns) in getting many of these problems resolved.
> The main problem with a bounty system is getting people to pay since
> certain needs/desires lose their urgency over time. To address this, the
> system needs to be an escrow type setup where money is pooled until project
> is complete, then payment in full is given.
>
> There are large barriers to entry in setting up such a system though such
> as legal and financial hurdles. I don't believe the technical hurdles are
> over-whelming and I would be willing develop a web front end for such a
> system. Because of the barriers I believe such a system should be setup
> and spun off by the FreeBSD Foundation and I don't want to do any dev
> unless there is some momentum.
Bounty systems have not come into existence because of the
potential legal ramifications w.r.t. distribution of funds,
responsibility of completion of work, and a number of other points
I've not listed here.
iXsystems does help funnel money to contractors [with a small
amount of "administrative overhead"] if you need something done and
you have the funds to do it with. In which case, it's advised to have
a proper plan, requirements document, and deliverables setup before
going and proposing a course of action. That's where some opensource
projects tend to fail: the requirements are too openended and thus the
end-result cannot be achieved in a meaningful timeframe or in
sufficiently manageable quanta (deliverables in this case).
The deliverables and the scope of the work should be negotiated
between all three parties: the 'customer', the 'contracting group',
and the 'contractor'.
Thanks,
-Garrett
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
