Skip to main content

Shared Project Manifesto Version 2

Contents:

  1. Introduction
  2. Launch
  3. Trade
  4. Reward
  5. Develop
  6. Vote
  7. Harvest

1. Introduction

IP (Intellectual Property) is a great asset but it is hard to produce well. We hypothesize that a market to facilitate shared projects would make it easy to produce IP better.
Light bulb, coin, and wrench, in formation
The Shared Project Model


The market contains projects. Each project has one admin and a number of traders and developers. One user can have any combination of roles at the same time. For example, a user may be an admin and also a trader, or a trader and also a developer.
  • Projects
    • Users
      • Admin: Provides ideas in exchange for control
      • Traders: Provide incentives in exchange for growth
      • Developers: Provide IP in exchange for incentives

2. Launch

When somebody came up with an idea for an IP product, they could create a project for it on the market. That person would be the admin.

The market would record the time the admin launched the project. That lasting record could provide for the admin to claim credit for the project idea, on a first-come, first-served basis. This recognition would provide an incentive for admins to quickly launch many projects, to claim credit for their ideas.
  1. Somebody comes up with an idea for an IP product
  2. That person launches a project for that product on the market
  3. The market provides recognition for that person as the admin of the idea
  4. The admin uses the market to divide the project into a number of shares
Traders could use shares to trade incentives for a stake in the project growth. The admin would be the first holder of all shares.

3. Trade

A trader is anyone who has an interest in the development of a IP product. For example, businesspersons want the IP so that they can benefit their customers. Investors want to find ways to make their investments work for them.
A trader is anyone who has an interest in the development of a IP product.
Shares simply represent a proportion of influence in a project. For example, in a project with 100 shares, a trader with 50 shares would have 50% influence. Traders could trade shares of projects somewhat like on the stock market.
  • Project
    • Number of Shares
      • Trader holding each share
      • Incentives per share
A trader can bid a number of incentives per share to buy a number of shares in a certain project. A trader can also ask a number of incentives to sell shares.

4. Reward

The incentives fairly reward developers for contributing valuable improvements. Developers can buy shares from the admin at a relatively low price, right after the launch of a project. Then, developers contribute improvements. Real improvements would raise the value of the project in the perspective of investors. That would increase the value of the developer's shares.

Admins already receiving significant incentives in connection with the development of the IP, could choose to share some of those incentives with traders by issuing dividends.

5. Develop

Developers would work in an environment, controlled by the admin, outside the scope of the market. Admins would have the final say over accepting or rejecting developers to access the development environment and make contributions.

Developers who were not accepted by the admin of a main project, could create their own project forks of the main projects, in the market. Those developers would become admins of those fork projects, with their own shares. The fork admin could then make contributions within the fork and send the main project admin a pull request to merge the fork, with its contributions, into the main project.

To complete the merge, the main project admin and fork project admin would negotiate a certain number of main project shares in exchange for the shares of the fork project.

6. Vote

Traders could positively influence the direction of the project through voting. The traders could cast one vote per share, to elect a new admin. This way, the traders would not need to directly control all of the development decisions. The admin could focus on that. But, the traders could still indirectly influence all of those decisions by electing the admin.

7. Harvest

Projects would grow as traders were willing to pay more. Traders would have incentives to pay more from having an opportunity to influence the project by voting, having an opportunity to receive dividends (from some projects), having the potential for future growth, and, by the possibility of being involved in a harvest.

One trader could buy (or keep) all of the shares. Then, that trader (known as a hero) could harvest the project. Once a hero obtained all of the shares and harvested the project, the IP product would no longer be subject to the market. The project would be replaced on the market by a monument which would certify that the hero provided adequate incentives to all other traders. The monument would provide an authoritative promotional referral to the hero's resulting product.

Comments

Popular posts from this blog

Contact Codes Lite™

CCL (Contact Codes Lite™) would be a software product to help people exchange many kinds of contact information much more easily. CCL would do this by providing users with relatively simple contact codes. The users could distribute the codes to many people in many ways. Then, a person who received a contact code could use it to retrieve the original person's contact information through CCL.

For example, many people still exchange business cards. Retrieving various information from the cards can be time consuming and error prone, especially when there are many cards. Also, when somebody updates their information, the information from the card is no longer valid.

Other good examples for usage of contact codes include:
On a slide in a presentationIn email signaturesOn name tagsIn applications that provide limited space for profile informationWhenever you want to provide easy access to many different contact options without listing each
The main thing that would make CCL different from…

Fog Machine

Fog Machine™ (named because fog is like a cloud, on the ground) is a software product to provide cloud services to customers without a cloud service provider. The problem with the traditional cloud is that it requires a provider. Fog Machine™ would run cloud "nodes" in idle system resources on ordinary user's devices. This would be a peer to peer system in which each connected device would be a peer.

It would support standard cloud APIs (perhaps Cloud Foundry?) and it would be easy to port cloud apps to it off providers such as Google cloud, Azure, or AWS--or maybe it would be effortless for apps that were already portable through compliance with open standards.

We might use encryption for privacy, redundancy for reliability, and remuneration/incentive for resource consistency. The showstopper (critical assumption) is that the synergy would be sufficient to significantly surpass the overhead, and provide competitive performance for at least some types of cloud applicat…

Please Comment

Have you ever heard of a similar idea? What challenges might an idea run into? How might you like to be involved? Comment to add your voice to each idea.