I have concerns on bounty system especially with some of the more detailed implementation methods you suggested below (see below for more info). This is not to say they can't be addressed through taking a more careful approach, though.
These are my main concerns with a bounty system. Think of them as risks that must be managed with moving in this direction.
Risk 1 : "Customers" with the most money may not be the best ones. They may be less loyal, or may push you in ways which are tangential to a broader base of users (which improve code testing), or more involved customers (in terms of contributing code/docs) and so on.
Way to address 1: Must be careful not to enter slippery slope of letting money direct development. To do this, err on the side of caution - i.e. avoid institutionalizing money matters. Personal contracts between community members are sanctioned and even provided some free publicity like through page like this http://tikiwiki.org/tiki-index.php?page=TikiMarketPlace (or even something better), but not institutionalized.
Risk 2: End up attracting developers that are interested more in money than in being part of a community, or developers who have little knowledge of open source ways. De-personalizing of relationships leading to community fragmentation.
Way to address 2: We don't want some kind of impersonal bounty system. We want one where the people who are providing bounties and receiving bounty are part of the community and have commitment to it, not outsiders. We want people to be valued by their involvement, not for the money they bring.
Now in response to nyloth's points.
> - Many people are using tikiwiki and they have many needs. Some of them (and
> I'm convinced they are quite a lot) may be able to pay for those needs to be
> - Many developpers need funds to invest them more in tikiwiki,
Agree. Personal contracting is already being done. And I have also offered bounties but I only offer them to people I trust understand that money is not the most important thing.
I suggest one of us can lead the creation of a Tiki developers network (TDN) with a website and identity separate from tw.o that can be linked to http://tikiwiki.org/tiki-index.php?page=TikiCommunity. The people will overlap across both groups, but the separation helps to address my concerns.
> - Many developments are done in different companies or organizations but are
> not send back to the community. This is not a problem, but It would be better
> if we could convince more people that it is better for us and for them to
> share new feature developments, since they will benefit from the existing
> community (bug fixing, compatibility with code evolution, etc.)
I do not think the bounty system directly addresses this, and may in fact confuse the issue. The way to tackle this problem is to have a separate section on a tw.o site for patches and users - the user community. This is more work, but I believe is worth the effort as a separate activity. No need to mix in the bounty system into this. Someone else could lead this, preferably a very advanced power user not necessarily a dev.
> - show that more and more companies are involved in tiki development and
> have some budget for it (which is something important for many companies when
> choosing a product),
This can be taken care of by the user community I mentioned above. We are not the "company-sponsored" type of open source project. We are more diverse - many smaller companies (like me) and self-employed joined together type. The information for who is involved as users should be available as part of the user community. As for bounties, that should exist on the TDN.
> - motivate some developpers and convince new developpers to join our
External TDN website may help in this, to avoid risk number 2. It will also help provide better mentoring of new devs. e.g. The devs who are also in core and in TDN can identify new devs who have potential to be more involved in core. Open source projects scale only with concentric circles - we need more of these circles.
> - more quickly reduce our bug and wish list
We don't want to "bountify" bugs. Ironically, this might actually discourage bug fixing overall if people only fix bugs that are bountied.
> Xavi has already done a wiki page to put some bounties there, but :
> - Wiki is not, IMO, the right tool to handle bounties,
> - Not enough developpers are aware of this page,
do a tracker on the TDN site (which I assume will run Tiki )
> I think we could now :
> - Use our own trackers to manage bounties :
> * either in dev.tw.o, by adding new fields to our 'Tiki Tracks' tracker,
> * either in a new bounties.tikiwiki.org tracker
> - Promote bounties (see above : link on tw.o, ...)
Once it goes beyond a wiki page, it will start to look institutionalized and slippery slope may happen. I strongly suggest TDN site be not on tw.o domain. Linking is less of an issue then.
> If the choice is made to use our trackers, we could use existing data types
> ('Feature request', 'Bug', ...) or add a new data type "Bounty".
No. Not existing trackers, please.
Finally, I am willing to help in this Tiki Developers Network site.