[Marketing] Bidding for patches
adam.weinrich at nokia.com
adam.weinrich at nokia.com
Thu Mar 15 18:37:12 CET 2012
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!
From: ext Peter Winston <peter at ics.com<mailto:peter at ics.com>>
Date: Fri, 9 Mar 2012 18:24:04 -0500
To: <marketing at qt-project.org<mailto:marketing at qt-project.org>>
Cc: Adam Weinrich <adam.weinrich at nokia.com<mailto:adam.weinrich at nokia.com>>
Subject: RE: [Marketing] Bidding for patches
This is a really interesting problem, it's great to hear you bring this up. Getting this right would both turbo charge open governance, and developer adoption.
and I’m ready to start!
However, I understand Quim’s point that the commercial support aspects (regardless of the mechanism) should be kept separate from qt-project. Anything that Nokia does, runs the risk of being seen being an “endorsement”. This is a great goal, but how far does Nokia want to facilitating it. If you sitting between the customers, and the vendors, by pooling payment, or validating a design, they your effectively putting Nokia on the hook for its success.
Still, I love the basic idea of building a market place that connects customers with pain with vendors who can help them.
I would be happy to brainstorm the issues with you.
---------- Forwarded message ----------
From: Quim Gil <quim.gil at nokia.com<mailto:quim.gil at nokia.com>>
Date: Thu, Mar 8, 2012 at 6:30 PM
Subject: Re: [Marketing] Bidding for patches
On 03/07/2012 01:13 PM, 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
> 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
- 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<http://qt-project.org>.
Marketing mailing list
Marketing at qt-project.org<mailto:Marketing at qt-project.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Marketing