freakboy3742
commented
9 years ago I'm not sure if I'm completely understanding your proposal - let me paraphrase and see if I've got your intention correct.
What you're proposing is an analog to a capital raising stock market. A project issues "shares" in project governance. Those "shares" entitle the shareholder to votes that direct what the project should prioritise (specific features, bugs etc). Those "shares" are also freely tradable. If a project becomes successful, more people will want shares, which means the original "investors" will have an asset that is appreciating in capital value.
If I've understood you correctly, this is a very interesting idea, because it takes a model that works really well in the capitalist system - stock trading - and applies it to project management. It's effectively no different to a "wall street" stock exchange - where you buy a share of physical assets and get a slice of control of the board.
It's especially interesting for new projects, because you're proposing the same deal that VCs get - in exchange for early capital (with more risk), you get a chunk of shares that will hopefully increase significantly in value over the long term.
It also means you're not selling anything that you weren't interested in selling anyway - that is, the priority on the list of features and bugs that need to be addressed.
Some potential pitfalls I can see:
- The biggest problem with open source projects is ongoing funding. Once you've made a share issue, you have all the money you're going to get - and often, people are expecting a dividend return. In a traditional share market, a company has a source of revenue; open source projects wont.
Two possible solutions:
- Reverse the dividend arrangement and expect that shareholders will pay an annual dividend rather than collect one. That annual dividend would provide the ongoing revenue for the project. If the annual dividend isn't paid, the share would revert to the capital pool of the project.
- Another option would be to control the market itself, and charge a "tax" on every market transaction. If the market itself took X% of the sale price the act of trading in the market would generate the ongoing operating budget. As a side effect, it would also discourage purely speculative investment (i.e., investments doing microtrades to generate profit based on minor price fluctuations). However, as a share becomes "blue chip", the frequency of trade is likely to decrease, which will affect the revenue stream.
- Using the word "share" could get really interesting - legally, you'd need to make sure you don't fall foul of securities regulations etc.
- One possible outcome would be for a large company to come in and buy all the shares, thereby controlling the direction of the project. It might be necessary to have antitrust rules limiting share ownership, just as Wall Street markets do.
- In the early days of a project, the decisions about features and bugs etc are really important. However, once a project stabilizes, this is less of a concern. Take Django, for example - sure, there's still plenty that could be added, but all the really important stuff that is needed is there - because if it wasn't, people wouldn't use the framework. So - doesn't this devalue the "asset" that has been bought? If there isn't a need to pick specific bugs to improve, or features to add, why would I want to own shares? How do you maintain "value" of the asset in the long term?
rethore
Basically you issue some tokens that represents a share of the open source project (OSP). People/Companies that are interested to have an opinion about where the project should go, what should be the priorities should buy those tokens in order to "vote". Votes are done by giving back the tokens to the DCO, which are then put back by the DCO to be sold on the market again. The cash accumulated by the DCO can then be redistributed to its core programers as salary or as bounty for external programers. Another aspect could be that, if you think that there is an issue that you think is important, you can buy tokens on the exchange market, and you allocate them to the issue. They work as a bounty, until the issue hasn't been closed, the token is kept under the control of the OSP (or even better an Ethereum smart contract). When the issue is closed, the tokens are redistributed to the programers that contributed to fixing the issue. They can then sold by the programmer on the exchange for e.g. bitcoins or be reused to vote on decisions concerning the OSP-DCO. This way both people that work on the project and people that invest on the project can vote on the direction that the project should take.