In how I further described the process it requires no approval by the community. It's done through the committee members. Every FBA should have the opportunity for fight or flight based on its own merits. Prior to issuing an FBA the committee holds the vote to determine if the FBA was done with due diligence. I thought about having it run through the Worker proposal for this function, but then we are back to community members at large voting down features that they 'feel' is not important or should not be focused on. The beauty and point of the FBA is that if an entity or people are willing to invest their own money to create something then it should be give the opportunity by those that want to see it succeed.
Approval from committee members isn't enough, it has to be worker proposal. Or we could create new kind of worker proposal that is meant only for FBAs. But the point is that if the new feature will require a hardfork, it should be approved by the shareholders. Just like it is now.
I don't think that the problem of shareholders voting down FBA-proposals will last very long. It is problem only for a short period when only party that has enough skills and knowledge is Cryptonomex. When there are other developers who can be hired to implement features, they will be voted in without any problems because they don't consume any manpower from more important features that are funded by DAC.
I agree.. that's where I started from and as my post continued I pushed the idea more towards it happening within the Worker space. However when it comes to managing the FBA ongoing, it really should be in the hands of the committee members just like MPAs. Otherwise we invite liabilities and other issues into this. The developers of the feature however are free to set the terms of licensing however they see fit. It's the coop setup of the whole thing that can introduce serious regulatory issues that can cause problems if not setup right. Thus you do not want a single person/company to be the holder of an FBA, you want it to be part of the decentralized network. In the end, if they want to profit from the introduction, they can always buy up as much of the FBA as they like when it gets created.
Only time committee members might need to manage an FBA would be to adjust the fees to compensate for market movement.. ie. BTS goes from 0.001 to 0.10 .. pretty sure the FBA holders would like to see some action taken on that.. and I envision this to become a regular part of committee member activity that would likely just shift all fees on a % scale easily to compensate with the market movement. This again should not be left to an individual for securities and liability reasons.
We don't want a crowdfund.. we want a coop as far as how this works where regulations are concerned.
What if the FBA that is created and issued into the market for sale for funding, all the funds will be submitted into the RESERVE POOL (same pool that Worker Funds come from) and inside of Worker pay methods there is a new type of Worker pay method that can be paid via the FBA supporting the feature?
I think this is too limiting way for funding. Remember, we are trying to get privatized funding here. There can be many different kind of developers, companies, investors and crowdfunders and not all of them are interested in having the funding go through reserve pool. Simpler way is just to give them the FBA and they can do whatever they think is best and suitable for their business plan.
I think I may not have explained it clearly enough. The funds are going from the FBA sale into the reserve pool which is payout out for the Worker 1:1 with it's budget for the FBA project only after it has reached 100% of funding via the sale of the FBA initial shares issued. Anyone will be free to buy them on the DEX (though I think a better interface should be used for that initial sale). This uses our existing systems and prevents crowdfunder fraud transactions and keeps all the transactions coming from whomever is contributing coming through bitshares. It all stays on the blockchain. The payment might not need to go to the reserve pool actually though. Could just have the funds go directly to the Worker that created it. However a new mechanism would need to be created to either vest the balance until 100% funding is reached or some other parameter.
A wish list item might be to have the FBA created be able to have the initial funding specified in the Asset of choice. In other words if someone says it will cost 20,000 CNY to get done, then the sale of the FBA Asset wlll be in CNY and passed through to the Worker as such. This to me will eliminate some market variable waste, and also help the project managers/developers with their own tax reporting/accounting.
I like this method better.. it will keep our funding method for new features in the same place under Worker.
This is not only and maybe not even preferable way for funding. I predict that there will be lots of complaining in this kind of contracts. Crowdfunders want a feature and somebody says "yeah, I'll do it for 20k" and after a while they announce that "20k isn't enough, I want more".
I think easier way would be that a company or a group of developers make the feature half way ready and then announce that "we have a new feature and if you want it implemented in Bitshares, we want in exchange an FBA with these parameters". BTS shareholders don't need to know how much the feature cost to develop – all that we have to care is that will it be a good deal for Bitshares. Do we want that feature on the blockchain, how many users it could get, etc.
How good or bad the developers are will depend on the judgement of the community at large. I am rather confident they are going to be ruthless in their vetting. What you are arguing is exactly the same thing that can happen with Workers now. Has nothing to do with FBAs. If you have devs half way develop things before introducing them to the community they certainly can do that if they like.. I doubt you are going to have many developers take that risk though. It is far more likely that people interested in a particular feature are going to seek out dev resources on their own prior to rallying a fund together much like what you have seen happen with Stealth feature. Even if they start from forum and someone says they can do it for X amount like you said, the funders can decide how to handle that long before creating an FBA and perhaps ask the dev to do as you suggested in creating it half way on his/their own. That would/could all happen pre-FBA.
@rgcrypto mentioned division of funds. I agree with 20% going to the network. However, the accumulation of 20% for maintenance seems like a slush fund that is just going to be raided by.. who? Would it be enough for all those things?
I think its better to let the profits go to the funders.. have the 80% go full on to all holders.. they are free to buy and sell them as they wish in the market. If there is improvements or updates to be done it means another worker and more shares put out on that FBA feature. Existing holders can either buy them up in support, or allow others too and dilute their positions. The 20% otherwise could become a bottleneck to properly funding things.. then we have what
@Samupaha said about developers coming back saying they need more money (for different reasons.. ie the fees collected in the 20% isn't enough to cover the maintenance or updates) and now no decentralized mechanism to get the job done.
In the end.. what I am suggesting in how FBAs work gives total freedom to whom ever wants to see a particular feature backed that others are likely to want to be involved with to create a worker proposal that can then be bought up by whom ever would like to participate while keeping the entire coop decentralized, sustainable, efficient, and free of regulatory issues.
Topic: Fee Backed Assets (FBA) (Read 13763 times)
