Community owned code for every proposal
During the Zoom earlier today I inquired about WPS winners who may drop the project for some reason, If they drop in a stage we should "own" the code as the community. This is standard as Thomas said in most of these situations. The community needs to own the code. I see this being a good thing if a project bails for some reason, but potentially as something that stops someone from trying to get involved. I suggest milestones for payouts in general, but also payouts come with a bit of string attached, as more milestones are met the community keeps license on more of the project. We need to think about methods to control how people may abuse this system. At a million dollars, increasing over time, per day we're going to get hit with a ton of bad projects, and good projects that just technically failed to achieve written goals. WE the WPS and EOS community need to hold the code at the end of the day.
I don't know how this would work exactly, so I hope we get some discussion on the topic.
**For instance: **
1. What prevents someone from bailing and another group coming in and taking 99% of the code and changing a few lines, calling it unique and trying to reapply?
2. What happens when the same group or friends of theirs from the prior failed project come back and keep bidding and winning?
a. When hiring contractors I think the Federal Gov in the USA is the best example, there's a rotating door of "Beltway Bandits" who run projects into the ground, lose
intellectual property or physical property. Another contractor is brought in and then hires most of the same developers (who may have been part of the problem, but are
b. Another company entirely which is owned by the family of the previous companies owners starts to compete against them, even after so many failed projects they keep
WPS get's stuck with code we don't, and no other dev's understand. They won't want to take the existing code and use it unless it's easy.
a. WPS can mitigate this somewhat by making detailed documentation a part of ALL milestones so that they cannot get paid out before they document. Whoever is reviewing
code on these projects (the WPS project manager??) will need to validate that the documentation is good (on the surface, we cannot expect them to validate everything).
How do we determine Milestones? Can we in any way do this with a smart contract?
a. Not always.
b. If the results are qualitative in that may full automation here may not be possible.
c. So this leads us into a situation that is very similar to a normal escrow account, in which we need to define how funds can come into and out of a payment wallet/contract
address. The contractor will want to see the funds are available in the wallet perhaps, and view the contract timers on their being paid milestone 1 if we fail to do XYZ, and us
getting the bank back if they don't do XYZ before a certain time.
You can see the issues here. And these are all going to be solvable with code, we need to pay attention which means we need some structure around all of this, and where human's are concerned, additional oversight is always a great plan.
Thomas did a great job outlining how this might all break down and I think these discussions will really help. Please pour your thoughts down.