Hi Nyloth,+1 to the general project.
> Many developments are done in different companies or organizations but are
> not send back to the community. This is not a problem, but...
I think this is a big problem.
"No problem should ever have to be solved twice. Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there."
With 450+ items on our wishlist, do we really want to waste resources?
I have seen too many times where developers fix things and because they come or are invited too late to share their code, it ends up being too much work to merge and that code is effectively lost forever.
I think Tiki is better than the average project to share code. However, I think we can do even better.
The #1 point I want to address is "It's not so easy, for the moment, for those two groups of people to contact each other"
Not so easy?
It is outright difficult. Say a new user comes along (let's call him John), checks out the rated feature page (http://doc.tikiwiki.org/Features), tests TikiWiki and likes it. John concludes that Tiki is almost ideal for his needs but would like some improvements on feature X and Y. (which are rated C or D). John could work on it himself (he used to code a little), or he could have it done by someone working for him. But he thinks it would be much simpler/future-proof to hire whomever wrote that feature and work out something directly. Say John wants enhancements to the newsletter, he should first try to work something out with Sylvie who did that last major upgrade of that feature.
With or without money, the interaction between users/power users and developers has historically been difficult. Why? Because unless you spend a lot of time with Tiki (on IRC, mailing lists, etc), you can't know who does what. The vast majority of other CMS/Groupware systems have a small core and most of the features are available via a 3rd party module system. It makes it very easy to identify who works on what. I have a friend who is a "module developer" for Xoops. He routinely gets requests for enhancements and part of his growing business is funded by these. And he contributes these enhancements in the next version.
Some open source projects have "maintainers". Again, it makes it easy to coordinate bugfixes, enhancements, bounties, etc.
In Tiki, the only way to know who developed a feature is to know the file names of the features and checking the CVS history to see who worked on it. And for the untrained eye, it's not easy to know who did significant work on the feature vs some minor bugfixes.
Some developers will be happy to get feedback, bounties, etc about their features.
Some developers wrote that feature a long time ago and are no longer active in Tiki (so don't want feedback)
Some developers are still active but don't want feedback (too busy, etc)
What concerns me: I am very happy that some people get paid to work on Tiki. Let's just keep an eye open for some botched code which answers the bounty (and the person gets paid) but since it's crappy code, someone else ends up cleaning up the mess later on. (unfinished features, difficult to merge up, etc) Being worried about this should in no way, shape or fashion slow down or hinder putting in place a bounty system. However, if ever we do run into problems later on, let's be proactive in the communication with the developer to make sure things are harmonious. (and we should be doing this, with or without bounties). In fact, the bounty system should encourage & promote the idea of harmonious code which will be part of the main Tiki distribution.
I see the bounties as an extension of the wishlist. People can now vote on tracker items. Next step is to have a pledge system. I pledge $20 to solve this bug, etc. I favor using dev.tikiwiki.org, either extending current "Wishlist" tracker or adding another tracker which serves to add "meta-data" to current trackers. If we can't do within 1.9.x, then, it's a good reason to Dogfood 1.10
If it's on another site completely (to handle money, etc), I hope the technical information about the bounty are still on dev.tikiwiki.org, which should be the master wishlist for everyone helping Tiki become better. So it makes it easier for community members to comment/enhance/discuss a bounty.
I am looking forward to reading everyone's ideas on this topic.