3 ms·
I've been thinking about building something like you describe for a while. However I do see that there are problems of agency in making such an arrangement wor
by olefoo 14y ago
I've been thinking about building something like you describe for a while.
However I do see that there are problems of agency in making such an arrangement work. Anytime you have a revenue stream that is supposed to be divided on an ongoing basis; you are going to have a fight and everyone involved will feel shortchanged.
The best solution I've come up with so far is a multi-layered rental market where producers rent pieces of functionality and access to content-streams and in turn are responsible for monetising the end-result. But that's not solving the transaction costs of building small sites in a way that's better than elance/odesk/etc.
The fundamental economic problem you're looking at is how to fairly value different peoples contribution to a productive asset. The traditional answer has been to form a company that orders production and manages the assets and the distribution of revenue. This introduces overhead, and generally biases ownership towards those who brought capital to the formation of the company.
I do think a protocol solution is possible where participants agree up front to a set of rules, and automate the revenue distribution and asset allocation by an internal market mechanism designed to maximise overall productivity. However I'm under no illusions that it will be easy or profitable to be the one setting up such a system; at least at first.
- propercoil 14y agoAs the builder of the system you'd probably take percentage of all managed project, say 10%. The collaborators will set rules up front as you mentioned with a voting options to ban members that aren't contributing. It's nice to see someone who thought of this.
- olefoo 14y agoThe problem is, if you're setting up such a system; why should you limit yourself to a 10% cut? In the short term, if you're setting up a company that is building revenue generating sites, you can probably capture more than that in revenue if you're paying people to do the work. The accounting gets a bit fuzzy because we're talking about two classes of entities here (one in which labor expenses come out of net revenue, and the other in which they come out of gross revenue). Another trade-off is liability, who pays out if one of these projects gets sued; are they individually severable from the parent entity? If not, then setting up the system is unappealing compared to a traditional employment relationship. And if they are that raises the cost-complexity of the setup since you need to manage the transaction costs of setting up new entities as well as the ongoing overhead of managing the accounting for each of the formed entities. Basically what you're talking about is a setup that would allow web workers to earn residual income for their efforts as opposed to the present system where the route to residuals goes through ownership of the company. Effectively, operations management as a service. I have thought about this quite a bit. And would like to discuss this further, on the level of sharing models and projections.