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
needed now).
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
coming back.

  1. 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).

  2. 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.


  • Great point!

  • These are very helpful. FWIW, I think we will probably want all projects to be open source.

  • Really good points. This may be unrelated, but what are the disincentives for contractors to leave the project? Would they potentially stake something? Or is it just reputation affected?

  • @someoneElse said:
    Really good points. This may be unrelated, but what are the disincentives for contractors to leave the project? Would they potentially stake something? Or is it just reputation affected?

    Pure reputation based might not really be possible, I mean we don't know "who" without a stronger Id system. So they can play beltway bandits on the system pretty easily. I definitely think there should be a stake they put in. Someone mentioned "Bonded Accounts" in the telegram the other day. This is an interesting idea - may apply here.

    If the poster is here on EOS go please help us elaborate on this. I'm not sure I totally understand the implications of that posting. I'd paste it in here but I'm not trying to hijack another users ideas as my own.

    As far as staking is concerned:
    So I think if they're gonna get WPS funds they should have to stake something just to front the proposal. And continue it throughout, as well as us bringing in milestone payments we may investigate vesting payments given. These all create a strong will to continue, in order to get paid in full.

    We'll have to hash out more on how that will be fair, but keeping that aside, for now, let's keep staking and reputation in mind as we navigate through the process a bit. (roughly).

    Limiting Proposal's inbound with staking requirement
    imagine the massive number of spam WPS proposals come at the system if we just open it up fully. The "Wen Lambo" crowd of nonsense spam will be easy to spot, and get rejected easily. Crap we can even filter on the word "Lambo" or "wen" for things like this.

    The more serious issue is what about the WP's that are all super-similar to each other. Nothing to stop me from copying your WP's, saying I can do it for less and tossing my idea on there as well. No ID mechanism. Here if we require staking we lose the "nonsense SPAMers".

    Upside: At least if you have to stake something to get in the input volume might go down. You (proposer) also tie yourself to the wallets involved. And we can watch you after that. So I like the idea of a nice sized stake on the proposal, but not unaffordable.

    Downside: I can still copy your WP and stake MORE than you to try to influence the decision of the WPS approval process if staking means some trust is established then more stake means I'll be more trustworthy... right? This sounds like a "Gas" war. And while the logic isn't really good, I can see it becoming a widely adopted strategy, and suddenly becoming the "Way it works".

    Staking Continued: Staking of payments? ("Vesting")

    Once WPS approval is given we'll have to agree that they receive bulk units of the total awarded bid on an incremental milestone basis, big chunks are typical, maybe 5-10 milestones at most in the commercial world. This is like a "Stake" or "Incentive" plan of sorts. They leave, they get no more money. So they'll want to stay to continue to be paid (we hope). I'll cover how we might tie up the payments also to discourage reaching milestone 1 and dipping out in a moment.

    1. Keeps Contractor working, keeps them away from reaching N milestones and leaving as soon as they get it. A job I was in once people would wait for bonuses before leaving the company. makes sense. They wanted to leave anyway, but waiting a few more weeks mean thousands of dollars. They were not contractors with a contract to abandon, but I've heard of that exact thing happening to my girl's mother's construction company with their sub-contractors. How do they mitigate that? ESCROW or BOND. We have similar functionality already, so we can simply copy the Project Management and business guide from general contracting for that portion of things (should we desire to).
    2. Helps THEM (Proposer/Contractor)budget. We shouldn't want to watch their books, but people in general, even well managed contracting companies, will blow through cash if they get it all at once.

    How do we implement such functionality:

    1. Break up milestone payments. Once Milestone 1 is reached, Milestone funds are released 50% at once, the remainder in a 3-month timer. Will work with a smart contract "Deadman switch". Return the WPS funds to WPS if we don't tap a button that they're on track in 3 months.

    2. We could also grant them "trickle" funds from an account that might be set up to grant funds over shorter increments than a milestone or a quarter year. This would be anything that approximates a "running budget". Weekly incremental. I would suggest that they get 75% of Milestone 1 is awarded instantly, 25% is awarded weekly over 3 months. We can set it up so that stops after so many milestones have happened, and they revert to normal Milestone to Milestone payments. Or we can go the other way and increase the % given in this fashion as they get closer to the end.

    3. I think a portion of the final WPS payments given (maybe 15%) might be good if they vested somehow also over a longer term. Perhaps inversely to the initial amount staked on the WP. (Stake more, get your final payment vested faster). This also makes the contractor want to stick around a bit. I would say maybe the coins are locked in a contract address for however long. We don't need to have the ability to interact with that contract, it can simply be a final payment timer. never forget the blockchain gives us super visibility into these folks, the longer we keep them under our eye the better for the WPS system, we'll be fighting SCAMs and poorly managed projects and Arbitration orders a lot. I think the more we keep someone IN WPS throughout the duration of development is a good thing.

    Final Statement, WP's for BP's
    This is tricky, BP's want development funds. I almost feel like we have to give it to them "Project/Need sight unseen" at the moment. I'd love it if someone drops a note in here about how we're going to handle these guys. They want they can 15/21 so we need to just keep that in our heads. They shouldn't feel incentivised to get executive on the chain. More on th at in another thread if a responder doesn't mind.

    We can't expect them to stake too much of their funds upfront. We'll have some issues with "gas wars" over proposals this way too, reputation would be preferred here IMO, but we have no mechanism. Perhaps MVP2+ will have access to this kind of functionality.

    STRUCTURE around the system will be good, I don't anticipate wanting or participating in creating a huge bureaucracy here. But I think if we don't harden ourselves a bit we'll be in a larger world of hurt. Balance is always important!
    WPS controls the process with milestones and stakes and "vestments" of payment. It encourages people to stick around, and PRODUCE. that's what we want. It seems game theory evident that we want to incentivize them to do what will be good for the system here so that choice is made more easily. It's easier to stay in production than to run away, they'll stay in production.
    This will help protect us from ECAF. Why do I say that? ECAF isn't going to be massively technical on all issues! For projects that fail outright because of technical hurdles, it behooves us to have a ton of evidence on why we pulled back funds, or appropriated the remaining code and gave it to another contractor to finish. If ECAF has only one side of the story, that'll be a loss for WPS and a bad precedent for ECAF to work under in the future.

    Please critique my responses!

Sign In or Register to comment.