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 From: ext Peter Winston <[email protected]<mailto:[email protected]>> Date: Fri, 9 Mar 2012 18:24:04 -0500 To: <[email protected]<mailto:[email protected]>> Cc: Adam Weinrich <[email protected]<mailto:[email protected]>> Subject: RE: [Marketing] Bidding for patches Hello Adam, 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. Cheers, -peter ---------- Forwarded message ---------- From: Quim Gil <[email protected]<mailto:[email protected]>> Date: Thu, Mar 8, 2012 at 6:30 PM Subject: Re: [Marketing] Bidding for patches To: 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 > 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<http://qt-project.org>. -- Quim _______________________________________________ Marketing mailing list [email protected]<mailto:[email protected]> http://lists.qt-project.org/mailman/listinfo/marketing
_______________________________________________ Marketing mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/marketing
