Re: Model for FOSS financing by consortium

Rich Bodo <[email protected]>, wrote in part:

> If I understand correctly, Distributor is probably a non-profit.  The
> software is provided to a Customer of the Distributor.

Why non-profit?

> O.K. So a hypothetical.  Developer writes a widget, puts Copyright
> Developer and GPL at the top, and submits to the Distributor.

I guess it could work that way, but I originally conceived of
this as the Developer is the first Distributor.  The developer holds
onto his source until he gets the price he sets, and agrees to treat
all customers fairly and move the price point gradually.

Of course the downstream recipients may want to re-distribute,
but they can use this or any other model according to the open-source
license.  Their selling price does not affect the contract or
trigger any refunds for the upstream distributors, of course.

> First_Customer is betting that Other_Customers will agree to pay
> Distributor for use of widget, therefore causing Distributor to
> effectively pass on a portion of that money to First_Customer.
> 
> I think this would be interesting to me if First_Customer was viewed
> as funding widget, and could earn unlimited "refunds".  This would be
> "cool".

First_Customer gets a one-time refund, and then only if the Distributor
sells to other customers for substantially less within 12 months.

There are no "unlimited refunds", but a distributor who did their
marketing correctly might be able to build a substantial number
of paying customers before the source became well-known, and by
then there is probably another version available.  

A distributor thinking rationally could decide that each customer
was going to purchase 3 or 4 upgrades over the product life, or that
most customers would purchase related products and services (some
of which may be proprietary.)  This would tend to lower selling
prices, and therefore increase likelihood of distribution contracts.

I can imagine also a system where the contract is for a limited
time access (per month?) to a repository under active development.
The distributor (who is the developer) should then try to set the
price to fully cover his development costs for that week.  (Of course
there are some issues about whether the product is usable, etc, etc,
but it allows customers to break off the deal with everything they
paid for up to present: they have the source code.  So this is better
to fund "improvements" instead of "from scratch."  That's OK, since
most development is "improvements.")

The refund arrangement is designed to permit First_Customer to remain
rational and not think that delayed purchase is a good strategy. Knowing the
price levels will not change that fast allows PHBs to do NetPresentValue
calculations with reasonable risk.  (Well, not exactly:  they just
get a refund if prices do drop that fast, which means they are not
worse off than their competitors.  It is a protection against deflation.)

I agree that changing clause 4 could result in a model with
unlimited refunds to first customer, and that could be used
to encourage speculative funding. That would be a totally different
than what I intended.