The following is exact verbatim text taken from Tom Veatch's Inventions Notebook, dated 10/17/1999, based on ideas a month or two old at that date. [FYI, an Inventions Notebook is a bound notebook of numbered hand-written pages containing, in dated order, descriptions of inventions including sections labelled Title, Purpose, Description, Ramification, Advantage, Novel Feature; each page has the inventor's and witness(es) signatures and dates. It is normally considered adequate evidence for patenting purposes.] Thomas C. Veatch and Sprex, Inc., hereby assign their rights to the concepts described herein to the Free Software Foundation. -------------------------------------------------------------------- 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 get the project done & receive to a specified access to the results. Early customers project may get money back. Idea specifier Defines spec Gets part of the money. 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. 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. The 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 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. RAMIFICATION: Why should the first customer contribute? Early on there is little confidence that the product will be completed. Solution: Establish a declining returns function, by which early paying customers get some (perhaps all, perhaps a multiple, perhaps a high multiple of their money back. If the early contributions produce large returns because of the declining-returns function over the total contributions, then the customers will be motivated to contribute early. The declining returns function could be, for example, a declining exponential with a fixed multiplier for the first dollar and a fixed negative exponent and base: return(i'th currency unit) = m * b ^(-c*i) Thus every contribution gets some return but the majority get a small percentage back, leaving the rest to fund the project & pay off the earlier customers who through this approach have become investors. [drawing entitled Exponential Return Function] Other declining returns functions may also work. If the spec is good, likely to product a lot of paying customers, then a foresighted customer or investor/speculator will contribute early so as to get those returns later. This bootstraps the funding of good ideas since early money will bring in the developers and then other customers as the project is closer to reality. RAMIFICATION: What sets the price? If it is software, then the cost of an additional copy is approximately zero. So the price could be fixed, variable, specified by the customer or in the project specification, calculated by formula from the projected expenses of the project and estimated number of customers, or determined by any means. Superior methods would extract larger contributions a) from those who will benefit more, b) from those whose needs are more urgent. Also they will c) cover the project costs over a reasonably-projected market size. Letting the customer contribute any amount provides automatically and by definition for (a) & (b) and Darwinian competition will ensure that market-desired projects are fully funded, (c), also by definition. However some minimum price-of-entry may be specified to obtain the privilege of access to the product (e.g., before acceptance is declared) to prevent late customers' download-and-run tactics, which, if allowed, would leave any project in a partly-funded state at the end, since noone would pay at the end when acceptance is on the way, and the only disruption caused is an incremental loss of revenue to already-committed constituents. If the minimum entry price is low then lots of people will pay it; best if any reasonable user should find it an easy decision to pay it, since there is an intrinsic value in buglist-traffic -- having all interested customers contributing. Aids to rational self-pricing may/should be provided to customers at their point of payment, including currently projected total market, current financial and technical status of the project, a suggested price based on revenue, cost, and market size, etc. Hiding or revealing some information to induce commitment may enhance income: e.g., the first contribution event might be hidden, so that speculators can gamble on being early & thus getting larger returns. RAMIFICATION: What terminates the payment phase? If free software is produced, and all contributions are fully paid up, then it is possible to terminate the payment phase, declaring the project accepted and paid for, putting the software out for free download and use in perpetuity. (Patches, modifications, enhancements, etc. will then be handled as separate projects.) If so the problem arises of the last customer's motivation. If they wait another day until someone else pays the last dollar, then they get the same product without paying. Mutually aware customers can indefinitely wait on each other in a game of chicken that has no endpoint. A customer with an urgent need may pay just to get it, even if they are the last one, if their need is urgent enough. That is, customer demand can automatically solve this problem. But sales-oriented deceits seem required. The last customer must not know they are the last, or close to the last: the percieved time window until it converts to free must be longer than the time window of needed use by the customer. Perhaps the date of conversion to free can be declared as far in the future, but changeable at the discretion of an appropriate constituent who is motivated to convert early (i.e., none of the above "'s), but only after full funding is attained, & who will remain inscrutable w.r.t. new customers. There may be other ways to systematize the last-customer sale. Another approach is non-terminating payment. If the product is copyright-owned by the administrator, as a condition of using the system, the price may be set by the administrator and never made free. This avoids the last customer problem and benefits the administrator, but eliminates the public-service motivation of all constituents (which is arguably irrelevant anyway since everyone has a commercial interest). If the payment-returns system provides ongoing royalties, effectively, to all constituents, then it becomes an eternal income stream for all. This would be if each contributors' return were specified as a percentage of future income rather than as a fixed price; many returns-on-contributions agreements are possible other than these two. 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. a): If the specification is made modular, then a developer can simply deliver the module & fix it in the face of bug reports. Since modularity is a goal rather than a constant assumeably present in all cases, we must provide for fluctuating specs, moving module boundaries, renegotiation of technical details & issues, arguments over whose module owns a given bug, etc This is best handled by a cooperating team where non-members can join if they happen to know how to solve a current problem. But then payment is made similarly fluctuating and endless disputes could arise, which may be solved simply by having a manager put prices on pieces or on time, and negotiating each contribution as it is made or proposed. b): Developer payments may be set by auction, bidding on a given part, or by a manager who keeps prices reasonable, or by fixed measures such as per hour or per line of code (the latter being inferior). Developers may be solicited by the manager or other constituents, and should be motivated to join by the presence of committed money as shown in the financial statements of the project. Developers do not receive (all of, or maybe just part of) their agreed payment until customer acceptance, & bugfree status of the project, releases money to the distribution account. The distribution account shall have a payment schedule and rules to determine who gets payments when. E.g., deliver date of a module puts that price on the schedule after all pre-delivered items are paid out on; no developer payments are made until a full funding or full acceptance or full cost-only funding or manager's decision event occurs. 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. 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.