TITLE: Paid For Free Software

PURPOSE: A new method of organizing constituents to design, build, distribute and pay for projects (especially software products) which harnesses the power of customer money to drive projects, especially the process of developing software, especially free (open source) software.

BACKGROUND: Free software is built by sharing-oriented volunteer developers with capability, time, & interest to volunteer their efforts to build software (or do other projects) for the common good. With enough developer interest, large, complex projecs can be undertaken successfully. The problem is, volunteerism is a weak motivator. The solution is customer money and an organizing system.

DESCRIPTION: A system in which the various constituencies in a project can make their contributions, which organizes the various roles to work together. The constituents and their contributions and motivations are:

Constituent	Contribution	Motivation
---------------	----------------------	------------------------------
Customers	Money attached to a specified project	Gets the project done & needs met; receives access to the results. Early customers may get money back.
Idea specifier	Defines spec	Gets paid
Project Manager	Manages project	" " " " "
Administrator	Provides the system and in- frastructure	" " " " "
Developers	Work, pieces of the project	" " " " "

RAMIFICATIONS: Regular commercial entities such as corporations provide such an organizing system for producing and delivering products to customers. Normally the entity includes or hires the administrator, idea person/specifier, project manager, and the entity HIRES and PAYS FOR the developers, then OWNS the results & SELLS it to customers. Such an entity and such roles are dispensable in the current system. The administering entity need not have an employer relationship with specifier, manager, developers, nor does it need to own the results, nor engage in sales (per se).

DESCRIPTION (continued): The ADMINISTRATOR provides a perhaps publicly visible (e.g., on the internet) project infrastructure including a description of the project, its current state of financing & development & instructions for participation that each constituent must follow including agreements they must accept & pointers to (or full downloadable access to) the materials requires for participating (e.g., partly completed source code, spec, &c.) & financial accounting systems to accept customer contributions, to keep track of their association with the spec or project (or component thereof) which the customer determined & specified, to keep track of the status of the $ as it moves form the customer's intent to the ultimate recipient's possession, & of the constituents, their roles, & their contributions & current status.

The IDEA may come from a customer, a current user who comes up with an enhancement (enhancements can also be considered as projects in their own right), an independent inventor, a patent-holder, i.e., from anywhere. The system should include forums where ideas can be proposed, discussed, developed. However what is key is that the idea become embodied in a project SPECIFICATION, entered into this system in such a way that the contributions and receipts of the various constituents can be well-defined, so that the system can operate. The source of the idea may be difficult to establish because of the lack of records, the synergies of discussion, & simple disputes. But the contributor of a specification is well defined. It is the responsibility of the specifier (person, group, etc.) to obtain permission for use of protected ideas, which might reasonably include sharing the role & benefits as a group, pre-establishing the relative contributions of each. The system must require under pain of law that the specification be free of intellectual property constraints against operation of the system on it, so a LEGAL PROTECTION role should also be included in the system.

The MANAGER's role may be shared among other constituents or minimized, perhaps eliminated, by sufficient clarity in the specification and in the system itself. The goal is that all pull together out of cooperative self-interest. Yet a manager may be needed to keep everything running smoothly, to negotiate contributions & returns with constituents, to reinvigorate the structure where respect for it is waning, to unblock obstacles, replace developers, make needed modifications, etc. The less management is needed, the better, but to the extend it is needed it should be provided for. One approach would be to establish a management hierarchy of no management (let the spec & system operate without intervention), consensus-based management (where all relevant parties agree), democracy-based management (where voting or some other kind of shared decision-making process is used) to dictator-based management (where the manager decides), with rules for backing off from one level of the hierarchy to another, which motivate participants to avoid backing off if possible & practical, yet which reward energy & results over gridlock. Another approach is to be entirely mechanical: no management. Another approach is parallel management where multiple simultaneous manager-processes are allowed, with some means of combining or selecting from their results is used.(sic) Start with the mechanical approach & let experience suggest & refine the solution.

CUSTOMERS are constituents who contribute money to drive the process. They associate their contribution with a specification, & their money is transferred into a holding account associated with that specification. The customer determines the acceptability of the resulting product, and when so determined, indicates to the system that their contribution be transferred from the holding account to the distribution account. That is, there is a two-level accounting system. The customer's money goes first into the holding account, thereby being committed to the system irretrieveably. There it remains hostage until the product is delivered to the customer's satisfaction. To minimize the impact of customer obtuseness, there should be a bug list associated with each spec. Once delivered, if the bug list is cleared for a specified period of time, then acceptance is declared with or without further customer agreement.

ADVANTAGE: The bug list with sliding expiration of non-acceptance will keep the disputes focussed on technical issues, will give customers an opportunity to test & constructively to refuse to accept, pending fixes, the product; will help prevent abuses.

ADVANTAGE: Customer money drives the system. It motivates all the participants to deliver their contributions. The importance of this cannot be underestimated: this harnesses the motive force of capitalism and commerce itself to driving the development of products, especially free software, which otherwise depend only on the goodwill of volunteers.

...

DEVELOPERS *labor* to produce a *product* that meets the *specification* for an agreed *return*. The issues are a) how to measure their results & b) how to agree upon a return. (See invention.description for details)

ADVANTAGES: This system brings the power of customer demand and money to bear on projects without requiring capitalist ownership, management, hiring and invention. It harnesses self-interest in the development of free software (and other projects).

NOVEL FEATURES: Previous business models are based on the model of ownership of property, where the owning entity unites the functions of invention, development, management, administration, and pre-customer funding, in order to recieve & channel the benefits of customer money. Volunteer-based production for the public good, on the other hand, divides ownership (of copyright) among contributors, while giving access to all, divides development, management, & administration opportunistically among volunteers and eliminating funding in general.

In contrast, the new model described here relaxes the constraints of the property-owning business model, allowing different entities to do their various functions as in the divided-roles volunteer model, while retaining the commercial motivations of participants to receive customer money. It is a new approach by which paid-for projects are not paid for to a commercial entity which hires & manages the work, owns the results, and takes the money, unlike the property-oriented business model. And it is different from volunteer approaches which are not paid for. It has new structures to deal with the problems of resource allocation & transfer (e.g., the 2-level accounts and the declining-returns function). It is a business model which allows more people to participate in more flexible ways with lower levels of commitment, smaller contributions, and less constraints against availability of the results than the previous property based model, and with greater motivation than the volunteer based model.

The Buzz

Community Capitalism harnesses market forces to create public works instead of private property. It is a new and in some ways better way of getting projects specified, sold, built, delivered, and paid for without using either corporate capitalist ownership or pure volunteerism as the organizing principle.

Community Capitalism meets customer needs, harnessing market forces to drive and pay for good works from software to roadways to cures for diseases. It provides an organizational, financial, and technical structure for the participants (customers, inventors, developers, and managers) to cooperate, playing their respective roles, and receiving their respective benefits, while jointly getting good things done.

Everybody cooperates, everybody wins, the work is paid for, and the results are perpetual public property.

Great areas for CC applications include business niches where software is being sold expensively to a medium sized community of hundreds or thousands of users.

• Hospital and doctor's office software. Presently there are hundreds of incompatible, variably professional providers; doctors and administrators a hard time just choosing, then the integration issues are endless, etc. Take the software licensing costs out of the equation by a contribution to a community development project that delivers a compatible, widely usable, easily installed, learned, and updated system, then get what little tech support you may need to integrate it with your business processes, and work and live happily forever after. You just have to specify in the project requirements the user-level features you need such as compatibility or ease of installation, etc., and you will receive them in the results, otherwise your money contributions don't get delivered to the developers. Simple: you're happy, they get paid, costs are split across many other user institutions. Every doctor, office, and hospital ought to contribute $5000 today just for the possibility that it will be able to help them down the road. If it goes, and you will see others doing it too, then pretty soon you have a very motivating pile of cash that is attached to your needs, and it will soon enough get done and make you happy. A small small price to pay for long term high value utility.
• Retail, restaurant, pizza joint software. Businesses need to spend lots of money on really simple software that ought to be better maintained, updated, more easily accessible, etc. If each contributed a little to a shared fund to drive a project that serves all, then good work will be done and good service received. Throw down $500 and get yours.
• CAD/CAM software. How come every plumber, inventor, and engineer needs to use Windows and buy AutoCAD? Put in $200 today for a lifetime license for something that does what you need, tell your peers to join you, and then watch the boiling as people who want money get organized to deliver something that will benefit you today and everyone forever.
• Business software. Why not make a checklist generating some free downloads and installs of compatible, co-working communications, HR, ERP, CRM, sales history, telephone call history, etc., business modules where data is shared across all modules so customer servicers can see the history and move workflow forward intelligently. Put it in your spec, throw down some money, talk it up with your peers to get the pot big enough to draw some attention, and watch the developers and providers get hot, get moving, and get 'er done. Then you click "Satisfied" after you are, and then they get paid. Sweet for everyone.