Idea Site™

Contents: Introduction Launch Trade Reward Develop Vote 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. 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

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 judg

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 presentation In email signatures On name tags In applications that provide limited space for profile information Whenever you want to provide easy access to many different contact options without listing each The main thing that would make

Contact Codes would make it quick and easy for any individuals or organizations to exchange all kinds of relevant, accurate, contact information. Then, the same service could be used to provide secure login and password recovery. Solution:  We would provide new codes for free through a public site on the web. Contact codes would be relatively short, unique codes, designed to be easy to enter through electronic devices. The codes could come with web addresses to retrieve the associated contact information. The web site would be optimized for mobile devices, and we could also provide mobile apps. Unlimited Applications: Associated information could include actual name, physical address, phone number, email address, and links to profiles on Facebook, Twitter, Snapchat, etc. It is important that we would not limit the associated information to any specific kinds of contact information. This lack of such a limit would allow these codes to be used for all  kinds of contact information,

The Problem When I have mentioned this to other people, most of them have been quick to agree: there's an issue with the way agile software development is done in many big corporations. Often separate people fill the roles of a business person or developer. Then, a breakdown in collaboration occurs between the two. Particularly, many high performing developers are frustrated. They feel the business people make poor decisions impacting software development. Consequently, developers lack the liberty to use their software development acumen to choose which software to develop, and how to develop it. Lacking this liberty, they feel pressured into developing software that they know will provide less value to the business. The Solution We propose solving this breakdown in collaboration by introducing a couple of easy metrics and roles: the Relevance Points metric, Relevance Spy role, Spy Stripes metric, and Double Spy role. Solution - Relevance Points™ Developers migh

Pain Story Software development costs a lot and still ends up with a bunch of bugs. Developers are frustrated because they can tell there's a problem: the development process is managed in a way that is very counterproductive. There's a systemic problem in the way software is developed in most companies: the process is fundamentally flawed. Business relationships with software developers breakdown through issues with communication, roles, scope, timelines, and productivity. Grand Vision As a leader in business, what if you could get business problems and other real world problems solved without the current issues inherent to managing developers? As a developer, what if you could have everything you need to develop, without the usual pain associated with going through a corporation to do it? We propose OSM (Open Software Market), a system to facilitate people to: Inspire : Think of great ideas? Share to find out which will fly Influence : Aware of needs? Promote