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

Reality Checks to Demystify Buzzwords

As an IT insider, I feel I have something valuable to offer nontechnical people in terms of correcting misinformation. Here are a few simple tests for some popular buzzwords in tech. When evaluating a product or service, if you can honestly answer Yes to the reality check question, the buzzword probably truly applies. If the answer is No, it is probably fake. agile Does it make the developers happy? blockchain Does it cut out the middleman? cloud Does it automatically scale? microservice Does it only do one thing? object oriented Is it mostly made of interfaces? RESTful When requests arrive at a certain address, are they ready to use (without parsing)? unit test Does it prevent the tested code from touching anything outside itself?

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.

Starting a company or Developing ideas?

Are you starting a company that needs software developed? Or, are you a developer with ideas? Take the chance to let us know what you want We need your input to be successful. Help us help you by sharing what problems are important. It would really help us out, and we would greatly appreciate it. Thank you.