[Marketing] Bidding for patches

[Quim Gil]

On 03/07/2012 01:13 PM, ext adam.weinrich at nokia.com wrote:
> I've discovered that corporate Qt users sometimes have a need for their
> bugs or features they care about to be escalated and they are willing to
> pay for it.  At the DD11 SFO Contributors Summit we had a discussion
> during the Qt Project Corporate Outreach session where we brainstormed
> about a bidding system to address the need for such one-off development
> work.
>
> A partner services engagement is one-to-one relationship with a high cost
> of entry.  We could provide an alternative which opened up bidding on JIRA
> tasks to all, partners as well as freelance programmers. Maybe even
> multiple parties interested in a task could commit to pay what its worth
> to them and once the pooled amount is worth their effort a contractor
> agrees to do the work.
>
> I wonderŠ
> 1) How we could integrate this into the community workflow

Does it need to be integrated? Why not keeping the Qt Project 
infrastructure and workflow focusing on the development, leaving the 
business motivations and organization aside?

> 2) How to assure trust and payment

Using a 3rd party service. I don't see the Qt Project infrastructure 
and the thin legal & accounting overhead having to take that responsibility.

http://www.freelancer.com/ could be an option. Are there others? I'm not 
an expert on this.


> 3) How to deal with patches that are not approved to be merged.

The Qt Project context offers a lot of flexibility on this, making 
easier to merge good patches (while keeping away the rest, no matter how 
much money someone is willing to pay for its merge).

No bounty should come with a promise that the patch would be merged. The 
reasons for patches to be merged or not are based in many factors and 
this is what someone willing to see a patch upstream should look at.

Let's look at the possible scenarios considering that there are 
fundamentally two types of patches: bugfixes and new functionality. 
Bugfixes are relatively simple to merge. You need:

- A patch with proof of the bugfix. Without this you wouldn't get your 
bounty anyway.

- Needs to follow the contribution guidelines of the Qt Project and the 
specific module (if any). This can be required in the bounty offer.

- Needs to be reviewed and approved. This can be tricky if maintainers 
are busy with other priorities or the module is basically unmaintained. 
A sub-bounty for a reviewers / approvers to have a look? Nobody should 
be able to buy an approval, though. If the patch is buggy or doesn't 
follow the guidelines it will be rejected anyway.

- If we are talking about new functionality it needs to be discussed 
within the project in the first place. Is that functionality fitting in 
the module roadmap? Is someone else working on this already? What is the 
approach proposed for the implementation?

- Note also that new features imply a new IPR risk that needs to be 
assessed. Maybe a brilliant patch solves a problem for a specific 
customer but puts in potential legal trouble the Qt Project and the 
unaware users of that code.

> 4) How to get started

Find the 3rd party service. Find a customer with money and bugs. Let's 
try a pilot?


> Is this something the community is up for or YOU want to get involved with?

I see it as a nice "add-on" that the community can work around, more 
than as something the Qt Project itself should take responsibility of. 
At the end this is about paying money for development, which is no 
different that what Nokia, Digia, ICS and others are doing already - 
keeping their accounts and agreement out of qt-project.org.

--
Quim