Skip to main content

Why Shared Projects Would Work

We recently described a proposed paradigm shift in managing knowledge work. This generated a few questions, which we endeavor to answer below. In summary, we explain why shared projects would work.

I. Why Would Marketing Work?

Because Many People Value Software

Supposing shared projects could facilitate the development of better could that software be marketed to customers?

Shared projects would work because they would not need to deal directly with marketing. We anticipate that there will continue to be a high demand for the development of valuable software. We simply propose a better way to manage that software development. As the software is developed through shared projects, it could be brought to market through similar channels as today.

For example, if a company wanted to provide XYZ software to its customers, an employee at the company could launch an XYZ project on the market. That employee could represent the company as the admin, and the company could maintain control of administration by holding a majority of the stake. The company could then market the resulting product to its customers through existing channels.

II. Why Would Authenticity Work?

Because Many People Trust Lasting Public Records

If an admin launches a shared project, and perhaps developers also already contribute some level of implementation, what would keep somebody else from "stealing those ideas" and claiming them as their own?

Shared projects would provide lasting public records of who launched and harvested what projects, when. The market would endeavor to prevent people from maliciously tampering with those records. If a question arose about which were the authentic project for XYZ, or who were the official admin of the XYZ project, the market records would provide an authoritative single source of truth.

This follows the same principle underlying a patent or copyright office. Further, we could argue that a market like this might implement that principle even more effectively than those offices. Enforcement could be baked into the technology before it would need to be litigated or settled in court.

III. Why Would Incentives Work Early?

Because Trading Can Provide Early Value

Let's say I'm an early admin or developer on a project. How do I earn incentives for early contributions, before the project has matured to the point of being very valuable?

The market would allow the general public to openly bid to buy and sell shares in exchange for incentives. This system rewards traders for accurately predicting future value, early. If traders can tell from the initial launch or early stages, that a particular project is likely to grow very much in the future, they will have a strong incentive to invest as much as they can in that project, as early as possible. They will also have an incentive to be as accurate with those predictions as they can. That will allow them to maximize their rewards when they sell back shares for more incentives later.

Since the admin and developers could be the earliest stakeholders, the market would reward them quickly through stages of project growth, as traders competed to bid higher, earlier, for increasingly valuable shares.


It would be valuable to provide a better way to manage software development, because we anticipate that there will continue to be a thriving market for the efficient development of valuable software. It would also be valuable to maintain a lasting public record about certain contributions, because a market with such records could provide an authoritative single source of truth for those projects. Such a market would also provide a valuable way to reward contributors, amply and early. So, consideration of how shared projects would work with marketing, authenticity, and early incentives, serves to illustrate the value of shared projects even more clearly.


Popular posts from this blog

How (Not) to Handle Different Exceptions

Came across this sample from a certain multi-billion-dollar company, purporting to show how to implement exception handling. I slightly changed a few cosmetic details to make it anonymous.
try { // ... } catch (GeneralException e) { if (e instanceof SpecificExceptionA){ // ... } else if (e instanceof SpecificExceptionB){ // ... } }This is a true actual story--you can't make this stuff up. Yeah, I thought it was pretty hilarious; so I felt like I had to share it.

What We're About

About UsMission Statement: We provide a product to make high performing software developers happy by giving them a chance to work in a more self-directed way on software that is more meaningful to them. Core Values (in priority order):Integrity: Honesty, trustworthiness, and faithfulnessPreparation: Research, planning, and goalsReputation: Branding, naming, presence, and networkingProfitability: Product salesProduction: Product development, ideas, online contentImprovement: Research and trainingSupport: Minimal overhead Who We Are
Isaac Serafino is a Software Architect in Omaha, Nebraska. He has a strong experience developing technology solutions. He has long had the dream to lead his own startup business.
Our ProductsSnap Screen™
More efficiently provide a safe environment for using electronic devices. Sends pictures of what is on the display at somewhat random times so user knows they could be observed at any time, but the supervisor does not need to be their watching over their sho…