Commercial, Bidding Patches

1

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
2) How to assure trust and payment
3) How to deal with patches that are not approved to be merged.
4) How to get started

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

Cheers,
Adam

Adam Weinrich
Nokia-DXM Qt Key Accounts

2

On 03/07/2012 01:13 PM, ext [email protected] 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

3

Sorry to toppost. 

To Peters concern about "Nokia",  This idea of enabling patch bidding(or 'bounties' as Quim calls it) might fall under the Qt Project umbrella, which is distinct and separate non-profit organization and Nokia could not be responsible for any activities between participants.   I believe facilitation or integration of bounties at some level by the Qt Project infrastructure could actually be of real value to the community.   I accept some of Quim's points and agree that dealing with actual accounts/payments must not be part of the Qt Project so lets push that to a 3rd party.  I also understand that theres no way to guarantee a merge – but I say I would say it would encourage better quality in JIRA if payers expected clarity about what they plan to pay for.  The fact is that the farther away from the code you go, the less streamlined and more cost is added to a development effort. 

I know the proposition of integrating finances directly into open source development is heresy but Im throwing it out here because I envision, if done subtly, it could provide a catalyst for fixes and features and offer interesting metrics back to the community(hey what value are votes?).  It could foster satisfaction in the Qt user community within the Qt Project context instead of forcing organizations to translate needs into  RFQ's, manager speak, sales meetings,  and other such cost generating overhead.  It would definitely reduce the barrier to entry for small efforts that might never get done through a partner and thus encourage the Qt freelancer community to be more dynamic and visible.  Frankly, its more efficient and keeps control closer to the developer level.  In this sense it could add a lot more than simply paying money for large scale development in the way that formal engagement with partners currently works. 

I'll touch base with Peter directly on his ideas to get started but if anyone else is interested please share your thoughts!
 
Best Regards,
Adam