Skip to main content

Shared Project Manifesto

Abstract

Complex technical projects have various needs for sustainable success. Interested parties need a working product and creative workers need appropriate incentives. However, it has become increasingly apparent that the standard development model is not enough. The disconnect between technical workers and non-technical managers leaves both with dismal results and low morale. That is why we are introducing a fresh approach, which we call shared projects.

Introduction

We believe that the standard model for managing creative work is fundamentally flawed. Traditionally, non-technical managers would funnel payment to technical workers, in exchange for the product of their work. That system inevitably led to a major disconnect, since then there was no way for the managers to understand the nature of the work. Naturally, this caused many strained relationships and counterproductive decisions.

Managers have to make personnel and compensation decisions based on their best judgment of a worker's performance. But, how can they be expected to know the right people to hire, fire, promote, or reward with a raise, without an accurate way to assess their performance? And, how can they be expected to accurately assess worker's performance when they personally lack understanding of the nature and value of the work?

It has been said that "The productivity, indeed the social cohesion, of every developed society rests increasingly on the ability to make knowledge work productive and the knowledge worker achieving. This may be the central social problem of the new, the knowledge society." (Management: Tasks, Responsibilities, Practices, by Peter Drucker).

We feel that creative work is fundamentally different, and fundamentally different work needs a different foundation. A shared project recognizes three essential elements, which must each be present and work together effectively: ideas, incentives, and development.
Coin, light bulb, and wrench, in formation
Shared Project Diagram

For these elements, shared projects involve three roles: inventor, stakeholder, and developer. Inventors provide ideas, stakeholders provide incentives, and developers provide the working product.

Each of these roles complement each of the others. Inventors can receive incentives from stakeholders for their ideas, and they can see developers produce their ideas into the fruit of a working product. Stakeholders can choose to support ideas they value, and receive benefits of working products that are valuable to them. Last but not least, developers can be informed by inventors of what valued ideas are available to implement, and receive incentives, accordingly, in exchange for their work.

I. Resolving the Underlying Disconnect

Our hypothesis is that there is a systemic problem with the traditional way creative projects are managed. Traditional managers often value the wrong products and reward the wrong workers. Now, we are not talking about bad management, in general. That is a separate issue. We hypothesize that there is something about creative work itself that makes it particularly hard for otherwise good managers, to make good decisions.

We need to recognize the distinction between ideas, incentives, and development, because there is more to these projects than simply pay and work to produce a product. The overly simplistic traditional model does not provide a way for non-technical decision makers to make good decisions impacting the work.

The root issue is the disconnect. It simply can't work to have a decision maker who is supposed to provide incentives and direction without understanding the issues, and a developer who is supposed to provide a valuable product without accurate feedback or the freedom to do the work the way they think it should be done.
The solution is the concept of shares.
Ideas, development, and incentives, should stand on their own. We would accomplish this by using something called shares. We could develop a system without shares to simply facilitate exchange of incentives between an influencer and implementer. But that system would become much more complicated quickly.

For instance, what if there were a second party who wanted to become an influencer? Then we would need the ability for multiple influencers to contribute to some communal pool of incentives. What if there were a second person who wanted to become an implementer of the same project? We would need a way to divide up the pool of incentives between multiple implementers.

It would be more complex, but we could still produce a system supporting multiple influencers and implementers, without using shares. But, what about the common situation where one influencer may contribute incentives more than another? Or, when one developer contributes more value to the product than another? So, you can see how it can get complicated. How would the system fairly divide up a pool of different sizes of incentives from different influencers, between multiple developers with different values of contribution?

Finally, if we could develop such a system, it would still only support one-time exchanges of incentives for work. In such a system, how would we prevent the phenomenon of dead projects? That is the painful situation where much work may be put into a project, but it ceases to provide value and eventually gets abandon. In a simple incentives-for-work system, the incentives and work are exchanged at the same time. So, there would be no way to provide early incentives for potential future value. Fortunately, there is a solution, and that solution is surprisingly simple. The solution is the concept of shares.

II. Shares Help Everyone

A market would facilitate shared projects. When an inventor had an idea for a technical product, they could bring their idea to the market. They could submit the idea to the market with some kind of brief, preliminary, description. This would launch a project. The inventor could then have their project divided up into some number of shares.

Each share would simply represent a conceptual division of a proportional amount of stake in a project. For example, 50 out of 100 shares would represent 50% stake. There would not be such a thing as certain shares tied to certain "parts" or "pieces" of a project. The project would be evaluated as a whole, and each share would simply represent a proportional amount of stake in that whole project.

Shares are a very important concept, because it would be very difficult to decide how to divide such a project up into parts. Such projects are a complex configuration of many different parts. There are many possibly ways to attempt to divide those parts. But, it can be readily understood that the chief source of any benefit from the project is the complete system. Therefore, we skip trying to map shares to parts. That way, we save ourselves a lot of work, and arrive at a system which makes more sense anyway.

III. Roles For Each Element

The inventor becomes the first stakeholder in their own project. The terms inventor, stakeholder, and developer, refer to roles, not necessarily distinct parties. Therefore, any one individual could hold any combination of these roles at the same time. A stakeholder owns shares, representing their stake in a project. A stakeholder can be any party with an interest in the product being developed. It is a party who has some reason to feel that there will be a certain amount of value realized through the development of the product.

It is important that a stakeholder is a distinct role, because there could be many different reasons someone could have a desire to have a complex product developed. It could be the inventor, as at first. It could be a potential customer, or a representative of a customer, such as a businessperson who feels their own customer would benefit. It could be someone with another product, that could benefit from that product. It could simply be an investor, looking for a new type of investment, and willing to risk their money for a potential gain. It could possibly even be a philanthropist, or someone trying to promote some social change.

Initially, the original inventor will also be stakeholder of 100% of the shares. But, anybody can become a stakeholder, and any stakeholder can trade shares of any project (assuming they have enough incentives to offer). To trade shares, the selling stakeholder places an order to sell. In the order, they ask for a certain price per share. Other stakeholders can place orders to buy the same project. Buying stakeholders bid a certain price they are willing to pay per share of that project. The market tracks and processes orders. When there are high enough bids to match the asking price, the market will facilitate the exchange of shares to the buyer, and incentives to the seller.

Also, the inventor can choose to issue a dividend. This is an amount of extra incentive that is paid per share to each stakeholder. The inventor could supply this out of some substantial income the inventor may receive in connection with a project with commercial benefit.

Developers can browse through the variety of interesting projects and apply to one they like. With good faith that their contributions will improve the project, developers can also become stakeholders by buying shares. As their work improves the project value, the share price can grow accordingly to reflect the increased demand. This growth provides an incentive to the developers for their work.

IV. Who Is In Control

Inventors have the final say in controlling the project. They decide whether to allow certain contributions. Each stakeholder can cast one vote per share to elect an inventor. This provides for representative government. The advantage is the benefit of limited democracy through voting, but with specialists to represent the voters while focusing on making good decisions efficiently. The ability to vote provides a substantial benefit to stakeholders, as they have an influence on the general future direction of the project.

Claiming Ideas

A market like this might not be very successful if it couldn't attract many good ideas quickly. Also, many inventors are nervous that someone could steal their idea. Without a solution, someone could hypothetically steal someone elses' idea, submit it to this market, and start receiving authority and incentives as if they were the inventor.

We could resolve this by using claims. A claim would be rewarded in the market on a first-come-first-served basis. An inventor could bring an idea and claim it on the market. The claim would publicly recognize and record that party as the official authentic inventor, at that exact moment in time. If any dispute arose about the original inventor afterward, people could refer to the record of the claim.

Additionally, such a claim system could help the market be successful, by helping it attract many good ideas quickly. Many inventors would have a good reason to submit claims quickly, to ensure they were the first to get the credit for their ideas.

The Harvest

Finally, a stakeholder who holds or buys 100% of the shares can harvest a project into a product. The ability to harvest a mature product is also an incentive. Once the product is harvested, the market publicly recognizes that stakeholder as the harvester, and provides a referral to their product. And, that product will no longer be subject to a project on the market.

Popular posts from this blog

AppDirective™

Directives go in, apps come out.™ An app to get software created without managing developers How it works: Go to AppDirective and become a CodeBoss™Provide a simple description of your problem to launch adirectiveSit back and enjoy reviewing and approving contributions AppDirective uses advanced technology to get the software developed that you want, without you ever needing to hire a developer.
Note: This app is currently about halfway built, at the time this is being posted. We plan to have it completed soon. Until then, please leave a comment or contact us to become a boss. Q&A: Q: How do I get recognized for being original? A: When you launch a directive, you stake a claim to your app idea on a first-come, first-served basis. AppDirective™ keeps an unchanging public record that you deserve credit for claiming the idea at that time.
Q: Does launching a directive protect my legal rights?
A: No. Directives do not provide any legal protection for Intellectual Property (IP) rights.…

Shared Project Manifesto Version 2

Contents:IntroductionLaunchTradeRewardDevelopVoteHarvest 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.


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. ProjectsUsersAdmin: Provides ideas in exchange for controlTraders: Provide incentives in exchange for growthDevelopers: 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 recogn…

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.