Fundamental Problems
				of the
			Paid-For Free Software
				system

A) The moving (technical) target problem:
	modularly adding/removing a feature is easy:	

	After acceptance, handle an addition like a new project.  
	Before acceptance, provide an allocation tree so customers
		can vote with their money on any separable parts

	A simple submission list can handle contributions
	of ideas, specifications, implementations.

A') Other moving target issues: 
	Money contributions also are simply accepted.

	Change to a spec requested by the customers or developers: (a)
	customer requests for performance enhancement may require
	redesign of underlying structure, or (b) the idea contributor,
	developers, project manager, may request changes to make
	development or study easier.

	Treat such modifications as OVERLAYS: Separate projects which
	cover & fill down into previously-committed/done parts.
	Pre-acceptance, the engineers vote with their works which can
	implement one or another overlaid layer.

	Changes may be demanded before or after acceptance.


B) Consider a world of ideas/software components, a world of Darwinian
economic competition, containing many coexisting variants of the same
idea, different implementations for the same UI, different sets of
peripheral features, different UI models for the same functionality,
where survival is permanent, once proposed it is always there, but
success is measured through acceptance and scale of use.  

We need structure for clean proposal, implementation, combination, &
payment in this world where contributions are made one time only.

C) Cash accounts should be in a hierarchy of accounts from an S&P 500
index fund to more liquid accounts (or maybe they should be locked up
in something boring and trustworthy like T-Bills?  No, growth is more
trustworthy.)

D) Commitment/Acceptance should be in bits:
	0) I want it.  $ goes from customer to pending-acceptance account.
	1) I've seen it work.  X% goes from pending to dischargeable
	2) I'm satisfied it has no bugs.  (100-X)% becomes dischargeable
		if a bug list is cleared for period Y this can be automated.

	This can be broken down by project components according to the
	customer's choice.

E) Costs & compensation for developer, specifier, administrator:
	Developer: self-auction (self-set but competitive).  Include
		a delivery date (winner is i: the first to be received
		or ii: the cheapest component completed before the
		acceptance date or iii: before the subscription-complete
		date.  
		
		I think this is best managed by a project manager who
		has a reasonable sense of what programming talent is
		being paid nowadays

	Idea specifier: 10% fixed percentage.  
	Administration: 10% fixed percentage or cost plus margin
		whichever is greater

		Specify a fixed amount or a percentage of the project cost
		Specify it by rule or by informal negotiations with the
		manager, specifier, administrator or team leader.

F) Maybe expose buyin amounts only up to the previous weeks or N
days/hrs/secs to encourage many to jump in as speculators, to include
land-rush mentality.

G) Intellectual property protection/certification
	a) Developers must certify it's their own IP and doesn't
		infringe.
	   The system should provide detailed directions for
	   developers to check  their employment agreements & get
	   written permission from employers.
	b) developer owns the copyright and signs a license agreement
	   giving unlimited, irrevocable GNU rights  to the system (& public)
	c) developers must indemnify the system against IP attacks.

H) The first dollar problem. 
	Why should someone contribute if noone has contributed yet, since
	the project hasn't become real yet?
	
I) The last dollar problem. 
	Why should I be the last contributor if they only need 
	one (or few) more, since the system could survive a minor
	income shortfall?

J) The payment-phase termination problem.
	When do we know we have collected enough money? 
	
K) The escalating costs problem.  
	How do we prevent greed-based abuses by the
	non-customer constituents? What prevents a developer from
	demanding an exorbitant amount for their contribution.

L) The competing submissions problem.
	How do we minimize redundant development?

M) The corruption and abuse problem.
	If this idea is not patented then it can be used with
	trivial changes for nefarious purposes.
	Proprietary software development could work on this model;
	all they need to do is change the developer agreements
	and maybe if they use a more persuasive sales
	technique they might completely outproduce us.