The OP's intentions are good, however provided with funds, those should go directly into the development for Kaya, either by our hands or independent developers.
All and any funding of the project should go into helping Kaya be a better server as it's always been.
Right from the start open sourcing was always an option we considered. It is part of my vision for a server to be constantly evolving and improving, and Open sourcing the server might be the solution to achieve and continue that independent of my capacity and ability.
OpenKaya is proof of our intentions to have an open platform, where many people contributed libraries and utilities used on the server, like the rating system, scoring and estimator algorithms, time systems and more. We have built APIs that collaborate with external sites as well.
Open source means that anyone has the capacity to read code in a platform they use or consume. It doesn't mean that an open source venture is absolutely free or that people working it are doing it for free.
What other uses code readers can do on open sourced code is mainly dependent on licenses.
Also, it does not mean that any programmer can perform a code change and see the effects on the server as he pleases: it has to go through a controller that verifies that there is no malicious code, bugs or simply detrimental to the service in one way or another.
I was the code controller in Open Kaya, providing coordination, assistance, testing and doing hard-code contributions, and would gladly be so for any other part of Kaya that gets open sourced.
Open-sourcing however is not a silver bullet. There are other go servers right now that are actually open source and they don't get a swarm of contributors. Kaya has a much better position to pull this one off though.
However there are consequences. Once the code is open, potential security or usage exploits become a lot easier to find. Ideally, those that find the issues contribute to fixing them, either by reporting them or by performing the fixes themselves. With malicious intent, provoking issues could be very detrimental, causing downtime or other plethora of issues.
This means that we have to be able to respond to such issues in a timely fashion to protect our users.
Its also a commitment on our part to document and assist the community into contributing. OpenKaya is worked that way, but the server and the full client require a much higher level of commitment on our part and also on a potential contributor.
In a regular programming job, its not uncommon to spend the first 2 days working over the local environment to set it up.
It is in my best interest to create a community of contributors around Kaya, that is the guarantee that im interested and open-minded about this topic.
To make an open source initiative effective, we need to be very well organized and prepare ourselves for it, making an informed and very conscious decision.
There are so many fronts and covert-ops projects on Kaya and it has many features ready to explode on the client, provided with more development power.
------ OT -------
At one time we toyed with the idea of making a Feature market. So ideas could be taken from uservoice and posted there, and estimated in cost. Then people could directly fund a feature they wanted.
The idea seemed hard to make and mantain so we dropped it

----- OT 2 -----
Kaya now has also Ayabot!
And we actually made a release today, related to a much better translation support.